Archive for February, 2008

Variables d’environnement et services

Monday, February 25th, 2008

Plusieurs services (Apache, Tomcat, etc.) dépendent de variables d’environnement, notamment des variables LC_*/LANG*. Il faut donc prendre garde à la façon dont on (re)lance un service. Par exemple, sous Debian, un apache(2)ctl start ne revient pas au même qu’utiliser un “wrapper” comme /etc/init.d/apache(2). Mais il ne suffit pas d’utiliser systématiquement les scripts init.d : toujours sous Debian, /etc/init.d/tomcat5.5 peut dépendre de variables d’environnement. Concrètement, relancer un service depuis un shell avec un environnement particulier peut donc changer son comportement (dates incorrectes, problème de charset, etc.). D’ailleurs, au passage, sous Debian, il est conseillé d’utiliser systématiquement /etc/init.d/apache2 (et non apache2ctl) pour Apache car celui-ci réinitialise l’environnement, et une astuce pour Tomcat est d’exporter les variables voulues (notamment celles concernant la locale) dans le fichier /etc/default/tomcat5.5.

En règle générale, la relance de services sur un serveur en production s’effectue par sudo et/ou SSH. Pour éviter les erreurs d’inattention, il est donc préférable ne pas conserver les variables LC_*/LANG*. Avec sudo, il est ainsi recommandé d’utiliser env_reset pour des raisons de sécurité, mais env_reset conserve ces variables sans qu’il soit possible a priori de les supprimer avec env_delete (voir bug Debian #392321). Au niveau de SSH, on peut agir plus efficacement, comme éviter que ces variables soient envoyées par le client SSH en retirant la directive SendEnv LANG LC_* dans le fichier /etc/ssh/ssh_config. On peut également le faire au niveau du serveur en évitant la directive AcceptEnv LANG LC_* dans le fichier /etc/ssh/sshd_config. Bien sûr, comme toujours toutes ces “astuces” ne doivent pas être appliquées sans précaution ; le principal est de garder en tête que certains services peuvent dépendre des variables d’environnement et d’éviter de les (re)lancer depuis un environnement modifié.

Pseudo-cartes RAID DELL/Adaptec

Saturday, February 23rd, 2008

Mon histoire avec les cartes Adaptec (Dell OEM) 39320 Ultra320 SCSI adapter commence il y a trois ans quand j’ai eu à installer plusieurs exemplaires de machines DELL PowerEdge SC420 incluant cette carte. Cette carte est sensée permettre du RAID hardware mais c’est loin d’être le cas. Les premiers drivers pour cette carte ont été inclus dans le noyau Linux 2.6.11 (l’installation de Sarge nécessitait donc une technique annexe : debian-installer avec un noyau custom ou debootstrap à partir d’un autre disque) mais ils ignorent tout simplement la configuration RAID effectuée au niveau du BIOS de la carte. Celle-ci gère pourtant le RAID0 et RAID1 mais au démarrage de Linux, les disques sont vus par le noyau comme des disques indépendants… Bref, pas de RAID hardware possible (des blobs pour Suse/RedHat existent mais je préfère éviter cette solution).

Récemment, j’ai du ajouter un nouveau disque sur ce controleur. J’ai donc branché ce 2e disque sur la machine concernée et tenté de démarrer la machine : le controleur ne trouvait pas de périphérique de démarrage valide. En regardant de plus près, il cherchait un volume RAID0, forcément inexistant. Or, je souhaitais simplement avoir deux malheureux disques, sans RAID. Mais même en retirant le disque ajouté, il cherchait toujours un volume RAID0 : le second disque devait contenir un reste de RAID0 et le controleur l’a considéré maître et et a écrasé la configuration du premier disque. Youpi : bien que le RAID de ce controlleur ne fonctionne pas sous Linux… me voilà coincé à cause du RAID. Premier réflexe : désactiver les fonctionnalités RAID de la carte, et la documentation d’Adaptec m’indique que c’est simple, il suffit de l’indiquer dans le BIOS de la carte. Sauf que j’ai une carte DELL/Adaptec, c’est-à-dire que DELL a placé un firmware modifié pour faire croire à une carte DELL et, au passage, a eu la chouette idée de supprimer la possibilité de désactiver le RAID. Arrivé ici, on pourrait penser qu’il suffit de mettre un firmware Adaptec mais c’est justement indiqué que l’on ne doit le faire qu’avec les cartes 100% Adaptec et non issues d’un autre fournisseur. Et de toute façon, cela risquerait de me faire perdre la garantie DELL, ultime recours en cas de soucis :-)

Je vais donc devoir me débrouiller avec ce firmware. Ma première mission est de ré-initialiser le RAID du premier disque car, avec controleur on ne peut pas effacer la configuration RAID, il faut… ré-initialiser complètement le disque (ce qui l’efface au passage). À noter que cette ré-initialisation peut être délicate, j’ai déjà explosé un disque SCSI en annulant cette opération ! À noter aussi que cela prend plusieurs heures et si l’on ajoute les temps de backup (dd powered), ça fait beaucoup de temps pour effacer quelques octets dans le firmware du disque dur… Ces opérations de réparation prennent donc des heures et des heures et un message de confirmation aurait ainsi été bienvenu avant que le controleur écrase ses fameux paramètres RAID stockés sur un disque.

En conclusion, lorsque l’on manipule les disques de volumes RAID, outre la possibilité de perdre les données, il faut bien avoir en tête le temps considérable que peuvent prendre certaines opérations, d’autant plus quand il s’agit de controleurs de qualité médiocre (qui impliquent souvent des fonctionnalités réduites).

Please don’t manage permissions of libnss-ldap.conf file with debconf

Friday, February 15th, 2008

During a random security upgrade on Debian :

# ls -l libnss-ldap.conf
-rw-r--r-- 1 root root 9863 2008-02-15 18:40 libnss-ldap.conf
# dpkg -l nscd | grep un
un  nscd           <none>         (no description available)
# aptitude upgrade
[...]
Preparing to replace libnss-ldap 251-7.5 (using .../libnss-ldap_251-7.5etch1_i386.deb) ...
Unpacking replacement libnss-ldap ...
Setting up libnss-ldap (251-7.5etch1) ...
# ls -l libnss-ldap.conf
-rw------- 1 root root 9863 2008-02-15 20:55 libnss-ldap.conf

Oops! With this permissions on the libnss-ldap.conf file, some services will be broken. For example, in Postfix/LDAP configuration, Postfix local mail delivery will fail because he can’t find homeDirectory of local user. And Postfix error message isn’t very explicit:

postfix/qmgr[12063]: warning: transport local failure --
see a previous warning/fatal/panic logfile record for the problem description

For more details, see my post on #455907