REVISION 13/03/09

Dotdeb a mis à jour les paquets relatifs à la messagerie: qmail, vpopmail, ezmlm. La mise à jour ne pose aucun problème mais il convient de vérifier les droits sur le fichier /usr/sbin/vchkpw (Merci Guillaume) si vous utilisez votre serveur en courrier sortant avec authentification: les droits doivent être ajustés ainsi:

srvweb:/usr/sbin# ll vchkpw
-rwsr-sr-x 1 root root 85364 mar 12 18:53 vchkpw

REVISION 14/03/09

1) Désormais le fichier /etc/vpopmail/vlimits-default contient une directive: disable_spamassassin . Si (comme moi) vous n'avez pas opté pour le remplacement de ce fichier lors de la mise à jour, TOUS vos mails passeront par l'anti-spam en IGNORANT le .qmail du répertoire de l'utilisateur virtuel. Il convient donc de rajouter manuellement cette ligne dans ce fichier.

De plus cela générera des logs de la forme pour un utilisateur censé ne pas utiliser l'anti-spam:

Mar 14 13:48:03 srvweb qmail: 1237034883.030212 starting delivery 2: msg 915834 to local net.caen-postmaster@net.caen
Mar 14 13:48:03 srvweb qmail: 1237034883.030394 status: local 1/10 remote 0/20
Mar 14 13:48:03 srvweb spamd[10338]: spamd: connection from localhost.localdomain [127.0.0.1] at port 57343
Mar 14 13:48:03 srvweb spamd[10338]: spamd: handle_user unable to find user: 'postmaster@net.caen'
Mar 14 13:48:03 srvweb spamd[10338]: spamd: processing message <20090314124802.12384.qmail@pmenier.dynalias.net> for postmaster@net.caen:1004
Mar 14 13:48:06 srvweb spamd[10338]: spamd: clean message (-102.1/2.5) for postmaster@net.caen:1004 in 3.9 seconds, 3419 bytes.
Mar 14 13:48:06 srvweb spamd[10338]: spamd: result: . -102 - AWL,BAYES_00,NORMAL_HTTP_TO_IP,NO_RELAYS,USER_IN_WHITELIST scantime=3.9,size=3419,user
=postmaster@net.caen,uid=1004,required_score=2.5,rhost=localhost.localdomain,raddr=127.0.0.1,rport=57343,mid=<20090314124802.12384.qmail@pmenier.dy
nalias.net>,bayes=0.000000,autolearn=ham

On voit une ligne d'erreur: spamd: handle_user unable to find user

Après correction:

Mar 14 13:52:21 srvweb qmail: 1237035141.324008 info msg 915834: bytes 870 from <root@mx.net.sarge> qp 12824 uid 64011
Mar 14 13:52:21 srvweb qmail: 1237035141.330186 starting delivery 3: msg 915834 to local net.caen-postmaster@net.caen
Mar 14 13:52:21 srvweb qmail: 1237035141.330364 status: local 1/10 remote 0/20
Mar 14 13:52:21 srvweb qmail: 1237035141.334870 delivery 3: success: did_0+0+1/
Mar 14 13:52:21 srvweb qmail: 1237035141.335082 status: local 0/10 remote 0/20
Mar 14 13:52:21 srvweb qmail: 1237035141.335199 end msg 915834

2) Concernant ezmlm-idx là aussi un petit ajustement a été nécessaire faute de quoi on se prend le message d'erreur suivant:

Mar 14 16:11:15 sarge qmail: 1237043475.797100 delivery 2: deferral: ezmlm-send:_fatal:_temporary_qmail-queue_error:_unable_to_exec_qq_(#4.
3.0)/

Après recherches il semblerait que cela soit lié à une variable d'environnement : QMAILQUEUE. J'ai donc ajouté la ligne suivante dans le script de démarrage de qmail:

export QMAILQUEUE=/var/qmail/bin/qmail-queue


