Upgrade Debian Squeeze => Wheezy : retour d’expérience

Cet article a été publié il y a 10 ans 10 mois 23 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Salut,
Un bail que je ne blogge plus grand chose, j’ai trop d’autres occupations.
M’enfin là, il fallait bien mettre à jour la release stable de Debian… Comme elle est sortie il y a quelques temps déjà, ça s’annonçait pas trop risqué avec Google sous la main pour résoudre les problèmes déjà connus par d’autres. Je ne regrette pas cette décision car ça c’est exactement passé comme ça… donc je reprends ici ceux que j’ai rencontré, ça peut resservir.

Je vous livre donc ici les différents problèmes sur un tas de serveurs (donc un tas de configuration et de services différents)
C’est parti :

Côté APT

Le backport est intégré au mainstream (je sais pas si c’est le terme) normal, donc il faut adapter. On passe de quelque chose comme :

deb ftp://ftp.fr.debian.org/debian/ squeeze main contrib  non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb ftp://ftp.fr.debian.org/debian/ squeeze-updates main contrib  non-free
deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

à :

deb ftp://ftp.fr.debian.org/debian/ wheezy main contrib  non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb ftp://ftp.fr.debian.org/debian/ wheezy-updates main contrib  non-free
deb ftp://ftp.fr.debian.org/debian/ wheezy-backports main contrib non-free

Attention à bien regarder vos fichiers /etc/apt/preferences et /etc/apt/apt.conf.d/* où vous pouvez avoir fixé des versions de paquets ou fixé la release à Apt::Default-Release "squeeze"; au lieu de Apt::Default-Release "stable";.
Ensuite, un aptitude update && aptitude dist-upgrade et c’est parti.
Lorsque vous aurez les éternelles questions où il faut choisir entre le fichier de conf du mainteneur et le votre, ne pas oublier de bien lire les différences de fichiers. Si vous n’avez rien touché, vous prenez celle du mainteneur, sinon vous réfléchissez. L’idée est de bénéficier des nouveautés sans pour autant perdre vos paramétrages. Quitte à accepter le fichier du mainteneur puis aller voir le fichier « machin.conf.dpkg-dist » pour y retrouver vos anciennes modifs et adapter.

Enfin, si aptitude mouline pendant des heures sur l’analyse des dépendances, lisez ces messages. Cela se résout avec aptitude en mode interface.

/bin/sh et /etc/crontab

Attention, j’ai le sentiment qu’on vient de passer de /bin/sh => bash à /bin/sh => dash (avec un ‘d’).
Donc dans la crontab, pour un script bash mal écrit (pas d’entête #!/bin/bash), le lancement depuis crontab ne fonctionnait plus tout à fait en dash.
La crontab contient un SHELL=/bin/sh en entête qui fait que par défaut, les scripts partent donc en dash.
Exemples de différences dash/bash.

Mise à jour PHP & oracle

On passe de PHP de 5.3 à 5.4, rien de violent (sauf pour les puristes peut-être qui iront voir la page PHP de ces changements), mais tout au moins mon module Oracle a sauté à cette occasion.
Un pecl install oci8 devrait suffire à vous ramener ce qu’il faut. Testez alors à nouveau votre connexion Oracle.

le patch suhosin pour Apache

Il y a une discussion citée sur ce bug. Entre le fait que ce patch ne se justifierait plus trop (PHP aurait au fil du temps assez évolué pour combler pas mal de choses que suhosin apporte) et le fait que ça manquerait de main d’oeuvre côté debian/suhosin. Bref, le patch est désactivé pour le moment et il faut vérifier les conf de vos serveurs/applications web et adapter les éventuels paramètres suhosin positionnés (php_value…).
Je vous recommande un bon locate suhosin et un grep -ri suhosin /etc/apache2/ pour y voir clair rapidement et dans la plupart des outils web.

ocs-inventory-server

Alors là, le paquet a simplement sauté sur un serveur OCS. Rien de méchant, la conf est restée, la base de données aussi, mais les agents ont vite couiné.
Il suffit simplement d’installer à nouveau le paquet.
Coup de pas de bol ? bug ? je ne sais pas.

postfix et SASL

Quelques légers paramètres sautent dans le main.cf : virtual_create_maildirsize, message_helo_required, virtual_maildir_extended, virtual_overquota_bounce
HYPER IMPORTANT : l’authentification en envoi ne marchait plus du tout, on trouve des messages d’erreur type May 23 09:39:33 bla postfix/smtpd[31851]: warning: mail.toto.fr[x.y.z.t]: SASL LOGIN authentication failed: no mechanism available.
J’ai trouvé différentes méthodes sur le web pour contourner ça, dont une qui consiste à réinjecter les paquets « Squeeze » de SASL. Beurk. Et ça ne passait même pas pour moi. Finalement, la bonne méthode est de commenter le paramètre auxprop_plugin: whatever et votre fichier /etc/postfix/sasl/smtpd.conf. Pourquoi ? paske… (je n’ai pas été lire de prose sur le sujet et la conf SASL est déjà assez pénible).
J’ai trouvé ça ici.

postfix et quota

Sur un certain serveur, j’utilise postfix avec le patch « VDA » ajoutant la notion de quota sur les boîtes mails.
Il faut bien penser à récupérer la nouvelle version du patch pour les sources Postfix en question (2.9.6), et on repart pour un tour pour générer le paquet.
SAUF QUE, la compilation échoue. C’est décrit ici.
Je ne sais pas pourquoi, mais il faut changer un paramètre dans le fichier rules de /usr/src/postfix-2.9.6/debian/) ; une histoire de « DEB_BUILD_HARDENING ».
Là ça compile.
Perso ensuite, pour figer postfix dans le temps (et tant pis pour les MAJ de sécu) et éviter que aptitude veuille me le mettre à jour à tout de bras, j’ajoute ceci dans mon /etc/apt/preferences :

Package: postfix
Pin: version *
Pin-Priority: -1

Package: postfix-mysql
Pin: version *
Pin-Priority: -1

Et voilà

Voilà, c’est tout. Ca ne fait pas trop de problèmes finalement, mais certains peuvent vraiment vous bloquer si vous n’avez pas rapidement la solution.