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.
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. :)
J'ai documenté comment tester OCSP stapling. Mais pas comment tester OCSP tout court. Vu que j'en ai eu besoin, il est temps de le faire. :)
Ces notes sont fortement inspirées de ce tutoriel : OCSP Validation with OpenSSL – Akshay Ranganath's Blogs.
OCSP = protocole qui permet à un client TLS (un navigateur web, par exemple) de vérifier, en direct, lors de l'accès à une ressource (un site web via le protocole HTTPS, par exemple), la validité d'un certificat x509. Cette vérification se fait en interrogeant l'autorité de certification (AC) qui a émis le certificat x509. But ? Vérifier que le certificat n'a pas été révoqué car la clé privée utilisée pour sa génération a été compromise, par exemple.
Cela pose un problème de respect de la vie privée, surtout quand une autorité de certification est hégémonique (comme Let's Encrypt, par exemple). J'ai expliqué cela en détail ici.
OCSP stapling remédie à ce problème puisque c'est le site web visité qui communique la preuve de validité de son certificat x509 lors de la poignée de main TLS (via une extension TLS). Cette preuve ne peut pas être falsifiée puisqu'elle est signée par l'autorité de certification. Ainsi, l'AC n'est pas interrogée par les navigateurs web qui visitent le site web, mais uniquement par le serveur de ce site (et la réponse est mise en cache), donc la vie privée est préservée.
Il faut penser à désactiver OCSP et à vérifier qu'OCSP stapling est bien activé dans la configuration de son navigateur web (et autres clients TLS comme un logiciel de courriels). Voir ici pour Firefox.
Tester un répondeur OCSP. Ici, celui d'iPXE :
# Récupérer un certificat signé par l'AC :
wget http://ca.ipxe.org/cross-ca.crt
# Récupérer le certificat de l'AC (il n'y a pas de certificat intermédiaire) :
wget https://ca.ipxe.org/ca.crt
# Dépiauter l'URL du répondeur OCSP
openssl x509 -in cross-ca.crt -ocsp_uri -noout
# Tester le répondeur OCSP
openssl ocsp -issuer ca.crt -cert cross-ca.crt -text -url http://ocsp.ipxe.org/ocsp/root/
Résultat :
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 9D22406E09E917C47B5C2317E37F3A895110EF1F
Issuer Key Hash: AB41305C0BB30C7107313C337644981C51D42A72
Serial Number: 4C
Request Extensions:
OCSP Nonce:
0410FA5B843E6EA96F70F9C2DA6F75A955DA
Responder Error: trylater (3)
Ha, le répondeur OCSP du projet iPXE est hors service.
Un cas plus difficile. Récupération des certificats lors de la poignée de main TLS et présence d'un certificat intermédiaire :
# Récupérer la chaîne de certification du service TLS
openssl s_client -connect ent.univ-avignon.fr:443 -showcerts < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p' > chaine.crt
# Isoler le certificat feuille (celui du service TLS) dans un fichier dédié et l'effacer de la chaîne (sinon OpenSSL échoue, « unauthorized ») :
sed -n '1,/-----END/p' chain.cert > ent.crt ; sed -in '1,/-----END/d' chaine.crt
# Dépiauter l'URL du répondeur OCSP
openssl x509 -in ent.crt -ocsp_uri -noout
# Tester le répondeur OCSP
openssl ocsp -issuer chaine.crt -cert ent.crt -text -url http://GEANT.ocsp.sectigo.com
Attention : s'il est obligatoire (par la norme) que le certificat feuille soit le premier dans la liste communiquée par un serveur TLS, le certificat intermédiaire ne sera pas toujours le deuxième, car cela dépend de la rigueur de l'administrateur du serveur TLS. Ce choix, très courant, a été acté dans la norme TLS 1.3. Donc, il faut parfois s'adapter, et vérifier l'ordre des certificats + s'assurer que chaque certificat est dans le bon fichier passé au bon paramètre d'OpenSSL, est la première chose à faire quand OpenSSL crache une erreur « unauthorized ».
Résultat :
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: C3FDEA1EAA0EBEDE75016EEC6E5BB393F0F12E5D
Issuer Key Hash: 6F1D3549106C32FA59A09EBC8AE81F95BE717A0C
Serial Number: B3A8B670D4517A753871ED8F2EF46450
Request Extensions:
OCSP Nonce:
041034E12F9591DFFCCE41926E4C9834F0F5
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: 6F1D3549106C32FA59A09EBC8AE81F95BE717A0C
Produced At: Apr 15 15:24:27 2022 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: C3FDEA1EAA0EBEDE75016EEC6E5BB393F0F12E5D
Issuer Key Hash: 6F1D3549106C32FA59A09EBC8AE81F95BE717A0C
Serial Number: B3A8B670D4517A753871ED8F2EF46450
Cert Status: good
This Update: Apr 15 15:24:27 2022 GMT
Next Update: Apr 22 15:24:27 2022 GMT
Signature Algorithm: sha384WithRSAEncryption
5b:1a:4f:4d:71:7c:d5:81:37:36:a7:e6:5a:80:47:fc:ec:d5:
a5:18:49:86:b1:2f:05:0d:e9:30:0c:61:75:36:cf:fd:d0:10:
b2:9b:fa:15:92:c1:91:5c:e5:28:ee:06:c5:50:fb:8b:18:58:
04:5c:b9:07:f2:f3:37:8d:e7:0f:be:3e:58:7d:ca:b8:83:08:
b3:c7:a0:40:ae:d2:0a:7a:c2:18:0b:f4:e9:67:9d:ca:b7:d9:
0c:88:35:3b:d7:7f:95:e6:b5:92:c0:78:8a:26:72:26:1c:1e:
e0:32:2e:03:4c:84:0e:bf:3c:9a:6d:e1:93:83:76:1d:e5:04:
3b:62:3e:c4:6a:01:8e:fb:b6:1a:0a:4e:64:cd:7c:9d:99:d3:
05:50:f5:52:71:bf:36:26:f0:d7:ad:7e:a5:7c:fc:e5:db:6e:
c7:ae:a4:66:ef:94:a8:53:8c:3a:c5:5b:cc:bb:a4:89:c9:c6:
60:ca:fc:f9:cd:e0:af:39:f0:6e:ea:8e:e6:21:d5:78:ae:f9:
d5:bc:3d:ac:3b:e4:7e:d6:7e:c1:3a:ce:21:dd:7e:aa:ca:82:
e1:b5:74:f4:10:62:69:6e:be:60:dd:fb:78:e7:7e:52:82:1c:
3d:73:b1:db:84:65:a4:14:ee:29:99:11:31:a9:3f:42:5a:b2:
0f:e3:e9:2c:d0:40:56:0f:b0:04:1a:e0:51:09:6e:47:56:c1:
b5:f2:72:da:68:ec:3f:cc:4b:fd:8e:c3:9b:6f:0f:78:a3:22:
83:f7:28:ee:f5:4f:5b:82:bf:17:2f:eb:c9:fa:3d:28:d2:ef:
0f:90:ed:3e:1c:be:78:89:d9:2d:b9:f1:68:1b:79:7d:a7:6d:
93:c0:13:15:4f:73:6c:a7:39:77:97:17:5d:79:f9:ef:fb:1d:
67:cb:79:72:e5:2a:ca:66:b6:cf:7b:4e:cc:23:a0:5b:f4:ae:
33:b2:0d:95:54:44:e8:e0:18:3a:79:49:67:2d:ac:c8:cf:d8:
43:3b:6a:7a:4d:8f:f4:6d:77:d9:bf:55:48:6f:50:3f:da:07:
d3:58:dc:9d:e8:78:20:09:49:e5:7c:8b:1e:a4:79:95:5d:37:
69:d0:b3:0f:f3:47:d5:92:74:16:34:b5:6a:a0:47:9a:54:b9:
ad:fd:13:2a:b8:60:39:d7:f7:0d:b4:9d:0a:b9:2d:09:99:51:
91:e5:c0:ea:03:68:30:10:00:94:aa:cd:31:3a:57:8b:0d:82:
df:8a:d0:64:d3:69:7f:84:ac:25:ce:10:18:65:db:36:58:6c:
0c:28:59:de:ad:a9:c7:05:0d:35:b3:7a:73:b7:d9:61:91:39:
ee:9f:da:f8:f5:c4:57:54
WARNING: no nonce in response
Response verify OK
ent.crt: good
This Update: Apr 15 15:24:27 2022 GMT
Next Update: Apr 22 15:24:27 2022 GMT
Les lignes importantes :
En fonction de la panne que l'on diagnostique, et afin d'être rigoureux, il faudrait également vérifier que le répondeur de l'AC qui a signé le certificat intermédiaire répond et que ce dernier n'est pas révoqué. Pour ce faire, il suffit de déplacer le certificat intermédiaire dans un fichier, de passer ce fichier en paramètre de -cert
et le certificat racine (que l'on peut télécharger sur le site web de l'AC ou récupérer dans le navigateur web : icône cadenas dans la barre d'URL, « connexions sécurisée », « plus d'informations », identifier le certificat, et cliquer sur « PEM (cert) » sur la ligne « Télécharger »), en paramètre de -issuer
.
Avec un certificat révoqué, il y a uniquement la fin qui change :
XXXXXXXXXX.crt: revoked
This Update: Apr 16 14:41:26 2022 GMT
Next Update: Apr 23 14:41:26 2022 GMT
Revocation Time: Apr 16 14:41:22 2022 GMT
The Web Console: […] Enables you to interact with a web page by executing JavaScript expressions in the context of the page
Je ne savais pas (ou j'ai oublié), que la console web des outils de développement web de Firefox permet d'interagir avec une page web en causant JavaScript.
Dans ladite console, il y a deux chevrons grisés à gauche (sous l'icône corbeille). Il suffit de cliquer en face d'eux dans la zone blanche et de saisir du JavaScript, genre, sur ce shaarli, document.getElementById("menu");
. Si l'objet existe, il est retourné, sinon « null » est retourné.
Une collègue m'a montré cela alors que nous cherchions à comprendre pourquoi le logiciel web bbb-recorder, qui permet de faire un screencast d'un enregistrement BigBlueButton (BBB) afin de le rendre indépendant du lecteur interne de BBB (et donc, de l'exporter).
Depuis quelques jours, il n'arrivait plus à récupérer la durée d'un enregistrement BBB et donc à lancer le screencast.
Si l'on regarde le code, l'élément du DOM contenant la durée est recherché. Le nom de cet élément change en fonction de la version de l'API de Scalelite (et non pas de la version de BBB, la variable « bbbVersionIs23 » est mal nommée).
Ma collègue ajoute un console.log(url);
afin que l'on récupère, dans le journal de l'application sur le serveur (et pas dans la console web comme on pourrait s'y attendre), l'URL du lecteur BBB pour un enregistrement donné. On y accède avec nos navigateurs web. J'ai le réflexe de regarder le code source de la page… et j'y trouve ni élément avec l'ID « vjs_video_3_html5_api », ni élément avec l'ID « video ». :O Ma collègue, qui a utilisé la console web de Firefox, a trouvé l'élément avec l'ID « video ».
C'est un classique, la page « view-source » qui n'affiche pas forcément le code qui correspond à ce que l'on voit à l'écran (car JavaScript peut manipuler la page web, par exemple).
Mais ça n'échappe pas à un requêtage via la console web, c'est noté.
Notons que, lors du premier copier+coller d'un code JavaScript en son sein, la console demande à débloquer explicitement le copier+coller en saisissant une phrase.
Merci Jade de m'avoir appris (ou rappelé) cette possibilité de la console web. :)
Lors de leur installation, certains logiciels livrés en paquets Debian (.deb) posent des questions dans une interface semi-graphique (bleu/gris, ncurses).
La plupart d'entre eux prévoient un choix par défaut. Donc on peut réclamer le silence durant leur installation : sudo DEBIAN_FRONTEND=noninteractive dpkg -i <paquet>.deb
.
Mais certains logiciels exigent une réponse et leur installation échoue si on leur réclame le silence. Exemple ? Cisco PacketTracer qui veut que l'on accepte son contrat de licence.
L'écosystème Debian propose des outils pour parer à cette situation en provisionnant des réponses : debconf-get-selections
, debconf-set-selections
, debconf-communicate
.
On n'en attend pas moins d'un système qui permet déjà de fournir des réponses pré-enregistrées (preseed) pour son installation.
D'abord, on récupère toutes les réponses déjà provisionnées : debconf-get-selections | sort > debconf_avant_PT.txt
.
Il faut trier la sortie car debconf-get-selections
ne régurgite pas les réponses dans le même ordre entre deux exécutions. :(
Puis on installe le paquet pénible normalement, en répondant aux questions afin que l'installation soit conforme à ce qu'on attend, à la cible : sudo dpkg -i CiscoPacketTracer_801_Ubuntu_64bit.deb
.
Puis, on récupère à nouveau la liste des réponses provisionnées : debconf-get-selections | sort > debconf_apres_PT.txt
.
On compare les deux listes afin de trouver les configurations ajoutées par Packet Tracer : diff debconf_avant_PT.txt debconf_apres_PT.txt
. Résultat :
PacketTracer PacketTracer_800_amd64/accept-eula boolean true
PacketTracer PacketTracer_800_amd64/show-eula note
On supprime les réponses pré-enregistrées pour/par Packet Tracer : echo PURGE | sudo debconf-communicate PacketTracer
. (Le paramètre est la première chaîne de caractères d'une ligne debconf-get-selections
qui est au format « propriétaire clé/sous-clé valeur »).
On désinstalle le logiciel puis on retente son installation : sudo DEBIAN_FRONTEND=noninteractive dpkg -i CiscoPacketTracer_801_Ubuntu_64bit.deb
. Il demande à nouveau de valider son contrat de licence. Jusque-là, tout va bien.
On le désinstalle à nouveau.
On provisionne les réponses :
echo 'PacketTracer PacketTracer_800_amd64/accept-eula boolean true
PacketTracer PacketTracer_800_amd64/show-eula note' | sudo debconf-set-selections
On installe le paquet normalement (sudo dpkg -i CiscoPacketTracer_801_Ubuntu_64bit.deb
) : aucune question et l'installation est réussie. \o/
On peut donc automatiser l'installation de ce logiciel sur tout un parc d'ordinateurs (avec un script, Puppet, peu importe) : il suffit d'utiliser debconf-set-selections
avant dpkg -i
.
A priori, les réponses pré-enregistrées sont ignorées par dpkg-reconfigure <nom_logiciel>
. J'ai testé avec le paquet unattended-upgrades (voir ici). C'est sensé : dpkg-reconfigure
stocke la réponse dans le même dépôt accessible à debconf-get|set-selections
. Si dpkg-reconfigure
utilisait ce dépôt pour provisionner, il serait impossible de reconfigurer un logiciel (réponse déjà dans le dépôt, je la prends, donc logiciel pas reconfiguré) alors que c'est le but de la commande.
Merci Alex de m'avoir appris l'existence de ces outils. :)
La méthode préconisée un peu partout semble être sudo dpkg-reconfigure unattended-upgrades
+ répondre « No » dans l'interface semi-graphique (ncurses).
Comme elle le dit elle-même (« Replacing config file /etc/apt/apt.conf.d/20auto-upgrades with new version »), cette commande remplace le contenu de /etc/apt/apt.conf.d/20auto-upgrades
par les deux lignes suivantes :
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "0";
Plus facile à puppetiser (fichier > commande). :)
Pourquoi désactiver les mises à jour automatiques d'Ubuntu ? Sécurité tout ça, c'pas bien de désactiver.
sleep 1m
), notre script d'initialisation qui, entre autres, installe Puppet et ajoute la machine à notre domaine winwin Samba 4. Or, il arrive que les mises à jour automatiques se déclenchent avant. Auquel cas, Puppet n'est pas installé et la machine n'est pas ajoutée à notre domaine (car notre script installe les paquets nécessaires, krb5-utils
, sssd-ad
, etc.). C'est normal puisque toute utilisation d'apt
/ dpkg
est exclusive (et heureusement) : « Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2921 (unattended-upgr)... ». On pourrait adapter notre script pour faire une boucle "tant qu'apt
/ dpkg
est utilisé, j'attends" / "tant que tels logiciels ne sont pas installés, re-tenter" mais ça retarde la mise en service du poste alors que les mises à jour peuvent se faire plus tard, en arrière-plan, quand l'utilisateur du poste travaille ;apt
/ dpkg
avec apt -y --fix-broken install
et dpkg --configure -a
et de lancer Puppet (raisons pour lesquelles nous ne laissons pas tourner l'agent toutes les 30 minutes). Ces actions garantissent le bon fonctionnement des mises à jour et de Puppet. Autant que ce script soit le seul à agir : en cas de problème, nous avons une seule source d'ennuis à analyser.Pourquoi ne pas désinstaller le paquet unattended-upgrades
?
unattended-upgrades
affiche un message "màj en cours, ne pas éteindre" lorsque des mises à jour (via CRON, cf ci-dessus) ou des installations (via Puppet) seront en cours. D'après mes tests, cet espoir est vain.