Migrer un serveur

bbenn · Le 09/12/2012, à 00:01

Salut,

je vais devoir migrer un serveur (ubuntu vers ubuntu sur une autre machine)
Il y a un truc qui me pose problème: les groups et les users.
J'ai une vingtaine de groupe et une soixantaine de users sur le serveur, est-ce que je vais devoir tout refaire à la main sur le nouveau ou bien est-ce que je peux automatiser ça?

Merci

J5012 · Le 09/12/2012, à 03:04

tu fais une copie clone bit-a-bit de la partition serveur a deplacer avec clonezilla par ex.

tiramiseb · Le 09/12/2012, à 11:33

J5012 a écrit :

tu fais une copie clone bit-a-bit de la partition serveur a deplacer avec clonezilla par ex.

C'est une possibilité.
Mais la migration peut éventuellement être l'occasion de remettre le système au propre et éventuellement monter de version

bbenn, pour conserver les groups/users/pass (si toutefois tu n'utilise pas d'authentification LDAP ou d'autres trucs sioux dans le genre) tu peux tout à fait copier le contenu des fichiers /etc/group, /etc/passwd et /etc/shadow (uniquement le contenu qui t'intéresse hein, les "vrais" utilisateurs, pas les utilisateurs qui sont créés automatiquement par le système); Fais gaffe quand même à ne pas t'empêcher d'accéder aux données, il ne faut simplement pas qu'un autre utilisateur - avec un autre mot de passe - ait le même UID que ton premier utilisateur sur le nouveau système (cet UID étant 1000 a priori).

bbenn · Le 09/12/2012, à 12:37

tiramiseb a écrit :

J5012 a écrit :
tu fais une copie clone bit-a-bit de la partition serveur a deplacer avec clonezilla par ex.
C'est une possibilité.
Mais la migration peut éventuellement être l'occasion de remettre le système au propre et éventuellement monter de version

bbenn, pour conserver les groups/users/pass (si toutefois tu n'utilise pas d'authentification LDAP ou d'autres trucs sioux dans le genre) tu peux tout à fait copier le contenu des fichiers /etc/group, /etc/passwd et /etc/shadow (uniquement le contenu qui t'intéresse hein, les "vrais" utilisateurs, pas les utilisateurs qui sont créés automatiquement par le système); Fais gaffe quand même à ne pas t'empêcher d'accéder aux données, il ne faut simplement pas qu'un autre utilisateur - avec un autre mot de passe - ait le même UID que ton premier utilisateur sur le nouveau système (cet UID étant 1000 a priori).

ces 3 fichiers suffisent? il n'y à rien de plus qui est modifié quand on fait un adduser?
il faudra aussi que je crée les home de chacun mais ça à la limite je peux faire un cp massif du dossier /home vers le nouveau serveur
à priori pas de soucis pour les ID car j'avais commencé avec 10000
merci à toi

tiramiseb · Le 09/12/2012, à 12:43

bbenn a écrit :

ces 3 fichiers suffisent? il n'y à rien de plus qui est modifié quand on fait un adduser?

À part le home comme tu l'as précisé, non, rien de plus.

chefdelegion · Le 09/12/2012, à 22:16

du moment que tu gardes les fichiés comme dit tiramiseb et le dossié /home c'est bon jai déjà fait sa pour passer de Debian à RedHaT

jlmas · Le 10/12/2012, à 16:26

bbenn a écrit :

ces 3 fichiers suffisent?
il faudra aussi que je crée les home de chacun mais ça à la limite je peux faire un cp massif du dossier /home vers le nouveau serveur

Utilise plutôt rsync à la place de cp

Personnellement je fais un tar.gz de /etc et je récupère les paquets installés avec la commande suivante :

dpkg --get-selections > /var/backups/installed-software

Il ne te reste plus qu'à installer la liste des paquets ainsi produite sur le nouveau serveur et de renvoyer les fichiers de conf spécifiques dans le /etc de ton nouveau serveur

devphp · Le 10/12/2012, à 17:07

Commence par faire un backup en gardant les droits des fichiers tel qu'ils sont.

tar -zcf /var/backups/home.tgz /home/

Pour la base de donnée

#!/bin/bash
# Au cas où, voici la ligne de commande qui permet de remettre un dump dans mysql. Vous noterez que l'on n'utilise pas la commande 'mysqldump'.
# mysql -uUSER -pPASSWORD maBaseDeDonnee < mondump.sql
# Droit de l'utilisateur USER 
# SELECT, SHOW DATABASES, LOCK TABLES
 
#date du jour
DATE=`date +%y_%m_%d`

echo "Save SQL jobs start "$DATE
#liste des dossier
LISTEBDD=$( echo 'show databases' | mysql -uUSER -pPASSWORD )
 
#on boucle sur chaque dossier (for découpe automatiquement par l'espace)
for SQL in $LISTEBDD
 
do
 
if [ $SQL != "information_schema" ] && [ $SQL != "mysql" ] && [ $SQL != "Database" ] && [ $SQL != "performance_schema" ]; then
 
