翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Linux WorkSpace を別のオペレーティングシステムに移行する ユーザーのホームディレクトリ、ファイル、データを維持しながら、既存の Linux WorkSpace を別の Linux オペレーティングシステムバンドルに移行できます。移行は、ユーザーボリューム () をそのままにしながら、ルートボリューム (オペレーティングシステム`/home`) を新しいバンドルに置き換えます。これは、同じ OS バンドルでルートボリュームを更新する再構築とは異なります。 WorkSpace の移行機能は、必要に応じてファイル所有権の修正やデスクトップ環境のクリーンアップなど、プロセス全体を自動的に処理します。 **Topics** + [サポートされている移行パス](#linux-migration-paths) + [前提条件](#linux-migration-prerequisites) + [WorkSpace を移行する方法](#linux-migration-how-to) + [移行後の検証](#linux-migration-verification) + [移行中の動作](#linux-migration-during) + [Amazon Linux 2 からの移行](#linux-migration-from-al2) + [最新のディストリビューション間の移行](#linux-migration-modern-distros) + [ユーザーが保持するものと変更するもの](#linux-migration-preserved) + [WorkSpaces の自動停止と常時オン](#linux-migration-autostop-alwayson) + [既知の制限事項](#linux-migration-limitations) + [トラブルシューティング](#linux-migration-troubleshooting) ## サポートされている移行パス 次の表は、Linux WorkSpace 移行でサポートされているソースオペレーティングシステムとターゲットオペレーティングシステムを示しています。 | 移行元 OS | Ubuntu 22.04 | Ubuntu 22.04 グラフィック | Ubuntu 24.04 | RHEL 8 | RHEL 9 | Rocky 8 | Rocky 9 | | --- | --- | --- | --- | --- | --- | --- | --- | | Amazon Linux 2 (PCoIP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Amazon Linux 2 (WSP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Ubuntu 22.04 | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Ubuntu 22.04 グラフィック | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ | | Ubuntu 24.04 | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ | | RHEL 8 | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ | | RHEL 9 | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | | Rocky 8 | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | | Rocky 9 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | **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 状態** — WorkSpace は `AVAILABLE`状態である必要があります。起動中、停止中、またはエラー状態の WorkSpace を移行することはできません。 + **Active Directory フォレスト信頼なし** — WorkSpace のディレクトリにフォレスト信頼関係を設定してはいけません。Active Directory 統合のすべての最新の Linux ディストリビューションで使用される SSSD は、フォレストトラストをサポートしていません。Forest Trust が設定されている場合、プロビジョニング中に移行が失敗します。 + **十分な EBS ストレージ** — WorkSpace には、移行オペレーションに十分な EBS ストレージが必要です。 ## WorkSpace を移行する方法 ### AWS マネジメントコンソールの使用 1. [https://console.aws.amazon.com/workspaces/](https://console.aws.amazon.com/workspaces/) で Amazon WorkSpaces コンソールを開きます。 1. ナビゲーションペインで [**WorkSpaces**] を選択します。 1. 移行する WorkSpace を選択します。 1. **「アクション**」を選択し、**WorkSpace の移行**」を選択します。 1. ターゲットオペレーティングシステムバンドルを選択します。 1. **移行** を選択します。 ### の使用 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) ``` ## 移行中の動作 移行を開始すると、次のステップが実行されます。 1. ユーザーボリューム (`/home`) は既存の WorkSpace からデタッチされます。 1. 既存の WorkSpace が破棄されます。 1. ターゲットオペレーティングシステムバンドルから新しい WorkSpace が作成されます。 1. ユーザーボリュームは、 の新しい WorkSpace に再アタッチされます`/home`。 1. 新しい WorkSpace がプロビジョニングされます。ネットワーキングが設定され、インスタンスが Active Directory に参加し、ユーザーのホームディレクトリが設定されます。 1. Amazon Linux 2 から移行する場合、ファイルの所有権が修正され、レガシーデスクトップ設定がクリーンアップされます (「」を参照[Amazon Linux 2 からの移行](#linux-migration-from-al2))。 1. WorkSpace が再起動し、ユーザーがログインできるようになります。 ユーザーのホームディレクトリは、移行全体で保持される別の 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** (AL2): 予測不可能なアルゴリズムスキーム (UID 1000 など) を使用してユーザー IDs を割り当てます。 + **SSSD** (モダンディストリビューション): Active Directory SID (UID 1285401133 など) から派生した安定したユーザー IDs を割り当てます。 移行後、ユーザーのホームディレクトリ内のすべてのファイルは、古い Winbind UID によって所有されます。新しい SSSD UID と一致するように所有権が修正されるまで、ユーザーは独自のファイルにアクセスできません。 さらに、Amazon Linux 2 は **MATE** デスクトップ環境 (GNOME 2) を使用し、新しいディストリビューションは **GNOME 3.x **を使用します。MATE 設定ファイルは GNOME 3.x と競合するため、動作するデスクトップを確保するためにクリーンアップする必要があります。 ### 2 フェーズの所有権の修正 タイムアウトのプロビジョニングを避けるため、所有権の修正は 2 つのフェーズに分割されます。 **フェーズ 1 (プロビジョニング中)** 即時ログインに必要なデスクトップクリティカルファイルの所有権を修正しました。 + ホームディレクトリ自体 + SSH キー (`~/.ssh/`) + デスクトップ設定 (`~/.config/`) + シェルプロファイル (`.bashrc`、`.bash_profile`、`.profile`) + ワールドリードアクセス許可のない最上位のファイルまたはディレクトリ フェーズ 1 は、ホームディレクトリの合計サイズに関係なくすばやく完了するため、大きなホームディレクトリが原因でプロビジョニングが失敗することはありません。 **フェーズ 2 (バックグラウンド、再起動後)** 残りのすべてのファイルの所有権を修正しました。 + 起動時に systemd サービス (`ws-migrate-phase2.service`) として実行 + SSSD がまだ起動準備ができていない場合、最大 10 分間ユーザー解決を再試行します。解決がタイムアウトすると、サービスは有効のままになり、次の起動時に再試行されます。 + アイドル I/O 優先度と最低 CPU 優先度を使用します。ユーザーエクスペリエンスには影響しません + ユーザーは、フェーズ 2 の実行中にログインして正常に作業できます。 + 大きなディレクトリ (1,000 万以上のファイル) の所有権の修正は、バックグラウンドで引き続き完了します。 + 正常に完了すると、systemd サービスファイルを自己削除します ### デスクトップ環境のクリーンアップ AL2 からの移行中、次の MATE デスクトップ設定ファイルが移行ログ () 内のバックアップディレクトリに移動されます`~/workspace-migration-log-YYYYMMDD/removed-configuration/`。 + `~/.config/dconf/user` — MATE 固有の dconf データベース + `~/.gconf/` — レガシー GConf ディレクトリ + `~/.config/mate-session/` — MATE セッション設定 + `~/.config/mate-panel/` — MATE パネル設定 + `~/.local/share/mate-panel/` — MATE パネルアプリケーションデータ + `~/.config/pluma/` — MATE テキストエディタの設定 + `~/.config/caja/` — MATE ファイルマネージャーの設定 + `~/.config/marco/` — MATE ウィンドウマネージャーの設定 + `~/.config/gtk-2.0/`、 `~/.config/gtk-3.0/` — GTK テーマ設定 + `~/.local/share/recently-used.xbel` — 最近のファイルリスト これらのファイルは削除されません。バックアップディレクトリに移動され、必要に応じて復元できます。クリーンアップ後、デスクトップはデフォルトの GNOME 3.x の外観でロードされます。 ### SELinux コンテキストの復元 移行ターゲットが RHEL または Rocky Linux の場合、SELinux セキュリティコンテキストは、ソースオペレーティングシステムに関係なく、常にユーザーのホームディレクトリ全体 (`/home/{{username}}`) に復元されます。これは、以下を含む SELinux 対応ディストリビューションをターゲットとするすべての移行パスに適用されます。 + 非 SELinux ソース (Ubuntu、AL2) からの移行。ファイルには SELinux ラベルが完全にありません。 + SELinux 対応ディストリビューション間の移行 (RHEL 8 → RHEL 9、Rocky 8 → Rocky 9、RHEL 9 → Rocky 9 など）。SELinux ポリシーバージョンとファイルコンテキスト定義は、メジャーリリース間で変更される可能性があります。 いずれの場合も、コンテキストの復元により、ファイルにはターゲットディストリビューションの SELinux ポリシーに適したセキュリティラベルが付けられます。 コンテキストの復元は、所有権の修正に一致する 2 つのフェーズで実行されます。 + **フェーズ 1**: プロビジョニング中にクリティカルパス (`~/.ssh/`、`~/.config/`) のコンテキストを復元します。 + **フェーズ 2**: 再起動後にホームディレクトリ全体のコンテキストをバックグラウンドで復元します。 ### RFC 2307 ホームディレクトリの自動修正 Active Directory は RFC 2307 属性 (「Unix 属性」とも呼ばれます) をサポートしています。これにより、管理者はホームディレクトリパス () を含む POSIX ユーザープロパティを指定できます`unixHomeDirectory`。SSSD はこの属性を尊重しますが、AL2 の Winbind はそれを無視し、常に を使用します`/home/{{username}}`。 AL2 から SSSD ベースのディストリビューションに移行する場合、AD ユーザーオブジェクトは を別のパス ( など) `unixHomeDirectory`に設定している可能性があります`/home/CORP/jsmith`。この場合、SSSD はユーザーのホームディレクトリを AD 指定のパスに解決します。ユーザーの実際のデータは AL2 時代`/home/{{username}}`の に存在するため、AD 指定のパスはボリュームに存在しません。 移行システムは、この状況を自動的に検出します。 1. プロビジョニング後、SSSD はユーザーのホームディレクトリを AD 指定のパスに解決します。 1. 移行システムは、このパスがユーザーボリュームに存在するかどうかを確認します。 1. AD 指定のパスが存在しないが、存在する`/home/{{username}}`場合、システムはこれを RFC 2307 パスの不一致として認識します。 1. システムは `/etc/sssd/sssd.conf` (すべてのドメインセクションで) `override_homedir=/home/%u`に直接 を設定し、SSSD を再起動します。 1. SSSD が再起動すると、ユーザーのホームディレクトリは`/home/{{username}}`、データが実際に存在する に解決されます。 1. 移行は通常、既存のデータに対して続行されます。 この修正は永続的です。`override_homedir`この設定は再起動と今後の SSSD 再起動`sssd.conf`の間は に保持されます。 ### 移行後の RFC 2307 ホームディレクトリパスの有効化 移行が RFC 2307 ホームディレクトリパスを自動的に修正し、SSSD で AD `unixHomeDirectory` 属性を今後尊重する場合は、オーバーライドを元に戻すことができます。これは高度な設定変更であり、影響を理解した場合にのみ実行する必要があります。 **警告** オーバーライドを削除すると、SSSD は AD 指定のホームディレクトリパスを使用します。オーバーライドを削除する前に、ユーザーのデータをそのパスに移動する必要があります。移動しないと、ユーザーは空のホームディレクトリを取得します。 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 ``` **重要** オーバーライドを削除すると、今後の WorkSpace の再構築と移行では AD 指定のパスが使用されます。次の再構築または移行の前に、データが適切な場所にあることを確認します。 ### ユーザー通知 移行システムでは、2 つの通知メカニズムを使用してユーザーへの通知を維持します。 1. **フェーズ 2 systemd サービス通知** — フェーズ 2 の開始または完了時にユーザーがデスクトップに接続されている場合、サービスから直接通知が表示されます。 + **フェーズ 2 の開始時:**「バックグラウンドでのファイル移行の完了」。正常に動作し続けることができます。一部のファイルは、移行が完了するまでアクセスできない場合があります。」 + **フェーズ 2 の完了時:**「ファイル移行が正常に完了しました。これで、すべてのファイルに正しい所有権が付与されます。詳細については、\~/workspace-migration-log-\* を参照してください。」 1. **XDG 自動スタートログイン通知** — 自動スタートエントリ (`~/.config/autostart/ws-migration-notify.desktop`) は、移行後の最初のログイン`/usr/lib/skylight/check-migration-status`時に実行されます。これにより、フェーズ 2 の実行中または完了後にユーザーが接続するケースが処理されます。 + **フェーズ 2 がまだ実行されている場合:**「ファイル移行はバックグラウンドで実行されています。正常に動作し続けることができます。一部のファイルは、移行が完了するまでアクセスできない場合があります。」 + **フェーズ 2 が完了した場合:**「ファイル移行が正常に完了しました。これで、すべてのファイルに正しい所有権が付与されます。詳細については、\~/workspace-migration-log-\* を参照してください。」 自動開始エントリは、完了通知を表示した後に削除されるため、以降のログインでは実行されません。 ユーザーが接続されていない場合 (アクセスされていない WorkSpace の自動停止など）、フェーズ 2 はエラーなしでサイレントに実行されます。 ## 最新のディストリビューション間の移行 Ubuntu、RHEL、Rocky Linux ディストリビューション間の移行には、ユーザー ID の所有権の修正は必要ありません。これらのディストリビューションはすべて、AD SID から派生した安定したユーザー IDs を割り当てる Active Directory 統合に SSSD を使用します。ユーザーのファイルは、移行全体で正しい所有権を保持します。 このカテゴリの一般的な移行パスは次のとおりです。 + **クロスファミリー:** Ubuntu 22.04 ↔ RHEL 8/9、Ubuntu 22.04 ↔ Rocky 8/9、RHEL ↔ Rocky + **バージョンアップグレード:** Ubuntu 22.04 → Ubuntu 24.04、RHEL 8 → RHEL 9、Rocky 8 → Rocky 9 + **グラフィックスバンドル:** 任意のソース → Ubuntu 22.04 Graphics。Ubuntu Graphics WorkSpaces は、Graphics 以外のターゲットに移行することもできます。 RHEL または Rocky Linux ターゲットへの移行の場合、SELinux コンテキストの復元は常に実行され、ファイルがターゲットディストリビューションの SELinux ポリシーに対して正しいセキュリティラベルを持つようにします。これは、ソースディストリビューションに関係なく適用されます。すでに正しいラベルを持つファイルの場合、復元は no-op です。 ## ユーザーが保持するものと変更するもの ### 保存されるもの + ホームディレクトリ内のすべてのファイル (ドキュメント、ダウンロード、デスクトップなど) + SSH キーと設定 (`~/.ssh/`) + シェル設定 (`.bashrc`、`.profile`、`.bash_profile`) + ブラウザのブックマークとプロファイル (Firefox、Chrome) + アプリケーション固有のデータと設定 (AL2 移行の MATE デスクトップコンポーネントを除く) ### 変更点 + デスクトップ環境は、ターゲットディストリビューションのデフォルトの GNOME 3.x の外観にリセットされます。 + レガシー MATE デスクトップ設定は削除され、バックアップされます (AL2 移行のみ）。 + デスクトップアイコンとパネルのカスタマイズはデフォルトにリセットされます。 + ルートボリュームにインストールされたアプリケーションは、ターゲットバンドルのデフォルトアプリケーションに置き換えられます。ユーザーがホームディレクトリにインストールしたアプリケーションは保持されます。 ## WorkSpaces の自動停止と常時オン ### WorkSpaces の自動停止 自動停止 (アイドルタイムアウト後に休止) で設定された WorkSpaces の場合: 1. 移行が完了し、WorkSpace が再起動します。 1. フェーズ 2 バックグラウンドサービスは起動時に開始されます。SSSD がまだ準備ができていない場合、サービスはユーザー解決を最大 10 分間再試行してから続行します。 1. アイドルタイムアウト (通常は 1 時間) 内にユーザーが接続しない場合、フェーズ 2 はバックグラウンドでサイレントに実行されます。 1. 一般的なワークロード (100,000 ファイル未満) の場合、フェーズ 2 はアイドルタイムアウト内に完了します。 1. WorkSpace は、フェーズ 2 の完了後に休止状態になります。 1. ユーザーが次に接続すると、移行はすでに完了しており、通知は表示されません。 ### 常時オンの WorkSpaces 常時オンの WorkSpaces の場合: 1. 移行が完了し、WorkSpace が再起動します。 1. フェーズ 2 バックグラウンドサービスは起動時に開始され、完了するまで実行されます。 1. ユーザーはいつでも接続でき、正常に動作 — フェーズ 2 はアイドル優先度で実行され、パフォーマンスには影響しません。 ## 既知の制限事項 + **Active Directory フォレスト信頼:** SSSD はフォレスト信頼関係をサポートしていません。Forest Trust が設定されたディレクトリの WorkSpaces は移行できません。 + **ターゲットとしての Amazon Linux 2:** AL2 end-of-lifeとなり、有効な移行ターゲットではありません。AL2 *から*のみ移行でき、AL2 *には*移行できません。 + **ロールバックなし:** 完了した移行を以前のオペレーティングシステムにロールバックすることはできません。以前の OS に戻る必要がある場合は、新しい移行を開始する必要があります (有効なターゲットではない AL2 を除く）。 + **MATE デスクトップのカスタマイズ:** AL2 から移行すると、MATE デスクトップの設定は削除されます。これらは にバックアップされます`~/workspace-migration-log-YYYYMMDD/removed-configuration/`が、GNOME 3.x デスクトップに自動的に適用することはできません。 + **大規模なホームディレクトリ:** 数百万のファイルがあるホームディレクトリの場合、フェーズ 2 のバックグラウンド所有権の修正には数時間かかることがあります。この間、ユーザーは正常に作業できますが、フェーズ 2 が完了するまで、一部のファイルの所有権が間違っている可能性があります。 + **ファイル共有:** ユーザーがホームディレクトリにファイル共有 (Samba 共有など) を設定している場合、AL2 移行中の所有権の変更が共有アクセス許可に影響する可能性があります。ファイル共有設定は、移行後に再確立する必要がある場合があります。 + **RFC 2307 オーバーライド:** 移行が RFC 2307 ホームディレクトリパスの不一致を自動修正した場合、AD `unixHomeDirectory` 属性は `override_homedir`の を介して上書きされます`sssd.conf`。SSSD で AD 指定のパスを優先[移行後の RFC 2307 ホームディレクトリパスの有効化](#linux-migration-al2-rfc2307-reverse)するかどうかを確認してください。 ## トラブルシューティング ### プロビジョニング中に移行が失敗する 移行が失敗し、WorkSpace が `ERROR`状態に戻ると、コントロールプレーンは自動的に元の WorkSpace の復元を試みます。プロビジョニングログを確認します。 ``` # Connect to the WorkSpace (if accessible) and check the domain-join log sudo cat /var/log/skylight/domain-join.log ``` 一般的な原因: + **フォレストトラストの設定:** SSSD はドメインをフォレストトラストに参加させることができません。移行する前にフォレスト信頼を削除します。 + **AD 接続の問題:** WorkSpace がドメインコントローラーに到達できません。VPC ネットワークとセキュリティグループのルールを確認します。 + **DNS 解決の失敗:** WorkSpace は AD ドメインを解決できません。DNS 設定を確認します。 ### 移行後にユーザーがログインできない + WorkSpace が `AVAILABLE`状態であることを確認します。 + ドメイン結合が正常に完了したことを確認します。 には が含まれている`sudo cat /var/lib/skylight/domain-join-status`必要があります`true`。 + ユーザーが解決できることを確認します。 `id {{username}}` はユーザーの UID とグループを返します。 + SSSD ステータスを確認する: `sudo sssctl domain-status {{domain}}`に が表示されます`Online status: Online`。 ### デスクトップが壊れているように見えるか、間違ったテーマがある これは通常、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}} {} + ``` ### ログファイルの場所 | Log | ロケーション | 内容 | | --- | --- | --- | | ドメイン結合ログ | /var/log/skylight/domain-join.log | 移行フェーズ 1 を含む完全なプロビジョニングワークフロー | | 移行の概要 | \~/workspace-migration-log-YYYYMMDD/user-id-migration.txt | フェーズ 1 とフェーズ 2 の古い/新しい UIDs、ファイル数、タイムスタンプ | | バックアップされた MATE 設定 | \~/workspace-migration-log-YYYYMMDD/removed-configuration/ | AL2 移行中に削除された MATE デスクトップファイル | | フェーズ 1 ファイルリスト | \~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt | フェーズ 1 で処理されたファイル (フェーズ 2 で重複をスキップするために使用) |