Afin que vous puissiez entrevoir l'espace de possibilités qu'ouvre cette technique, cette partie donne quelques exemples additionnels d'applications possibles.
4. 1
... pour tester la cohérence d'un code
Imaginez que vous travaillez dans l'industrie sur un logiciel vieux de 15 ans et écrit en C. Il doit tourner 24h/24, 7j/7 pour superviser la production, dans des usines qui fabriquent des bouteilles en verre. Mais ça c'est juste la théorie : vous avez noté que dans certaines usines le serveur se relance toutes les 3 semaines environ, à cause d'un manque de mémoire.
Il doit y avoir une fuite quelque part.
Il vous faut donc trouver un moyen efficace pour cibler un problème sur une base de code plutôt imposante. Outre les solutions existantes (valg rind par exemple), vous tombez sur un tutoriel concernant LD_PRELOAD, où les fonctions maUoc ( ) et f ree ( ) sont redéfinies pour rechercher une incohérence. Intéressant...
En surchargeant ces mêmes fonctions, on peut également obtenir des statistiques des allocations effectuées par le programme ... Et une fois qu'on a ces statistiques, pourquoi ne pas en tirer parti et implémenter un gestionnaire de mémoire plus efficace pour ce programme ? Ou même, un garbage collector ?
Entre-temps, la fuite mémoire a été découverte dans un ajout de code récent. Mais vous gardez ces réflexions dans un coin de votre tête ...
4.2 ...
pour gérer un effet de bord complètement imprévisible
Un ou deux ans plus tard, vous travaillez sur un projet de grille de calcul (en gros un réseau de centres de calcul) qui recueille (entre autres) les données générées par l'accélérateur
de particules « LHC ». S'agissant d'une grille de calcul mon
diale reposant sur un middleware gourmand en adresses publiques, la problématique du passage il. IPv6 est primor
diale et c'est sur ce thème que vous travaillez. Yous avez donc milité comme il faut pour que tous les composants logiciels deviennent IPv6-compliant. Tout cela avance bien, sans souci majeur, jusqu'au jour où vous recevez un e-mail qui vient du CERN (qui gère le LHC) et qui dit en gros « depuis la migration IPv6 de tel composant, notre load-balancing DNS ne fonctionne plus ; donc on va revenir à la version précédente ». Un tel effet de bord vous paraît assez improbable, surtout que les machines en question n'ont qu'une adresse I Pv4. Mais le CERN étant le contribu
teur le plus important de la grille, un tel retour en arrière pourrait presque compromettre la migration, donc vous tentez aussitôt de diagnostiquer le souci. Et là, vous vous rendez compte qu'effectivement. dans leur environnement réseau bien précis, la fonction getadd rinfo O (introduite - lors de la migration) trie les adresses retournées par le DNS et présente toujours la même en première position ; donc les clients interrogent tous le même serveur. Qu'à cela ne tienne vous avez plusieurs cordes à votre arc. Yous commencez donc à réfléchir à la technique que vous allez employer pour réordonner ces adresses aléatoirement en sortie de cette fonction ...
Sauf si vous êtes chez le dentiste et que vous feuilletez ce magazine de manière vraiment distraite, vous devriez deviner la fin de J'histoire ... [RDMZGAI]
4.3 ...
pour gérer une technologie que le programmeur n'a pas prévue ou ne maîtrisait pas
En fait, ce n'était pas tout à fait la fin de J'histoire.
Alors, où en est-on avec cette migration de middleware ?
Eh bien on a maintenant quasiment 100% du code qui est m igré. Par contre, un tiers des composants n'ont pas J'air
de fonctionner dans un environnement IPv6. Ah bon, com
ment ça ??? Eh bien a priori, certaines des librairies que le middleware utilise ne sont pas compatibles. Et comme on ne gère pas le code de ces librairies externes au projet, il n'est pas toujours possible de savoir si un jour elles seront migrées et si oui, quand.
Résumons la situation : vous aimeriez donc modifier le comportement de certains morceaux de logiciel (pour les rendre compatibles IPv6), sans modifier leur code ... Cela ne vous rappelle pas quelque chose ? (Ça commence par LD et ça finit par PRELOAD ... ).
Yous vous mettez donc au travail. Bien entendu, là il ne 'agit plus d'un simple patch pour un programme isolé : vous voulez rendre compatibles IPv6 tous les processus
Le monde merveil leux de LD_PRELOAD LD PRELOAD
tournant sur une machine. Bon OK. vous vous autorisez quelques exceptions (voir paragraphe sur les limites), mais votre but final est que tous les processus du middleware soient capables de parler IPv6, qu'ils soient codés en shell, en C/C++, en Java, en Python ou en Perl !! (Entre nous, y a-t-il vraiment eu une concertation avant de commencer à coder ce middleware ????)
Yous décidez alors de partir de votre projet existant, IPv6 CARE, qui permet déjà aux développeurs de détecter les appels de fonction réseau effectués par leur programme et d'en déduire un diagnostic de compatibilité IPv6 (<< check » mode, voir [I PV6CARE]). Avec ce nouveau « patch » mode, il ne faudra pas se contenter de détecter ces appels, mais carrément les corriger. Par exemple, si J'on s'aperçoit qu'un serveur effectue un appel à la fonction accept ( ) avec en paramètre un socket IPv4, il est évident qu'il ne sera pas capable de recevoir des clients IPv6. Donc, à la place du accept ( ), on devra dans ce cas créer un socket IPv6, faire un select( ) pour attendre une connexion sur le socket IPv4 ou le socket IPv6 et enfin, réaliser l'accept ( ) sur le socket qui a réveillé le select ( ). Trois adaptations de ce genre plus tard, avec tout ce qu'il faut autour et pas mal de tests. vous avez atteint votre objectif (voir [IC_PATC H]).
4.4 ...
pour adapter un programme complètement borné
àdes contraintes imprévues
Bon, je suis désolé d'être aussi directif au sujet de votre destin fictif, mais maintenant que ça tourne au niveau d 'IPv6, vous allez passer à autre chose, en l'occurrence à du moni
toring réseau, car la grille en a besoin. Yous travaillez donc dorénavant sur un système qui comprend un serveur central et des sondes à installer dans chaque site. Ces sondes sont des systèmes Linux avec différents outils de diagnostic réseau.
Lun de ces outils permet de mesurer la bande passante entre 2 sondes (donc le plus souvent entre 2 sites).
Pour vos tests, vous avez installé 2 sondes virtualisées sur un serveur Xen. Pas de bol, l'utilitaire pour tester la bande
passante refuse de faire le test. En effet, il vérifie que la
synchronisation NTP entre vos sondes fonctionne, or celle-cl
n'est pas opérationnelle. .
Voici l'explication. Dans sa configuration par défaut, le serveur Xen (domO dans le jargon) et les machines virtuelles qui y sont hébergées (iCi les 2 sondes) partagent la même horloge. On peut modifier ce comportement (voir encadré).
mais à J'époque vous ne le saviez pas. On peut se dire que si les sondes ont la même horloge, alors évidemment il e t inutile de les synchroniser. Mais ce programme ne teste pas les horloges, il fait des appels aux démons NTP sur chaque sonde pour savoir si la synchronisation NTP est OK.
N EWS 1 LABO 1 M O B ILITE 1 1 EN C O U V E RT U R E 1 R E P E R E S 1 E X P E R I M E NTATION 1 DOMOTIQUE 1 RÉSEAU 1
Or, dans cet environnement, une machine virtuelle ne peut pas modifier son horloge (vu que celle-ci est la même pour tous ... ), donc le démon NTP reto\lrne une erreur de synchronisation.
Remarque Désynchroniser les horloges sous Xen
Si la configuration par défaut est effectivement de partager la même horloge entre domO et les machines virtuelles hébergées, on peut choisir de les désynchroniser via le sysctl xen . independent_waUclock.
Vous cherchez bien, mais ce programme borné n'a pas l'option « ignorer la synchro NTP », donc il commence rapi
dement à vous donner des boutons avec ses messages répétés affirmant (à tort !) que les sondes ne sont pas synchronisées.
Finalement, vous vous rendez compte que l'interroga
tion du démon NTP des sondes se fait avec une fonction de l 'API NTP, donc il est tout bête de patcher cette fonction pour qu'elle renvoie toujours « synchro OK ». C'est fait en 5 minutes et ça laisse quand même la satisfaction d'avoir plié à vos exigences un programme qui faisait vraiment preuve de mauvaise volonté.
4.5
... pour mettre de la couleur dans votre vie d'informaticien
Suite à ces diverses expériences où LD_PRELOAD vous a bien rendu service, vous décidez d'écrire un article sur ce sujet pour GLMF/Open Silicium.
POur introduire cet article, vous cherchez un premier exemple accrocheur. Vous vous dites qu'il serait intéressant de patcher les programmes pour qu'ils affichent les mes
sages d'erreur en rouge. Dans un script un peu verbeux par exemple, cela peut être très utile. Vous commencez donc à investiguer ce sujet.
En fait, il suffit de patcher la fonction errorO ... Et d'utili
ser des constantes avec des codes d'échappement comme :
#defi ne ROUGE " \e[31m"
#define COULEULDEFAUT " \e[9m"
Il faut quand même prendre soin de désactiver ce chan
gement de couleur si la sortie standard n'est pas un terminal (sinon, si on redirige la sortie de commande vers un fichier par exemple, on y retrouve ces séquences d'échappement...).
La fonction isatty O permet de gérer ce petit souci.
Et s'il y a des lecteurs grincheux qui trouvent que les erreurs ne sont toujours pas suffisamment repérables, on pourra leur répondre qu'il existe une séquence pour écrire en
inverse vidéo, ou même pour faire clignoter le texte ! Bien sûr, en contrepartie, on s'éloigne des standards et on peut donc rencontrer des émulateurs de terminaux qui n'implémentent pas ces fonctionnalités. Il faut les tester au préalable avec des commandes du type :
S echo ·e "\e[31;7mblablabla\e[Om"
Et vérifier que blablabla est bien affiché en inverse vidéo sur fond rouge.
Mouais, c'est pas mal comme exemple. Par contre ... Pour représenter ces messages en couleur, pas facile de respecter les conventions d'écriture des articles GLMF/Open Silicium ...
Bon, dans ce cas, on ne va pas les mettre en couleur, mais juste les rendre plus agréables ...
Conclusion
J'espère que vous avez apprécié cette petite promenade dans le monde merveilleux de LD]RELOAD. A priori, à la lecture de cet article, vous avez acquis suffisamment de points d'expérience pour vous y lancer sans risque, si cela vous dit de jouer le jeu ... _
Remerciements
]e voudrais remercier Bernard Rappachi pour sa relecture de la dernière fois et parce que j'ai apprécié la période où il était mon chef ; Florian Marcos pour nos séances de brainstormingsympas (les bonnes idées apparaissent souvent autour d'une bière) ; et enfin, l'ensemble des personnes qui participent à GNU/Linux Magazine et Open Silicium, parce qu'il en résulte un excellent outil de veille technologique.
[DYNLDR] Il Y a tout sur le dynamic linkerlloader dans sa page de manuel : man ld . so
[IC_USERGUIDE] http://sourceforge .net/projects/lpv6-care/files/User%20Guide/
[TLS] http://fr.wikipedia.org/wiki/Thread_Local_Storage [RDMZGAD https://twikLcern.ch/twiki/bin/view/EGEE/
RandomizeGetAddrlnfo
[IPV6CARE] http://sourceforge.netlprojects/ipv6-care/
[IC_PATCH] https://twiki.cern.ch/twiki/bin/view/EGEE/
IPv6CARE
EXEMPLE :
r---�---_r--_+----�----�
Cl Je souhaite recevoir des inlos des Ëdtions Oiamond
IJ Je souhaite recevoir des inlos des partenaires des Ëditions Oiamond
Retrouvez les sommaires et commandez tous nos magazines sur notre site :
L'EMBARQUÉ DEVIENT ACCESSIBLE À TOUS ! Prise en main et évaluation de la carte Mini2440 de FriendiyARM
ARDUINO - Apprenez à exploiter votre module Arduino et à tirer le meilleur du micro
contrôleur AVR d'Atmel
ARM + FPGA = ROBOTIQUE ! Couplez ARM et FPGA pour contrôler efficacement jusqu'à 32 servomoteurs sur platefonne Armadeusllinux
Voici mes coordonnées postales :
Nom : Prénom : Adresse :
Code Postal : Ville : Téléphone : e-mail :
Je choisis de régler par :
Cl Chèque bancaire ou postal à l'ordre des Éditions Diamond Cl Carte bancaire nO I 1 1 I l 1 1 1 I l 1 1 1 I l 1 1
Expire le : 1 1 1 1
Cryptogramme visuel : LLLJ
Date et signature obligatoire
(>pen
[3Jlicium
l',·
IIIiiiiiiIIILJ
CE S 0 NT ...
-