Linux Attitude

Niveau :      
Résumé : bibliothèque

Une bibliothèque (et non pas une librairie) est un fichier qui contient des fonctions que vous allez réutiliser dans plusieurs programmes. Il en existe de plusieurs sortes.

Les bibliothèques statiques sont des fichiers qui seront inclus à votre programme lors de la compilation. Ce qui grossira d'autant plus le binaire résultant. Avantage, il sera indépendant de l'installation de bibliothèques par l'utilisateur. Pratique quand vous voulez faire installer un logiciel par tout le monde (plus de problème de version).

Les bibliothèques dynamiques sont des fichiers qui seront chargés automatiquement par le système lors du lancement de votre programme. Elles permettent de l'alléger de beaucoup, mais rendent ce dernier dépendant de l'installation du système. Ce sont bien évidemment les plus utilisées.

Comment se différencient-elles ? Petit exemple en C.
lib.c :

#include <stdio .h>
void hello()
{
	printf("Hello world !\n");
}

main.c :

int main()
{
	hello();
	return 0;
}

On va découper la compilation en étapes élémentaires pour bien la comprendre :

Niveau :      

Savoir relire le code d'un autre est indispensable. Et ce pour plusieurs raisons, soit parce que vous voulez vous mettre à travailler sur un projet existant, soit parce que vous voulez simplement fournir un patch pour un code qu'on vous a fourni (probablement open source). Nous allons donc voir de quoi il s'agit, puis mettre en pratique sur apache.

Pour vous lancer dans l'aventure, il peut vous être utile de savoir utiliser ctags ou etags. De plus, connaître des techniques de lecture rapide vous permettra d'aller plus vite.

Plantons le décor, nous voulons faire un patch à apache 2.2 pour permettre d'ajouter dans les logs les durées de récupération de données par mod_proxy. Récupérons le code source et partons de ce qu'on sait (et n'oublions pas de le dupliquer pour nous simplifier la création de patch par la suite).

$ cp -a apache2-2.2.6 apache2-2.2.6.old
$ cd apache2-2.2.6
$ find . -type f | grep "c$" | xargs ctags

On sait qu'actuellement, grâce à mod_log_config, on peut logguer les durées individuelles des requêtes. Le code source semble divisé logiquement, nous allons donc lire modules/loggers/mod_log_config.c. Parcourons-le rapidement, on constate un certain nombre de fonctions log_*, probablement pour écrire dans les logs. Étant donné la façon dont elles sont appelées, il doit y avoir une référence dans un tableau quelque part. On la trouve en fin de fichier, ainsi que la fonction qui nous intéresse : log_request_duration_microseconds.

Lisons-la :

$ vi -t log_request_duration_microseconds

Deux choses intéressantes :

• apr_time_now() -> au vu du nom et de la précision, ça doit donner la date et l'heure en microsecondes. Donc on sait comment on va calculer notre durée.
• r->request_time et request_rec *r -> on en déduit qu'il existe une structure par requête dans laquelle on pourra stocker les dates de début et de fin.

Cherchons maintenant où appeler ces fonctions pour calculer les durées. Nous allons donc lire ./modules/proxy/mod_proxy.c. On le parcourt en largeur et on constate que :

• C'est plutôt bien commenté
• Les noms de fonction ont un sens
• La majorité des fonctions s'appelle proxy_*

Niveau :      
Résumé : ctags && etags

J'imagine qu'il vous arrive de lire le code d'un autre, ou même de lire le votre, et de chercher des fonctions précises. Si vous faites avec grep, vous perdez du temps a différencier les appels des déclarations. Si vous avez un vrai environnement de développement, alors vous disposez déjà de la fonction et vous avez raison.

Bon, maintenant supposons que vous n'ayez que des moyens ultra-sophistiqués à votre disposition, emacs ou vi.

Il existe deux commandes (qui en fait sont les mêmes) pour générer un fichier de tag qui sera lu par emacs ou vi pour retrouver instantanément ou est définie une fonction. Ces commandes sont etags pour emacs et ctags pour vi, avec presque les mêmes arguments. Elle comprennent toutes les 2 un très grand nombre de langages différents (etags --help pour la liste):

Pour indexer des fichiers :

$ ctags fichier1.c fchier2.h 
$ etags fichier1.c fchier2.h 

ctags génère un fichier tags alors que etags génère un fichier TAGS. Attention, les options par défaut de etags et de ctags ne sont pas les mêmes.

Avec vi, vous pouvez ouvrir directement le fichier contenant la définition de la fonction main en utilisant l'option suivante :

$ vi -t main

Pour utiliser le fichier de tags dans un éditeur déjà ouvert, vous avez plusieurs raccourcis.

• Sous emacs M-. main et M-x tags-search main(et bien d'autres http://www.cs.cmu.edu/cgi-bin/info2... )
• Sous vi :tag main et ctrl-]

Pour indexer tout un projet, utilisez une commande du style (à adapter selon le langage) :

$ find . -type f  -name '*.c' -o -name '*.h' | xargs etags

Enfin un certain nombre d'options peut vous intéresser, pour cela je vous conseille la lecture de man etags. En particulier -d -g -m -t et -T

Niveau :      
Résumé : TP NTP

Avant, il y avait l'heure

Le time protocol est un protocole permettant de se mettre à l'heure en se comparant avec l'heure d'une autre machine. Ce protocole est infiniment simple : on se connecte sur le serveur (port 37), le serveur répond un temps en 32 bits et c'est fini. Ceci marche en tcp et en udp comme indiqué dans la RFC 868.

Bon évidemment la simplicité se paye, la précision d'un tel protocole est très réduite, de plus il ne permet pas réellement la synchronisation entre plusieurs serveurs. De plus 32 bits c'est un peu léger pour représenter une date, on a une précision à la seconde.

Finalement, mauvaise idée, ce protocole ne sert qu'à avoir l'heure.

Avant, il y avait l'horloge

Il existe un autre protocole nommé ICS (internet clock service) décrit ici dans la RFC 778. La méthode reste assez simple. Il s'agit de mesurer les temps d'aller et de retour des paquets dans la communication avec un serveur ics. Grâce aux différences entre les différents temps on peut en déduire le décalage avec le serveur et donc le corriger.

Le service utilise des entiers de 32 bits avec une précision à la milliseconde, donc un décalage maximum de 25 jours.

Après il y eu le réseau

Un nouveau protocole est apparu, nommé NTP (network time protocol), capable de donner la date et l'heure mais aussi le décalage avec l'horloge locale. Il se base sur le même principe qu'ICS, mais en utilisant 2 fois 32 bits (pour former un nombre 64 bits à virgule fixe). On peut donc avoir une précision énorme (1/2^32 s) tout en ayant une échelle de temps suffisante pour avoir la date (136 ans).

De plus, ses évolutions permettent une synchronisation entre des réseaux de serveurs (strates) pour conserver au mieux une heure précise à l'intérieur de ce réseau.

La dernière rfc à ce sujet est pour NTPv3 RFC 1305.

Aujourd'hui le protocole en est à sa version 4 (non rfcisé) et la version 5 est en cours de développement.

À bientôt pour un nouvel article sur la configuration de ntp.

Niveau :      
Résumé : Test::Harness

Régulièrement vous avez des problèmes sur vos machines. C'est normal, ça arrive à tout le monde. La plupart du temps on corrige le problème et c'est fini. Nooooonnnnn ... C'est mal !

Il ne faut pas corriger le problème. Il faut

• S'assurer que le problème n'a pas d'impact
• Faire un script qui vérifie que le problème est présent
• Corriger le problème
• S'assurer que le script renvoie ok
• Compléter le script par des commentaires

En détail :

• 1- Bon si vous n'avez pas le point 1 (ça s'explique très bien par le manque de moyens et plus rarement par le manque de temps) inversez les étapes 2 et 3, on fera avec.

