

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# IDT テストを実行するようにデバイスを設定する
<a name="device-config-setup"></a>

IDT でデバイス認定のためのテストを実行するには、デバイスにアクセスするようにホストコンピュータを設定して、デバイス上でユーザーのアクセス許可を設定する必要があります。

## ホストコンピュータに Java をインストールする
<a name="install-java-for-idt"></a>

IDT v4.2.0 以降、 のオプション認定テストでは Java を実行 AWS IoT Greengrass する必要があります。

Java バージョン 8 以降を使用することができます。[Amazon Corretto](https://aws.amazon.com/corretto/) または [OpenJDK](https://openjdk.java.net/) の長期サポートバージョンを使用することをお勧めします。バージョン 8 以降が必要です。

## テスト対象デバイスにアクセスするようにホストコンピュータを設定する
<a name="configure-host"></a>

IDT はホストコンピュータで動作し、SSH を使用してデバイスに接続できる必要があります。IDT がテスト対象のデバイスへの SSH アクセスを許可するには、2 つのオプションがあります。

1. こちらの手順に従って SSH キーペアを作成し、パスワードを指定せずにテスト対象のデバイスにサインインすることをキーに承認します。

1. `device.json` ファイルに各デバイスのユーザー名とパスワードを入力します。詳細については、「[device.json の設定](set-config.md#device-config)」を参照してください。

任意の SSL 実装を使用して SSH キーを作成できます。次の手順は、[SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) または [PuTTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (Windows の場合) を使用する方法を示しています。別の SSL 実装を使用する場合は、その実装に関するドキュメントを参照してください。

テスト対象デバイスで認証するには、IDT で SSH キーを使用します。

**SSH-KEYGEN を使用して SSH キーを作成するには**

1. SSH キーを作成します。

   OpenSSH **ssh-keygen** コマンドを使用して SSH キーペアを作成できます。ホストコンピュータに SSH キーペアがすでにある場合は、IDT 専用の SSH キーペアを作成することをお勧めします。こうすることで、テストを完了した後、ホストコンピュータはパスワードを入力しないとデバイスに接続できなくなります。また、リモートデバイスへのアクセスを必要なユーザーのみに制限することもできます。
**注記**  
Windows に SSH クライアントがインストールされていません。Windows での SSH クライアントのインストールについては、「[SSH クライアントソフトウェアをダウンロードする](https://www.ssh.com/ssh/#sec-Download-client-software)」を参照してください。

   **ssh-keygen** コマンドは、キーペアを保存する名前とパスの入力を求めます。デフォルトでは、キーペアファイルの名前は `id_rsa` (プライベートキー) と `id_rsa.pub` (パブリックキー) です。macOS および Linux の場合、これらのファイルのデフォルトの場所は `~/.ssh/` です。Windows の場合、デフォルトの場所は `C:\Users\<user-name>\.ssh` です。

   プロンプトが表示されたら、SSH キーを保護するキーフレーズを入力します。詳細については、「[新しい SSH キーを生成する](https://www.ssh.com/ssh/keygen/)」を参照してください。

1. テスト対象デバイスに承認済み SSH キーを追加します。

   IDT で SSH プライベートキーを使用して、テスト対象デバイスにサインインする必要があります。SSH プライベートキーがテスト対象デバイスにサインインすることを承認するには、ホストコンピュータから **ssh-copy-id** コマンドを使用します。このコマンドは、テスト対象デバイスの `~/.ssh/authorized_keys` ファイルにパブリックキーを追加します。例:

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

   *remote-ssh-user* は、テスト対象デバイスへのサインインに使用するユーザー名です。*remote-device-ip* は、テスト対象デバイスの IP アドレスです。例:

   **ssh-copy-id pi@192.168.1.5**

   プロンプトが表示されたら、**ssh-copy-id** コマンドで指定したユーザー名に対応するパスワードを入力します。

   **ssh-copy-id** では、パブリックキー名が `id_rsa.pub` で、デフォルトの保存先が `~/.ssh/` (macOS と Linux の場合) または `C:\Users\<user-name>\.ssh` (Windows の場合) であるとみなされます。パブリックキーに別の名前や別の保存先を指定した場合は、**ssh-copy-id** で **-i** オプションを使用し、SSH 公開鍵への完全修飾パス (**ssh-copy-id -i \$1/my/path/myKey.pub** など) を指定する必要があります。SSH キーの作成とパブリックキーのコピーの詳細については、「[SSH-COPY-ID](https://www.ssh.com/ssh/copy-id)」を参照してください。

**PuTTYgen を使用して SSH キーを作成するには (Windows のみ)**

1. テスト対象デバイスに OpenSSH サーバーとクライアントがインストールされていることを確認します。詳細については、「[OpenSSH](https://www.openssh.com/)」を参照してください。

1. テスト対象のデバイスに [PuTTYgen](https://www.puttygen.com/) をインストールします。

1. PuTTYGen を開きます。

1. [**Generate**] を選択し、ボックス内にマウスカーソルを移動してプライベートキーを生成します。

1. [**Conversions**] メニューから [**Export OpenSSH key**] を選択し、プライベートキーに `.pem` ファイル拡張子を付けて保存します。

1. テスト対象デバイスの `/home/<user>/.ssh/authorized_keys` ファイルにパブリックキーを追加します。

   1. PuTTYgen ウィンドウからパブリックキーテキストをコピーします。

   1. PuTTY を使用して、テスト対象のデバイスでセッションを作成します。

      1. コマンドプロンプトまたは Windows Powershell ウィンドウから、次のコマンドを実行します。

          **C:/*<path-to-putty>*/putty.exe -ssh *<user>*@*<dut-ip-address>* ** 

      1. プロンプトが表示されたら、デバイスのパスワードを入力します。

      1. vi などのテキストエディタを使用して、テスト対象のデバイスの `/home/<user>/.ssh/authorized_keys` ファイルにパブリックキーを追加します。

1. `device.json` ファイルを、ユーザー名、IP アドレス、およびテスト対象の各デバイスのホストコンピュータに保存したプライベートキーファイルへのパスで更新します。詳細については、「[device.json の設定](set-config.md#device-config)」を参照してください。必ずプライベートキーの完全パスとファイル名を指定し、スラッシュ (「/」) を使用してください。たとえば、Windows パス `C:\DT\privatekey.pem` の場合は、`device.json` ファイルで `C:/DT/privatekey.pem` を使用します。

## Windows デバイスのユーザー認証情報を設定する
<a name="configure-windows-user-for-idt"></a>

Windows ベースのデバイスを認定するには、テスト対象のデバイスの LocalSystem アカウントで、次のユーザーに対してユーザー認証情報を設定する必要があります。
+ デフォルトの Greengrass ユーザー (`ggc_user`)。
+ テスト対象のデバイスに接続するために使用するユーザー。このユーザは、[`device.json` ファイル](set-config.md#device-config)で設定します。

各ユーザーは、テスト対象のデバイスの LocalSystem アカウント内に作成し、ユーザーのユーザー名とパスワードは LocalSystem アカウントの認証情報マネージャーインスタンスに格納する必要があります。<a name="set-up-windows-device-environment-procedure"></a>

**Windows デバイスでユーザーを設定するには**

1. 管理者として Windows コマンドプロンプト `cmd.exe` を開きます。

1. Windows デバイスの LocalSystem アカウント内でユーザーを作成します。作成する各ユーザーに対して、次のコマンドを実行します。デフォルトの Greengrass ユーザーの場合は、*user-name* を `ggc_user` と置き換えます。*パスワード*を安全なパスワードに置き換えます。

   ```
   net user /add user-name password
   ```

1. [PsExec ユーティリティ](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec)を Microsoft からダウンロードしてデバイスにインストールします。

1. PsExec ユーティリティを使用して、デフォルトユーザーのユーザー名とパスワードを LocalSystem アカウントの認証情報マネージャーインスタンスに格納します。

   認証情報マネージャーで、設定する各ユーザーに対して、次のコマンドを実行します。デフォルトの Greengrass ユーザーの場合は、*user-name* を `ggc_user` と置き換えます。*パスワード*を以前に設定したユーザーのパスワードに置き換えます。

   ```
   psexec -s cmd /c cmdkey /generic:user-name /user:user-name /pass:password
   ```

   **PsExec License Agreement** が開いたら、**Accept** を選択し、ライセンスに同意してコマンドを実行します。
**注記**  
Windows デバイスでは、LocalSystem アカウントが Greengrass nucleus を実行します。ユーザーは PsExec ユーティリティを使用して LocalSystem アカウントにユーザー情報を保存する必要があります。認証情報マネージャーアプリケーションを使用すると、この情報は LocalSystem アカウントではなく、現在ログオンしているユーザーの Windows アカウントに保存されます。

## デバイスに対するユーザーのアクセス許可を設定する
<a name="root-access"></a>

IDT は、テスト対象デバイスのさまざまなディレクトリやファイルに対してオペレーションを実行します。このようなオペレーションの中には、高いアクセス許可が必要な場合があります (**sudo** を使用)。これらのオペレーションを自動化するには、IDT for AWS IoT Greengrass V2 がパスワードの入力を求められることなく sudo でコマンドを実行できる必要があります。

パスワードの入力を求めることなく、sudo にアクセスを許可するには、テスト対象デバイスで以下の手順を実行します。

**注記**  
`username` は、テスト対象デバイスにアクセスするために IDT で使用する SSH ユーザーを指します。

**ユーザーを sudo グループに追加するには**

1. テスト対象のデバイスで、`sudo usermod -aG sudo <username>` を実行します。

1. サインアウトし、再度サインインして、変更を反映します。

1. ユーザー名が正常に追加されたことを確認するには、**sudo echo test** を実行します。パスワードの入力を要求されない場合、ユーザーは正しく設定されています。

1. `/etc/sudoers` ファイルを開き、ファイルの末尾に次の行を追加します: 

   `<ssh-username> ALL=(ALL) NOPASSWD: ALL`

## カスタムトークン交換ロールを設定する
<a name="configure-custom-tes-role-for-idt"></a>

テスト対象のデバイスが AWS リソースを操作するために引き受けるトークン交換ロールとして、カスタム IAM ロールを使用することを選択できます。IAM ロールの作成方法の詳細については、「IAM ユーザーガイド」の「[IAM ロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)」を参照してください。

IDT がカスタム IAM ロールを使用できるようにするには、以下の要件を満たす必要があります。このロールには、最低限必要なポリシーアクションのみを追加することを強く推奨します。
+ [userdata.json](set-config.md#custom-token-exchange-role-idt) 設定ファイルを更新して、`GreengrassV2TokenExchangeRole` パラメータを `true` に設定する必要があります。
+ カスタム IAM ロールは、次の最小限の信頼ポリシーで設定する必要があります。

------
#### [ JSON ]

****  

  ```
  {
     "Version":"2012-10-17",		 	 	 
     "Statement":[
        {
           "Effect":"Allow",
           "Principal":{
              "Service":[
                 "credentials.iot.amazonaws.com",
                 "lambda.amazonaws.com", 
                 "sagemaker.amazonaws.com" 
              ]
           },
           "Action":"sts:AssumeRole"
        }
     ]
  }
  ```

------
+ カスタム IAM ロールは、次の最小限のアクセス許可ポリシーで設定する必要があります。

------
#### [ 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":"*"
        }
     ]
  }
  ```

------
+ カスタム IAM ロールの名前は、テストユーザーの IAM アクセス許可で指定した IAM ロールリソースと一致する必要があります。デフォルトでは、[テストユーザーポリシー](dev-tst-prereqs.md#configure-idt-permissions)は、ロール名に `idt-` プレフィックスを持つ IAM ロールへのアクセスを許可します。IAM ロール名にこのプレフィックスが使用されていない場合、次の例に示されているように、テストユーザーポリシーの `roleAliasResources` ステートメントと `passRoleForResources` ステートメントに `arn:aws:iam::*:role/custom-iam-role-name` リソースを追加してください。

    
**Example `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 `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"
     ]
  }
  ```

## オプション機能をテストするためのデバイスの設定
<a name="optional-feature-config"></a>

このセクションでは、オプションの Docker および機械学習 (ML) 機能に対して IDT テストを実行する際のデバイス要件について説明します。ML 機能は IDT v4.9.3 でのみサポートされています。これらの機能をテストする場合にのみ、デバイスがこれらの要件を満たしていることを確認する必要があります。それ以外の場合は、「[認定スイートを実行するように IDT AWS IoT Greengrass 設定を構成する](set-config.md)」に進みます。

**Topics**
+ [Docker の認定要件](#idt-config-docker-components)
+ [ML の認定要件](#idt-config-ml-components)
+ [HSM の認定要件](#idt-config-hsm-components)

### Docker の認定要件
<a name="idt-config-docker-components"></a>

IDT for AWS IoT Greengrass V2 には、デバイスが AWSが提供する Docker [アプリケーションマネージャーコンポーネントを使用して、カスタム Docker](docker-application-manager-component.md) コンテナコンポーネントを使用して実行できる Docker コンテナイメージをダウンロードできることを検証するための Docker 認定テストが用意されています。カスタム Docker コンポーネントを作成するための詳細については、「[Docker コンテナの実行](run-docker-container.md)」を参照してください。

Docker 認定テストを実行するには、テスト対象のデバイスが Docker アプリケーションマネージャーコンポーネントをデプロイするための次の要件を満たしている必要があります。
+ <a name="docker-engine-requirement"></a>[Docker Engine](https://docs.docker.com/engine/) 1.9.1 以降が Greengrass コアにインストールされていいること。バージョン 20.10 は、 AWS IoT Greengrass Core ソフトウェアで動作することが検証された最新バージョンです。Docker コンテナを実行するコンポーネントをデプロイする前に、コアデバイスに直接、Docker をインストールしておく必要があります。
+ <a name="docker-daemon-requirement"></a>このコンポーネントをデプロイする前に、Docker デーモンがコアデバイス上で起動し、実行されています。
+ <a name="docker-user-permissions-requirement"></a>Docker コンテナコンポーネントを実行するシステムユーザーには、ルート権限または管理者権限が必要です。権限がない場合は、ルート権限または管理者権限を持たないユーザーとして実行されるように Docker を設定する必要があります。
  + Linux デバイスでは、ユーザーを `docker` グループに追加することで、`sudo` のない `docker` コマンドを呼び出せます。
  + Windows デバイスでは、ユーザーを `docker-users` グループ に追加することで、管理者の権限のない `docker` コマンドを呼び出せます。

------
#### [ Linux or Unix ]

  Docker コンテナコンポーネントの実行に使用する `ggc_user` または非ルートユーザーを `docker` グループに追加するには、次のコマンドを実行します。

  ```
  sudo usermod -aG docker ggc_user
  ```

  詳細については、「[Docker を非ルートユーザーとして管理する](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user)」を参照してください。

------
#### [ Windows Command Prompt (CMD) ]

  Docker コンテナコンポーネントの実行に使用する `ggc_user` またはユーザーを `docker-users` グループに追加するには、次のコマンドを管理者として実行します。

  ```
  net localgroup docker-users ggc_user /add
  ```

------
#### [ Windows PowerShell ]

  Docker コンテナコンポーネントの実行に使用する `ggc_user` またはユーザーを `docker-users` グループに追加するには、次のコマンドを管理者として実行します。

  ```
  Add-LocalGroupMember -Group docker-users -Member ggc_user
  ```

------

### ML の認定要件
<a name="idt-config-ml-components"></a>

**注記**  
機械学習機能は IDT v4.9.3 でのみサポートされています。

IDT for AWS IoT Greengrass V2 は、デバイスが AWSが提供する[機械学習コンポーネント](machine-learning-components.md)を使用して [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) または [TensorFlow Lite ML フレームワークを使用してローカルで ML 推論を実行できることを検証するための](https://www.tensorflow.org/lite/guide/python) ML 認定テストを提供します。Greengrass デバイスで ML 推論を実行する際の詳細については、「[機械学習の推論を実行する](perform-machine-learning-inference.md)」を参照してください。

ML 認定テストを実行するには、テスト対象のデバイスが機械学習コンポーネントをデプロイするための次の要件を満たしている必要があります。<a name="ml-component-requirements"></a>
+ Amazon Linux 2 または Ubuntu 18.04 を実行している Greengrass コアデバイスの場合は、[GNU C ライブラリ](https://www.gnu.org/software/libc/) (glibc) バージョン 2.27 以降がデバイスにインストールされている必要があります。
+ Raspberry Pi などの Armv7l デバイスでは、OpenCV-Python の依存関係がデバイスにインストールされています。次のコマンドを実行して依存関係をインストールします。

  ```
  sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev
  ```
+ Raspberry Pi OS Bullseye を実行する Raspberry Pi デバイスでは、次の要件を満たす必要があります。
  + デバイスに、NumPy 1.22.4 以降がインストールされていること。Raspberry Pi OS Bullseye には以前のバージョンの NumPy が含まれているため、次のコマンドを実行してデバイスの NumPy をアップグレードできます。

    ```
    pip3 install --upgrade numpy
    ```
  + デバイスで、レガシーカメラスタックが有効になっていること。Raspberry Pi OS Bullseye には、デフォルトで新しいカメラスタックが含まれており有効化されていますが、これには互換性がないるため、レガシーカメラスタックを有効にしておく必要があります。<a name="raspberry-pi-bullseye-enable-legacy-camera-stack"></a>

**レガシーカメラスタックを有効にするには**

    1. 次のコマンドを実行して、Raspberry Pi 設定ツールを開きます。

       ```
       sudo raspi-config
       ```

    1. **[Interface Options]** (インターフェイスオプション) を選択します。

    1. **[Legacy camera]** (レガシーカメラ) を選択して、レガシーカメラスタックを有効にします。

    1. Raspberry Pi を再起動します。

### HSM の認定要件
<a name="idt-config-hsm-components"></a>

AWS IoT Greengrass は、デバイスの [PKCS ハードウェアセキュリティモジュール (HSM) と統合するための PKCS\$111 プロバイダーコンポーネント](pkcs11-provider-component.md)を提供します。HSM の設定は、お使いのデバイスと、選択した HSM モジュールによって異なります。[IDT 構成設定](set-config.md)に文書化されているように、予想される HSM 設定が提供される限り、IDT は、このオプション機能である認定テストを実行するために必要な情報を入手することができます。