Minutes from installation

Jour 1 : mercredi 06 mars 2011, 9h à 16h50

Après quelques soucis logistiques pour la connexion à openmeeting, nous avons finalement pu commencer les travaux vers 10h (pratiquement 1h de retard). Étaient présents : Darko, Alex, Niry, David, Francis le consultant et moi-même. Jeff nous a rejoint pendant quelques temps avant de se retirer (dans la cité de Constantine).

Voici le déroulement des travaux :

* vérification des pre-installations qui avaient été faites * configuration du noeud de gestion du cluster mysql (/etc/mysql/ndb_mgmd.cnf) pour déclarer tous les noeuds qui vont y participer. * configuration du mysql server sogo de Montréal : ajout des paramètres clusters (/etc/mysql/conf.d/local.cnf) * idem sur le serveur de Tana * ajout de la source inverse.ca et installation de sogo (aptitude install sogo). Soucis de dépendance et conflit :

• Les paquets suivants sont CASSÉS :
  mysql-cluster-client-5.1 mysql-cluster-server-5.1
  Les NOUVEAUX paquets suivants vont être installés :
  autotools-dev{a} avahi-daemon{a} bind9-host{a} consolekit{a} dbus{a} geoip-database{a} gnustep-base-common{a}
  gnustep-base-runtime{a} gnustep-common{a} gnustep-make{a} libavahi-client3{a} libavahi-common-data{a}
  libavahi-common3{a} libavahi-compat-libdnssd1{a} libavahi-core6{a} libbind9-60{a} libck-connector0{a} libdaemon0{a}
  libdbd-mysql-perl{a} libdbi-perl{a} libdbus-glib-1-2{a} libdns64{a} libeggdbus-1-0{a} libevent-1.4-2{a} libffi5{a}
  libgeoip1{a} libgnustep-base1.19{a} libisc60{a} libisccc60{a} libisccfg60{a} liblwres60{a} libmemcached2{a}
  libmysqlclient16{a} libnet-daemon-perl{a} libnss-mdns{a} libobjc2{a} libpam-ck-connector{a} libplrpc-perl{a}
  libpolkit-gobject-1-0{a} libsbjson2.3{a} libsope-appserver4.9{a} libsope-core4.9{a} libsope-gdl1-4.9{a}
  libsope-ldap4.9{a} libsope-mime4.9{a} libsope-xml4.9{a} libxml2{a} libxslt1.1{a} memcached{a} mysql-client-5.1{a}
  mysql-client-core-5.1{a} mysql-server{a} mysql-server-5.1{a} mysql-server-core-5.1{a} sgml-base{a} sogo
  sope4.9-gdl1-mysql{a} sope4.9-libxmlsaxdriver{a} tmpreaper{a} xml-core{a}
  0 paquets mis à jour, 60 nouvellement installés, 0 à enlever et 1 non mis à jour.
  Il est nécessaire de télécharger 34,3Mo d'archives. Après dépaquetage, 95,7Mo seront utilisés.
  Les paquets suivants ont des dépendances non satisfaites :
  mysql-cluster-server-5.1: Est en conflit avec: mysql-server (< 7.0.9-1ubuntu7) mais 5.1.41-3ubuntu12.10 doit être installé.
  Est en conflit avec: mysql-server-5.1 mais 5.1.41-3ubuntu12.10 doit être installé.
  mysql-cluster-client-5.1: Est en conflit avec: mysql-client-5.1 mais 5.1.41-3ubuntu12.10 doit être installé.
  Les actions suivantes permettront de résoudre ces dépendances :
  
  Conserver les paquets suivants dans leur version actuelle :
  mysql-client-5.1 [Non installé]
  mysql-server [Non installé]
  mysql-server-5.1 [Non installé]
  
  Laisser les dépendances suivantes non satisfaites :
  sope4.9-gdl1-mysql recommande mysql-server (>= 5.0)
  Le score est de -123
  
  Accepter cette solution ? [Y/n/q/?]

  • Sélection du paquet libmysqlclient16 précédemment désélectionné.
    Dépaquetage de libmysqlclient16 (à partir de .../libmysqlclient16_5.1.41-3ubuntu12.10_i386.deb) ...
    dpkg : erreur de traitement de /var/cache/apt/archives/libmysqlclient16_5.1.41-3ubuntu12.10_i386.deb (--unpack) :
     tentative de remplacement de « /usr/lib/libmysqlclient.so.16.0.0 », qui appartient aussi au paquet mysql-cluster-client-5.1 0:7.0.9-1ubuntu7
    dpkg-deb: sous-processus coller tué par le signal (Relais brisé (pipe))
    
    
    Paramétrage de xml-core (0.13) ...
    
    dpkg : des problèmes de dépendances empêchent la configuration de sope4.9-gdl1-mysql :
     sope4.9-gdl1-mysql dépend de libmysqlclient16 (>= 5.1.21-1) ; cependant :
      Le paquet libmysqlclient16 n'est pas installé.
    dpkg : erreur de traitement de sope4.9-gdl1-mysql (--configure) :
     problèmes de dépendances - laissé non configuré
    Paramétrage de libpam-ck-connector (0.4.1-3ubuntu2) ...
    
    
    
    dpkg : des problèmes de dépendances empêchent la configuration de sogo :
     sogo dépend de sope4.9-db-connector ; cependant :
      Le paquet sope4.9-db-connector n'est pas installé.
      Le paquet sope4.9-gdl1-mysql qui fournit sope4.9-db-connector n'est pas encore configuré.
    dpkg : erreur de traitement de sogo (--configure) :
     problèmes de dépendances - laissé non configuré

