Envole » Envole-Mutualisé » etherpad

L’installation manuelle des trois plugins ne posent pas particulièrement de problème, par contre, la procédure en posttemplate implique d’autres traitements à la suite desquels le service etherpad ne démarre plus. Il y a un problème avec la version de log4js et peut-être un problème de versions de dépendances de différents composants.

Bonjour Benjamin,

Merci pour ce travail !
Est-ce que le problème vient d'un plugin en particulier ?

Est-ce que le problème pourrait venir de la version d'Etherpad ? 1.8.7 alors que 1.8.18 (et même une toute récente 1.9.0) existe.
Cela pourrait valoir le coup de mettre à jour Etherpad ? et donc node.js
Mais il faudrait s'assurer que la version node.js requise (v12.13.0 ?) tourne bien sur Eole 20.04 / PHP 7.4...

Qu'en pense Arnaud ?

Merci et à bientôt !
Laurent

Pour l’instant, le problème avec la bibliothèque log4js semble pouvoir être réglé avec une montée de la version indiquée en dépendance dans les sources du dépôt. Cela évite d’avoir un conflit au reconfigure et ne semble pas poser de problème.

Par contre, il y a une étape de mise à jour des dépendances qui semble nécessaire malgré ce qui est déjà fait au reconfigure. Ce point reste à éclaircir.

Il me semble que la version de etherpad avait été choisie (et conservée) précisément pour des raisons de compatibilité. Je laisse Arnaud développer sur ce point si nécessaire.

Le problème de mise à jour des dépendances nécessaire après reconfigure est posé par le fait que cette même étape échoue lors du reconfigure (au moins dans l’environnement de test). La commande npm ci pour ep_etherpad-lite tombe ene timeout lorsque exécuté en posttemplate. La même commande aboutit après reconfigure (ou même en postservice).

Il semble y avoir une lenteur dans l’étape de résolution de nom dont npm fait un usage intensif pour localiser les sources des dépendances à télécharger.

En dehors du reconfigure, les requêtes sont prises en charge par samba. Durant l’étape posttemplate, les requêtes DNS sont finalement prises en charge par le serveur renseigné dans la variable adresse_ip_dns.

La différence de temps nécessaire suffit pour que "npm ci", la commande qui est utilisée pour remettre le cœur de l’application etherpad en place, s’interrompe avec une erreur de timeout. À la suite de quoi l’application etherpad n’est pas fonctionnelle.

En supprimant la ligne indiquant le conteneur addc comme destination des requêtes DNS, après la templatisation du fichier resolv.conf et avant l’exécution du script 20-etherpad, l’opération se passe bien et etherpad est fonctionnel.