@xv, comme discuté sur irc l'autre jour, j'ai au moins un autre owncloud qui doit subir la même migration. Donc je vais prochainement ansibler une migration de owncloud7 vers nextcloud last, sur db et vhost alternatif, avec une base de tests fonctionnels.

Tu es sur que ça va s'ansibler ? Avec le problème qu'il faut sortir d'un paquet Debian ?

Cela dit, je viens d'ansibler du déploiment de machine et je suis plutôt partant pour le faire ainsi.

Quelques infos en vrac résultants entre autre de ma propre expérience :
- la migration n'est possible qu'à partir de OC 8 vers NC 8 (https://help.nextcloud.com/t/migrating-from-owncloud-to-nextcloud/551)
- il vaut mieux faire les migration mineures par mineures et mettre à jour les applis au fur et à mesure
- on peut s'inspirer de cette procédure : https://lacavernedemanu.fr/articles/migration-d'owncloud-vers-nextcloud-sous-debian

Contacter Isabella, Benj et Elsa pour vérifier l'usage de Owncloud/Nextcloud.

Prévoir une à deux journée en présentiel au local pour la recette.

Etant donné que:

• Il y a 4 utilisateurs actifs, tous permanents de l'April
• Qu'il y a très peu de documents (quelques dizaines de photos, une douzaine de fichiers) et pas de partage de document par lien public
• Que seuls les applications calendrier et contact sont utilisées

Une migration pourrait se faire avec:

• Export des calendriers et contacts
• Import dans un Nextcloud tout neuf
• Création des groupes et des comptes manuellement
• Copie manuelle des fichiers qui doivent l'etre
• Passer le temps qu'il faut avec chaque utilisateur pour s'assurer que les accès aux contacts et calendrier sur la nouvelle valise sont fonctionels

Autrement dit on export/import au lieu de migrer. A ce stade c'est juste une idée, si quelqu'un voit une raison pour laquelle ça ne marcherait pas ou serait beaucoup plus long que la migration, c'est le moment.

C'est pas une mauvaise stratégie. J'ai pas d'avis sur qui d'une migration ou un upgrade est le plus rapide. Dans tous les cas, passer en revue les confs avec l'utilisateur final est un bon plan.

Cette procédure semble le faire bien.

De plus le Owncloud installé est la version 7 alors que les procédures de migration de Nextcloud prennent en charge à partir de la version 8.2 :

(April) root@lamp:~# dpkg -l |grep owncloud
hi  owncloud                       7.0.4+dfsg-4~deb8u4                          all          cloud storage for files, music, contacts, calendars and many more

https://nextcloud.com/migration/
The Nextcloud migration tool
The easiest way to migrate is using our migration tool. This tool supports ownCloud 8.2 to ownCloud 10, migrating to the appropriate Nextcloud release automatically.

La machine lamp a php 7.0. Il faut au minimum php 7.1 (7.2 ou 7.3 recommandés) pour installer Nextcloud. Trois possibilités:

- Installer Nextcloud 16 sur une machine séparée
- Upgrader lamp à 7.3
- Installer Nextcloud 15

Un consensus se dégage pour installer Nextcloud 15 qui est compatible php 7.0.

Sauf que en fait non parce que... lamp fait tourner php5 et non php7. Activer php7 c'est prendre le risque de créer des problèmes dans un nombre indeterminé de services qui en dépendent. Une idée pour avancer ?

Quentin propose:

configurer un php-fpm en php7 et garder du php-apache en php5
un truc genre :

<FilesMatch ".+\.ph(p[3457]?|t|tml)$">
    SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost" 
</FilesMatch>

directement dans le <directory></directory> de nextcloud

si tu installes le paquet php7.0-fpm, suffit de regarder /etc/apache/conf-available/php7.0-fpm.conf et dupliquer son contenu au sein de la conf site-enabled/nextcloud

https://admin.april.org/doku.php?id=sysadm:applications:photos.april.org est une VM qui a une configuration lamp avec php7, isolée en raison d'une vulnérabilité https://agir.april.org/issues/2996

mv /var/www/valise-new.april.org /var/www/valise-new.april.org /var/www/valise-new.april.org.remove-me-december-2019
cd /var/www
wget https://download.nextcloud.com/server/releases/nextcloud-15.0.11.tar.bz2
tar -xvf nextcloud-15.0.11.tar.bz2
mv nextcloud valise-new.april.org
mkdir valise-new.april.org/data
chown -R www-data:www-data valise-new.april.org

apt-get install php7.0-fpm php-curl
a2enmod proxy_fcgi

cat /etc/apache2/sites-available/valise-new.april.org.conf 
<VirtualHost *:80>
        ServerName valise-new.april.org

        DocumentRoot /var/www/valise-new.april.org
        ErrorLog /var/log/apache2/valise.april.org/valise-new.april.org-error.log
        CustomLog /var/log/apache2/valise.april.org/valise-new.april.org-access.log combined-proxy

        <Directory /var/www/valise-new.april.org>
           SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
           <FilesMatch ".+\.ph(p[3457]?|t|tml)$">
                SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost" 
           </FilesMatch>
        </Directory>

    DirectoryIndex index.php

</VirtualHost>

    sudo mysql -u root
    CREATE DATABASE nextcloud_db;
    CREATE USER nextcloud_db IDENTIFIED BY 'xxx';
    GRANT ALL PRIVILEGES ON nextcloud_db.* TO 'nextcloud_db';
    flush privileges;

cd /var/www/valise-new.april.org
php occ maintenance:install --database-host=127.0.0.1 --database "mysql" --database-name "nextcloud_db"  --database-user "nextcloud_db" --database-pass "xxxx" --admin-user "admin" --admin-pass "xxxx" 
chown -R www-data:www-data .
sudo -u www-data php -f occ config:system:set trusted_domains 1 --value valise-new.april.org
sudo -u www-data php -f occ config:system:set trusted_domains 2 --value valise.april.org
sudo -u www-data php occ app:install calendar
sudo -u www-data php occ app:install contacts
sudo -u www-data php occ app:install impersonate
sudo -u www-data php occ config:system:set mail_domain --value=april.org --type string
sudo -u www-data php occ config:system:set mail_from_address --value=noreply --type string
sudo -u www-data php occ config:system:set mail_smtphost --value=127.0.0.1 --type string
sudo -u www-data php occ config:system:set mail_smtpmode --value=php --type string
sudo -u www-data php occ config:system:set mail_smtpport --value=25 --type int

sudo -u www-data php occ group:add 'dotproject'
sudo -u www-data php occ group:add 'CA'
sudo -u www-data php occ group:add 'permanents'
sudo -u www-data php occ user:add -g permanents -g dotproject -g admin madix
sudo -u www-data php occ user:setting madix settings email fcouchet@april.org
sudo -u www-data php occ user:add -g permanents -g dotproject egonnu
sudo -u www-data php occ user:setting egonnu settings email egonnu@april.org
sudo -u www-data php occ user:add -g permanents -g dotproject epottier
sudo -u www-data php occ user:setting epottier settings email epottier@april.org
sudo -u www-data php occ user:add -g permanents -g dotproject ivanni
sudo -u www-data php occ user:setting ivanni settings email ivanni@april.org

En raison du reverse proxy il faut ajouter dans /var/www/valise-new.april.org/config/config.php

  'overwriteprotocol' => 'https',

Pour archive remote.php (caldav endpoint) ne fonctionait pas (erreur 401 not authorized) parce que php7 FPM n'avait pas la variable d'environnement contenant les crédentials. C'est pour cela que SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1 a été ajouté.

La migration des contacts rencontre un obstacle innatendu. Il semble que dans un lointain passé xul-ext-sogo-connector a été installé pour permettre le lien avec valise via carddav

root@damiana:~# apt-cache policy xul-ext-sogo-connector
xul-ext-sogo-connector:
  Installé : (aucun)
  Candidat : 60.0.0+gite2547a3-1~deb9u1
 Table de version :
     60.0.0+gite2547a3-1~deb9u1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
     31.0.3-3 -1
        100 /var/lib/dpkg/status

Mais la fonctionalité "New => Remote address book" n'est pas présente sur la machine damiana. Et il est par ailleurs impossible de savoir comment est configuré le carnet d'addresse Valise. On peut seulement constaté qu'il communique bien avec valise.april.org. Malgré le fait que le package xul-ext-sogo-connector soit supprimé, les fichiers qu'il contient existent toujours. Ils sont d'une version très ancienne comparé à thunderbird mais contribuent peut-être au bon fonctionnement de la synchronisation entre thunderbird et la valise.

root@damiana:~# dpkg -l xul-ext-sogo-connector
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                        Version            Architecture       Description
+++-==========================-==================-==================-=========================================================
rc  xul-ext-sogo-connector     31.0.3-3           all                transforms Icedove / Thunderbird into a full DAV client f
root@damiana:~# ls -l /etc/xul-ext/sogo-connector.js
-rw-r--r-- 1 root root 191 nov.  11  2014 /etc/xul-ext/sogo-connector.js
# dpkg -L xul-ext-sogo-connector
/etc
/etc/xul-ext
/etc/xul-ext/sogo-connector.js

Plutôt que d'élucider ce mystère, on pourrait suivre les instructions de la documentation nextcloud qui fonctionnent bien. On table sur le fait que les deux peuvent coexister le temps de la migration. Il est possible que l'installation du greffon suggéré par Nextcloud casse la synchronisation qui marche magiquement actuellement. Si c'est le cas, on pourra l'utiliser pour avoir accès à l'ancienne valise. La difficulté est de trouver le lien carddav qui correspond car il n'apparait pas sur l'interface web. C'est https://valise.april.org/remote.php/carddav/addressbooks/egonnu/contacts_shared_by_admin/.

Mise à jour plusieurs jours après

En fait la synchronisation ne se fait pas du tout entre Owncloud et le poste ivanni & epottier. La base de contact de ivanni contient 1560 entrées alors que owncloud en contient 1527. La base de contact epottier en contient bien 1527 car il n'y a pas d'ajout. Cette absence de synchronisation est vérifiée avec un test d'ajout de contact sur le poste de epottier et dans Owncloud.

Il faut exporter la base contact de ivanni et la comparer avec celle de Owncloud car elles ont divergé.

J'ai constaté des délais de plusieurs secondes dans la completion d'addresse thunderbird lorsque je rédige un mail. C'est sur un laptop assez puissant et récent, avec environ 3000 addresses dans le Cardbook. Je soupçonne que c'est une lenteur introduite par Cardbook. C'est a tester avec soin avant la bascule sinon c'est juste inexploitable.

Dans un export vCard ou chaque contact est dans un fichier dans un répertoire, pour afficher les doublons de noms:

ls | tr 'A-Z' 'a-z' | sort | uniq -D

Je ne sais pas si c'est pertinent dans ton cas mais il faut penser aussi aux accents et à la ponctuation (Marie thérêse vs marie-Thérese).

Un truc comme slugify fait ça bien ; je ne connais pas d'équivalement en shell. https://docs.djangoproject.com/fr/2.2/ref/utils/#django.utils.text.slugify ; https://docs.djangoproject.com/fr/2.2/_modules/django/utils/text/#slugify

François Poulain a écrit :

Je ne sais pas si c'est pertinent dans ton cas mais il faut penser aussi aux accents et à la ponctuation (Marie thérêse vs marie-Thérese).

Un truc comme slugify fait ça bien ; je ne connais pas d'équivalement en shell. https://docs.djangoproject.com/fr/2.2/ref/utils/#django.utils.text.slugify ; https://docs.djangoproject.com/fr/2.2/_modules/django/utils/text/#slugify

Merci. Je vais laisser les fichiers doublons parce qu'il y en a assez peu. Je me suis seulement interessé à ceux qui présentaient une divergence entre le poste de ivanni et la valise. Et il y en avait un seul.

Isa m'a montré que les notifications de son calendrier sont faites via evolution et non pas thunderbird. Il faut donc aussi synchroniser son evolution.

Apres merge des bases contact de ivanni et de la valise owncloud, il y a 1586 contacts contre 1527, donc environ 60 de plus. Au moment de l'import dans nextcloud de ces 1586 contacts, il y a eu 41 erreurs sur des contacts qui n'ont donc pas été importés. Les logs du serveur ne permettent pas de déterminer quelle entrée vCard est en erreur parce que le numéro de ligne affiché est relatif a l'entrée de la vcard dans un fichier qui en contient 1586.

Il faut faire un script après la bascule pour déterminer quel sont ces contacts et corriger les erreurs.

Sur lamp.april.org, /var/www/valise-new.april.org/data/nextcloud.log contient les erreurs avec l'intégralité de la vCard qui n'a pas pu être importée.

grep 'This resource only supports valid vCard or jCard data' nextcloud.log

Cependant il n'y a pas 41 lignes, seulement 33. Les autres vCard qui ont échoué à l'import sont silencieuses. Il faudrait exporter et comparer pour les identifier.

En exportant les contacts depuis nextcloud, puis en les important dans cardbook thunderbird, puis en les exportant dans un répertoire, on obtient les 41 contacts manquant exactement. Je vais tenter de les importer l'un après l'autre pour identifier les problèmes.

En éditant manuellement les fichiers j'ai pu tous les importer. C'est moi qui avait injecté un bug avec mon script normalize.py, donc ma faute.

La découverte de MRC Compose et de son incompatibilité avec CardBook nous impose de faire machine arriere. C'était bien tenté mais nous n'avons pas vaincu :-)

