Parti pour tester les possibilités de monitoring du package OMSA sur des Dell Poweredge R410 flambants neufs, je me suis cassé le nez sur la carte réseau. Celle ci est une Broadcom tout ce qu’il y a de plus classique simplement les drivers du chipset BCM 5716 sont absents du noyau 2.6.26 compilé pour lenny. S’en est suivi une journée de bataille pour tenter de se créer un CD netinst.iso customizé avec le noyau 2.6.30 des backports. Autant le dire tout de suite, j’ai perdu la bataille !
Pour moi la manipulation a consisté à récupérer le noyau 2.6.30 des backports ainsi que le firmware qui va avec (comme dirait Sefyu) sur une clé USB. Armé de tout ca, on peut démarrer une install standard via le netinst.iso classique. Une fois le système installé, reboot. Il est aussi conseillé de récupérer les packages virtuels associés dans les backports (linux-image-2.6-686-bigmem et firmware-bnx2) pour suivre les mises à jour.
Pour la suite, on va monter la clé et installer les deux packages backportés :
mount -t vfat /dev/sdb1 /mnt/usb
cp /mnt/usb/*.deb /root
cd /root
dpkg -i linux-image-2.6.30-bpo.1-686-bigmem[...].deb
dpkg -i firmware-bnx2_0.17~bpo50+1_all.deb
dpkg -i llinux-image-2.6-686-bigmem_[...].deb
dpkg -i firmware-bnx2.deb
Ensuite, comme on a utilisé les backports, il faut les ajouter dans notre /etc/apt/sources.list :
deb http://www.backports.org/debian lenny-backports main contrib non-free
Ensuite, il faut mettre à jour le cache apt et récupérer le keyring des backports :
apt-get update
apt-get install debian-backports-keyring
Enfin pour gérer les mises à jour, il faut que nos 2 packages backportés pointent sur les dépôts backports. Pour se faire, il faut créer ou modifier le fichier /etc/apt/preferences :
Package: linux-image-2.6-686-bigmem_[...].deb
Pin: release a=lenny-backports
Pin-Priority: 999
Package: firmware-bnx2
Pin: release a=lenny-backports
Pin-Priority: 999
Et hop, maintenant la mise à jour devrait se faire trankilou. Il est important de noter que l’emploi des logiciels backportés a des implications au niveau sécurité. Les mises à jour sont au bon vouloir du mainteneur. Les problèmes ouverts pour lenny sont consultables ici.
Pour éviter de NATer à tort et à travers nos (chers) utilisateurs, nous avons décidé de mettre en place un proxy FTP. Nous pensions pouvoir trouver une multitude d’outils pour rendre ce service. Hé bien non, il n’y en a que deux :
- ftp-proxy qui est un peu plus récent (2005) et qui lui ne semble pas avoir de problèmes connus.
Notre choix s’est porté sur ftp-proxy. Ce produit fait partie de la proxy-suite développée par SuSE (mais elle avale pas). L’installation sur une Debian Lenny est d’une simplicité biblique.
Tout d’abord, installons le package :
apt-get install ftp-proxy
Ensuite, il faut autoriser le démarrage du service en mode daemon dans /etc/default/ftp-proxy :
Enfin, il faut modifier le fichier /etc/proxy-suite/ftp-proxy.conf. J’ai mis l’intégralité de mon fichier purgé des commentaires :
[-Global-]
AllowMagicUser yes
AllowTransProxy no
DestinationAddress localhost
DestinationTransferMode client
Group nogroup
LogDestination /var/log/ftp-proxy/ftp-proxy.log
LogLevel INF
Port 2121
User nobody
Une petite explication des paramètres. AllowMagicUser permet de “mettre de la magie” dans le nom de l’utilisateur. En gros ça permet d’interpréter une chaine type utilisateur@serveur:port ce qui est assez courant pour les clients FTP en ligne de commande. AllowTransProxy permet d’autoriser ou non le proxy transparent. J’ai choisi de le désactiver. DestinationAddress est utile quand on veut utiliser ftp-proxy en reverse devant un de nos serveurs FTP (pour interdire des commande ou bloquer du trafic non FTP). Dans ce cas on doit aussi activer le mode transparent. DestinationTransferMode permet de forcer le mode de fonctionnement en actif ou en passif. Ici je laisse le choix au client. Group et User fixent l’identité sous laquelle le service s’exécute. LogDestination et LogLevel l’emplacement et le niveau de détails des événements remontés. Enfin Port donne le port utilisé par ftp-proxy. Il n’y a plus qu’a le lancer :
/etc/init.d/ftp-proxy start
Et voila !
Aujourd’hui j’ai participé à une install party organisé par LUG orléannais Cenabumix. Cette manifestation s’est passée dans les locaux de l’IUT Informatique d’Orléans. Au programme : installation et dépannage de GNU\Linux et deux conférences sur les thèmes de la messagerie Jabber et des logiciels libres. Ambiance très sympa et atmosphère studieuse. Ce qui m’a frappé c’est d’abord le monde. Plus d’une centaines de personnes sont passées et les conférences ont fait le plein. L’audience était fortement hétérogène avec quand même une forte population d’age mure qui n’ont pas peur de se lancer dans le monde du libre. Un de nos sémillant ancêtre m’a même dit “Moi je garde une partoche windows pour mes petits enfants quand ils viennent jouer, sinon je n’aurais que Ubuntu !”. En discutant avec eux, il semble que les principales raison qui leur on fait opter pour un système Linux sont :
- Le foutage de gueule de Microsoft avec Vista et Seven. En effet, un geste élégant aurait été d’offrir Seven : “ce qu’aurait du être Vista” selon l’adage. Mais non la tu passes deux fois à la caisse.
- Le prix des systèmes propriétaires non négligeable.
- La complexité des nouveaux systèmes. Ce qui plait avec Ubuntu et Mandriva c’est le système de gestion de paquets. En 1 clic, nos pappys récupèrent Opera, Thunderbird, Audacity etc. Et ça, ça n’existe ni sous Windows, ni sous OSX (fink et Darwin porcs = LOL).
- Les systèmes Linux sont plus virus-free que Windows c’est indéniable.
Bref, nos ancêtres sont des as du clic, rebelles dans l’âme qui recherchent avant tout la simplicité. Une position dont devraient s’inspirer nombre de décideurs qui persistent sur les chemins du logiciel fermé avec une surface d’attaque aussi importante que le montant de la maintenance annuelle.