Migration Tux v5

De Linux-Nantes Wiki.

MIGRATION EFFECTUÉE !!!

MIGRATION EN COURS !!!

Page dédiée à la migration vers le nouveau serveur tux de l'association.

Sommaire

Todo

Fait

  • Installation de chkrootkit
  • Sauvegarde sur distribution
  • Installation de logwatch
  • Sauvegarde des bases sur distribution
  • Migration /home et alias mails
  • Migration SPIP
  • Migration DNS
    • Le domaine linux-nantes.org est le domaine maitre
    • Domaine linux-nantes.fr.eu.org modifié pour devenir le domaine esclave
  • Prévenir les listes de diffusion
  • ...
  • Migration sympa (tests à faire avec postfix arrêté)
    • voir https://www.cduce.org/~abate/sympa-migration-step-step
    • le plus simple, c'est d'installer sympa v5, de copier les archives (via rsync), de remettre la base mysql et de passer /usr/lib/sympa/bin/sympa.pl --upgrade --from=4.1.5
    • Penser à modifier les uids des répertoires de sympa (/var/lib/sympa et /var/spool/sympa), l'uid sur tux4 correspond à l'utilisateur postfix sur tux5.
    • Penser également à convertir les fichiers nécessaires en utf-8, sympa les gère mal, de même pour les fichiers partagés
  • Migration web (gallery, wikini ?)
    • Gallery1 => Gallery2 fait par CHiPs (avec mise en place du paquet smarty de Squeeze recompilé).
      • Règles de redirection mises en place avec redirection permanente de l'ancienne arborescence
      • Squellette spip mis à jour pour refléter la nouvelle URL
      • Spams purgés
  • Installation de awstats
  • Installation de munin
  • Migrer de spip 1.9.2 en spip 2 (cf site spip)
  • Migration mediawiki

A faire

  • ...

Migration finale

  1. Bloquer l'envoi sur les listes sur tux4
  2. Refaire la migration sympa (pour ne pas perdre des archives et des abonnements)
  3. Peut-être configurer postfix sur tux4 pour relayer les mails sur tux5 pour ne rien perdre
    • relay_domains = linux-nantes.fr.eu.org, linux-nantes.org
    • relay_host = [tux5.linux-nantes.org]
  4. Eventuellement refaire la migration spip
  5. Resynchroniser les homes
  6. Migrer les DNS
    • tux5 restera le nom canonique
    • Création d'un enregistrement tux4 pour garder un lien vers l'ancien serveur
    • tux deviendra un alias vers tux5
    • Le domaine linux-nantes.org deviendra la référence, le domaine linux-nantes.fr.eu.org contiendra des liens vers linux-nantes.org (en gros, on change de sens)
  7. Publier un article sur le nouveau spip pour signaler le changement de serveur (+ photo de tux v5 dans sa baie)
  8. Serrez les fesses

Matériel Tuxv5

Caractéristiques

Voici la configuration matérielle du nouveau tux v5 :

  • Marque : Dell
  • Modèle : PowerEdge 2650
  • Détails :
    • Processeur(s) :
      • Nombre : 2
      • Fréquence : 2,4 Ghz
      • Cache L2 : 512 Ko
      • Modèle : ?
    • RAM : 3 Go (6 x 512 Mo PC-1600 ECC)
    • Disque :
      • Type : SCSI Ultra320
      • Nombre : 2 + 3
      • Taille : 73 Go / 36 Go
    • RAID :
      • Type : Matériel
      • Model : RAID controller Embedded dual channel Ultra3 (U160) SCSI with 128MB cache
      • Possibilité : 0, 1, 5

Ci-joint :

Documentation

Partitionnement

Partitionnement définitif effectué le 01/02/2010 par PatLeNain et CHiPs

Les 2 disques de 73 Go sont sur le "channel" n°0, et forment le conteneur RAID1 "RAID1_2X73".

Les 3 disques de 36 Go sont sur le "channel" n°1, et forment le conteneur RAID5 "RAID5_3X36".

Les partitions sont réparties comme suit

  • / sur RAID1_2X73 : ? Go, ROOT
  • Swap sur RAID1_2X73 : ? Go
  • /home sur RAID1_2X73 : ? Go, HOME
  • /var sur RAID5_3X36 : 50%, VAR
  • /data sur RAID5_3X36 : 50%, DATA

N.B. : il y a eu également création d'un compte admin UID/GID=999, avec HOME=/data/admin/ pour effectuer la migration des utilisateurs.

Historique

Les 2 disques de 73 Go sont sur le "channel" n°0, et forment le conteneur RAID1 "RAID1_2X73", destiné à accueillir la racine "/".

Les 3 disques de 36 Go sont sur le "channel" n°1, et forment le conteneur RAID5 "RAID5_3X36", destiné à accueillir "/home".

(décision arbitraire de CHiPs le 13/12/2009).

Les 2 disques de 73 Go sont sur le "channel" n°0, et forment le conteneur RAID1 "RAID1_2X73", destiné à accueillir la racine "/".