3) Toujours à propos de ezmlm le format des fichiers/répertoires a du changer car je me prenais ce type de message d'erreur:

Mar 14 16:20:50 srvweb qmail: 1237044050.779938 delivery 3: failure: Sorry,_only_subscribers_may_post._If_you_are_a_subscriber,_please_forward_this_message_to_netcaen-owner@net.caen_to_get_your_new_address_included_(#5.7.2)/

Il existe un utilitaire censé reconstruire les fichiers (ezmlm-make) mais je n'ai pas réussi à trouver la bonne syntaxe. Mes listes de diffusion étant assez limitées, je les ai simplement supprimées puis recrées.






Afin de ne pas "courir de risques", j'avais déjà migré quelques machines physiques et virtuelles vers lenny sans constater de problèmes particuliers, quelques ajustements sans plus.

Et donc comme prévu cela s'est déroulé tout à fait correctement, moyennant quelques peaufinages en fin d'install.

L'opération ayant déjà été effectuée, j'ai utilisé un apt-proxy et le sources.list de la machine était donc le suivant:

deb http://192.168.0.42:9999/debian/ lenny main contrib non-free
deb-src http://192.168.0.42:9999/debian/ lenny main contrib non-free
deb http://192.168.0.42:9999/security lenny/updates main
deb http://192.168.0.42:9999/dotdeb etch all
deb http://192.168.0.42:9999/backports lenny-backports main
deb http://192.168.0.42:9999/volatile lenny/volatile main contrib non-free


Ce qui correspond à:

deb http://security.debian.org/ lenny/updates main contrib non-free
deb ftp://ftp.fr.debian.org/debian/ lenny main contrib
deb-src ftp://ftp.fr.debian.org/debian/ lenny main contrib
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
deb http://www.backports.org/debian/ lenny-backports main
deb http://packages.dotdeb.org etch all

Vous remarquerez que le depôt dotdeb est laissé sur etch dans la mesure où son maintainer n'a pas encore eu le temps de recompiler les paquets pour lenny (vpopmail, qmail, qmailadmin, php5, mysql-5/5.1 etc...)

Curieusement d'ailleurs ceci n'a posé aucun souci: vpopmail, qmail, qmailadmin fonctionnent au poil.

srvweb:/web/clients/pwre14dj/cgi-bin# dpkg -l vpopmail-bin qmail qmailadmin
||/ Nom                             Version                         Description
+++-===============================-===============================-==============================================================================
ii  qmail                           1.03-38.dotdeb.2                Secure, reliable, efficient, simple mail transport system
ii  qmailadmin                      1.2.11-0.dotdeb.5               web interface for managing qmail with virtual domains
ii  vpopmail-bin                    5.4.25-0.dotdeb.2               vpopmail binaries

Comme j'utilise le POP3S il m'a fallu regénérer le certificat qui doit désormais s'appeler dans /etc/stunnel/stunnel.pem.

J'utilise pour ceci le script suivant:

make_stunnel_cert.sh

#!/bin/sh

openssl req -new -x509 -days 365 -nodes -config /etc/ssl/openssl.cnf -out stunnel.pem \
-keyout stunnel.pem

openssl gendh 512 >> stunnel.pem
mv /etc/ssl/certs/stunnel.pem /etc/ssl/certs/stunnel.pem.bak
mv stunnel.pem /etc/stunnel/stunnel.pem


Attention toutefois lors de la prochaine maj de vpopmail.



Ensuite pour éviter les messages d'erreurs à répétitions à propos des locales, j'ai commencé par installer les .... locales (et leurs dépendances).

srvweb:/# apt-get update
srvweb:/# apt-get install locales

Puis j'avais remarqué que certains paquets plantaient systématiquement: il s'agit de iscsitarget et de libming-dev. Je les ai donc désinstallés avant le dist-upgrade.

srvweb:/# apt-get remove iscsitarget libming-dev

Et enfin mise à jour complète:

srvweb:/# apt-get dist-upgrade

Comme je compile moi-même php5 et apache2 j'utilise pas mal de libxxx-dev qui n'ont pas toutes été remplacées. J'ai donc lancé leur mise à jour après le dist-upgrade:

srvweb:/# apt-get install libmhash-dev liblua5.1-curl-dev libcurl4-openssl-dev libbz2-dev libssl-dev libncurses5-dev libc6-dev build-essential libjpeg62-dev libimlib2-dev libxpm-dev libsnmp-dev libsqlite3-dev libtidy-dev libxmlrpc-epi-dev libpq-dev libc-client2007b-dev libsasl2-dev libsqlite0-dev libpcre3-dev

J'ai profité de l'upgrade pour corriger quelques oublis antérieurs, par exemple la réindexation de la base ldap.
Cette manip s'effectue sous le compte openldap qui a un shell à /bin/false par défaut. Donc modification du shell:

srvweb:/# cat /etc/passwd | grep openldap
openldap:x:108:111:OpenLDAP Server Account,,,:/var/lib/ldap:/bin/bash

Puis réindexation:

srvweb:/# su - openldap
openldap@srvweb:~$ /usr/sbin/slapindex -f /etc/ldap/slapd.conf -b "dc=pmenier,dc=dynalias,dc=net"

Et retour à la normale:

srvweb:/# cat /etc/passwd | grep openldap
openldap:x:108:111:OpenLDAP Server Account,,,:/var/lib/ldap:/bin/false


Autre détail: j'utilise awstats (depuis les sources) ainsi que divers plugins, en fait des modules perl: hostinfo, geoip...
J'ai du réinstaller une dépendance:

srvweb:/# apt-get install libnet-xwhois-perl libgeo-ip-perl

Un autre paquet oublié (?) par l'upgrade: locate, bien pratique tout de même.

srvweb:/# apt-get install locate

Et pour terminer, j'ai réinstallé libming-dev (iscsitarget n'étant plus utilisé sur ce serveur).