Après essai, https://addons.thunderbird.net/en-US/thunderbird/addon/tbsync/ et https://github.com/jobisoft/DAV-4-TbSync/wiki/Compatibility-list-(DAV) font parfaitement le job. Poubelle cardbook dont le seul avantage est un redesign de l'UI. Mais c'est pas ce dont on a besoin.

Pour archive il y a un mauvais karman entre Enigmail et TBsync: les envois de mails sont bloqués. Ca se débloque si on disable Enigmail.

• activer cardbook chez isa + importer contacts locaux + export dans directory
• scp -r du directory dans ivanni sur mon laptop
• https://valise.april.org/index.php/apps/contacts/ + export Admin
• activer cardbook chez moi
• charger le fichier Contacts_(admin).vc dans cardbook
• exporter dans repertoire contacts-admin
• sed -i -e '/BDAY:-0001-11-30/d' Contacts_(admin).vcf
• pour contacts-admin + ivanni
  • fromdos *.vcf ; for i in *.vcf ; do tr '\r' ' ' < "$i" > temp ; mv temp "$i" ; done
  • for i in *.vcf ; do grep '^[Nn]' "$i" | grep -qv ':' && echo "$i" ; done # doit ne rien afficher
  • for f in *.vcf ; do echo "$f" ; python3 ../normalize.py "$f" || break ; done
