| Solaris 운영 체제용 Sun ONE Calendar Server 6.0 설치 설명서 |
3장
Calendar Server 데이터 이전Sun™ ONE Calendar Server 6.0은 다음과 같은 이전 유틸리티를 제공합니다.
- cs5migrate 유틸리티 - Calendar Server 5.x 데이터베이스를 Calendar Server 6.0으로 이전하며 달력 데이터베이스를 Berkeley DB 버전 2.6에서 버전 3.2.9로 업그레이드합니다.
- csmig 유틸리티 - 달력 데이터베이스의 각 달력에 소유자를 할당하고 필요한 경우 각 달력 아이디(calid)를 소유자에게 매핑합니다. 이렇게 하면 호스트된 (가상) 도메인과 LDAP 달력 조회 데이터베이스(CLD) 플러그 인 지원이 허용됩니다.
- csvdmig 유틸리티 - 호스트된 (가상) 도메인을 사용하도록 Calendar Server 6.0 사이트를 업그레이드합니다.
- ics2migrate 유틸리티 - iPlanet Calendar Server 2.x에서 데이터를 이전합니다.
- ncs4migrate 유틸리티 - Netscape Calendar Server 4.x에서 데이터를 이전합니다.
- csrename 유틸리티 - 달력 데이터베이스와 LDAP Directory Server ("ics" 접두어를 가진 Calendar Server 속성)의 달력 사용자 아이디를 바꿉니다.
그림 3-1에서는 Calendar Server 이전 유틸리티를 실행하기 위한 로드맵을 표시합니다.
그림 3-1 Calendar Server 이전 유틸리티 실행을 위한 로드맵
cs5migrate 유틸리티Calendar Server 5.x에서 Calendar Server 6.0으로 업그레이드하는 경우에는 Calendar Server 6.0을 실행하기 전에 먼저 cs5migrate 유틸리티를 실행해야 합니다. cs5migrate 유틸리티는 다음 기능을 수행합니다.
이전 시간
cs5migrate 이전 시간은 여러 요소에 따라 달라질 수 있습니다. 먼저, cs5migrate에서 LDAP Directory Server에 액세스하여 스키마 속성을 업데이트해야 합니다. 그러면 LDAP 서버에 대한 네트워크 연결이 이전 시간에 큰 영향을 줄 수 있습니다. 가능하면 LDAP 서버에 대해 빠른 네트워크 연결을 설정하고 다른 네트워크 트래픽이 최소일 때 cs5migrate를 실행합니다.
이전 시나리오 - Sun Fire™ (UltraSPARC™ III Cu, CPU 12개, 750MHz, 12GB 메모리, 부동 소수점 프로세서, 20GB 교체 파일 공간이 있는 Solaris 8 OS 실행)에서 cs5migrate가 다음 Calendar Server 5.x 달력 데이터베이스를 약 1시간 15분만에 이전했습니다.
cs5migrate 구문
cs5migrate 유틸리티는 다음 구문을 사용합니다.
-q는 quiet 모드를 지정합니다. 이전에 성공하면 cs5migrate는 정보를 표시하지 않습니다. 그러나 오류가 발생하면 해당 오류를 표시합니다.
-d는 dry run 모드를 지정합니다. dry run은 실제 이전 과정에서 cs5migrate가 수행하는 일을 보고하지만 실제로 데이터를 이전하거나 데이터베이스를 업그레이드하지는 않습니다.
-r은 반복 이벤트에 대한 마스터 구성 요소를 만들도록 지정합니다.
-l min|max는 이전 로그(cs5migrate.log)의 로그 모드 및 세부 정보 수준을 지정합니다.
주 -t 옵션은 현재 릴리스에서 구현되지 않았습니다.
source-directory는 Calendar Server 5.x 데이터베이스 파일을 포함하는 디렉토리를 지정하는 필수 매개 변수입니다.
target-directory는 cs5migrate가 새 Calendar Server 6.0 데이터베이스 파일을 만들 기존 디렉토리를 지정하는 필수 매개 변수입니다.
중요 cs5migrate를 실행하기 전에 먼저 target-directory를 만들어야 합니다.
이전 프로세스
cs5migrate를 실행하기 전에 다음 단계를 수행합니다.
- csbackup, Sun StorEdge Enterprise Backup™ 소프트웨어 또는 Legato Networker®와 같은 유틸리티를 사용하여 Calendar Server 5.x 데이터베이스를 백업합니다.
- 이전하기 전에 csbd rebuild 명령을 사용하여 달력 데이터베이스를 다시 만드는 것이 좋습니다. 자세한 내용은 Sun ONE Calendar Server 관리자 설명서의 5장, “Calendar Server 데이터베이스 관리”를 참조하십시오.
- 필요하면 ics.conf 파일에서caldb.serveralarms 매개 변수를 yes로 설정하여 경보를 활성화합니다.
- Calendar Server 5.x 데이터베이스를 다른 서버로 이동해야 할 경우 데이터베이스(*.db) 파일이 너무 크지만 않으면 새 서버로 간단히 복사할 수 있습니다. 데이터베이스 파일이 큰 경우에는 데이터베이스 파일의 압축 파일을 만들고 그 압축 파일을 새 서버로 복사한 다음 압축을 풉니다.
cs5migrate를 실행하려면 다음 단계를 수행합니다.
- Solaris 및 기타 UNIX 시스템에서는 icsgroup 및 icsuser와 같이 Calendar Server를 실행 중인 사용자 및 그룹으로 로그인합니다.
- 필요한 경우 stop-cal 명령을 사용하여 Calendar Server를 중지합니다.
- 필요한 경우 target-directory를 만듭니다. target-directory가 있어야 cs5migrate를 실행할 수 있습니다.
- cs5migrate를 실행합니다. 구문에 대해서는 cs5migrate 구문을 참조하십시오.
예를 들어 Solaris 시스템에서는 다음과 같이 실행합니다.
./cs5migrate -q -l max /var/opt/SUNWics5/csdb511
/var/opt/SUNWics5/csdb60
이 예에서는 /var/opt/SUNWics5/csdb60 디렉토리가 있어야 이전할 수 있습니다.
이전 상태에 관한 정보는 cs5migrate.log 파일을 확인합니다. 이전 중에 오류가 발생하거나 달력 데이터베이스 항목을 이전할 수 없는 경우 cs5migrate는 해당 사항을 cs5migrateerror.log에 작성합니다.
- cs5migrate는 ics.conf 파일을 수정하지 않으므로 cs5migrate가 완료되면 ics.conf 파일의 caldb.berkeleydb.homedir.path 매개 변수는 이전된 데이터베이스를 가리킵니다.
이 매개 변수가 이전된 데이터베이스 디렉토리를 가리키도록 재설정하거나 이전된 데이터베이스 파일을 매개 변수에서 지정한 디렉토리로 이동합니다.
- LDAP 데이터 캐시 옵션(local.ldap.cache.enable = "yes")이나 CLD 캐시 옵션(caldb.cld.cache.enable = "yes")을 사용하는 경우에는 cs5migrate를 실행한 후 ldap_cache 및 cld_cache 디렉토리를 대상 디렉토리에 만듭니다.
- 이전된 데이터베이스 파일에 대한 권한을 확인합니다. cs5migrate를 icsuser로 실행한 경우 액세스 문제가 발생하지 않습니다. 수퍼유저(root)로 실행한 경우 권한을 재설정해야 할 수도 있지만 권장되지는 않습니다.
- start-cal 명령을 사용하여 Calendar Server를 다시 시작합니다.
csmig 유틸리티csmig 유틸리티는 달력 데이터베이스의 각 달력에 소유자를 할당하며 필요하다면 각 달력 아이디(calid)를 소유자와 매핑합니다.
csmig 유틸리티가 호스트된 (가상) 도메인 및 LDAP 달력 조회 데이터베이스(CLD) 플러그 인을 지원하면 이 플러그 인을 사용하여 이전된 데이터베이스의 달력에 액세스할 수 있습니다. LDAP CLD 플러그 인은 달력을 여러 백엔드 서버에 분산할 수 있게 함으로써 달력 데이터베이스의 수평 확장성을 제공합니다. LDAP CLD 플러그 인에 대한 자세한 내용은 Sun ONE Calendar Server 관리자 설명서를 참조하십시오.
이 절은 다음 내용으로 구성되어 있습니다.
csmig 기능
csmig 이전 유틸리티는 다음 기능을 수행합니다.
- csmig는 icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet 및 uid (자원 달력용)를 포함하여 LDAP 항목과 관련된 모든 LDAP 속성을 업데이트합니다. csmig는 LDAP Directory Server 데이터베이스의 각 달력에 대해 icsDWPHost 속성을 만듭니다. icsDWPHost는 달력이 상주하는 백엔드 서버의 호스트 이름을 지정합니다.
- csmig는 달력 데이터베이스의 각 달력에 소유자를 할당하며 필요하다면 각 달력 아이디(calid)를 소유자와 매핑합니다. 모든 기본 calids를 그대로 유지하며 아무 것도 변경하지 않습니다. 다른 달력은 다음과 같이 매핑됩니다.
csmig 요구 사항
csmig를 사용하기 위한 요구 사항은 다음과 같습니다.
- 달력 데이터베이스가 손상되지 않아야 합니다. csdb check 명령을 사용하여 달력 데이터베이스를 점검하고 필요하다면 csdb rebuild 명령을 실행하여 데이터베이스를 다시 만듭니다. 이 명령에 대한 정보는 Sun ONE Calendar Server 관리자 설명서를 참조하십시오.
- 새로운 대상 데이터베이스 및 백업 데이터베이스(해당되는 경우)를 위한 충분한 디스크 공간이 있어야 합니다.
- csmig를 실행하려면 icsuser (또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인합니다. csmig를 수퍼유저(root)로 실행한 경우 이전된 파일에 대한 권한을 재설정해야 할 수도 있습니다.
csmig 구문
csmig 유틸리티는 다음 구문을 사용합니다.
csmig [ -t DestinationDB ] [ -b Backend-DWPHost ]
[ -o OutputFile ] [ -e ErrorFile ] [ -m MappingFile ]
-c calendarOwner -r resourceOwner { migrate|dryrun }
-t DestinationDB는 csmig가 생성하는 대상 데이터베이스를 지정합니다. 기본값은 MigratedDB입니다.
-b Backend-DWPHost는 DWP 백엔드 호스트 서버의 이름을 지정합니다. 이 이름은 ics.conf 파일에서 지정한 DWP 백엔드 호스트 서버 이름과 일치해야 합니다.
-o OutputFile은 발생한 오류뿐 아니라 csmig 화면 출력을 캡처하는 출력 파일을 지정합니다. 기본값은 MigrateOut입니다.
-e ErrorFile은 csmig가 해결할 수 없는 오류 또는 데이터베이스 항목을 기록하는 파일입니다. 데이터베이스 항목을 해결하지 못하면 대상 데이터베이스에 이를 기록하지 않습니다. 기본값은 MigrateError입니다.
-m MappingFile은 dryrun 모드에서 생성된 출력 매핑 파일로, LDAP 스키마의 항목을 업데이트하는 데 권장되는 변경 사항을 나열합니다. 예를 들면 다음과 같습니다.
Old calid = jsmith New calid = jsmith:basketball
매핑 파일은 LDAP 스키마에 권장되는 변경 사항 목록만 제공합니다. csmig는 실제로 스키마를 변경하지 않습니다.
migrate 모드에서는 MappingFile이 사용되지 않습니다.
-c calendarOwner는 소유자가 없는 사용자 달력에 대한 소유자를 지정합니다.
-r resourceOwner는 소유자가 없는 자원 달력에 대한 소유자를 지정합니다.
csmig 이전 단계
구성에 포함된 모든 서버에 Calendar Server 6.0을 설치한 다음에는 csmig를 실행하여 기존 Calendar Server 및 LDAP 데이터를 새로운 Calendar Server 6.0 및 LDAP 데이터로 이전해야 LDAP CLD 플러그 인이 제대로 작동할 수 있습니다. 다음은 csmig를 사용하여 달력 데이터를 이전하는 권장 단계입니다.
- LDAP Directory Server 구성 - 색인을 추가하면 이전 성능 및 LDAP 데이터의 달력 검색 성능을 크게 향상시킬 수 있습니다.
- 테스트 Dry Run 수행 - dry run은 이전 과정에서 csmig가 수행할 작업을 보고하며 실제 데이터를 이전하지는 않습니다. dry run을 실행한 후 오류를 수정하고 미해결 달력을 처리할 계획을 세울 수 있습니다.
- 작업 데이터 이전 - 실제 이전 작업 실행 중 csmig는 달력 데이터베이스(.db 파일) 및 LDAP 데이터(사용자 및 그룹 기본 설정 데이터), icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet 및 uid (자원 달력)를 이전합니다. 이전이 끝나면 모든 달력 자원에 대해 LDAP 항목이 만들어집니다.
LDAP Directory Server 구성
성능을 향상하기 위해 다음 두 가지 새로운 색인을 slapd.ldbm.conf 파일에 추가할 수 있습니다.
slapd.ldbm.conf 파일에서의 색인 생성에 대한 자세한 내용은 해당 Directory Server 설명서를 참조하십시오.
테스트 Dry Run 수행
스테이징 서버에서 수행한 테스트 dry run은 이전될 내용을 보고하기만 하고 작업 데이터베이스를 실제로 이전하지는 않습니다. dry run을 사용하여 작업 데이터베이스의 이전 계획을 세울 수 있습니다. 예를 들어, 소유자가 없는 '고아' 달력을 처리하는 방법을 결정할 수 있습니다.
csmig를 사용하여 테스트 dry run을 실행하려면 다음 단계를 수행합니다.
- icsuser (또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인합니다. csmig를 수퍼유저(root)로 실행한 경우 이전된 파일에 대한 권한을 재설정해야 할 수도 있습니다.
- (필요한 경우) Calendar Server 6.0을 스테이징 서버에 설치합니다.
- 달력 데이터베이스의 스냅샷을 스테이징 서버에 복사합니다.
- 작업 LDAP 환경과 비슷하게 LDAP 서버를 설치합니다. LDAP 데이터베이스 스냅삿을 slapd.ldbm.conf 파일의 새로운 색인과 함께 해당 서버에 설치합니다.
- cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- 소유자가 없는 달력에 대해 포괄적인 calid를 만들 수도 있습니다. 예를 들어, Solaris 시스템에서 다음 명령은 orphan의 calid를 갖는 사용자를 만듭니다.
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan
- (필요한 경우) stop-cal 명령을 사용하여 Calendar Server를 중지합니다.
- csdb check 명령을 사용하여 데이터베이스가 손상되었는지 점검합니다. 손상이 발견되면 csdb rebuild를 실행하여 데이터베이스를 다시 만듭니다.
- dryrun 옵션을 사용하여 csmig를 실행합니다. 예를 들어, Solaris 시스템에서 다음과 같이 입력합니다.
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
이 명령은 소유자가 없는 사용자 달력을 orphan에 할당하고 소유자가 없는 자원 달력을 calmaster에 할당합니다.
출력 매핑 파일(csmig.map)을 확인합니다. 매핑 파일은 LDAP 스키마의 항목을 업데이트하는 데 권장되는 변경 사항을 나열합니다.
- 출력, 매핑 및 오류 파일을 점검합니다. 발견한 LDAP 문제 또는 오류를 해결합니다. 실제 이전하기 전에 미해결 달력을 처리하는 방법을 결정합니다. 다음과 같은 방법을 사용할 수 있습니다.
- 실제 작업 달력 데이터베이스를 이전하기 전에 달력 데이터베이스를 스테이징 서버로 이전하는 것이 좋습니다. 이 단계를 통해 작업 데이터베이스를 이전하기 전에 데이터 이전 방법을 정확하게 파악하고 문제를 수정할 수 있습니다.
예를 들어, Solaris 시스템에서 다음 명령은 달력 데이터베이스를 /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
- 테스트 이전이 끝나면 이전된 데이터베이스를 caldb.berkeleydb.homedir.path 매개 변수가 지정한 /csdb 디렉토리로 복사합니다. 또는 이전된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다. 그런 후 다음과 같이 점검을 수행합니다.
테스트 이전이 성공하면 작업 데이터베이스를 이전할 준비가 되었습니다.
작업 데이터 이전
csmig를 사용하여 작업 데이터베이스를 이전하려면 다음 단계를 수행합니다.
- icsuser (또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인합니다. csmig를 수퍼유저(root)로 실행한 경우 이전된 파일에 대한 권한을 재설정해야 할 수도 있습니다.
- cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- (필요한 경우) stop-cal 명령을 사용하여 Calendar Server를 중지합니다.
- 다음 데이터를 백업합니다.
- csmig를 migrate 옵션을 사용하여 실행합니다. 예를 들어, Solaris 시스템에서 다음 명령은 달력 데이터베이스를 /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
- 오류 파일에서 미해결 달력이 있는지 확인하고 테스트 Dry Run 수행의 단계 10에서 세운 계획에 따라 해결합니다.
- 새로 이전된 데이터베이스를 caldb.berkeleydb.homedir.path 매개 변수가 지정한 /csdb 디렉토리로 복사합니다. 또는 이전된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다.
- csdb check 명령을 실행하여 이전된 데이터베이스를 점검합니다. 손상이 나타나면 csdb rebuild를 실행하여 데이터베이스를 다시 만듭니다.
- 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 캐시 디렉토리의 위치를 지정합니다. 기본값은 cal_svr_base/var/opt/SUNWics5/csdb/cld_cache입니다.
- start-cal 명령을 사용하여 Calendar Server를 다시 시작합니다.
- Calendar Server에 로그인하고 이전된 여러 달력을 점검하여 구성이 제대로 작동하는지 확인합니다. 점검 중 경보를 비활성화하려면 ics.conf 파일에서 다음 매개 변수를 no로 설정합니다.
csmig 팁 및 문제 해결
이 절에서는 다음과 같은 팁과 문제 해결 방법에 대해 설명합니다.
csmig dry run 달력 소유자가 원하는 달력 소유자가 아닌 경우
예를 들어, tchang:myCalendar라는 달력이 달력 데이터베이스에서는 jsmith를 소유자로 가지고 있는데 csmig dry run은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 데이터에서 서로 다른 두 가지 검색을 수동으로 실행하고 출력 내용을 비교합니다.
서버가 icsCalendaruser 객체 클래스를 포함하는 필터를 사용하기 때문에 LDAP 서버를 스키마 점검이 비활성인 상태로 배포했을 가능성이 있고 일부 달력 항목을 icsCalendaruser 객체 클래스 없이 제공했을 수도 있습니다.
csmig dry run이 중복된 달력 이름을 보여주는 경우
csmig dry run 매핑 파일과 출력 파일에 따르면 중복된 달력 이름이 있습니다. 예를 들어, 원본 데이터베이스에서 jsmith가 다음 달력을 소유합니다.
dry run에 따르면 이전 과정에서 두 달력이 병합되며 그 결과 달력은 다음과 같습니다.
출력 파일은 다음 경고 메시지를 포함합니다.
Error modifying calendar properties, error=2
해결책
두 달력이 병합되지 않게 하려면 이전을 실행하기 전에 basketball에 jsmith가 아닌 소유자를 지정합니다. 이렇게 하면 서로 다른 두 달력의 데이터 무결성이 보존됩니다.
고아 달력을 다른 소유자에게 할당하려는 경우
기본적으로 csmig는 모든 고아 달력을 한 소유자에게 할당하지만 일부 고아 달력을 다른 소유자에게 할당하려 합니다.
해결책
csmig는 명령줄에서 매핑 파일을 사용할 수 없습니다. 그러나 이전을 실행하기 전에 원본 데이터베이스에서 고아 달력에 소유자를 할당할 수 있습니다. 모든 고아 달력에 대해 dry run 매핑 파일을 점검합니다. 그리고 이전을 실행하기 전에 cscal 유틸리티를 사용하여 고아 달력에 소유자를 할당합니다. dryrun 모드에서 csmig를 다시 실행하여 새 소유자를 확인합니다.
달력 사용자를 다른 백엔드 서버로 이동하려는 경우
어떻게 사용자를 한 백엔드 서버에서 다른 서버로 이동시킬 수 있습니까?
해결책
달력 사용자를 이동시키려면 원본 서버에서 사용자의 달력을 내보낸 후 두 번째 서버로 해당 달력을 가져옵니다. 달력을 이동한 다음 원본 서버의 달력을 삭제할 수 있습니다. 사용자 이동의 세부 단계는 Sun ONE Calendar Server 관리자 설명서를 참조하십시오.
csvdmig 유틸리티csvdmig 유틸리티는 호스트된 (가상) 도메인을 사용할 사이트의 Calendar Server 데이터베이스와 LDAP Directory Server 데이터베이스를 수정합니다. csvdmig 유틸리티는 다음과 같이 도메인 이름을 사용자 아이디에 추가합니다.
주의
csvdmig 유틸리티는 실제로 데이터를 다른 위치로 이전하지는 않습니다. 현재 위치에 있는 달력 데이터베이스와 LDAP Directory Server를 수정합니다.
따라서 csvdmig를 실행하기 전에 Calendar Server 데이터베이스와 LDAP Directory Server 데이터베이스를 백업하십시오.
csvdmig 구문
csvdmig 유틸리티는 다음 구문을 사용합니다.
-m MappingFile은 매핑 파일을 지정하는 입력 매개 변수입니다. 기본값은 MigrateMapping입니다.
매핑 파일은 기존 사용자와 그 사용자의 개별 도메인을 매핑하는 입력 텍스트 파일입니다. csvdmig를 실행하기 전에 먼저 매핑 파일을 만들어야 합니다. 기존 값과 새 값 사이에 공백을 사용하여 각 행마다 하나씩 항목을 지정합니다. 예를 들면 다음과 같습니다.
user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
...
user-n user-n@siroe.com-c ConfigFile은 Calendar Server 구성 파일을 지정하는 입력 매개 변수입니다. 기본값은 ics.conf 파일입니다.
-t DestinationDB는 이전된 데이터베이스의 위치를 지정하는 출력 매개 변수입니다. 기본값은 MigratedDB입니다.
-e ErrorFile은 해결할 수 없는 오류의 오류 파일 이름을 지정하는 출력 매개 변수입니다. 기본값은 MigrateError입니다.
DB | LDAP는 Calendar Server 데이터베이스(DB) 또는 LDAP Directory Server (LDAP)의 수정 여부를 지정합니다. 기본값은 달력 데이터베이스(DB)입니다.
csvdmig 예
ics2migrate 유틸리티ics2migrate 이전 유틸리티는 iPlanet Calendar Server 2.x 달력 데이터와 LDAP 사용자 기본 설정을 Calendar Server 6.0으로 이전합니다.
이 절은 다음 내용으로 구성되어 있습니다.
이전 요구 사항
Calendar Server 2.x에서 6.0으로 이전하려면 다음과 같은 하드웨어와 소프트웨어가 필요합니다.
소스 시스템과 대상 시스템은 다른 서버일 수도 있고 같은 서버일 수도 있습니다. 지원 플랫폼 목록은 Sun ONE Calendar Server 릴리스 노트를 참조하십시오.
이전 내용
다음 표는 Calendar Server 2.x 데이터를 나열하며 ics2migrate가 데이터를 Calendar Server 6.0에 이전하는 방법을 설명합니다.
다음 표는 Calendar Server 2.x LDAP 속성을 나열하고 ics2migrate가 Calendar Server 6.0으로 속성을 이전하는 방법을 설명합니다.
이전 프로세스
ics2migrate 단계는 다음과 같습니다.
2.x 달력 데이터베이스 업그레이드
Calendar Server 6.0을 사용하려면 Sleepycat Software의 Berkeley DB 버전 3.2.9가 있어야 합니다. ics2migrate를 실행하기 전에 Berkeley DB db_recover 및 db_upgrade 유틸리티를 사용하여 달력 데이터베이스를 버전 3.2.9로 업그레이드해야 합니다. Calendar Server 6.0의 다음 디렉토리에는 Berkeley DB 유틸리티가 포함되어 있습니다.
cal_svr_base/opt/SUNWics5/cal/tools/unsupported/bin
Berkeley DB 유틸리티에 대한 자세한 내용은 다음 웹 사이트를 참조하십시오.
http://www.sleepycat.com/docs/utility/index.html
데이터베이스를 버전 3.2.9로 업그레이드하는 방법
- Solaris 및 기타 UNIX 시스템에서 icsgroup 및 icsuser와 같이 Calendar Server를 실행 중인 사용자 및 그룹으로 로그인합니다.
- 필요한 경우 2.x Calendar Server를 중지합니다.
- 달력 2.x 데이터베이스를 백업하지 않은 경우 백업합니다.
- 다음 디렉토리에서 기존 공유(__db_name.share) 또는 로그(log.*) 파일을 제거(삭제)합니다.
cal_svr_base/opt/SUNWics5/cal/lib/http
cal_svr_base/var/opt/SUNWics5/csdb
- db_upgrade 유틸리티를 실행하여 2.x 달력 데이터베이스를 버전 3.2.9로 업그레이드합니다. 현재 디렉토리가 2.x 달력 데이터베이스가 있는 디렉토리가 아니면 -h 옵션을 사용하여 해당 데이터베이스 파일을 가리킵니다.
주 모든 2.x 데이터베이스 파일(alarms.db, calprops.db, events.db, todos.db)에서 db_upgrade를 실행해야 합니다. 서버를 달력 데이터베이스에 직접 연결하지 않더라도 Calendar Server 구성의 모든 프런트엔드 및 백엔드 서버에서 db_upgrade를 실행해야 합니다.
- 데이터베이스 파일이 있는 csdb 디렉토리에서 Calendar Server 2.x caldb.conf 파일을 찾은 다음 그 파일의 첫 번째 행을 다음과 같이 변경합니다.
이전 값: caldb.version "1.0.0 [BerkeleyDB]"
새 값: caldb.version= "1.0.0 [BerkeleyDB]"
주 이 파일이 csdb 디렉토리에 없을 경우 텍스트 편집기를 사용하여 파일을 만든 다음 첫 번째 행에 새 값을 설정합니다.
데이터 이전
다음 단계를 수행하여 ics2migrate를 실행합니다.
- ics2migrate가 있는 디렉토리로 변경합니다.
- ics2migrate 구문의 구문을 사용하여 ics2migrate를 실행합니다.
- 이전 후에 ics.conf 파일의 caldb.berkeleydb.homedir.path 매개 변수가 이전된 데이터베이스를 가리키는지 확인합니다.
- csdb check 명령을 실행하고, 필요하면 csdb rebuild 명령을 실행하여 달력 데이터베이스를 다시 만듭니다.
ics2migrate 구문
Calendar Server 2.x 데이터베이스와 LDAP 사용자 기본 설정 이전
Calendar Server 2.x 데이터베이스만 이전
LDAP 사용자 기본 설정만 이전
표 3-3은 ics2migrate 옵션과 각 옵션에 대한 설명을 나열합니다.
이전 결과 점검
이전을 마치면 그 결과를 점검합니다.
이전 예
달력 데이터베이스와 LDAP 사용자 정보를 모두 이전
LDAP 사용자 정보와 Calendar Server 2.x 데이터베이스를 이전합니다. Calendar Server 2.x 데이터베이스는 /var/opt/SUNWicsrv/2x_db 디렉토리에 저장되어 있고 6.0 데이터베이스는 /var/opt/SUNWics5/50_db 디렉토리에 저장되어 있습니다.
모든 달력에 대해 예약 및 사용 가능/사용 중 액세스 권한을 부여하고 ics2migrate.log라는 로그 파일에 최소 이전 통계를 기록합니다.
ics2migrate /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db -l min
Quiet 모드에서 이전
앞의 예와 동일한 이전을 quiet 모드에서 수행합니다. ics2migrate는 이전 통계를 콘솔에 표시하지 않으며 로그 파일도 생성하지 않습니다.
ics2migrate -q /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db
달력 데이터베이스만 이전
2x_db 디렉토리(현재 디렉토리에 대한 상대 경로)에 저장된 2.x 달력 데이터베이스만 이전하며 /var/opt/SUNWics5/50_db 디렉토리에 6.0 데이터베이스를 만듭니다.
ics2migrate -m db 2x_db /var/opt/SUNWics5/50_db
LDAP 사용자 정보만 이전
Calendar Server 2.x LDAP 사용자 정보만 6.0 버전 형식으로 이전합니다.
ics2migrate -m ldap
달력 데이터베이스와 LDAP 사용자 정보를 모두 이전
LDAP과 달력 데이터베이스 정보를 지정한 디렉토리로 이전합니다. 각 사용자의 기본 달력에 대해서만 예약 액세스 권한을 부여하고 서버의 모든 달력에 대해 사용 가능/사용 중 액세스 권한을 거부하며 로그 파일에 통계 정보를 생성하지 않습니다.
ics2migrate -s def -f none 2x_db 50_db
ncs4migrate 유틸리티이 절에서는 ncs4migrate 이전 유틸리티를 사용하여 Netscape Calendar Server 4.x 달력 데이터를 Sun ONE Calendar Server로 이전하는 방법에 대해 설명합니다.
Netscape Calendar Server 4.x 달력은 개발업체인 Corporate Software & Technologies Int. Inc.의 이름을 따서 CS&T 달력이라고도 합니다.
ncs4migrate 유틸리티 복사본이 필요하면 Sun 기술 지원 담당자나 영업 담당자에게 문의하십시오. ncs4migrate를 받으면 이를 cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리에 복사합니다.
이 절은 다음 내용으로 구성되어 있습니다.
이전 요구 사항
이전 작업에는 다음과 같은 하드웨어와 소프트웨어가 필요합니다.
소스 시스템과 대상 시스템은 다른 서버일 수도 있고 같은 서버일 수도 있습니다. 지원 플랫폼 목록은 Sun ONE Calendar Server 릴리스 노트를 참조하십시오.
이전 내용
다음 표에서는 ncs4migrate가 Netscape Calendar Server 4.0 데이터를 Calendar Server 6.0으로 이전하는 방법에 대해 설명합니다.
이전 단계
Calendar Server 5.0 데이터베이스 백업
이전하기 전에 달력 데이터베이스의 무결성을 보장하기 위해 다음 단계를 수행하는 것이 좋습니다.
- csbackup, Sun StorEdge Enterprise Backup™ 소프트웨어 또는 Legato Networker® 같은 유틸리티를 사용하여 달력 데이터베이스를 백업합니다.
자세한 내용은 Sun ONE Calendar Server 관리자 설명서를 참조하십시오.
- 달력 데이터베이스에서 csdb 유틸리티의 check 명령을 실행하여 데이터베이스가 손상되었는지 점검합니다. check 명령이 손상을 발견하면 csdb 유틸리티의 rebuild 명령을 실행하여 데이터베이스를 다시 만듭니다.
csdb 및 csbackup 유틸리티에 대한 설명서는 Sun ONE Calendar Server 관리자 설명서를 참조하십시오.
이전 준비
ncs4migrate 유틸리티를 실행하기 전에 대상 시스템에서 다음 단계를 수행합니다.
- 수퍼유저(root) 또는 시스템에 대해 관리자 권한이 있는 사용자로 로그인합니다.
- cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- ncs4dirpaths.dat라는 이름으로 텍스트 파일을 만들고 Netscape Calendar Server 4.0 데이터베이스의 전체 디렉토리 경로를 지정합니다. 예를 들면 다음과 같습니다.
/apps/ncs/calendar/unison/db/nodes/N0/perm
Netscape Calendar Server 4.0 데이터베이스를 포함하는 디렉토리를 찾으려면 unison.dbd 파일을 검색합니다.
필요하다면 ncs4migrate가 노드에 액세스하고 Netscape Calendar Server 4.0 데이터베이스가 있는 디렉토리를 읽을 수 있도록 필요한 요구 사항을 충족시킵니다.
여러 노드의 데이터에 대해 하나의 ncs4dirpaths.dat 파일을 생성하는 것에 대한 정보는 여러 노드에서 데이터 이전을 참조하십시오.
- 선택한 사용자를 이전하려면 cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리에 ncs4userfilter.dat라는 사용자 필터 파일을 만듭니다. ncs4userfilter.dat는 이전할 사용자를 지정하는 텍스트 파일입니다. 각 행은 다음 형식 중 하나로 사용자를 식별합니다.
- LDAP 서버가 실행 중인지 확인합니다.
- 이전 과정에서 달력 데이터베이스가 업데이트되지 않도록 하려면 달력 서버를 중지합니다. 그러나 Netscape Calendar Server는 계속 실행하거나 중지시킬 수 있습니다.
Netscape Calendar Server 4.0 데이터를 이전할 준비가 되었습니다.
데이터 이전
대상 시스템에서 다음 단계를 수행합니다.
- (필요한 경우) 수퍼유저(root) 또는 시스템에 대해 관리자 권한이 있는 사용자로 로그인하고 cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- 명령줄에 ncs4migrate를 입력합니다.
그러면 ncs4migrate 유틸리티는 표 3-5의 옵션과 함께 시작 메뉴를 표시합니다.
주: ncs4migrate가 (E)xport 및 (I)mport 옵션을 표시하더라도 이러한 옵션은 지원되지 않으므로 사용할 수 없습니다.
- ncs4migrate 메뉴에서 S 옵션을 지정하여 모든 사용자를 이전합니다. 또는 사용자 필터 파일(ncs4userfilter.dat)의 특정 사용자를 이전하는 중이라면 O 옵션을 지정합니다.
- 이전 로그 파일을 모니터하여 이전 상태를 점검합니다. 자세한 내용은 이전 로그 파일 점검을 참조하십시오.
- 이전이 끝나면 이전된 데이터 점검에서 설명한 대로 이전된 달력 데이터베이스를 점검합니다.
여러 노드에서 데이터 이전
여러 노드로부터 Netscape Calendar Server 4.0 데이터를 이전하려면 대상 시스템에서 다음 단계를 수행합니다.
- 수퍼유저(root) 또는 시스템에 대한 관리자 권한을 갖는 사용자로 시스템에 로그인한 후 각 노드에서 ncs4migrate를 실행할 시스템으로 Netscape Calendar Server 4.0 데이터베이스 디렉토리를 복사합니다(각 Netscape Calendar Server 4.0 디렉토리는 unison.dbd 파일을 포함해야 함).
Netscape Calendar Server 4.0 데이터를 각 노드로부터 직접 이전할 수도 있지만 먼저 ncs4migrate가 다른 노드의 Netscape Calendar Server 4.0 데이터를 액세스할 수 있도록 필요한 요구 사항을 해결해야 합니다.
- cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- ncs4dirpaths.dat 파일에서 모든 노드의 데이터에 대한 디렉토리 경로 이름을 지정합니다. 예를 들어, 다음 ncs4dirpaths.dat 파일은 세 노드에 대한 디렉토리 경로를 포함합니다.
/apps/ncs/calendar/unison/db/nodes/N0/perm
/apps/ncs/calendar/unison/db/nodes/N1/perm
/apps/ncs/calendar/unison/db/nodes/N2/perm- 이전 유틸리티를 실행하려면 명령줄에 ncs4migrate를 입력합니다.
- ncs4migrate 메뉴에서 S 옵션을 지정하여 모든 사용자를 이전합니다. 또는 사용자 필터 파일(ncs4userfilter.dat)의 특정 사용자를 이전하는 중이라면 O 옵션을 지정합니다.
- 이전 로그 파일을 모니터하여 이전 상태를 점검합니다. 자세한 내용은 이전 로그 파일 점검을 참조하십시오.
- 이전이 끝나면 이전된 데이터 점검에서 설명한 대로 이전된 달력 데이터베이스를 점검합니다.
이전 로그 파일 점검
ncs4migrate 유틸리티는 다음 이름의 로그 파일을 cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리에 생성합니다.
ncs4migrate_yyyymmdd-hhmmss.log
여기서 yyyymmdd-hhmmss는 이전이 시작된 시점을 나타내는 타임스탬프입니다.
ncs4migrate 유틸리티를 실행하는 데 너무 많은 시간이 걸리는 경우 유틸리티가 계속 실행 중임을 알리는 표시로 로그 파일의 크기가 증가하고 있는지 확인합니다.
이전된 데이터 점검
이전이 끝나면 대상 시스템에서 다음 단계를 수행합니다.
csrename 유틸리티csrename 유틸리티는 다음과 같이 달력 사용자 아이디를 바꿉니다.
csrename 유틸리티는 다음 디렉토리에 있습니다.
cal_svr_base/opt/SUNWics5/cal/sbin
csrename을 실행하기 전에 먼저 다음을 수행해야 합니다.
csrename을 실행하려면 icsuser (또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인해야 합니다. csrename을 수퍼유저(root)로 실행한 경우 새 데이터베이스 파일에 대한 권한을 재설정해야 할 수도 있습니다. LDAP Directory Server 속성을 수정하려면 해당 디렉토리에 대해 관리 권한이 있어야 합니다.
프런트엔드/백엔드 서버 구성인 경우에는 각 백엔드 서버에서 csrename을 실행해야 합니다.
csrename 구문
다음 구문을 사용하여 csrename을 실행합니다.
-t DestinationDB는 csrename에서 변환된 사용자 아이디로 새 데이터베이스를 생성하는 대상 디렉토리를 지정합니다. 기본값은 MigratedDB입니다.
csrename이 완료되면 ics.conf 파일의 caldb.berkeleydb.homedir.path 매개 변수는 해당 대상 데이터베이스를 가리켜야 합니다. caldb.berkeleydb.homedir.path가 해당 대상 데이터베이스 디렉토리를 가리키도록 재설정하거나 대상 데이터베이스 파일을 매개 변수에서 지정한 디렉토리로 이동합니다.
-c ConfigFile은 Calendar Server 구성 파일을 지정하는 입력 매개 변수입니다. 기본값은 ics.conf 파일입니다.
csrename은 구성 파일의 caldb.berkeleydb.homedir.path 매개 변수를 사용하여 입력 달력 데이터베이스의 위치를 결정합니다. 달력 데이터베이스의 기본 위치는 cal_svr_base/var/opt/SUNWics5/csdb입니다.
-e ErrorFile은 csrename이 해결할 수 없는 오류 또는 데이터베이스 항목을 기록하는 파일입니다. 기본값은 MigrateError입니다.
-m MappingFile은 입력 매핑 파일을 지정합니다. 기본값은 MigrateMapping입니다.
입력 매핑 파일은 기존 사용자 아이디와 새 사용자 아이디를 매핑시킨 텍스트 파일입니다.
csrename을 실행하기 전에 매핑 파일을 만들어야 합니다. 기존 값과 새 값 사이에 공백을 사용하여 각 행마다 하나씩 항목을 지정합니다. 예를 들면 다음과 같습니다.
tchang tc897675
jsmith js963123
...
bkamdar bk548769DB|LDAP는 다음과 같이 업데이트되는 데이터베이스를 지정합니다.
csrename 예
