Tiroir Hemera multimode upgrader = faire passer du 10 G monomode (OS1/2) sur des fibres multimodes (OM1).
Cas d'usage : rentabiliser les investissements d'il y a 20 ans (on posait des fibres multimodes) et/ou passer au 10 G dans des environnements contraints (bâtiment protégé, etc.).
Boîtier passif 1U 19 pouces pour 4/8/12 fibres OM1. J'avoue que le côté passif (donc un jeu purement physique / optique) me bluffe.
Distance / portée : < 2 km. Au-delà de 800 m, il faut un boîtier à chaque extrémité des fibres multimodes. En deçà, une épissure entre une fibre multimode et une jarretière monomode suffirait.
Fabricant : Acome. SCOP. Produit fabriqué en France (usine FR, a dit le commercial).
Prix : 6 k€ pour un boîtier 12 fibres. En comparaison, nous avons dépensé 8 k€ TTC pour la pose de 24 fibres optiques monomodes sur 4 segments (soit 8 cassettes + soudures, qui est ce qui coûte le plus cher dans une pose de fibres). Et pour un segment, il y avait des contraintes : bâtiment protégé, absence de faux plafonds, plans des chemins de câbles perdus, etc.
Mon avis : bricolage (le commercial a reconnu, sans que je l'y pousse, qu'une fibre monomode est préférable et que leur produit est un palliatif pour les cas où l'on ne peut pas remplacer de la multi par de la mono d'un claquement de doigts) + pas rentable.
commande1 |& commande2 = commande1 2>&1 | commande2 = redirection de la sortie standard (stdout) et de la sortie des erreurs (stderr) de commande1 sur l'entrée standard (stdin) de commande2.
Pratique quand on utilise des outils de débogage (s_client, strace, etc.) et qu'on ne sait pas sur quelle sortie sera affichée le motif que l'on cherche.
A priori, ce n'est pas POSIX, ça ne fonctionne pas avec tous les shells. En tout cas, ça fonctionne avec bash.
Ma liste réduite d'autorités de certification (AC) répond toujours à mes besoins plus de 21 mois après. :)
Fin mars 2022, j'ai constaté la présence des AC suivantes dans mon Firefox et je les ai également désactivé sans conséquence néfaste à ce jour :
ANF Secure Server Root CA
Certum EC-384 CA
Certum Trusted Root CA
certSIGN Root CA G2
e-commercie monitoring GmbH - globaltrust 2020
FNMT-RCM - AC RAIZ GNMT-RCM SEVIDORES SEGUROS
GlobalSign Root R46
GlobalSign Root E46
Microsec Ltd. - e-Szigno Root CA 2017
Microsoft RSA Root Certificate Authority 2017
Microsoft ECC Root Certificate Authority 2017
Naver Global Root Certification Authority
Trustware Global ECC P256 Certification Authority
Trustware Global ECC P384 Certification Authority
Trustware Global Certification AuthorityLa syntaxe traditionnelle fonctionne toujours avec la version 8 de rsyslog : *.* @<ADRESSE_IP> pour envoyer tous les journaux dans un flux syslog sur udp/514. @@ pour un flux tcp/514. Ajouter :<PORT> pour changer de port.
On peut utiliser des conditions afin de transférer uniquement le journal d'un programme précis. Exemple :
if $programname == 'sudo' then @192.0.2.1
& stop
Et avec la ""nouvelle"" syntaxe ?
if $programname == 'sudo' then {
action(type="omfwd" target="192.0.2.1" protocol="udp" port="514")
stop
}
On notera que la documentation du module omfwd est erronée : les paramètres « protocol » et « port » ne sont pas facultatifs.
Dans un précédent shaarli sur rsyslog, j'ai consigné comment configurer rsyslog pour créer automatiquement une arborescence variable et un nom de journal selon un template genre /var/log/distant/<ANNÉE>/<MOIS>/<JOUR>/bidule/programme.log.
Par défaut, les dossiers créés par rsyslog ont le mode 0700 (0644 pour les fichiers). Ainsi, un compte utilisateur local non-root ne peut pas parcourir l'arborescence de stockage des journaux.
D'après sa documentation, le module omfile de rsyslog propose un paramètre pour configurer le mode des dossiers créés : « dirCreateMode » (« FileCreateMode » pour les fichiers).
Exemple d'utilisation :
template (name="chemin-prog" type="string" string="/var/log/distant/%$year:::%/%$month:::%/%$day:::%/bidule/programme.log")
if $hostname == 'machine1' then {
action(type="omfile" dynaFile="chemin-prog" dirCreateMode="0755")
stop
}
Une autre façon de faire est de créer un groupe d'utilisateurs dédiés à la consultation des journaux, genre « log » et de configurer rsyslog pour attribuer les dossiers créés à ce groupe.
C'est légèrement plus propre car ça évite de donner un accès en lecture seule aux journaux à tous les comptes utilisateurs de la machine. Mais ça suppose toujours de changer le mode avec lequel les dossiers sont créés (0700 = le groupe n'a pas d'accès non plus).
Le plugin omfile de rsyslog propose les paramètres « dirGroup » / « dirGroupNum » (« fileGroup » / « fileGroupNum » pour les fichiers).
Exemple :
template (name="chemin-prog" type="string" string="/var/log/distant/%$year:::%/%$month:::%/%$day:::%/bidule/programme.log")
if $hostname == 'machine1' then {
action(type="omfile" dynaFile="chemin-prog" dirGroup="log" dirCreateMode="0750")
stop
}
Il est également possible de modifier l'utilisateur propriétaire du journal ou de l'arborescence : « fileOwner », « dirOwner », « fileOwnerNum », « dirOwnerNum ».
Évidemment, ces paramètres du plugin omfile peuvent être utilisés même quand on n'utilise pas de template. ;)
Par défaut dans OpenStreetMap (OSM), les noms des villes et des pays sont dans la langue locale dudit pays (russe, arabe, chinois, etc.). Pas même en anglais et encore moins dans la langue du visiteur.
Pour avoir ces noms en français et en écriture latine, on peut consulter des projets tiers qui réutilisent les données d'OSM. Les deux seuls en français à cet instant sont :
Forcément, il y a aussi des inconvénients :
On peut supposer que les autres projets apparaîtront sur la page dédiée à l'internationalisation du wiki officiel.
Source : https://mamot.fr/@klorydryk/108185595944513572 via https://mastodon.gougere.fr/@bortzmeyer.
Résumé : pourquoi j'ai séché la formation à l'habilitation électrique et pourquoi tu devrais en faire autant. Si tu choisis de refuser cette absurdité, sache qu'un pixel sait que ce n'est pas facile et te soutient. :)
Fin 2019, mon employeur nous invite, nous, administrateurs de systèmes et de réseaux informatiques, à passer l'habilitation électrique. Plusieurs chefs de la hiérarchie sonnent le tocsin.
Au final, personne de mon équipe l'a passé. L'enthousiasme de mon chef d'équipe face à mes arguments sur l'absurdité du système de l'habilitation électrique s'est transformé en flemme.
En janvier 2022, c'est obligatoire. Je ne m'attendais pas à ce que ça revienne si vite, mais comme disait ma grand-mère : quand un chef / personne responsable a une idée derrière la tête, ce n'est pas dans le cul !
Pour quelle partie de mon travail l'habilitation est-elle nécessaire ? Personne nous a dit quoi que ce soit. C'est le service machin qui demande, alors on ne pose pas de question, il sait ce qu'il fait, hop, hop, hop.
Pour ré-armer les disjoncteurs de notre salle serveurs ? Au cas où nos serveurs nous enverraient des chocs électriques ? Pour les rares fois où on va insérer un composant (barrette de RAM, contrôleur RAID, etc.) dans un serveur hors tension ?
Je suis en poste depuis 4 ans et demi. Le risque électrique direct et indirect est mentionné dans toutes mes fiches de poste depuis la première.
Pourquoi attendre 4 ans si c'est si important ?! C'est comme la visite médicale obligatoire à laquelle j'ai jamais été convié (chez mon employeur actuel) : le service compétent (RH d'un côté, Sûreté de l'autre) se réveille et ce qui passait à la trappe avant devient urgence vitale turbo priorité plus plus plus… Ce sont des gens responsables, on nous dit.
Je rappelle mes griefs contre cette habilitation :
Les chefs veulent se couvrir. Si l'un d'eux te demande de ré-armer un disjoncteur alors que tu n'es pas habilité, l'employeur engage sa responsabilité en cas de pépin. Après ton habilitation, ça sera la faute de personne. Dilution de la responsabilité. De mémoire, un employeur peut habiliter un sous-fifre sans lui faire passer la formation, mais, là aussi, il engage sa responsabilité en cas de problème. Bref, le but de l'habilitation est de permettre aux chefs de se défausser. Mais ces gens-là se présentent et sont présentés comme des gens res-pon-sa-bles, va comprendre ;
Les formations de deux jours à l'habilitation électrique sont d'une qualité plus que douteuse :
Une amie m'a demandé comment est financée cette daube. Par l'employeur. Il lui faut payer le formateur et les deux jours pas travaillés. Elle m'a demandé pourquoi le MEDEF ne s'y oppose pas, alors, comme il le fait pour tant d'autres « charges » salariales.
L'habilitation électrique est une pompe à fric pour les formateurs en électricité. Formation obligatoire tous les trois ans, imagine. Tu radotes chaque année, rien de neuf. Argent facile !
J'ai refusé de suivre la formation, et, en conséquence, je ne suis pas habilité. Sans conséquence à ce jour.
La décision a été compliqué à prendre. Au début, j'ai envoyé un email au dirlo de mon service pour exposer que je ne suivrai pas cette formation.
Mon chef d'équipe revient vers nous tous pour collecter nos réponses. Je dis que je vais réfléchir, et j'obtiens un jour de réflexion.
À ce moment-là, je suis blasé, frappé par le renoncement et la solitude. Même mes amis les plus têtus, ceux qui refusent de se faire emmerder par de telles conneries, étaient plutôt d'avis que je devais suivre la formation. Partir en guerre pour si peu, est-ce raisonnable ? Glander en formation, n'est-ce pas plus cool que de travailler ? Deux jours en plus, ça vaaaa, c'pas la mort. L'excuse du CDD est-elle vraiment viable alors qu'il a été renouvelé 4 fois ? La profession veut cette habilitation donc, même chez un autre employeur, je serai obligé d'y passer… sauf si la salle serveurs est externalisée ; Or, j'évite de postuler chez de tels employeurs car je trouve que c'est insensé d'un point de vue économique, répartition de la richesse sur un territoire, etc. Bref, c'est chiant et ça va revenir sur le tapis régulièrement, et, à chaque fois, il faudra trouver la force de s'y opposer, réfléchir, etc.
Quelques jours plus tard, je sors de ma léthargie. C'est toujours par de petites concessions, de petits riens, qu'on te fait plier. C'est jamais important, ça vaut jamais la peine de s'énerver ni d'opposer un refus. Et toi, tu regretteras d'avoir accepté, trop bon trop con, qu'ils disent… après coup.
Mais, à l'inverse, personne te demandera jamais de faire un truc très crade d'un coup. C'est progressif. On découpera l'action crade en petits bouts, et chaque intervenant comme toi n'aura que ce bout-là à accomplir. Un tout petit bout, rien de grave, rien d'illégal, rien d'immoral. Petit à petit, tu recomposeras le puzzle, et tu comprendras que le petit rouage que tu étais a participé à des choses peu reluisantes. Ceux qui prétendent que rien est grave et attendent qu'on leur demande une action vraiment crade pour la refuser se trompent : ce moment arrivera jamais, car la société, les mœurs auront changé avant, et l'inacceptable sera devenu acceptable. Et la personne peu entraînée à refuser, l'acceptera par habitude. Bien sûr, j'exagère un peu, mais tu vois l'idée.
Bref, je me suis dit « merde à la fin, je ne veux pas y aller, point ! ».
La veille de la formation, j'ai posé une semaine de congés au motif d'un giga mal de dos (crédible, j'en ai déjà eu un).
Évidemment, ça ne fera pas avancer la cause que je prétends servir puisque ce geste ne dit pas pourquoi j'ai séché cette formation. Mais, je rappelle l'existence de mon email à mon dirlo. Il contient quelques-uns de mes arguments. La prochaine fois, je serai moins lâche. Je me console en me disant que, de toute façon, il n'y a pas plus aveugle que celui qui refuse de voir, et que même le plus complet des argumentaires sert environ à rien (cf réchauffement climatique).
À ce jour, j'ai reçu un email du service RH. M'exposant que j'ai séché et me demandant de justifier mon absence. Je n'ai pas répondu. C'était il y a plus d'un mois.
Mais, en tant que CDD, je sais que le couperet pourrait tomber plus tard.
J'ai qu'une seule envie : que nous soyons plus nombreux à refuser cette absurdité afin qu'elle soit questionnée et amendée.
Je recopie un extrait de mon dernier shaarli sur le sujet :
P.-S. : j'ai rien contre le fait de former aux risques électriques, de développer des automatismes permettant de réagir à un danger électrique, etc., mais ce n'est clairement pas le sujet de l'habilitation électrique qui apprend plutôt la paperasse (se tenir seul à xx cm du tableau électrique, hein !), le dédouanement et la couardise. D'autant qu'elle est obligatoire au travail pour des tâches que tu effectues sans problème chez toi sur des circuits identiques (230 V, 10-20 A, 50 Hz)… On pourrait au moins faire sauter ce premier niveau d'habilitation pour les tâches basiques.
Il y a quelques mois, l'extinction impromptue de l'ampoule a repris. Tout comme la variation de l'intensité lumineuse.
En levant les yeux, je constate que le spot est plus tourné d'un côté que de l'autre. Ben, oui, il y a un axe central. On le voit sur cette photo. Les picots blancs sous les ressorts. Le spot est orientable, comme on le voit ici.
J'utilise le manche d'un balai pour remettre le spot droit : l'ampoule se rallume. Droit = la vitre qui protège l'ampoule (ou l'humain de la chaleur de celle-ci) est parallèle au sol, quoi.
Les jours suivants, le spot change de position et l'ampoule ne s'allume plus. À chaque fois, j'utilise le balai et ça repart. Actuellement, ça tient sans coup d'balai depuis plusieurs semaines. :D
En vrai, je pense qu'il doit y avoir, à nouveau, un faux contact du côté de la douille. Je suppose que bouger le spot dans une certaine position fait pression "comme il faut" sur les fils électriques, ce qui explique que ma méthode sans queue ni tête produit un résultat.
Je crois savoir que l'axe central était bloqué par des languettes en métal (on en voit une ici, en bas, à droite). Je les ai faites tomber lors du premier démontage du spot, fin 2019, et je ne les ai pas remises lors du changement de la douille de mi-2020. Ceci explique aussi cela, je pense. Mais bon, depuis, j'ai jeté lesdites languettes en métal…
Bref, pour l'instant ça chemar, et quand ça ne chemar pas, hop, un p'tit coup de balai et ça repart. :D
Résumé : quand un dégraissant ne parvient plus à vaincre la saleté sèche accumulée sur ta plaque de cuisson durant des mois, utilise un grattoir pour plaque de cuisson vitrocéramique. :D
Depuis que j'ai commencé à cuisiner, j'ai pourri ma plaque de cuisson. Je la nettoyais rarement. Il fallait donc y aller au dégraissant.
Ça fonctionnait, donc je la nettoyais encore plus rarement. À force d'accumulation d'eau salée (qui déborde de la casserole), de soupe (idem), de graisse (qui coule le long de la paroi quand je repose la poêle sur la plaque après avoir déplacé la bouffe cuite dans une assiette ‒ ce qu'il faut éviter de faire, paraît-il, la plaque continuant de dégager de la chaleur alors que la poêle est vide ‒), d'herbes de Provence (apprendre à saupoudrer), etc., le dégraissant n'était plus efficace, même en en aspergeant la plaque plusieurs fois, même en frottant comme un ouf avec le côté grattant d'une éponge. Surtout après avoir laissé tout ça sécher des mois durant. Ça formait un relief sur la plaque, autour des feux. :D
Sauf que cette plaque de cuisson vitrocéramique n'est pas à moi. Un jour, je devrais donc la nettoyer (ou laisser la caution). J'avais également l'impression que ça prenait masse de temps pour faire bouillir de l'eau (on était clairement au-dessus de 10 minutes, peut-être 15, contre 8 minutes en ce moment), et j'attribuais ça au fait qu'il fallait faire chauffer la couche de merde qui délivrait la chaleur à la casserole qui la transmettait à l'eau.
Que faire ? Quand je le questionne, professeur Johndescs m'apprend qu'il existe des grattoirs pour plaque de cuisson. Juste une lame de cutter greffée sur un manche, quoi. Mais la lame étant large, ça réduit le risque de rayer méchamment la plaque avec la pointe de la lame, à condition de bien tenir le grattoir.
J'en trouve un viteuf chez Darty. 10 €. Flemme d'aller en magasin (c'était encore l'époque du port du masque obligatoire dans les transports en commun et dans les galeries marchandes), je l'ai acheté sur le web.
Ça marche vachement bien : avant / après.
On voit masse de rayures, mais elles ne sont pas profondes (je ne les sens pas avec mes doigts, quoi), donc je pense que j'ai fait ça plus avec le côté grattant d'une éponge qu'avec le grattoir.
Ces derniers mois, je parviens à faire l'effort de nettoyer ma plaque à l'éponge après chaque utilisation, mais le grattoir demeure quand même utile car l'éponge n'enlève pas forcément tout (et gratter avec la partie verte / grattante, c'est augmenter le risque de rayures).
TL;DR : l'algorithme ssh-rsa est désactivé dans la version de SSH livrée dans Ubuntu 22.04 car il utilise la fonction cryptographique SHA-1 qui est jugée dangereuse depuis des années.
Enfin, il ne faut pas confondre le format d'une clé SSH (RSA) et l'algorithme utilisé pour vérifier cette clé et signer avec (ssh-rsa = RSA + SHA-1). Ce n'est pas donc les clés RSA qui sont dépréciées par SSH et tu peux conserver la tienne (et celle de ton serveur) sans danger.
Un collègue met à jour sa station de travail à la version 22.04 d'Ubuntu. Il ne parvient plus à se connecter en SSH au serveur depuis lequel nous administrons nos serveurs (je refuse d'utiliser le terme « bastion », car il renvoie l'idée d'un point sécurisé, d'un contrôle d'accès fin, d'une journalisation des accès et des commandes saisies, etc. ce qui n'est pas le cas). L'erreur ? « Unable to negotiate with XXX.XXX.XXX.XXX port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 ».
Ubuntu 21.10 embarquait la version 8.4 d'OpenSSH (l'implémentation la plus répandue du protocole SSH). Ubuntu 22.04 embarque la version 8.9. (Source.) Or, à partir de sa version 8.8, OpenSSH désactive l'algorithme ssh-rsa. ssh-rsa = RSA + SHA-1. Or, ce dernier est considéré comme très faible depuis 2015, comme je l'ai évoqué dans un article sur le renforcement de mes configurations SSH.
Or, on constate que le serveur ne propose pas mieux que ssh-rsa (si l'on reste dans la famille RSA). Il ne propose pas rsa-sha2-256 ni rsa-sha2-512. C'est normal : il s'agit d'un système Debian 8 avec OpenSSH 6.7 ; les nouveaux algorithmes de la famille RSA sont implémentés à partir de la version 7.2 d'OpenSSH.
Tu vas me dire : « le serveur propose d'autres algorithmes, d'autres familles, le client l'annonce dans son message d'erreur, pourquoi ssh ne bascule pas dessus automatiquement ? ».
En effet… Sur un Ubuntu 22.04, c'est l'algorithme ssh-ed25519 qui est choisi car il est pris en charge par le serveur (dernier choix) et qu'il est premier choix du client après les algorithmes qui utilisent des certificats (cf man ssh_config).
Sur un Debian 10, c'est l'algorithme ecdsa-sha2-nistp256 qui est retenu, pour la même raison.
Sur un Ubuntu 22.04 avec un fichier known_hosts contenant l'empreinte de la clé RSA du serveur SSH, ssh affiche son traditionnel message « WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! » car il a négocié la présentation, par le serveur, de sa clé au format ED25519 (« The fingerprint for the ED25519 key sent by the remote host is »). Il suffit donc de supprimer l'empreinte de la clé de type RSA du fichier known_hosts (la commande est donnée dans le message d'erreur) pour basculer sur l'algorithme ssh-ed25519 et ne plus avoir d'erreur.
Si mon collègue n'a pas eu ce message d'erreur, c'est probablement qu'il devait avoir une configuration de son client SSH qui autorisait uniquement les algorithmes de la famille RSA et, potentiellement, d'autres algorithmes non pris en charge par le serveur. Du coup, son client SSH ne pouvait pas utiliser la famille RSA à cause de la dépréciation de l'algorithme ssh-rsa, et il ne pouvait pas utiliser une autre famille d'algorithmes car on le lui interdit ou le serveur SSH ne les implémente pas.
Il y a plusieurs solutions :
Ré-autoriser l'utilisation de ssh-rsa dans la configuration SSH du client en ajoutant les lignes suivantes dans le fichier ~/.ssh/config :
Host *
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
C'est la meilleure solution si t'as encore de vieux serveurs (< Debian 7) ou des swiths, car ils ne prennent pas en charge autre chose que ssh-rsa.
Utiliser un autre algorithme, donc un autre format de clé. Pour ce faire, il faut supprimer les empreintes de la clé RSA du serveur du fichier known_hosts :
ssh-keygen -f ".ssh/known_hosts" -R "<nom_du_serveur>"
ssh-keygen -f ".ssh/known_hosts" -R "<adresse_IP_du_serveur>"
Oui, il faut cibler le nom et les adresses IP (si t'as IPv6 en sus d'IPv4, t'as une commande de plus à taper ;) ). Pour le nom, il s'agit du FQDN ou du seul nom de la machine en fonction de ton usage. Il faut s'assurer que le serveur prend en charge d'autres algorithmes (ssh -o 'HostkeyAlgorithms -ssh-rsa' <nom_du_serveur> et que d'autres types de clés sont disponibles : ls -lh /etc/ssh/ssh_host_* (si non, ça se génère avec ssh-keygen, comme d'habitude).
Comme le dit le changelog d'OpenSSH : non, il est innocent.
Faut-il supprimer sa clé SSH RSA personnelle ? Non, elle est innocente.
Explications.
Lors de l'établissement d'une connexion SSH, une partie de l'échange se déroule ainsi :
/etc/ssh/ssh_host_* sur le serveur. C'est cette clé dont tu dois valider l'empreinte lors de la première connexion à un serveur SSH (modèle de sécurité TOFU, Trust On First Use). Dans le cas de mon collègue, son client et le serveur décident que le serveur doit se présenter avec sa clé de type RSA (/etc/ssh/ssh_host_rsa_key*) ;Sur un serveur plus récent (>= Debian 9), mon collègue ne rencontre aucun problème alors que le serveur se présente pourtant avec sa clé au format RSA, car ce serveur prend en charge des algorithmes RSA plus récents qui n'ont pas été dépréciés comme rsa-sha2-256 (RSA + SHA-256) et rsa-sha2-512.
Ce n'est donc pas le format de la clé (RSA) qui n'est plus pris en charge, mais l'algorithme de signature et de vérification car il repose sur la fonction cryptographique SHA-1 qui est considérée comme étant faible / dangereuse depuis des années.
Il est donc vain de jeter / changer / renouveler sa clé SSH personnelle au format RSA à coup de ssh-keygen, car le sujet est la clé du serveur.
Et il est démesuré de jeter la clé SSH RSA du serveur, car le sujet est l'algorithme utilisé, pas le format de la clé.
Ha, au fait, j'ai simplifié ci-dessus : la négociation du format de la clé et de l'algorithme se fait en une seule et même étape. Je l'ai découpé en deux afin de bien appuyer sur la différence entre le format de la clé et les procédures de signature et de vérification cryptographiques effectuées avec cette clé.
À la mi-mars 2022, j'ai fermé les commentaires sur mon blog.
Raisons :
Il y a quelques années, j'avais cherché comment fermer les commentaires. J'avais trouvé qu'il y a un paramètre pour fermer ceux des nouveaux articles / pages, mais qu'il fallait fermer à la mano les commentaires sur chaque article / page existant (ou pondre une requête SQL qui le fasse). La flemme suscitée avait pesé dans ma décision de ne pas fermer les commentaires. Avec le recul, je pense que je n'avais pas consulté les bonnes documentations, car il paraît absurde qu'un outil grand public ne permette pas de fermer les commentaires à l'heure du spam, des trolls, du harcèlement, etc. et des responsabilités légales.
En tout cas, en 2022, la fermeture des commentaires de tous les articles d'un WordPress se fait dans l'administration, « Réglages », « Commentaires », décocher « Autoriser les commentaires sur les nouvelles publications » et cocher « Fermer automatiquement les commentaires pour les publications de datant de plus de X jours ».
On n'oublie pas de désactiver et de supprimer Spam Karma. Cela se passe dans la rubrique « Extensions » de l'administration WordPress. Raison : sécurité (le code de l'extension n'est plus chargé, donc il devient inerte, il ne peut plus servir lors d'une attaque).
Mésusages de données personnelles durant la campagne présidentielle 2022 :
TL;DR : si le journal Puppet est rempli d'erreurs « SSL_CTX_use_PrivateKey: key values mismatch » mais qu'un agent puppet lancé à la main fonctionne, redémarre le service Puppet, car il a une clé privée obsolète en RAM.
Sur un serveur, je constate que des modifications de configurations prévues dans mon code Puppet n'ont pas été déployées. J'exécute l'agent puppet à la mano (puppet agent -t). Puppet applique des changements, qui, d'après l'historique du dépôt git contenant le code Puppet, datent de plusieurs semaines.
pgrep -x puppet (voir actualiser sa manière de chercher un processus) et systemctl status puppet confirment que l'agent puppet tourne pourtant en tâche de fond.
Je consulte le journal de Puppet (je l'ai rangé dans /var/log/puppet/puppetagent.log avec une configuration spécifique pour rsyslog, mais, par défaut, il est dans /var/log/syslog) et j'y trouve plein d'erreurs « SSL_CTX_use_PrivateKey: key values mismatch ». À chacune de ses tentatives de lancement, Puppet crache cette erreur.
Je pense à une bourde au niveau du réseau genre l'adresse IP ou l'adresse MAC du serveur Puppet (puppetmaster) est en double sur le réseau. Ça expliquerait un comportement du type "ça marche (quand je lance l'agent Puppet à la main), ça marche pas (d'après le journal)" : en fonction de quelle machine cause en dernier, le trafic est envoyé à la mauvaise, et la validation x509 joue parfaitement l'un de ses rôles, l'authentification du pair, et fait capoter la connexion. Je détecte aucune anomalie avec nos outils genre Netdisco ou SSH (qui, dans sa config' par défaut, vérifie l'empreinte d'un serveur à chaque connexion).
A posteriori, il y avait trois indices simples pour invalider cette hypothèse : 1) d'après le journal Puppet, il n'y a pas d'aspect aléatoire dans le dysfonctionnement (ce qui arrive rarement lors d'un conflit réseau) ; 2) un unique serveur était concerné par le problème ; 3) il est improbable que la machine usurpatrice ait, comme par hasard, un puppetmaster en écoute (sans ça, pas d'échange dans le bon protocole, donc pas d'erreur x509).
Je cherche sur le web et je trouve la ressource pointée par ce shaarli.
On a effectivement changé le certificat x509 du client Puppet (car renommage de la machine, de mémoire). À chaque exécution, l'agent puppet lancé à la mano récupère le certificat et sa clé privée en vigueur sur le disque dur. L'agent lancé par systemd qui tourne en tâche de fond a visiblement la mauvaise clé privée (ou le mauvais certificat) dans la RAM… Un systemctl restart puppet et ça repart.
Sur un serveur Red Hat fraîchement redémarré, un SGBD Oracle ne démarre pas. systemctl status nous indique « Result: timeout », « code=killed, signal=TERM », « Start operation timed out. Terminating. », « Control process exited, code=killed, status=15/TERM », et « Failed with result 'timeout'. ».
Si l'on démarre le service à la mano (systemctl start oracledb), on obtient « Job for oracledb.service failed because a timeout was exceeded ».
Par défaut, systemd accorde 1 minute 30 à chaque service pour démarrer et pour s'arrêter (cf grep Timeout /etc/systemd/system.conf).
Notre Oracle dépasse le temps imparti. Pour augmenter ce délai, il faut surcharger l'unit avec systemctl edit oracledb. Contenu de la surcharge :
[Service]
TimeoutStartSec=300
Normalement, systemd prend en compte cette modif' immédiatement, mais pour s'en assurer : systemctl daemon-reload.
On peut ensuite démarrer notre service (systemctl start oracledb), il fonctionnera, y compris au prochain redémarrage.
P.-S. : j'aime bien la façon de faire du tutoriel pointé par ce shaarli. systemctl edit crée une surcharge nommée « override.conf » stockée dans un sous-dossier nommé du nom de l'unit. Ainsi, si l'on change plusieurs paramètres, tout est dans un même fichier. Pratique ou non, c'est subjectif et ça dépend des cas (avec Puppet, on préfère déployer des fichiers unitaires de type "briques de base". Un pour configurer le timeout, un pour modifier les dépendances d'un service, etc. car c'est plus facilement ré-utilisable). Si l'on parcourt /etc/systemd/system, on voit que telle unit est surchargée mais il faut ouvrir la surcharge pour savoir ce qui l'est. Dans le tuto, il crée un fichier de surcharge nommé par le but recherché, « startup-timeout », c'est lisible.
TL;DR : indique à systemd l'ensemble des dépendances d'un service qu'il doit lancer, y compris les partitions qui doivent être montées au préalable. Surtout si le binaire qu'une unit systemd doit lancer est stocké sur une autre partition que la partition racine. Sans ça, tu t'exposes à un comportement aléatoire (unit démarre, unit démarre pas, unit démarre, etc.) lors du démarrage de la machine.
Suite au déplacement sans interruption raté d'une machine virtuelle au sein d'une grappe d'hyperviseurs (migration à chaud) et à son crash, je démarre ladite machine virtuelle Red Hat 7.9. Il s'agit d'une machine de test donc je suis détendu, mais après 30 minutes, ma supervision m'indique toujours que les bases de données Oracle ne sont pas ouvertes. En effet, systemctl status oracledb indique « code=exited », « status=203/EXEC ». Pas d'info complémentaire intéressante dans l'extrait de journal également retourné par la commande.
Une recherche dans la doc' officielle de systemd me met sur la piste que le programme à lancer est inaccessible ou non-exécutable. Pourtant, un systemctl start oracledb fonctionne. Donc le binaire est OK en temps normal… mais pas au démarrage du serveur ?
Regardons ce que lance l'unit avec systemctl show oracledb | grep -i execstart. (On peut aussi faire systemctl show oracledb -p ExecStart. Attention à bien respecter les majuscules, sensibilité à la case, tout ça.) Il n'y a pas de programme lancé au préalable (« ExecStartPre ») qui pourrait lui aussi foirer. « ExecStart=/appli/oracle/product/19c/db/bin/dbstart ». Hum… Sur ce serveur, /appli est un volume logique LVM distinct de celui de la racine. Il est référencé dans fstab et il est monté automatiquement au démarrage. Est-il possible que systemd tente de démarrer Oracle avant le montage de /appli ?
Un détail dans la définition de l'unit oracledb conforte cette hypothèse : « After=opt-oracle.mount ». Cette unit est explicitement conçue pour être démarrée après que /opt/oracle ait été montée. Mais, sur ce serveur, Oracle est stocké dans /appli/oracle. Oubli d'adapter l'unit systemd ?
Une lecture de /var/log/boot.log valide définitivemnt cette hypothèse : systemd a d'abord tenté de lancer le service oracledb avant de monter /appli.
A posteriori, je pense que c'est plus subtil que cela. La machine virtuelle crashe lors de sa migration à chaud. Au démarrage suivant, fsck est lancé. Il vérifie d'abord /, puis les autres partitions, car, dans fstab, elles ont la valeur 2 à l'attribut « fs_passno » (6e champ). En attendant, en l'absence d'information sur la dépendance, systemd lance le service oracledb. Cela explique pourquoi le démarrage d'Oracle au boot peut être effectif ou non : race condition.
Pour régler le problème, il faut conditionner le lancement du service oracledb au montage de /appli. L'unit est stockée dans /usr/lib/systemd/system/oracledb.service. Normalement, ces units sont censées être déposées par des paquets, des installeurs, etc., et ne pas être modifiées par l'administrateur. Dans le cas présent, mes collègues ont déjà trifouillé dedans, donc je continue. Avec n'importe quel éditeur de texte, je remplace la ligne After=opt-oracle.mount par After=appli.mount.
Si j'avais voulu faire propre, j'aurai fait systemctl edit oracledb. Cela aurait créé une surcharge de l'unit sous la forme d'un fichier stocké dans /etc/systemd/system/oracledb.service.d/override.conf. Dedans, j'aurai mis le contenu suivant :
[Unit]
After=appli.mount
J'ai redémarré trois fois ce serveur (afin d'avoir des stats fiables) : 0 échec du service oracledb. \o/ Dans le journal, je vois que l'unit' oracledb est lancée immédiatement après le montage de /appli.
N'étant pas le référent de ce serveur, j'en parle à celui-ci, afin, notamment, qu'il valide ma modif' et qu'il l'applique en prod'. Il est étonné : c'est la même unit systemd pour lancer Oracle sur tous ses serveurs et ça juste marche ailleurs. On regarde ensemble sur un autre serveur. Ce n'est pas la même unit. Celle-ci contient « After=network.target ».
Là encore, c'est un coup de chance que cela fonctionne : on peut raisonnablement espérer que le réseau sera monté après les partitions locales. Donc si l'on demande à systemd de lancer Oracle après le réseau, on peut légitimement s'attendre à ce que ça fonctionne. Mais c'est bancal… et implicite (les pré-requis d'un service ne sont pas clairement énoncés).
Bref, prends soin des dépendances de tes units systemd.
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 ?
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…
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.