Vérifier et déployer

Une machine est déployée quand openlatch doctor ne signale aucun problème et que la console détient son enregistrement. Cette page prouve les deux, puis élargit le déploiement en trois vagues.

Vérifier une machine

Lancez les deux commandes sur chaque machine installée, dans cet ordre.

openlatch status
openlatch doctor

openlatch status répond à une question : cette machine est-elle couverte en ce moment ? Un bon résultat montre la machine connectée à la console, des politiques présentes sur la machine, et chaque agent de la machine raccordé.

openlatch doctor répond à la question plus difficile : ce compte rendu est-il vrai ? Il affiche une cause et un remède pour chaque point relevé. Un bon résultat, c’est qu’il ne relève aucun problème. C’est l’étape de recette d’une machine : comptez une machine avec un point non résolu comme une machine en échec dans le bilan de la vague. Quand il relève quelque chose, suivez le remède qu’il indique et relancez-le, jusqu’à ce qu’il soit propre.

Ce que vous confirmez	À quoi ressemble un bon résultat
La machine est connectée	Elle a atteint la console et y détient un enregistrement à jour
Les politiques sont présentes	Des politiques sont sur la machine. C’est ce qui lui permet de continuer à décider quand la console est injoignable
Les agents sont raccordés	Chaque agent installé sur la machine est raccordé, et aucun n’attend encore que son développeur confirme la connexion

Attention

Une machine peut tourner sans rien couvrir, et vue de l’extérieur elle ressemble exactement à une machine qui fonctionne : le client tourne, la console détient un enregistrement, et un agent de la machine n’a jamais été raccordé. Ne passez pas à l’étape suivante du déploiement derrière une installation que openlatch doctor n’a pas validée.

Constituer une archive de diagnostic

Quand une machine a un problème que le remède affiché ne permet pas de résoudre, constituez une archive de diagnostic.

openlatch doctor --rescue

La commande produit une archive ZIP expurgée qui contient le diagnostic, la configuration du client et une fenêtre récente des enregistrements locaux de la machine.

Option	Effet
--since 24h	Borne la fenêtre d’enregistrements locaux incluse dans l’archive
--yes	Saute la confirmation, pour une exécution sans surveillance

L’archive permet d’examiner un problème à partir des éléments de la machine elle-même plutôt que d’une description du symptôme. Elle est expurgée dans ce but : envoyez l’archive plutôt que le répertoire lui-même.

Note

Ouvrez une demande de support avec l’archive jointe, le système d’exploitation de la machine, et l’heure du problème avec son fuseau horaire. Contactez votre référent technique OpenLatch par le canal convenu avec votre organisation. Envoyez les signalements de sécurité à security@openlatch.ai.

Confirmer dans la console

Un compte rendu propre sur la machine est la moitié de la vérification. L’autre moitié, c’est la console qui détient un enregistrement pour la machine, avec les agents détectés et la personne à qui ses actions sont attribuées.

1. Ouvrez le registre des agents. Connectez-vous sur app.openlatch.ai et ouvrez Agents.

   Résultat attendu : une ligne par agent qui a remonté des données.

2. Trouvez la machine. Cherchez par nom d’hôte ou par l’utilisateur du système d’exploitation sous lequel l’installation a tourné.

   Résultat attendu : la machine apparaît dans les 24 heures suivant l’installation, et en quelques minutes sur un réseau sain.

3. Confirmez les agents de la machine. Ouvrez un agent et lisez ses détails, dont son niveau de contrôle.

   Résultat attendu : chaque agent installé sur cette machine est listé, chacun avec son niveau de contrôle. Un agent manquant est un problème d’installation, pas un problème de console : revenez aux vérifications de la machine ci-dessus.

4. Confirmez le propriétaire déterminé. L’onglet Identity de l’agent nomme la personne à qui ses actions sont attribuées, avec son rôle et sa place dans l’organisation. Avec un annuaire connecté, le propriétaire est déterminé par une recherche en lecture seule ; sans annuaire, OpenLatch s’appuie sur ce que la machine remonte.

   Deux commandes se trouvent à côté du nom : l’une explique comment ce propriétaire a été déterminé, l’autre permet de le remplacer à la main. Corriger la propriété est le travail du rôle editor.

   Résultat attendu : une personne nommée plutôt qu’un champ vide.

5. Confirmez que les enregistrements arrivent. Lisez l’heure de dernière activité de l’agent pendant qu’un développeur travaille sur cette machine.

   Résultat attendu : l’heure avance. Un enregistrement qui cesse d’avancer renvoie à la route de sortie de la machine.

app.openlatch.ai/agents

Agents : une ligne par agent qui a remonté des données, avec son niveau de contrôle et son propriétaire.