Les 3 disques de 36 Go sont sur le "channel" n°1, et forment le conteneur RAID5 "RAID5_3X36", destiné à accueillir "/var".

(proposition arbitraire de Pat le 15/12/2009).

Les 2 disques de 73 Go sont sur le "channel" n°0, et forment le conteneur RAID1 "RAID1_2X73", en lvm, pour accueillir "/", "/home"

Les 3 disques de 36 Go sont sur le "channel" n°1, et forment le conteneur RAID5 "RAID5_3X36", destiné à accueillir "/var".

(proposition matinale de Fred le 23/12/2009)

Partitionnement actuel

  • Racine sur le channel n°0
  • /var sur le channel n°1

Services existants

Voici la liste des services importants tournant sur tux v4

Web

Site web

Le site web comprends les virtualhosts suivants :

  • www.linux-nantes.fr.eu.org / www.linux-nantes.org
  • www.gasell.org => DELETE!
  • gridcoffee.linux-nantes.org

les répertoires suivants sont accessibles depuis www.linux-nantes.org :

  • gallery
  • phpmyadmin
  • phppgadmin
  • sympa

Logiciels

Voici les principaux logiciels utilisés :

  • Apache 1.3.33 => Apache 2.2 : OK
  • PHP 4.x => PHP 5.2 : OK
    • php-mysql : OK
    • php-pgsql : OK
  • gallery : TODO! (paquetage)
  • phpmyadmin : OK
  • phppgadmin : OK
  • libapache-mod-fastcgi : OK
  • SPIP : TODO! (pas un paquetage)

Mail

Voici les principaux logiciels utilisés :

  • Sympa : TODO!
  • Postfix : OK
  • amavis-new : OK
  • clamav : OK
  • pyzor : OK
  • razor : OK
  • spamassassin : OK

Autres

  • MySQL : OK
  • SSH : OK
  • fail2ban : OK
  • PostgreSQL : OK
  • mailgraph : OK
  • unison : OK
  • rsync : OK
  • ntp : OK
  • procmail : OK

Sauvegarde

La sauvegarde actuelle se fait en local via zbackup avec un historique de 10 jours et ensuite celle-ci est synchronisé via unison et rsync sur 2 serveurs distants.

Services à venir

Voici les différents points à définir pour la mise en place du prochain tux

Web

Le service web en soi ne subira pas spécialement de gros changement, sachant que le site web est mis à jour régulièrement pour ce qui est du SPIP. Cela ne devrait pas trop être difficile de faire une restauration. Pour les autres sites hébergé, un ménage s'impose. De plus, il faut voir si nous continuons à fournir un public_html au utilisateur (voir réflexion dans "Home Directory").

Pour les autres sites (gasell et gridcoffee), ces projets ne sont plus supportés par LNA. Le domaine gasell.org n'a pas été renouvellé, donc inutile de maintenir le site. Pour gridcoffee, on peut le garder pour archive. Une fois mis en place, on pourra migrer le wiki dessus. --PatLeNain 15 décembre 2009 à 12:13 (UTC)

  • Il faut pas oublier de virer postgresql, et les différentes dépendances car cela ne servait qu'à gasell. De plus, je pense qu'il serait pratique d'avoir au local sur Distribution un mirroir locale du/des site(s) pour sauvegarde et surtout pour test de mise à jour --Nissen 24 décembre 2009

Mail

Hormis une mise à jour du système de mail et des règles de filtrage (j'aime bien le mélange clamav-amavis-spamassassin-SPF). Il faut voir aussi si nous continuons à fournir des alias aux membres de l'association. Pour l'instant et d'après ce que je vois dans les logs seul une dizaine de personnes l'utilisent. C'est sympa d'avoir un alias mais il faut alors bien faire comprendre aux membres que cela ne doit pas devenir leurs adresses principales (ie: ne pas s'abonner à une liste à fort débit genre kernel linux).

  • De plus et pour être sûr de ne pas "manger" toute la bp de sigma en smtp, on peut aussi limiter la bp de postfix directement dans postfix --Nissen 24 décembre 2009

Listes de diffusion

Hormis une mise à jour, il faut vérifier si on peut facilement récupérer les archives sans soucis....

  • Ne pas oublier de prévenir tout le monde du changement (je l'avais oublié lors du passage de mailman à sympa, c'est pas top ...) --Nissen 24 décembre 2009

Accès SSH

Juste une réflexion qui date, devons-nous fournir un accès ssh au serveur à tout le monde ? Ou aux seul admins ?

  • Juste pour les détails : Accès via mdp ou seulement par clé ? --Nissen 24 décembre 2009

Home Directory

Toujours dans la même veine, à fournir ou pas. Je suis dans tous les cas pour la mise en place de quota. Ça permet de pouvoir anticiper.

Sauvegarde

