[sympa-fr] Un exemple d'upgrade Sympa (6.1.17 -> 6.2.40)

[Jean-Hugues Belpois <adresse@cachée>]

Bonjour  à toutes-tous,

On vient, à Brest, de migrer notre système de listes sous sympa, passant 
de de 6.1.17 à 6.2.40, comme on a tout changé d'un coup (appli bien sur, 
machine, os et bdd), voici la façon dont on s'y est pris et les quelques 
difficultés rencontrées, pour le cas où vous seriez dans ce schéma là.

Au passage, bien en amont : Opération de com (via les listes 
institutionnelles) à destination de la communauté pour prévenir les 
collègues de l'évolution à venir (j -7 environ)

On a procédé en suivant les conseils de David, nouvelle machine + 
nouvelle install de la dernière version + trf uniquement de ce qui est 
nécessaire, du coup dans les grandes lignes ça donne :

- Nouvelle VM en CENTOS pour recevoir le nouveau sympa + postfix + 
postgrey + amavis + apache + MariaDB (installation du système, update, 
etc. tout le tralala habituel d'une nouvelle VM)
- Installation de sympa à partir des sources sur la nouvelle machine :
    - Difficultés avec le module perl dbi::oracle dont l'installation 
ne fonctionne pas si :
    1) On installe pas un oracle minimum en local à partir des rpm 
fournis par oracle
    2) On ne renseigne pas les variables systèmes dans le .bashrc de 
root LD_LIBRARY_PATH et ORACLE_HOME
    3) Et malgré cela il y a un truc qui déconne avec oracle + wwsympa, 
voir + bas
- Création d'un user et d'une BDD sympa dans mariadb sur la nouvelle machine
- Arrêt du postfix, puis du sympa puis du mariadb puis du httpd de 
l'ancienne machine (chkconfig off, ou équivalent, au cas ou la machine 
viendrait a redémarrer)
- Recopie (à grands coups de rsync) des répertoires /home/sympa/arc,  
list_data et spool de l'ancienne machine vers la nouvelle (ça prends un 
certain temps, surtout arc) + /var/www/html car on a des pages web 
spécifiques sur sympa (faq, index, applis, etc) à cet endroit
- Recopie également de fichiers sympa liés à notre utilisation locale 
(families, certains scenarii, etc.)
- Dump de la BDD de l'ancienne machine et injection dans la nouvelle
- Lancement du script d'upgrade de sympa /home/sympa/bin/sympa.pl 
--upgrade --from=6.1.17 (ça prends "un certain temps")
- Changement de l'ip/nom de l'ancienne machine vers une adresse/nom 
provisoire
- Changement de l'ip/nom de la nouvelle machine vers l'adresse/nom de 
"notre" sympa
- Démarrage postfix nouvelle machine
- Démarrage sympa + wwsympa nouvelle machine (croisez les doigts)

C'est parti, premier message pour les listes institutionnelles "Coucou, 
c'est fini, profitez du nouveau sympa, voyez comme l'interface est jolie !"

Quelques remarques :

- Bon c'est un peu le serpent de mer de Sympa (poke -> David), mais la 
liste des listes provoque toujours un 503 au bout de 30 secondes (on à 
+5300 listes), donc on conserve notre solution de contournement : on 
fabrique notre propre liste des listes en php avec un cache en bdd, et 
du coup on  a redirigé avec apache pour que "liste des listes" et 
"rechercher une liste" dans l'interface d'admin pointe sur notre index 
(les collègues ne comprenaient pas le problème de toutes façons, et on 
se faisait enguirlander régulièrement avec "ça marche pas votre truc"). 
Truc de voyou => on ignore superbement la visibilité de la liste 
conceal/no conceal, on considère que toutes les listes doivent 
apparaitre dans l'index, sauf exceptions que nous gèrerions nous-même 
(y'en a pas pour l'instant).

- Comme on utilise massivement (au sens univ moyenne de province bien 
sur) les familles de listes, on a aussi des listes de listes spéciales 
par catégories : listes par UE et listes par code étapes, même trucs en 
php que précédemment.

- On a aussi de grosses demandes pour une procédure de désabonnement 
"rapide" à une/des listes, le lien avec un mailto+unsub dans le pied de 
message est beaucoup trop complexe pour 90% de nos collègues, du coup on 
propose un outil cassifié "Mes listes" avec désabonnement en 1 clic (php 
encore qui envoie discrètement le unsub à sympa, même résultat mais plus 
simple à l'usage).

- On autorise plus la connexion "à l'ancienne" adresse mail + passwd, 
c'est CAS ou rien (décision DSI).

- On autorise pas la demande de création de listes, pour nous ça renvoie 
vers un formulaire qui provoque une demande à l'autorité (la DGS pour 
nous) qui valide ou pas la demande, et ensuite seulement on crée la liste.

- Il y a un truc un peu retors concernant oracle, ou plutôt les listes 
qui tapent dans un serveur oracle pour récupérer leurs abonnés : si 
c'est le taskmanager qui le fait, cycliquement donc, pas de soucis, si 
c'est wwsympa qui le fait ça ne fonctionne pas car il (wwwsympa) ne 
trouve pas où est le module oracle et donc vous envoie un mail avec

Le pilote de base de données pour Sympa::DatabaseDriver::Oracle n'est pas
installé ; vous devez télécharger et installer DBD::Oracle depuis le site
CPAN.

On a essayé un tas de truc pour corriger ça : forcer la réinstall du 
module, mettre des liens symboliques, dupliquer les répertoires, etc. : 
wallouh ! Pour l'instant la rustine est d'ajouter, truc de bourrin on en 
est bien conscients, au début de wwsympa.fcgi (poke2 -> David) :

    use lib split(/:/, $ENV{SYMPALIB} || ''), 
'/home/sympa/bin','/usr/local/lib64/perl5/lib/perl5/x86_64-linux-thread-multi/';
au lieu de
    use lib split(/:/, $ENV{SYMPALIB} || ''), '/home/sympa/bin';

Je ne sais si vous avez déjà eu ça ?


Voilà, si vous vous lancez dans une upgrade sympa, on espère que ça 
pourra vous être utile.

Bonne journée

Jean-Hugues Belpois
Listmaster Université de Brest