• rm -fr merged ; mkdir merged ; python3 merge.py ivanni contacts-admin merged > /tmp/2

Le contenu du pad pour archive¶

Installation de Nextcloud 15 (compatible php 7.0)

• https://agir.april.org/issues/2795#note-29
• https://agir.april.org/issues/2795#note-31

Synchro d'un calendrier sur Evolution

• Menu New => Calendar
• Nom Isa April
• Check "Use a secure connection"
• URL https://valise-new.april.org/remote.php/dav/calendars
• User: egonnu
• Click "Find Calendar"
• Enter password
• Click the desired calendar
• Check that adding / removing an event is reflected when looking at the calendar via the web interface

Synchro de la base contact sur Evolution

• Cliquer sur "Contacts" en bas a gauche
• Click New => Address book en haut a gauche
• Type CardDAV
• Name April
• URL https://valise-new.april.org/remote.php/dav/addressbooks/users/admin/contacts/
• User: egonnu
• Enter password
• Click the desired address book
• Check that 1527 contacts are imported (less than 1 minute)

Synchro des calendriers et des contacts sur Thunderbird

• Installer https://addons.thunderbird.net/en-US/thunderbird/addon/tbsync/ et https://github.com/jobisoft/DAV-4-TbSync/wiki/Compatibility-list-(DAV)
• Faire le hack pourri https://help.nextcloud.com/t/thunderbird-calendar-contacts-sync-fails-with-http-503/37179/2
• Tools => Add-ons préferences => TBSync
• Account actions => Add new Account => CalDAV & CardDav
• CalDAV https://valise-new.april.org/remote.php/dav/
• CardDAV https://valise-new.april.org/remote.php/dav/addressbooks/users/admin/contacts/
• User ivanni / epottier + password
• Selectionner les calendriers voulus
• Selectionner la base contact
• Demander sync toutes les 5 minutes
• Cliquer sur "Sync now"
• Aller dans les préférences de MRCompose et valider que l'auto-completion cherche dans la valise