srvweb:/# apt-get install libming-dev

Enfin dernier petit détail: modification de /etc/stunnel/stunnel.conf qui était un peu trop verbeux à mon goût sur la console en passant le debug_level à 1 et modification du script de démarrage de vpopmail:

if [ "$POP3SSLSTART" == "1" ] ; then
                        sh -c "start-stop-daemon --start --quiet --user root \
                            --make-pidfile --pidfile /var/run/tcpserver_vpopmails.pid \
                            --exec /usr/bin/tcpserver -- \
                        -H -R 0 995 /usr/sbin/stunnel -o /var/log/pop3s.log -l /usr/sbin/qmail-popup /usr/sbin/qmail-popup pmenier.dynalias.net \
                            $DAEMON /usr/sbin/qmail-pop3d Maildir &"
                        echo -n " POP3-SSL"
fi


La mise à jour était à peine terminée que le dernier patch linux-vserver était en ligne et j'en ai profité pour recompiler le noyau avec la dernière mouture gcc : nouvelle version :

srvweb:/# uname -a
Linux srvweb 2.6.27.19-vs2.3.0.36.4 #1 SMP Mon Feb 23 09:08:55 CET 2009 i686 GNU/Linux

srvweb:/# cat /etc/issue
Debian GNU/Linux 5.0 \n \l

Une petite vérif dans les ps me confirment bien que tout est ok à savoir: bind9, apache2 (perso), slapd, vpopmail, qmail, courier-authdaemon, courier-imap, pure-ftpd, mysql, imapproxy, spamassassin clamav.

Je revalide enfin le sources.list avec les valeurs par défaut (sans passer par l'apt-proxy qui n'est pas toujours démarré).

Voilà c'est terminé pour le serveur. Il ne me reste plus qu'à upgrader les vservers. Les paquets étant déjà stockés sur l'hôte je ne vais même pas utiliser apt-proxy mais un mount --bind.

