Allez cette fois-ci je ne pars pas dans un délire mais je vais vous donner de la matière. En travaillant sur le client windows pour nufw, j’ai trouvé une page sur le site de la respectable société HSC. Ils décrivent de manière précise certains des problèmes relatif à netstat. Cela va s’en dire qu’il s’agit des problèmes rencontrés avant d’avoir viré la dame pipi. L’article est très technique et très sérieux donc prévoyez un peu de temps avant de le lire (quelques mois si vous n’êtes pas informaticien, le temps d’apprendre les bases 😉 .
Je profite de cette brève pour tirer mon chapeau à l’auteur, Jean-Baptiste Marchand. j’aurais sans doute eu du mal à rester aussi calme et impartial en rédigeant un tel texte.
Des paquets poupées russes ?
La seule différence entre des paquets IP et des poupées russes, c’est qu’il faut être un geek pour connaître et apprécier l’encapsulation IP qui est souvent transparente pour l’utilisateur.
J’ai récemment réalisé une configuration me permettant de relever mes mails depuis une connexion WiFi anonyme. Le cahier des charges est simple, je ne veux pas toucher à la configuration de mon logiciel de mail, et je ne veux pas ouvrir de port sur mon firewall depuis le VPN. Plusieurs étapes sont donc nécessaires pour parvenir à mes fins. La succession des encapsulations et transformations réseaux est alors la suivante :
- REDIRECT netfilter pour rediriger les paquets du client mail vers un port local
- Forward ssh des ports redirigés sur localhost vers les ports des machines concernées
- lien openvpn supportant la connexion ssh (en udp port 53 pour faire simple)
Si on rajoute à cela l’encapsulation des paquets du lien ADSL qui est sans doute du L2TP donc de l’IP encapsulée dans UDP, on atteint un certain niveau d’encapsulation, et encore la description ne quitte pas la couche protocolaire 😉
De la surveillance et du paradoxe de la poule et de l’oeuf
Le logiciel MOM est un outil de monitoring. Ce logiciel renouvèle agréablement le paradoxe de l’oeuf est de la poule : Pour monitorer un serveur on a besoin de pouvoir le joindre, donc de connaitre son adresse. Or, pour connaître son adresse, MOM impose l’utilisation de la résolution de nom par l’Active Directory. Donc si on veut monitorer l’Active Directory, on a besoin de l’Active Directory. Côt côt ! Euh pardon Gruik !!! Gruik !!!
Microsoft et la gratuité
J’ai récemment évoqué le Windows 2003 SP1 DDK qui permait de compiler les pilotes de périphériques sous Windows. Ce logiciel d’une taille de 220Mo est disponible gratuitement depuis un des sites de Microsoft, mais il n’est pas téléchargeable (Je sens que certains commencent à voir la suite).
Pensant avoir à faire à un envoi de CD du même type que celui qui avait eu lieu pour windows XP SP2, j’ai rempli les formulaires jusqu’à découvrir que l’envoi du CD était facturé 25$ (voir la Saisie d’écran).
À croire que l’image que nos amis de Redmond ont de la gratuité est aussi fausse que celle qu’ils ont du Logiciel Libre.
Des pilotes en Java par défaut ?
Je vous entends tous dire :
“Et la marmotte, …”
Mais si je suis sérieux , c’est une des nouveautés du Windows DDK 2003 SP1 !
J’en tiens pour preuve ce qu’il se passe lorsque j’ai lancé build dans le répertoire des drivers d’un projet respectable trouvé sur internet (Celui-ci se contente de manière bien politiquement correcte d’inclure le Makefile du DDK et de lui faire confiance.)
Dès que la compilation se lance, la console est noyée sous les messages d’erreurs :
jvc command not found
Ne sachant pas ce que c’est jvc (jvc télécommande not found, j’aurais compris mais là non), je googlize et apprends qu’il s’agit du compilateur Java de Microsoft.
Après un moment de stupeur, je tente de trouver un moyen de lui indiquer un autre compilateur. J’ouvre le Makefile avec vim, je modifie quelque chose et je relance la compilation. Rien à faire, même état. En désespoir de cause, j’ouvre un fichier avec EDIT et je quitte. Je relance la compilation et, Ô miracle, il trouve le bon compilateur.
Bon, j’arrête ce post là , pas la peine de trouver une chute, on ne peut pas tomber lorsque l’on est au fond du trou.
Des paramètres constants et autres fioritures
L’API système Windows est vraiment fascinante à plusieurs égards.
D’un côté, elle tient de Perl, il y a toujours plus d’un moyen de faire la même chose. Le problème vient ici qu’il ne s’agit pas de trouver des solutions algorithmiques différentes à un même problème mais qu’il y a de multiples systèmes parallèles pour effectuer une même tâche. Il s’ensuit une complexité inutile amplifié par la puissance de l’outil de recherche disponible sur MSDN.
D’un autre côté, elle tient du grand-guignol le plus trépidant. De nombreuses fonctions ont un nombre invraisemblable de paramètres. Bon, cela reste admissible, mais lorsque l’on sait que certains des “paramètres” doivent être à des valeurs fixées, alors là on sort du rationnel pour entrer dans le n’importe quoi le plus total. Bon prince, je leur file un tuyau : #define et vous je vous donne un exemple.
L’histoire de netstat et de la dame pipi
Comme vous le savez peut-être je suis l’un des developpeurs de NuFW. Ce magnifique parefeu authentifiant a besoin d’un client sur chaque poste de travail. Grosso modo c’est un netstat qui récupère la liste des paquets SYN (Pour ceux qui n’ont pas suivi, c’est un peu comme une dame pipi qui lève les yeux à chaque fois que quelqu’un entre). Bon bref, c’est au système d’exploitation ce que la balayette est aux toilettes : “on peut faire sans, mais ça finit vite par être vraiment sale.”.
Donc c’est le genre de trucs qui existent sur toutes les machines qui font du réseau (même Windows 95 à cette fonctionnalité si vous me passez la métaphore).
En charge de la partie client Windows pour NuFW, j’ai donc développé au prix d’efforts surhumains un client logiciel fonctionnel. Enfin, je me vante là mais j’en arrive à la chute. Courant mai 2005, un trou de sécurité a été trouvé dans la couche réseau des OS de Microsoft. Jusque là , rien que de très habituel (ça arrive parfois même à des OS sérieux). Un patch est bien sûr venu corriger le problème et tout allait pour le mieux dans le meilleur des mondes.
Quelques temps après, je commencais une nouvelle campagne de développement sous Windows (Tiens j’aurais du appeler le blog “La guerre des Gaules”). Je testais donc à nouveau mon joli logiciel. Rien à faire, il ne parvenait pas à remplir sa tâche. Je pestait et désespérait jusqu’à ce que je retire un patch de sécurité du Windows 2000 sur lequel je faisais mes tests. Et là j’ai compris, Bill avait viré la dame pipi ! D’ailleurs, ses compères avaient aussi piqué la balayette si l’on en croit l’ensemble des problèmes remontés suite à ce patch de sécurité (connexion impossible, bande passante divisée par 4).
Grand seigneur, Microsoft annonça un patch du patch qui s’avéra ne pas réanimer la dame pipi. L’ensemble de ces patchs fût condensé dans le patch cumulatif 1 pour Windows 2000. Cependant, cela reste toujours aussi disfonctionnel au niveau du netstat. Mais bon, netstat, comme on le sait ne sert qu’à savoir ce qui se passe, et lorsque que l’on utilise un logiciel propriétaire, il ne faut pas s’étonner de ne pas savoir ce qui se passe.
De l’avantage des fichiers plats
Nagios stocke bien entendu ses fichiers de configuration et son fichier de status dans des fichiers plats. Il est donc possible de les parser pour en extraire les informations. C’est ce que fait le projet Naupy qui fournit une classe PHP permetttant d’extraire les informations maintenues par Nagios.
Un blog de plus !
Bon, qu’est ce que c’est que ce blog de plus ?
C’est simple, c’est un site de plus qui nait pour pouvoir pousser des coups de gueule. Linuxien confirmé et passionné je suis professionnellement de plus en plus confronté à l’OS de Redmond et ça m’énerve au plus haut point. Passant du stade de “c’est de la merde mais je ne connais pas” à “Mais qu’est ce qu’ils nous ont encore fait!”, j’ai pas mal de choses à dire.
Bon bien sûr, je suis tout de même un être humain et je vais donc blogger aussi normalement.