Archives du mot-clé Jessie

Un bug à l’ex­port de VMs dans Ganeti

Encore un article sur un bug dans Ganeti.

Situa­tion : Debian Jessie, avec Ganeti 2.15.2–1~b­po8+1 prove­nant des back­ports Jessie.

Problème : ça foire quand on veut faire une sauve­garde d’une VM avec gnt-backup export ma_vm. Avec ce genre de message :

Fri Aug 11 12:08:36 2017  - WARNING: import 'import-disk0-2017-08-11_12_08_27-igVAWh' on mynode.mydomain failed: Exited with status 1
Fri Aug 11 12:08:36 2017 snapshot/0 failed to receive data: Exited with status 1 (recent output: socat: E openssl-method="TLSv1": method unknown or not provided by library)

Le bug est déjà connu de Debian et corri­gé… dans la version Stretch ! Pas la version Jessie-back­ports 🙁

Bon, c’est rien de bien méchant. Il suffit d’édi­ter le fichier /etc/ganeti/share/ganeti/impexpd/__init__.py et chan­ger les lignes

SOCAT_OPENSSL_OPTS = ["verify=1", "method=TLSv1",
                      "cipher=%s" % constants.OPENSSL_CIPHERS]

en

SOCAT_OPENSSL_OPTS = ["verify=0", "method=TLS1",
                      "cipher=%s" % constants.OPENSSL_CIPHERS]

Notez la modi­fi­ca­tion de verify et de method.

Et c’est tout bon !

Bien sûr, il vaut mieux passer son serveur en Stretch, mais avec les 70 machines de Frama­soft, j’ai du établir un plan­ning pour tenter de mini­mi­ser le nombre de services à tomber en même temps, du coup je n’y vais à un rythme que de une ou deux machines par jour (ça va, j’en suis à peu près à deux tiers de machines sous Stretch, un tiers sous Jessie et quelques unes encore sous Wheezy (diffi­cile de les upgra­der sans péter les logi­ciels qui sont dessus)).

Me soutenir sur Tipeee Me soutenir sur Liberapay

Mettre à jour un serveur umap vers Debian Stretch

Ayant bien galéré, voici un petit guide pour mettre à jour un serveur Debian Jessie héber­geant umap vers Debian Stretch.

Commen­cez à mettre à jour votre Debian de façon clas­sique et redé­mar­rez. C’est après que tout est cassé.

Mise à jour du virtua­lenv

Vous aviez créé votre virtua­lenv avec virtua­lenv­wrap­per en choi­sis­sant python3, mais malheu­reu­se­ment, c’était la version 3.4 et main­te­nant c’est la 3.5 qui est instal­lée dans Debian. Bah, rien de plus simple : relan­cez la commande de créa­tion de votre virtua­lenv.

mkvirtualenv umap --python=`which python3`

Par contre, umap n’est toujours pas installé pour python 3.5. Hop, on le réins­talle (à exécu­ter dans le virtua­lenv) :

pip install umap-project

C’est tout pour la partie python. Par contre uwsgi plante lamen­ta­ble­ment à coup de

could not access file "$libdir/postgis-2.1": No such file or directory

C’est la faute à la version de l’ex­ten­sion post­gis de Post­greSQL : la mise à jour a provoqué l’ins­tal­la­tion de Post­greSQL 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éins­tal­la­tion de post­gis pour Post­greSQL 9.4

Malheu­reu­se­ment, il n’y a pas de paquet postgresql-9.4-postgis-2.3 et vous ne pouvez pas réins­tal­ler postgresql-9.4-postgis-2.1.

La solu­tion est de passer par les paquets four­nis par les dépôts de Post­greSQL :

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 instal­ler postgresql-9.4-postgis-2.3, mais je me suis retrouvé avec postgresql-9.4-postgis-2.4, donc autant y aller gaie­ment en mettant à jour post­gis pour Post­greSQL 9.6 :

sudo apt install postgresql-9.4-postgis-2.4 postgresql-9.6-postgis-2.4

Connec­tez-vous à votre base de données Post­greSQL :

su postgres
psql umapdb

Véri­fiez la version de post­gis que vous indique Post­greSQL :

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’ex­ten­sion :

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 main­te­nant deux versions de Post­greSQL sur votre serveur et qu’il vaudrait mieux passer sur la 9.6. J’y ai d’ailleurs consa­cré un article derniè­re­ment.

EDIT : atten­tion, le problème ci-dessous n’ar­ri­vera que si vous avez ajouté l’in­dex search_idx en suivant la recom­man­da­tion pour une grosse base. Ne modi­fiez pas les fonc­tions unaccent et to_tsvector sur votre nouveau clus­ter si vous n’aviez pas précé­dem­ment créé l’in­dex, cela risque­rait d’avoir des effets de bords indé­si­rables si jamais vous avez d’autres bases de données que celle d’umap sur votre Post­greSQL.

Problème : un index sur la table leaflet_storage_map empêche la migra­tion, et vous vous retrou­ve­rez avec le message

ERROR: functions in index expression must be marked IMMUTABLE

Réso­lu­tion du problème de l’in­dex

Ce n’est pas compliqué : on va suppri­mer l’in­dex sur le clus­ter 9.4 et le recréer une fois la migra­tion vers 9.6 effec­tuée.

umapdb=# DROP INDEX search_idx;

Hop, on fait la migra­tion en suivant mon tuto (ne suppri­mez pas tout de suite le clus­ter 9.4, faut d’abord véri­fier que tout fonc­tionne norma­le­ment).

Recon­nec­tons-nous sur la base d’umap, mais cette fois, ce sera sur le clus­ter 9.6 et tant qu’à faire, véri­fions que nous sommes bien connec­tés sur le bon clus­ter).

umapdb=# SELECT version();

Il est temps de recréer l’in­dex. 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é­mar­rez peut-être uwsgi pour qu’il prenne en compte le chan­ge­ment de clus­ter, mais je ne suis pas sûr que ce soit néces­saire.

Testez votre umap et si tout est bon, vous pour­rez virer votre clus­ter 9.4 et les paquets asso­ciés 🙂

Crédits : image d’illus­tra­tion by Himesh Kumar Behera on Unsplash

Me soutenir sur Tipeee Me soutenir sur Liberapay