lalahop

De Debian GNU/Linux Squeeze à Wheezy

Le Debian nouveau est arrivé. Malgré que j'ai attendu 2 semaines pour que d'autres essuient les plâtres, j'ai rencontré des problèmes lors de la mise à jour et je vais vous raconter tout ça.

Table des matières

Pour la procédure de mise à jour en elle-même, c'est du classique : apt-get update && apt-get dist-upgrade, changer le sources.list, apt-get update && apt-get upgrade puis dist-upgrade. apt-get install -f pour terminer l'installation après correction d'un truc qu'à foiré. Pour la version longue, voir, par exemple : De Squeeze à Wheezy… sur le blog de NicoLargo.

Backports

Attention, les backports ne sont plus sur une grappe de serveurs séparée des dépôts principaux. Voir l'annonce officielle.

Dovecot

On passe de la branche 1.x à la branche 2.x (sauf ceux qui utilisaient les backports). Le format du(des) fichier(s) de configuration a changé donc vous allez avoir des erreurs du genre :

doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:1 ...

Ce n'est pas bloquant mais pour éviter de futurs problèmes, il suffit de suivre la procédure : Upgrading Dovecot v1.2 to v2.0. Faites quand même une copie du fichier de configuration actuel, au cas-où.

php5-suhosin

Si vous utilisez suhosin, vous allez avoir cette erreur durant le redémarrage d'Apache pendant la mise à jour :

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525/suhosin.so' - /usr/lib/php5/20100525/suhosin.so: cannot open shared object file: No such file or directory in Unknown on line 0

La raison est que suhosin n'est plus disponible dans les dépôts Debian. J'avoue ne pas avoir creusé le sujet concernant la raison (manque de support/réactivité ? plus de mainteneurs Debian ? fonctionnalités de suhosin intégrées nativement dans PHP 5.4 ? Autre ?).

Il suffit donc de désinstaller php5-suhosin :

apt-get remove --purge php5-suhosin

sudo

