Ubuntu-fr

mac-gyver31

Le passage sans risque d'une version n à n+1

On est toujours écartelé entre l'envie de passer à une nouvelle version à cause des nouveautés annoncés et attendues, et la peur de perdre la stabilité et le bon fonctionnement d'une config qu'on a mis du temps à mettre au point.

- Les softs spécifiques, genre virtualbox, ou Blender, que j'ai installé, vont-il toujours fonctionner ?
- Ne vais je pas subir les mêmes bugs très pénalisants qui peuplent le forum ?

Il y a un moyen assez simple de se faire une idée, à condition d'avoir un PC doté d'un Bios capable de booter sur un disque externe USB : se munir d'un tel disque  ( on en trouve de bonne capacité à prix très abordable), y transférer son système dessus, et y tester l'upgrade vers la nouvelle version.
Une fois l'upgrade réalisée, on a tout loisir de tester avec la profondeur désirée.

L'idéal est de concevoir un protocole de test, sorte de check-list de tout ce qu'il faut vérifier, qu'il ne faut pas oublier d'enrichir chaque fois qu'on installe un soft "sensible" ou comprenant des paramétrages manuels. Ce protocole facilite cette tâche de "qualification", a la manière d'un pilote de ligne qui fait ses vérifications mécaniquement et méthodiquement, et donc sans risque d'erreur,  avant chaque vol

Ce n'est qu'une fois ce protocole de test déroulé, en ayant résolu les éventuels problèmes apparus (toujours à documenter), que vous pourrez réaliser l'upgrade sur votre disque de référence. Vous mesurerez alors le retour sur investissement, et le ferez sans angoisse. Le test sur le disque de qualification peut être mené au rythme du temps que vous pouvez y consacrer, et votre système origine reste opérationnel pour les tâches qu'on aime toujours à voir se réaliser rapidement. Tout le monde aspire aujourd'hui à un système opérationnel et fiable.

Ca peut paraître lourd et fastidieux, mais c'est imparable. Je travaille dans un centre de production, et c'est la base du métier : jamais de mise en production directe sans qualification et tests d'intégration plus ou moins poussés, selon la nature du "change", profondeur que l'on apréhende de mieux en mieux avec l'expérience.

C'est une mesure du même niveau que celle consistant à faire des sauvegardes régulière de ses données.

Au fait, à quand remonte votre dernière sauvegarde ?

---

Il est temps d'enlever les fenêtres, et de construire un monde ouvert.

bizulk

Re : Le passage sans risque d'une version n à n+1

En fait le second souhait qui nécessite ta méthode est d'avoir en même temps le système en production et le système à qualifier.
Tu peux aussi faire une install identique sur une deuxième partition, et tester l'upgrade dessus.
Sinon une marche arrière avec une sauvegarde partimage ou un simple tgz devrait suffire, mais on a toujours peur des marches arrière.
++

---

N'oubliez pas de marquer les messages [resolus]

mac-gyver31

Re : Le passage sans risque d'une version n à n+1

En fait le second souhait qui nécessite ta méthode est d'avoir en même temps le système en production et le système à qualifier.

Pas forcément. On peut très bien envisager de recréer à chaque fois le système de qualification. Si le système de production est de taille importante, c'est généralement le fait de données utilisateurs (photos, films, ...) inutiles en totalité pour la qualification. Il suffit alors d'avoir une stratégie de stockage de ses documents , et ne pas en mettre partout.

en utilisant la commande cpio -p pour copier de partitions à partitions, on peut facilement exclure les données :

find . -print > liste_fichier

va générer la liste de tous les fichiers à sauvegarder du FS monté (attention, il faut avoir booté sur un live CD, monter les partitions à copier une à une, car le find ne s'arrête pas au frontières des systèmes de fichier)
Ensuite, on ouvre liste_fichier sous éditeur, et on enlève toutes les références aux données utilisateurs
Et ensuite :

cat liste_fichier | cpio -pdmv /mnt/fs_cible

Cette liste de fichier servant à générer le système de qualification peut être conservée et re-utilisée à chaque fois, tant que le système de production n'a pas évolué par installation d'un nouveau paquetage.

Tu peux aussi faire une install identique sur une deuxième partition, et tester l'upgrade dessus.

C'est précisément le fondement de la méthode, sauf que cette install identique, il est préférable à mon sens de la regénérer à chaque fois qu'on veut tester un upgrade. Sinon, celà oblige à faire évoluer deux systèmes, ce qui est source d'erreur. Au bout d'un moment, les deux environnements divergent à cause d'un oubli un jour, ou d'une install reportée par manque de temps...
Après, l'expérience joue aussi pour décider s'il faut dérouler la procédure, ou si on peu faire l'upgrade direct car le risque est faible. Par exemple : je le fais pour un passage de Intrepid à Jaunty. Je ne le fait pas pour un passage de firefox Vx.y à Vx.y+1 ou Vx+1

Sinon une marche arrière avec une sauvegarde partimage ou un simple tgz devrait suffire, mais on a toujours peur des marches arrière.

En production, on emploie cette méthode pour des opérations complexes et contraintes dans le temps pour lesquelles il n'est pas possible de dérouler le process de qualif / intégration. Comme tu dis, on a peur des marches arrières, et la décision est prise qu'en situation totalement déserpérée, et ce qu'autant plus qu'on est avancé dans l'opération de changement.

---

Il est temps d'enlever les fenêtres, et de construire un monde ouvert.