本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 將 Linux WorkSpace 遷移至不同的作業系統 您可以將現有的 Linux WorkSpace 遷移到不同的 Linux 作業系統套件，同時保留使用者的主目錄、檔案和資料。遷移會將根磁碟區 （作業系統） 取代為新的套件，同時保持使用者磁碟區 (`/home`) 不變。這與重建不同，重建會使用相同的作業系統套件重新整理根磁碟區。 遷移 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 遷移支援的來源和目標作業系統。 | 來源作業系統 | 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) 之間的遷移不需要所有權更正，因為這些分佈都使用 SSSD 進行 Active Directory 整合，這會指派穩定的使用者 IDs。 ## 先決條件 在遷移 Linux WorkSpace 之前，請確認下列事項： + **WorkSpace 狀態** — WorkSpace 必須處於 `AVAILABLE` 狀態。您無法遷移正在啟動、停止或處於錯誤狀態的 WorkSpace。 + **沒有 Active Directory 樹系信任** — WorkSpace 的目錄不得設定樹系信任關係。所有現代 Linux 發行版本用於 Active Directory 整合的 SSSD 不支援樹系信任。如果已設定樹系信任，遷移會在佈建期間失敗。 + **足夠的 EBS 儲存**體 — WorkSpace 必須有足夠的 EBS 儲存體，才能進行遷移操作。 ## 如何遷移 WorkSpace ### 使用 AWS 管理主控台 1. 開啟位於 https：//[https://console.aws.amazon.com/workspaces/](https://console.aws.amazon.com/workspaces/) 的 Amazon WorkSpaces 主控台。 1. 在導覽窗格中，選擇 **WorkSpaces**。 1. 選取您要遷移的 WorkSpace。 1. 選擇**動作**，然後選擇**遷移 WorkSpace**。 1. 選取目標作業系統套件。 1. 選擇 **Migrate (遷移)**。 ### 使用 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` → `AVAILABLE`（成功時） `PENDING` 或 `ERROR`（失敗時）。如果在佈建期間遷移失敗，控制平面會自動還原原始 WorkSpace。 ## 遷移後驗證 遷移完成後，請確認下列事項： **檢查 WorkSpace 狀態** 在 AWS 主控台或透過 CLI 確認 WorkSpace 處於 `AVAILABLE` 狀態。 **驗證使用者登入** 讓使用者登入 WorkSpace 並確認桌面負載正確。 **檢查遷移日誌** 對於 AL2 遷移，請檢閱遷移日誌，以取得變更內容的詳細資訊： ``` cat ~/workspace-migration-log-*/user-id-migration.txt ``` 此日誌顯示新舊使用者 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 磁碟區中。中的所有檔案在轉換後`/home/{{username}}`仍然存在，包括文件、SSH 金鑰、殼層組態和應用程式資料。 ## 從 Amazon Linux 2 遷移 從 Amazon Linux 2 遷移涉及自動處理的其他步驟。本節說明發生的情況和原因。 ### 為什麼 AL2 遷移不同 Amazon Linux 2 使用 **Winbind** 進行 Active Directory 整合，而所有較新的 Linux 發行版本 (Ubuntu、RHEL、Rocky) 則使用 **SSSD**。這兩個系統會將不同的 POSIX 使用者 IDs 指派給相同的 Active Directory 使用者： + **Winbind** (AL2)：使用無法預測的演算法配置 （例如 UID 1000) 指派使用者 IDs。 + **SSSD** （現代分佈）：指派衍生自 Active Directory SID 的穩定使用者 IDs （例如 UID 1285401133)。 遷移後，使用者主目錄中的所有檔案都是舊的 Winbind UID 所擁有。在更正擁有權以符合新的 SSSD UID 之前，使用者無法存取自己的檔案。 此外，Amazon Linux 2 使用 **MATE** 桌面環境 (GNOME 2)，而較新的發行版本則使用 **GNOME 3.x。**MATE 組態檔案與 GNOME 3.x 衝突，必須清理以確保桌面正常運作。 ### 兩階段擁有權校正 為了避免佈建逾時，所有權更正分為兩個階段。 **階段 1 （佈建期間）** 修正立即登入所需的桌面關鍵檔案擁有權： + 主目錄本身 + SSH 金鑰 (`~/.ssh/`) + 桌面組態 (`~/.config/`) + Shell 設定檔 (`.bashrc`、`.bash_profile`、`.profile`) + 任何沒有世界讀取許可的頂層檔案或目錄 無論主目錄大小總計為何，階段 1 都會快速完成，確保佈建不會因為大型主目錄而失敗。 **階段 2 （背景，重新啟動後）** 修正所有剩餘檔案的擁有權： + 在開機時以系統化服務 (`ws-migrate-phase2.service`) 執行 + 如果 SSSD 在開機時尚未就緒，則重試使用者解析度最多 10 分鐘；如果解析度逾時，服務會保持啟用狀態，並在下次開機時重試 + 使用閒置 I/O 優先順序和最低 CPU 優先順序 — 不會影響使用者體驗 + 第 2 階段執行時，使用者可以登入並正常運作 + 大型目錄 (10M\+ 檔案） 的擁有權修正將繼續在背景完成 + 成功完成後自行移除系統化服務檔案 ### 桌面環境清除 從 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 政策的正確安全標籤。 內容還原會分兩個階段執行，符合所有權更正： + **階段 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 指定的路徑。由於使用者的實際資料`/home/{{username}}`位於 AL2 時代的 ，因此磁碟區上不存在 AD 指定的路徑。 遷移系統會自動偵測此情況： 1. 佈建後，SSSD 會將使用者的主目錄解析為 AD 指定的路徑。 1. 遷移系統會檢查此路徑是否存在於使用者磁碟區上。 1. 如果 AD 指定的路徑不存在但`/home/{{username}}`確實存在，系統會將此視為 RFC 2307 路徑不相符。 1. 系統會`override_homedir=/home/%u`直接在 中設定 `/etc/sssd/sssd.conf`（在所有網域區段上），並重新啟動 SSSD。 1. SSSD 重新啟動後，使用者的主目錄會解析為 `/home/{{username}}`，其中資料實際上是存留的。 1. 遷移通常會針對現有資料進行。 此校正為永久性 — 在重新啟動和未來的 SSSD 重新啟動`sssd.conf`時`override_homedir`，設定會保留在 中。 ### 遷移後啟用 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 指定的路徑。在下一次重建或遷移之前，請確定資料位於正確的位置。 ### 使用者通知 遷移系統使用兩種通知機制來通知使用者： 1. **階段 2 系統化服務通知** — 如果使用者在階段 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 擁有權校正。所有這些分佈都使用 SSSD 進行 Active Directory 整合，這會指派從 AD SID 衍生的穩定使用者 IDs。使用者的檔案在整個遷移過程中會保留正確的擁有權。 此類別中的常見遷移路徑包括： + **跨系列：**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 圖形。Ubuntu Graphics WorkSpaces 也可以遷移到任何非圖形目標。 對於遷移至 RHEL 或 Rocky Linux 目標，SELinux 內容還原一律執行，以確保檔案具有適用於目標分發 SELinux 政策的正確安全標籤。無論來源分佈為何，這都適用。對於已有正確標籤的檔案，還原是無操作。 ## 使用者保留的項目和變更項目 ### 保留的內容 + 主目錄中的所有檔案 （文件、下載、桌面等） + SSH 金鑰和組態 (`~/.ssh/`) + Shell 組態 (`.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 不支援樹系信任關係。已設定樹系信任的目錄中的 WorkSpaces 無法遷移。 + **Amazon Linux 2 作為目標：**AL2 已達到end-of-life，並且不是有效的遷移目標。您只能*從* AL2 遷移*至* AL2。 + **無復原：**完成的遷移無法復原至先前的作業系統。如果您需要返回先前的作業系統，您必須啟動新的遷移 (AL2 除外，這不是有效的目標）。 + **MATE 桌面自訂：**從 AL2 遷移時，會移除 MATE 桌面偏好設定。它們會在 中備份，`~/workspace-migration-log-YYYYMMDD/removed-configuration/`但無法自動套用至 GNOME 3.x 桌面。 + **大型主目錄：**對於具有數百萬個檔案的主目錄，階段 2 背景擁有權校正可能需要幾個小時。使用者可以在此期間正常運作，但某些檔案在階段 2 完成之前可能會有不正確的擁有權。 + **檔案共用：**如果使用者已在主目錄上設定檔案共用 （例如 Samba 共用），AL2 遷移期間的所有權變更可能會影響共用許可。檔案共用組態可能需要在遷移後重新建立。 + **RFC 2307 覆寫：**如果遷移自動更正 RFC 2307 主目錄路徑不相符，則會透過 `override_homedir`中的 覆寫 AD `unixHomeDirectory` 屬性`sssd.conf`。[遷移後啟用 RFC 2307 主目錄路徑](#linux-migration-al2-rfc2307-reverse) 如果您希望 SSSD 遵循 AD 指定的路徑，請參閱 。 ## 疑難排解 ### 在佈建期間遷移失敗 如果遷移失敗且 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 | Location | 目錄 | | --- | --- | --- | | 網域聯結日誌 | /var/log/skylight/domain-join.log | 完整佈建工作流程，包括遷移階段 1 | | 遷移摘要 | \~/workspace-migration-log-YYYYMMDD/user-id-migration.txt | 舊/新 UIDs、檔案計數、階段 1 和階段 2 的時間戳記 | | 備份 MATE 組態 | \~/workspace-migration-log-YYYYMMDD/removed-configuration/ | 在 AL2 遷移期間移除的 MATE 桌面檔案 | | 階段 1 檔案清單 | \~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt | 階段 1 期間處理的檔案 （由階段 2 用來略過重複項目） |