As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Configure seu dispositivo para executar testes de IDT Para permitir que o IDT execute testes de qualificação de dispositivos, você deve configurar seu computador host para acessar seu dispositivo e configurar as permissões de usuário nele. ## Instalar o Java no computador host A partir do IDT v4.2.0, os testes de qualificação opcionais AWS IoT Greengrass exigem que o Java seja executado. Você pode usar o Java versão 8 ou superior. Recomendamos que você use as versões de suporte de longo prazo do [Amazon Corretto](https://aws.amazon.com/corretto/) ou do [OpenJDK](https://openjdk.java.net/). A versão 8 ou superior é obrigatória. ## Configurar o computador host para acessar o dispositivo em teste O ITD é executado em seu computador host e deve ser capaz de usar o SSH para se conectar ao seu dispositivo. Há duas opções para permitir que o IDT obtenha acesso SSH aos dispositivos em teste: 1. Siga as instruções aqui para criar um par de chaves SSH e autorizar sua chave a fazer login no dispositivo em teste sem especificar uma senha. 1. Forneça um nome de usuário e uma senha para cada dispositivo no arquivo `device.json`. Para obter mais informações, consulte [Configurar device.json](set-config.md#device-config). Você pode usar qualquer implementação SSL para criar uma chave SSH. As instruções a seguir mostram como usar o [SSH-KEYGEN ou o](https://www.ssh.com/ssh/keygen/) [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (para Windows). Se você estiver usando outra implementação de SSL, consulte a documentação para essa implementação. O IDT usa chaves SSH para autenticar com o dispositivo em teste. **Para criar uma chave SSH com SSH-KEYGEN** 1. Crie uma chave SSH. Você pode usar o comando **ssh-keygen** Open SSH para criar um par de chaves SSH. Se você já tem um par de chaves SSH em seu computador host, é uma prática recomendada criar um par de chaves SSH especificamente para IDT. Dessa forma, depois de concluir o teste, o computador host não poderá mais se conectar ao dispositivo sem inserir uma senha. Ele também permite que você restrinja o acesso ao dispositivo remoto apenas para aqueles que precisam. **nota** O Windows não tem um cliente SSH instalado. Para obter informações sobre como instalar um cliente SSH no Windows, consulte [Fazer download do software cliente SSH](https://www.ssh.com/ssh/#sec-Download-client-software). O comando **ssh-keygen** solicita que você informe um nome e caminho para armazenar o par de chaves. Por padrão, os arquivos de pares de chaves são nomeados como `id_rsa` (chave privada) e `id_rsa.pub` (chave pública). No macOS e no Linux, o local padrão desses arquivos é `~/.ssh/`. No Windows, o local padrão é `C:\Users\\.ssh`. Quando solicitado, insira uma frase-chave para proteger sua chave SSH. Para obter mais informações, consulte [Gerar uma chave SSH](https://www.ssh.com/ssh/keygen/). 1. Adição de chaves SSH autorizadas ao seu dispositivo em teste. O ITD deve usar sua chave privada SSH para fazer login no seu dispositivo em teste. Para autorizar sua chave privada SSH a fazer login no seu dispositivo em teste, use o comando **ssh-copy-id** do seu computador host. Esse comando adiciona sua chave pública ao arquivo `~/.ssh/authorized_keys` no seu dispositivo em teste. Por exemplo: **\$1 ssh-copy-id **@**** Onde *remote-ssh-user* está o nome de usuário usado para fazer login no dispositivo em teste e *remote-device-ip* o endereço IP do dispositivo em teste para executar testes. Por exemplo: **ssh-copy-id pi@192.168.1.5** Quando solicitado, insira a senha para o nome de usuário especificado no comando **ssh-copy-id**. **ssh-copy-id** supõe que a chave pública chama-se `id_rsa.pub` e está armazenada no local padrão (`~/.ssh/` no macOS e no Linux, e `C:\Users\\.ssh` no Windows). Se você atribuiu à chave pública um nome diferente ou armazenou em um local diferente, você deve especificar o caminho para sua chave pública SSH usando a opção **-i** para **ssh-copy-id** (por exemplo, **ssh-copy-id -i \$1/my/path/myKey.pub**). Para obter mais informações sobre a criação de chaves SSH e a cópia de chaves públicas, consulte [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id). **Para criar uma chave SSH usando Pu TTYgen (somente Windows)** 1. Verifique se o servidor e o cliente OpenSSH estão instalados no dispositivo em teste. Para obter mais informações, consulte [OpenSSH](https://www.openssh.com/). 1. Instale o [Pu TTYgen](https://www.puttygen.com/) no seu dispositivo em teste. 1. Abra PuTTYgen. 1. Selecione **Generate (Gerar)** e mova o cursor do mouse dentro da caixa para gerar uma chave privada. 1. No menu **Conversions (Conversões)**, selecione **Export OpenSSH key (Exportar chave OpenSSH)** e salve a chave privada com uma extensão de arquivo `.pem`. 1. Adicione a chave pública ao arquivo `/home//.ssh/authorized_keys` no dispositivo em teste. 1. Copie o texto da chave pública da TTYgen janela Pu. 1. Use o PuTTY para criar uma sessão no dispositivo em teste. 1. Em um prompt de comando ou janela Windows Powershell, execute o seguinte comando: **C:/**/putty.exe -ssh **@** ** 1. Quando solicitado, insira a senha do dispositivo. 1. Use vi ou outro editor de texto para anexar a chave pública ao arquivo `/home//.ssh/authorized_keys` no dispositivo em teste. 1. Atualize o arquivo `device.json` com o nome de usuário, o endereço IP e o caminho para o arquivo da chave privada que você acabou de salvar no computador host para cada dispositivo em teste. Para obter mais informações, consulte [Configurar device.json](set-config.md#device-config). Você deve fornecer o caminho completo e o nome do arquivo para a chave privada e usar barras ('/'). Por exemplo, para o caminho do Windows `C:\DT\privatekey.pem`, use `C:/DT/privatekey.pem` no arquivo `device.json`. ## Configurar credenciais de usuário para dispositivos Windows Para qualificar um dispositivo baseado em Windows, você deve configurar as credenciais do usuário na LocalSystem conta do dispositivo em teste para os seguintes usuários: + O usuário padrão do Greengrass (`ggc_user`). + O usuário que você usa para se conectar ao dispositivo em teste. Você configura esse usuário no [arquivo `device.json`](set-config.md#device-config). Você deve criar cada usuário na LocalSystem conta no dispositivo em teste e, em seguida, armazenar o nome de usuário e a senha do usuário na instância do Credential Manager da LocalSystem conta. **Para configurar usuários em dispositivos Windows** 1. Abra o prompt de comando do Windows (`cmd.exe`) como um administrador. 1. Crie os usuários na LocalSystem conta no dispositivo Windows. Execute o comando a seguir para cada usuário que você deseja criar. Para o usuário padrão do Greengrass, *user-name* substitua por. `ggc_user` *password*Substitua por uma senha segura. ``` net user /add user-name password ``` 1. Baixe e instale o [PsExecutilitário](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec) da Microsoft no dispositivo. 1. Use o PsExec utilitário para armazenar o nome de usuário e a senha do usuário padrão na instância do Credential Manager da LocalSystem conta. Execute o seguinte comando para cada usuário que você deseja configurar no Gerenciador de Credenciais. Para o usuário padrão do Greengrass, *user-name* substitua por. `ggc_user` *password*Substitua pela senha do usuário que você definiu anteriormente. ``` psexec -s cmd /c cmdkey /generic:user-name /user:user-name /pass:password ``` Se **PsExec License Agreement** abrir, selecione **Accept** para concordar com a licença e execute o comando. **nota** Em dispositivos Windows, a LocalSystem conta executa o núcleo Greengrass, e você deve usar o PsExec utilitário para armazenar as informações do usuário na conta. LocalSystem O uso do aplicativo Credential Manager armazena essas informações na conta do Windows do usuário atualmente conectado, em vez da LocalSystem conta. ## Configurar permissões de usuário no dispositivo O ITD executa operações em vários diretórios e arquivos em um dispositivo em teste. Algumas dessas operações exigem permissões elevadas (usando **sudo**). Para automatizar essas operações, o IDT for AWS IoT Greengrass V2 deve ser capaz de executar comandos com sudo sem ser solicitado a fornecer uma senha. Siga estas etapas no dispositivo em teste para permitir o acesso ao sudo sem receber uma solicitação de senha. **nota** `username` refere-se ao usuário SSH usado pelo IDT para acessar o dispositivo em teste. **Para adicionar o usuário ao grupo sudo** 1. No dispositivo em teste, execute `sudo usermod -aG sudo `. 1. Saia e faça login novamente para que as alterações entrem em vigor. 1. Para verificar se o nome de usuário foi adicionado com êxito, execute **sudo echo test**. Se você não receber uma solicitação de senha, o usuário foi configurado corretamente. 1. Abra o arquivo `/etc/sudoers` e adicione a linha a seguir ao final do arquivo: ` ALL=(ALL) NOPASSWD: ALL` ## Configurar um perfil personalizado de troca de tokens Você pode optar por usar uma função personalizada do IAM como a função de troca de tokens que o dispositivo em teste presume interagir com os AWS recursos. Para aprender a criar perfis do IAM, consulte [Como criar perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) no *Guia do usuário do IAM*. Você deve atender aos seguintes requisitos para permitir que o IDT use o perfil do IAM personalizado. É altamente recomendável adicionar somente as ações de política mínimas necessárias a esse perfil. + O arquivo de configuração [userdata.json](set-config.md#custom-token-exchange-role-idt) deve ser atualizado para definir o parâmetro `GreengrassV2TokenExchangeRole` como `true`. + O perfil do IAM personalizado deve ser configurado com a seguinte política de confiança mínima: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":[ "credentials.iot.amazonaws.com", "lambda.amazonaws.com", "sagemaker.amazonaws.com" ] }, "Action":"sts:AssumeRole" } ] } ``` ------ + O perfil do IAM personalizado deve ser configurado com a seguinte política de permissões mínima: ------ #### [ 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":"*" } ] } ``` ------ + O nome do perfil do IAM personalizado deve corresponder ao recurso do perfil do IAM que você especifica nas permissões do IAM para o usuário de teste. Por padrão, a [política de usuário de teste](dev-tst-prereqs.md#configure-idt-permissions) permite o acesso aos perfis do IAM que têm o prefixo `idt-` nos nomes de perfil. Se o nome do perfil do IAM não usar esse prefixo, adicione o recurso `arn:aws:iam::*:role/custom-iam-role-name` à instrução `roleAliasResources` e a instrução `passRoleForResources` na sua política de usuário de teste, conforme mostrado nos exemplos a seguir: **Example Instrução `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 Instrução `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" ] } ``` ## Configurar seu dispositivo para testar atributos opcionais Esta seção descreve os requisitos do dispositivo para executar testes de IDT para atributos opcionais do Docker e do Machine Learning (ML). Os atributos de ML são compatíveis somente com o IDT v4.9.3. Você deve garantir que seu dispositivo atenda a esses requisitos somente se quiser testar esses atributos. Caso contrário, avance para [Defina as configurações de IDT para executar o pacote de AWS IoT Greengrass qualificação](set-config.md). **Topics** + [Requisitos de qualificação do Docker](#idt-config-docker-components) + [Requisitos de qualificação de ML](#idt-config-ml-components) + [Requisitos de qualificação do HSM](#idt-config-hsm-components) ### Requisitos de qualificação do Docker O IDT for AWS IoT Greengrass V2 fornece testes de qualificação do Docker para validar se seus dispositivos podem usar o componente [gerenciador de aplicativos Docker AWS fornecido para baixar imagens de contêiner do Docker](docker-application-manager-component.md) que você pode executar usando componentes de contêiner Docker personalizados. Para obter informações sobre como criar componentes personalizados do Docker, consulte [Executar um contêiner do Docker](run-docker-container.md). Para executar testes de qualificação do Docker, seus dispositivos em teste devem atender aos seguintes requisitos para implantar o componente gerenciador de aplicações do Docker. + [Docker Engine](https://docs.docker.com/engine/) 1.9.1 ou versão posterior instalado no dispositivo principal do Greengrass. A versão 20.10 é a versão mais recente verificada para funcionar com o software AWS IoT Greengrass Core. É preciso instalar o Docker diretamente no dispositivo principal antes de implantar componentes que executam contêineres do Docker. + O daemon do Docker foi iniciado e executado no dispositivo principal antes de você implantar esse componente. + O usuário do sistema que executa um componente de contêiner do Docker deve ter permissões de raiz ou administrador, ou é necessário configurar o Docker para executá-lo como usuário não raiz ou não administrador. + Em dispositivos Linux, você pode adicionar um usuário ao grupo `docker` para chamar os comandos `docker` sem `sudo`. + Em dispositivos Windows, é possível adicionar um usuário ao grupo `docker-users` para chamar comandos do `docker` sem privilégios de administrador. ------ #### [ Linux or Unix ] Para adicionar `ggc_user` ou o usuário não raiz que você usa para executar componentes de contêiner do Docker ao grupo de `docker`, execute o seguinte comando. ``` sudo usermod -aG docker ggc_user ``` Para obter mais informações, consulte [Gerenciar o Docker como um usuário não raiz](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user). ------ #### [ Windows Command Prompt (CMD) ] Para adicionar `ggc_user` ou o usuário que você usa para executar componentes de contêiner do Docker ao grupo de `docker-users`, execute o seguinte comando como administrador. ``` net localgroup docker-users ggc_user /add ``` ------ #### [ Windows PowerShell ] Para adicionar `ggc_user` ou o usuário que você usa para executar componentes de contêiner do Docker ao grupo de `docker-users`, execute o seguinte comando como administrador. ``` Add-LocalGroupMember -Group docker-users -Member ggc_user ``` ------ ### Requisitos de qualificação de ML **nota** O atributo de machine learning é compatível somente com o IDT v4.9.3. [O IDT for AWS IoT Greengrass V2 fornece testes de qualificação de ML para validar se seus dispositivos podem usar os [componentes de aprendizado AWS de máquina](machine-learning-components.md) fornecidos para realizar inferência de ML localmente usando as estruturas [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) ou Lite ML. TensorFlow ](https://www.tensorflow.org/lite/guide/python) Para mais informações sobre como executar a inferência de ML em dispositivos do Greengrass, consulte [Executar a inferência de machine learning](perform-machine-learning-inference.md). Para executar testes de qualificação de ML, seus dispositivos em teste devem atender aos seguintes requisitos para implantar os componentes de machine learning. + Nos dispositivos principais do Greengrass que executam o Amazon Linux 2 ou o Ubuntu 18.04, a [Biblioteca do GNU C](https://www.gnu.org/software/libc/) (glibc) versão 2.27 ou posterior está instalada no dispositivo. + Em dispositivos Armv7l, como o Raspberry Pi, as dependências do OpenCV-Python estão instaladas no dispositivo. Execute o seguinte comando para instalar as dependências. ``` sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev ``` + Os dispositivos Raspberry Pi que executam o Raspberry Pi OS Bullseye devem atender aos seguintes requisitos: + NumPy 1.22.4 ou posterior instalado no dispositivo. O Raspberry Pi OS Bullseye inclui uma versão anterior do NumPy, então você pode executar o seguinte comando para atualizar NumPy o dispositivo. ``` pip3 install --upgrade numpy ``` + A pilha de câmeras antiga habilitada no dispositivo. O Raspberry Pi OS Bullseye inclui uma nova pilha de câmeras que está habilitada por padrão e não é compatível, portanto você precisa habilitar a pilha de câmeras antiga. **Para habilitar a pilha de câmeras antiga** 1. Execute o comando abaixo para abrir a ferramenta de configuração do Raspberry Pi. ``` sudo raspi-config ``` 1. Selecione **Opções de interface**. 1. Selecione **Câmera antiga** para habilitar a pilha de câmeras antiga. 1. Reinicie o Raspberry Pi. ### Requisitos de qualificação do HSM AWS IoT Greengrass fornece o [componente provedor PKCS \$111](pkcs11-provider-component.md) para integração com o Módulo de Segurança de Hardware (HSM) PKCS no dispositivo. A configuração do HSM depende do seu dispositivo e do módulo HSM que você escolheu. Desde que a configuração esperada do HSM seja fornecida, conforme documentado nas [definições de configuração do IDT](set-config.md), o IDT terá as informações necessárias para executar esse teste opcional de qualificação de atributos.