3장 Calendar Server 6.3용 데이터베이스 마이그레이션 유틸리티

이 장에서는 Calendar Server 6.3 소프트웨어를 설치 및 구성한 후 달력 데이터베이스 및 LDAP 데이터베이스를 마이그레이션하는 데 사용할 수 있는 다양한 데이터베이스 마이그레이션 유틸리티에 대해 설명합니다.

이 장은 다음 내용으로 구성되어 있습니다.

• 3.1 Calendar Server 데이터베이스 마이그레이션 유틸리티 개요

• 3.2 올바른 Calendar Server 유틸리티 선택

• 3.3 csmigrate 유틸리티

• 3.4 cs5migrate 유틸리티

• 3.5 csmig 유틸리티

• 3.6 csvdmig

• 3.7 commdirmig

Calendar Server 6.0, 6.1 또는 6.2 버전에서 마이그레이션하는 경우 3.3 csmigrate 유틸리티를 실행하십시오. 이전 배포 시 반복 이벤트 및 작업에 대해 아직 cs5migrate를 실행하지 않은 경우 기존 달력 데이터베이스에서 cs5migrate를 실행한 후 csmigrate를 실행해야 합니다.

Calendar Server 5.1.1에서 마이그레이션하는 경우 3.2 올바른 Calendar Server 유틸리티 선택에서 설명한 마이그레이션 유틸리티를 사용하여 달력 데이터베이스 및 LDAP 데이터베이스를 마이그레이션하십시오.

더 이전 버전의 Calendar Server가 설치되어 있는 경우 데이터 마이그레이션에 대한 기술 지원을 받으십시오.

3.1 Calendar Server 데이터베이스 마이그레이션 유틸리티 개요

이 절에서는 다양한 마이그레이션 유틸리티에 대해 설명합니다. 이전에 설치한 Calendar Server 버전에 따라 필요한 마이그레이션 유틸리티만 사용하십시오. 이러한 유틸리티는 sbin 디렉토리에 있습니다.

데이터베이스에 대해 cs5migrate 유틸리티를 사용했지만 -r 옵션을 사용하지 않은 경우 -r 옵션을 사용하여 다시 실행한 후 다른 유틸리티를 실행해야 합니다.

마이그레이션 유틸리티는 다음과 같습니다.

3.5 csmig 유틸리티

Calendar Server 6 데이터베이스의 각 달력에 소유자를 지정하고 필요한 경우 각 달력 아이디(calid)를 소유자에게 매핑하여 다중 도메인 및 LDAP 달력 조회 데이터베이스(CLD) 플러그 인에 대한 지원을 사용할 수 있게 합니다.

이 유틸리티는 cs5migrate 실행 후, csvdmig 실행 전에 실행합니다.

3.6 csvdmig

달력의 도메인(@domainname)을 각 calid에 추가하여 다중 도메인을 사용하도록 Calendar Server 6 사이트를 업그레이드합니다. 예를 들어, sesta.com 도메인에서 jdoe calid는 이제 jdoe@sesta.com이 됩니다. 이 유틸리티는 Calendar Server와 같은 패키지로 제공됩니다.

이 유틸리티는 csmig 실행 후, cs5migrate 실행 전에 실행합니다.

3.4 cs5migrate 유틸리티

Calendar Server 버전 5에서 버전 6.2 형식으로 달력 데이터베이스를 마이그레이션합니다. 이 유틸리티는 -r 옵션을 지정하여 데이터베이스에 대해 실행해야 합니다. 이전에 Calendar Server 버전 5.1.1에서 버전 6.2로 마이그레이션했지만 -r 옵션을 사용하여 cs5migrate 유틸리티를 실행하지 않은 경우 이 옵션을 사용하여 실행한 후 csmigrate 유틸리티를 실행해야 합니다.

이 유틸리티는 csmig 및 csvdmig 실행 후, csmigrate 실행 전에 실행합니다.

3.3 csmigrate 유틸리티

Calendar Server 버전 6.0, 6.1 또는 6.2에서 Calendar Server 6.3 버전으로 업그레이드하려면 달력 데이터베이스를 마이그레이션합니다. -r 옵션을 사용하여 cs5migrate를 실행해야 하는 경우 이 유틸리티를 실행하기 전에 실행하십시오.

3.7 commdirmig

Access Manager(레거시 모드)와 함께 사용하기 위한 준비 과정으로 LDAP 데이터를 Schema 버전 1에서 Schema 버전 2로 마이그레이션합니다.

