[gull] Upgrade OpenSuse

[Yves Martin]

On Tue, 2014-11-11 at 09:50 +0100, Thierry de Coulon wrote:

> J'adore Debian, mais la version stable pose souvent des problèmes en "fin de 
> vie", comme maintenant: certains applications ont besoin de nouvelles 
> librairies, il faut incorporer des bouts de testing...  et il arrive que la 
> mise à jour devienne impossible.

  Bonjour,

Tout dépend de ce qu'on appelle des "bouts" de testing. Si c'est une ou
deux applications qui tirent peu de dépendances, et gérées dans APT avec
le pining (je l'ai fait pour firefox par exemple, enfin iceweasel).
Alors ça se passe relativement bien.

Mais il est préférable de chercher dans les "backports" (voire de
recompiler le deb-src si ça passe facilement) avant de se lancer dans un
mix stable+testing. Ou mieux, utiliser la testing directement.


> Par ailleurs, est-ce qu'on peut vriament faire une mise à jour d'une Debian 5 
> à une Debian 7 sans problème? Je n'ai pas essayé de mettre à jour une SuSE à 
> chaque coup, mais ici l'OP veut passer d'une 11 à une 13, et il s'est passé 
> beaucoup de choses entre deux (bon, il doit s'être écoulé moins de temps 
> entre deux versions principales que chez Debian...)

La procédure recommandée est toujours la suivante:

- mettre à jour la distribution dans sa version actuelle - le dépôt peut
avoir été déplacé dans "archives.debian.org", donc il faut éditer la
source APT

- faire l'upgrade vers chaque version majeure en incluant les dernières
mises à jour, dans ton cas 5 -> 6 -> 7

- à chaque étape, vérifier les fichiers ".dpkg-old" et ".dpkg-new" ou
encore ".ucf-old" et ".ucf-new" qui indique des conflits lors d'éditions
dans /etc

Si par contre, la configuration des services a uniquement été faite par
les masques de Debconf (dpkg --reconfigure paquet), alors même les mises
à jour les plus tordues (comme MySQL) passent souvent tout seul.

J'en profite pour signaler qu'il est important de configurer en ajoutant
des fichiers dans les répertoires ".d" comme
/etc/sysctl.d/
/etc/apt/sources.list.d/
/etc/apt/preferences.d/
/etc/mysql/conf.d
/etc/sudoers.d/
(même si des tuto ou des blogs ne les mentionnent que rarement !!)
pour s'épargner justement les reports de clefs de configuration
(.dpkg-old et .dpkg-new) dans les fichiers principaux gérés par les
paquets.


Et bien sûr, quand il s'agit d'un serveur, le moins de paquets sont
installés, le mieux c'est, pour la sécurité, mais aussi pour les
ugprades.



> Moi, même avec Debian, je tourne "à la japonaise": pour les grands temples, 
> ils construisent le nouveau pendant qu'ils utilisent l'actuel, puis ils 
> changent de temple et reconstruisent l'ancien à neuf.
> Moi j'ai une distribution que j'utilise. QUand je veux passe à une nouvelle, 
> je l'installe au propre à côté, je transfère progressivement les 
> configurations. C'est seulement une fois la nouvelle configuration rodée que 
> je peux écraser la "vielle" distribution.

Pourquoi pas, mais c'est vraiment un travail inutile quand il s'agit
d'une Debian gérée correctement / proprement.

Perso, je fais souvent des clones de VM ou de système avec des copies
rsync lorsque je veux changer les partitions, avant de tester et valider
la procédure d'upgrade.
Si certaines configurations ne sont plus compatibles, cela me laisse le
temps de chercher et documenter, avant d'appliquer l'upgrade en
production.


> J'ajoute que je ne mets pas mes données importantes dans "home", elles sont 
> sur une autre partition, jamais touchée lors de l'installation - libre à 
> l'utilisateur de faire un lien dans home, évidemment.

Si "home" est un système de fichiers indépendant, il n'y a aucune raison
de ne pas l'utiliser "tel quel", c'est quand même plus confortable.
Par précaution, il m'arrive de démonter "/home" avant le "apt-get
dist-upgrade", pour éviter des bricoles inattendues, même avec des
backups tout frais dûment vérifiés.


Pour conclure, les upgrades Debian de versions stables passent
normalement comme une lettre à la poste, si le système est géré avec
rigueur et précautions (j'ai appris ça sur le temps, upgrade après
upgrade).

Pour un poste de travail, utiliser la "testing" présente souvent peu de
risque de "crash" gênant (mais jamais définitif) et permet d'avoir un
système "toujours à jour", en fonction du rythme d'update que l'on
choisit (par mois ou par trimestre).


En espérant avoir motivé de nouveaux adeptes
-- 
Yves Martin