Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for February, 2009

Niveau :      
Résumé : opensearch

Utilisez-vous firefox (pas que lui, mais bon) ?
Avez-vous déjà utilisé la barre de recherche en haut à droite (probablement google) ?
Avez-vous remarqué que vous pouvez rechercher sur autre chose que sur google avec cette barre (petite flèche) ?
Savez-vous que vous pouvez ajouter Linux Attitude dans votre liste de recherche (petite flèche, bouton ajouter) ?
Savez-vous que vous pouvez vous aussi ajouter votre propre moteur à cette liste ?

Voici comment il faut procéder. Si vous avez un moteur de blog c'est déjà fait pour vous, ce n'est pas très intéressant. Sinon, vous devez disposer d'une page permettant de faire une requête utilisant un paramètre (peut-être même pas une recherche en fait).

Le principe est simple, il suffit de suivre le standard OpenSearch. Prenons l'exemple minimaliste de ce site :

<?xml version="1.0" encoding="UTF-8"?>
		<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
			<ShortName>Linux attitude</ShortName>
			<Description>Rechercher dans Linux attitude.</Description>
			<Url type="text/html" template="http://linux-attitude.fr/?q={searchTerms}"/>
		</OpenSearchDescription>

il suffit ensuite d'indiquer dans la page html que le moteur de recherche est disponible :

<link rel="search" href="http://linux-attitude.fr/dcOpenSearch/description.xml" type="application/opensearchdescription+xml" title="Linux attitude" />

Et si une favicon est définie pour le site, elle sera utilisée dans la barre de recherche pour décrire le moteur.

En lisant la norme vous verrez qu'il existe beaucoup de paramètres possibles, beaucoup sont inutiles. Le plus important est de lire le paragraphe décrivant les paramètres de la recherche. Et pour les plus courageux, OpenSearch recommande de retourner les résultats au format RSS ou Atom.

Il existe aussi quelques extensions proposées. La plus intéressante est la suggestion qui permet de jouer à la google suggest et de proposer des mots de recherche à l'utilisateur. Je prendrai peut-être le temps un jour de développer cela.

Niveau :      
Résumé : perl

Perl fait beaucoup de choses, trop, tellement que certaines sont complètement inutiles

Il est possible de changer la numérotation des tableaux :

