Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Migrasikan Linux WorkSpace ke sistem operasi yang berbeda

Anda dapat memigrasikan Linux yang ada WorkSpace ke bundel sistem operasi Linux yang berbeda sambil mempertahankan direktori home, file, dan data pengguna. Migrasi menggantikan volume root (sistem operasi) dengan bundel baru sambil menjaga volume pengguna (/home) tetap utuh. Ini berbeda dari pembangunan kembali, yang menyegarkan volume root dengan bundel OS yang sama.

WorkSpace Fitur Migrasi menangani seluruh proses secara otomatis, termasuk koreksi kepemilikan file dan pembersihan lingkungan desktop bila diperlukan.

Jalur migrasi yang didukung

Tabel berikut menunjukkan sumber dan sistem operasi target yang didukung untuk WorkSpace migrasi Linux.

Amazon Linux 2 adalah sumber migrasi yang valid tetapi bukan target migrasi yang valid. Amazon Linux 2 telah mencapai akhir masa pakai dan baru WorkSpaces tidak dapat dibuat dengan bundel AL2.

Semua jalur migrasi antara Ubuntu, RHEL, dan Rocky Linux didukung di kedua arah. Anda dapat meningkatkan (misalnya, RHEL 8 → RHEL 9) atau menurunkan versi (misalnya, Ubuntu 24.04 → Ubuntu 22.04). Anda juga dapat bermigrasi di seluruh keluarga distribusi (misalnya, Rocky 9 → Ubuntu 24.04 atau RHEL 9 → Rocky 8). Satu-satunya batasan adalah Anda tidak dapat memigrasikan WorkSpace a ke bundel yang sama yang sudah digunakan.

Migrasi dari Amazon Linux 2 memerlukan koreksi kepemilikan ID pengguna otomatis dan pembersihan lingkungan desktop. Migrasi antara semua distribusi lainnya (Ubuntu, RHEL, Rocky) tidak memerlukan koreksi kepemilikan karena distribusi ini semua menggunakan SSSD untuk integrasi Active Directory, yang menetapkan ID pengguna yang stabil.

Prasyarat

Sebelum memigrasi Linux WorkSpace, verifikasi hal berikut:

Bagaimana cara memigrasi WorkSpace

Menggunakan AWS Konsol Manajemen

Menggunakan AWS CLI

Gunakan migrate-workspace perintah untuk memigrasikan a WorkSpace ke bundel yang berbeda:

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

Untuk menemukan ID bundel target yang tersedia:

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

Memantau status migrasi

Migrasi biasanya memakan waktu 20-30 menit. Pantau WorkSpace status:

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

Trans WorkSpace isi melalui keadaan berikut: AVAILABLE → PENDING → AVAILABLE (pada keberhasilan) atau ERROR (pada kegagalan). Jika migrasi gagal selama penyediaan, bidang kontrol secara otomatis mengembalikan yang asli WorkSpace.

Post-migration verifikasi

Setelah migrasi selesai, verifikasi hal berikut:

Periksa WorkSpace status

Konfir WorkSpace masikan dalam AVAILABLE keadaan di Kon AWS sol atau melalui CLI.

Verifikasi login pengguna

Mintalah pengguna masuk ke WorkSpace dan konfirmasikan pemuatan desktop dengan benar.

Periksa log migrasi

Untuk migrasi AL2, tinjau log migrasi untuk detail tentang apa yang telah diubah:

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

Log ini menunjukkan ID pengguna lama dan baru, jumlah file yang berubah di setiap fase, dan stempel waktu.

Periksa status Tahap 2

Untuk memverifikasi apakah migrasi latar belakang telah selesai:

# 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)

Apa yang terjadi selama migrasi

Saat Anda memulai migrasi, langkah-langkah berikut terjadi:

Direktori rumah pengguna disimpan pada volume EBS terpisah yang dipertahankan di seluruh migrasi. Semua file /home/username bertahan dalam transisi, termasuk dokumen, kunci SSH, konfigurasi shell, dan data aplikasi.

Bermigrasi dari Amazon Linux 2

Migrasi dari Amazon Linux 2 melibatkan langkah-langkah tambahan yang ditangani secara otomatis. Bagian ini menjelaskan apa yang terjadi dan mengapa.

Mengapa migrasi AL2 berbeda

Amazon Linux 2 menggunakan Winbind untuk integrasi Active Directory, sementara semua distribusi Linux yang lebih baru (Ubuntu, RHEL, Rocky) menggunakan SSSD. Kedua sistem ini menetapkan ID pengguna POSIX yang berbeda untuk pengguna Active Directory yang sama:

Setelah migrasi, semua file di direktori home pengguna dimiliki oleh UID Winbind lama. Pengguna tidak dapat mengakses file mereka sendiri sampai kepemilikan dikoreksi agar sesuai dengan UID SSSD baru.

Selain itu, Amazon Linux 2 menggunakan lingkungan desktop MATE (GNOME 2), sedangkan distribusi yang lebih baru menggunakan GNOME 3.x. File konfigurasi MATE bertentangan dengan GNOME 3.x dan harus dibersihkan untuk memastikan desktop berfungsi.

Two-phase koreksi kepemilikan

Untuk menghindari batas waktu penyediaan, koreksi kepemilikan dibagi menjadi dua fase.

Tahap 1 (selama penyediaan)

Memperbaiki kepemilikan pada file penting desktop yang diperlukan untuk login segera:

Fase 1 selesai dengan cepat terlepas dari ukuran direktori home total, memastikan bahwa penyediaan tidak pernah gagal karena direktori home yang besar.

Fase 2 (latar belakang, setelah reboot)