• 2- C'est lourd ce que vous me proposez là ! Oui, mais non, c'est un travail qui se prépare, vous devez déjà avoir un système de vérification disponible, et donc votre script sera très court. Par exemple :

[ -x /usr/bin/perl ] && echo ok

• 3- OK, c'est votre boulot

• 3.5- Itérez sur 2 si ça ne fonctionne toujours pas.

• 4- Simple, ça prouve que vous avez bien écrit votre script et que vous avez corrigé le problème.

• 5- Vu que vous avez corrigé le problème, ajoutez un commentaire sur le pourquoi du comment, voire un check supplémentaire qui détectera la prochaine arrivée du problème.

Ainsi lors du prochain incident, la procédure commencera par

• Lancer le test

• 0- Si ce test est ok on continue, sinon on lit les commentaire et c'est fini

Mieux, vous pouvez lancer les tests régulièrement et ainsi prévenir les problèmes.

Bon, il vous faut un infrastructure de test, faisons simple (autotest.pl) :

Niveau :      
Résumé : crypt ; aespipe ; openssl gpg

Si vous voulez chiffrer un fichier, par exemple un fichier de backup, vous avez plusieurs commandes pour le faire, adaptées à différents besoins.

Chiffrement symétrique

Vous pouvez utiliser le chiffrage symétrique pour des besoins courants, rapide et sûr, cette méthode permet de chiffrer rapidement avec un mot de passe connu de l'émetteur et du récepteur.

Nous avons donc l'ancienne méthode : crypt

# un mot de passe
$ crypt < file1 > file2

Bien, mais ce chiffrage est un peu faible, ça commence à dater. Heureusement, un tout nouveau standard de chiffrage est apparu, AES.