# le premier élément d'un tableau sera maintenant le numéro 42
$[=42;

Il est possible d'allouer de la mémoire inutilisée :

# alloue 64Mio de mémoire pour que perl puisse les utiliser quand il meurt a cause du manque de mémoire !!
# ce qui ne l'empêche pas de mourir bien sur
$^M=64<<20; 

Les sections BEGIN {} et END {} sont des blocs très utiles qui s'écrivent tels quel, mais il peuvent aussi être écrits comme des méthodes :

sub BEGIN {}

Perl disposes de modules en provenance du CPAN. Parmi ces modules on trouve les modules Acme, dont voici quelques exemples pour bien en comprendre l'utilité :

  • Acme::Anything qui permet de charger des modules qui n'existent pas
  • Acme::Error qui permet d'afficher toutes les erreurs en capitales.
  • Acme::Godot qui vous permet d'attendre Godot
  • Acme::EyeDrops pour convertir votre code perl en ascii art (fonctionnel en perl), très joli d'ailleurs
  • Acme::Code::Police supprime toute erreur de code qui n'utiliserait pas strict en supprimant le code.

Niveau :      
Résumé : vi ; firefox ; iptables ; ip ; PS1

A utiliser sur vi (je vous rappelle l'existence du vimrc collaboratif) :
La touche '*' permet de faire une recherche sur le mot se trouvant en ce moment sous le curseur.

Dans firefox, pour qu'une recherche s'ouvre dans un nouvel onglet, tapez l'url about:config puis modifiez :

browser.search.openintab = true

Faire disparaître un routeur linux du traceroute :

$ iptables -t mangle -A PREROUTING -j TTL --ttl-inc 1

Créer un routeur fantôme dans le traceroute :

$ iptables -t mangle -A FORWARD -j TTL --ttl-dec 1

Renommer une carte réseau :

$ ip link name macarte dev eth0

Récupérer la passerelle pour une destination donnée :

$ ip route get 10.0.0.1

Et un prompt sympa sur plusieurs lignes pour la route (changez les nombre en 3x pour changer les couleurs) :

$ export PS1="${debian_chroot:+($debian_chroot)}\n<~~~ \e[01;34m\]\u\e[m\] sur \e[01;32m\]\h\e[m\] à \t #\# : \e[01;35m\]\w \e[m\]~~~> \n \$ "

Lorsqu'on écrit un texte un tant soit peu explicatif, on se retrouve toujours à donner un exemple. L'exemple est l'essence même de l'explication, essayez d'expliquer l'addition à votre fils sans utiliser d'objet "pour l'exemple". L'exemple est l'élément déclencheur de la compréhension.

Un long texte abscons ne permettra jamais à quelqu'un d'apprendre ni de comprendre vraiment de quoi il s'agit. Mais plus la formalisation est grande, moins les exemples sont nécessaires. Et pourtant même en mathématique, un exemple permet toujours d'avancer un peu plus vite dans la compréhension des choses.

C'est pourquoi il est indispensable de bien choisir ses exemples. Un exemple doit à la fois :

  • coller à la théorie qu'on expose
  • être valable
  • être concis
  • être commun dans un premier temps
  • être original dans un deuxième temps
  • ouvrir l'esprit

Si l'exemple met en pratique une simple action, vous ne retiendrez que les quatre premières propriétés. Si ce que vous voulez montrer est vaste, faites en plusieurs et n'hésitez pas à sortir des sentiers battus.

Exemple (:-) : Supposons que vous vouliez expliquer ce qu'est un fruit. Ne vous cantonnez pas à ceux que vous avez dans votre cuisine. Votre auditeur en déduira qu'un légume se trouve dans la cuisine (oui c'est peu tiré par les cheveux, mais vous a-t-on raconté l'histoire du robot a qui on avait appris à reconnaître des arbres sur des photos, et qui finalement avait appris à reconnaître la présence du ciel bleu ?).

Autant que possible, essayez de mettre en pratique tous les éléments de la définition. La tomate est un fruit, mais le rambutan aussi.

Ce n'est qu'à la condition d'être un peu original et d'exploiter les différentes variations de la notion que vous désirez expliquer que vous ouvrirez l'esprit de votre spectateur et qu'il se demandera enfin si oui ou non la pomme de pin est un fruit (de même que la banane qui n'a pas de graine).

En gros, ne prenez pas pour exemple mon article précédent.

Faites donc bien attention aux exemples que vous donnerez, votre lectorat s'attachera bien plus à les comprendre que la théorie sous-jacente. C'est aussi grâce à eux que vos correspondants auront un esprit ouvert et que vous augmenterez leur QI (félicitation, vous participez à l'augmentation du QI mondial).

Niveau :      
Résumé : HTTP

HTTP règne en maître dans le monde des protocoles. C'est le plus utilisé et il n'est pas près de lâcher sa place. Je vais vous rappeler pourquoi.

Les protocoles

Dans le monde des protocoles il y a plusieurs couches.

Partons de la couche 3 : IP. Ce protocole est internet à lui tout seul. Personne ne parviendra à le détrôner si ce n'est lui-même (IPv6). Les autres protocoles de niveaux 3 viables visent des niches ou du à-peine-réseau (bluetooth ou usb collent aussi au modèle osi).

Sur la couche 4 on trouve TCP et UDP, qui ont très peu de concurrents. Il en existe, mais ils sont rares car difficiles à développer (il faut toucher au noyau sous linux si on veut faire propre et efficace).

Sur la couche 5 on trouve des milliers de protocoles, ils sont faciles à développer (en espace utilisateur) et donc courants. Et pourtant, on constate que sur internet un très petit nombre d'entre eux sont utilisés en masse : DNS, SMTP, HTTP. Les autres POP, IMAP, FTP, SSH ... sont utilisés mais commencent à se faire anecdotiques. Pourquoi ?

HTTP

HTTP est de loin de plus utilisé parce que de plus en plus de services se basent directement sur HTTP plutôt que d'inventer leur protocole. Et ils ont de très bonnes raisons pour ça :

  • ne pas réinventer la roue, des bibliothèques et des serveurs existent déjà
  • HTTP est autorisé à traverser quasiment tous les firewalls
  • il traverse le NAT
  • il est capable de supporter la déconnexion (il fonctionne en mode non connecté)
  • le SSL est déjà implémenté
  • l'authentification est déjà implémentée
  • il est possible de développer rapidement une preuve de concept avec apache et un langage de script
  • il utilise une API très simple : question -> réponse

Du coup on le retrouve dans :

  • les sites web (ouf)
  • le transfert de fichier
  • les systèmes de fichiers (webdav)
  • les appels de fonction à distance (XMLRPC)
  • la gestion de calendrier (caldav)
  • l'interconnexion de services (SOAP)
  • les applications distantes (ajax)
  • la communication instantanée (Jabber)
  • et j'en oublie ...

Mais pourquoi une telle domination sur tous les autres protocoles ? Ce n'est pas seulement grâce à l'omniprésence des navigateurs. Tout d'abord HTTP propose déjà un certain nombre de services (voir plus haut) qui ne sont plus à redévelopper. Mais surtout, regardons ses concurrents :

  • SMTP
  • DNS
  • RPC
  • SNMP
  • Et c'est tout !

Oui c'est tout, en effet, ce sont à peu près les seuls protocoles qui ont été prévus pour être extensibles et disposer d'une couche supérieure. Ils fonctionnent tous sur le système question réponse et laissent le soin à la couche du dessus d'interpréter le sens des questions et des réponses :

  • DNS : basé sur UDP, non fiable, limité en taille -> éliminé
  • SNMP : idem, même s'il existe une version TCP -> éliminé
  • RPC : format binaire difficile à mettre en place -> éliminé
  • SMTP : il est difficile de récupérer autre chose que des codes d'erreur en SMTP puisqu'il est fait pour l'envoi -> éliminé

Si on veut développer une nouvelle application qui communique par le réseau, on a le choix entre inventer un nouveau protocole ou simplement créer une sémantique de question / réponse au dessus de HTTP et profiter de tous ses avantages. Les rares cas où ce n'est pas possible :

  • besoin de données en temps réel (et encore le débit augmentant, HTTP peut faire RTSP du pauvre)
  • besoin de la notion d'évènement du serveur vers le client (et encore, certaines bidouilles HTTP laissant la connexion ouverte permettent ce comportement)
  • besoin de multicast ou de fonctionnalités encore exotiques aujourd'hui

Conclusion

Le HTTP c'est LE protocole, celui qui remplace le TCP d'hier. Le TCP n'est plus ce qu'il était, c'est à dire la couche sur laquelle on se base pour développer un nouveau protocole. Vous pouvez être sûr qu'il y a encore des milliers de protocoles à inventer, mais vous pouvez aussi être sur que la plupart d'entre eux se baseront sur HTTP. D'ailleurs celui-ci étant extensible, il est probable qu'il évolue un jour pour être un peu plus générique et apporter des réponses aux problèmes qui se posent dans certains cas comme les évènements.

On ne devrait plus parler de TCP/IP mais de HTTP/TCP/IP. Finalement, on se rapproche du modèle OSI.

Niveau :      
Résumé :

La gestion des langues sur les unix c'est pas le paradis. Il est possible de configurer finement les choses, mais ce n'est pas des plus adapté.

Terminal

Prenons le cas d'un terminal. La gestion doit se faire en plusieurs endroits. Tout d'abord le terminal virtuel est lui-même un processus (sauf la console linux qui se configure différemment) qui peut avoir des langues différentes. Il doit en plus être configuré pour communiquer avec la même langue que le processus qu'il fait tourner. En effet cette communication n'inclut pas explicitement la langue, il faut donc qu'elle soit définie implicitement de la même façon de chaque côté.

En supposant que le terminal soit déjà lancé avec une langue donnée (disons le français). Celui-ci vous propose encore à travers son menu (mais chaque terminal est spécifique) de configurer la façon dont il communique avec le client (bash le plus souvent).
Cette configuration gère deux choses simultanément : le format des codes de caractère venant du clavier et envoyés à l'application et le format des caractères envoyés par l'application au terminal et qui seront affichés.

L'application lancée à travers ce terminal doit parler la même langue que celui-ci (à moins qu'elle ne soit graphique auquel cas on se fout de la configuration du terminal). Les applications sont configurées au travers des variables d'environnement LANG et LC_* (ce qui explique qu'à part bash, les application supportent rarement le changement de langue en cours de route. Cela explique aussi que tous les processus fils d'une application tournent avec la même localisation (gnome et les applications graphiques par exemple).

Variables

Ces variables configurent l'entrée et la sortie des applications lancées :

  • LANG définit d'un coup la langue, l'encodage et le pays utilisés par l'application c'est une valeur par défaut qui peut être surchargées par les variables suivantes.
  • LC_* sont des variables permettant de redéfinir plus finement les valeurs de LANG. Par exemple on peut choisir une langue française mais afficher les nombre avec des points à la place des virgules. Les valeurs de * sont CTYPE, NUMERIC, TIME, COLLATE, MONETARY et MESSAGES. Chacune de ces variables correspond en réalité à une fonction de la libc.
  • LC_ALL est une variable qui surcharge tous les autres LC_* d'un coup, les mettant à la même valeur.
  • LANGUAGE est une variable qui ne définit QUE la langue utilisée pour les messages (la partie codage ne sert pas), mais permet d'en spécifier plusieurs par ordre de préférence (séparées par des ':' ).

continue reading...

Niveau :      
Résumé : getfacl ; setfacl ; cp ; mv ; tar ; rsync ; chmod ; umask

Après avoir vu comment marchent les ACL, vous avez voulu les utiliser tous les jours. Et là vous avez besoin de quelques petites connaissances supplémentaires.

Les outils

Les outils de base ont pour la plupart bien intégré les ACL.

ls

Un ls -l ajoute un + après les droits pour vous indiquer qu'il faut utiliser getfacl pour avois plus de détail sur les droits.

Et c'est tout.

mv cp rsync

mv conserve les ACL.
cp conserve les ACL si on lui demande (avec les option -a ou -p)
rsync conserve les ACL si on lui demande (avec l'options -A)

tar

tar ne sait pas conserver les acl, il faut donc utiliser un outil différent, comme star, ou stocker les ACL dans un fichier à part et le sauvegarder avec tar. Ex:

$ getfacl -R repertoire > ACL
$ tar cvz backup.tgz repertoire ACL
$ tar xfz backup.tar.gz
$ setfacl --restore=ACL

scp

scp ne conserve bien évidemment pas les ACL, il ne conserve déjà pas les droits.

Outil perso

A vous de savoir si les script et les outils que vous avez conservent les ACL. Faites particulièrement attention aux systèmes de backup qui bien souvent utilisent tar. Si le votre ne les supporte pas, enregistrez le résultat de getfacl -R avec chacun de vos backups.


continue reading...