Configurez votre appareil pour exécuter des tests IDT - AWS IoT Greengrass

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 ou 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.

  2. Fournissez un nom d'utilisateur et un mot de passe pour chaque appareil du fichier device.json. Pour plus d’informations, consultez Configurer device.json.

Vous pouvez utiliser n'importe quelle implémentation SSL pour créer une clé SSH. Les instructions suivantes vous montrent comment utiliser SSH-KEYGEN ou 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.

    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\<user-name>\.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.

  2. 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 :

    $ ssh-copy-id <remote-ssh-user>@<remote-device-ip>

    remote-ssh-usersont le nom d'utilisateur utilisé pour vous connecter à votre appareil testé et remote-device-ipl'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\<user-name>\.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 ~/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.

Pour créer une clé SSH à l'aide de PuTTYgen (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.

  2. Installez PuTTYgen sur votre appareil testé.

  3. Ouvrez PuTTYgen.

  4. Choisissez Generate (Générer) et déplacez le curseur de la souris dans la zone pour générer une clé privée.

  5. Dans le menu Conversions choisissez Export OpenSSH key, et enregistrez la clé privée avec une extension de fichier .pem.

  6. Ajoutez la clé publique au fichier /home/<user>/.ssh/authorized_keys sur l'appareil testé.

    1. Copiez le texte de la clé publique à partir de la fenêtre PuTTYgen.

    2. 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:/<path-to-putty>/putty.exe -ssh <user>@<dut-ip-address>

      2. Lorsque vous y êtes invité, entrez le mot de passe de votre appareil.

      3. Utilisez vi ou un autre éditeur de texte pour ajouter la clé publique au fichier /home/<user>/.ssh/authorized_keys sur votre appareil testé.

  7. 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 plus d’informations, consultez Configurer device.json. 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.jsonfichier.

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.

  2. 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 le nom d'utilisateur par. ggc_user Remplacez le mot de passe par un mot de passe sécurisé.

    net user /add user-name password
  3. Téléchargez et installez l'PsExecutilitaire de Microsoft sur l'appareil.

  4. 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 le nom d'utilisateur par. ggc_user Remplacez le mot de passe par le mot de passe de l'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 Agreements'ouvre, choisissez Acceptd'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 <username>

  2. Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur.

  3. 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.

  4. Ouvrez le fichier /etc/sudoers, puis ajoutez la ligne suivante à la fin du fichier :

    <ssh-username> 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 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 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 :

    { "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 :

    { "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 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'roleAliasResourcesinstruction et à l'passRoleForResourcesinstruction dans votre politique utilisateur de test, comme indiqué dans les exemples suivants :

    Exemple 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" ] } } }
    Exemple 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.

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 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, consultezExécuter un conteneur Docker.

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 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 commandessudo.

    • 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.

    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 fournis pour effectuer une inférence ML localement à l'aide des frameworks Deep Learning Runtime ou TensorFlow Lite 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

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 (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
      2. Sélectionnez Options d'interface.

      3. Sélectionnez Legacy camera pour activer l'ancienne pile de caméras.

      4. Redémarrez l'appareil Raspberry Pi.

Exigences de qualification HSM

AWS IoT Greengrass fournit un composant fournisseur PKCS #11 à 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, est fournie, IDT disposera des informations nécessaires pour exécuter ce test de qualification des fonctionnalités optionnel.