Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Configura il tuo dispositivo per eseguire test IDT Per consentire a IDT di eseguire test per la qualificazione dei dispositivi, è necessario configurare il computer host per accedere al dispositivo e configurare le autorizzazioni utente sul dispositivo. ## Installa Java sul computer host A partire da IDT v4.2.0, i test di qualificazione opzionali AWS IoT Greengrass richiedono l'esecuzione di Java. È possibile utilizzare Java versione 8 o successiva. Ti consigliamo di utilizzare le versioni di supporto a lungo termine di [Amazon Corretto](https://aws.amazon.com/corretto/) o [OpenJDK](https://openjdk.java.net/). È richiesta la versione 8 o successiva. ## Configurazione del computer host per l'accesso al dispositivo sottoposto a test IDT viene eseguito sul computer host e deve essere in grado di utilizzare SSH per connettersi al dispositivo. Sono disponibili due opzioni per consentire a IDT di ottenere l'accesso SSH ai dispositivi sottoposti a test: 1. Segui le istruzioni contenute in questa pagina per creare una coppia di chiavi SSH e autorizzare la chiave ad accedere al dispositivo sottoposto a test senza specificare una password. 1. Fornisci un nome utente e una password per ogni dispositivo nel file `device.json`. Per ulteriori informazioni, consulta [Configura dispositivo.json](set-config.md#device-config). Puoi utilizzare qualsiasi implementazione SSL per creare una chiave SSH. Le seguenti istruzioni mostrano come usare [SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) o [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (per Windows). Se stai utilizzando un'altra implementazione SSL, consulta la documentazione dell'applicazione. IDT utilizza chiavi SSH per eseguire l'autenticazione con il dispositivo sottoposto a test. **Per creare una chiave SSH con SSH-KEYGEN** 1. Crea una chiave SSH. Puoi utilizzare il comando Open SSH **ssh-keygen** per creare una coppia di chiavi SSH. Se disponi già di una coppia di chiavi SSH sul computer host, una best practice è creare una coppia di chiavi SSH appositamente per IDT. In questo modo, dopo aver completato il test, il computer host non può più connettersi al dispositivo senza immettere una password. Ciò consente inoltre di limitare l'accesso al dispositivo remoto solo a coloro che ne hanno bisogno. **Nota** Windows non dispone di un client SSH installato. Per informazioni sull'installazione di un client SSH in Windows, consulta [Download del software client SSH](https://www.ssh.com/ssh/#sec-Download-client-software). Il comando **ssh-keygen** richiede di specificare un nome e un percorso di archiviazione della coppia di chiavi. Per impostazione predefinita, i file della coppia di chiavi sono `id_rsa` (chiave privata) e `id_rsa.pub` (chiave pubblica). In macOS e Linux, il percorso predefinito di questi file è `~/.ssh/`. In Windows, la posizione predefinita è `C:\Users\\.ssh`. Quando richiesto, immetti una frase chiave per proteggere la chiave SSH. Per ulteriori informazioni, consulta l'argomento relativo alla [generazione di una nuova chiave SSH](https://www.ssh.com/ssh/keygen/). 1. Aggiungi chiavi SSH autorizzate al dispositivo sottoposto a test. IDT deve utilizzare la chiave privata SSH per accedere al dispositivo sottoposto al test. Per autorizzare le chiavi SSH private per accedere al dispositivo sottoposto a test, utilizza il comando **ssh-copy-id** dal computer host. Questo comando aggiunge la chiave pubblica al file `~/.ssh/authorized_keys` nel dispositivo sottoposto a test. Esempio: **\$1 ssh-copy-id **@**** *remote-ssh-user*Dov'è il nome utente usato per accedere al dispositivo sottoposto a test e *remote-device-ip* l'indirizzo IP del dispositivo sottoposto a test su cui eseguire i test. Esempio: **ssh-copy-id pi@192.168.1.5** Quando richiesto, immetti la password per il nome utente specificato nel comando **ssh-copy-id**. **ssh-copy-id** presuppone che la chiave pubblica sia denominata `id_rsa.pub` e sia archiviata nella posizione predefinita (in macOS e Linux `~/.ssh/` e in Windows `C:\Users\\.ssh`). Se hai attribuito un nome diverso alla chiave pubblica o la hai archiviata in una posizione diversa, devi specificare il percorso completo della chiave pubblica SSH con l'opzione **-i** di **ssh-copy-id**, ad esempio **ssh-copy-id -i \$1/my/path/myKey.pub**. Per ulteriori informazioni sulla creazione di chiavi SSH e sulla copia di chiavi pubbliche, consulta [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id). **Per creare una chiave SSH usando Pu TTYgen (solo Windows)** 1. Assicurati di aver installato il server e il client OpenSSH sul dispositivo sottoposto a test. Per ulteriori informazioni, consulta [OpenSSH](https://www.openssh.com/). 1. Installa [Pu TTYgen](https://www.puttygen.com/) sul tuo dispositivo in fase di test. 1. Apri PuTTYgen. 1. Scegli **Generate (Genera)** e sposta il cursore del mouse all'interno della casella per generare una chiave privata. 1. Dal menu **Conversions (Conversioni)**, scegli **Export OpenSSH key (Esporta chiave OpenSSH)** e salvare la chiave privata con un'estensione di file `.pem`. 1. Aggiungi la chiave pubblica al file `/home//.ssh/authorized_keys` sul dispositivo sottoposto a test. 1. Copia il testo della chiave pubblica dalla TTYgen finestra Pu. 1. Utilizza PuTTY per creare una sessione sul dispositivo sottoposto a test. 1. Da un prompt dei comandi o dalla finestra Windows Powershell, esegui il comando seguente: **C:/**/putty.exe -ssh **@** ** 1. Quando richiesto, immetti la password del dispositivo. 1. Utilizza vi o un altro editor di testo per aggiungere la chiave pubblica al file `/home//.ssh/authorized_keys` sul dispositivo sottoposto a test. 1. Aggiorna il file `device.json` con il nome utente, l'indirizzo IP e il percorso al file della chiave privata appena salvato sul computer host per ogni dispositivo sottoposto a test. Per ulteriori informazioni, consulta [Configura dispositivo.json](set-config.md#device-config). Assicurati di fornire il percorso completo e il nome di file per la chiave privata e utilizza le barre ("/"). Ad esempio, per il percorso di Windows `C:\DT\privatekey.pem`, utilizza `C:/DT/privatekey.pem` nel file `device.json`. ## Configura le credenziali utente per i dispositivi Windows Per qualificare un dispositivo basato su Windows, è necessario configurare le credenziali utente nell'LocalSystem account sul dispositivo in esame per i seguenti utenti: + L'utente Greengrass predefinito ()`ggc_user`. + L'utente che usi per connetterti al dispositivo in prova. Questo utente viene configurato nel [`device.json`file](set-config.md#device-config). È necessario creare ogni utente nell' LocalSystem account sul dispositivo in esame, quindi memorizzare il nome utente e la password dell'utente nell'istanza di Credential Manager dell'LocalSystem account. **Per configurare gli utenti sui dispositivi Windows** 1. Apri il prompt dei comandi di Windows (`cmd.exe`) come amministratore. 1. Crea gli utenti nell' LocalSystem account sul dispositivo Windows. Esegui il comando seguente per ogni utente che desideri creare. Per l'utente Greengrass predefinito, sostituire *user-name* con. `ggc_user` Sostituisci *password* con una password sicura. ``` net user /add user-name password ``` 1. Scarica e installa l'[PsExecutilità](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec) di Microsoft sul dispositivo. 1. Utilizzate l' PsExec utilità per memorizzare il nome utente e la password per l'utente predefinito nell'istanza di Credential Manager per l' LocalSystem account. Eseguite il comando seguente per ogni utente che desiderate configurare in Credential Manager. Per l'utente Greengrass predefinito, sostituire *user-name* con. `ggc_user` Sostituisci *password* con la password dell'utente che hai impostato in precedenza. ``` psexec -s cmd /c cmdkey /generic:user-name /user:user-name /pass:password ``` Se si **PsExec License Agreement**apre, scegli **Accept**di accettare la licenza ed esegui il comando. **Nota** Sui dispositivi Windows, l' LocalSystem account esegue il nucleo Greengrass ed è necessario utilizzare l' PsExec utilità per memorizzare le informazioni utente nell'account. LocalSystem L'utilizzo dell'applicazione Credential Manager archivia queste informazioni nell'account Windows dell'utente attualmente connesso, anziché nell'account. LocalSystem ## Configurazione delle autorizzazioni utente sul dispositivo IDT esegue operazioni su varie directory e file in un dispositivo sottoposto a test. Alcune di queste operazioni richiedono autorizzazioni elevate (utilizzando **sudo**). Per automatizzare queste operazioni, IDT per AWS IoT Greengrass V2 deve essere in grado di eseguire comandi con sudo senza che venga richiesta una password. Segui questi passaggi sul dispositivo sottoposto a test per consentire al comando sudo di accedere senza che venga richiesta una password. **Nota** `username` fa riferimento all'utente SSH utilizzato da IDT per accedere al dispositivo sottoposto a test. **Per aggiungere l'utente al gruppo sudo** 1. Sul dispositivo sottoposto a test, esegui `sudo usermod -aG sudo `. 1. Per rendere effettive le modifiche, esci ed esegui di nuovo l'accesso. 1. Per verificare che il nome utente sia stato aggiunto correttamente, esegui **sudo echo test**. Se non viene è richiesta una password, l'utente è configurato correttamente. 1. Apri il file `/etc/sudoers`, quindi aggiungi la riga seguente alla fine del file: ` ALL=(ALL) NOPASSWD: ALL` ## Configura un ruolo di scambio di token personalizzato Puoi scegliere di utilizzare un ruolo IAM personalizzato come ruolo di scambio di token che il dispositivo sottoposto a test assume per interagire con AWS le risorse. Per informazioni sulla creazione di un ruolo IAM, consulta [Creating IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) nella *IAM User Guide*. È necessario soddisfare i seguenti requisiti per consentire a IDT di utilizzare il ruolo IAM personalizzato. Ti consigliamo vivamente di aggiungere solo le azioni politiche minime richieste a questo ruolo. + Il file di configurazione [userdata.json](set-config.md#custom-token-exchange-role-idt) deve essere aggiornato per impostare il parametro su. `GreengrassV2TokenExchangeRole` `true` + Il ruolo IAM personalizzato deve essere configurato con la seguente politica di fiducia minima: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":[ "credentials.iot.amazonaws.com", "lambda.amazonaws.com", "sagemaker.amazonaws.com" ] }, "Action":"sts:AssumeRole" } ] } ``` ------ + Il ruolo IAM personalizzato deve essere configurato con la seguente politica di autorizzazioni minime: ------ #### [ 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":"*" } ] } ``` ------ + Il nome del ruolo IAM personalizzato deve corrispondere alla risorsa del ruolo IAM specificata nelle autorizzazioni IAM per l'utente di test. Per impostazione predefinita, la [policy dell'utente di test](dev-tst-prereqs.md#configure-idt-permissions) consente l'accesso ai ruoli IAM che hanno il `idt-` prefisso nei nomi dei ruoli. Se il nome del tuo ruolo IAM non utilizza questo prefisso, aggiungi la `arn:aws:iam::*:role/custom-iam-role-name` risorsa all'`roleAliasResources`istruzione e all'`passRoleForResources`istruzione nella tua policy per l'utente di test, come mostrato negli esempi seguenti: **Example Dichiarazione `passRoleForResources`** ``` { "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 Dichiarazione `roleAliasResources`** ``` { "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" ] } ``` ## Configurazione del dispositivo per testare le funzionalità opzionali Questa sezione descrive i requisiti del dispositivo per eseguire i test IDT per le funzionalità opzionali di Docker e machine learning (ML). Le funzionalità ML sono supportate solo in IDT v4.9.3. Devi assicurarti che il tuo dispositivo soddisfi questi requisiti solo se desideri testare queste funzionalità. Altrimenti, passare a [Configurare le impostazioni IDT per eseguire la suite di AWS IoT Greengrass qualifiche](set-config.md). **Topics** + [Requisiti di qualificazione Docker](#idt-config-docker-components) + [Requisiti di qualificazione ML](#idt-config-ml-components) + [Requisiti di qualificazione HSM](#idt-config-hsm-components) ### Requisiti di qualificazione Docker IDT per AWS IoT Greengrass V2 fornisce test di qualificazione Docker per verificare che i dispositivi possano utilizzare il componente [Docker Application Manager AWS fornito per scaricare immagini di container Docker](docker-application-manager-component.md) che è possibile eseguire utilizzando componenti Docker container personalizzati. Per informazioni sulla creazione di componenti Docker personalizzati, consulta. [Esegui un contenitore Docker](run-docker-container.md) Per eseguire i test di qualificazione Docker, i dispositivi sottoposti a test devono soddisfare i seguenti requisiti per distribuire il componente Docker Application Manager. + [Docker Engine](https://docs.docker.com/engine/) 1.9.1 o versione successiva installato sul dispositivo principale Greengrass. La versione 20.10 è l'ultima versione verificata per funzionare con il software Core. AWS IoT Greengrass È necessario installare Docker direttamente sul dispositivo principale prima di distribuire componenti che eseguono contenitori Docker. + Il daemon Docker è stato avviato e funzionante sul dispositivo principale prima di distribuire questo componente. + L'utente di sistema che esegue un componente del contenitore Docker deve disporre delle autorizzazioni di root o di amministratore oppure è necessario configurare Docker per eseguirlo come utente non root o non amministratore. + Sui dispositivi Linux, puoi aggiungere un utente al gruppo senza il quale chiamare i comandi. `docker` `docker` `sudo` + Nei dispositivi Windows, è possibile aggiungere un utente al `docker-users` gruppo per richiamare `docker` comandi senza privilegi di amministratore. ------ #### [ Linux or Unix ] Per aggiungere `ggc_user` al `docker` gruppo l'utente non root che usi per eseguire i componenti del contenitore Docker, esegui il comando seguente. ``` sudo usermod -aG docker ggc_user ``` Per ulteriori informazioni, consulta [Gestire Docker come](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user) utente non root. ------ #### [ Windows Command Prompt (CMD) ] Per aggiungere al `docker-users` gruppo`ggc_user`, o l'utente che usi per eseguire i componenti del contenitore Docker, esegui il comando seguente come amministratore. ``` net localgroup docker-users ggc_user /add ``` ------ #### [ Windows PowerShell ] Per aggiungere al `docker-users` gruppo`ggc_user`, o l'utente che usi per eseguire i componenti del contenitore Docker, esegui il comando seguente come amministratore. ``` Add-LocalGroupMember -Group docker-users -Member ggc_user ``` ------ ### Requisiti di qualificazione ML **Nota** La funzionalità di apprendimento automatico è supportata solo in IDT v4.9.3. [https://github.com/neo-ai/neo-ai-dlr](https://github.com/neo-ai/neo-ai-dlr) Per ulteriori informazioni sull'esecuzione dell'inferenza ML sui dispositivi Greengrass, vedere. [Esecuzione dell'inferenza di Machine Learning](perform-machine-learning-inference.md) Per eseguire i test di qualificazione ML, i dispositivi sottoposti a test devono soddisfare i seguenti requisiti per implementare i componenti di machine learning. + Sui dispositivi core Greengrass che eseguono Amazon Linux 2 o Ubuntu 18.04, sul dispositivo è installata la versione 2.27 o successiva della [GNU C Library](https://www.gnu.org/software/libc/) (glibc). + Sui dispositivi ARMv7L, come Raspberry Pi, le dipendenze per OpenCV-Python sono installate sul dispositivo. Esegui il comando seguente per installare le dipendenze. ``` sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev ``` + I dispositivi Raspberry Pi che eseguono il sistema operativo Raspberry Pi Bullseye devono soddisfare i seguenti requisiti: + NumPy 1.22.4 o versione successiva installata sul dispositivo. Il sistema operativo Raspberry Pi Bullseye include una versione precedente di NumPy, quindi è possibile eseguire il seguente comando per l'aggiornamento del dispositivo. NumPy ``` pip3 install --upgrade numpy ``` + Lo stack di fotocamere legacy è abilitato sul dispositivo. Il sistema operativo Raspberry Pi Bullseye include un nuovo stack di fotocamere abilitato di default e non compatibile, quindi è necessario abilitare lo stack di fotocamere precedente. **Per abilitare lo stack di telecamere precedente** 1. Esegui il seguente comando per aprire lo strumento di configurazione Raspberry Pi. ``` sudo raspi-config ``` 1. Seleziona **Opzioni di interfaccia**. 1. Seleziona **Legacy camera** per abilitare lo stack di telecamere legacy. 1. Riavvia il dispositivo Raspberry Pi. ### Requisiti di qualificazione HSM AWS IoT Greengrass fornisce il [componente provider PKCS \$111](pkcs11-provider-component.md) da integrare con l'Hardware Security Module (HSM) PKCS sul dispositivo. La configurazione HSM dipende dal dispositivo e dal modulo HSM scelto. Se viene fornita la configurazione HSM prevista, documentata nelle [impostazioni di configurazione IDT, IDT disporrà](set-config.md) delle informazioni necessarie per eseguire questo test di qualificazione delle funzionalità opzionali.