Préparation de la nouvelle valise (valise-new)

• Création des groupes identiques à ceux de la valise
• Création des utilisateurs identiques à ceux de la valise
• Mettre chaque utilisateur dans les groupes auquels il appartient
• Demander à chaque utilisateur de vérifier son accès et changer son mot de passe
• importer les calendriers partagés (cf plus bas) + Mi-temps-Fred pour l'historique
• vérifier l'accès aux calendriers depuis thunderbird et evolution
• importer les contacts
• vérifier l'accès aux contacts depuis thunderbird et evolution

Le jour de la migration

• Exporter tous les calendriers partagés * https://valise.april.org/index.php/apps/calendar/ * cliquer sur la fleche download pour tous sauf Calendrier-partagé-April qui apparait deux fois (Quand on les download ce sont exactement les même.)
• Creer les calendriers * Calendrier-partagé-April 837d00 * Elsa-April b3dc6c * Etienne-April ffa200 * Fred-April ed8df2 * Isa-April 9bc8e9 * Mi-temps-Fred ff1e00 * et les partager en écriture avec le groupe permanent. Ca ne reproduit pas exactement le regroupement originel parce que ça ignore le groupe CA et que les calendriers sont crées par chaque utilisateur. Mais en pratique c'est la meme chose)
• Importer les calendriers partagés ( Calendrier-partagé-April ~10 minute, Elsa-April, Etienne-April, Fred-April ~1 minute, Isa-April, Mi-temps-Fred ) * https://valise-new.april.org/index.php/apps/calendar/ * clique "Parametres et importation" * clique Import * choisir le calendrier * choisir le fichier correspondant * en cas d'erreur, recommencer l'import plusieurs fois jusqu'a ce que le total des imports réussis égale le total des entrées ( workaround bug d'import : https://github.com/nextcloud/calendar/issues/871#issuecomment-451455419 )
• Exporter les contacts * https://valise.april.org/index.php/apps/contacts/ * Click sur la roue dentée en bas a gauche * Click la fleche vers le bas sur Contacts admin * sed -i -e '/BDAY:-0001-11-30/d' Contacts_(admin).vcf * après normalize.py et merge.py, vérifier qu'il n'y a pas de fichiers avec un N/n en début de ligne et pas de :
• Importer les contacts * https://valise-new.april.org/index.php/apps/contacts/Tous%20les%20contacts * Click sur la roue dentée en bas a gauche * Click Importer vers * En cas d'erreur regarder dans https://valise-new.april.org/index.php/settings/admin/logging

