Analyser l’impact d’une mise à jour ESXi

Lorsqu’on met à jour à la main un ESXi, il est possible d’analyser les paquets qui vont être installés, ceux qui vont être mis à jour, et ceux qui ne vont pas être touchés. On a alors une sortie qui ressemble à ça.

Comme on peut le voir, il est difficile d’avoir une vue claire permettant de savoir quel paquet va être mis à jour et en quelle version. J’ai à ces fins écris un petit script en PowerShell permettant d’améliorer la lisibilité de la sortie.

Il suffit de remplacer le contenu de $in  par ta sortie et $result  contiendra désormais la liste des packages impactés avec la version d’origine et la version de destination. Il est de même rapide de voir les paquets définitivement supprimés, les nouveaux et ceux qui ne seront pas impactés par la mise à jour.

Enjoy.

 

Description de l’authentification via NTLM en HTTP

Format Lien

Petit article que j’ai déniché expliquant comment fonctionne une authentification avec un site web utilisant le fournisseur NTLM. Note: je ne dis pas si c’est bien ou pas d’utiliser NTLM, juste de savoir comment ça marche.

Cela explique toutefois pourquoi je n’arrive pas à reverse-proxifier un site web qui utilise NTLM pour authentifier le client avec nginx.

NTLM Authentication Scheme for HTTP

rc-status ne voit pas crond

J’ai observé sur mon routeur Alpine que le daemon crond affichait tout le temps crashed.

Alors même qu’il était vivant vu que  pidof crond me renvoyait bien un PID.

Une analyse du script init.d revèle que le pid devrait se trouver dans le fichier  /var/run/crond.pid . Que nenni mon ami, ce fichier contient un PID inexistant, voilà pourquoi rc-status  affiche n’importe quoi !

C’est courant lorsque le script init.d récupère le PID du process qu’il lance, alors que ce dernier se fork encore une fois afin de pouvoir fonctionner en background.

On va résoudre ça vite fait. Examinons s’il est possible que crond crée le pid file, ou alors qu’il ne passe pas en arrière plan lui-même mais laisse faire start-stop-daemon.

Au vu des paramètres possibles, je dirais qu’on va tester crond en foreground. On édite donc /etc/conf.d/crond  pour préciser à crond de rester en background.

Et on relance le service avec rc-service crond restart . Et voilà c’est terminé ! … et là on remarque qu’il n’y a plus de crond du tout ! Et pas de messages d’erreur non plus.

Aux grand maux les grands remèdes, je sors l’artillerie lourde afin de comprendre ce qu’il s’est passé pour de vrai. Le passage intéressant est à la fin; il n’est pas nécessaire de lire toutes ces horreurs.