Memperbaiki kepemilikan pada semua file yang tersisa:

Pembersihan lingkungan desktop

Selama migrasi dari AL2, file konfigurasi desktop MATE berikut dipindahkan ke direktori cadangan di dalam log migrasi (~/workspace-migration-log-YYYYMMDD/removed-configuration/):

File-file ini tidak dihapus - mereka dipindahkan ke direktori cadangan dan dapat dipulihkan jika diperlukan. Setelah pembersihan, desktop dimuat dengan tampilan default GNOME 3.x.

Pemulihan konteks SELinux

Ketika target migrasi adalah RHEL atau Rocky Linux, konteks keamanan SELinux selalu dipulihkan pada seluruh direktori home pengguna (/home/username), terlepas dari sistem operasi sumbernya. Ini berlaku untuk semua jalur migrasi yang menarget SELinux-enabled kan distribusi, termasuk:

Dalam semua kasus, pemulihan konteks memastikan bahwa file memiliki label keamanan yang benar untuk kebijakan SELinux distribusi target.

Pemulihan konteks berjalan dalam dua fase, cocok dengan koreksi kepemilikan:

Koreksi otomatis direktori rumah RFC 2307

Active Directory mendukung atribut RFC 2307 (juga dikenal sebagai “Atribut Unix”), yang memungkinkan administrator untuk menentukan properti pengguna POSIX termasuk path direktori rumah (). unixHomeDirectory SSSD menghormati atribut ini, sementara Winbind di AL2 mengabaikannya dan selalu digunakan. /home/username

Saat bermigrasi dari AL2 ke SSSD-based distribusi, objek pengguna AD mungkin telah diset unixHomeDirectory el ke jalur yang berbeda (misalnya,/home/CORP/jsmith). Dalam hal ini, SSSD menyelesaikan direktori home pengguna ke jalur itu AD-specified . Karena data aktual pengguna berasal /home/username dari era AL2, AD-specified jalur tidak ada pada volume.

Sistem migrasi mendeteksi situasi ini secara otomatis:

Koreksi ini permanen - override_homedir pengaturan tetap ada di sssd.conf seluruh reboot dan restart SSSD di masa mendatang.

Mengaktifkan jalur direktori rumah RFC 2307 setelah migrasi

Jika migrasi secara otomatis mengoreksi jalur direktori rumah RFC 2307 dan Anda ingin SSSD menghormati unixHomeDirectory atribut AD ke depan, Anda dapat membalikkan penggantian. Ini adalah perubahan konfigurasi lanjutan yang hanya boleh dilakukan jika Anda memahami implikasinya.

Untuk memulihkan jalur direktori home RFC 2307:

Langkah 1: Tentukan jalur direktori AD-specified home

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

Langkah 2: Pindahkan data pengguna ke AD-specified jalur

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

Langkah 3: Hapus pengaturan override_homedir dari /sssd.conf etc/sssd

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

Langkah 4: Mulai ulang SSSD

sudo systemctl restart sssd

Langkah 5: Verifikasi direktori home diselesaikan dengan benar

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

Notifikasi pengguna

Sistem migrasi menggunakan dua mekanisme notifikasi untuk terus memberi informasi kepada pengguna:

Jika pengguna tidak terhubung (misalnya, penghentian otomatis WorkSpace yang belum diakses), Fase 2 berjalan diam-diam tanpa kesalahan.

Migrasi antar distribusi modern

Migrasi antara distribusi Ubuntu, RHEL, dan Rocky Linux tidak memerlukan koreksi kepemilikan ID pengguna. Semua distribusi ini menggunakan SSSD untuk integrasi Active Directory, yang menetapkan ID pengguna stabil yang berasal dari AD SID. File pengguna mempertahankan kepemilikan yang benar di seluruh migrasi.

Jalur migrasi umum dalam kategori ini meliputi:

Untuk migrasi ke target RHEL atau Rocky Linux, pemulihan konteks SELinux selalu berjalan untuk memastikan file memiliki label keamanan yang benar untuk kebijakan SELinux distribusi target. Ini berlaku terlepas dari distribusi sumber. Untuk file yang sudah memiliki label yang benar, pemulihan tidak dapat dilakukan.

Apa yang disimpan pengguna dan perubahan apa

Apa yang diawetkan

Apa yang berubah

Auto-stop dan selalu aktif WorkSpaces

Auto-stop WorkSpaces

Untuk WorkSpaces dikonfigurasi dengan auto-stop (hibernasi setelah batas waktu idle):

Always-on WorkSpaces

Untuk selalu aktif: WorkSpaces

Keterbatasan yang Sudah Diketahui

Pemecahan masalah

Migrasi gagal selama penyediaan

Jika migrasi gagal dan WorkSpace kembali ke ERROR status, bidang kontrol secara otomatis mencoba mengembalikan yang asli WorkSpace. Periksa log penyediaan:

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

Penyebab umum:

Pengguna tidak dapat masuk setelah migrasi

Desktop tampak rusak atau memiliki tema yang salah

Ini biasanya terjadi ketika bermigrasi dari AL2 dan beberapa file konfigurasi MATE tidak dibersihkan. Untuk mengatur ulang desktop ke default:

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

# Log out and log back in

File memiliki kepemilikan yang salah setelah migrasi

Jika file di direktori home tidak dapat diakses setelah migrasi AL2, Fase 2 mungkin masih berjalan:

# 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

Jika Tahap 2 telah selesai tetapi beberapa file masih memiliki kepemilikan yang salah, Anda dapat memperbaikinya secara manual:

# 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 {} +

Lokasi file log