Pièges à éviter

Lisez cette page avant chaque étape du déploiement. Chaque ligne indique ce que vous voyez quand le piège se referme, comment l’éviter, et la page qui contient la procédure complète. Les cinq premières lignes de la page de départ sont celles qui bloquent le plus de déploiements.

Avant l’arrivée de votre organisation

Piège	Ce que vous voyez	Comment l’éviter	Détails
Une règle de flux sortants qui autorise la console mais oublie les destinations nécessaires à l’installation	L’installation échoue avant que le client n’ait jamais atteint la console, et l’échec ressemble à un produit défaillant plutôt qu’à une route fermée	Autorisez le registre de paquets ou votre miroir, openlatch.ai pour les scripts d’installation, et github.com pour une installation par npm	Exigences réseau
Une autorisation par adresse IP	La route fonctionne un temps, puis se rompt	Il n’existe aucune plage d’adresses statique. Autorisez app.openlatch.ai par nom et par SNI	Exigences réseau
Un proxy uniquement NTLM	Le client ne peut s’authentifier auprès du proxy sur aucune machine	NTLM n’est pas pris en charge, par choix de conception. Prévoyez pour le client un chemin Kerberos (Negotiate) ou sans authentification avant la première vague	Exigences réseau
Un fichier de configuration automatique de proxy sur Linux	L’installation refuse la route par configuration automatique	Définissez la route explicitement sur Linux. La configuration automatique n’est évaluée par le système d’exploitation que sur Windows et macOS	Exigences réseau
Des points d’accès de modèles mis en tampon ou inspectés en flux par un proxy	L’agent semble se figer, puis affiche tout d’un coup	Gardez les points d’accès que vos agents atteignent déjà exemptés de la mise en tampon des réponses et de l’inspection des flux	Exigences réseau
Une plateforme non prise en charge dans la vague	L’installation n’a aucun paquet pour la machine	Windows sur ARM64 et les distributions Linux basées sur musl, comme Alpine, ne sont pas pris en charge. Vérifiez les versions minimales dans la liste de contrôle	Liste de contrôle des prérequis
Une machine partagée traitée comme une seule installation	Seule la personne qui a fait l’installation est couverte	L’installation et l’état local sont propres à chaque utilisateur. Chaque utilisateur d’une machine partagée fait sa propre installation	Liste de contrôle des prérequis

À l’arrivée de votre organisation

Piège	Ce que vous voyez	Comment l’éviter	Détails
Se connecter pour la première fois sans l’invitation, ou depuis une autre adresse	La console vous fait créer une nouvelle organisation au lieu d’ouvrir la vôtre	Ouvrez le lien d’invitation, depuis l’adresse que vous avez donnée à votre contact OpenLatch	Premiers pas dans la console
Le navigateur d’un administrateur ne peut pas atteindre challenges.cloudflare.com	La vérification de connexion échoue à chaque fois	Autorisez-le pour les navigateurs qui se connectent à la console. Aucune machine qui exécute le client n’en a besoin	Exigences réseau
Attendre que l’assistant de configuration apparaisse	Le propriétaire invité d’une organisation créée par OpenLatch ne le voit jamais de lui-même	Ouvrez-le depuis Home › Reopen setup	Premiers pas dans la console
Se fier au seul test de connexion de l’authentification unique	Le test réussit, et les personnes ne peuvent toujours pas se connecter	Le test vérifie seulement que l’URL de métadonnées ou l’URL d’authentification du fournisseur d’identité répond. Enregistrez d’abord, puis testez, puis connectez-vous vous-même par SAML dans une fenêtre de navigation privée avant d’inviter qui que ce soit	Premiers pas dans la console
Des domaines de messagerie autorisés trop larges	Des personnes que vous n’avez pas invitées s’inscrivent dans l’organisation	Gardez les domaines restreints, et admettez tous les autres par invitation	Premiers pas dans la console
Inscrire un parc avec une clé personnelle	Une clé personnelle ne peut pas détenir host:enroll, seul son propriétaire la voit, et elle cesse de fonctionner quand cette personne part	Créez une clé d’organisation à partir de Host enrollment sur Settings › API keys, une par vague	Premiers pas dans la console
Désactiver Collect identity signals from endpoints	Aucun agent n’est jamais rattaché à un propriétaire	Laissez l’interrupteur activé partout où vous voulez que les agents soient attribués à une personne	Premiers pas dans la console
Laisser la conservation de l’audit à sa valeur par défaut	Une fois la purge automatique activée, les enregistrements au-delà de la durée sont purgés toutes les 24 heures	Définissez la durée de conservation et la purge automatique avant le début du déploiement	Premiers pas dans la console