Pour chaque utilisateur

• Faire l'inventaire des calendriers non partagés
• Exporter les calendriers non partagés depuis valise
• Importer les calendriers non partagés version valise-new
• Désactiver les calendriers non partagés sur valise
• Ajouter les calendriers partagés, vérifier l'accès écriture / lecture
• Ajouter les contacts, vérifier l'accès écriture / lecture

Apres une semaine

• Renommer valise en valise-old
• Faire pointer valise sur valise-new
• Changer les URLs pour chaque utilisateur de valise-new en valise

ivanni

Synchro calendrier via thunderbird ou interface web, calendrier non partagé
    Synchro calendrier via evolution (pour les notifications)
    Synchro contacts: thunderbird mais pas interface web 
    Partage de fichiers (dernier fichier 7 mois)
    evolution => preferences => Agenda & taches => Rappels

epottier

Calendrier, via l'interface web uniquement, calendrier non partagé
    Copie non synchronisée des contacts thunderbird

egonnu

Contacts evolution : contacts propriété, pas d'ajout ou probablement pas
   Calendrier evolution : via Agenda, pas de calendrier pas partagé sur la valise
   Utilisation rare de l'agenda en web
   evolution => preferences => Agenda & taches => Rappels

madix

Utilise l'agenda et les contacts via le web uniquement et encore pas souvent

Apres tentative de synchro des agendas sur la machine eipoca on voit l'erreur mOfflineStorage is null

C'est le bug https://bugzilla.mozilla.org/show_bug.cgi?id=1081504