#echo $SQL
mysqldump -uUSER -pPASSWORD $SQL | gzip > /var/backups/sql/$SQL"_mysql_"$DATE.sql.gz
 
fi

done

echo "Save completed"

Je stock donc mes sauvegarde dans /var/backups/ (qui existe de base) une fois que j'ai bien tout sauvegardé (il faut patienté un peu)

scp fichier.tar user@ip:/dossier/de/destination 
Password please : ??

Le transfère est ok

Dernière modification par devphp (Le 10/12/2012, à 17:07)

bbenn · Le 11/12/2012, à 23:27

Pour les droits ça va être un peu plus chaud car j'utilise les ACL

ah oui j'ai remarqué un truc tout pourri aussi: dans le password mysql il y a le terme '!!' et de ce fait je n'arrive pas à le mettre directement dans la ligne de la commande mysql
je suis obligé de ne pas le mettre puis de le saisir manuellement quand on me le demande
du coup je ne peux pas scripter pour faire un dump par le cron par exemple
je n'ai pas tenté de modifier le mdp non plus car je flippe un peu des conséquences

Dernière modification par bbenn (Le 11/12/2012, à 23:35)

devphp · Le 12/12/2012, à 06:46

bbenn a écrit :

Pour les droits ça va être un peu plus chaud car j'utilise les ACL
ah oui j'ai remarqué un truc tout pourri aussi: dans le password mysql il y a le terme '!!' et de ce fait je n'arrive pas à le mettre directement dans la ligne de la commande mysql
je suis obligé de ne pas le mettre puis de le saisir manuellement quand on me le demande
du coup je ne peux pas scripter pour faire un dump par le cron par exemple
je n'ai pas tenté de modifier le mdp non plus car je flippe un peu des conséquences

Et bien c'est très simple, tu crée un utilisateur, qui a les droits SELECT, LOCK TABLE et SHOW TABLE. Tu lui donne un mdp compliqué mais sans !!.
De cette façon, la tache se fera sans mal. Pour la sécurité un chroot peut permettre d’empêcher la lecture par autrui.

bbenn · Le 13/12/2012, à 21:35

j'ai encore 2 ptites interrogations:
j'utilise actuellement des clés ssh pour permettre des montages sshfs entre le serveur et des postes clients.
Est-ce que je peux récupérer les clés sur le serveur et les mettre sur le nouveau sans avoir rien à faire sur les postes clients?
Je voudrais m'assurer également que ces montages sshfs ne puisse plus se faire pendant que je fais la manip (le temps que je récupère toutes les données et pour empêcher que les utilisateurs fassent des modifs sur leur données), comment est-ce que je peux faire?

tiramiseb · Le 13/12/2012, à 21:44

Est-ce que je peux récupérer les clés sur le serveur et les mettre sur le nouveau sans avoir rien à faire sur les postes clients?

Oui, car la clé privée est sur le client : sur les serveurs tu ne mets que la clé publique, tu peux utiliser plusieurs fois la même clé publique sur plusieurs serveurs différents pour un seul client.

Je voudrais m'assurer également que ces montages sshfs ne puisse plus se faire pendant que je fais la manip

Tu enlèves les clés sur l'ancien serveur (en modifiant, renommant ou déplaçant le fichier "authorized_keys")

bbenn · Le 13/12/2012, à 23:10

cool merci beaucoup

bbenn · Le 16/12/2012, à 00:22

et selon vous, ça a quelle valeur (en terme de rémunération pour un prestataire) pour réaliser ces actions?

tiramiseb · Le 16/12/2012, à 00:39

C'est difficile à dire comme ça...

Je peux faire un devis mais il me faut plus d'informations (si intéressé, on peut en parler en privé).

bbenn · Le 03/02/2013, à 16:43

Salut,
je me pose une ptite question actuellemnt concernant la migration et notemment le dump de labase mysql.

pour faire un dump il faut que la base soit dans un état start. Dans ce cas comment m'assurer qu'il n'y a pas de transaction pendant le dump?
il n'y a pas moyen de faire un dump avec la basse arrétée?

tiramiseb · Le 03/02/2013, à 17:08

Si tu veux sauvegarder avec la base arrêtée, tu peux directement prendre le contenu de /var/lib/mysql, à la limite...

comment m'assurer qu'il n'y a pas de transaction pendant le dump?

http://stackoverflow.com/questions/4514 … hen-ddl-is

Il faut mettre un verrou :

mysql> FLUSH TABLES WITH READ LOCK;

bbenn · Le 03/02/2013, à 17:26

tiramiseb a écrit :

Si tu veux sauvegarder avec la base arrêtée, tu peux directement prendre le contenu de /var/lib/mysql, à la limite...
comment m'assurer qu'il n'y a pas de transaction pendant le dump?
http://stackoverflow.com/questions/4514 … hen-ddl-is
Il faut mettre un verrou :
mysql> FLUSH TABLES WITH READ LOCK;