Mise à jour des vservers

srvweb:/opt/vservers# mount |grep bind
/var/cache/apt/archives on /opt/vservers/vweb1/var/cache/apt/archives type none (rw,bind)
/var/cache/apt/archives on /opt/vservers/vweb2/var/cache/apt/archives type none (rw,bind)
/var/cache/apt/archives on /opt/vservers/vweb3/var/cache/apt/archives type none (rw,bind)
/var/cache/apt/archives on /opt/vservers/vweb4/var/cache/apt/archives type none (rw,bind)
/var/cache/apt/archives on /opt/vservers/vweb6/var/cache/apt/archives type none (rw,bind)

Le vserver vweb5 n'est pas oublié mais tourne pour sa part sur Centos-5.2.

Je recopie le nouveau sources.list sur chacun des vservers et je mets à jour la base des paquets.

srvweb:/etc/apt# for i in vweb{1,2,3,4,6};do cp sources.list /opt/vservers/$i/etc/apt;done

srvweb:/etc/apt# for i in vweb{1,2,3,4,6};do vserver $i exec apt-get update;done

Ensuite il faut se les taper un par un...

Au hasard prenons vweb3:

srvweb:/# vserver vweb3 enter

Je mets à jour une clé manquante par défaut:

vweb3:/# gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 4D270D06F42584E6

vweb3:/# gpg --armor --export 4D270D06F42584E6 | apt-key add -

vweb3:/# apt-get dist-upgrade

L'install s'effectue correctement jusqu'à la mise à jour de klogd que je suis obligé de stopper par un ctrl-c:

....
Installing new version of config file /etc/init.d/klogd ...
Stopping kernel log daemon... failed!
Starting kernel log daemon...
^Cdpkg: error processing klogd (--configure):
 subprocess post-installation script killed by signal (Interrupt)
Setting up sysklogd (1.5-5) ...

klogd ne présentant aucun intérêt sur un vserver je modifie donc le script suivant:

vweb3:/# vi /var/lib/dpkg/info/klogd.postinst

en ajoutant un exit 0 juste après le shebang.

Et je reprends:

vweb3:/# apt-get install -f

En fin d'install il faut aller faire un peu de ménage dans les rc?.d :

vweb3:/etc/rc0.d# rm K20ircd-hybrid K20maxdb-server K20maxdb-webtools K20openbsd-inetd K20ssh K21maxdb-xserver K25hwclock.sh K63mountoverflowtmp K85quota K89atd S20sendsigs S31umountnfs.sh S35networking S36ifupdown S40umountfs S60umountroot S90halt

vweb3:/etc/rc1.d# rm K20ircd-hybrid K20maxdb-server K20maxdb-webtools K20openbsd-inetd K20ssh K21maxdb-xserver K79quotarpc K89atd S30killprocs S90single

vweb3:/etc/rc2.d# rm S11klogd s15ssh_gen_host_keys S20ircd-hybrid s20maxdb-webtools s20maxdb-xserver S20openbsd-inetd s20ssh s20zope s21maxdb-server S21quotarpc s89atd S99rmnologin S99stop-bootlogd

vweb3:/etc/rc3.d# rm S20ircd-hybrid s20makedev S20openbsd-inetd s21quotarpc S99rmnologin S99stop-bootlogd sS20maxdb-webtools sS20maxdb-xserver sS20ssh sS20zope sS21maxdb-server sS89atd

vweb3:/etc/rc4.d# rm S20ircd-hybrid S20maxdb-webtools S20maxdb-xserver S20openbsd-inetd S20ssh S21maxdb-server S21quotarpc S89atd S99rmnologin S99stop-bootlogd

vweb3:/etc/rc5.d# rm S20ircd-hybrid S20maxdb-webtools S20maxdb-xserver S20openbsd-inetd S20ssh S21maxdb-server S21quotarpc S89atd S99rmnologin S99stop-bootlogd

