4장 데이터베이스 마이그레이션 유틸리티

Calendar Server를 설치하고 설치 후 구성을 수행한 후에도 이전 버전의 Calendar Server(5.11 및 이전 버전)가 있다면 구성 요소 데이터베이스와 LDAP 데이터베이스를 마이그레이션해야 합니다.

이 장의 올바른 유틸리티 선택 절에서 실행해야 하는 올바른 유틸리티를 선택하는 방법을 설명합니다.

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

• 설치 후 데이터베이스 마이그레이션 유틸리티

• 올바른 유틸리티 선택

• csmig

• csvdmig

• commdirmig

설치 후 데이터베이스 마이그레이션 유틸리티

un Java System Calendar Server를 설치한 후에도 이전에 설치된 Calendar Server 5.1.1에서 가져온 달력 데이터베이스와 LDAP 데이터베이스 항목이 있다면 다음 유틸리티를 순서대로 실행합니다.

1. cs5migrate

   Calendar Server 버전 5에서 버전 6 형식으로 달력 데이터베이스를 마이그레이션합니다. 이 유틸리티는 기술 지원에서 다운로드할 수 있습니다.

   Connector for Microsoft Outlook을 사용할 계획이고 반복 구성 요소가 있는 경우 각 반복 시리즈에 대해 마스터 레코드 및 예외를 만드는 cs5migrate_recurring을 사용합니다.

   기존 데이터베이스에 반복 구성 요소가 없거나 반복 구성 요소가 있지만 Connector for Microsoft Outlook을 사용하지 않으려면 cs5migrate를 사용합니다.

   cs5migrate 및 cs5migrate_recurring은 기술 지원을 통해서만 사용할 수 있습니다. 제품과 함께 제공되지 않습니다.

2. csmig

   Calendar Server 6 데이터베이스의 각 달력에 소유자를 지정하고 필요한 경우 각 달력 아이디(calid)를 소유자에게 매핑하여 호스트된(가상) 도메인 및 LDAP 달력 조회 데이터베이스(CLD) 플러그 인에 대한 지원을 사용할 수 있게 합니다. 이 유틸리티는 Calendar Server와 같은 패키지로 제공됩니다. 이 유틸리티는 cs5migrate 실행 후, csvdmig 실행 전에 실행합니다.

3. csvdmig

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

4. commdirmig

   Access Manager 6.1 이상에서 사용할 수 있도록 LDAP 데이터를 스키마 1에서 스키마 2로 마이그레이션합니다. 이 유틸리티는 Access Manager와 함께 제공됩니다.

올바른 유틸리티 선택

선택할 수 있는 유틸리티가 많으므로 아래 그래픽을 참조하여 실행할 유틸리티를 선택하십시오.

그림 4–1 실행할 마이그레이션 유틸리티 선택

csmig

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

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

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

• csmig 기능

• csmig 요구 사항

• csmig 구문

• csmig 마이그레이션 단계

• csmig 팁 및 문제 해결

csmig 기능

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

• 달력 마이그레이션

• 달력에 소유자 할당

• LDAP 속성 업데이트

달력 마이그레이션

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

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

달력에 소유자 할당

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.

LDAP 속성 업데이트

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

csmig 요구 사항

csmig 사용에 대한 요구 사항은 다음과 같습니다.

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

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

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

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

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

csmig 구문

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

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

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

csmig 마이그레이션 단계

Calendar Server 6을 설치하고 구성한 후에 csmig를 실행하여 기존 Calendar Server 및 LDAP 데이터를 마이그레이션해야 합니다. LDAP CLD 플러그 인이 제대로 작동하려면 LDAP 데이터의 마이그레이션이 필요합니다. 이 단계에 따라 csmig를 사용하여 달력을 마이그레이션합니다.

csmig 사용을 위한 고급 단계

단계

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

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

2. (작업 서버가 아닌)스테이징 서버를 사용하여 테스트 건실행을 수행합니다.

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

   테스트 건실행을 수행하는 방법에 대한 자세한 내용은 csmig 마이그레이션 단계를 참조하십시오.

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

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

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

테스트 건실행 수행

단계

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

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. csmig를 migrate 옵션을 사용하여 실행합니다.

   예를 들어, 다음 명령은 달력 데이터베이스를 /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)에서 미해결 달력이 있는지 확인하고 csmig 마이그레이션 단계의 csmig 마이그레이션 단계에서 세운 계획에 따라 해결합니다.

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

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

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

   • service.dwp.enable = "yes"

   • service.dwp.port = "9779"

   • csapi.plugin.calendarlookup = "y"

   • 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 플러그 인의 구성 매개 변수 설정에 대한 자세한 내용은 6 장, 여러 시스템에서 달력 데이터베이스 배포 구성을 참조하십시오.

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"