bah jusqu'à présent je sauvegardais effectivement /var/lib/mysql mais j'ai tenté de restaurer et ça ne fonctionne pas.
c'est peut-être lié à la différence de version de mysql

pour passer la commande FLUSH TABLES WITH READ LOCK; comment je peux le faire dans un script stp?

tiramiseb · Le 03/02/2013, à 17:33

je sauvegardais effectivement /var/lib/mysql mais j'ai tenté de restaurer et ça ne fonctionne pas.
c'est peut-être lié à la différence de version de mysql

Fort possible.

pour passer la commande FLUSH TABLES WITH READ LOCK; comment je peux le faire dans un script stp?

mysql -u<utilisateur> -p<mot de passe> -e "FLUSH TABLES WITH READ LOCK;" <base de données>

Et n'oublie pas de déverrouiller la base à la fin.

Autre possibilité (peut-être plus simple), utiliser une des options suivantes de mysqldump :
- --lock-all-tables : verrouiller toutes les tables de toutes les bases pendant le dump
- --lock-tables : verrouiller les tables de la base courante

bbenn · Le 03/02/2013, à 17:46

en effet la 2eme soluce semble plus simple
je test tout ça en live.
Concernant un de tes posts dans lequel tu me propose de créer un user avec les droits SELECT, LOCK TABLE et SHOW TABLE
je suis un peu embété car voici les droits que me propose phpmyadmin:

Données
SELECT
INSERT
UPDATE
DELETE
Structure
CREATE
ALTER
INDEX
DROP
CREATE TEMPORARY TABLES
SHOW VIEW
CREATE ROUTINE
ALTER ROUTINE
EXECUTE
CREATE VIEW
EVENT
TRIGGER
Administration
GRANT
LOCK TABLES
REFERENCES

tiramiseb · Le 03/02/2013, à 17:49

Ah ça n'a pas dû être moi, je ne me rappelle pas avoir conseillé ces droits : la seule fois où j'ai parlé de droits récemment j'ai évoqué "GRANT ALL" (et c'est pas le plus propre, c'est sûr)

bbenn · Le 03/02/2013, à 17:50

quand bien mème, j'ai accordé tout les droits a mon user et ça ne passe pas:

mysqldump: Couldn't execute 'FLUSH TABLES': Access denied; you need the RELOAD privilege for this operation (1227)

tiramiseb · Le 03/02/2013, à 17:50

Ben dans ce cas il faut donner le privilège RELOAD à l'utilisateur en question

bbenn · Le 03/02/2013, à 17:55

je viens de remarquer que dans la gestion des privilèges dans phpmyadmin, il y a 2 lignes pour mon user.
1 sur les serveur localhost et 1 sur le serveur %
en faisant les modifs sur la ligne 1 ça passe
en fait je ne sais pas à quoi correspond le %

bbenn · Le 03/02/2013, à 22:47

encore une ptite question

j'ai des montages sshfs depuis des postes clients sur le serveur.
au moment de faire le backup, je voudrais m'assurer que personne n'est connecté.
je fais donc un killall sshd ce qui est très efficace pour virer tout le monde.
PAr contre comment empêcher les reconnexions le temps que je fasse la backup?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 09/12/2012, à 00:01

Migrer un serveur

#2 Le 09/12/2012, à 03:04

Re : Migrer un serveur

#3 Le 09/12/2012, à 11:33

Re : Migrer un serveur

#4 Le 09/12/2012, à 12:37

Re : Migrer un serveur

#5 Le 09/12/2012, à 12:43

Re : Migrer un serveur

#6 Le 09/12/2012, à 22:16

Re : Migrer un serveur

#7 Le 10/12/2012, à 16:26

Re : Migrer un serveur

#8 Le 10/12/2012, à 17:07

Re : Migrer un serveur

#9 Le 11/12/2012, à 23:27

Re : Migrer un serveur

#10 Le 12/12/2012, à 06:46

Re : Migrer un serveur

#11 Le 13/12/2012, à 21:35

Re : Migrer un serveur

#12 Le 13/12/2012, à 21:44

Re : Migrer un serveur

#13 Le 13/12/2012, à 23:10

Re : Migrer un serveur

#14 Le 16/12/2012, à 00:22

Re : Migrer un serveur

#15 Le 16/12/2012, à 00:39

Re : Migrer un serveur

#16 Le 03/02/2013, à 16:43

Re : Migrer un serveur

#17 Le 03/02/2013, à 17:08

Re : Migrer un serveur

#18 Le 03/02/2013, à 17:26

Re : Migrer un serveur

#19 Le 03/02/2013, à 17:33

Re : Migrer un serveur

#20 Le 03/02/2013, à 17:46

Re : Migrer un serveur

#21 Le 03/02/2013, à 17:49

Re : Migrer un serveur

#22 Le 03/02/2013, à 17:50

Re : Migrer un serveur

#23 Le 03/02/2013, à 17:50

Re : Migrer un serveur

#24 Le 03/02/2013, à 17:55

Re : Migrer un serveur

#25 Le 03/02/2013, à 22:47

Re : Migrer un serveur

Pied de page des forums