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

Linux WorkSpace を別のオペレーティングシステムに移行する

ユーザーのホームディレクトリ、ファイル、データを保持しながら、既存の Linux WorkSpace を別の Linux オペレーティングシステムバンドルに移行できます。移行は、ユーザーボリューム () をそのままにしながら、ルートボリューム (オペレーティングシステム/home) を新しいバンドルに置き換えます。これは、同じ OS バンドルでルートボリュームを更新する再構築とは異なります。

WorkSpace の移行機能は、必要に応じてファイル所有権の修正やデスクトップ環境のクリーンアップなど、プロセス全体を自動的に処理します。

サポートされている移行パス

次の表は、Linux WorkSpace 移行でサポートされているソースオペレーティングシステムとターゲットオペレーティングシステムを示しています。

Amazon Linux 2 は有効な移行ソースですが、有効な移行ターゲットではありません。Amazon Linux 2 end-of-lifeとなり、AL2 バンドルで新しい WorkSpaces を作成することはできません。

Ubuntu、RHEL、Rocky Linux 間のすべての移行パスは、双方向でサポートされています。アップグレード (RHEL 8 → RHEL 9 など）、ダウングレード (Ubuntu 24.04 → Ubuntu 22.04 など）、ディストリビューションファミリー間の移行 (Rocky 9 → Ubuntu 24.04 または RHEL 9 → Rocky 8 など) を行うことができます。唯一の制限は、WorkSpace を既に使用しているのと同じバンドルに移行できないことです。

Amazon Linux 2 からの移行には、ユーザー ID の所有権の自動修正とデスクトップ環境のクリーンアップが必要です。他のすべてのディストリビューション (Ubuntu、RHEL、Rocky) 間の移行では、所有権の修正は必要ありません。これらのディストリビューションはすべて、安定したユーザー IDs を割り当てる Active Directory 統合に SSSD を使用するためです。

前提条件

Linux WorkSpace を移行する前に、以下を確認してください。

WorkSpace を移行する方法

AWS マネジメントコンソールの使用

の使用 AWS CLI

migrate-workspace コマンドを使用して、WorkSpace を別のバンドルに移行します。

aws workspaces migrate-workspace \
    --source-workspace-id ws-1234567890abcdef0 \
    --bundle-id wsb-jttwgmx20 \
    --region us-east-1

使用可能なターゲットバンドル IDsを検索するには:

aws workspaces describe-workspace-bundles \
    --query 'Bundles[?contains(Name, `Ubuntu`) || contains(Name, `Rocky`) || contains(Name, `RHEL`)].{Name:Name,BundleId:BundleId}' \
    --output table

移行ステータスのモニタリング

移行には通常 20～30 分かかります。WorkSpace のステータスをモニタリングします。

aws workspaces describe-workspaces \
    --workspace-ids ws-1234567890abcdef0 \
    --query 'Workspaces[0].State' \
    --output text

WorkSpace は、 AVAILABLE → PENDING → AVAILABLE (成功の場合) または ERROR (失敗の場合) の状態に移行します。プロビジョニング中に移行が失敗した場合、コントロールプレーンは自動的に元の WorkSpace を復元します。

移行後の検証

移行が完了したら、以下を確認します。

WorkSpace のステータスを確認する

WorkSpace が AWS コンソールまたは CLI で AVAILABLE状態であることを確認します。

ユーザーログインの確認

ユーザーに WorkSpace にログインさせ、デスクトップが正しくロードされることを確認します。

移行ログを確認する

AL2 移行の場合、変更された内容の詳細については、移行ログを確認してください。

cat ~/workspace-migration-log-*/user-id-migration.txt

このログには、古いユーザー ID と新しいユーザー IDs、各フェーズで変更されたファイルの数、タイムスタンプが表示されます。

フェーズ 2 のステータスを確認する

バックグラウンド移行が完了したかどうかを確認するには:

# Check if the Phase 2 service is still running
systemctl is-active ws-migrate-phase2.service 2>/dev/null

# "inactive" or "not found" means Phase 2 has completed
# "activating" means Phase 2 is still running (Type=simple service)

移行中の動作

移行を開始すると、次のステップが実行されます。

ユーザーのホームディレクトリは、移行中に保持される別の EBS ボリュームに保存されます。ドキュメント、SSH キー、シェル設定、アプリケーションデータなど、 のすべてのファイルは移行後も/home/username存続します。

Amazon Linux 2 からの移行

Amazon Linux 2 からの移行には、自動的に処理される追加のステップが含まれます。このセクションでは、何が起こるかとその理由について説明します。

AL2 移行が異なる理由

Amazon Linux 2 は Active Directory 統合に Winbind を使用しますが、すべての新しい Linux ディストリビューション (Ubuntu、RHEL、Rocky) は SSSD を使用します。これら 2 つのシステムは、同じ Active Directory ユーザーに異なる POSIX ユーザー IDsを割り当てます。

移行後、ユーザーのホームディレクトリ内のすべてのファイルは、古い Winbind UID によって所有されます。新しい SSSD UID と一致するように所有権が修正されるまで、ユーザーは独自のファイルにアクセスできません。

さらに、Amazon Linux 2 は MATE デスクトップ環境 (GNOME 2) を使用し、新しいディストリビューションは GNOME 3.x を使用します。MATE 設定ファイルは GNOME 3.x と競合するため、動作するデスクトップを確保するためにクリーンアップする必要があります。

2 フェーズの所有権の修正

プロビジョニングタイムアウトを回避するために、所有権の修正は 2 つのフェーズに分割されます。

フェーズ 1 (プロビジョニング中)

即時ログインに必要なデスクトップクリティカルファイルの所有権を修正しました。

フェーズ 1 は、ホームディレクトリの合計サイズに関係なくすばやく完了するため、大きなホームディレクトリが原因でプロビジョニングが失敗することはありません。

フェーズ 2 (バックグラウンド、再起動後)

残りのすべてのファイルの所有権を修正しました。

デスクトップ環境のクリーンアップ

AL2 からの移行中、次の MATE デスクトップ設定ファイルが移行ログ () 内のバックアップディレクトリに移動されます~/workspace-migration-log-YYYYMMDD/removed-configuration/。

これらのファイルは削除されません。バックアップディレクトリに移動され、必要に応じて復元できます。クリーンアップ後、デスクトップはデフォルトの GNOME 3.x の外観でロードされます。

SELinux コンテキストの復元

移行ターゲットが RHEL または Rocky Linux の場合、SELinux セキュリティコンテキストは、ソースオペレーティングシステムに関係なく、常にユーザーのホームディレクトリ全体 (/home/username) に復元されます。これは、以下を含む、SELinux 対応ディストリビューションをターゲットとするすべての移行パスに適用されます。

いずれの場合も、コンテキストの復元により、ファイルにはターゲットディストリビューションの SELinux ポリシーに適したセキュリティラベルが付けられます。

コンテキストの復元は、所有権の修正に一致する 2 つのフェーズで実行されます。

RFC 2307 ホームディレクトリの自動修正

Active Directory は RFC 2307 属性 (「Unix 属性」とも呼ばれます) をサポートしています。これにより、管理者はホームディレクトリパス () を含む POSIX ユーザープロパティを指定できますunixHomeDirectory。SSSD はこの属性を尊重しますが、AL2 の Winbind はそれを無視し、常に を使用します/home/username。

AL2 から SSSD ベースのディストリビューションに移行するときに、AD ユーザーオブジェクトが別のパス ( など/home/CORP/jsmith) にunixHomeDirectory設定されている場合、SSSD はユーザーのホームディレクトリをその AD 指定のパスに解決します。ユーザーの実際のデータは AL2 時代/home/usernameの に存在するため、AD 指定のパスはボリュームに存在しません。

移行システムは、この状況を自動的に検出します。

この修正は永続的です。override_homedirこの設定は再起動と今後の SSSD 再起動sssd.confの間は に保持されます。

移行後の RFC 2307 ホームディレクトリパスの有効化

移行によって RFC 2307 ホームディレクトリパスが自動修正され、SSSD で AD unixHomeDirectory 属性を今後尊重する場合は、オーバーライドを元に戻すことができます。これは高度な設定変更であり、影響を理解した場合にのみ実行する必要があります。

RFC 2307 ホームディレクトリパスを復元するには:

ステップ 1: AD 指定のホームディレクトリパスを決定する

# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
    "(sAMAccountName=jsmith)" unixHomeDirectory

ステップ 2: ユーザーのデータを AD 指定のパスに移動する

sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith

ステップ 3: /etc/sssd/sssd.conf から override_homedir 設定を削除する

sudo sed -i '/^override_homedir/d' /etc/sssd/sssd.conf

ステップ 4: SSSD を再起動する

sudo systemctl restart sssd

ステップ 5: ホームディレクトリが正しく解決されることを確認する

getent passwd jsmith
# Should show /home/CORP/jsmith as the home directory

ユーザー通知

移行システムでは、2 つの通知メカニズムを使用してユーザーへの通知を維持します。

ユーザーが接続されていない場合 (アクセスされていない WorkSpace の自動停止など）、フェーズ 2 はエラーなしでサイレントに実行されます。

最新のディストリビューション間の移行

Ubuntu、RHEL、Rocky Linux ディストリビューション間の移行には、ユーザー ID の所有権の修正は必要ありません。これらのディストリビューションはすべて、AD SID から派生した安定したユーザー IDs を割り当てる Active Directory 統合に SSSD を使用します。ユーザーのファイルは、移行全体で正しい所有権を保持します。

このカテゴリの一般的な移行パスは次のとおりです。

RHEL または Rocky Linux ターゲットへの移行の場合、SELinux コンテキストの復元は常に実行され、ファイルがターゲットディストリビューションの SELinux ポリシーに対して正しいセキュリティラベルを持つようにします。これは、ソースディストリビューションに関係なく適用されます。すでに正しいラベルを持つファイルの場合、復元は no-op です。

ユーザーが保持するものと変更するもの

保存されるもの

変更点

WorkSpaces の自動停止と常時オン

WorkSpaces の自動停止

自動停止 (アイドルタイムアウト後に休止) で設定された WorkSpaces の場合:

常時オンの WorkSpaces

常時オンの WorkSpaces の場合:

既知の制限事項

トラブルシューティング

プロビジョニング中に移行が失敗する

移行が失敗し、WorkSpace が ERROR状態に戻ると、コントロールプレーンは自動的に元の WorkSpace の復元を試みます。プロビジョニングログを確認します。

# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log

一般的な原因:

移行後にユーザーがログインできない

デスクトップが壊れているように見えるか、間違ったテーマがある

これは通常、AL2 から移行し、一部の MATE 設定ファイルがクリーンアップされていない場合に発生します。デスクトップをデフォルトにリセットするには:

# Remove remaining desktop configuration
rm -rf ~/.config/dconf/user
rm -rf ~/.gconf

# Log out and log back in

移行後のファイルの所有権が間違っている

AL2 移行後にホームディレクトリ内のファイルにアクセスできない場合、フェーズ 2 がまだ実行されている可能性があります。

# Check Phase 2 status
systemctl is-active ws-migrate-phase2.service 2>/dev/null

# Check the migration log for progress
cat ~/workspace-migration-log-*/user-id-migration.txt

フェーズ 2 が完了しても一部のファイルの所有権が間違っている場合は、手動で修正できます。

# Find files with the old UID and change ownership
sudo find /home/username -uid old-uid -exec chown username {} +
sudo find /home/username -gid old-gid -exec chgrp username {} +

ログファイルの場所