3.2 올바른 Calendar Server 유틸리티 선택

이 절에서는 모든 달력 데이터베이스 및 LDAP 데이터베이스를 Calendar Server 6.3 소프트웨어 수준에서 유지하기 위해 실행해야 하는 유틸리티를 결정할 수 있도록 도와줍니다.

다음 표를 사용하여 실행할 적합한 유틸리티 모음을 찾을 수 있습니다.

지정된 순서대로 유틸리티를 실행하십시오.

3.3 csmigrate 유틸리티

csmigrate 유틸리티는 Calendar Server 6.0, 6.1 또는 6.2 데이터베이스를 Calendar Server 6.3 데이터베이스로 마이그레이션하는 데 사용됩니다. csmigrate 유틸리티는 다른 관리 도구와 함께 Calendar Server 제품의 sbin 디렉토리에 있습니다.

이 절은 다음 내용으로 구성되어 있습니다.

• 3.3.1 csmigrate 유틸리티 구문

• 3.3.2 csmigrate 예

• Calendar Server csmigrate 유틸리티 실행 방법

3.3.1 csmigrate 유틸리티 구문

csmigrate 명령 구문은 다음과 같습니다.

csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir

옵션 및 사용법은 다음과 같습니다.

-q(선택 사항)

자동 모드를 지정하며 출력되는 내용이 없습니다.

-d(선택)

드라이런 모드를 지정하며 새 데이터베이스를 기록하지 않습니다.

-l min|max(선택 사항)

로그 수준을 지정합니다. 마이그레이션 로그는 기본 로그 디렉토리의 csmigrate.log에 기록되고 오류는 csmigrateError.log에 기록됩니다.

-b backup_dir(선택 사항)

소스 데이터베이스를 백업할 디렉토리를 지정합니다. 프로그램은 소스 데이터베이스를 이 디렉토리로 백업해 두고 소스 데이터베이스가 손상되지 않도록 복사본에서 작업합니다. 기본 위치는 소스 데이터베이스 디렉토리의 backup입니다.

-source_dbdir(필수)

마이그레이션하기 전 데이터베이스 파일이 위치한 디렉토리입니다.

-target_dbdir(필수)

마이그레이션 후 파일이 생성된 디렉토리입니다.

-V(기타 지원 옵션)

도구의 버전 정보를 표시합니다.

-?(기타 지원 옵션)

도구의 사용법을 표시합니다.

프로그램 종료 코드는 실패할 경우 255, 성공할 경우 0입니다.

3.3.2 csmigrate 예

csmigrate 명령에서 옵션을 사용하는 예는 다음과 같습니다.

csmigrate -b /var/opt/SUNWics5/tmpdb /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db
csmigrate -q /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db
csmigrate -l min old_db /var/opt/SUNWics5/new_db
csmigrate -l max old_db /var/opt/SUNWics5/new_db

Calendar Server csmigrate 유틸리티 실행 방법

1. 루트 권한으로 로그인합니다.

2. 모든 서비스를 중지합니다.

   예를 들어, 다음 명령을 실행합니다.

   stop-cal

