Sur un puppet master 6.X, je crée un nouvel environnement en reprenant la structure d'un environnement qui fonctionne sur un puppet master 5.X. Il fonctionne. Jusqu'à ce que j'essaye d'inclure un module depuis le manifest principal. L'agent puppet 5.5.X me retourne alors l'erreur suivante :

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Unacceptable location. The name '<NOM_MODULE>' is unacceptable 
  in file '/etc/puppetlabs/code/environments/<CENSURE>/site/modules/<NOM_MODULE>/manifests/init.pp' (file: /etc/puppetlabs/code/environments/<CENSURE>/site/modules/<NOM_MODULE>/manifests/init.pp, line: 3, column: 1) on node <CENSURE>

L'écrasante majorité des résultats d'une recherche web pointent sur un renforcement de la convention de nommage des fichiers et classes Puppet. La version 6.X ne laisse plus passer les écarts.

Je vérifie plusieurs fois : je respecte la convention de nommage imposée par Puppet.

En effet, voici mon arborescence :

/etc/puppetlabs/code/environments/envi
                                    - modules
                                    - manifests
                                        - site.pp
                                    - site
                                        - modules
                                            - modu
                                                - manifests
                                                      - init.pp (qui contient la classe « modu »)
                                        - profils
                                            - manifests
                                                - pro.pp (qui contient la classe « profils::pro »)
                                        - roles
                                            - manifests
                                                - ro.pp (qui contient la classe « roles::ro »)

Et mon modulepath (dans environment.conf) : site:site/modules:modules. Ce fichier est bien pris en compte comme nous le montre la commande suivante :

$ puppet config print modulepath --section server --environment envi
/etc/puppetlabs/code/environments/envi/site:/etc/puppetlabs/code/environments/envi/site/modules:/etc/puppetlabs/code/environments/envi/modules

Ainsi, un « include modu » depuis manifests/site.pp devrait fonctionner. Or, ça génère l'erreur mentionnée au début de ce shaarli.

En revanche, aucun problème avec un « include profils::pro » depuis manifests/site.pp.

Je te passe le debug : l'ordre dans le modulepath est important. Avec une valeur « site:site/modules:modules », Puppet cherche la classe d'abord dans le dossier site. « include profils::pro.pp » fonctionne puisque profils/manifests/pro.pp est bien dans le dossier site. En revanche, « include modu » ne fonctionne pas car, si site/modules/modu/manifests/init.pp existe, on ne peut pas l'inclure avec « include modu » sans outrepasser la convention de nommage. Il est d'autant plus difficile de parvenir à ce constat sur l'invalidité du modulepath puisque le message d'erreur de Puppet indique qu'il a trouvé le module (or, un path sert à trouver quelque chose…)

En changeant la valeur du modulepath pour site/modules:modules:site, cela fonctionne, car le chemin « site/modules » est examiné d'abord et que site/modules/modu/manifests/init.pp existe et respecte la convention de nommage. Dans le cas de « include profils::pro.pp », rien est trouvé dans site/modules, ni dans modules/, donc la recherche se termine dans site/ et cela fonctionne car site/profils/manifests/pro.pp est trouvé.

Cela fonctionne aussi si le modulepath a pour valeur modules:site/modules:site. Ce dernier est d'ailleurs le plus logique : on cherche d'abord dans les modules externes puis dans les modules maison, puis dans les profiles et les rôles maison.

Au taff, on utilisait Jabber. Puis on a migré vers Mattermost (Slack-like libre et auto-hébergeable) il y a 3 ans. Puis vers RocketChat (car API + tout le taff d'intégration avec d'autres outils était déjà fait).

Forcément, le tout-sur-le-web m'emmerde. J'aime bien avoir des usages différents sur des protocoles différents. C'est comme ça qu'a été conçu Internet. Je trouve ça propre et facile à expliquer (sans ça, les Moldus ne font plus la différence entre un webmail, c'est-à-dire une interface de présentation, et un service, l'email dans le cas présent, et ne pigent pas qu'on peut découpler un service d'emails du logiciel pour le consulter, ce qui entretient la centralisation chez quelques acteurs genre Google qui met une icône GMail sur Android). Chaque usage son protocole, car chaque usage a des besoins techniques différents. Ça permet aussi du filtrage applicatif moins invasif (bloquer un port sans lire le contenu de la communication versus lire le contenu pour découvrir un service / usage interdit).

Jabber est fédéré (chaque personne / entité peut avoir son serveur, et les serveurs communiquent entre eux) là où Mattermost / RocketChat est centralisé (tout le monde doit être connecté au même serveur). Dans le cas d'une messagerie instantanée professionnelle, on s'en fiche : il y a un seul serveur pour toute l'entité, chaque employé ne va pas installer son serveur. Idem pour les groupes de discussions inter-entités / inter-professions : pour simplifier la vie de tout le monde, tous les salons de discussion seront sur le même serveur, généralement maintenu par une association / consortium inter-pro. Que ce serveur soit un RocketChat ou un ejabberd change rien.

Mais je dois avouer que Jabber a perdu la bataille de la simplicité d'utilisation.

