Merci de bien vouloir compléter ces informations avec vos Problèmes rencontrés lors de migrations en fin de page ! |
Cette page présente la migration de Debian Etch (4.0r7) vers Debian Lenny (5.0).
Pour connaître la technique conseillée pour installer Debian à l'AUF, consultez la page Debian.
Migration de Etch vers Lenny
Commencez par vérifier que votre système est à jour !
vérifiez vos sources apt dans /etc/apt/sources.list
lancez apt-get update ; apt-get upgrade
intégrez les éventuels changements que vous trouverez avec find /etc -name "*.dpkg*" -o -name "*.ucf*"
lisez la section « Problèmes rencontrés lors de migrations » ci-dessous, à vérifier avant la migration
- A noter deux systèmes à mettre absolument à jour :
Suivez la procédure officielle de mise à jour !
![/!\](/static/gugiel/img/alert.png "/!\")
Il faut absolument lire les notes de publications. Cela vous évitera la plupart des problèmes possibles. Si vous hésitez à mettre à jour un serveur en production, contactez d'abord la liste Tech@Auf afin que nous étudions ensemble les problèmes potentiels. 
Quand on vous propose de choisir entre votre ancienne configuration et celle proposée par Debian, dans la plupart des cas il est préférable de choisir cette dernière (celle de Debian) pour éviter une interruption de la mise à jour faute de configuration valide. Vous pourrez de toutes façons ré-intégrer vos modifications ensuite à partir des fichier .dpkg-old ou .ucf-old (ou de votre dernière sauvegarde). Attention : il s'agit d'intégrer les modifications de l'ancienne configuration et non pas simplement recopier l'ancien fichier de configuration !
Finalisez la mise à jour
une nouvelle fois, intégrez les éventuels changements que vous trouverez avec find /etc -name "*.dpkg*" -o -name "*.ucf*"
cherchez s'il reste des paquets non-Debian : aptitude search ~i\!~Odebian
aptitude affichera la liste des paquets installés qui ne sont pas originels d'une archive Debian officielle
Problèmes rencontrés lors de migrations : À LIRE AVANT DE MIGRER !!
Suivi des modifications avec git
Étant donné les différences importantes entre git 1.4 et 1.5, le paquet auf-git-etc fixe maintenant des variables d'environnement GIT_DIR et GIT_WORK_TREE pour tous les utilisateurs dans le groupe admin.
Cela n'a en principe aucune conséquence pour la migration mais pourrait en avoir pour des utilisateurs ou scripts dans le groupe admin qui gérerait des dépôts autres que celui servant à suivre la racine. Mais a priori on ne devrait pas trouver ce cas particulier à l'AuF.
WebMail Horde/IMP
- Pas de gros problème en général vu que ce n'est qu'un changement de version mineur.
En revanche il faut lire tous les /usr/share/doc/{horde3,imp4,turba2,kronolith2,mimp1,…}/UPGRADING* car il y a quelques scripts SQL à lancer pour créer ou mettre à jour des tables (ici aussi de façon mineure).
Par ailleurs, si vous avez défini des hooks pour IMP, il faut les déplacer de /etc/horde/horde3/hooks.php vers /etc/horde/imp4/hooks.php.
- En cas de souci, pensez à activer et consulter les logs de PHP !!
Si votre webmail n'est pas sur un serveur dédié, pour séparer les problèmes vous pouvez bloquer la mise à jour de Horde/IMP juste avant de lancer la dernière phase de migration de Etch vers Lenny (avant le aptitude dist-upgrade) avec la commande suivante :
sudo aptitude hold horde3 imp4
- Vous pourrez alors vous occuper tranquillement de vérifier le reste des services sur le même serveur web, puis revenir plus tard terminer la partie de la migration concernant Horde/IMP avec les commandes suivantes :
sudo aptitude unhold horde3 imp4 sudo aptitude dist-upgrade
Il faudra impérativement repasser par l'interface d'administration web pour mettre à jour vos fichiers de configuration !
Gestionnaire de liste de discussion Mailman
Il faut bien vérifier qu'il ne reste aucun message à traiter en attente avant de faire la mise à niveau de mailman.
┌─────────────────────────┤ Configuring mailman ├──────────────────────────┐ │ The directory /var/lib/mailman/qfiles contains files. It needs to be │ │ empty for the upgrade to work properly. You can try to handle them by: │ │ - Stop new messages from coming in (at the MTA level). │ │ - Start a mailman queue runner: /etc/init.d/mailman start │ │ - Let it run until all messages are handled. │ │ If they don't all get handled in a timely manner, look at the logs │ │ to try to understand why and solve the cause. │ │ - Stop it: /etc/init.d/mailman stop │ │ - Retry the upgrade. │ │ - Let messages come in again. │ │ You can also decide to simply remove the files, which will make Mailman │ │ forget about (and lose) the corresponding emails. │ │ │ │ If these files correspond to shunted messages, you have to either │ │ delete them or unshunt them (with /var/lib/mailman/bin/unshunt). │ │ Shunted messages are messages on which Mailman has already abandoned │ │ any further processing because of an error condition, but that are kept │ │ for admin review. You can use /var/lib/mailman/bin/show_qfiles to │ │ examine the contents of the queues. │ │ │ │ You have the option to continue installation regardless of this │ │ problem, at the risk of losing the messages in question or breaking │ │ your Mailman setup. │ │ │ │ Old queue files present │ │ │ │ abort installation │ │ continue regardless │ │ │ │ │ │ <Ok> │ │ │ └──────────────────────────────────────────────────────────────────────────┘
Backuppc
- Juste pour signaler que ça marche sans aucun souci ni deboggage
Nagios
- Nagios passera de la version 2 à la version 3.
- Nagios2 sera supprimé, il faut installer nagios3 à la main, et remettre les config.
- Faire attention au "notify-by-email" qui devient "notify-service-by-email" et "host-notify-by-email" qui passe à "notify-host-by-email"
Bind9
Après la migration, le serveur DNS ne répond qu'aux requêtes concernant les domaines pour lesquels il a autorité et plus pour les domaines externes. Voici un exemple de lignes qu'il faut ajouter au fichier /etc/bind/named.conf.options pour autoriser les requêtes récursives depuis les réseaux internes :
acl "local" { 127.0.0.1; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; options { directory "/var/cache/bind"; // ... allow-query { "local"; }; allow-recursion { "local"; }; };
Freeradius
- Faire attention au fichier de conf radius.conf dont certains paramètres changent :
- log_auth devient auth
- log_auth_badpass devient auth_badpass
- ...
- L'activation de l'authentification PAM ou autres se fait dans d'autres fichiers qui sont inclus au radius.conf
- J'ai donc accepté les nouvelles config, et j'ai réadapté l'ancienne config à la nouvelle manière de faire. -- Roger
Moodle
Pour ceux qui comme moi utilisent le paquet Debian de Moodle pour profiter du travail de suivi de sécurité de Debian, il faut faire attention à vérifier que le paquet php5-mysql est bien installé après la mise à niveau, faute de quoi Moodle ne fonctionnera plus (car il recommande php5-psql par défaut). Ne pas oublier de relancer apache2 le cas échéant, ainsi que de passer par /admin/ pour effectuer la mise à jour de la base de données.
Après la migration, il se peut que les utilisateurs ne puissent plus se connecter si l'authentification avec « Auto-enregistrement par courriel » a été désactivée. Pour corriger cela, on peut soit l'activer, soit mettre à jour le champ correspondant dans la base de données Moodle en manual :
UPDATE mdl_user SET auth='manual' WHERE auth='email';
Dovecot
Pour ceux qui utilisent mail_chroot, il faut prendre garde à y mettre un / terminal (par exemple mail_chroot = /var/mail/) faute de quoi l'accès aux boîtes aux lettres ne fonctionnera pas.