Moving SME to new Hardware/fr

From SME Server
Jump to navigation Jump to search


PythonIcon.png Skill level: Advanced
The instructions on this page may require deviations from standard procedures. A good understanding of linux and Koozali SME Server is recommended.


Is this article helpful to you?
Please consider donating or volunteering
Thank you!

Déplacer un serveur SME sur une nouvelle machine

Introduction

Il y a plusieurs façons de déplacer une installation du Serveur SME sur un nouveau matériel et également sur une nouvelle version logicielle du Serveur SME.

Ce document décrit une méthode utilisant la contribution smeserver-affa v3.

  Attention :
il faut utiliser la contribution smeserver-affa et non Affa ; le développeur d'Affa a abandonné SME pour la version 3 qui ne fonctionne que pour CentOS ; les mainteneurs de smeserver-affa ont implémenté dans smeserver-affa v3 les fonctions nécessaires pour le Serveur SME. Dans la suite de ce document, lorsqu'on parle d'Affa, il s'agit de la contribution smeserver-affa.


Affa donne 3 possibilités pour changer de matériel, qui dépendent du matériel disponible (1, 2 ou 3 serveurs, un disque USB) et la durée acceptable d’interruption du service :

  • En utilisant la fonction «rise», le serveur de sauvegarde sera converti en nouveau serveur de production => 2 machines sont nécessaire - la durée de l'interruption est courte.
  • En utilisant les fonctions de sauvegarde normale et de restauration :
  • avec 2 machines (serveur de production et serveur de sauvegarde - durée d'interruption longue) ou 3 machines (ancien serveur de production, serveur de sauvegarde et nouveau serveur de production - interruption courte) ;
  • avec seulement 1 machine et un disque USB externe (interruption longue).

Ces 3 méthodes peuvent également être utilisées pour passer à une version logicielle supérieure. Cela est aussi valable pour passer de la version SME 8.2 à la version 9.x.

Affa rend cela possible avec une interruption de service minimale du serveur de production.

Dans la suite, il est convenu que IP_prod est l'adresse IP de votre serveur de production et IP_nouvelle est l’adresse IP du nouveau matériel serveur. Remplacer les espaces réservés par vos adresses IP réelles.

En utilisant la fonction «rise»

Préparation

  Attention :
avant d'envisager le passage de SME 8 à SME 9 qui va bientôt devenir urgent (31 mars 2017), penser à vérifier l'état de boguage de chacune des contributions utilisées par le serveur SME. En effet, certaines contributions en version SME 9 ont des bogues qui n'existent pas en version SME 8 et qui peuvent, au mieux, engendrer des messages d'erreurs au redémarrage. Ces messages peuvent faire croire à un bogue de la fonction «rise» d'Affa. A ce jour (10 août 2016), il n'en est rien.


Serveur de production

Activer l'accès ssh à distance pour l'administrateur dans le gestionnaire du serveur de l'IP_prod. Cela inclut de configurer à la fois :

  • - l'accès Secure shell à partir du réseau local ;
  • - autoriser l'administrateur à accéder à SSH en ligne de commande en configurant à «Oui» ;
  • - et «Autoriser l'administrateur à se connecter à l'aide de mots de passe standards» à «Oui».


Se connecter en tant qu'administrateur au serveur d'IP_prod et lancer une mise à jour logicielle :

yum update

Si des paquets sont mis à jour, il est nécessaire de lancer les commandes post mises à jour et de redémarrer :

signal-event post-upgrade; signal-event reboot
Nouveau matériel

Installer le Serveur SME à partir du dernier CDROM/ISO. Lui attribuer une adresse IP inutilisée (IP_nouvelle) et désactiver la fonction DHCP.
Activer l'accès ssh à distance dans le gestionnaire du serveur de la machine d'IP_nouvelle.


  Note :
à partir de maintenant, toutes les étapes suivantes peuvent être réalisées à distance par accès ssh.



Se connecter au serveur d'IP_nouvelle et lancer une mise à jour.

yum update

Effectuer les procédure post mises à jour et redémarrer si c'est demandé.

Installer la contribution Affa. Suivez les dernières instructions d'installation d'Affa ici, en anglais pour l'instant.

Se souvenir, s.v.p., de créer en ligne de commande le répertoire pour les fichiers d'archives :

mkdir /var/affa


  Note :
durant la transition entre SME8 et SME9, les paquets des contributions seront déplacés dans le dépôt des contributions de SME9. Si la contribution n'est pas encore dans le dépôt des contributions de SME9 et une entrée dans les questions/réponses suggère que ce sera installé proprement, il faudra installer la contribution à partir du dépôt de SME8. Voir : http://wiki.contribs.org/SME9.0_Contribs_QA#Setup.


Dans cet exemple, vous avez un Serveur SME de production (IP_prod) d'IP : 192.168.0.2.
Vous avez une seconde machine SME en tant que serveur de sauvegarde (IP_nouvelle) d'IP : 192.168.0.10.
La tâche Affa de sauvegarde s'appelle «ServProd».

Connectez-vous à votre IP_nouvelle en tant que root et éditer/créer le fichier /etc/affa/ServProd.conf. En utilisant, par exemple, l'éditeur nano, ajouter le texte de configuration de tâche de l'exemple suivant au nom de tâche ServProd et adapter Include=XXXXX selon les répertoires supplémentaires qui doivent être sauvegardés, par ex., du fait des contributions installées qui fonctionnent dans /opt) :