• Les solutions préconisées par Ludovic (Inverse), qui avait déjà expérimenté ses soucis

  • Corriger le bug (https://bugs.launchpad.net/ubuntu/+source/mysql-cluster-7.0/+bug/574367)
    
    cd /tmp
    aptitude download libmysqlclient16
    aptitude download mysql-cluster-server-5.1
    dpkg --install --force-all ./libmysqlclient16*.deb
    apt-get install sogo
    dpkg -r mysql-server-core-5.1
    dpkg -i mysql-cluster-server-5.1_7.0.9-1ubuntu7_amd64.deb 
    
    Re-executer "apt-get install sogo" pour finir l'isntallation de SOGo. 

n'ont pas réglé le problème.

• Alors, on s'est résolu à poursuivre le reste des configs, et Francis étudiera le soucis plus tard.
• les install sur Tana sont super-lente (problème de débit Internet)
• configuration de sogo (qui été en partie installé) : (/home/sogo/GNUstep/Defaults/.GNUstepDefaults)

• on s'est attardé sur les données/tables à mettre dans le cluster ou à centraliser. Selon les échanges préliminaires il était question, si j'ai bien compris, de partager juste deux tables entre les différents sites SOGo. Mais Francis nous fait comprendre qu'on a aussi besoin que la liste de tous les utilisateurs soit connue de toutes les instances SOGo. Or cette information n'est pas directement dans les 2 tables à partager. Du coup il faut aussi partager/centraliser la table contenant tous les utilisateurs (auf_users) qui doivent partager les agendas et carnets.

La solution retenue est de mettre cette table (dont les données proviennent du système de gestion des adèls via datamaster) dans le cluster de sorte qu'elle soit repliquée sur tous les noeuds.

• dans la même foulée s'est posée la question de l'accès aux serveurs imap. Certains sites utilisent des comptes locaux pour leur imap, et non pas les prenom.nom. Une solution est de créer une vue à partir de la table auf_users en y substituant l'adèl prenom.nom@auf.org par l'adèl local dans le champ mail. Ceci pose tout de même un problème : ce sont ces adèl qui apparaîtront dans le carnet d'adresses. Francis va donc étudier la possibilité d'utiliser un autre champ que le champ mail pour l'authentification imap.

• création de la bd sogo et de ses tables

• Ali s'est occupé de créer une nouvelle synchro datamaster pour le nouveau sogo et a peuplé la table auf_users. Le champ c_name contient le prenom.nom sans le '@auf.org' pour permettre une authentification en prenom.nom tout court

• ajustement de la config sogo/apache

• il faut modifier la synchro datamaster pour que les prenom.nom soient dans le champ c_uid, suivant la config par défaut de SOGo

• retour sur les conflits pour l'installation de SOGo : on fait encore des tentatives de résolutions et finalement Francis y arrive par des --force par-ci et par-là
  • Entre-temps JC nous propose plusieurs solutions :

        (16:36:55) Progfou - VIETNAM: Sinon, pour la solution, il y en a 2 possibles
    (16:37:54) Progfou - VIETNAM: La correcte : faire dire au paquet mysql-cluster qu'il "provides" libmysqlclient16, puisque ça semble être le cas
    (16:39:51) Progfou - VIETNAM: Et La pas correcte mais qui ira plus vite et marchera : faire un paquet Debian quelconque, vide, qui déclare fournir libmysqlcmient16, pour que sope voit ses dépendances résolues et s'installe sans broncher
    (16:41:08) Progfou - VIETNAM: Autre possibilité correcte aussi : modifier le paquet sope-gdl... Pour dépendre de libmysql16 | mysql-cluster...
    (16:41:51) Progfou - VIETNAM: Et il me semble que ce paquet sope vient de Inverse, non ? Donc facile a résoudre dans ce xas
    (16:42:30) Progfou - VIETNAM: (désolé pour toutes les fautes : je suis sur l'iPhone...)
    (16:43:38) Progfou - VIETNAM: Modifier les depends/provides/... = modifier le debian/control qui se trouve dans le fichier .deb
    (16:44:52) Progfou - VIETNAM: Ça se fait en principe a la source + rebuild de .deb (méthode correcte) mais ca peut aussi se bidouiller a l'arrache en éditant directement le .deb
    (16:45:11) NM: Francis me dit que c'est faisable
    (16:45:27) NM: et qu'il va s'en occuper

  • Francis va donc s'occuper de modifier le paquet sope tel que suggéré par JC.

• on peut y aller : http://test.sogo.ca.auf.org/SOGo (en prenom.nom@auf.org)

• Début de paramétrage des extensions sogo, notamment sogo-integrator
• création des accès ssh pour Francis sur les serveurs de Montréal et Tana.
• 16h50 : arrêt des travaux
• pour la suite :
  • les points restés en suspens plus haut
  • finaliser la mise en place du cluster
  • configurer le serveur de Tana
  • configurer le serveur de Paris (équipe AUF)
  • finaliser les extensions
  • mettre en place ssl sur apache
  • installer Funambol

Jour 2 : jeudi 07 avril 2011

Pour la journée d'aujourd'hui, Francis a essentiellement travaillé de son côté ; les choses sont bien résumée dans les échanges ci-dessous :

• "le 2011-04-07 15:25, Francis Lachapelle a écrit :
  
  >>On 2011-04-07, at 3:13 PM, Moussa NOMBRE wrote:
  > > Juste pour savoir où tu en es, sur quoi tu bosses et surtout si on pourra poursuivre.
  > > Pour ne pas répeter ce que disait mon patron hier "... sans vous mettre la pression, on est très attendu sur ce projet ..." > ;-)
  > > Et là quand on me demande où en êtes vous, je ne sais même pas quoi répondre.
  > Je fais des tests et j'ajuste la configuration pour le moment.
  Okay
  > Je ne pourrais pas coincer les modifications requises pour vous pour la version 1.3.6. Ça devra attendre à la version 1.3.7. Entretemps, je vais vous installer un nightly. Côté changements, je pense principalement à la possibilité de faire l'authentification IMAP avec un champs spécifique ainsi que le problème d'authentification limitée par site (seuls certains comptes peuvent s'authentifier pour chacun des sites).
  Si j'ai bien compris, tu feras les modifs directement sur nos serveurs et elles seront par la suite intégrée à la 1.3.7 ?
  
  Avez-vous pu travailler sur le paquet sope-gdl-mysql pour la résolution du conflit ?
  > Donc je corrige quelques trucs dans la config
  Ouaih, j'aurais préféré suivre ces config en screen avec toi (tel qu'on en avais discuté) ; n'oublies pas que notre objectifs est quand même de pouvoir dupliquer le système dans d'autres implantations, dont notamment Paris où c'est pressant.
  > et je te laisse jouer ensuite avec le système pour que tu puisses le tester à ton tour.
  C'est justement la partie qui me concerne moins, nos utilisateurs s'en occuperons mieux que moi.
  
  Places moi quand même un mail pour me dire à quel stade t'es rendu et ce qui reste à faire (sur les deux sites).
  "

• Néanmoins, on peut déjà commencer à s'amuser sur le site de Montréal avec le plugin suivant http://test.sogo.ca.auf.org/plugins/sogo-integrator-3.105-auf.xpi. J'ai du faire des manip pour virer les références à l'ancien SOGo dans mon TB (effacer des lignes dans prefs.js).

• J'ai aussi travaillé sur le serveur de Paris, notamment en finalisant l'installation des paquets (après avoir modifier le parqet bloquant tel que suggéré par JC), en important et adaptant la config sogo et en important les tables sogo. Par contre, une histoire de bean-counters m'a empêché d'aller plus loin. Notez que ces travaux ont été effectués dans l'après-midi (j'étais absent une bonne partie de la matinée), du coup je n'ai pas pu travailler avec Alex. Chose que nous ferons certainement demain.

