Des vérifications qui ne peuvent pas échouer : cinq faux positifs en une semaine d’automatisation Mac

Une seule règle nous aurait épargné presque une semaine. Avant de faire confiance à une vérification, demandez-vous ce qu’elle affiche quand la chose est cassée. Si la réponse est "la même chose", vous n’avez pas de vérification. Vous avez une décoration qui dit OK.

En voici cinq, trouvées en une semaine. Toutes sur macOS, toutes dans une automatisation qui tournait sans incident depuis des mois. Chacune a donné une mauvaise réponse avec assurance. Et chacune a envoyé un humain réparer quelque chose qui n’était pas cassé.

1. La mise à jour qui ne tournait pas

Une machine semblait lente à revenir après un redémarrage. Un rapide pgrep -f softwareupdate a trouvé une correspondance. Le script a donc indiqué qu’une mise à jour logicielle était en cours, et nous avons attendu.

Il n’y avait aucune mise à jour. softwareupdated est un démon résident présent sur chaque Mac. Une recherche par sous-chaîne le trouve, qu’il se passe quelque chose ou non. Le propriétaire de la machine l’a vu avec une question simple : aucune mise à jour ne devrait être en cours, alors quel est le problème ? La vérification n’avait pas de réponse, parce qu’elle n’en avait jamais eu.

La correction consiste à chercher ce qu’une mise à jour en cours laisse derrière elle. Un téléchargement en cours ou une activité disque soutenue, c’est une preuve. Un nom de processus toujours présent, non.

2. Le Xcode copié en zéro seconde

Nous clonons Xcode d’une machine à l’autre en envoyant une archive tar en flux par SSH. Une exécution est passée par un portable qui a manqué de mémoire. Le côté émetteur est mort. Le tar -xf - du côté récepteur a lu un flux vide, n’a rien extrait, et a renvoyé zéro. Le script a affiché XCODE_COPIED.

Zéro octet avait été transféré. Le code de sortie était honnête sur ce qu’on avait demandé à tar : extraire ce qui arrivait. Rien n’est arrivé.

# what we checked
tar -xf - -C /Applications && echo XCODE_COPIED

# what we should have checked
du -sh /Applications/Xcode.app          # 3.8G, or it did not happen
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -version

3. L’autorisation déclarée accordée

macOS protège l’enregistrement de l’écran par un privilège que seul un humain ou un profil MDM peut accorder. L’outil kickstart d’Apple affiche un avertissement clair quand le privilège manque. Notre sonde cherchait cet avertissement. N’en trouvant aucun, elle déclarait le privilège accordé.

Quand l’outil n’a aucun privilège, il n’affiche rien. Aucun avertissement, rien du tout. L’absence d’avertissement ressemblait exactement à un succès. L’histoire complète est dans le Mac qui vous connecte et ne vous montre rien. La correction a été d’arrêter de demander l’avis de l’outil, et d’échantillonner à la place de vrais pixels du framebuffer.

4. Le bureau déclaré mort

Pour confirmer qu’un utilisateur était connecté à l’interface graphique, nous regardions à qui appartenait /dev/console. Sur une machine neuve, la réponse était root. Nous en avons conclu que personne n’était connecté. Puis nous avons vérifié la machine d’un client, où un utilisateur était connecté depuis deux jours. La réponse était aussi root.

Pendant une dizaine de minutes, le bureau d’un client payant a été signalé comme hors service. Il allait bien. Le propriétaire du nœud de périphérique ne signifie tout simplement pas ce que nous pensions. who affiche une ligne console seulement quand une session existe, et c’est ce que notre télémétrie remonte désormais.

5. L’erreur qui était une constante

Une machine sous une toute nouvelle version majeure de macOS refusait l’ouverture de session automatique. Le sysadminctl -autologin set d’Apple renvoyait SACSetAutoLoginPassword error:22. Nouvel OS, nouvelle erreur, conclusion évidente : la nouvelle version avait cassé l’ouverture de session automatique par script.

Puis nous avons lancé la même commande sur une machine saine, une version majeure en arrière, où l’ouverture de session automatique marchait depuis des semaines. Même erreur. La commande échoue de la même façon sur les systèmes qui marchent et sur ceux qui sont cassés. Elle n’apportait donc aucune information sur les uns ou les autres. La vraie cause s’est révélée être un état passager du premier démarrage. Le diagnostic sûr de lui était faux, et le témoin l’a réfuté en moins d’une minute.

La règle, et deux corollaires

Chacune des cinq échoue à la première question. Nous avons passé quatre jours à les poursuivre. Aucun des systèmes sous-jacents n’était cassé de la façon annoncée par les vérifications.

Ce qui a changé

La vérification de l’écran échantillonne le framebuffer et compte les couleurs. La vérification de session utilise who et remonte dans la télémétrie. Une machine restée à la fenêtre de connexion déclenche donc une alerte au lieu de paraître saine. Les copies sont vérifiées par leur taille et en lançant le binaire copié. Et aucune panne ne reçoit de cause tant que la même vérification n’a pas été lancée sur quelque chose qui marche. Rien de tout cela n’est malin. C’est chaque fois la même question, posée avant d’écrire la vérification plutôt qu’après qu’elle a menti.