Ayant bien galéré, voici un petit guide pour mettre à jour un serveur Debian Jessie hébergeant umap vers Debian Stretch.
Commencez à mettre à jour votre Debian de façon classique et redémarrez. C’est après que tout est cassé.
Mise à jour du virtualenv
Vous aviez créé votre virtualenv avec virtualenvwrapper en choisissant python3, mais malheureusement, c’était la version 3.4 et maintenant c’est la 3.5 qui est installée dans Debian. Bah, rien de plus simple : relancez la commande de création de votre virtualenv.
mkvirtualenv umap --python=`which python3`
Par contre, umap n’est toujours pas installé pour python 3.5. Hop, on le réinstalle (à exécuter dans le virtualenv) :
pip install umap-project
C’est tout pour la partie python. Par contre uwsgi plante lamentablement à coup de
could not access file "$libdir/postgis-2.1": No such file or directory
C’est la faute à la version de l’extension postgis de PostgreSQL : la mise à jour a provoqué l’installation de PostgreSQL 9.6, ce qui a provoqué la mise à jour du paquet postgresql-9.4-postgis-2.1 en postgresql-9.6-postgis-2.3.
Réinstallation de postgis pour PostgreSQL 9.4
Malheureusement, il n’y a pas de paquet postgresql-9.4-postgis-2.3 et vous ne pouvez pas réinstaller postgresql-9.4-postgis-2.1.
La solution est de passer par les paquets fournis par les dépôts de PostgreSQL :
echo "deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main" \
| sudo tee /etc/apt/sources.list.d/pgdg.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc \
| sudo apt-key add -
sudo apt update
À ce moment-là, j’ai voulu installer postgresql-9.4-postgis-2.3, mais je me suis retrouvé avec postgresql-9.4-postgis-2.4, donc autant y aller gaiement en mettant à jour postgis pour PostgreSQL 9.6 :
sudo apt install postgresql-9.4-postgis-2.4 postgresql-9.6-postgis-2.4
Connectez-vous à votre base de données PostgreSQL :
su postgres
psql umapdb
Vérifiez la version de postgis que vous indique PostgreSQL :
umapdb=# SELECT name, default_version, installed_version FROM pg_available_extensions WHERE name = 'postgis';
name | default_version | installed_version
---------+-----------------+-------------------
postgis | 2.4.0 | 2.4.0
(1 row)
Et mettez à jour l’extension :
umapdb=# ALTER EXTENSION postgis UPDATE TO "2.4.0";
Avec ça, ça devrait rouler. MAIS ! (bah oui, y a un « mais »)
Mais vous savez que vous avez maintenant deux versions de PostgreSQL sur votre serveur et qu’il vaudrait mieux passer sur la 9.6. J’y ai d’ailleurs consacré un article dernièrement.
EDIT : attention, le problème ci-dessous n’arrivera que si vous avez ajouté l’index search_idx en suivant la recommandation pour une grosse base. Ne modifiez pas les fonctions unaccent et to_tsvector sur votre nouveau cluster si vous n’aviez pas précédemment créé l’index, cela risquerait d’avoir des effets de bords indésirables si jamais vous avez d’autres bases de données que celle d’umap sur votre PostgreSQL.
Problème : un index sur la table leaflet_storage_map empêche la migration, et vous vous retrouverez avec le message
ERROR: functions in index expression must be marked IMMUTABLE
Résolution du problème de l’index
Ce n’est pas compliqué : on va supprimer l’index sur le cluster 9.4 et le recréer une fois la migration vers 9.6 effectuée.
umapdb=# DROP INDEX search_idx;
Hop, on fait la migration en suivant mon tuto (ne supprimez pas tout de suite le cluster 9.4, faut d’abord vérifier que tout fonctionne normalement).
Reconnectons-nous sur la base d’umap, mais cette fois, ce sera sur le cluster 9.6 et tant qu’à faire, vérifions que nous sommes bien connectés sur le bon cluster).
umapdb=# SELECT version();
Il est temps de recréer l’index. Mais un bête
umapdb=# CREATE INDEX search_idx ON leaflet_storage_map USING gin(to_tsvector(unaccent(name)), share_status);
échouera avec le même problème que tout à l’heure. Il faut faire :
umapdb=# ALTER FUNCTION unaccent(text) IMMUTABLE;
umapdb=# ALTER FUNCTION to_tsvector(text) IMMUTABLE;
umapdb=# CREATE INDEX search_idx ON leaflet_storage_map USING gin(to_tsvector(unaccent(name)), share_status);
Et là on est bon ! Redémarrez peut-être uwsgi pour qu’il prenne en compte le changement de cluster, mais je ne suis pas sûr que ce soit nécessaire.
Testez votre umap et si tout est bon, vous pourrez virer votre cluster 9.4 et les paquets associés 🙂
Crédits : image d’illustration by Himesh Kumar Behera on Unsplash