csmig 팁 및 문제 해결

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

• csmig 건실행 달력에 달력의 소유자가 잘못 표시되어 있습니다.

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

• csmig 건실행이 중복된 달력 이름을 보여주는 경우

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

• 달력 사용자를 다른 백엔드 서버로 이동하려는 경우

csmig 건실행 달력에 달력의 소유자가 잘못 표시되어 있습니다.

문제의 예

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

해결책의 예

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

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

문제의 예

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

해결책의 예

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

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

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

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

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

csmig 건실행이 중복된 달력 이름을 보여주는 경우

문제의 예

csmig 건실행 매핑 파일과 출력 파일에 따르면 중복된 달력 이름이 있습니다. 예를 들어, 원본 데이터베이스에서 jsmith가 다음 달력을 소유합니다.

• 5개의 이벤트가 있는 basketball

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

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

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

Error modifying calendar properties, error=2

해결책의 예

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

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

문제의 예

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

해결책의 예

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

달력 사용자를 다른 백엔드 서버로 이동하려는 경우

문제의 예

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

해결책의 예

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

csvdmig

csvdmig 유틸리티는 호스트된(가상) 도메인을 사용할 사이트의 Calendar Server 데이터베이스와 LDAP 디렉토리 서버 데이터베이스를 수정합니다.

호스트되지 않은 환경에서 이동할 경우 이 유틸리티를 사용하기 전에 csmig를 실행해야 합니다.

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

• csvdmig 기능

• csvdmig 구문

• csvdmig 예

csvdmig 기능

csvdmig 유틸리티는 다음과 같이 도메인 이름을 사용자 아이디에 추가합니다.

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

  변경 전: userid[:calendar-name]

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

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

  변경 전: userid

  변경 후: userid@domain

• Calendar Server 속성에 대한 LDAP Directory Server 사용자 항목은 다음과 같이 수정됩니다.

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

• 달력 데이터베이스에 있는 이벤트/태스크의 소유자 및 참석자 필드를 업데이트합니다.

  예를 들면 다음과 같습니다. 도메인 sesta.com의 jsmith가 이벤트 소유자인 경우, 새 소유자 필드에는 jsmith@sesta.com이 포함됩니다.

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

csvdmig 구문

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

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

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

매핑 파일

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

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

대상 DB

이 유틸리티는 마이그레이션된 파일을 새 DestinationDB로 이동하지 않습니다. -t 옵션을 지정할 경우 csvdmig를 실행하기 전에 해당 디렉토리로 마이그레이션할 데이터베이스 파일을 복사해야 합니다.

-t 옵션을 지정하지 않으면 유틸리티는 작업 디렉토리에 있는 파일을 마이그레이션하므로 예측할 수 없는 결과가 발생할 수 있습니다.

csvdmig 예

• 기본값을 사용하여 LDAP Directory Server 데이터 마이그레이션

  csvdmig migrate LDAP

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

  csvdmig -t targetDB -e errorFile -m mappingFile migrate

commdirmig

commdirmig 유틸리티는 인증 서비스를 위한 Access Manager 사용에 대비하여 LDAP 데이터를 Sun LDAP 스키마 1에서 스키마 2로 마이그레이션합니다.

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

• 유틸리티 실행 담당자

• 유틸리티 실행 시간

• 설명서 위치

• 유틸리티 위치

유틸리티 실행 담당자

이전에 Messaging Server 5 또는 Calendar Server 5 버전을 사용한 경우에는 LDAP 항목이 Sun LDAP Schema 1용으로 포맷되어 있습니다. 새 Calendar Server 6 2005Q4 환경에서의 인증에 Access Manager를 사용하려면 이 유틸리티를 실행하여 LDAP 항목을 스키마 2로 변환해야 합니다.

스키마 2는 LDAP를 사용하는 모든 Java Enterprise System 제품에서 기본 LDAP 모드이므로 Access Manager를 사용 중이 아니라면 LDAP 데이터 마이그레이션을 고려해야 합니다. 앞으로 새로운 버전의 통신 제품(Calendar, Messaging 및 Instant Messaging)에서는 Schema 1을 지원하지 않습니다. 하지만 당장 Access Manager를 사용할 계획이 아니라면 나중에 더 편리한 시점에 마이그레이션을 진행해도 됩니다.

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

유틸리티 실행 시간

이전 Java Enterprise System 버전에 해당하는 Calendar Server를 마이그레이션하는 경우에는 cs5migrate, csmig 및 csvdmig를 실행한 후에 이 유틸리티를 실행합니다.

설명서 위치

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

유틸리티 위치

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

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