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

[Vincent RAIMBOUX <adresse@cachée>]

Bonjour,

Idem pour moi. Même problème que vous pour les bases oracles sur lesquelles récupérer des abonnés. Dans mon souvenir il manquait le NLS_LANG qui doit correspondre au client (la machine du serveur sympa) et non au serveur oracle. Pour chacune des listes concernées j'ai donc:

db_env ORACLE_HOME=/usr/lib/oracle/12.2/client64;TNS_ADMIN=/usr/lib/oracle/12.2/client64/network/admin;NLS_LANG=French_France.UTF8

---

De: "Pascal Maes" <adresse@cachée>
À: adresse@cachée
Envoyé: Vendredi 3 Mai 2019 18:09:44
Objet: Re: [sympa-fr] Un exemple d'upgrade Sympa (6.1.17 -> 6.2.40)

Bonjour,


Nous utilisons aussi Oracle (plus pour très longtemps) et nous avons la version 6.2.42 (nous sommes aussi passés par la 6.2.40)

Je constate que les variables d'environnement suivantes sont définies :

ORACLE_HOME=/usr/lib/oracle/11.2/client64/
TNS_ADMIN=/usr/share/oracle/11.2/client64/admin
NLS_LANG=FRENCH_FRANCE.UTF8


A part cela, rien de spécial si ce n'est que le client oracle est installé.


Je n'avais pas créé un script pour la liste des listes mais un script qui effectuait une recherche avec la possibilité d'utiliser des jokers.
J'ai dû le modifier pour tenir compte des listes "non visibles" ;-)




> Le 3 mai 2019 à 13:54, Jean-Hugues Belpois <adresse@cachée> a écrit :
>
> 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
>


Bon week-end,
--
Pascal

--

Vincent Raimboux

Centre de Ressources Informatiques

Bureau L101, en télétravail le mardi après midi

 _________________________________________

 UTT - Université de Technologie de Troyes

 12 rue Marie Curie - CS 42060 - 10004 TROYES CEDEX
 Tél. : (33) 03 25 71 76 00 | Fax : (33) 03 25 71 76 76

 

 www.utt.fr  - www.facebook.com/UTTroyes