Pendant le déploiement

Piège	Ce que vous voyez	Comment l’éviter	Détails
Révoquer la clé d’une vague avant que ses machines exécutent le client actuel	Une machine sur un client antérieur s’authentifie encore avec la clé : elle cesse de recevoir les mises à jour, et la console refuse sa clé (OL-1201)	Le client actuel échange la clé contre un identifiant d’hôte qui lui est propre et ne l’utilise plus une fois inscrit. Laissez la vague se mettre à jour avant de révoquer sa clé	Planifier le déploiement
Une clé passée en ligne de commande	Le client la refuse	Fournissez-la depuis votre coffre de secrets sous forme de fichier de clé, par --api-key-file ou OPENLATCH_API_KEY_FILE, ou par l’environnement sous le nom OPENLATCH_API_KEY. Considérez le corps d’un script de déploiement comme lisible	Déployer le client
Une route de proxy présente uniquement dans les variables du shell d’installation	La machine passe en direct après le redémarrage suivant	Le client démarre avec la session de l’utilisateur et n’hérite d’aucune variable du shell. Laissez l’installation enregistrer la route, ou transmettez-la avec openlatch init --proxy	Déployer le client
Un mot de passe de proxy dans l’URL du proxy	Le client refuse l’URL	Fournissez l’identifiant par OPENLATCH_PROXY ou par l’invite, qui le place dans un fichier chiffré lisible par son seul propriétaire	Déployer le client
Un hôte derrière un proxy sans exception pour le bouclage	Les appels de l’agent au client partent vers le proxy d’entreprise, qui répond par une erreur	Exportez NO_PROXY=127.0.0.1,localhost dans le shell qui lance l’agent, là où l’agent ne reçoit pas l’entrée à l’installation	Déployer le client
Installer le client avant les agents	Un agent installé ensuite n’est pas connecté	Installez d’abord les agents, ou relancez openlatch init ensuite. Une nouvelle exécution n’est jamais destructrice	Déployer le client
Une installation sans intervention sans --yes, ou sans clé	L’inscription ne peut pas poser de question, et s’arrête avec OL-1600	Lancez openlatch init --yes avec une clé d’inscription : --api-key-file, OPENLATCH_API_KEY_FILE ou OPENLATCH_API_KEY. Nommez l’organisation avec --org quand le compte appartient à plusieurs	Déployer le client
Déployer par la connexion dans le navigateur	Chaque machine attend une personne dotée d’un compte console devant un terminal, et une installation sans intervention s’arrête avec OL-1600	Déployez avec une clé d’organisation, pilote compris. La connexion par navigateur sert à essayer OpenLatch, ou à une personne sur sa propre machine	Déployer le client
Une clé saisie en ligne de commande pour une installation à la main	La clé se retrouve dans l’historique de votre shell	Lisez-la dans OPENLATCH_API_KEY sans la saisir sur la ligne, et effacez la variable après l’installation	Déployer le client
Intune traité comme un programme d’installation interactif	Des machines sont ignorées ou installées des jours plus tard	Lancez un script en contexte utilisateur qui va chercher la clé lui-même, attendez-vous à des affectations étalées sur plusieurs jours, et utilisez l’application Win32 quand une machine reçoit son premier agent après la fin des tentatives du script	Déployer le client
Une stratégie Jamf qui s’exécute en root	Une stratégie Jamf exécute normalement ses scripts en root : le client s’installe et s’inscrit pour root au lieu du développeur	Trouvez l’utilisateur connecté à la console et lancez l’installation et l’inscription en tant que cet utilisateur, avec launchctl asuser et sudo -u. Terminez en erreur quand personne n’est connecté, pour que le prochain check-in réessaie	Déployer le client
Élargir une vague trop tôt	Les problèmes trouvés dans la vague 1 se répètent sur cinquante machines	N’élargissez qu’une fois qu’une vague remplit ses critères de sortie, et lancez une installation gérée sur un échantillon avant le passage complet	Planifier le déploiement

Pendant la vérification