vweb3:/etc/rc6.d# rm K20ircd-hybrid K20maxdb-server K20maxdb-webtools K20openbsd-inetd K20ssh K21maxdb-xserver K25hwclock.sh K63mountoverflowtmp K85quota K89atd S20sendsigs S30urandom S31umountnfs.sh S35networking S36ifupdown S40umountfs S60umountroot S90reboot

vweb3:/etc/rcS.d# rm S01glibc.sh S02hostname.sh S02mountkernfs.sh S04mountdevsubfs.sh S05bootlogd S05keymap.sh S08hwclockfirst.sh S10checkroot.sh S11hwclock.sh S12mtab.sh S18ifupdown-clean S20module-init-tools S30checkfs.sh S35mountall.sh S35quota S36mountall-bootclean.sh S37mountoverflowtmp S39ifupdown S40networking S45mountnfs.sh S46mountnfs-bootclean.sh S48console-screen.sh S55bootmisc.sh S55urandom S70screen-cleanup S70x11-common S70xfree86-common S99stop-bootlogd-single

Au final j'ai donc:

vweb3:/etc# find rc?.d

rc0.d
rc0.d/K09apache2
rc0.d/K90sysklogd
rc0.d/README
rc0.d/K11cron
rc1.d
rc1.d/K09apache2
rc1.d/K90sysklogd
rc1.d/README
rc1.d/K11cron
rc2.d
rc2.d/README
rc2.d/S99rc.local
rc2.d/S89cron
rc2.d/S10sysklogd
rc2.d/s91apache2
rc3.d
rc3.d/S91apache2
rc3.d/README
rc3.d/S99rc.local
rc3.d/S89cron
rc3.d/S10sysklogd
rc4.d
rc4.d/S91apache2
rc4.d/README
rc4.d/S99rc.local
rc4.d/S89cron
rc4.d/S10sysklogd
rc5.d
rc5.d/S91apache2
rc5.d/README
rc5.d/S99rc.local
rc5.d/S89cron
rc5.d/S10sysklogd
rc6.d
rc6.d/K09apache2
rc6.d/K90sysklogd
rc6.d/README
rc6.d/K11cron
rcS.d
rcS.d/README
rcS.d/S70nviboot
rcS.d/S30procps


J'effectue une petite modif sur le script d'init de sysklogd (que j'ai conservé lors de l'upgrade) en mettant en remarque des lignes inutiles:

## cmd=`cat /proc/$pid/cmdline | tr "\000" "\n"|head -n 1 2>/dev/null`

    # No syslogd?
    #
    ##if [ "$cmd" != "$binpath" ]
    ##then
    ##  return 1
    ##fi

En fin d'install je vérifie que tout fonctionne et je m'aperçois qu'apache n'est pas démarré: c'est normal: il existe désormais un paquet spécifique pour le suexec et même un paquet suexec-custom (que je n'ai pas testé mais qui doit probablement permettre de tuner un peu enfin (!) les paths)


vweb3:/# apt-get install apache2-suexec


Voilà c'est terminé . Je vais tester un arrêt/redémarrage du vserver pour finaliser:

vweb3:/etc/init.d# logout

srvweb:/opt/vservers# vserver vweb3 stop
Stopping web server: apache2 ... waiting .
Stopping periodic command scheduler: crond.
Stopping system log daemon: syslogd.

srvweb:/opt/vservers/vweb4/etc/init.d# vserver-stat
CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
20     112 902.4M  78.5M   0m19s79   0m10s10   7h07m38 vweb1
21      21 465.5M  58.8M   0m04s22   0m01s40   7h07m24 vweb2
23      58 488.3M  12.4M   0m00s12   0m00s68  29m15s72 vweb4
24      11 394.3M  27.9M   0m00s14   0m00s14   7h07m07 vweb5
25       6  77.4M  20.7M   0m00s22   0m00s23   7h07m05 vweb6

