Mises à jour de l’agent

Deux faits indépendants doivent concorder avant qu’un nouveau binaire ne s’exécute sur votre hôte : son empreinte doit correspondre à la valeur publiée par la plateforme, et il doit porter une signature valable sur ses octets bruts, produite avec la clé de publication de la plateforme.

• La somme de contrôle prouve que le téléchargement est intact. Elle ne dit rien de qui l’a produit.
• La signature prouve qui l’a produit. Elle est contrôlée par l’agent avant toute préparation, puis de nouveau par un script que seul root peut modifier, avant l’installation du binaire.
• La clé publique utilisée par ce second contrôle appartient à root. Le compte de service sous lequel tourne l’agent ne peut pas la remplacer : compromettre l’agent ne permet donc toujours pas de faire exécuter un binaire en tant que root.
• Une version sans signature est refusée. De même pour une version dont la signature ne correspond pas, même si la somme de contrôle correspond.

Lorsqu’un agent est en retard, le panneau le signale en haut de sa page et dans la liste des agents. Appuyez sur le bouton et la plateforme remet à l’agent un lien de téléchargement à durée de vie courte, par la connexion déjà ouverte.

• Un seul agent : la bannière sur sa page, ou la carte de mise à jour dans l’onglet des paramètres.
• Plusieurs d’un coup : sélectionnez-les dans la liste des agents et mettez à jour la sélection. Le nombre affiché sur le bouton ne compte que les agents qui peuvent effectivement être mis à jour à cet instant.
• Le tableau de bord propose un bouton direct pour chaque agent en retard, pour que vous n’ayez pas à les chercher.
• La progression survit à un rechargement de page : elle est lue depuis la commande en cours, pas depuis quelque chose que le navigateur retient.

Chaque agent a un horaire, et il est actif d’origine à 03:00, heure d’Europe centrale. Si à l’une de vos heures une version plus récente existe, la plateforme la remet à cet agent comme le fait le bouton. Le reste ne change pas : le même binaire signé, les mêmes vérifications sur l’hôte, le même retour en arrière.

• Plusieurs heures par agent, six au maximum, sur une grille de cinq minutes. Six suffit pour toutes les quatre heures et reste assez court pour se lire d’un coup d’œil.
• Les heures sont lues sur la même horloge murale que le reste du panneau. Une heure qui n’existe pas la nuit où l’horloge avance s’exécute une heure plus tard au lieu d’être sautée, et une heure qui existe deux fois s’exécute une seule fois.
• Il y a une fenêtre de rattrapage de quinze minutes et pas davantage. Une mise à jour prévue pour 03:00 ne se souhaite pas à 09:00 : la nuit avait été choisie exprès.
• Un agent hors ligne à son heure saute la nuit sans consommer son créneau, et prend le suivant. Un agent joignable mais déjà à jour consomme bel et bien le créneau, pour que son historique montre que quelqu’un a regardé.
• Au plus cinq agents d’un même compte partent par minute. Une flotte de quarante télécharge environ 22 Mo chacun, depuis un seul réseau, et étaler cela sur huit minutes tient dans la fenêtre de rattrapage.
• Vous recevez une notification quand une mise à jour planifiée réussit et quand l’une échoue, groupée par compte. Un agent en échec se signale au plus une fois par jour, pour qu’un hôte bloqué ne remplisse pas vos notifications de la même phrase.

L’agent télécharge le nouveau binaire à côté de lui, vérifie la somme de contrôle et la signature, et ne se termine qu’ensuite. Systemd redémarre le service, une étape appartenant à root vérifie une fois de plus le binaire préparé, l’installe de façon atomique et contrôle qu’il s’exécute réellement avant de le conserver. Si l’une de ces étapes échoue, l’ancien binaire reste en place et le service repart dessus.

Vous n’êtes pas obligé de passer par le panneau. Tout ce que fait le bouton tient aussi en une poignée de commandes, et le panneau les affiche pour vous avec la somme de contrôle et la signature actuelles déjà renseignées. Les deux étapes à conserver si vous scriptez vous-même sont les étapes de vérification :

Vérifiez la somme de contrôle de ce que vous avez téléchargé.

echo "<sha256-from-the-panel>  provibr-agent-linux-x86_64" | sha256sum -c -

Vérifiez la signature contre la clé publique présente sur l’hôte. C’est l’étape qu’un simple téléchargement ne vous donne pas, et c’est celle qui compte.

openssl pkeyutl -verify -pubin -inkey /usr/local/lib/provibr-agent/license-signing.pub -rawin \
  -in ./provibr-agent-linux-x86_64 -sigfile ./provibr-agent-linux-x86_64.sig