The Daily Shaarli
Deux installateurs viennent présenter leurs « produits » et effectuer l'« installation » chez une mère de famille qui cache son enfant dans la salle de bain (je ne me souviens pas qu'un motif est donné).
J'ai bien aimé cette pièce. On passe de tirades sérieuses à des mini-chants et gestes absurdes.
À partir de maintenant et jusqu'à la fin de ce shaarli, je dévoile des éléments de l'intrigue.
Au début, le jargon politicien et administratif claque : ladite « installation » a été rendue obligatoire par une « directive » du gouvernement dans un « objectif patriotique ». Il faut « collaborer », sinon l'installation peut prendre du temps. Chacun doit y mettre du sien.
On est un peu dans une œuvre de Kafka : que reproche-t-on à cette femme, au peuple dont elle fait partie ? L'installation de quoi ? Elle ne sait pas.
Tout y passe : peur économique (chômage, marchés financiers aux commandes, etc.), peur sociale (les installateurs expliquent que les voisins ont peur, qu'ils rentrent chez eux sans traîner et n'en sortent que pour aller au travail, etc.), peur de l'agression sexuelle et de la menace physique, peur pour son enfant, etc. La peur du terrorisme est évoquée sous forme de boutade ("à qui cela fait-il encore peur ?!"). La pandémie de Covid est effleurée, uniquement pour la comparer à celle des marchés financiers.
La violence du gouvernement est évoquée uniquement à travers les propos des installateurs qui laissent entendre qu'il est omniprésent. Pourquoi ne pas avoir évoqué plus frontalement cette violence (violences policières chez nous, condamnation à mort pour des actes politiques ailleurs, etc.) ? La surveillance par la technologie (caméras, bidules connectées, etc.) est trop peu évoquée. Idem pour la surveillance sociale croisée (tout le monde surveille tout le monde).
La fin est intéressante. L'un des installateurs veut aller aux toilettes et découvre l'enfant dans la salle de bain. La femme le tue, sermonne son collègue, et le tue aussi. Son gamin était la ligne rouge à ne pas franchir. Elle avait accepté tant de peur et de contraintes, mais en échange, on devait laisser son gosse en paix. C'était le deal, peut-être même le contrat social. Au fond, chacun de nous a sa ligne rouge. Dont le piétinement par autrui nous donne le courage pour faire face, pour résister. C'est un joli message d'espoir auquel je crois. J'aimerais que le point de rupture de mes compatriotes soit moins élevé.
Petite incohérence tout de même : au début, le même installateur demande déjà à aller aux toilettes, se fait déjà débouter, et convient avec son collègue (et supérieur hiérarchique) de se soulager "à la camionnette". Pourquoi avoir forcé la salle de bain la deuxième fois ? Savaient-ils ?
Quelques erreurs émises lors du premier démarrage de la version winwin (Windows Server) de Bacula et leur solution.
J’ai rédigé ça dans notre doc’ interne (à l’exception du troisième point), donc autant en faire profiter le plus de personnes possible.
Pourquoi uniquement winwin ? Car, vu la très faible proportion de winwin dans notre parc de serveurs, nous n'avons pas pris la peine de concevoir un modèle du fichier de configuration (template) ni d'automatiser l'installation (Puppet ou script, peu importe). Les erreurs humaines comptent donc pour beaucoup.
Une erreur typiquement winwin-ienne : truc pas initialisé, opération réussie… … …
Il faut (re)démarrer le service « Cliché instantané de volume » depuis services.msc (la console des services, accessible depuis le menu démarrer, « Gestionnaire de serveur », menu « Outils », item « Services »).
À une époque, cette erreur revenait souvent (plusieurs fois par mois), mais plus rien depuis un moment, va comprendre (nope nope nope)…
Message d'erreur entier :
Fatal error: No drive letters found for generating VSS snapshots.
JobId XXXXXX: Error: VSS API failure calling "BackupComplete". ERR=Object is not initialized; called during restore or not called in correct sequence.
Aucun fileset défini dans la configuration du Director pour ce client.
D'après la doc' officielle qui correspond à notre version de Bacula, celui-ci consigne ses erreurs dans le journal « Application » que l'on peut consulter avec l'Observateur d'événements de winwin (accessible depuis le menu démarrer, « Gestionnaire de serveur », menu « Outils »).
Notre doc' interne propose d'aller dans la console des services (services.msc, accessible depuis le menu démarrer, « Gestionnaire de serveur », menu « Outils », item « Services »), d'ouvrir les propriétés du service « Bacula File Backup Service » (« bacula-fd » de son nom court), de copier le chemin d'accès vers l'exécutable et ses arguments, de coller tout ça dans une invite de commande (cmd, que l'on trouve dans le menu démarrer), et d'exécuter la commande.
TL;DR : un serveur rsyslog sur Debian 5 qui ne consigne pas des pans entiers des journaux qu'il reçoit et qui kernel panic de temps en temps. Plusieurs hypothèses possibles. Aucune totalement convaincante. Solution : le remplacer par un serveur rsyslog Debian 11 fraîchement installé.
On avait un serveur syslog. Implémentation rsyslog sur Debian 5. Réception des journaux sur le protocole UDP. Les journaux étaient écrits dans un partage NFS sur notre NAS.
Quand j'en suis devenu l'un des administrateurs, ce serveur était peu utilisé : réception de flux syslog depuis nos deux contrôleurs Wi-Fi Aruba + depuis nos deux routeurs (journal NAT) + depuis notre VPN Cisco ASA. Avant, il recevait également des flux syslog en provenance de nos switchs (quel intérêt ? mon organisation a jamais mis en place de l'AAA) et de nos serveurs Debian 5/6/7 (journal de l'agent Puppet).
On peut donc supposer que ce service fonctionnait convenablement. Notamment parce que mon organisation a déjà eu à répondre à des réquisitions judiciaires (via le journal NAT), à des demandes semblables de la direction, et on relayait à nos utilisateurs les signalements extérieurs concernant leurs pratiques P2P.
Pourtant, depuis que je le connais, ce serveur de journalisation est capricieux. Parfois, il kernel panic. Parfois, il cesse de journaliser. On a donc des trous dans nos journaux (suffisants pour retirer toute pertinence à une recherche). Une recherche dans les journaux (avec grep) était si interminable qu'on les faisait depuis une autre machine qui montait le point de montage NFS. Tellement lent qu'on avait également déplacé les scripts de rangement / tri des journaux sur une autre machine.
Évidemment, on trouvait rien d'évident dans les journaux de la machine. Concernant la perte de bouts de journaux, il suffisait de redémarrer rsyslog et ça repartait temporairement. Évidemment, tcpdump montrait la réception des paquets rsyslog. Évidemment, aucune lenteur de notre NAS à signaler, monter le même partage NFS depuis une autre machine Debian 8 fonctionnait impec.
Afin de valider le bon fonctionnement d'un nouvel équipement qui doit envoyer ses journaux à notre serveur de journalisation, j'ai mis en place un deuxième rsyslog. Debian 5, lui aussi, mais tout propre (hors template). Les problèmes se sont immédiatement manifestés. Il ne s'agit donc pas de crasse accumulée avec le temps, d'erreurs humaines empilées au fil des années, etc.
On peut supposer que notre template Debian 5 contient une conf' vaseuse. Ou que la configuration matérielle de la machine virtuelle n'est pas OK (vu son âge, elle a été migrée d'hyperviseur en hyperviseur). Ou que la version de rsyslog peine à gérer notre faible volumétrie de flux rsyslog (j'y crois pas vu les usages antérieurs sus-mentionnés). Ou que la pile réseau de la machine n'est pas calibrée pour nos flux syslog (paramètres sysctl) ? Ou que l'implémentation NFS dans le noyau Linux est moins résiliente que celle d'aujourd'hui (on a des serveurs web Debian 4 donc peu crédible…). Ou que nos options de montage NFS sont vaseuses (on en a aucune, peut-être faudrait-il bidouiller rsize/wsize afin de forcer Linux à écrire plus ou moins souvent ?).
On a déjà eu des problèmes chelous avec de vieilles machines. Genre celui-ci, avec le suicide de la machine à la clé.
Au final, j'ai préféré monter un serveur rsyslog Debian 11. Ça permet de flinguer une machine Debian 5 qui, par définition, ne devrait plus être en prod' depuis fort longtemps (absence de support éditeur, absence de sécurité, difficultés de cohabitation avec le monde moderne, etc.). L'effort à fournir était négligeable car j'ai déjà écrit un module Puppet pour configurer rsyslog selon notre sauce interne. Le plus long aura été de convertir notre configuration à la nouvelle syntaxe de rsyslog, et de forcer la main au chef ("pas la priorité, blablabla").
Il fonctionne impec depuis plusieurs mois. Parfois, chercher une réponse n'est pas la solution la plus pertinente.
Au final, je ne saurai pas ce qui s'est passé… Les ninjas de l'informatique ne savent pas tout…
TL;DR : dans ce précédent shaarli, j'énonçais qu'un bacula director ou un bacula storage en version 5.X (Debian 8) est incompatible avec un bacula file daemon en version 9.X (Debian 10). Après avoir mis à jour notre infra Bacula, je peux affirmer que l'inverse n'est pas vrai : un director et un storage 9.4 (Debian 10) prennent en charge des file daemon très anciens (1.38.11 sur Debian 4 et 2.4.4 sur Debian 3 !). Néanmoins, bconsole ne fonctionne pas sur un bacula 7.4.4 (Debian 9).
Depuis mon dernier écrit sur le sujet, et afin de solutionner l'incompatibilité entre notre infrastructure Bacula 5.X (Debian 8) et nos nouveaux serveurs Debian 10 et 11 (Bacula 9.X), nous avons mis à jour notre infrastructure Bacula (Director et Storage) en version 9.4.2 sur Debian 10 et nous avons basculé tous nos serveurs dessus.
Cela fonctionne parfaitement, y compris avec des File Daemon très anciens :
Chapeau aux dévs de Bacula pour avoir conçu et maintenu une compatibilité pendant plus de 15 ans ! :O
Une bizarrerie tout de même. bconsole est inutilisable en version 7.4.4 sur un Debian 9. Si l'on tape la commande help, vlam, bconsole se ferme et l'on revient au shell. Idem si l'on tape run puis le numéro d'un des jobs indiqués. Idem avec la commande restore. Bref, t'as compris. Nous n'avons pas ce problème sur un File Daemon de version antérieure genre 5.2.6 sur Debian 7 et 8.
Dans /var/log/syslog d'une machine Debian 9, l'erreur suivante est consignée : « bconsole: bsock.c:569 Packet size=1073742006 too big from "Director daemon:<CENSURE>:9101. Terminating connection. ».
On en revient donc à une incompatibilité entre la version de File Daemon et celle du Director.
Nous n'avons pas cherché plus loin l'origine de ce problème car les sauvegardes sont bien effectuées, et la restauration est fonctionnelle si nous la lançons depuis bconsole sur le Director. Autrement dit : aucune absence de fonctionnalité.
Merci Alex d'avoir monté notre nouvelle infrastructure Bacula. :)