srvweb:/opt/vservers/vweb4/etc/init.d# vserver vweb3 start
Starting system log daemon: syslogd.
Starting periodic command scheduler: crond.
Starting web server: apache2.

srvweb:/opt/vservers/vweb4/etc/init.d# vserver-stat
CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
20     112 902.4M  78.5M   0m19s79   0m10s10   7h07m45 vweb1
21      21 465.5M  58.8M   0m04s22   0m01s40   7h07m31 vweb2
22       8  94.3M  18.8M   0m00s92   0m00s72   0m02s56 vweb3
23      58 488.3M  12.4M   0m00s12   0m00s68  29m22s79 vweb4
24      11 394.3M  27.9M   0m00s14   0m00s14   7h07m14 vweb5
25       6  77.4M  20.7M   0m00s22   0m00s23   7h07m12 vweb6

srvweb:/opt/vservers# vserver vweb3 enter

vweb3:/# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 init [2] 
31645 ?        Ss     0:00 /sbin/syslogd -m 0
31660 ?        Ss     0:00 /usr/sbin/cron
31669 ?        Ss     0:00 /usr/sbin/apache2 -k start
31672 ?        S      0:00 /usr/sbin/fcgi-pm -k start
31676 ?        S      0:00 /usr/sbin/apache2 -k start
31678 ?        S      0:00 /usr/sbin/apache2 -k start
31681 ?        S      0:00 /usr/sbin/apache2 -k start
31683 ?        S      0:00 /usr/sbin/apache2 -k start
31685 ?        S      0:00 /usr/sbin/apache2 -k start
31686 ?        S      0:00 /usr/sbin/apache2 -k start
31695 ?        S+     0:00 login                                                                                            
31723 pts/1    Ss     0:00 /bin/bash -login
31727 pts/1    R+     0:00 ps ax


REMARQUE(S):

1) Concernant bind9 un petit message d'erreur dans les logs lors du démarrage ou d'un reload:

Mar  8 09:48:02 srvweb named[1078]: received control channel command 'reload'
Mar  8 09:48:02 srvweb named[1078]: loading configuration from '/etc/bind/named.conf'
Mar  8 09:48:02 srvweb named[1078]: max open files (1024) is smaller than max sockets (4096)
Mar  8 09:48:02 srvweb named[1078]: using default UDP/IPv4 port range: [1024, 65535]
Mar  8 09:48:02 srvweb named[1078]: using default UDP/IPv6 port range: [1024, 65535]
Mar  8 09:48:02 srvweb named[1078]: reloading configuration succeeded
Mar  8 09:48:02 srvweb named[1078]: reloading zones succeeded

Il suffit de modifier le script de démarrage de bind9 de cette façon:

Dans le case start)

....
 ulimit -HSn 8192
        if start-stop-daemon --start --oknodo --quiet --exec /usr/sbin/named \
                --pidfile ${PIDFILE} -- $OPTIONS; then
            if [ "X$RESOLVCONF" != "Xno" ] && [ -x /sbin/resolvconf ] ; then
                echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.named
            fi
            log_end_msg 0
        else
            log_end_msg 1
        fi
    ;;

.....


Voilà, c'est tout bon. On ferme :)

Des infos détaillées sur la config matérielle de cette machine sont à dispo ici : http://webpmenier.dynalias.net/yacs/sections/view.php?id=11&articles=2


Remarque pour les frileux :) J'ai par ailleurs effectué un dist-upgrade sur une machine station de travail avec gnome (arch i386 AMD 2800+) sans aucune erreur.


Je ne peux que féliciter une fois de plus les équipes debian et tous ceux qui ont participé à la sortie de cette version 5, qui, même si elle s'est faite un peu attendre est, de mon point de vue, une véritable référence.