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 em seu dispositivo.
Instale 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
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:
-
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.
-
Forneça um nome de usuário e uma senha para cada dispositivo no arquivo
device.json
. Para ter mais informações, consulte Configurar device.json.
Você pode usar qualquer implementação SSL para criar uma chave SSH. As instruções a seguir mostram como usar o SSH-KEYGEN
O IDT usa chaves SSH para autenticar com o dispositivo em teste.
Para criar uma chave SSH com SSH-KEYGEN
-
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
. 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) eid_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\
.<user-name>\.ssh
Quando solicitado, insira uma frase-chave para proteger sua chave SSH. Para obter mais informações, consulte Gerar uma chave SSH
. -
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: .$ ssh-copy-id
<remote-ssh-user>
@<remote-device-ip>
Onde
remote-ssh-user
está o nome de usuário usado para fazer login no seu dispositivo em teste eremote-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, eC:\Users\
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 ~/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<user-name>\.ssh
.
Para criar uma chave SSH usando o PuTTYgen (somente Windows)
-
Verifique se o servidor e o cliente OpenSSH estão instalados no dispositivo em teste. Para obter mais informações, consulte OpenSSH
. -
Instale o PuTTYgen
no dispositivo em teste. -
Abra o PuTTYgen.
-
Selecione Generate (Gerar) e mova o cursor do mouse dentro da caixa para gerar uma chave privada.
-
No menu Conversions (Conversões), selecione Export OpenSSH key (Exportar chave OpenSSH) e salve a chave privada com uma extensão de arquivo
.pem
. -
Adicione a chave pública ao arquivo
/home/
no dispositivo em teste.<user>
/.ssh/authorized_keys-
Copie o texto da chave pública da janela PuTTYgen.
-
Use o PuTTY para criar uma sessão no dispositivo em teste.
-
Em um prompt de comando ou janela Windows Powershell, execute o seguinte comando:
C:/
<path-to-putty>
/putty.exe -ssh<user>
@<dut-ip-address>
-
Quando solicitado, insira a senha do dispositivo.
-
Use vi ou outro editor de texto para anexar a chave pública ao arquivo
/home/
no dispositivo em teste.<user>
/.ssh/authorized_keys
-
-
-
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 ter mais informações, consulte Configurar device.json. Você deve fornecer o caminho completo e o nome do arquivo para a chave privada e usar barras ('/'). Por exemplo, para o caminho do WindowsC:\DT\privatekey.pem
, useC:/DT/privatekey.pem
no arquivodevice.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 device.jsonarquivo.
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
-
Abra o prompt de comando do Windows (
cmd.exe
) como administrador. -
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, substitua nome de usuário por.
ggc_user
Substitua a senha
por uma senha segura.net user /add
user-name
password
-
Baixe e instale o PsExecutilitário
da Microsoft no dispositivo. -
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 comando a seguir para cada usuário que você deseja configurar no Credential Manager.
Para o usuário padrão do Greengrass, substitua nome de usuário por.
ggc_user
Substitua asenha
pela senha do usuário que você definiu anteriormente.psexec -s cmd /c cmdkey /generic:
user-name
/user:user-name
/pass:password
Se for PsExec License Agreementaberto, escolha Acceptconcordar 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
-
No dispositivo em teste, execute
sudo usermod -aG sudo
.<username>
-
Saia e faça login novamente para que as alterações entrem em vigor.
-
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.
-
Abra o arquivo
/etc/sudoers
e adicione a linha a seguir ao final do arquivo:<ssh-username>
ALL=(ALL) NOPASSWD: ALL
Configurar uma função personalizada 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 no Guia do usuário do IAM.
Você deve atender aos seguintes requisitos para permitir que o IDT use sua função personalizada do IAM. É altamente recomendável que você adicione somente as ações políticas mínimas necessárias a essa função.
-
O arquivo de configuração userdata.json deve ser atualizado para definir o parâmetro como.
GreengrassV2TokenExchangeRole
true
-
A função personalizada do IAM deve ser configurada com a seguinte política de confiança mínima:
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":[ "credentials.iot.amazonaws.com", "lambda.amazonaws.com", "sagemaker.amazonaws.com" ] }, "Action":"sts:AssumeRole" } ] }
-
O papel personalizado do IAM deve ser configurado com a seguinte política de permissões mínimas:
{ "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 da função personalizada do IAM deve corresponder ao recurso de função 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 permite o acesso às funções do IAM que têm o
idt-
prefixo em seus nomes de função. Se o nome da sua função do IAM não usar esse prefixo, adicione oarn:aws:iam::*:role/
recurso àcustom-iam-role-name
roleAliasResources
declaração e apassRoleForResources
declaração na sua política de usuário de teste, conforme mostrado nos exemplos a seguir:exemplo 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" ] } } }exemplo 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 recursos opcionais do Docker e do Machine Learning (ML). Os recursos 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 recursos. Caso contrário, avance para Defina as configurações de IDT para executar o pacote de AWS IoT Greengrass qualificação.
Tópicos
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 que você pode executar usando componentes de contêiner Docker personalizados. Para obter informações sobre a criação de componentes personalizados do Docker, consulteExecute um contêiner Docker.
Para executar testes de qualificação do Docker, seus dispositivos em teste devem atender aos seguintes requisitos para implantar o componente Docker Application Manager.
-
Docker Engine
1.9.1 ou 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. Você deve 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 você deve 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
docker
grupo para chamardocker
comandos semsudo
. -
Em dispositivos Windows, você pode adicionar um usuário ao
docker-users
grupo para chamardocker
comandos sem privilégios de administrador.
-
Requisitos de qualificação de ML
nota
O recurso de aprendizado de máquina é suportado somente no 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 fornecidos para realizar inferência de ML localmente usando as estruturas Deep Learning Runtime
Para executar testes de qualificação de ML, seus dispositivos em teste devem atender aos seguintes requisitos para implantar os componentes de aprendizado de máquina.
-
Nos principais dispositivos do Greengrass que executam o Amazon Linux 2 ou o Ubuntu 18.04, a GNU C Library
(glibc) versão 2.27 ou posterior está instalada no dispositivo. -
Em dispositivos ARMv7L, como o Raspberry Pi, dependências do OpenCV-Python instaladas no dispositivo. Execute o comando a seguir 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 ativada no dispositivo. O Raspberry Pi OS Bullseye inclui uma nova pilha de câmeras que é ativada por padrão e não é compatível, portanto, você deve habilitar a pilha de câmeras antiga.
Para habilitar a pilha de câmeras antiga
-
Execute o comando a seguir para abrir a ferramenta de configuração do Raspberry Pi.
sudo raspi-config
-
Selecione Opções de interface.
-
Selecione Câmera antiga para ativar a pilha de câmeras antigas.
-
Reinicie o Raspberry Pi.
-
-
Requisitos de qualificação do HSM
AWS IoT Greengrass fornece o componente provedor PKCS #11 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, conforme documentada nas configurações do IDT, seja fornecida, o IDT terá as informações necessárias para executar esse teste opcional de qualificação de recursos.