3. 현재 데이터베이스를 임시 디렉토리로 이동합니다.

   예를 들어, 전체 csdb 디렉토리를 oldcsdb로 이동합니다.

   mv cal-svr-base/SUNWics5/csdb/* cal-svr-base/SUNWics5/oldcsdb

4. 새 디렉토리 및 이 디렉토리의 이전 파일의 소유자가 기본 관리자(icsuser, icsgroup)인지 확인합니다.

   소유권이 올바르지 않으면 다음 명령을 사용하여 소유권을 변경합니다.

   chown -R icsuser:icsgroup /cal-svr-base/SUNWics5/oldcsdb/

5. 마이그레이션 도구를 실행합니다.

   다음 예에 나와 있는 것처럼 새로운 백업 복사본(oldcsdb)을 csdb 디렉토리로 마이그레이션합니다.

   cd cal-svr-base/SUNWics5/cal/sbin/ 
   ./csmigrate -l max /cal-svr-base/SUNWics5/oldcsdb cal-svr-base/SUNWics5/csdb

6. 달력 서비스를 다시 시작합니다.

   예를 들어, 다음 명령을 사용합니다.

   start-cal

3.4 cs5migrate 유틸리티

cs5migrate 유틸리티는 Calendar Server 5.1.1 데이터베이스를 Calendar Server 6.3 수준으로 마이그레이션하는 데 사용됩니다. 또한 이전의 Calendar Server 6 버전 중 하나에서 마이그레이션하고 반복 옵션을 사용하지 않는 경우 이 유틸리티를 실행합니다.

cs5migrate 유틸리티는 다음 작업을 수행합니다.

이전에는 Connector for Microsoft Outlook을 사용하지 않을 경우 반복적인 데이터 변환을 수행하지 않고도 이 유틸리티를 실행할 수 있었습니다. 그러나 Calendar Server 6.3부터는 반복 데이터를 새로운 형식으로 변환해야 합니다.

이 유틸리티는 Calendar Server 6.3 소프트웨어로 업그레이드한 후 다른 관리 도구와 함께 sbin 디렉토리에서 찾을 수 있습니다.

3.5 csmig 유틸리티

csmig 유틸리티는 달력 데이터베이스의 각 달력에 소유자를 할당하며 필요한 경우 각 달력 아이디(calid)를 소유자에 매핑합니다.

csmig 유틸리티는 다중 도메인 및 LDAP 달력 조회 데이터베이스(CLD) 플러그 인을 지원합니다. 마이그레이션된 데이터베이스의 달력은 LDAP CLD 플러그 인을 사용하여 액세스할 수 있습니다. LDAP CLD 플러그 인에 대한 자세한 내용은 5 장, Calendar Server 버전 6.3에서 여러 시스템 간 달력 데이터베이스 배포 구성을 참조하십시오.

이 절에서는 다음 항목에 대해 설명합니다.

• 3.5.1 csmig 유틸리티 기능

• 3.5.2 csmig 유틸리티 요구 사항

• 3.5.3 csmig 구문

• 3.5.4 csmig 유틸리티 마이그레이션 단계

• 3.5.5 csmig 팁 및 문제 해결

3.5.1 csmig 유틸리티 기능

csmig 마이그레이션 유틸리티는 다음 기능을 수행합니다.

• 3.5.1.1 달력 마이그레이션

• 3.5.1.2 달력에 소유자 할당

• 3.5.1.3 LDAP 속성 업데이트

3.5.1.1 달력 마이그레이션

csmig는 caldb.berkeleydb.homedir.path 매개 변수가 지정한 현재 달력 데이터베이스(*.db 파일)의 사용자 및 자원 달력을 마이그레이션합니다. 새 대상 데이터베이스에서는 csmig가 달력 등록 정보(calprops ), 이벤트, 수행할 작업 및 그룹 예약 엔진(GSE) 데이터베이스 파일에서 LDAP CLD 플러그 인에 필요한 항목을 업데이트합니다.

csmig는 대상 데이터베이스에만 기록하며 사용자의 기존 달력 데이터베이스는 업데이트하지 않습니다.

3.5.1.2 달력에 소유자 할당

csmig는 달력 데이터베이스의 각 달력에 소유자를 할당하며 필요한 경우 각 달력 아이디(calid)를 소유자에 매핑합니다. 모든 기본 calid가 그대로 유지되며 아무 것도 변경되지 않습니다.

다른 달력은 다음과 같이 매핑됩니다.

• 유효한 소유자가 없는 사용자 달력은 -c 옵션으로 csmig에 전달된 사용자가 소유합니다. 예를 들어, 달력 아이디 jsmith의 소유자가 없다면 orphan:jsmith로 변환되며, 여기서 orphan은 -c 옵션으로 지정됩니다.

• 소유자가 없는 자원 달력은 -r 옵션에 의해 csmig에 전달된 자원 사용자가 소유합니다.

• 자원 달력 이름에 콜론(:)이 포함되었다면 밑줄로 변환되므로 마이그레이션된 이름에는 콜론이 하나만 있습니다.

  예를 들어, bkamdar가 소유자이고 이름이 football인 달력은 bkamdar:football로 변환됩니다. bkamdar가 소유자인 tchang:soccer라는 이름의 달력은 bkamdar:tchang_soccer로 변환됩니다. admin1이 소유자인 auditorium:room1이라는 자원 달력은 admin1:auditorium_room1로 변환됩니다.

3.5.1.3 LDAP 속성 업데이트

csmig는 모든 관련 LDAP 항목에 대해 icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet를 비롯한 LDAP 속성을 업데이트하고 자원 달력에 대해 uid를 업데이트합니다. csmig는 LDAP 디렉토리 서버 데이터베이스의 각 달력에 대해 icsDWPHost 속성을 만듭니다. icsDWPHost는 달력이 상주하는 백엔드 서버의 호스트 이름을 지정합니다.

3.5.2 csmig 유틸리티 요구 사항

csmig를 사용하기 위한 요구 사항은 다음과 같습니다.

• 달력 데이터베이스가 손상되지 않아야 합니다. csdb check 명령을 사용하여 달력 데이터베이스를 점검하고 필요한 경우 csdb rebuild 명령을 실행하여 데이터베이스를 재구축합니다. 이러한 명령에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

• 새로운 대상 데이터베이스 및 백업 데이터베이스(해당하는 경우)에 사용할 충분한 디스크 공간이 있어야 합니다.

• csmig를 실행하려면 icsuser(또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인합니다. csmig를 수퍼유저(root)로 실행하는 경우에는 마이그레이션된 파일에 대한 권한을 재설정해야 할 수도 있습니다.

  또한 사용자 기본 설정을 저장하는 LDAP 디렉토리 서버에서 달력 사용자의 속성을 관리할 권한이 있어야 합니다.

• Calendar Server를 중지해야 합니다.

3.5.3 csmig 구문

csmig 유틸리티 구문은 다음과 같습니다.

csmig [-t DestinationDB]
      [-b Backend-DWPHost]
      [-o OutputFile]
      [-e ErrorFile]
      [-m MappingFile]
      [-c calendarOwner]
      [-r resourceOwner]
      { migrate|dryrun }

다음 표에서는 유틸리티 옵션을 나열하고 각각의 설명과 기본값을 제공합니다.

3.5.4 csmig 유틸리티 마이그레이션 단계

Calendar Server 5.1.1 이전 버전을 사용하는 경우 Calendar Server 6.3을 설치 및 구성한 후 csmig를 실행하여 기존 Calendar Server 및 LDAP 데이터베이스를 마이그레이션할 수 있습니다. LDAP CLD 플러그 인이 제대로 작동하려면 LDAP 데이터의 마이그레이션이 필요합니다. 이 단계에 따라 csmig를 사용하여 달력을 마이그레이션합니다.

csmig 사용을 위한 고급 단계

1. comm_dssetup.pl을 사용하여 Directory Server를 구성합니다.

   comm_dssetup.pl을 사용하여 LDAP 속성을 아직 색인화하지 않았다면 지금 수행하십시오. 그러면 LDAP 데이터 마이그레이션의 성능이 크게 향상됩니다.

2. 작업 서버가 아닌 스테이징 서버를 사용하여 테스트 드라이런을 수행합니다.

   드라이런은 실제 마이그레이션 과정에서 csmig가 수행할 작업을 보고하며 데이터를 마이그레이션하지는 않습니다. 드라이런을 수행한 후 실제로 마이그레이션하기 전에 오류를 수정하고 미해결 달력을 처리할 계획을 세울 수 있습니다.

   테스트 드라이런을 수행하는 방법은 3.5.4 csmig 유틸리티 마이그레이션 단계를 참조하십시오.

3. 작업 데이터 마이그레이션

   작업 실행 중 csmig는 달력 데이터베이스(.db 파일) 및 LDAP 데이터(사용자 및 그룹 기본 설정 데이터), icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet 및 uid(자원 달력)를 마이그레이션합니다. 마이그레이션이 끝나면 모든 달력 자원에 대해 LDAP 항목이 만들어집니다.

   작업 데이터를 마이그레이션하는 방법에 대한 자세한 내용은 3.5.4 csmig 유틸리티 마이그레이션 단계를 참조하십시오.

테스트 드라이런을 수행하려면

1. Calendar Server 6.3을 스테이징 서버에 설치합니다(필요한 경우).

2. 달력 데이터베이스의 스냅샷을 스테이징 서버에 복사합니다.

3. 다음과 같이 수행하여 스테이징 서버의 작업 LDAP 환경을 비슷하게 만듭니다.

   • Directory Server를 설치합니다.

   • 이 서버에 LDAP 데이터베이스의 스냅샷을 설치합니다.

4. comm_dssetup.pl을 실행하여 스테이징 Directory Server를 구성합니다.

5. csconfigurator.sh를 실행하여 스테이징 Calendar Server를 구성합니다.

6. icsuser로 로그인합니다(또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디로 로그인). csmig를 수퍼유저(root)로 실행하는 경우에는 마이그레이션된 파일에 대한 권한을 재설정해야 할 수도 있습니다.

7. cal-svr-base/SUNWics5/cal/sbin 디렉토리로 변경합니다.

8. csdb check 명령을 사용하여 데이터베이스가 손상되었는지 점검합니다. 손상이 발견된 경우에는 csdb rebuild를 실행하여 데이터베이스를 재구축합니다.

9. 소유자가 없는 달력에 대해 포괄적인 calid를 만들 수도 있습니다. 예를 들어, 다음 명령은 calid가 orphan인 사용자를 만듭니다.

   ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

10. stop-cal 명령을 사용하여 Calendar Server를 중지합니다(필요한 경우).

    cal-svr-base/SUNWics5/cal/sbin/stop-cal

11. -dryrun 옵션을 사용하여 csmig를 실행합니다. 예를 들어, 다음과 같이 입력할 수 있습니다.

    ./csmig -b sesta.com -o csmig.out -e csmig.errors
     -m csmig.map -c orphan -r calmaster dryrun

    이 명령은 소유자가 없는 사용자 달력(고아 달력)을 소유자 orphan에 할당하고 소유자가 없는 자원 달력을 소유자 calmaster에게 할당합니다.

12. 출력 매핑 파일(csmig.map)을 확인합니다. 매핑 파일에서는 LDAP 스키마에서 업데이트해야 하는 항목을 나열합니다.

13. 출력, 매핑 및 오류 파일을 확인합니다. 발견한 LDAP 문제 또는 오류를 해결합니다. 실제로 마이그레이션하기 전에 미해결 달력을 처리하는 방법을 결정합니다.

    다음과 같은 방법을 사용할 수 있습니다.

    • 마이그레이션하기 전에 불필요한 달력을 삭제합니다.

    • 미해결 달력에 소유자를 할당합니다.

    • -c와 -r 옵션을 사용하여 마이그레이션 중에 csmig가 달력에 소유자를 할당할 수 있게 합니다.

14. csmig를 실행하여 스테이징 달력 데이터베이스를 마이그레이션합니다.

    예를 들어, 다음 명령은 달력 데이터베이스를 /var/opt/SUNWics5/testcsdb/ 디렉토리로 마이그레이션합니다.

    ./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com 
    -o csmig.out -e csmig.errors -m csmig.map -c orphan 
    -r calmaster migrate

15. 테스트 마이그레이션이 끝나면 이 단계를 수행하여 새롭게 마이그레이션된 달력 데이터베이스를 확인합니다.

    1. 마이그레이션된 데이터베이스를 caldb.berkeleydb.homedir.path 매개 변수에서 지정한 /csdb 디렉토리로 복사합니다. 또는 마이그레이션된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다.

    2. 새 달력 데이터베이스에서 csdb check를 실행합니다. 마이그레이션된 데이터베이스의 이벤트 및 수행할 작업 수가 마이그레이션 전의 합계와 일치해야 합니다.

    3. icsCalendarOwned 항목을 검색하고 이 항목이 마이그레이션 전의 달력 수와 일치하는지 확인합니다.

    4. Communications Express에 로그인하고 마이그레이션된 데이터베이스에서 일부 달력을 확인합니다.

       테스트 마이그레이션이 성공하면 작업 데이터베이스를 마이그레이션할 준비가 된 것입니다.

작업 데이터 마이그레이션

1. icsuser(또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인합니다. csmig를 수퍼유저(root)로 실행하는 경우에는 마이그레이션된 파일에 대한 권한을 재설정해야 할 수도 있습니다.

2. cal-svr-base/SUNWics5/cal/sbin 디렉토리로 변경합니다.

3. stop-cal 명령을 사용하여 Calendar Server를 중지합니다.

   cal-svr-base/SUNWics5/cal/sbin/stop-cal

4. 다음 데이터를 백업합니다.

   • 달력 데이터베이스(.db 파일)

   • LDAP 데이터: slapd 데이터베이스 디렉토리 및 LDAP 데이터베이스

   • ics.conf 파일. 이 단계는 필수 단계가 아니지만 원래 구성으로 되돌려야 할 경우 유용합니다.

5. -migrate 옵션을 사용하여 csmig를 실행합니다.

   예를 들어, 다음 명령은 달력 데이터베이스를 /var/opt/SUNWics5/newcsdb/ 디렉토리로 마이그레이션합니다.

   ./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com 
   -o csmig.out -e csmig.errors -m csmig.log -c orphan 
   -r calmaster migrate

6. 오류 파일(csmig.errors )에서 미해결 달력이 있는지 확인하고 3.5.4 csmig 유틸리티 마이그레이션 단계에서 세운 계획에 따라 문제를 해결합니다.

7. csdb check 명령을 실행하여 마이그레이션된 데이터베이스를 확인합니다. 손상이 발견된 경우에는 csdb rebuild를 실행하여 데이터베이스를 재구축합니다.

8. 새로 마이그레이션된 데이터베이스를 caldb.berkeleydb.homedir.path 매개 변수에서 지정한 /csdb 디렉토리로 복사합니다. 또는 마이그레이션된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다.

9. ics.conf 파일에서 다음과 같이 구성 매개 변수를 적절히 변경하여 LDAP CLD 플러그 인을 활성화합니다.

   • service.dwp.enable = "yes"

   • service.dwp.port = "59779"

   • csapi.plugin.calendarlookup = "yes"

   • csapi.plugin.calendarlookup.name = "*"

   • caldb.cld.type = "directory"

   • caldb.dwp.server.default = "default-server-name"

   • caldb.dwp.server. server-hostname.ip = "server-hostname"(로컬 서버를 포함하는 각 백엔드 서버의 경우)

   • caldb.cld.cache.enable = "yes" (CLD 캐시 옵션을 사용할 경우)

   • caldb.cld.cache.homedir.path는 CLD 캐시 디렉토리 위치를 지정합니다. 기본값은 /var/opt/SUNWics5/csdb/cld_cache입니다.

     LDAP CLD 플러그 인의 구성 매개 변수 설정에 대한 자세한 내용은 5 장, Calendar Server 버전 6.3에서 여러 시스템 간 달력 데이터베이스 배포 구성을 참조하십시오.

10. start-cal 명령을 사용하여 Calendar Server를 다시 시작합니다.

11. Communications Express에 로그인하고 마이그레이션된 달력 일부를 확인하여 구성이 제대로 작동하는지 확인합니다.

    검사 중에 경보를 비활성화하려면 ics.conf 파일의 다음 매개 변수를 "no"로 설정합니다.

    • caldb.serveralarms = "no"

    • caldb.serveralarms.dispatch = "no"

    • service.ens.enable = "no"

    • service.notify.enable = "no"

    • ine.cancellation.enable = "no"

    • ine.invitation.enable = "no"

    • service.admin.alarm = "no"

3.5.5 csmig 팁 및 문제 해결

이 절에서는 다음과 같은 팁과 문제 해결 예를 보여 줍니다.

• 3.5.5.1 csmig 드라이런 달력에서 잘못된 달력 소유자를 표시하는 경우

• 3.5.5.2 LDAP 달력 검색이 제대로 실행되지 않는 경우

• 3.5.5.3 csmig 드라이런이 중복된 달력 이름을 보여주는 경우

• 3.5.5.4 고아 달력을 다른 소유자에게 할당하려는 경우

• 3.5.5.5 달력 사용자를 다른 백엔드 서버로 이동시키는 방법

3.5.5.1 csmig 드라이런 달력에서 잘못된 달력 소유자를 표시하는 경우

문제의 예

tchang:myCalendar라는 달력의 소유자가 달력 데이터베이스에서는 jsmith이고 csmig 드라이런에서는 jsmith:tchang_myCalendar로 매핑을 표시합니다. 하지만 이 달력 이름을 tchang:myCalendar로 지정하고 소유자를 tchang으로 지정하려고 합니다.

해결책의 예

마이그레이션하기 전에 cscal 유틸리티를 사용하여 tchang:myCalendar 달력의 소유자를 tchang으로 변경합니다. 그러면 마이그레이션 과정에서 이 달력을 tchang:myCalendar로 매핑하고 icsCalendarowned를 사용자 아이디 tchang의 LDAP 항목에 추가합니다.

3.5.5.2 LDAP 달력 검색이 제대로 실행되지 않는 경우

문제의 예

마이그레이션을 실행한 다음 LDAP 달력 검색이 활성화되지만, 달력 검색 대화 상자가 아무 결과도 반환하지 않거나 부분적인 결과만 반환합니다.

해결책의 예

LDAP 달력 검색을 활성화하면 Calendar Server에서 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))을 검색할 수 있게 됩니다.

다음 필터를 사용하여 LDAP 데이터에서 서로 다른 두 가지 검색을 수동으로 실행하고 출력 내용을 비교합니다.

• 필터 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))을 사용한 LDAP 검색

• 필터 (icscalendarowned=*substr*)을 사용한 LDAP 검색

서버에서 icsCalendarUser 객체 클래스가 포함된 필터를 사용하기 때문에 스키마 점검이 비활성인 상태로 LDAP 서버가 배포되었을 가능성이 있고 icsCalendarUser 객체 클래스 없이 일부 달력 항목이 관리되었을 수 있습니다.

3.5.5.3 csmig 드라이런이 중복된 달력 이름을 보여주는 경우

문제의 예

csmig 드라이런 매핑 파일과 출력 파일에 따르면 중복된 달력 이름이 있습니다.

예를 들어, 원본 데이터베이스에서 jsmith가 다음 달력을 소유합니다.

• 5개의 이벤트가 있는 basketball

• 19개의 이벤트가 있는 jsmith:basketball

드라이런에 따르면 마이그레이션 과정에서 두 달력이 병합되며 그 결과 달력은 소유자가 jsmith이고 총 15개의 이벤트가 있는 jsmith:basketball이 됩니다.

출력 파일은 다음 경고 메시지를 포함합니다.

Error modifying calendar properties, error=2

해결책의 예

두 달력을 병합하지 않으려면 마이그레이션 전에 basketball의 소유자를 jsmith 이외의 사용자로 변경합니다. 그러면 서로 다른 두 달력의 데이터 무결성이 보존됩니다.

3.5.5.4 고아 달력을 다른 소유자에게 할당하려는 경우

문제의 예

기본적으로 csmig는 모든 고아 달력을 한 소유자에게 할당하지만 일부 고아 달력을 다른 소유자에게 할당하려고 합니다.

해결책의 예

csmig의 경우 명령줄에서 매핑 파일을 사용할 수 없습니다. 그러나 마이그레이션을 실행하기 전에 원본 데이터베이스에서 고아 달력에 소유자를 할당할 수 있습니다. 모든 고아 달력에 대해 드라이런 매핑 파일을 점검합니다. 그리고 마이그레이션을 실행하기 전에 cscal 유틸리티를 사용하여 고아 달력에 소유자를 할당합니다. -dryrun 모드에서 csmig를 다시 실행하여 새 소유자를 확인합니다.

3.5.5.5 달력 사용자를 다른 백엔드 서버로 이동시키는 방법

문제의 예

사용자를 한 백엔드 서버에서 다른 서버로 이동시키는 방법은 무엇입니까?

해결책의 예

달력 사용자를 이동하려면 export를 실행하여 원본 서버의 사용자 달력 각각을 내보낸 다음 import를 실행하여 두 번째 서버로 달력을 가져옵니다. 달력을 이동하고 나면 원본 서버의 달력을 삭제할 수 있습니다. 달력 이동 방법에 대한 자세한 내용은 15.6 사용자 달력 관리를 참조하십시오.

3.6 csvdmig

csvdmig 유틸리티는 다중 도메인 환경에서 사용할 달력 데이터베이스, LDAP 사용자 및 그룹 항목을 준비합니다. 기본 도메인만 사용하려는 경우에도 이 유틸리티를 실행해야 합니다.

도메인이 아닌 환경에서 Calendar Server 6.3의 다중 도메인 환경으로 마이그레이션하는 경우 csmig를 실행한 후 이 유틸리티를 사용하십시오.

이절은 다음 내용으로 구성되어 있습니다.

• 3.6.1 csvdmig 기능

• 3.6.2 csvdmig 구문

• 3.6.3 csvdmig 예

3.6.1 csvdmig 기능

csvdmig유틸리티는 데이터베이스 및 LDAP 항목에 대해 다음 내용을 변경합니다.

• 달력 아이디(calids)의 형식은 다음과 같이 변경됩니다.

  변경 전: userid[:calendar-name]

  변경 후: userid@domain[:calendar-name]

• 액세스 제어 목록(ACL) 액세스 규칙은 다음과 같이 변경됩니다.

  변경 전: userid

  변경 후: userid@domain

• Calendar Server 속성에 대한 LDAP 디렉토리 서버 사용자 항목은 다음과 같이 수정됩니다.

  userid[:calendar-name]에서 userid@domain[:calendar-name]으로

• 달력 데이터베이스에 있는 이벤트/작업의 소유자 및 참석자 필드를 업데이트합니다. 예를 들면 다음과 같습니다.

  도메인 sesta.com의 jsmith가 이벤트 소유자인 경우, 새 소유자 필드에는 jsmith@sesta.com이 포함됩니다.

csvdmig 유틸리티는 데이터베이스와 LDAP 디렉토리를 현재 위치에서 업데이트합니다. 즉 별도로 마이그레이션된 데이터베이스를 생성하는 것이 아니라 변환 중인 데이터베이스를 변경합니다. 그러므로 데이터베이스 및 LDAP 디렉토리의 스냅샷에 대해 csvdmig를 실행하는 것이 안전합니다.

3.6.2 csvdmig 구문

csvdmig 유틸리티는 다음 구문을 사용합니다.

csvdmig [-t DestinationDB]
         [-c ConfigFile]
         [-e ErrorFile]
         [-m MappingFile]
         migrate [DB|LDAP]

다음 표에서는 csvdmig에 사용되는 옵션을 나열하고 각각에 대한 설명을 제공합니다.

3.6.2.1 매핑 파일

매핑 파일은 기존 사용자를 해당 도메인에 매핑하는 입력 텍스트 파일입니다. csvdmig를 실행하기 전에 매핑 파일을 만들어야 합니다. 기존 값과 새 값 사이에 공백을 사용하여 각 행마다 하나씩 항목을 지정합니다. 예를 들면 다음과 같습니다.

user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
 ...
usern usern@siroe.com

3.6.2.2 대상 DB

데이터베이스를 마이그레이션할 위치입니다. 유틸리티가 해당 위치에서 파일을 업데이트합니다. csvdmig 유틸리티를 사용하기 전에 이 디렉토리를 백업하십시오.

-t 옵션을 지정하지 않은 경우 유틸리티가 명령줄에서 pwd를 수행하여 지정한 현재 디렉토리의 내용에 대해 마이그레이션을 시도하여 예상치 못한 결과가 발생합니다.

3.6.3 csvdmig 예

다음은 csvdmig 예입니다.

• 기본값을 사용하여 LDAP 디렉토리 서버 데이터 마이그레이션

  csvdmig migrate LDAP

• Calendar Server 데이터베이스 마이그레이션

  csvdmig -t targetDB -e errorFile -m mappingFile migrate

3.7 commdirmig

commdirmig 유틸리티는 인증 서비스를 위한 Access Manager 사용에 대비하여 LDAP 데이터를 Sun Java System LDAP Schema 버전 1에서 Schema 버전 2로 마이그레이션합니다. 이전 설치에서 이미 Schema 버전 2를 사용한 경우 이 유틸리티를 다시 실행하지 않아도 됩니다.

• 3.7.1 commdirmig 유틸리티를 실행할 사용자

• 3.7.2 commdirmig 유틸리티를 실행할 시기

• 3.7.3 commdirmig 유틸리티에 대한 설명서의 위치

• 3.7.4 유틸리티 위치

3.7.1 commdirmig 유틸리티를 실행할 사용자

이 마이그레이션 유틸리티는 Schema 버전 1 LDAP 데이터베이스를 Schema 버전 2로 마이그레이션합니다. 인증에 Access Manager 소프트웨어를 사용하려면 이 유틸리티를 실행하여 LDAP 항목을 Schema 버전 2 형식으로 변환해야 합니다.

Schema 버전 2는 LDAP를 사용하는 모든 Communications Suite 제품에서 기본 LDAP 모드이므로 Access Manager를 사용 중이 아니라면 LDAP 데이터 마이그레이션을 고려해야 합니다.

기본 설정용 LDAP 디렉토리가 별도로 있다면 인증용 LDAP뿐 아니라 이 LDAP에서도 commdirmig를 실행해야 합니다.

3.7.2 commdirmig 유틸리티를 실행할 시기

이전 버전의 Calendar Server 소프트웨어에서 6.3 버전의 Calendar Server 소프트웨어로 달력 및 LDAP 데이터베이스를 마이그레이션하는 데 필요한 다른 마이그레이션 유틸리티를 모두 실행한 후 commdirmig를 실행합니다.

3.7.3 commdirmig 유틸리티에 대한 설명서의 위치

commdirmig 마이그레이션 유틸리티를 사용하려면 특별한 준비와 계획이 필요합니다. 이 내용은 별도의 설명서에 나와 있습니다. Sun Java Communications Suite 5 Schema Migration Guide를 참조하십시오.

3.7.4 유틸리티 위치

commdirmig 유틸리티는 Communications Suite 설치 프로그램에서 설치하는 Delegated Administrator와 함께 제공됩니다.

이 유틸리티용 패치도 기술 지원부에서 구할 수 있습니다.