[ServProd]
remoteHostName=192.168.0.2
SMEServer=yes
Watchdog=yes
RPMCheck=yes
ConnectionCheckTimeout=120
Debug=no
Description=sauvegarde de smeserveur.chezmoi.xx d'IP 192.168.0.2
DiskSpaceWarn=strict
RootDir=/var/affa
Include=/chaque/répertoire/à/sauvegarder
Include=/autre/répertoire/à/sauvegarder
TimeSchedule=0630
localNice=15
remoteNice=15
rsync--inplace=yes
rsyncCompress=no
rsyncTimeout=900
scheduledKeep=1
dailyKeep=7
weeklyKeep=4
monthlyKeep=12
yearlyKeep=1
status=disabled

Puis sauvegarder votre fichier de configuration de tâche.

Si vous avez un certificat Letsencrypt sur le serveur de production, alors vous devriez l'inclure aussi :

Include=/etc/dehydrated

Maintenant, vérifier que votre configuration est correcte :

affa --configcheck

Cela ne devrait retourner aucune erreur.

Générer des clés DSA et envoyer la clé publique au serveur d'IP_prod.

affa --send-key ServProd

La réponse du serveur d'IP_prod doit être :

Job ServProd: root@IP_prod's password:

Entrer le mot de passe administrateur d'IP_prod. La réponse sera :

Public key sent to IP_prod
  Attention :
avant d'envoyer la clé publique, il faut impérativement modifier provisoirement le serveur d'IP_prod en mettant à «Oui» l'accès ssh à distance à l'aide de mots de passe standards.

Ne pas oublier de remettre cette possibilité à «Non» dès la réponse du serveur après l'entrée du mot de passe.


  Note :
si vous ne vous êtes jamais connecté à IP_prod depuis IP_nouvelle, le serveur va vous demander si vous êtes sûr de l’authenticité du serveur qui répond en vous présentant sa clé RSA qu'il faut alors accepter par «yes».


Copie des données

Exécuter la tâche Affa «ServProd» sur la machine d'IP_nouvelle.

affa --run prodserv

En fonction de la quantité de données et des performances du matériel et du réseau, cette première tâche peut être réellement longue.

Regarder maintenant le fichier /var/affa/ServProd/rpms-missing.txt.

less /var/affa/ServProd/rpms-missing.txt

Vous trouverez une liste de paquets qui sont installés sur le serveur d'IP_prod mais non sur ce serveur d'IP_nouvelle et aussi des paquets installés dans différentes versions. Installer ou mettre à jour les paquets listés. Pour vérifier, vous pouvez exécuter à nouveau les étapes de ce chapitre. A la fin, le fichier rpms-missing.txt ne devrait plus avoir aucun paquet.

Dans le cas où vous changez le système d'exploitation SME pour une version plus élevée, vous allez trouver dans cette liste, non seulement les contributions installées mais toutes les différences entre les 2 systèmes - dans ce cas, vous devez exécuter cette commande sur l'IP_prod

 /sbin/e-smith/audittools/newrpms

pour révéler quelles sont les contributions installées sur l'IP_prod.

Synchronisation finale des données

Demander à vos utilisateurs de se déconnecter.
Se connecter à la machine d'IP_prod et arrêter tous les services qui peuvent modifier des données :

SVC='qpsmtpd sqpsmtpd crond pop3 dovecot pop3s ftp httpd-e-smith atalk smb qmail' 
for s in $SVC; do service $s stop; done

Note : l'interruption de service du serveur de production commence ici.

Se connecter à la machine d'IP_nouvelle et lancer à nouveau la tâche Affa :

affa --run prodserv

Cette passe s'effectue très rapidement car seules les différences depuis la dernière exécution ont besoin d'être synchronisées.

Basculement sur le nouveau matériel

Se connecter à la machine d'IP_prod et l'arrêter :

poweroff


Se connecter à la machine d'IP_nouvelle et «élever» ce serveur comme votre serveur de production :

affa --rise --all prodserv

Cette action s'exécutera très rapidement car seuls des liens durs sont utilisés et aucune donnée n'est déplacée physiquement.

Note: ne pas s'effrayer si votre invite de commande a une apparence différente !

Effectuer maintenant un redémarrage :

reboot