Rien à installer (sauf un navigateur web) pour Mattermost / RocketChat versus un client à trouver / installer pour Jabber (il y a 5-6 ans, j'avais cherché une interface web simple d'administration et d'utilisation, laisse tomber…). Au début, je pensais que, dans une société où on veut tout, tout de suite, forcément, la recherche d'un client ça passe mal, mais, au final, le quidam installe bien un logiciel (une appli, qu'il dit) par usage (banque, bouffe, transport, soin, etc.) sur son smartphone, donc l'argument devrait être nul, mais non…

Les clients Jabber sont capricieux. Gajim qui bouffe parfois 100 % de CPU sans s'arrêter quand tu retrouves ta connexion au réseau. Gajim qui refuse de se connecter sur un serveur Jabber alors qu'il fonctionne sur un autre ordinateur avec le même compte Jabber. Pidgin qui galère sur l'authentification lors de l'ajout d'un compte. Salons parfois pas persistants dans le roster (liste des contacts+salons) avec Gajim, etc. J'ai jamais eu d'emmerdes avec Mattermost (auth via GitLab). Quelques personnes (dont moi) ont eu des problèmes d'authentification sur notre RocketChat (plugin SAML) lors de la première connexion sans qu'on sache WTF.

XMPP, le protocole derrière Jabber, est extensible donc chaque client implémente ce qu'il veut et présente les choses comme il veut. Il y a donc des comportements différents. Les smileys qui, par leur apparence, n'exprime pas exactement la même émotion entre deux clients Jabber. Tel participant a le plugin Gajim qui télécharge automatiquement une image (l'humour est de plus en plus visuel / mème), pas un autre. Récupération automatique du titre d'une page web à partir d'un lien (ce qui est également un vecteur d'attaque…) ou non. Bref, avec Jabber, tous les participants ne voient pas forcément la même causerie. Ce n'est pas le cas avec Mattermost / RocketChat. Notons que, dans une société commerciale, on peut imposer un client Jabber unique, ce qui nuance la portée de ce point, mais c'est encore du taff pour le service informatique (comparer les clients, trouver celui qui répondra à la majorité des besoins, identifier la configuration standard pour l'entité, etc.).

Niveau ergonomie, Mattermost et RocketChat plient le game. En plus de ce que j'ai écrit avant, chaque action possible sur un message (citer, corriger, supprimer) est disponible dans un menu. Les mêmes fonctionnalités avec Jabber dépendent du client (la correction d'un message consiste à ré-émettre le message, c'est donc au client de capter qu'il s'agit d'un message modifié, et il apparaît en double dans l'historique). Sans compter qu'avec Gajim, la correction et la citation se font avec des raccourcis clavier (ctrl+up pour correction, ctrl+maj+up pour citation), paie ta facilité d'utilisation.

Une messagerie tout-sur-le-web permet de récupérer l'historique des conversations. Avec ejabberd, il faut installer un module, MAM, sur le serveur et le bon fonctionnement dépend du client. Avec Gajim, il est fréquent que le client A récupère les échanges qui ont eu lieu avec le client B, mais pas l'inverse. Et, des fois, c'est l'inverse : Gajim B récupère l'historique de Gajim A mais plus l'inverse… Redémarrer Gajim ne suffit pas. Il faut parfois aller dans l'historique de chaque contact pour que l'historique manquant soit récupéré. Il y a vraiment un côté très aléatoire. Rien à redire avec Mattermost. Avec RocketChat, la remontée dans l'historique est lente et périlleuse : un léger scrolle et pouf, il charge 3 mois d'historique, ce qui oblige à scroller dans l'autre sens afin de trouver ses petits (sans compter la fonction « aller au message » qui ne fonctionne pas : ça charge l'historique des messages au compte-gouttes durant de longues minutes… sans t'amener au message recherché)… De même, des jours disparaissent de l'historique, tu passes d'un jour à un autre deux jours plus tard / tôt, comme s'il n'y avait pas eu d'échanges au milieu. Il faut alors vider le cache de son navigateur web.

En prolongement du point précédent, on peut évoquer la réception simultanée d'un même message sur tous les appareils connectés avec un même compte. Ça fonctionne de base avec Mattermost et RocketChat. XMPP propose les ressources, les priorités, etc., le client avec la plus haute priorité reçoit le message, si plusieurs clients ont une priorité identique, le serveur XMPP peut envoyer le message à tous les clients (ce que faisait ejabberd en 2011, j'ai pas trouvé plus récent) ou au dernier connecté ou au dernier actif ou autre critère de son choix (RFC 6121). Il y a même une norme interne à XMPP pour pallier cette incertitude : XEP message carbons. Donc, en pratique, la réception d'un même message sur tous les appareils d'un utilisateur ne fonctionne pas avec Jabber (avec ejabberd et Gajim, tantôt un message entrant est envoyé à toutes les ressources, tantôt à la dernière active, à priorité égale).

Mattermost et surtout RocketChat propose des fonctionnalités orientées travail collaboratif / société commerciale comme la classification automatique des personnes en fonction d'un groupe LDAP, l'ajout automatique à un salon en fonction d'un groupe LDAP, une ramification fine des conversations (canal, sous-canal / discussion), etc.