Pour la suite :

• Alex,faudra :
  1- ouvrir les ports :
  - 3306 : entre ton serveur et les deux sogo de Montréal (199.84.140.4 et 199.84.140.9) dans les deux sens
  - 1186 : entre ton serveur et le cluster manager (199.84.140.9) dans les deux sens
  2- créer test.sogo.fr.auf.org dans votre dns
  3- augmenter les beans du CT
  
  Niry : créer test.sogo.mg.auf.org

Jour 3 : vendredi 08 avril 2011

• > Pour sogo-tana, je vois que tu as encore les soucis avec les dépendances ; j'ai modifié le paquet tel que suggéré par JC et l'installation sur le serveur de Paris s'est bien passé.
  > Je vais donc faire l'installation du paquet modifié sur le sogo-tana ; en attendant que vous modifiez le paquet officiel (sur votre dépôt).
  
  Excellent, merci. Après discussion avec Wolfgang, nous ne pouvons pas facilement modifier les dépendances du package. L'outil que nous utilisons pour construire les packages découvre automatiquement les dépendances de chaque package. Nous avons donc sorti SOPE 1.3.6 sans correctif pour le package d'Ubuntu. On devrait plutôt encourager Ubuntu à corriger leurs packages. Entretemps, utilisons le package SOPE patché de JC.
  
  Voici donc où nous en sommes :
  
   - MySQL (ndb + ndb-mgm) installé à Montréal
   - MySQL (ndb) installé au Madagascar
   - SOGo installé et configuré à Montréal
   - extensions Thunderbird prêtes à Montréal

