기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Linux WorkSpace를 다른 운영 체제로 마이그레이션
사용자의 홈 디렉터리, 파일 및 데이터를 유지하면서 기존 Linux WorkSpace를 다른 Linux 운영 체제 번들로 마이그레이션할 수 있습니다. 마이그레이션은 사용자 볼륨()을 그대로 유지하면서 루트 볼륨(운영 체제/home)을 새 번들로 대체합니다. 이는 동일한 OS 번들로 루트 볼륨을 새로 고치는 재구축과 다릅니다.
WorkSpace 마이그레이션 기능은 파일 소유권 수정 및 필요한 경우 데스크톱 환경 정리를 포함하여 전체 프로세스를 자동으로 처리합니다.
내용
지원되는 마이그레이션 경로
다음 표에는 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 Forest Trust 없음 - WorkSpace의 디렉터리에 Forest Trust 관계가 구성되어 있지 않아야 합니다. Active Directory 통합을 위해 모든 최신 Linux 배포판에서 사용되는 SSSD는 Forest Trust를 지원하지 않습니다. Forest Trust가 구성된 경우 프로비저닝 중에 마이그레이션이 실패합니다.
-
충분한 EBS 스토리지 - WorkSpace에는 마이그레이션 작업을 위한 충분한 EBS 스토리지가 있어야 합니다.
WorkSpace를 마이그레이션하는 방법
AWS 관리 콘솔 사용
-
https://console.aws.amazon.com/workspaces/
Amazon WorkSpaces 콘솔을 엽니다. -
탐색 창에서 WorkSpaces를 선택합니다.
-
마이그레이션할 WorkSpace를 선택합니다.
-
작업을 선택한 다음 WorkSpace 마이그레이션을 선택합니다.
-
대상 운영 체제 번들을 선택합니다.
-
[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는 PENDING → AVAILABLE → AVAILABLE (성공 시) 또는 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)
마이그레이션 중에 발생하는 일
마이그레이션을 시작하면 다음 단계가 수행됩니다.
-
사용자 볼륨(
/home)이 기존 WorkSpace에서 분리됩니다. -
기존 WorkSpace가 폐기됩니다.
-
대상 운영 체제 번들에서 새 WorkSpace가 생성됩니다.
-
사용자 볼륨은에서 새 WorkSpace에 다시 연결됩니다
/home. -
새 WorkSpace가 프로비저닝됩니다. 네트워킹이 구성되고 인스턴스가 Active Directory에 조인하며 사용자의 홈 디렉터리가 설정됩니다.
-
Amazon Linux 2에서 마이그레이션하는 경우 파일 소유권이 수정되고 레거시 데스크톱 구성이 정리됩니다( 참조Amazon Linux 2에서 마이그레이션).
-
WorkSpace가 재부팅되고 사용자가 로그인할 수 있게 됩니다.
사용자의 홈 디렉터리는 마이그레이션 전반에 걸쳐 보존되는 별도의 EBS 볼륨에 저장됩니다. 문서, SSH 키, 쉘 구성 및 애플리케이션 데이터를 포함하여의 모든 파일은 전환 후에도 /home/ 유지됩니다.username
Amazon Linux 2에서 마이그레이션
Amazon Linux 2의 마이그레이션에는 자동으로 처리되는 추가 단계가 포함됩니다. 이 단원에서는 어떤 일이 발생하고 그 이유는 무엇인지 설명합니다.
AL2 마이그레이션이 다른 이유
Amazon Linux 2는 Active Directory 통합에 Winbind를 사용하는 반면, 모든 최신 Linux 배포판(Ubuntu, RHEL, Rocky)은 SSSD를 사용합니다. 이 두 시스템은 동일한 Active Directory 사용자에게 서로 다른 POSIX 사용자 IDs.
-
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와 충돌하므로 데스크톱이 제대로 작동하도록 정리해야 합니다.
2단계 소유권 수정
프로비저닝 제한 시간을 피하기 위해 소유권 수정은 두 단계로 나뉩니다.
1단계(프로비저닝 중)
즉시 로그인하는 데 필요한 데스크톱 크리티컬 파일의 소유권을 수정합니다.
홈 디렉터리 자체
SSH 키(
~/.ssh/)데스크톱 구성(
~/.config/)쉘 프로파일(
.bashrc,.bash_profile,.profile)월드 읽기 권한이 없는 모든 최상위 파일 또는 디렉터리
1단계는 총 홈 디렉터리 크기에 관계없이 빠르게 완료되므로 대용량 홈 디렉터리로 인해 프로비저닝이 실패하지 않습니다.
2단계(백그라운드, 재부팅 후)
나머지 모든 파일의 소유권을 수정합니다.
부팅 시 시스템 서비스(
ws-migrate-phase2.service)로 실행SSSD가 아직 부팅 시 준비되지 않은 경우 최대 10분 동안 사용자 확인을 재시도합니다. 확인 시간이 초과되면 서비스가 활성화된 상태로 유지되고 다음 부팅 시 재시도합니다.
유휴 I/O 우선 순위 및 최저 CPU 우선 순위 사용 - 사용자 경험에 영향을 주지 않음
사용자는 2단계가 실행되는 동안 로그인하고 정상적으로 작동할 수 있습니다.
대규모 디렉터리(1천만 개 이상의 파일)에 대한 소유권 수정은 백그라운드에서 계속 완료됩니다.
성공적으로 완료된 후 시스템 서비스 파일을 자체 제거합니다.
데스크톱 환경 정리
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/)에 복원됩니다. 이는 다음을 포함하여 SELinux 지원 배포를 대상으로 하는 모든 마이그레이션 경로에 적용됩니다.username
파일에 SELinux 레이블이 완전히 없는 비 SELinux 소스(Ubuntu, AL2)에서의 마이그레이션.
SELinux 지원 배포 간 마이그레이션(예: RHEL 8 → RHEL 9, Rocky 8 → Rocky 9 또는 RHEL 9 → Rocky 9). SELinux 정책 버전 및 파일 컨텍스트 정의는 메이저 릴리스 간에 변경될 수 있습니다.
모든 경우에 컨텍스트 복원은 대상 배포의 SELinux 정책에 대해 파일에 올바른 보안 레이블이 있는지 확인합니다.
컨텍스트 복원은 소유권 수정과 일치하는 두 단계로 실행됩니다.
1단계: 프로비저닝 중에 중요 경로(
~/.ssh/,~/.config/)에 대한 컨텍스트를 복원합니다.2단계: 재부팅 후 백그라운드의 전체 홈 디렉터리에서 컨텍스트를 복원합니다.
RFC 2307 홈 디렉터리 자동 수정
Active Directory는 관리자가 홈 디렉터리 경로()를 포함하여 POSIX 사용자 속성을 지정할 수 있도록 하는 RFC 2307 속성('Unix 속성'이라고도 함)을 지원합니다unixHomeDirectory. SSSD는이 속성을 준수하지만 AL2의 Winbind는이 속성을 무시하고 항상를 사용했습니다/home/.username
AL2에서 SSSD 기반 배포로 마이그레이션할 때 AD 사용자 객체가 다른 경로(예: /home/CORP/jsmith)로 unixHomeDirectory 설정되었을 수 있습니다. 이 경우 SSSD는 사용자의 홈 디렉터리를 해당 AD 지정 경로로 확인합니다. 사용자의 실제 데이터는 AL2 시대/home/부터에 있으므로 AD 지정 경로는 볼륨에 존재하지 않습니다.username
마이그레이션 시스템은이 상황을 자동으로 감지합니다.
프로비저닝 후 SSSD는 사용자의 홈 디렉터리를 AD 지정 경로로 확인합니다.
마이그레이션 시스템은이 경로가 사용자 볼륨에 존재하는지 확인합니다.
AD 지정 경로가 존재하지 않지만 존재하지
/home/않는 경우 시스템은 이를 RFC 2307 경로 불일치로 인식합니다.username시스템은
/etc/sssd/sssd.conf(모든 도메인 섹션에서)에override_homedir=/home/%u직접를 설정하고 SSSD를 다시 시작합니다.SSSD가 다시 시작되면 사용자의 홈 디렉터리는 데이터가 실제로 존재하는
/home/로 확인됩니다.username마이그레이션은 기존 데이터에 대해 정상적으로 진행됩니다.
이 수정은 영구적입니다.이 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 지정 경로를 사용합니다. 다음 재구축 또는 마이그레이션 전에 데이터가 올바른 위치에 있는지 확인합니다.
User Notifications
마이그레이션 시스템은 두 가지 알림 메커니즘을 사용하여 사용자에게 정보를 제공합니다.
-
2단계 시스템 서비스 알림 - 2단계가 시작되거나 완료될 때 사용자가 데스크톱에 연결된 경우 서비스에서 직접 알림이 표시됩니다.
2단계 시작 시: "배경에서 파일 마이그레이션 완료. 정상적으로 계속 작동할 수 있습니다. 마이그레이션이 완료될 때까지 일부 파일에 액세스하지 못할 수 있습니다.”
2단계 완료 시: "파일 마이그레이션이 성공적으로 완료되었습니다. 이제 모든 파일의 소유권이 정확해야 합니다. 자세한 내용은 ~/workspace-migration-log-*를 참조하세요.”
-
XDG 자동 시작 로그인 알림 - 마이그레이션 후 처음 로그인할
/usr/lib/skylight/check-migration-status때 자동 시작 항목(~/.config/autostart/ws-migration-notify.desktop)이 실행됩니다. 이렇게 하면 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는 그래픽이 아닌 대상으로도 마이그레이션할 수 있습니다.
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의 경우:
마이그레이션이 완료되고 WorkSpace가 재부팅됩니다.
2단계 백그라운드 서비스는 부팅 시 시작됩니다. SSSD가 아직 준비되지 않은 경우 서비스는 계속하기 전에 최대 10분 동안 사용자 확인을 재시도합니다.
사용자가 유휴 제한 시간(일반적으로 1시간) 내에 연결하지 않으면 2단계는 백그라운드에서 자동으로 실행됩니다.
일반적인 워크로드(100,000개 미만의 파일)의 경우 2단계는 유휴 제한 시간 내에 완료됩니다.
WorkSpace는 2단계가 완료된 후 최대 절전 모드로 전환됩니다.
사용자가 다음에 연결하면 마이그레이션이 이미 완료되고 알림이 표시되지 않습니다.
상시 작동 WorkSpaces
상시 작동 WorkSpaces 경우:
마이그레이션이 완료되고 WorkSpace가 재부팅됩니다.
2단계 백그라운드 서비스는 부팅 시 시작되어 완료될 때까지 실행됩니다.
사용자는 언제든지 연결하고 정상적으로 작업할 수 있습니다. 2단계는 유휴 우선 순위로 실행되며 성능에 영향을 주지 않습니다.
알려진 제한 사항
-
Active Directory Forest Trust: SSSD는 Forest Trust 관계를 지원하지 않습니다. Forest Trust가 구성된 디렉터리의 WorkSpaces는 마이그레이션할 수 없습니다.
-
Amazon Linux 2를 대상으로 사용: AL2가 end-of-life에 도달했으며 유효한 마이그레이션 대상이 아닙니다. AL2에서 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. 마이그레이션 후 RFC 2307 홈 디렉터리 경로 활성화 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가 포리스트 트러스트와 도메인에 조인할 수 없습니다. 마이그레이션하기 전에 Forest Trust를 제거합니다.
AD 연결 문제: WorkSpace가 도메인 컨트롤러에 연결할 수 없습니다. VPC 네트워킹 및 보안 그룹 규칙을 확인합니다.
DNS 확인 실패: WorkSpace가 AD 도메인을 확인할 수 없습니다. DNS 구성을 확인합니다.
마이그레이션 후 사용자가 로그인할 수 없음
WorkSpace가
AVAILABLE상태인지 확인합니다.도메인 조인이 성공적으로 완료되었는지 확인합니다. 에는가 포함되어야
sudo cat /var/lib/skylight/domain-join-status합니다true.사용자를 확인할 수 있는지 확인합니다.는 사용자의 UID와 그룹을 반환해야
id합니다.usernameSSSD 상태 확인:
sudo sssctl domain-status에이 표시됩니다domainOnline 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-uidold-uid-exec chownusername{} + sudo find /home/username-gidold-gid-exec chgrpusername{} +
로그 파일 위치
| Log | Location | 내용 |
|---|---|---|
| 도메인 조인 로그 | /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단계에서 중복을 건너뛰는 데 사용) |