Outre les nouvelles fonctionnalités et bugs corrigé, il est primordial de migrer tous vos serveurs et machines utilisant Debian 4.x (etch) vers la dernière version stable 5.0.5 (lenny) à l'heure ou j'écris ce billet.
Pourquoi
La raison est simple : depuis mars 2010 la version etch ne bénéficie d'aucune mise à jour de sécurité. De nombreuses exploits faisant leur apparation chaque mois, il est totalement suicidaire d'utiliser Debian 4 en production.
Voici comment faire cet upgrade de la version 4 vers 5.
Migrer en quelques étapes
La montée de version n'est pas compliquée et fonctionne relativement bien. Cependant il est fortement recommandé de réaliser une sauvegarde complète de votre serveur avant de vous lancer. Si vous pouvez cloner votre machine c'est encore mieux pour migrer la version qui n'est pas en production.
- Sauvegarder le fichier sources.list
cp /etc/apt/sources.list /etc/apt/sources.list.backup
- Mettre à jour le système (validez toutes les mises à jour)
aptitude update && aptitude upgrade
- Remplacer etch par lenny dans le fichier sources.list
sed -i 's/etch/lenny/g' /etc/apt/sources.list
- Ajouter les sections contrib et non-free dans le fichier sources.list, exemple de fichier
deb http://ftp.fr.debian.org/debian/ lenny main deb-src http://ftp.fr.debian.org/debian/ lenny main deb http://security.debian.org/ lenny/updates main contrib non-free deb-src http://security.debian.org/ lenny/updates main contrib non-free
- Relancer un mise à jour qui profitera des nouveaux dépôts (validez positivement les questions de mise à jour)
aptitude update && aptitude upgrade
Relancer cette étape en cas d'erreur, autant de fois qu'il le faudra.
Note : Si l'installation des disques a été réalisée via NFS, une erreur peut apparaître lors de la mise à jour de mount, ceci est normal. Il faut vérifier que nfs-common a bien été installé:
aptitude install nfs-common aptitude full-upgrade -y
Conclusion
J'ai réalisé l'upgrade sur plusieurs machines, sans 'encombre.
En cas de pépin (services qui ne redémarrent pas) pensez à regarder du côté des logs (/var/logs/syslog et /var/log/nom_du_service/*.log) pour localiser le souci. Les fichiers de configuration diffèrent quelque peu parfois lors des montées de version, c'est le cas d'Apache.
Une petite recherche Google en cas de message d'erreur vous apportera sûrement de l'aide, sinon les commentaires sont ouverts.
Auteur : Mr Xhark
Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter
4 commentaires
Je l'ai fait il y a peu sur une bécane en prod (oui le sens du risque :d ) ça s'est très bien passé ça m'a même résolu un problème 😀
#vodoo
PS : le com précédent on dirait du spam
@gonzague : si je devais le faire sur un serveur en prod, ce sera à distance pendant mes congés, pas d'accusation comme ça 😀
ps:spam delete.
Salut collègue de monolithe noir finlandais 😉
J'ai migré mon serveur il y a quelques semaines, ou, plus exactement, j'ai fait une nouvelle install (depuis 2001/Potatoe, il n'avait jamais été réinstallé, et il subit occasionnellement mes expériences 🙂 ), car le passage à udev était plus que douloureux. En effet, les upgrades, et tout ce qui avait été désinstallé sans --purge généraient des erreurs (il n'y avait pas que ça).
Donc, attention, sur une vieille install, l'upgrade peut être douloureux, perso, ça a été plus simple/rentable de prendre une machine ayant une conf semblable, pour faire une clean install, puis, de switcher les disques! (note au passage, si ça t'intéresse, j'ai suivi une vidéo youtube, pour bien paramétrer un système bootable sur raid1/lvm: ça marche très bien maintenant, sans bidouille, même si il faut visiblement revenir à lilo).
Justement, un autre écueil: je me suis fait avoir, car la hiérarchie des disques peut changer!!! J'ai ouvert ce topic d'aide:
http://forum.debian-fr.org/viewtopic.php?f=3&t=28736
Depuis, je suis monté en squeeze sans trop de soucis (juste trouver dans le sources.list quand est-ce qu'il faut mettre «testing», et quand il faut mettre «squeeze»)
Voili voilou 🙂
Franck-Sébastien
@inextenza : je ne pratique d'upgrade que d'une version à l'autre, de etch à lenny dans ce cas. Quand c'est trop vieux c'est toujours l'occasion de réinstaller une machine propre, si on a une procédure... dans le cas contraire c'est l'occasion d'en faire une 🙂
Personnellement je ne fais rien en LVM, histoire d'assurer une rétro-compatibilité en cas de panne d'une veille machine... y'a rien de mieux qu'un bon coup de partitionnement à l'ancienne ^^
Merci en tous les cas pour ton retour sur ta migration!