app.openlatch.ai/agents/ci-runner-payments-01/identity

L’onglet Identity d’un agent : la personne à qui ses actions sont attribuées, et sa place dans l’organisation.

Déployer par vagues

Trois vagues de deux semaines, chacune prouvant quelque chose dont la suivante dépend. La vague 1 prouve l’installation par le parcours développeur. La vague 2 prouve la voie gérée. La vague 3 prouve le périmètre. Émettez un identifiant client par vague et révoquez-le dans la console quand la vague se termine.

Attribut	Vague 1	Vague 2	Vague 3
Périmètre	Environ dix machines de développeurs	Environ cinquante machines	Le périmètre complet
Voie d’installation	Parcours développeur, dans le terminal du développeur	Voie gérée, sans surveillance	Voie gérée, sans surveillance
Durée	Deux semaines	Deux semaines	Deux semaines
Activité	Inscrire chaque machine, la vérifier, relancer les agents qui attendent encore leur développeur, et noter ce que les personnes rencontrent	Empaqueter l’installation, la prouver sur une machine de chaque système d’exploitation, puis la lancer sans surveillance et lire le rapport qu’elle collecte	Lancer le même paquet sur tout le périmètre, et relancer les machines qui ne remontent jamais
Critères d’entrée	L’organisation est configurée, et un identifiant est émis pour la vague	La vague 1 a rempli ses critères de sortie, et le script géré tourne proprement sur une machine de chaque système d’exploitation	La voie gérée est prouvée sur chaque système d’exploitation du parc, et le type de proxy est confirmé sur chaque sous-réseau concerné
Critères de sortie	Chaque machine inscrite remonte à la console dans les 24 heures suivant l’installation ; openlatch doctor ne signale aucun problème sur chacune ; aucun agent n’attend son développeur ; la route du proxy est confirmée sur chaque système d’exploitation de la vague	Les quatre mêmes, plus chaque machine installée sans qu’un développeur ouvre de terminal	Les quatre mêmes, plus la décision de passer en exploitation courante
Retour arrière	openlatch uninstall sur la machine concernée	Le même, livré par l’outil qui a installé	Le même, livré par l’outil qui a installé

Figure 1. Trois vagues, ce que chacune prouve, et la porte entre elles.

Problèmes les plus probables

Symptôme	Cause probable	Que faire
La machine remonte, mais un de ses agents n’est pas raccordé	Cet agent n’était pas installé au moment de l’installation, ou sa configuration se trouve à un chemin personnalisé	Installez l’agent, puis relancez openlatch init sur la machine. Le client est déjà là : aucun téléchargement n’est nécessaire. Si le chemin est personnalisé, définissez-le dans l’environnement de l’inscription
Un agent est indiqué en attente	Certains agents demandent au développeur de confirmer la connexion une fois, au premier lancement après l’installation	Faites ouvrir l’agent une fois au développeur pour qu’il confirme. Si le parc verrouille la configuration des agents de façon centralisée, livrez la connexion par ce canal géré
Les politiques n’arrivent jamais sur la machine	La machine n’a pas atteint la console depuis son installation, ou son identifiant a été révoqué ou renouvelé	Confirmez d’abord la route de sortie, selon Exigences réseau. Si l’identifiant a été refusé, émettez-en un pour la vague et relancez l’installation
La machine est connectée, mais ses agents se comportent comme si rien n’était là	Les points d’accès de modèles des agents sont bloqués au proxy, ou leurs réponses en flux sont mises en tampon	Exemptez ces points d’accès de la mise en tampon des réponses et de l’inspection des flux. C’est le trafic propre des agents, qui doit rester joignable comme avant
La machine n’apparaît jamais dans la console	La route de sortie est bloquée, ou l’inscription n’est jamais allée au bout	Lancez openlatch doctor sur la machine. Il nomme ce qui a échoué, ce qui distingue un problème de proxy d’une installation interrompue

En bref

• Une installation est vérifiée quand openlatch doctor ne signale aucun problème et que la console montre les agents de la machine, chacun avec un niveau de contrôle et un propriétaire déterminé.
• openlatch status indique si la machine est couverte. openlatch doctor le prouve, avec une cause et un remède pour chaque point relevé.
• openlatch doctor --rescue constitue une archive expurgée avec le diagnostic, la configuration et une fenêtre récente des enregistrements locaux. Ouvrez chaque demande de support avec elle.
• Un agent qui attend encore que son développeur confirme la connexion est connecté sur le papier mais pas dans les faits. Relancez ces cas avant de clore une vague.
• Trois vagues de deux semaines : environ dix machines de développeurs, environ cinquante par la voie gérée, puis le périmètre. Un identifiant client par vague, révoqué quand la vague se termine.