sur la machine de eipoca, apres avoir supprimé cache.sqlite dans le répertoire calendar-data de thunderbird, on redemarre et eipoca se retrouver avec une bonne vingtaines d'agendas distants surgis de nulle part
signe indéniable que le cache ... cachait qqc de pas net du tout
plein d'espoir nous supprimons tous les agendas distants
et nous demandons à tbsync de faire son travail

On constate sur la machine de ivanni que thunderbird lancé en mode safe ne freeze pas (thunderbird -safe-mode). Donc on va relancer en désactivant toutes les extensions pour voir si ça freeze encore. La bonne nouvelle c'est que les freeze ne viennent pas du nombre de dossiers imap (~3000).

Avec thunderbird sur la machine de ivanni relancé en mode normal (i.e. pas -safe-mode) et en désactivant tout les add ons, il n'y a pas de freeze (expérimentation sur plus de 2h de travail avec des rédactions de mail).

Voir aussi https://discourse.mozilla.org/t/how-to-diagnose-random-freezes/47378 pour une discussion sur le diagnostic des freeze

On constate que les 5 calendriers lightning de ivanni sont programés pour etre mis à jour toutes les 30 minutes. Comme tbsync fait aussi une synchro toutes les 60 minutes, ça fait doublon. Si lightning est a l'origine des freezes (ce qui semble possible vu qu'il y a eu un freeze apres sa reactivation) ca pourrait expliquer les freeze plusieurs fois par heure. Chaque calendrier etant probablement synchronisé a des moments différents et non pas tous en meme temps.

Pour tester cette théorie tout les calendriers ont été configurés pour se mettre à jour manuellement au lieu de toutes les 30 minutes. Et tout les addons ont été remis en place. Si les freezes ne se reproduisent plus, on a peut etre trouvé la source. Si ça se reproduit ça veut dire que cette théorie ne vaut pas grand chose ;-)

J'ai installé lightning et tbsync sur mon laptop (debian bullseye). J'ai ajouté un compte dans tbsync pour synchroniser les calendriers et carnet d'adresses.

J'ai activé la synchronisation pour toutes les ressources disponibles sur le serveur (calendriers et carnet d'adresses). A chaque synchronisation je note que Thunderbird monte à 100% d'utilisation du CPU pendant plusieurs secondes.

Si je désactive la synchronisation pour « Anniversaire des contacts » lors de la synchronisation Thunderbird monte à 30% de CPU max pendant 1 seconde.

A noter que le délai de synchronisation ne semble pas être respecté de manière très précise.

Pour info les tbird de ivanni & epottier sont configurés pour ne pas inclure la synchro des anniversaires. Dans l'hypothèse ou la synchro tbird des calendriers est responsable des freeze, cela voudrait dire que

• elle prend parfois plusieurs secondes (probable)
• une partie du processus de synchro est bloquante (gros bug)

On en saura plus aujourd'hui.

On est sûr qu'il n'y a pas une synchro des anniversaires d'une manière ou d'une autre ?

Est-ce que ce calendar est utile ? En test, on pourrait peut-être le supprimer pour voir l'effet que cela produit.

on pourrait peut-être le supprimer pour voir l'effet que cela produit.

J'ai supprimé ce nouveau calendrier (Anniversaires) dont personne ne dépend encore et qui pose problème. Pour ivanni, epottier et egonnu. Mais pas pour madix. Il suffit d'aller sur l'interface web et de cliquer sur les trois petit points a coté du calendrier, puis choisir Supprimer.

Une source de problèmes potentiels en moins, c'est plutôt une bonne idée :-)

J'ai mis en place une collecte de données système sur damiana avec sar (je ne sais plus quelle précision il permet, par exemple sur le suivi de l'activité des processus).

• apt install sysstat

• vi /etc/default/sysstat (pour modifier false en true)

• vi /etc/cron.d/sysstat (pour avoir une collecte toutes les minutes)

• service sysstat restart

pour en savoir plus : man sar.

La commande sar -A est un bon début.

Le paquet owncloud a été désinstallé de lamp après la mise à jour de lamp en buster (conflit curl pour php-fpm 7.3), cf https://agir.april.org/issues/3947#note-4