Piège	Ce que vous voyez	Comment l’éviter	Détails
Une machine qui tourne et ne couvre rien	Le client fonctionne et la console détient un enregistrement, mais un agent n’a jamais été raccordé	Ne comptez une machine comme terminée que lorsque openlatch doctor ne signale aucun problème	Vérifier chaque machine et chaque vague
Un agent qui attend encore son développeur	L’agent est connecté sur le papier mais pas en pratique	Certains agents demandent au développeur de confirmer la connexion une fois. Relancez ces cas avant de clôturer une vague	Vérifier chaque machine et chaque vague
S’attendre à voir la machine dans la console immédiatement	La machine manque juste après l’installation	Elle apparaît dans les 24 heures, et en quelques minutes sur un réseau sain. Une heure de dernière activité qui cesse d’avancer désigne la route	Vérifier chaque machine et chaque vague
Suivre un remède de connexion sur une machine déployée	openlatch doctor nomme openlatch system auth login, et la personne sur la machine n’a pas de compte console	Lancez plutôt openlatch init --yes avec une clé d’organisation	Déployer le client
Attendre un propriétaire sans annuaire connecté	L’agent est enregistré comme non attribué	Connectez un annuaire, ou demandez à un editor de désigner le propriétaire à la main	Premiers pas dans la console

Pendant l’exploitation

Piège	Ce que vous voyez	Comment l’éviter	Détails
Mettre à jour les fichiers sans redémarrer le client	La machine signale une incohérence de version	Terminez la fenêtre de maintenance par openlatch restart, ou par la déconnexion et la reconnexion que votre parc planifie déjà	Exploiter
Figer la version et désactiver aussi la vérification	Les machines cessent de signaler qu’une version plus récente existe	Figez avec OPENLATCH_AUTO_UPDATE=false et laissez OPENLATCH_UPDATE_CHECK actif	Exploiter
Une longue coupure	Au-delà du plafond de 100 Mo, les enregistrements non envoyés les plus anciens sont abandonnés, avec un avertissement OL-1204 dans le journal	Rétablissez la route avant que le plafond ne soit atteint ; les politiques continuent de décider pendant ce temps	Exploiter
Prendre une purge pour une désinstallation	Les fichiers installés et la ligne PATH restent sur la machine	openlatch uninstall --purge supprime le répertoire d’état et l’identifiant conservé. Supprimez les fichiers installés à part	Désinstaller
Supprimer un agent dans la console avant de désinstaller	L’agent revient avec l’événement suivant	Retirez d’abord le client de la machine	Désinstaller
Une réexécution planifiée de l’installation sur un hôte que vous avez coupé	La gestion des postes qui relance l’installation inscrit de nouveau l’hôte, et il compte de nouveau	Protégez la recette pour qu’elle n’inscrive qu’une fois : elle laisse un marqueur et saute l’inscription quand elle en trouve un. Sinon, sortez la machine du périmètre de la stratégie, ou révoquez la clé avec laquelle elle s’inscrit, avant de choisir Cut it off	Déployer le client
Bloquer la télémétrie au niveau du réseau	La machine perd aussi la console	La télémétrie et les rapports de plantage transitent avec le trafic propre du client. Désactivez-les plutôt sur le client	Traitement des données et sécurité
Le bundle du certificat de relais sur une URL publique, dans un dépôt ou dans une couche d’image	Rien au début ; quiconque le détient peut intercepter chaque machine qui lui fait confiance	Gardez le bundle dans votre coffre de secrets ; importez-le à l’exécution dans les conteneurs	Utiliser le certificat de relais de votre organisation
Le bundle, avec sa clé privée, poussé par la gestion des appareils	Le profil s’installe, et la clé atteint le canal de gestion de chaque machine	Ne poussez que relay-ca.cer, le certificat public	Utiliser le certificat de relais de votre organisation
Une clé EC écrite avec des paramètres de courbe explicites, ce qu’écrit LibreSSL par défaut sur macOS	L’installation sort avec le statut 8 et OL-2111	Utilisez la recette RSA 3072, ou une courbe nommée P-256 ou P-384	Utiliser le certificat de relais de votre organisation
L’installation lancée en root ou en SYSTEM	La CA de relais est approuvée pour le mauvais compte, et la personne sur la machine voit quand même la boîte de dialogue	Lancez l’installation en tant qu’utilisateur de la machine	Utiliser le certificat de relais de votre organisation
Un profil de configuration ouvert à la main sur macOS 13 ou version ultérieure	Le certificat n’est pas approuvé, et l’installation affiche la boîte de dialogue	Livrez-le par la gestion des appareils au niveau ordinateur, puis vérifiez avec openlatch doctor	Utiliser le certificat de relais de votre organisation