Ce qu'il reste à faire :

•  - activer la réplication MySQL entre les deux sites
   - installer SOGo au Madagascar
   - modifier SOGo afin qu'il supporte l'authentification IMAP avec comme identifiant un champs spécifique (pour Madagascar)
   - modifier SOGo afin qu'il supporte une contrainte d'authentification (pour limiter les usagers à un seul site)
   - préparer les extensions Thunderbird pour Madagascar
   - compléter l'installation de Funambol à Montréal
   - installer Funambol au Madagascar
   - tester Lightning sous Ubuntu
  
  De votre côté, serait-il possible d'ouvrir le port 3306 sur chaque serveur puisque le port 1186 ne semble pas suffire. De plus, ça serait bien si vous pouviez installer votre package patché de SOPE sur le serveur de Montréal afin qu'on passe à 1.3.6.
  
  Concernant la personnalisation de la page de login, j'ai créé une copie du template original vers /home/sogo/GNUstep/Library/SOGo/Templates/MainUI/SOGoRootPage.wox sur le serveur de Montréal. Il s'agit de le modifier à votre guise sans toutefois toucher aux formulaires (<form>, <input>, etc) et balises SOPE (<var:>).

Semaine 2

• Salut,
  
  La semaine a été très pauvre en compte-rendu, pas parce qu'il n'y a rien à dire, mais juste à cause de la tournure des choses.
  Alors que s'est-il passé depuis lundi ?
  
  - depuis la fin de semaine dernière, le SOGo de Montréal est fonctionnel.
  Depuis lundi, nous avons travaillé à la configuration de thunderbird (TB) pour les tests. Les choses ont traîné sur la migration des données de l'ancien SOGo vers le nouveau. L'outils proposé par SOGo (sogo_tool) ne semble pas marcher avec cette ancienne version. Finalement, nous avons procédé de façon "manuelle" : exportation au format ics et importation.
  En plus, il fallait nettoyer le ficher prefs.js pour plus que Tb point sur l'ancien serveur.
  Conclusion : depuis hier, les postes de Victor et de Christine ainsi que le mien sont fonctionnel sur le nouveau serveur avec les extensions SOGo
  Les iphones ont aussi été configurés et sont fonctionnels.
  
  - Funambol est aussi installé à Montréal. J'ai commencé hier la configuration d'un blackberry pour les tests ; ceci est en cours (oui, faut que je m'habitue d'abord à manipuler le BB)
  
  - Pour le reste (Madagascar, cluster) :
  > le 2011-04-12 21:56, Francis Lachapelle a écrit :
  > J'avais l'intention de t'écrire pour te dresser un bref bilan de la situation. Le voici donc :
  >
  > - le serveur de Montréal est entièrement fonctionnel depuis jeudi dernier (incluant les extensions TB)
  > - le serveur Funambol est installé à Montréal depuis hier
  > - le développement de la contrainte d'authentification est en cours
  > - le lien qui relie Montréal au Madagascar est horrible -- on a des pertes de paquets ce qui rend la réplication synchrone impossible
  >
  > Les imprévus qui ralentissent la livraison sont les suivants :
  >
  > - Vous avez des demandes spécifiques qui n'ont pas été évaluées lors de l'analyse et qui nécessitent de coder de nouvelles fonctionnalités (contrainte d'authentification et authentification IMAP variable).
  > - La réplication synchrone ne pourra pas être mis en place avec des liens peu fiables. Nous avons une alternative, soit une réplication asynchrone, mais qui nécessite elle aussi des modifications au code de SOGo. Il faudra donc compter du temps de développement additionnel (principalement pour éliminer une colonne de type "auto-increment").
  A la date d'aujourd'hui, Francis a finalisé :
  
  - développement de la contrainte d'authentification est en cours
  - support de l'authentification IMAP par champs spécifique
  
  
  - Paris : Jeff, de retour de mission, va ouvrir les ports sur le parefeu et augmenter les beans-counters ; suite à quoi, nous pourrons continuer les configurations.
  
  Comme vous le remarquez, le planning prévisionnel se retrouve faussé par l'état d'avancement des travaux. Nous avons pour le moment une semaine de décalage ; je dis "pour le moment" car les configurations ne sont pas encore achevées.
  
  Outre les travaux techniques, Christine est en train de préparer des environnements de communications (liste de discussion, page wiki pour résumer les tests) et un protocole de tests. Tout ceci dans le cadre de la communauté des utilisateurs que Victor compte dynamiser cette année.
  
  Voilou voila.
  
  NM

• Liste de discussion autour des tests : sogo-tests@auf.org

• Wiki de la communauté des utilisateurs, une rubrique sera créer pour consigner les résultats des tests : http://wiki.auf.org/communauteutilisateurs

Point au lundi 9 mai 2011

• * Montréal : SOGo (1.3.7a) installé, fonctionnel et utilisé par l'équipe ARI locale.
    Iphone et BB : ça marche
    Mysql-cluster viré
  
  * Tana : SOGo (1.3.7a) installé et fonctionnel. 1ers tests effectués par Niry la semaine dernière
    Iphone et BB : ça marche
    Mysql-cluster viré
  
  * Paris : SOGo (1.3.7a) installé et fonctionnel. 1ers ests effectués par Jeff, Alex et David
    Iphone : ça marche
    BB : il reste à finaliser l'installation de Funambol
  
  
  Partage inter-implantation : la solution initiale envisagée (mysql-cluster) a été abandonnée au profit d'une solution de synchro inter-base de données.
  JC et moi avons RDV demain pour y travailler (c'est principalement JC qui s'occupe du script de synchro). D'ailleurs, il résume très bien ainsi comment va fonctionner ce script :
  "(17:00:22) Progfou - VIETNAM: le script commence par se connecter en central pour synchroniser sa copie locale de auf_users (slave) avec la version centrale (master)
  (17:01:15) moussa.nombre@auf.org/Buro: ok
  (17:02:07) Progfou - VIETNAM: ensuite il cherche dans ses tables sogo_folder_info et sogo_user_profile les lignes qui correspondent aux comptes de auf_users appartenant aux domaines gérés localement et envoie les données correspondantes (master) vers la base centrale « référentiel SOGo » (slave)
  (17:03:05) Progfou - VIETNAM: et pour finir il récupère les lignes concernant tous les autres comptes non locaux (slave) depuis le « référentiel SOGo » central (master)
  ...
  (17:48:41) Progfou - VIETNAM: donc on pourrait synchroniser tous les comptes, mais seulement les mdp de domaines du site
  (17:48:56) Progfou - VIETNAM: histoire de ne pas populer les mdp de tout le monde sur tous les sites
  "
  
  Il y a une autre question à traiter : l'accès au serveur imap, via l'interface web, pour les implantation ayant des comptes imap du type "pnom@refer.xx" (ou autre).
  La version 1.3.7a apporte une modification qui permet de dire à SOGo d'utiliser un champ d'authentification autre que celui contenant le prenom.nom.
  Il nous faut alors trouver comment intégrer cette information dans la BdD SOGo.
  Nous allons y travailler dans le courant de la semaine.
  Il faut noter que cet accès imap via l'interface web, ne sera fonctionnel que pour les utilisateurs du pays abritant le bureau régional (ex : mg pour le sogo.mg.auf.org), vu qu'on ne peut spécifier qu'un seul serveur imap ; on pourra éventuellement demander une modification dans SOGo pour contourner cette limitation si on le souhaite.
  
  D'autre part, une page wiki et une liste de discussion (sogo-tests@auf.org) ont été mises en place pour recueillir les retours d'expérience des utilisateurs-testeurs de SOGo dont nous même.
  La page est sur une version  wysiwyg de notre cher moinmoin : http://wiki.auf.org/communauteutilisateurs/AgendaSOGo/TestsFonctionnalites.
  
  Lorsque nous auront finalisé (pour cette fin de semaine si tout se passe bien) les derniers éléments mentionnés plus haut, nous pourrons passer à la phase de tests par nos utilisateurs.
  Ceci suppose que nous-même, nous nous ayons suffisamment fait la main pour les aider en cas de besoin. Il nous faut donc continuer et intensifier nos tests pour nous approprier l'outil.