Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for 2007

Niveau :      
Résumé : xrestop && xwininfo && xev && x2x && import

Si vous avez lancé une application graphique chez vous et que, comme moi, vous êtes parti au boulot sans cliquer sur sauvegarder, c'est rageant de ne pas pouvoir le faire à distance. Eh bien je vais vous proposer une solution à l'aveugle qui marche.

On commence par se connecter sur la machine portant l'affichage distant et on fait en sorte de se connecter au serveur X. En cas de problèmes de droits, lire l'article sur xauth :

$ ssh mamachine.net.net
$ export DISPLAY=:0

Maintenant il nous faut le pid du processus concerné, rien de plus simple :

$ pgrep -l firefox
> 4908 firefox-bin
$ PID=4908

Ensuite on cherche les fenêtres appartenant à ce processus et en particulier leur titre :

$ xrestop -b -m 1 | grep -A 15 "PID: $PID"
> 0 - Linux attitude - Iceweasel ( PID: 4908 ):
>  [... blah ...]

$ TITLE="Linux attitude - Iceweasel" 

De ce titre on peut déduire l'ID de la fenêtre :

$ xwininfo -name "$TITLE" 
> xwininfo: Window id: 0x2400276 "Linux attitude - Iceweasel"
>  [... blah ...]
$ ID=0x2400276

Ça y est nous avons notre info, nous allons pouvoir commencer à travailler. Rappelez-vous, nous sommes aveugles, il nous faut obtenir le toucher, nous allons donc percevoir ce qui ce passe sur cette fenêtre :

$ xev -id $ID

continue reading...

Bonjour,

L'article de vendredi a sauté, pas de bol, à la place j'ai fait quelques petits changements sur le site. ces changements sont minimes pour la plupart.

Le site permet maintenant les recherches avec opensearch, regarder sur firefox dans la barre de recherche la liste des moteurs. Lorsque vous êtes sur le site il vous propose d'ajouter la recherche sur le site directement depuis votre navigateur. Si cela vous est utile, ça prouve que ce site commence à être fourni en contenu.

Une liste des commentaires récents apparaît dans la barre de gauche, remarquez que si vous les survolez avec la souris, la date et le début du contenu apparaissent.

Une entrée article aléatoire est aussi dans la barre de gauche.

De nouveaux liens de navigation sont disponibles en bas de la page remarquez, 28 pages ! Youhou !

Une section archive est maintenant disponible directement dans la barre de droite.

Pour vous simplifier les réactions, une barre d'outil est disponible lors de l'édition des commentaires, pour vous aider avec la syntaxe dotclear. Notez aussi qu'il n'est plus indispensable de donner son adresse email pour donner son avis (ouf, de toute façon vous savez bien y mettre ce que vous voulez).

Et enfin (je vous passe les détails internes au site), je suis en train d'essayer de faire fonctionner la coloration syntaxique du code, mais il ne s'intègre pas trop dans le style actuel pour l'instant.

Mais tout cela peut rendre le site plus lourd et plus fouillis, si vous remarquez quelque chose ou que cela vous gêne, n'hésitez pas.

---
Peck

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 :


continue reading...

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_*

continue reading...

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.

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) :


continue reading...