Migration via upgrade

Support Debian
#1

BOnjour,

J’ai, Il y a quelque temps, installé au boulot une debian 4.0 sur un vieux poste de travail.
j’y ai passsé du temps comment pas de souris ? :open_mouth:

bref aujourd’hui est installé:
cacti
glpi
ocs inventory
awstats
joomla

entre autres.

joomla servant a l’intranet, il prend de plus en plus de place et mon pôvre Pentium III et ses 128Mo de RAM commencent a avoir du mal a tout gerer.

je souhaite passer sur une machine plus puissante et passer sur la nouvelle version de debian (peut etre meme la testing)

avez vous une procédure pour faire cette migration ? ou des conseils ?
ou alors je réinstall tout a l’identique puis je dump les bases msql et je copie/colle les fichiers de l’ancien au nouveau serveur?

voila, ma question est vaste mais j’ai besoin d’un coup de main pour me lancer ds la bonne direction…

j’espère que vous aurez des réponses a m’apporter !

Cordialement

T

#2

[quote=“Taltos”]BOnjour,

J’ai, Il y a quelque temps, installé au boulot une debian 4.0 sur un vieux poste de travail.
j’y ai passsé du temps comment pas de souris ? :open_mouth:

bref aujourd’hui est installé:
cacti
glpi
ocs inventory
awstats
joomla

entre autres.

joomla servant a l’intranet, il prend de plus en plus de place et mon pôvre Pentium III et ses 128Mo de RAM commencent a avoir du mal a tout gerer.

je souhaite passer sur une machine plus puissante et passer sur la nouvelle version de debian (peut etre meme la testing)

avez vous une procédure pour faire cette migration ? ou des conseils ?
ou alors je réinstall tout a l’identique puis je dump les bases msql et je copie/colle les fichiers de l’ancien au nouveau serveur?

voila, ma question est vaste mais j’ai besoin d’un coup de main pour me lancer ds la bonne direction…

j’espère que vous aurez des réponses a m’apporter !

Cordialement

T[/quote]

Ouhlà en production je recommande pas du tout la testing, après tu es seul juge après pour ce qui est de la configuration je ferais déjà l’installation et la configuration de base ensuite seulement je vérifierai qu’il y est pas de changement majeure avant de copier coller les fichiers de configuration ( j’ai déjà eu le coup avec un changement de PHP4 à PHP5 par exemple :smt002 ).

#3

hum…

j’arrive pas en fait a décider de l’avantage de prendre la testing plutôt que la stable

est ce a ce point instable ?
j’entends par la que j’installe que le strict nécessaire sur le serveur alors j’avais plutot tendance a penser que cela ne devrait pas déstabiliser trop le serveur…

#4

Tout simplement c’est pas encore gelée donc nombre de paquets de base peuvent être amené à être mis à jour et c’est jamais vraiment bon de faire moult mise à jour sur une machine de production car comme son nom l’indique on la mets en place et elle fait son boulot.

Grosso modo je trouverai plus naturel de trouver des serveurs en production sur sarge ou etch plutôt qu’en testing :smt002

Et je te renvoie la question qu’est-ce que tu as à profiter de squeeze qui n’est pas disponible sous lenny :question:

#5

+1 avec Clochette, pour un serveur en production : LENNY, point.

#6

[quote=“Taltos”]hum…

j’arrive pas en fait a décider de l’avantage de prendre la testing plutôt que la stable
[/quote]
Si un paquetage est cassé (problème de dépendances ou autre) sur une stable, ce qui je le rappelle n’est pas possible en théorie, c’est fixé en quelques heures. Sur une testing, ça peut prendre des mois.

Un exemple qui rentre pile dans ton cas, pendant près de 4 mois l’année dernière le support d’innoDB sur MySQL en testing était défaillant suivant la configuration utilisée.

Aujourd’hui encore, toujours en testing, le fichier de conf (my.cnf) fourni par défaut est erroné au niveau des options de logs… et ça aussi ça fait des mois que ça dure, voila le bug report en question: bugs.debian.org/cgi-bin/bugreport.cgi?bug=540527. Bien sur ici le bug est mineur, mais je te conseille de faire un tour sur le BTS, parfois ça fait peur…

Un exemple encore plus frappant, hors de la production. Midori (un navigateur) en testing actuellement est une boucherie en frenglish, sans adblock, et qui crashe régulièrement, car compilé avec une version peu compatible de webkit, alors que la version disponible en unstable est… nickel puisque compilée avec une version récente de webkit, arrivée par la suite en unstable !

Des exemples comme ça, je (nous) peux (pouvons) en écrire un bouquin :]

Bref, encore un +1 pour Lenny :slightly_smiling:

#7

tu peux aussi:

sauvgarder du type barre metal(complet systeme compris) avec dd ou ce que tu veux un topic est dans truc et astuce a ce sujet.

tester la squeez (future version stable). et ne plus mettre a jours les paquet ensuite, par contre il te faut te tenir aux courant pour les bogue coter sécurité, si faille il y a il faut faire la mise a jours avec les risque que cela comporte aux niveau stabiliter. mai si tu as le temps et les moyen sauvgarder avant permet de contourner le problèmes. tu peux aussi avoir 2 machine enfin plutot 2 disque, un avec la stable et 1 avec la squeez.

voila une sauvegarde a son interet, d’ailleurs je vai ajouter ce chapitre.

#8

ok, vos arguments font mouche. je prend acte.

une dernière chose y a t’il une commande qui puisse me lister ce qui a été installé ?
quels appels apt-get auraient ete fait par exemple ?

c’est con je sais comme question mais ca fait quand meme longtemps qu’il est installé et j’ai rien noté lors de la première installation :blush:

cela pourrait me servir de pense bete en quelque sorte

merci de continuer a suivre le fil

#9

La commande suivante va te lister tous les paquets installés :

Les commandes ci-dessous te permettront de sauvegarder cette liste et de la restaurer au besoin :

[quote=“lol”]# dpkg --get-selections "*" > myselections

Tu aura tout dans le fichier “myselections”

Et tu peux restaurer avec :