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
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 :
-
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.
-
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
IDT utilise les clés SSH pour s'authentifier avec votre appareil testé.
Pour créer une clé SSH avec SSH-KEYGEN
-
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) etid_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 estC:\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
. -
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>
Où
remote-ssh-user
sont le nom d'utilisateur utilisé pour vous connecter à votre appareil testé etremote-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\
). 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<user-name>\.ssh
.
Pour créer une clé SSH à l'aide de PuTTYgen (Windows uniquement)
-
Assurez-vous que le serveur et le client OpenSSH sont installés sur votre appareil testé. Pour plus d'informations, consultez OpenSSH
. -
Installez PuTTYgen
sur votre appareil testé. -
Ouvrez PuTTYgen.
-
Choisissez Generate (Générer) et déplacez le curseur de la souris dans la zone pour générer une clé privée.
-
Dans le menu Conversions choisissez Export OpenSSH key, et enregistrez la clé privée avec une extension de fichier
.pem
. -
Ajoutez la clé publique au fichier
/home/
sur l'appareil testé.<user>
/.ssh/authorized_keys-
Copiez le texte de la clé publique à partir de la fenêtre PuTTYgen.
-
Utilisez PuTTY pour créer une session sur votre appareil testé.
-
À 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>
-
Lorsque vous y êtes invité, entrez le mot de passe de votre appareil.
-
Utilisez vi ou un autre éditeur de texte pour ajouter la clé publique au fichier
/home/
sur votre appareil testé.<user>
/.ssh/authorized_keys
-
-
-
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 WindowsC:\DT\privatekey.pem
, utilisezC:/DT/privatekey.pem
dans le fichierdevice.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
-
Ouvrez l'invite de commande Windows (
cmd.exe
) en tant qu'administrateur. -
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 lemot de passe
par un mot de passe sécurisé.net user /add
user-name
password
-
Téléchargez et installez l'PsExecutilitaire
de Microsoft sur l'appareil. -
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 lemot 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
-
Sur l'appareil testé, exécutez
sudo usermod -aG sudo
<username>
-
Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur.
-
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.
-
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 laarn:aws:iam::*:role/
ressource à l'custom-iam-role-name
roleAliasResources
instruction et à l'passRoleForResources
instruction 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.
Rubriques
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 appelerdocker
des commandessudo
. -
Sur les appareils Windows, vous pouvez ajouter un utilisateur au
docker-users
groupe pour appeler desdocker
commandes sans privilèges d'administrateur.
-
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
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
-
Exécutez la commande suivante pour ouvrir l'outil de configuration du Raspberry Pi.
sudo raspi-config
-
Sélectionnez Options d'interface.
-
Sélectionnez Legacy camera pour activer l'ancienne pile de caméras.
-
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.