# attention, par contre le mot de passe doit faire 20 caractères minimum
$ aespipe < file1 > file2

Vous trouverez aussi bcrypt qui a un niveau tout à fait acceptable, et qui accepte les mots de passe de 8 caractères. Notez que vous avez aussi openssl en ligne de commande qui vous propose un grand nombre d'algorithmes de chiffrement symétrique, avec un usage relativement simple (man enc), mais bizarrement pas de chiffrement asymétrique.

$ openssl enc -des -e -salt -in file1 -out file2

Chiffrement asymétrique

Maintenant il se peut que vous vouliez chiffrer un fichier pour le communiquer à quelqu'un. Dans ce cas, un chiffrage asymétrique est probablement plus adapté (pas besoin de partager de mot de passe entre les 2 personnes).

Pour ce faire, intéressons nous donc à gpg. Il nous faut une clé pour le destinataire :

$ gpg --gen-key

Clé dont on donne la partie publique à celui qui va chiffrer le fichier :

$ gpg --armor --export chiffre@dest.fr > pubkey

Émetteur qui va enregistrer cette clé :

$ gpg --import pubkey

On va enfin pouvoir chiffrer le fichier secret, côté sympathique, il n'y a aucun mot de passe à spécifier :

$ gpg -o secret.gpg -r chiffre@dest.fr -e secret

Un fichier chiffré secret.gpg est créé et vous pouvez le transmettre. Le récepteur pourra alors le déchiffrer :

$ gpg -o secret -d secret.gpg

Niveau :      
Résumé : xchat ; screen irssi

Allez-vous sur irc de temps en temps ? Non alors je vais vous couper la tête !

Introduction

Irc, Internet Relay Chat est LE moyen de discuter sur internet. Contrairement à la messagerie instantanée, l'irc a pour principe de base de discuter avec des groupes de personnes et non pas avec une personne en particulier. Bien sur, ceux qui veulent discuter seul à seul le peuvent aussi. Je vous passe les bases du protocole, mais il est assez simple. Le principe est de faire passer toute communication par un serveur, lequel redistribue le message vers les clients concernés. Comme il ne peut y avoir un serveur unique, les serveurs sont connectés entre eux et se redistribuent les messages à travers le net (comme pour les newsgroup).

Au départ l'irc était comme le mail, tout le monde pouvait parler à tout le monde, mais l'histoire ainsi que des désaccords sur la façon de gérer ce réseau on fait que l'irc est maintenant divisé en réseaux qui ne communiquent pas entre eux. Ces réseaux portent des noms comme efnet, dalnet, freenode ... on les compte par centaines. Et c'est bien dommage, car il est assez difficile de s'y retrouver.

Sur un réseau irc, on retrouve de nombreux canaux, un canal est un lieu de discussion dont le nom commence généralement par #. On en trouve des dizaines de milliers, chacun avec un sujet différent. C'est dire si vous pouvez y trouver votre bonheur.

Un client simple

Pour vous connecter sur irc, il existe un outil sympathique nommé xchat. Il a l'avantage de connaître la plupart des réseaux et la plupart des serveurs associés. Il vous permettra de vous connecter à plusieurs serveurs et à de nombreux canaux simultanément ?

Son interface graphique est simple et intuitive, et la plupart des actions peuvent être effectuées sans taper une seule commande.

Un client avancé

Mais ce n'est pas pour vous parler de xchat que je fais cet article. Un autre client irc populaire chez les linuxiens est irssi. Ce client fonctionne purement en mode texte. C'est à la fois un avantage et un inconvénient. Inconvénient car les débutants devront apprendre le commandes irc de base. Mais un avantage car il est possible de le lancer à peu près partout avec ou sans interface graphique et qu'on peut le combiner avec screen.

Détaillons donc ce que cela veut dire. Si vous disposez d'une machine connectée en permanence à internet, vous pourrez y lancer irssi pour ne jamais l'arrêter, jamais ... Vous ne perdrez plus une miette des discussions, et on pourra vous écrire même quand vous n'êtes pas là.

Pour le lancer :

$ screen -S irc
$ irssi 

Puis pour vous y reconnecter :

$ screen -d -r irc

Sachant qu'il vous arrivera de vous connecter à distance de temps en temps sur cette machine, créez vous un alias pour vous connecter à irc :

alias irc="ssh serveur.reseau.net 'screen -d -r irc'"

Irssi dispose de thèmes permettant de changer l'apparence des clients. Personnellement je préfère les thèmes alignés comme dot. Irssi dispose aussi de nombreux plugins permettant d'étendre celui-ci directement en perl. J'utilise par exemple hilightwin.pl qui permet d'avoir une fenêtre supplémentaire pour tous les messages qui vous concernent sur les canaux auxquels vous êtes connectés.