Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Configurez votre appareil pour exécuter des tests IDT Pour permettre à IDT d'exécuter des tests de qualification des appareils, vous devez configurer votre ordinateur hôte pour accéder à votre appareil et configurer les autorisations utilisateur sur votre appareil. ## Installation de Java sur l'ordinateur hôte À partir de la version 4.2.0 d'IDT, les tests de qualification facultatifs AWS IoT Greengrass nécessitent l'exécution de Java. Vous pouvez utiliser la version 8 ou supérieure de Java. Nous vous recommandons d'utiliser les versions de support à long terme d'[Amazon Corretto](https://aws.amazon.com/corretto/) [ou](https://openjdk.java.net/) d'OpenJDK. La version 8 ou supérieure est requise. ## Configurer votre ordinateur hôte pour accéder à l'appareil testé IDT s'exécute sur votre ordinateur hôte et doit être en mesure d'utiliser SSH pour se connecter à votre appareil. Il existe deux options pour permettre à IDT d'obtenir un accès SSH à vos appareils testés : 1. Suivez les instructions indiquées ici pour créer une paire de clés SSH et autoriser votre clé à se connecter à votre appareil testé sans spécifier de mot de passe. 1. Fournissez un nom d'utilisateur et un mot de passe pour chaque appareil du fichier `device.json`. Pour de plus amples informations, veuillez consulter [Configurer device.json](set-config.md#device-config). Vous pouvez utiliser n'importe quelle implémentation SSL pour créer une clé SSH. Les instructions suivantes vous montrent comment utiliser [SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) ou [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (pour Windows). Si vous utilisez une autre implémentation SSL, veuillez vous reporter à la documentation correspondante. IDT utilise les clés SSH pour s'authentifier avec votre appareil testé. **Pour créer une clé SSH avec SSH-KEYGEN** 1. Créez une clé SSH. Vous pouvez utiliser la commande **ssh-keygen** Open SSH pour créer une paire de clés SSH. Si vous disposez déjà d'une paire de clés SSH sur votre ordinateur hôte, la bonne pratique consiste à créer une paire de clés SSH spécifique pour IDT. Ainsi, une fois que vous avez terminé le test, votre ordinateur hôte ne peut plus se connecter à votre appareil sans saisir de mot de passe. Cela vous permet également de restreindre l'accès à l'appareil à distance aux seules personnes qui en ont besoin. **Note** Windows n'a pas de client SSH installé. Pour plus d'informations sur l'installation d'un client SSH sous Windows, consultez [Download SSH Client Software](https://www.ssh.com/ssh/#sec-Download-client-software). La commande **ssh-keygen** vous invite à indiquer un nom et un chemin d'accès pour stocker la paire de clés. Par défaut, les fichiers de la paire de clés sont nommés `id_rsa` (clé privée) et `id_rsa.pub` (clé publique). Sur Mac OS et Linux, l'emplacement par défaut de ces fichiers est `~/.ssh/`. Sur Windows, l'emplacement par défaut est `C:\Users\\.ssh`. Lorsque vous y êtes invité, saisissez une expression clé pour protéger votre clé SSH. Pour de plus amples informations, veuillez consulter [Generate a New SSH key](https://www.ssh.com/ssh/keygen/). 1. Ajoutez des clés SSH autorisées à l'appareil testé. IDT doit utiliser votre clé SSH privée pour se connecter à l'appareil testé. Pour autoriser votre clé SSH privée à se connecter à l'appareil testé, utilisez la commande **ssh-copy-id** à partir de votre ordinateur hôte. Cette commande ajoute votre clé publique au fichier `~/.ssh/authorized_keys` sur l'appareil testé. Par exemple : **\$1 ssh-copy-id **@**** Où *remote-ssh-user* sont le nom d'utilisateur utilisé pour vous connecter à votre appareil testé et *remote-device-ip* l'adresse IP de l'appareil testé sur lequel effectuer les tests ? Par exemple : **ssh-copy-id pi@192.168.1.5** Lorsque vous y êtes invité, entrez le mot de passe du nom d'utilisateur que vous avez spécifié dans la commande **ssh-copy-id**. **ssh-copy-id** suppose que la clé publique est nommée `id_rsa.pub` et est stockée à l'emplacement par défaut (sur Mac OS et Linux, `~/.ssh/` et sur Windows, `C:\Users\\.ssh`). Si vous avez donné à la clé publique un autre nom ou si vous l'avez stockée à un autre emplacement, vous devez spécifier le chemin d'accès qualifié complet de votre clé publique SSH à l'aide de l'option **-i** pour **ssh-copy-id** (par exemple, **ssh-copy-id -i \$1/my/path/myKey.pub**). Pour plus d'informations sur la création de clés SSH et la copie des clés publiques, consultez [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id). **Pour créer une clé SSH à l'aide de Pu TTYgen (Windows uniquement)** 1. Assurez-vous que le serveur et le client OpenSSH sont installés sur votre appareil testé. Pour plus d'informations, consultez [OpenSSH](https://www.openssh.com/). 1. Installez [Pu TTYgen](https://www.puttygen.com/) sur votre appareil en cours de test. 1. Ouvrez PuTTYgen. 1. Choisissez **Generate (Générer)** et déplacez le curseur de la souris dans la zone pour générer une clé privée. 1. Dans le menu **Conversions** choisissez **Export OpenSSH key**, et enregistrez la clé privée avec une extension de fichier `.pem`. 1. Ajoutez la clé publique au fichier `/home//.ssh/authorized_keys` sur l'appareil testé. 1. Copiez le texte de la clé publique depuis la TTYgen fenêtre Pu. 1. Utilisez PuTTY pour créer une session sur votre appareil testé. 1. À partir d'une invite de commande ou d'une fenêtre Windows Powershell, exécutez la commande suivante : **C:/**/putty.exe -ssh **@** ** 1. Lorsque vous y êtes invité, entrez le mot de passe de votre appareil. 1. Utilisez vi ou un autre éditeur de texte pour ajouter la clé publique au fichier `/home//.ssh/authorized_keys` sur votre appareil testé. 1. Mettez à jour votre fichier `device.json` avec votre nom d'utilisateur, l'adresse IP et le chemin d'accès au fichier de clé privée que vous venez d'enregistrer sur votre ordinateur hôte pour chaque appareil testé. Pour de plus amples informations, veuillez consulter [Configurer device.json](set-config.md#device-config). Assurez-vous de fournir le chemin d'accès complet et le nom de fichier à la clé privée et d'utiliser des barres obliques (« / »). Par exemple, pour le chemin Windows `C:\DT\privatekey.pem`, utilisez `C:/DT/privatekey.pem` dans le fichier `device.json`. ## Configuration des informations d'identification utilisateur pour les appareils Windows Pour qualifier un appareil Windows, vous devez configurer les informations d'identification utilisateur dans le LocalSystem compte de l'appareil testé pour les utilisateurs suivants : + L'utilisateur Greengrass par défaut ()`ggc_user`. + L'utilisateur que vous utilisez pour vous connecter à l'appareil testé. Vous configurez cet utilisateur dans le [`device.json`fichier](set-config.md#device-config). Vous devez créer chaque utilisateur du LocalSystem compte sur l'appareil testé, puis enregistrer le nom d'utilisateur et le mot de passe de l'utilisateur dans l'instance Credential Manager du LocalSystem compte. **Pour configurer les utilisateurs sur les appareils Windows** 1. Ouvrez l'invite de commande Windows (`cmd.exe`) en tant qu'administrateur. 1. Créez les utilisateurs dans le LocalSystem compte sur l'appareil Windows. Exécutez la commande suivante pour chaque utilisateur que vous souhaitez créer. Pour l'utilisateur Greengrass par défaut, remplacez par*user-name*. `ggc_user` *password*Remplacez-le par un mot de passe sécurisé. ``` net user /add user-name password ``` 1. Téléchargez et installez l'[PsExecutilitaire](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec) de Microsoft sur l'appareil. 1. Utilisez l' PsExec utilitaire pour stocker le nom d'utilisateur et le mot de passe de l'utilisateur par défaut dans l'instance Credential Manager du LocalSystem compte. Exécutez la commande suivante pour chaque utilisateur que vous souhaitez configurer dans Credential Manager. Pour l'utilisateur Greengrass par défaut, remplacez par*user-name*. `ggc_user` *password*Remplacez-le par le mot de passe utilisateur que vous avez défini précédemment. ``` psexec -s cmd /c cmdkey /generic:user-name /user:user-name /pass:password ``` S'il **PsExec License Agreement**s'ouvre, choisissez **Accept**d'accepter la licence et exécutez la commande. **Note** Sur les appareils Windows, le LocalSystem compte exécute le noyau Greengrass, et vous devez utiliser l' PsExec utilitaire pour stocker les informations utilisateur dans le LocalSystem compte. L'application Credential Manager stocke ces informations dans le compte Windows de l'utilisateur actuellement connecté, plutôt que dans le LocalSystem compte. ## Configurer les autorisations utilisateur sur votre appareil IDT effectue des opérations sur différents répertoires et fichiers d'un appareil testé. Certaines de ces opérations nécessitent des autorisations d'un niveau élevé (à l'aide de la commande **sudo**). Pour automatiser ces opérations, IDT pour AWS IoT Greengrass V2 doit être capable d'exécuter des commandes avec sudo sans qu'un mot de passe ne soit demandé. Suivez ces étapes sur l'appareil testé afin d'autoriser l'accès sudo sans avoir à saisir un mot de passe. **Note** `username` fait référence à l'utilisateur SSH utilisé par IDT pour accéder à l'appareil testé. **Pour ajouter l'utilisateur au groupe sudo** 1. Sur l'appareil testé, exécutez `sudo usermod -aG sudo ` 1. Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur. 1. Vérifiez que votre nom d'utilisateur a été correctement ajouté et exécutez **sudo echo test**. Si vous n'êtes pas invité à saisir un mot de passe, cela signifie que votre utilisateur est configuré correctement. 1. Ouvrez le fichier `/etc/sudoers`, puis ajoutez la ligne suivante à la fin du fichier : ` ALL=(ALL) NOPASSWD: ALL` ## Configurer un rôle d'échange de jetons personnalisé Vous pouvez choisir d'utiliser un rôle IAM personnalisé comme rôle d'échange de jetons que le périphérique testé suppose d'interagir avec les AWS ressources. Pour plus d'informations sur la création d'un rôle IAM, consultez la section [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le Guide de l'utilisateur *IAM*. Vous devez satisfaire aux exigences suivantes pour permettre à IDT d'utiliser votre rôle IAM personnalisé. Nous vous recommandons vivement de n'ajouter que le minimum d'actions de stratégie requises à ce rôle. + Le fichier de configuration [userdata.json](set-config.md#custom-token-exchange-role-idt) doit être mis à jour pour que le `GreengrassV2TokenExchangeRole` paramètre soit défini sur. `true` + Le rôle IAM personnalisé doit être configuré avec la politique de confiance minimale suivante : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":[ "credentials.iot.amazonaws.com", "lambda.amazonaws.com", "sagemaker.amazonaws.com" ] }, "Action":"sts:AssumeRole" } ] } ``` ------ + Le rôle IAM personnalisé doit être configuré selon la politique d'autorisation minimale suivante : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:DescribeCertificate", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams", "iot:Connect", "iot:Publish", "iot:Subscribe", "iot:Receive", "iot:ListThingPrincipals", "iot:GetThingShadow", "iot:UpdateThingShadow", "s3:GetBucketLocation", "s3:GetObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource":"*" } ] } ``` ------ + Le nom du rôle IAM personnalisé doit correspondre à la ressource de rôle IAM que vous spécifiez dans les autorisations IAM pour l'utilisateur de test. Par défaut, la [politique des utilisateurs de test](dev-tst-prereqs.md#configure-idt-permissions) autorise l'accès aux rôles IAM dont le nom de rôle contient le `idt-` préfixe. Si le nom de votre rôle IAM n'utilise pas ce préfixe, ajoutez la `arn:aws:iam::*:role/custom-iam-role-name` ressource à l'`roleAliasResources`instruction et à l'`passRoleForResources`instruction dans votre politique utilisateur de test, comme indiqué dans les exemples suivants : **Example `passRoleForResources` déclaration** ``` { "Sid":"passRoleForResources", "Effect":"Allow", "Action":"iam:PassRole", "Resource":"arn:aws:iam::*:role/custom-iam-role-name", "Condition":{ "StringEquals":{ "iam:PassedToService":[ "iot.amazonaws.com", "lambda.amazonaws.com", "greengrass.amazonaws.com" ] } } } ``` **Example `roleAliasResources` déclaration** ``` { "Sid":"roleAliasResources", "Effect":"Allow", "Action":[ "iot:CreateRoleAlias", "iot:DescribeRoleAlias", "iot:DeleteRoleAlias", "iot:TagResource", "iam:GetRole" ], "Resource":[ "arn:aws:iot:*:*:rolealias/idt-*", "arn:aws:iam::*:role/custom-iam-role-name" ] } ``` ## Configurer votre appareil pour tester des fonctions facultatives Cette section décrit la configuration requise pour exécuter des tests IDT pour les fonctionnalités optionnelles de Docker et d'apprentissage automatique (ML). Les fonctionnalités ML ne sont prises en charge que dans IDT v4.9.3. Vous devez vous assurer que votre appareil répond à ces exigences uniquement si vous souhaitez tester ces fonctionnalités. Dans le cas contraire, passez à [Configurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification](set-config.md). **Topics** + [Exigences de qualification pour Docker](#idt-config-docker-components) + [Exigences de qualification ML](#idt-config-ml-components) + [Exigences de qualification HSM](#idt-config-hsm-components) ### Exigences de qualification pour Docker IDT for AWS IoT Greengrass V2 propose des tests de qualification Docker pour valider que vos appareils peuvent utiliser le composant du [gestionnaire d'applications Docker AWS](docker-application-manager-component.md) fourni pour télécharger des images de conteneur Docker que vous pouvez exécuter à l'aide de composants de conteneur Docker personnalisés. Pour plus d'informations sur la création de composants Docker personnalisés, consultez[Exécuter un conteneur Docker](run-docker-container.md). Pour exécuter les tests de qualification Docker, vos appareils testés doivent répondre aux exigences suivantes pour déployer le composant du gestionnaire d'applications Docker. + [Docker Engine](https://docs.docker.com/engine/) 1.9.1 ou version ultérieure installé sur le périphérique principal de Greengrass. La version 20.10 est la dernière version vérifiée pour fonctionner avec le logiciel AWS IoT Greengrass Core. Vous devez installer Docker directement sur le périphérique principal avant de déployer des composants qui exécutent des conteneurs Docker. + Le daemon Docker a démarré et s'est exécuté sur le périphérique principal avant que vous ne déployiez ce composant. + L'utilisateur du système qui exécute un composant de conteneur Docker doit disposer des autorisations root ou administrateur, ou vous devez configurer Docker pour l'exécuter en tant qu'utilisateur non root ou non administrateur. + Sur les appareils Linux, vous pouvez ajouter un utilisateur au `docker` groupe sans lequel vous pouvez appeler `docker` des commandes`sudo`. + Sur les appareils Windows, vous pouvez ajouter un utilisateur au `docker-users` groupe pour appeler des `docker` commandes sans privilèges d'administrateur. ------ #### [ Linux or Unix ] Pour ajouter `ggc_user` au `docker` groupe l'utilisateur non root que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante. ``` sudo usermod -aG docker ggc_user ``` Pour plus d'informations, consultez [Gérer Docker en tant qu'utilisateur non root](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user). ------ #### [ Windows Command Prompt (CMD) ] Pour ajouter `ggc_user` au `docker-users` groupe l'utilisateur que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante en tant qu'administrateur. ``` net localgroup docker-users ggc_user /add ``` ------ #### [ Windows PowerShell ] Pour ajouter `ggc_user` au `docker-users` groupe l'utilisateur que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante en tant qu'administrateur. ``` Add-LocalGroupMember -Group docker-users -Member ggc_user ``` ------ ### Exigences de qualification ML **Note** La fonctionnalité d'apprentissage automatique n'est prise en charge que dans IDT v4.9.3. IDT for AWS IoT Greengrass V2 propose des tests de qualification ML pour valider que vos appareils peuvent utiliser les [composants d'apprentissage automatique AWS](machine-learning-components.md) fournis pour effectuer une inférence ML localement à l'aide des frameworks [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) ou [TensorFlow Lite](https://www.tensorflow.org/lite/guide/python) ML. Pour plus d'informations sur l'exécution de l'inférence ML sur les appareils Greengrass, consultez. [Exécuter l'inférence de Machine Learning](perform-machine-learning-inference.md) Pour exécuter des tests de qualification ML, vos appareils testés doivent répondre aux exigences suivantes pour déployer les composants d'apprentissage automatique. + Sur les appareils principaux de Greengrass exécutant Amazon Linux 2 ou Ubuntu 18.04, la version 2.27 ou ultérieure de la [bibliothèque GNU C](https://www.gnu.org/software/libc/) (glibc) est installée sur l'appareil. + Sur les appareils ARMv7L, tels que le Raspberry Pi, les dépendances pour OpenCV-Python sont installées sur l'appareil. Exécutez la commande suivante pour installer les dépendances. ``` sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev ``` + Les appareils Raspberry Pi qui exécutent le système d'exploitation Raspberry Pi Bullseye doivent répondre aux exigences suivantes : + NumPy 1.22.4 ou version ultérieure installée sur l'appareil. Raspberry Pi OS Bullseye inclut une version antérieure de NumPy. Vous pouvez donc exécuter la commande suivante pour effectuer la mise à niveau NumPy sur l'appareil. ``` pip3 install --upgrade numpy ``` + L'ancienne pile de caméras activée sur l'appareil. Raspberry Pi OS Bullseye inclut une nouvelle pile de caméras activée par défaut et non compatible. Vous devez donc activer la pile de caméras existante. **Pour activer l'ancienne pile de caméras** 1. Exécutez la commande suivante pour ouvrir l'outil de configuration du Raspberry Pi. ``` sudo raspi-config ``` 1. Sélectionnez **Options d'interface**. 1. Sélectionnez **Legacy camera** pour activer l'ancienne pile de caméras. 1. Redémarrez l'appareil Raspberry Pi. ### Exigences de qualification HSM AWS IoT Greengrass fournit un [composant fournisseur PKCS \$111](pkcs11-provider-component.md) à intégrer au module de sécurité matérielle (HSM) PKCS du périphérique. La configuration du HSM dépend de votre appareil et du module HSM que vous avez choisi. Tant que la configuration HSM attendue, telle que décrite dans les [paramètres de configuration IDT](set-config.md), est fournie, IDT disposera des informations nécessaires pour exécuter ce test de qualification des fonctionnalités optionnel.