Il était une fois, l’histoire de pacemaker, corosync et pcs…

Pour ceux qui ne connaissent pas cette histoire, un petit résumé s’impose (je dois mettre le mot pcs ici pour le référencement).

En temps normal, cette suite d’outils liée à la haute disponibilité est présente dans les miroirs officiels Debian GNU/Linux. Hélas, pour Debian GNU/Linux Jessie (8.x) ce ne fut pas le cas…

Trois problèmes:

Un problème avec la librairie libqp qui n’a pas été résolu à temps. [1]
Le paquet corosync était plutôt en mauvais état. [2]
L’équipe Debian en charge de la haute disponibilité était quasiment inactive. [3]

Heureusement, même si cela arrive tard, les trois problèmes cités ci-dessus ont été résolus et ces paquets sont désormais disponibles via les backports officiels Debian.

pcs, un oubli malheureux

pcs permet de configurer pacemaker et corosync en ligne de commande sans avoir à éditer le fichier de configuration de corosync ou la CIB (un splendide fichier XML) de pacemaker. Cet outil est souvent comparé à crmsh.

Malheureusement, pcs n’a pas été packagé pour la branche jessie par les mainteneurs Debian.

En route vers un backport \o/

pcs étant packagé dans la branche stretch (testing) de Debian, le backporter pour jessie ne devrait pas être difficile (en théorie).

Presque toutes les dépendances liées à pcs sont disponibles sous jessie, à l’exception du paquet ruby-rpam-ruby19, un second paquet à backporter \o/

La construction de ces deux paquets s’est faite sans douleur, seul problème, pcs ne fonctionne pas. C’est un léger détail me direz-vous, non ?

Ouille, aïe, etc…

Pour faire fonctionner pcs, il m’a fallu résoudre deux problématiques:

Le service pcsd se lançait mais impossible d’authentifier les nœuds entre eux.
Impossible d’utiliser pcsd via un réseau en ipv4.

Ces deux erreurs sont connues, la première est liée au packaging Debian et Ubuntu, il manque une dépendance Ruby: orderedhash ! [4]

Lorsque le service pcsd est lancé via systemd, aucune erreur n’apparait car la commande utilisée pour démarrer le service redirige les erreurs vers le fameux « & > /dev/null » 😛

Par contre, si le service est lancé via la ligne de commande suivante, l’erreur s’affiche:

# /usr/bin/ruby -C/var/lib/pcsd -I/usr/share/pcsd -- /usr/share/pcsd/ssl.rb

1	# /usr/bin/ruby -C/var/lib/pcsd -I/usr/share/pcsd -- /usr/share/pcsd/ssl.rb

Erreur:

ruby[17930]: /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- orderedhash (LoadError)
ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
ruby[17930]: from /usr/lib/ruby/vendor_ruby/backports/std_lib.rb:9:in `require_with_backports'
ruby[17930]: from /usr/share/pcsd/config.rb:2:in `<top (required)>'
ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
ruby[17930]: from /usr/lib/ruby/vendor_ruby/backports/std_lib.rb:9:in `require_with_backports'
ruby[17930]: from /usr/share/pcsd/pcs.rb:12:in `<top (required)>'
ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
ruby[17930]: from /usr/share/pcsd/ssl.rb:7:in `<main>

ruby[17930]: /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- orderedhash (LoadError)

ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'

ruby[17930]: from /usr/lib/ruby/vendor_ruby/backports/std_lib.rb:9:in `require_with_backports'

ruby[17930]: from /usr/share/pcsd/config.rb:2:in `<top (required)>'

ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'

ruby[17930]: from /usr/lib/ruby/vendor_ruby/backports/std_lib.rb:9:in `require_with_backports'

ruby[17930]: from /usr/share/pcsd/pcs.rb:12:in `<top (required)>'

ruby[17930]: from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'

ruby[17930]: from /usr/share/pcsd/ssl.rb:7:in `<main>

Rien de bien dramatique me direz-vous ? Manque de bol, il n’existe pas de paquet ruby-orderedhash sous Debian ou Ubuntu.

La solution la plus simple pour créer ce paquet consiste à utiliser l’outil fpm, ça poutre, c’est bien, mangez-en ! Parce que je suis sympa, je poste la commande (à vous de faire quelques recherches sur cette dernière):