valise-old ayant été arreté de façon permanente, la migration est terminée. Pour récupérer ce qui reste éventuellement dans l'ancienne valise il faudra faire un travail d'archéologie. Je ne sais pas exactement comme il faudrait procéder et ça devrait faire l'objet d'un autre ticket.

Sur le poste de ivanni toutes les extensions sont activées, tout les agendas sont en mise à jour manuelle et tbsync se met a jour toutes les 60 minutes. Attention, il semble que certains agendas reviennent spontanément à une mise à jour toutes les 30 minutes.

Après une journée sur le poste de ivanni avec tous les addons activés et tous les agendas synchro manuellement et tbsync qui se lance toutes les 60 minutes, il y a toujours des freeze occasionels. Parfois plusieurs dans la même heure. Il faut donc revenir a l'étape 2:

• etape 0: thunderbird -safe-mode => pas de freeze
• etape 1: thunderbird aucun addon activé => pas de freeze
• etape 2: thunderbird addons activés: thunderbird => ???

Ajourd'hui un freeze par heure exactement. Pas d'incide de surcharge système selon sar:

# sar 1 300000
                CPU     %user     %nice   %system   %iowait    %steal     %idle
17:48:00        all      0,77      0,00      0,51      0,00      0,00     98,71
17:48:01        all      0,51      0,00      0,77      0,26      0,00     98,46
17:48:02        all      0,77      0,00      0,51      0,00      0,00     98,72
17:48:03        all      1,26      0,00      1,26      0,25      0,00     97,22
17:48:04        all      1,50      0,00      0,75      0,25      0,00     97,49
17:48:05        all      1,50      0,00      0,75      0,75      0,00     96,99
17:48:06        all      0,76      0,00      0,76      0,00      0,00     98,49
17:48:07        all      1,75      0,00      0,50      0,50      0,00     97,24
17:48:08        all      1,50      0,00      1,00      0,75      0,00     96,75
17:48:09        all      2,53      0,00      1,27      1,01      0,00     95,19
17:48:10        all      8,08      0,00      0,51      0,25      0,00     91,16
17:48:11        all     13,38      0,00      2,02      0,76      0,00     83,84
17:48:12        all     20,85      0,00      1,51      0,25      0,00     77,39
17:48:13        all      4,30      0,00      1,27      0,76      0,00     93,67
17:48:14        all      4,80      0,00      0,76      0,25      0,00     94,19
17:48:15        all     14,43      0,25      6,47      0,00      0,00     78,86
17:48:16        all     24,94      0,00      1,48      0,25      0,00     73,33
17:48:17        all     24,50      0,00      1,25      0,00      0,00     74,25
17:48:18        all     25,54      0,00      4,82      0,00      0,00     69,64
17:48:19        all     27,23      0,00      4,34      0,72      0,00     67,71
17:48:20        all     26,06      0,00      5,40      0,47      0,00     68,08
17:48:21        all     25,00      0,00      2,00      0,50      0,00     72,50
17:48:22        all     26,12      0,00      1,00      0,50      0,00     72,39
17:48:23        all     24,63      0,00      2,49      0,75      0,00     72,14
17:48:24        all     27,23      0,00      1,49      0,74      0,00     70,54
17:48:25        all     26,14      0,00      3,84      0,48      0,00     69,54
17:48:26        all     26,49      0,00      0,99      0,50      0,00     72,03
17:48:27        all     23,50      0,00      2,75      0,00      0,00     73,75
17:48:28        all     25,37      0,00      1,00      0,50      0,00     73,13
17:48:29        all     25,31      0,00      0,99      0,25      0,00     73,45
17:48:30        all     25,62      0,25      0,50      0,75      0,00     72,89
17:48:31        all     25,81      0,00      0,99      0,25      0,00     72,95
17:48:32        all     36,07      0,00      1,74      0,75      0,00     61,44
17:48:33        all     25,69      0,00      0,50      0,25      0,00     73,57
17:48:34        all     26,24      0,00      0,99      0,74      0,00     72,03
17:48:35        all     26,33      0,00      3,14      2,17      0,00     68,36
17:48:36        all     16,83      0,00      2,40      1,44      0,00     79,33
17:48:37        all     13,94      0,00      1,96      0,73      0,00     83,37
17:48:38        all      6,40      0,00      4,03      0,95      0,00     88,63
17:48:39        all     10,80      0,00      1,01      0,25      0,00     87,94
17:48:40        all      4,66      0,00      1,23      0,74      0,00     93,38
17:48:41        all      9,22      0,00      2,13      0,71      0,00     87,94
17:48:42        all     12,35      0,00      4,28      1,43      0,00     81,95
17:48:43        all     12,65      0,00      1,70      0,49      0,00     85,16
17:48:44        all     13,13      0,00      1,91      0,95      0,00     84,01
17:48:45        all     10,21      0,00      3,33      1,66      0,00     84,80
17:48:46        all      9,91      0,00      3,77      0,71      0,00     85,61
17:48:47        all     10,53      0,00      3,35      2,39      0,00     83,73
17:48:48        all      4,91      0,00      0,98      0,25      0,00     93,86
17:48:49        all     12,29      0,00      2,65      0,72      0,00     84,34
17:48:50        all     17,40      0,00      2,45      1,47      0,00     78,68
17:48:51        all     23,94      0,00      0,75      0,25      0,00     75,06
17:48:52        all     15,54      0,00      1,50      0,25      0,00     82,71
17:48:53        all     21,61      0,00      1,51      0,25      0,00     76,63
17:48:54        all      0,50      0,00      0,00      0,00      0,00     99,50
17:48:55        all     11,28      0,00      1,00      0,00      0,00     87,72
17:48:56        all     10,60      0,00      1,45      1,69      0,00     86,27
17:48:57        all     11,06      0,00      2,64      0,48      0,00     85,82
17:48:58        all      8,25      0,00      2,67      0,73      0,00     88,35
17:48:59        all     12,29      0,00      2,60      4,49      0,00     80,61
17:49:00        all      6,39      0,00      1,47      0,98      0,00     91,15
17:49:01        all     15,71      0,00      2,49      1,50      0,00     80,30
17:49:02        all      5,29      0,00      1,68      0,48      0,00     92,55
17:49:03        all      8,87      0,00      2,22      0,49      0,00     88,42
17:49:04        all      9,88      0,00      1,98      1,73      0,00     86,42
17:49:05        all     17,20      0,00      1,72      0,98      0,00     80,10
17:49:06        all      6,11      0,24      1,47      0,49      0,00     91,69
17:49:07        all     22,53      0,00      1,77      1,77      0,00     73,92
17:49:08        all     31,41      0,00      2,51      1,01      0,00     65,08
17:49:09        all     12,06      0,00      1,76      2,01      0,00     84,17
17:49:10        all     17,41      0,00      4,23      2,24      0,00     76,12
17:49:11        all     54,55      0,00      5,56      2,02      0,00     37,88
17:49:12        all     38,54      0,00      3,02      0,25      0,00     58,19
17:49:13        all     27,75      0,00      1,00      1,00      0,00     70,25
17:49:14        all     26,01      0,00      3,03      0,25      0,00     70,71
17:49:15        all     34,59      0,00      1,75      0,50      0,00     63,16
17:49:16        all      1,49      0,00      1,24      0,75      0,00     96,52
17:49:17        all     11,25      0,00      2,00      1,50      0,00     85,25
17:49:18        all     22,47      0,00      2,78      1,01      0,00     73,74

Par ailleurs la consomation mémoire est faible (~3GB sur 16GB)

On peut fermer ?
Les conf apache sont ok ?

C'est bon (retour à mod php) et j'ai viré les valise-new partout. Welcome sur valise.april.org :)

Loïc Dachary a écrit :

La découverte de MRC Compose et de son incompatibilité avec CardBook nous impose de faire machine arriere. C'était bien tenté mais nous n'avons pas vaincu :-)

[20200924 sur #april]
(11:16:49) Thom1: avant TB 78, il y avait un champ (To, Cc ou Cci) par adresse. MRC Compose permet d'avoir un seul champ avec toutes les adresses, c'est ça ?
(11:17:20) cioccolisa: c'est ça : un seul champ avec toutes les adresses
(11:17:32) Thom1: depuis TB 78, c'est comme ça par défaut
(11:17:39) Thom1: et cardbook fonctionne avec TB 78