Note : l'interruption de service du serveur de production se termine ici.

Vous avez maintenant une copie conforme de votre ancien serveur de production en fonctionnement sur le nouveau matériel. Vos utilisateurs peuvent maintenant se connecter.

Nettoyage

Effacer les archives Affa :

/bin/rm -rf /var/affa

Supprimer les paquets Affa et toutes les données d'état et de configuration :

yum remove smeserver-affa perl-Filesys-DiskFree
rm -f /etc/cron.d/affa-status /etc/cron.d/affa
rm -rf /home/e-smith/db/affa /home/e-smith/db/affa-report
rm -rf /var/log/affa 

Note : ne pas oublier de nettoyer /var/affa. Sinon vous perdrez de l'espace disque et vous verrez d'étranges rapports de quota. Voir ce fil de discussion pour plus de détails.

Information additionnelle

Performance

Avec cette méthode, vous devriez être en mesure de déplacer un serveur d'une taille typique de 500 Gb sur un nouveau matériel avec une interruption de service de moins de 20 minutes. La durée de la synchronisation finale et de l'«élévation» ne dépendent pas tant de la taille totale des fichiers que du nombre de fichiers et de répertoires.

En utilisant les fonctions de sauvegarde et de restauration

La manière générale de travailler est de faire une sauvegarde de l'ancien serveur Koozali et de la restaurer sur le nouveau serveur Koozali (mise à jour ou non). La fonction «RPMCheck» peut être utilisée indirectement avec le serveur de sauvegarde (comparez la liste entre l'ancien et le nouveau matériel) pour obtenir la liste des paquets rpm manquants sur le nouveau matériel mais elle n'est pas disponible pour une sauvegarde sur le disque USB externe.

Preparation

Take a backup of the running old 'prod server' (see the above conf file /etc/affa/prodserv.conf ).

  Note:
Like using the way based on "rise", your can take the first backup (takes long time) without stopping the services and the last one (is quick) after the logout of the users and the stop of the services


After the backup, set a temporary IP into the conf file of the backup job:

remoteHostName=tem.po.ra.ry.IP

For a backup on an external usb disk, set:

remoteHostName=localhost
RootDir=/the/mount/point/of/the/disk

and mount the disk. You should make a list of the installed rpm's too.

Install SME on the new hardware

Install at least the same version of SME you were running on the old hardware or a more recent one (e.g. from SME8 to SME9).

For the method based on a backup server:
  • Set the temporary IP as internal address of the new hardware
  • From the backup server create the ssh connection between the backup server and the new hardware by sending the ssh key:
 affa --send-key prodserv

The answer from Prod-temp-IP server will be

Job prodserv: root@Prod-temp-IP's password:

enter the root Prod-temp-IP password. The answer will be:

Public key sent to prod-temp-IP
External usb disk:
  • Install "smeserver-affa" on the new hardware
  • mount the usb disk on the same mountpoint than for the backup
  • go into the archive and copy the .ini file into /etc/affa as conf file:
cd /mount/point/prodserv/scheduled.0
ls -a   ### to see the ini file
cp .prodserv.ini /etc/affa/
mv /etc/affa/.prodserv.ini /etc/affa/prodserv.conf
In case of upgrade SME8 to SME9

The restoration of the default data (parameter "SMEServer=yes" into the conf file of the job) will configure yum repos for SME8 on the new server SME9!

In order to avoid this there are 2 possibilities:

  • make a copy of both folders /etc/yum.repos.d and /etc/yum.smerepos.d before the restore. It will be helpful for reconfiguring by hand the repos for SME9 after the restore.
  • add following into the conf file of the backup job:
Exclude=/etc/yum.repos.d
Exclude=/etc/yum.smerepos.d

before the last backup (of course if you will restore from the last backup - scheduled.0 - and not from an older one like weekly.2!)

Restore the data

From the backup server (or from the new production server in case of restoring from external usb disk) run:

affa --full-restore [--preserve-newer=no] [--delete=yes]  prodserv

To get 1:1 the state of the backup.

Keep in mind that:

[--preserve-newer=no]: files on the remote server with modification time newer than on the backup are overwritten through the older ones of the backup.
[--delete=yes]: all files on the remote server, which are not in the backup, are deleted.


  Warning:
A full restore with --preserve-newer no and --delete yes reconstructs the server as it was at the time of the backup. That means, that all files created or server configuration changes made before the restore will be lost!


After the restore, the new prodserver will reboot.

Note for the case of 3 machines: Make sure that the old hardware is switched off or no more connect to the network before the new hardware reboots because the new hardware will take its IP after the reconfiguration.

Tasks post restore

  • If the backup job should be used for further backups of the new hardware, don't forget to replace the temporary IP of "Remotehost" through the previus set IP of the old server into the conf file of the affa job.
  • In case of an OS upgrade, check and if necessary reconfigure the repositories of yum for the new version.