翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS IoT Greengrass V2 コアデバイスを非ルートに移行する
**重要**
このトピックでは、推奨される移行アプローチについて説明します。これらのステップは、デバイス設定、オペレーティングシステム、インストールされているソフトウェアに合わせて調整する必要がある場合があります。
デフォルトでは、 は Linux デバイスでルートユーザーとして AWS IoT Greengrass 実行されます。 AWS IoT Greengrass コアデバイスを移行して、 が AWS IoT Greengrass 必要とする Linux 機能のみを持つ非ルートユーザーとして実行することで、デバイスのセキュリティ体制を改善できます。単一のデバイスを移行することも、フリート間で移行をスケールすることもできます。
## 考慮事項
非ルートに移行する前に、次の点を考慮してください。
+ この移行手順は、systemd を使用する Linux AWS IoT Greengrass で nucleus (Java ベース) を実行する AWS IoT Greengrass コアデバイスに適用されます。 AWS IoT Greengrass nucleus lite を実行しているデバイスには適用されません。
+ 本番稼働用フリートを移行する前に、開発環境の単一デバイスで移行をテストします。
## 単一のデバイスを移行する
この移行手順は、「」で説明されているアプローチに従います[解決策 3: コンポーネントユーザーを分離して非ルート AWS IoT Greengrass V2 として設定する](setup-greengrass-non-root.md#non-root-solution-3)。開始する前に、そのトピックの前提条件を完了します。これには、非ルートユーザーがコンポーネントを個別のユーザーとして実行できるようにする sudoers 設定が含まれます。
フリートを移行する前に、この手順を使用して単一のデバイスを移行します。
### ステップ 1: ルート以外のユーザーとグループを作成する
デバイスに接続し、 として AWS IoT Greengrass 実行されるシステムユーザーとグループを作成します。{{user-name}} と {{group-name}} を、使用する名前に置き換えます。
```
sudo groupadd --system {{group-name}}
sudo useradd --system --create-home --shell /sbin/nologin -g {{group-name}} {{user-name}}
```
### ステップ 2: ファイルの所有権をバックアップする
現在のファイル所有権構造を停止 AWS IoT Greengrass して保存し、ロールバックする必要がある場合に復元できるようにします。
```
sudo systemctl stop greengrass.service
sudo mkdir -p /opt/greengrass-backup
sudo find /greengrass/v2 -exec stat -c 'chown %U:%G "%n"' {} \; | sudo tee /opt/greengrass-backup/restore_ownership.sh > /dev/null
sudo chmod 700 /opt/greengrass-backup/restore_ownership.sh
```
**注記**
このトピックのコマンドでは、 を AWS IoT Greengrass ルートパス`/greengrass/v2`として使用します。を別の場所にインストールした場合は、 AWS IoT Greengrass を実際の AWS IoT Greengrass ルートパス`/greengrass/v2`に置き換えます。
### ステップ 3: ファイルの所有権を変更する
AWS IoT Greengrass ディレクトリの所有権を非ルートユーザーに転送します。
```
sudo chown -R {{user-name}}:{{group-name}} /greengrass/v2
```
### ステップ 4: systemd ドロップインオーバーライドを作成する
必要な Linux 機能を持つ非ルートユーザー AWS IoT Greengrass として を実行するように systemd に指示するドロップインディレクトリと設定ファイルを作成します。
```
sudo mkdir -p /etc/systemd/system/greengrass.service.d
```
移行では、 で systemd ドロップインオーバーライドファイルを使用します`/etc/systemd/system/greengrass.service.d/10-nonroot.conf`。ドロップインオーバーライドは、ベースサービスファイルの設定を直接変更せずに置き換えます。このオーバーライドは、Linux 機能のセットが制限された非ルートユーザーとして AWS IoT Greengrass サービスを実行するように systemd を設定します。ドロップインディレクトリを削除すると、systemd は元の設定で root として実行されるベース`greengrass.service`ファイルに戻ります。
次の内容`/etc/systemd/system/greengrass.service.d/10-nonroot.conf`で ファイルを作成します。
```
[Service]
User={{user-name}}
AmbientCapabilities=CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_SYS_RESOURCE CAP_AUDIT_WRITE
CapabilityBoundingSet=CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_SYS_RESOURCE CAP_AUDIT_WRITE
ProtectSystem=strict
ReadWritePaths=/greengrass/v2 /tmp
```
これらの systemd ディレクティブと必要な機能の詳細については、「」を参照してください[解決策 3: コンポーネントユーザーを分離して非ルート AWS IoT Greengrass V2 として設定する](setup-greengrass-non-root.md#non-root-solution-3)。
### ステップ 5: systemd を再ロードして起動する AWS IoT Greengrass
次のコマンドを実行して systemd デーモンを再ロードし、起動します AWS IoT Greengrass。
```
sudo systemctl daemon-reload
sudo systemctl start greengrass.service
```
### ステップ 6: 移行を検証する
AWS IoT Greengrass が非ルートユーザーとして実行されていることを確認します。
```
sudo systemctl status greengrass.service
ps -ef | grep greengrass
```
出力には、 ではなく、非ルートユーザーがプロセス所有者として表示されます`root`。
次に、デプロイされたすべてのコンポーネントが実行されていることを確認します。このコマンドを実行するには、デバイスに `aws.greengrass.Cli` コンポーネントをデプロイする必要があります。
```
sudo /greengrass/v2/bin/greengrass-cli component list
```
各コンポーネントは、 `RUNNING`または `State`をレポートする必要があります`FINISHED`。 `FINISHED`は、 の予想される終了状態です`aws.greengrass.Nucleus`。移行が完了したとみなす前に、 `BROKEN`または `ERRORED`状態のコンポーネントを調べます。
### 単一のデバイスをロールバックする
ルートとして実行 AWS IoT Greengrass するために復元する必要がある場合は、ドロップインオーバーライドを削除し、ファイルの所有権を復元して再起動します AWS IoT Greengrass。
```
sudo systemctl stop greengrass.service
sudo rm -rf /etc/systemd/system/greengrass.service.d
sudo bash /opt/greengrass-backup/restore_ownership.sh
sudo systemctl daemon-reload
sudo systemctl start greengrass.service
```
から[ステップ 6: 移行を検証する](#migrate-nonroot-step6)再度検証コマンドを実行して、 AWS IoT Greengrass がルートとして実行されていることを確認します。このプロセスは所有者`root`として表示されます。
ロールバックが成功したことを確認したら、オプションで移行アーティファクトをクリーンアップできます。
+ **バックアップディレクトリ** — 後で移行を再試行する場合、または削除`/opt/greengrass-backup`する場合は、 を保持できます。
```
sudo rm -r /opt/greengrass-backup
```
+ **非ルートユーザーとグループ** — 非ルートユーザー AWS IoT Greengrass として実行する予定がない場合は、ステップ 1 で作成したユーザーとグループを削除できます。
```
sudo userdel {{user-name}}
sudo groupdel {{group-name}}
```
他のサービスまたはコンポーネントがこのユーザーを使用している場合は、ユーザーを削除しないでください。
## デバイスのフリートを移行する
単一のデバイスで移行を確認したら、フリート全体で移行をスケールできます。次のいずれかの方法を選択してください。
+ [カスタム AWS IoT Greengrass ブートストラップコンポーネントを使用する](#migrate-nonroot-fleet-bootstrap)
+ [を使用する AWS Systems Manager](#migrate-nonroot-fleet-ssm)
### カスタム AWS IoT Greengrass ブートストラップコンポーネントを使用する
フリート全体の単一デバイス移行ステップを自動化するカスタム AWS IoT Greengrass コンポーネントを作成できます。このアプローチは自己完結型で、 AWS IoT Greengrass デプロイのみを使用します。Systems Manager などの外部ツールは必要ありません。
コンポーネントは、 を `RequiresPrivilege`に設定してブートストラップライフサイクルを使用します。これは`true`、デプロイ中にコンポーネントをルートとして実行します。ブートストラップスクリプトは、単一デバイスプロシージャと同じ特権オペレーションを実行します。
+ ルート以外のユーザーとグループがまだ存在しない場合は作成します。
+ ロールバック用のファイル所有権構造をバックアップします。
+ AWS IoT Greengrass ルートディレクトリの所有権を非ルートユーザーに変更します。
+ systemd ドロップインオーバーライドファイルを作成します。
+ systemd デーモンを再ロードします。
+ コード 101 で終了してデバイスを再起動します。
**重要**
コンポーネントは、100 ではなくコード 101 で終了する必要があります。終了コード 100 は、メモリに既にキャッシュされている systemd サービス設定を使用する AWS IoT Greengrass JVM プロセスのみを再起動します。完全な再起動により、systemd はディスクから新しいドロップインオーバーライドを読み取り、非ルートユーザー AWS IoT Greengrass として開始します。再起動により、デバイスのすべてのサービスが一時的に中断されます。
すでにデバイスを移行している場合に再デプロイが失敗しないように、コンポーネントをべき等にします。
移行デプロイが完了したら、デバイスが非ルートユーザーとして実行されていることを確認します。詳細については、「[ステップ 6: 移行を検証する](#migrate-nonroot-step6)」を参照してください。実行中のユーザーをチェックして結果をレポートする検証コンポーネントをデプロイすることも、 AWS IoT Greengrass コンソールでデプロイステータスをモニタリングすることもできます。
#### ロールバックメカニズムを設定する
フリート間でルート設定をリモートで復元するには、移行コンポーネントがロールバックメカニズムを設定する必要があります。1 つのアプローチは、systemd を使用してトリガーファイルをモニタリングすることです。このアプローチには、次の systemd リソースが必要です。
+ ドロップインオーバーライドを削除し、バックアップから元のファイルの所有権を復元し、systemd デーモンを再ロードして、ルート AWS IoT Greengrass として再起動する*ロールバックスクリプト*。
+ ロールバックスクリプトをルートとして実行する systemd *ワンショットサービス*。ワンショットサービスは、存続期間の長いデーモンとして実行するのではなく、単一のタスクを実行してから終了します。
+ など、特定のファイルパスをモニタリングする systemd *パスユニット*`/greengrass/v2/rollback/.rollback-trigger`。ファイルが表示されると、パスユニットは自動的にワンショットロールバックサービスを開始します。
このメカニズムを使用すると、トリガーファイルを作成するシンプルな AWS IoT Greengrass コンポーネントをデプロイすることで、デバイスをロールバックできます。systemd パスユニットはファイルを検出し、ロールバックサービスをルートとして実行し、元のルート設定 AWS IoT Greengrass に復元します。
### を使用する AWS Systems Manager
Systems Manager を使用してデバイスを管理する場合は、単一デバイスの移行ステップを自動化する SSM ドキュメントを作成できます。SSM は とは独立して実行されるため AWS IoT Greengrass、デバイスを再起動せずに AWS IoT Greengrass サービスを直接停止および再起動できます。
SSM ドキュメントは、次の要件を満たしている必要があります。
+ 現在のサービス設定 AWS IoT Greengrass とファイル所有権構造を停止してバックアップします。
+ ルート以外のユーザーとグループを作成します。
+ AWS IoT Greengrass ディレクトリの所有権を非ルートユーザーに変更します。
+ systemd ドロップインオーバーライドファイルを作成します。
+ systemd デーモンを再ロードして起動します AWS IoT Greengrass。
+ が非ルートユーザーとして正常に AWS IoT Greengrass 開始されたことを確認します。
フリート間で移行を実行するには、Systems Manager Run Command を使用して、タグまたはリソースグループを使用してデバイスに対して SSM ドキュメントを実行します。Systems Manager コンソールでコマンド実行ステータスをモニタリングできます。このコンソールには、エラーを含む各ターゲットデバイスの結果が表示されます。
ロールバックするには、停止し AWS IoT Greengrass、ドロップインオーバーライドを削除し、元のファイルの所有権を復元し、systemd デーモンを再ロードして、ルート AWS IoT Greengrass として再起動する別の SSM ドキュメントを作成します。ロールバックする必要があるデバイスに対してこのドキュメントを実行します。
マネージドノードでコマンドを実行する方法の詳細については、[「Systems Manager Run Command を使用したコマンド](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)の実行」を参照してください。