# fpm -n ruby-orderedhash -v 0.0.6 -d "ruby | ruby-interpreter" --deb-priority optional --iteration 1 -s gem -t deb orderedhash

1	# fpm -n ruby-orderedhash -v 0.0.6 -d "ruby \| ruby-interpreter" --deb-priority optional --iteration 1 -s gem -t deb orderedhash

Pour ce qui est de l’erreur liée à l’impossibilité de se connecter à pcsd via un réseau ipv4, cette dernière est bien connue. Il s’agit d’un bout de code à changer dans la librairie Ruby SSL utilisée par pcsd, voici le patch en question [5]:

--- pcs-0.9.149.orig/pcsd/ssl.rb
+++ pcs-0.9.149/pcsd/ssl.rb
@@ -47,8 +47,8 @@ end
 
 webrick_options = {
   :Port               => 2224,
-  :BindAddress        => '::',
-  :Host               => '::',
+  :BindAddress        => nil,
+  :Host               => nil,
   :SSLEnable          => true,
   :SSLVerifyClient    => OpenSSL::SSL::VERIFY_NONE,
   :SSLCertificate     => OpenSSL::X509::Certificate.new(crt),

--- pcs-0.9.149.orig/pcsd/ssl.rb

+++ pcs-0.9.149/pcsd/ssl.rb

@@ -47,8 +47,8 @@ end

webrick_options = {

:Port => 2224,

- :BindAddress => '::',

- :Host => '::',

+ :BindAddress => nil,

+ :Host => nil,

:SSLEnable => true,

:SSLVerifyClient => OpenSSL::SSL::VERIFY_NONE,

:SSLCertificate => OpenSSL::X509::Certificate.new(crt),

Cette modification consiste à « binder » pcsd sur toutes les interfaces, d’un point de vue sécurité ce n’est pas la meilleure façon de faire mais en attendant ça fonctionne.

Ce patch est appliqué au code source de pcsd lors de la construction du paquet. Ce patch a été créé à l’aide de la commande quilt.

Conclusion

Pour conclure, au total trois paquets ont été créés, deux d’entre eux ont été backportés depuis la branche stretch de Debian et le dernier a été créé via fpm (ce dernier va certainement évoluer dans les futures semaines).

Pour accéder à ces trois paquets, il suffit d’ajouter le miroir InCloudUs à votre /etc/apt/sources.list :

deb http://packages.incloudus.com jessie main

1	deb http://packages.incloudus.com jessie main

Puis de signer le miroir en question via la commande apt-key:

# wget http://packages.incloudus.com/incloudus/incloudus.pub -O- | apt-key add -
# apt-get update
# apt-get install pcs

# wget http://packages.incloudus.com/incloudus/incloudus.pub -O- | apt-key add -

# apt-get update

# apt-get install pcs

La commande pcs est désormais disponible sous Debian GNU/Linux Jessie (8.x) et devrait aussi fonctionner sous Ubuntu.

Gaëtan Trellu (goldyfruit)

Cloud Operations Lead chez Ormuco

Autodidacte en informatique, depuis 2005 je parcours l’écosystème Unix à la recherche de nouvelles connaissances et de nouvelles rencontres.

Derniers articles parGaëtan Trellu (goldyfruit) (voir tous)

systemd-networkd, l’âge de la maturité ? - 13 mars 2018
Hyper-V, Nova, VxLAN et Open vSwitch, enfin une belle histoire ! - 31 décembre 2017
iPXE et la fameuse erreur 0x040ee119 qui rend fou ! - 17 avril 2017

Paquet pcs disponible pour Debian Jessie

Il était une fois, l’histoire de pacemaker, corosync et pcs…

pcs, un oubli malheureux

En route vers un backport \o/

Ouille, aïe, etc…

Conclusion

Liens

Gaëtan Trellu (goldyfruit)

Derniers articles parGaëtan Trellu (goldyfruit) (voir tous)

Articles similaires

Il était une fois, l’histoire de pacemaker, corosync et pcs…

pcs, un oubli malheureux

En route vers un backport \o/

Ouille, aïe, etc…

Conclusion

Liens

Gaëtan Trellu (goldyfruit)

Derniers articles parGaëtan Trellu (goldyfruit) (voir tous)

Partager :

Articles similaires