Buster, bucardo, solr, etc.

Les weekends s'enchainent et parfois se ressemblent, mise à jour de serveurs vers Buster, cette fois-ci pour le backoffice et le frontoffice du site de la radio.

Tout ça est du Django plutôt classique, backoffice = panikdb, frontoffice = panikweb mais la disposition est particulière, le backoffice tourne dans une machine virtuelle dans les locaux de la radio, ce qui permet particulièrement d’uploader rapidement les podcasts en local et de les laisser se synchroniser au rythme de la connexion; ça permet aussi d'avoir la phase de traitement (création de versions mp3 et ogg, ajout de métadonnées) exécutée sur un ordi un peu puissant en local (par rapport au site web qui tournait sur un petit Atom jusqu’il y a peu), et de ne pas stocker les versions brutes sur le serveur dédié. Bref, upload local / traitements / rsync réguliers des fichiers audio générés, affaire réglée pour les fichiers statiques.

Pour la partie base de données, c’était il y a des années déjà, les méthodes de réplication PostgreSQL étaient ce qu’elles étaient et j’avais mis en place bucardo (« an asynchronous PostgreSQL replication system, allowing for both multi-master and multi-slave operations »), ça utilise des procédures stockées en PL/Perl, ça rend l’affaire assez baroque, il y a parfois des glitchs, ça ne reprend pas toujours très bien après une perte de connexion, mais en vivant/contournant ça, ça rend plutôt très bien service. Aussi, ça permet un contrôle assez fin des tables synchronisées, ça permet sans effort de laisser des tables non-synchronisées, pour utilisation exclusive côté serveur (les abonnés newsletter).

À côté de ça, pour la recherche, ça tourne Solr, qui a notamment une fonction « more like this » tout à fait adaptée pour proposer des suggestions d’émissions, ce qui permet de donner une visibilité à un contenu autrement la perd trop rapidement vu le rangement chronologique et l’arrivée continue de nouveautés.

Bucardo et Solr, parce que je les utilise seulement dans ces projets et que les technos derrière ne sont pas mon quotidien, étaient mes deux craintes pour cette mise à jour.

Mise à jour lancée sur la pointe des pieds, pour diminuer le downtime, genre des apt install bien ciblés, pour commencer par les essentiels du système (apt, dpkg, openssh…) puis morceau par morceau m’atteler au reste, avec comme premier gros morceau PostgreSQL et là la bourde d’oublier postgresql-plperl-11 dans les paquets à installer, résultat une première mise à jour de la base de données qui annonce être ok mais a affiché suffisamment de messages d’erreur pour que je n'en croie rien. Retour en arrière, installation du paquet manquant, nouvelle exécution de la mise à jour, là plus de message d’erreurs mais pas de redémarrage pour autant, et comme il ne pense pas avoir réussi sa mise à jour il laisse un port différent de 5432 dans la configuration de postgresql 11, ce que je ne vois pas tout de suite, mais en reprenant les quelques problèmes un par un, bucardo a une procédure de mise à jour à suivre (bien annoncée dans les messages d’erreur), il reste une vieille affaire d’IPv6 à corriger à la radio et désactiver les tentatives de PostgreSQL d’écouter en IPv6 est nécessaire, la version n’a pas été marquée pour redémarrage automatique (vu la mise à jour automatique en échec), et quelques autres et finalement ça passe.

Mise à jour continuée avec Solr donc, apt install jetty9 libsolr-java solr-common solr-jetty et ça démarre mais ne trouve pas solr, trace qui indique qu’il manque un fichier, apt install libwoodstox-java et ça passe (le genre de truc qui aurait dû être détecté, dépendance correcte ajoutée, mais vraisemblablement les paquets sont arrivés en même temps dans la distribution, et pas tellement utilisés, ce qui a fait que cette dépendance n’a pas été notée).

Et là, ça semble tien tourner, jusqu’au moment où un job de mise à jour de l’index échoue, message inintelligible, lecture des logs,

jetty9[660]: GRAVE: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/srv/panikdb/solr/data/index/write.lock: java.io.FileNotFoundException: /srv/www.radiopanik.org/solr/data/index/write.lock (Système de fichiers accessible en lecture seulement)

Vérification et non le système de fichiers n’est pas en lecture seule. Là je pense à AppArmor qui est une nouveauté de Buster mais non, ça demanderait à être activé. Quelques fausses pistes et vérifications et j'arrive enfin à /etc/system/jetty9.service.d/solr-permissions.conf qui définit

[Service]
ReadWritePaths=/var/lib/solr/

et voilà, il suffit d’ajouter mon chemin particulier et l’affaire est corrigée. (et ça se fait en ajoutant une ligne ReadWritePaths=... supplémentaire, pas en ajoutant le chemin à la ligne existante).

Suite de la mise à jour, juste une petite foirade sur quelques paquets Java entre lesquels ont été déplacés des fichiers et qui n’ont rien déclaré à ce sujet, rien de méchant apt -f install pour reprendre et ça passe.

En bilan quelques imprévus mais sur les zones où je m'y attendais, et rien qui me pousse à regarder à remplacer bucardo ou solr, qui font quand même leur job parfaitement toute l’année.