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 GMTThe 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.Transformer instantanément une partition logique en partition primaire sans perte de données avec fixparts (nom du paquet Debian : gdisk).
J'ai testé uniquement avec une table des partitions au format MBR.
sudo fixparts /dev/sdX
p
r
p
w
fixparts demandera le numéro de la partition logique à transformer ;Dans mon cas, sur mon disque dur, j'avais une partition primaire FAT32 (EFI ?) et une partition logique ext4 dans une unique partition étendue située en fin de disque. Je ne suis pas certain que fixparts fonctionne en toute circonstance, notamment si la partition étendue contient plusieurs partitions logiques.
Pour réparer GRUB, j'utilise toujours un live USB et chroot. Fiabilité garantie à chaque utilisation, contrairement aux outils magiques qui viennent et qui vont sans apporter de résultats.
mkdir /mnt/chroot
mount /dev/sdaX /mnt/chroot
mount --bind /dev /mnt/chroot/dev
mount --bind /dev/pts /mnt/chroot/dev/pts
mount --bind /sys /mnt/chroot/sys
mount -t proc /proc /mnt/chroot/proc
chroot /mnt/chroot
update-grub2
grub-install /dev/sdXJe me demandais comment l'équipe de campagne de Zemmour (comme celle de tant d'autres candidats à une érection ‒ ;) ‒ avant elle) s'y est prise pour laisser un message vocal sur les mobiles des citoyens.
Le faire sans subterfuge, c'est prendre le risque que l'appelé décroche et que l'automate lui apparaisse bien fade.
De plus, sur plusieurs annuaires inversés / site de signalement d'arnaques téléphoniques (1, 2), on trouve des signalements selon lesquels leur téléphone n'a pas sonné avant le dépôt du message de Zemmour sur leur répondeur.
Cette causerie sur Twitter référence deux manières de laisser un message vocal sans faire sonner un téléphone :
Comme quoi, même un prétendu méchant pas gentil pas beau peut faire découvrir / apprendre quelque chose. :D
‒ Sachant que vous avez 67 milliards de bénéfices annuels, il nous aura fallu tout de même 4 ans de procédure pour vous arracher 15 minutes de votre temps … … … Ah zut, ils sont déjà partis.
Tellement ça. :D Asymétrie entre attaque et défense liée à l'accumulation du capital. (Oui, y'a les temps d'attente de la procédure, mais bon.)
Farce de la primaire populaire. Résultats du vote : 1) Taubira ; 2) Jadot ; 3) Mélenchon. Quand Taubira ne collecte pas les 500 parrainages, le Conseil d'Administration de 2022 ou jamais, l'asso organisatrice, vote un soutien à Mélenchon… Le même qui lui avait manifesté un grand désintérêt et qui a reçu un nombre plus conséquent de mentions "insuffisant" que Jadot. Le vote d'un petit cénacle a donc bafoué celui de 392 k citoyens. Un classique dans le salariat et l'associatif :) ;
Article douteux sur le sabotage de câbles sous-marins d'Internet par la Russie. En août 2021, un mini sous-marin russe aurait suivi le câble AEC-1 (genre le FSB n'a pas récupéré le tracé lors de sa pose ? :O). La France a décidé de se doter d'une stratégie et de robots sous-marins permettant d'opérer à 6 km de profondeur (cf le communiqué de presse de la sinistre désarmée ‒ jeu de mots volontaire ;) ‒). Le reste de l'article est pipeau :
Cette décision de justice provisoire (car Zemmour a annoncé faire appel) est intéressante sur trois points :
On notera que les ayants-droits ont, eux aussi, été excessifs dans leurs demandes (argent), n'ont pas apporté de justifications (en quoi de courts extraits passant du coq à l'âne dénaturent les œuvres ?) et ont été déboutés sur ces points précis.
Le tribunal a également évoqué la jurisprudence de la CJUE concernant les liens hypertextes : est répréhensible un lien hypertexte vers une œuvre illégalement publiée sur un autre site web.
On notera que l'engorgement de la justice est à géométrie variable : assignation le 30/12/2021 ; Audience le 27/01/2022 ; Jugement le 04/03/2022.
ÉDIT DU 20/10/2022 : le parti de Zemmour s'est désisté de son appel. Le jugement sus-analysé est devenu définitif. FIN DE L'ÉDIT.