Simple question : continuons nous sur zbackup (qui fonctionne très bien et fait parfaitement ce que l'on veut) ou passons nous sur un système de sauvegarde type bacula ?

En tout cas, il faut garder le rsync sur distribution. Peut-être mettre en place rsnapshot en local.--PatLeNain 15 décembre 2009 à 12:15 (UTC)

Oui, et faire la bascule de mon serveur vers Distribution dans le script de zbackup. --Nissen 23 décembre 2009

Dans ce cas, faut-il garder zbackup sachant que l'on a une sauvegarde intégrale (et incrémentale) avec distribution ? --PatLeNain 23 décembre 2009 à 09:54 (UTC)

  • Le type de sauvegarde n'est pas génant, c'est surtout comment on sauvegarde et que l'on s'assure qu'une sauvegarde à jour est ailleurs à ce moment là. --Nissen 24 décembre 2009

Divers

Proposition d'ajout de logiciels ou autres ?

  • Mise en place d'un ldap pour la gestion des membres avec Gosa (cela permet de regrouper dans une seul interface la gestion des mails, comptes unix, sympa (j'ai un doute), spip, etc ....
  • Faire l'install un samedi aprem et finir par une bouffe ?
  • Se faire une réunion avant pour savoir ce qui sera mis en place ou pas et comment on fait ?
  • 2 cartes réseaux, possibilité de faire du bonding si on peut brancher les 2
  • Mise en place de munin pour faire un peut de supervision
  • Logiciel sympa pour la gestion de documents de manière simple : http://www.hyla-project.org/
  • Gosa me paraît un peu lourd et complexe
  • Un samedi aprem m'irait bien (voir 2 suivant l'avancée)
  • le bonding me paraît superflu

--PatLeNain 15 décembre 2009 à 12:19 (UTC)

  • Gosa n'est qu'un frontend à ldap, mais une fois perdu de ses plugins superflu, je trouve très pratique de pouvoir gérer tout depuis une seule interface. Maintenant effectivement si c'est juste pour la gestion utilisateur c'est surement trop gros :) --Nissen 23 décembre 2009
  • Pour éviter d'avoir trop de soucis de test de password ssh, il faudrait réactiver fail2ban aussi et même si nous sommes derrière le firewall sigma, peut-être se mettre quelques règles histoire de ....
    • fail2ban est prévu, je l'avais rajouté sur tuxv4 il y a quelques mois mais la version ne devait pas marcher terrible. --PatLeNain 26 décembre 2009 à 12:12 (CET)
  • Voir aussi mettre un mx secondaire sur Distribution pour les moments ou Tux n'est pas ou peu joignable, cela fait un backup dans tous les cas et c'est facile à mettre en place. --Nissen 24 décembre 2009
    • J'y ai pensé. Cela demande un peu de boulot mais on peut le faire à distance sans problème plus tard. --PatLeNain 26 décembre 2009 à 12:12 (CET)

Migration

Proposition initiale

  • Objectif : Passer d'une sarge à une lenny
    • Copie du système puis dist-upgrade
    • Install en lenny puis installation et configuration des services au fur et à mesure (choix retenu)

Proposition de --CHiPs 14 décembre 2009 à 22:29 (UTC)

Il est possible d'installer la machine à Sigma sur une autre IP publique et de la mettre en place en parallèle de l'ancienne le temps de migrer.

Il faudra ensuite

  • soit arrêter l'ancienne machine et modifier la configuration IP de la nouvelle,
  • soit modifier le MX et les autres enregistrements A ou CNAME dans le DNS pour garder la nouvelle IP, puis arrêter l'ancienne machine.

Info de CHiPs du 20/12

Il serait très utile pour Sigma de récupérer l'adresse IP actuelle (pour une histoire de gestion du plan d'adressage). A voir ce qui serait le plus pratique (utilisation des deux machines en parallèle le temps de la migration ou remplacement) sachant que la nouvelle machine s'appelle déjà tux.

  • Pas de soucis pour changer d'adresse IP. On peut faire tout le paramétrage à distance, par contre le gros de l'install est de préférence à faire en local histoire de pas faire courir CHiPs dans la salle serveur, si tux ne redémarre pas. le temps de propagation des DNS mets de 3h à 18h en moyenne donc une fois les tests faits (avec nom dns de test par exemple). On fait la bascule et hop (avec redirection des mails de l'ancien vers le nouveau). -- Nissen 23 décembre 2009

Proposition de Nissen 24 décembre 2009

Voilà par ordre :

  • Local :
    • Installation d'une debian toute propre
    • Installation des logiciels
    • Test de l'ensemble
  • Depuis Sigma :
    • Mise en place du tux v5 sur une nouvelle IP
    • Récupération des données
    • Mise en place et test de la sauvegarde
    • Préparation du dns pour le changement d'adresse IP
    • Mise en place du relay postfix sur Tuxv4 vers Tuxv5
    • Mise en place de la redirection web de Tuxv4 vers Tuxv5
    • Vérification de l'ensemble
    • Changement du dns
Récupérée de « http://wiki.linux-nantes.org/wiki/Migration_Tux_v5 »