Encore un bug Ganeti

Petite blagou­nette de Ganeti, à cause de la version d’OpenSSH de Debian Stretch.

Adonc, la situa­tion : j’ai récem­ment voulu ajou­ter un nouveau serveur au clus­ter Ganeti de Frama­soft. Et pas moyen pour ganeti de contac­ter le nouveau nœud une fois qu’il y a ajouté sa clé SSH (les commu­ni­ca­tions entre les nœuds passent par SSH).

Tous les serveurs du clus­ter avaient été récem­ment mis à jour vers Debian Stretch, vu que je n’aime pas me traî­ner de vieilles versions des systèmes que je gère, et qu’on profite géné­ra­le­ment de nouvelles règles de sécu­rité.

Et en effet, la version d’OpenSSH de Stretch, la version 7, désac­tive par défaut l’uti­li­sa­tion de clés DSA.

Pour notre malheur, Ganeti utilise des clés DSA pour la commu­ni­ca­tion entre les nœuds du clus­ter. Impos­sible du coup pour Ganeti de se connec­ter au nouveau nœud avec sa clé DSA.

En atten­dant la sortie de Ganeti 2.16 qui devrait permettre de choi­sir le type de clés à employer, on va, pour contour­ner le souci, modi­fier les fichiers /etc/ssh/ssh_config et /etc/ssh/sshd_config pour y ajou­ter :

PubkeyAcceptedKeyTypes=+ssh-dss

Ne me jugez pas, je sais que c’est très sale, mais c’est le seul moyen que j’ai trouvé pour pouvoir conti­nuer à opérer mon clus­ter Ganeti.

EDIT (10 décembre 2017) : La version de Ganeti de Debian 9.3 permet de chan­ger le type des clés SSH de Ganeti ! Vous pouvez, après avoir passé tous les nœuds de votre clus­ter en Debian 9.3, modi­fier le type de clé utilisé avec la commande

gnt-cluster renew-crypto --new-ssh-keys --ssh-key-type=rsa --ssh-key-bits=2048

Allez voir la page de manuel de gnt-cluster, à la section INIT pour voir les options. Vous pouvez utili­ser des clés DSA, RSA et ECDSA.

Crédit : Photo de Santosh Maharjan sur Unsplash

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)).