NicoLargo prévient d'un problème avec sudo. En prévision, j'ai gardé une copie du fichier /etc/sudoers puis j'ai procédé à la mise à jour. Durant celle-ci, on m'a proposé de garder ma version de ce fichier ou de la remplacer. J'ai accepté le remplacement. J'ai ensuite remis mes 2 lignes personnelles (issues de l'ancienne version) dans la nouvelle version du fichier. Je ne déplore aucun dysfonctionnement.

rsyslog

Si vous n'avez pas accepté le remplacement du fichier /etc/logrotate.d/rsyslog (je l'ai refusé car j'avais effectué des modifs), vous aurez le message suivant :

Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
invoke-rc.d: initscript rsyslog, action "reload" failed.
error: error running non-shared postrotate script for /var/log/syslog of '/var/log/syslog

La raison est que rsyslog n'a plus de commande « restart » mais « rotate ». Il suffit donc de corriger ça dans la directive « postrotate » de /etc/logrotate.d/rsyslog :

invoke-rc.d rsyslog rotate > /dev/null

Apache (dans un chroot uniquement)

Si vous avez créé un chroot pour votre Apache, vous aurez cette erreur :

Cannot load /lib/libnss_dns.so.2. into server: /lib/libnss_dns.so.: cannot open shared object file: No such file or directory

Cette lib a tout simplement été déplacée vers /lib/x86_64-linux-gnu/libnss_dns.so. Il suffit donc de corriger le fichier de configuration de votre Apache pour en tenir compte.

Mysql (dans un chroot uniquement)

Si vous avez créé un chroot pour votre MySQL, vous aurez cette erreur :

[ERROR] Error message file '/usr/share/mysql/english/errmsg.sys' had only 641 error messages, but it should contain at least 728 error messages.
Check that the above file is the right version for this program!

Il suffit de procéder à une mise à jour d'un fichier du chroot :

cp /usr/share/mysql/english/errmsg.sys /chemin/vers/le/chroot/usr/share/mysql/english/errmsg.sys

Sympa (plus précisément : wwwsympa, l'interface web)

Après la mise à jour, on a une erreur 500 et le log Apache qui dit :

(104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
Premature end of script headers: wwsympa-wrapper.fcgi

et le log sympa indique :

err [robot ] Config error: wwsympa should run with UID 112 (instead of 33). *** Switching to maintenance mode. ***

J'utilise le wrapper donc je vérifie les permissions de /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi : sympa:sympa/755 ... De tête, là comme ça, je ne vois rien de nouveau. Ha si, il manque le setuid bit. Corrigeons :

chmod u+s /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi

Je redémarre sympa, je kill le processus wwwsympa et je reteste : l'erreur 500 est toujours là, l'erreur dans le log Apache aussi. Par contre, l'erreur a disparu du log de sympa.

Je vérifie les permissions dans /usr/lib/cgi-bin/sympa/ et /etc/sympa/. Dans le premier, tout est en sympa:sympa/755. Dans le second, tout est en sympa:sympa/644. Je ne vois rien à redire.

Quelques recherches sur le web plus tard, j'ai trouvé la solution : sympa: mod_fcgid fails with "Premature end of script headers: wwsympa-wrapper.fcgi".

ÉDIT du 16/06/2013 à 15h30 :
Si un /usr/sbin/apache2ctl graceful tue votre apache (« [apache2] <defunct> ») et que vous avez l'erreur suivante dans le log d'erreur apache (error.log par défaut) :

[error] FastCGI process 13780 still did not exit, terminating forcefully

Alors, il faut activer suexec :

a2enmod suexec && service apache restart

Fin de l'édit

ÉDIT du 25/06/2013 à 02h30 :
Si Sympa envoi le mail suivant au listmaster de manière intempestive :

file error - help_suspend.tt2: not found

C'est qu'un bot (lié à un moteur de recherche comme Google ou non) ou un humain a cliqué sur Aide -> une documentation destinée aux utilisateurs des listes de diffusion ; -> suspendre ou reprendre votre abonnement pour chaque liste; et que cette page (/wws/help/suspend) cause une erreur :

Sympa n'a pas pu renvoyer la page demandée pour la raison suivante :
file error - help_suspend.tt2: not found
Veuillez contacter le listmaster

Un tour sur un moteur de recherche permet de constater que mon installation de Sympa n'est pas la seule à rencontrer ce problème.

Comme j'ai installé Sympa avec apt-get, il est donc passé de la version 6.0.1 à 6.1.11. En récupérant Sympa sur le site officiel, on remarque que la version 6.1.11 ne dispose pas du fichier /web_tt2/help_suspend.tt2 :

tar tf sympa-6.1.11.tar.gz  | grep help_suspend

En revanche, on remarque que la version 6.1.12 dispose d'un tel fichier. Je l'ai donc récupéré de la version 6.1.12 pour le mettre dans le dossier /usr/share/sympa/default/web_tt2/ de ma version 6.1.11 by Debian. Cela fonctionne. Plus de messages d'erreur et l'utilisateur désireux d'avoir l'information peut l'obtenir.

Néanmoins, cette page reste en anglais comparé à toutes les autres pages de wwsympa. Je n'ai pas encore compris comment interagissent les fichiers de langues (fichiers po/gmo dans le source officiel) avec la version Debian ...Fin de l'édit

OpenDNSSEC

Je ne m'attendais pas à avoir de problèmes avec ce logiciel qui passe de la version 1.3.2-1 à 1.3.9-5 (numéro de version mineur tout ça tout ça) et pourtant, ils ont changé le schéma de la base de données sqlite utilisée comme le dit le message durant la mise à jour :

ERROR: database version number incompatible with software; require 2, found 1. Please run the migration scripts

Je n'ai trouvé que très peu d'infos, même le changelog, /usr/share/doc/opendnssec/changelog.gz, n'indique pas un changement de la base de données.

Apparemment, le script de migration est : /usr/share/opendnssec/migrate_keyshare_sqlite3.pl. Évidemment, ce script n'a pas fonctionné chez moi sinon c'est trop facile.

J'ai remarqué que la commande « ods-ksmutil key list » ne m'affiche plus les clés/les zones et qu'un message apparaît dans le log opendnssec :

Key (xxx) has gone straight to active use without a prepublished phase

Le problème est sérieux et je n'ai trouvé aucune solution viable : toutes mes tentatives, forcer la signature des zones, nettoyer les états, ..., ont échouées.

Partant du principe que tout était perdu (OpenDNSSEC n'a plus l'état des zones, les clés associées, rien ...), j'ai décidé de faire une sauvegarde des fichiers de configuration actuels, de réinstaller complètement OpenDNSSEC et de refaire la configuration à partir des fichiers sauvegardés. Solution radicale (mes zones sont temporairement invalides) mais efficace.

ÉDIT du 24/05/2013 à 19h30 :

LXC et le réseau

Suite à la mise à jour, il m'étais parfois impossible de me connecter en SSH avec l'un de mes conteneurs LXC. Une connexion SSH vers l'hôte fonctionnait parfaitement et le conteneur était démarré. J'allais commencer à chercher une solution à ce problème quand j'ai reçu un mail du robot de sécurité d'OVH qui me disait que, depuis quelques temps, ma machine émettait de la merde en ARP. Il s'avére que ce « quelques temps » était en fait depuis le moment où j'ai redémarré mon serveur (nouveau noyau tout ça tout ça) après la mise à jour. Étrange coïncidence, non ?

Je regarde les IPs mentionnées dans les requêtes ARP ... Tiens, le premier octet est toujours le même que l'IP du conteneur LXC : 87. ... À qui sont allouées ces IPs ? Des whois plus tard, je trouve de tout : OVH, Bouygues et d'autres ... Bizarre ... Mon conteneur se croirait-il sur un réseau /8 alors que son IP est explicitement configurée comme étant un /32 (config IP FailOver chez OVH) ? Vérification avec ifconfig : oui. Et c'est ainsi pour tous mes conteneurs LXC. Pourtant, les fichiers /etc/network/interfaces sont corrects et n'ont pas changé d'un octet ...

En fait, dans le fichier de config de chacun de mes conteneurs, j'avais une ligne comme ça :

lxc.network.ipv4 = 87.98.183.12

Elle n'a jamais posé problème avant, le fichier /etc/network/interfaces devait prendre le relai lors du démarrage du conteneur, je ne sais pas ... LXC doit désormais intervenir plus tard dans le processus de boot et doit croire qu'il s'agit d'une IP du réseau 87/8. Préciser un /32 dans ce fichier ne change rien car les up/down script prévus dans /etc/network/interfaces ne seront pas exécutés donc la gateway ne sera pas précisée donc vous perdrez l'accès à votre conteneur depuis l'extérieur.

La solution est bêtement de commenter la ligne ci-dessus. On ne touche pas aux autres lignes concernant le réseau (type, flags, link, ...), hein ! Un redémarrage des LXC plus tard, le problème est résolu.
Fin de l'édit

ÉDIT du 03/08/2013 à 20h00 :

postfix-policyd-spf-python

Depuis mon passage à Wheezy, j'avais remarqué, en lisant les logs, que la réception d'un mail par postfix prenait plus de temps. En fait, le MTA distant semble être mis en attente 1 minute. Tout le temps. Exemple :

Jun 30 01:28:14 localhost postfix/smtpd[29532]: connect from [...]
Jun 30 01:29:14 localhost postfix/smtpd[29532]: ADC3A271CA: client= [...]

Et c'est comme ça pour toutes les connexions entrantes. Ça ressemble fortement à l'expiration d'un timer. En mai/juin, je n'ai rien trouvé, ni dans le changelog de Postfix, ni en faisant quelques recherches, qui pourrait expliquer cette mise en attente.

Puis, j'ai quand même voulu résoudre ce problème. Le problème ne se produit pas sur une installation toute fraîche dans une VM. L'installation est minimaliste : juste Postfix, aucun milter, aucune policy, rien.

En désactivant tous les milter et policy, le problème disparaît. Après quelques recherches complémentaires, je trouve que c'est postfix-policyd-spf-python qui foire.

Le log de postifx-policyd-spf-python n'indique rien, si ce n'est Temperror pour tous les mails entrants depuis la mise à jour vers Wheezy. Exemple :

Jun 30 01:28:44 localhost policyd-spf[29538]: Temperror; identity=helo; client-ip= [...]
Jun 30 01:29:14 localhost policyd-spf[29538]: Temperror; identity=mailfrom; client-ip= [...]

Je ne sais pas d'où vient le problème avec précision : peut-être un problème dans les bibliothèques sous-jacentes comme pydns. J'utilise Python 2.7 donc ce bug ne semble pas me concerner.

Je me suis contenté de passer à la version codée en Perl : postfix-policyd-spf-perl. Ça juste marche ...
Fin de l'édit

Les commentaires sont fermés