4장 마이그레이션 유틸리티

Calendar Server를 설치 및 구성한 후에는 구성 요소 데이터베이스와 LDAP 데이터베이스를 마이그레이션해야 할 수도 있습니다. 낮은 수준의 데이터베이스를 현재 버전으로 높이기 위해 제공되는 마이그레이션 유틸리티가 몇 가지 있습니다. 이 장에서는 정확한 유틸리티를 선택하여 실행할 수 있도록 돕는 마이그레이션 유틸리티 로드맵을 제공합니다.

Calendar Server 마이그레이션 유틸리티 개요

Calendar Server 6 2004Q2에서는 두 가지 유형의 데이터베이스 마이그레이션 유틸리티를 제공합니다.

구성 요소 데이터베이스 마이그레이션 유틸리티

LDAP 데이터베이스 마이그레이션 및 업그레이드 유틸리티

구성 요소 데이터베이스 마이그레이션 유틸리티

구성 요소 데이터베이스에는 모든 달력 사용자와 자원에 해당하는 이벤트와 수행할 작업이 포함되어 있습니다. 다음 유틸리티는 구성 요소 데이터베이스를 마이그레이션합니다.

cs5migrate(기본 버전) - Calendar Server 5.x 데이터베이스를 Calendar Server 6으로 마이그레이션하며 달력 데이터베이스를 Berkeley DB 버전 2.6에서 버전 4.2로 업그레이드합니다.

cs5migrate_recurring(Outlook 호환 버전) - Sun Java System Connector for Microsoft Outlook을 설치하는 경우 Outlook에서 오래된 반복 이벤트를 볼 수 있도록 Calendar Server 6.0에서 업데이트하는 경우라도 이 버전을 실행합니다.

ics2migrate - iPlanet Calendar Server 2.x에서 5.x로 데이터를 마이그레이션합니다. 이 유틸리티는 Calendar Server 5.1.1과 함께 번들로 제공됩니다.

ncs4migrate - Netscape Calendar Server 4.x에서 5.x로 데이터를 마이그레이션합니다. 이 유틸리티는 마이그레이션 웹 사이트에서 구할 수 있습니다. 마이그레이션 웹 사이트를 참조하십시오.

LDAP 데이터베이스 마이그레이션 및 업그레이드 유틸리티

LDAP 데이터베이스에는 인증(사용자 및 자원 항목) 및 달력 기본 설정 정보가 포함되어 있습니다. 다음 유틸리티는 LDAP 데이터를 업그레이드 또는 마이그레이션합니다.

csmig - Calendar Server 6.x 데이터베이스의 각 달력에 소유자를 할당하고 필요한 경우 각 달력 아이디(calid)를 소유자에게 매핑합니다. 이렇게 하면 호스트된(가상) 도메인과 LDAP 달력 조회 데이터베이스(CLD) 플러그 인 지원이 허용됩니다. 이 유틸리티는 Calendar Server와 같은 패키지로 제공됩니다. 이 유틸리티는 cs5migrate를 실행한 후 csvdmig보다 먼저 실행합니다.

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

commdirmig 유틸리티 - Identity Server 6.1 이상에서의 사용에 대비하여 LDAP 데이터를 스키마 1에서 스키마 2로 마이그레이션합니다. 이 마이그레이션 유틸리티는 별도의 설명서에 자세히 설명되어 있습니다. 다음 위치의 Sun Java System Communications Services Schema Migration Guide를 참조하십시오.

http://docs.sun.com/coll/CalendarServer_04q2 및 http://docs.sun.com/coll/CalendarServer_04q2_ko

이전에 Messaging Server 5.x 또는 Calendar Server 5.x를 사용한 경우에는 LDAP 항목이 Sun LDAP Schema 1용으로 포맷됩니다. 새 Calendar Server 6 2004Q2 환경에서 인증에 Identity Server를 사용하려면 이 유틸리티를 사용하여 LDAP 항목을 스키마 2로 변환해야 합니다.

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

Sun Java Enterprise System 2004Q2의 경우 이 유틸리티는 규정 유틸리티 commadmin과 함께 Identity Server 6.2(2004Q2)에 번들로 제공됩니다.

Identity Server를 업데이트하지 않고 Calendar Server 6.0(2003Q4)에 대한 마이그레이션 유틸리티만 필요한 경우에는 기술 지원에 문의하여 해당 유틸리티의 패치만 구할 수 있습니다.

마이그레이션 유틸리티 로드맵

선택할 수 있는 유틸리티가 많으므로 그림 4-1에 유틸리티 사용 순서를 결정하는 데 도움이 되는 로드맵이 표시되어 있습니다.

그림 4-1 Calendar Server 마이그레이션 유틸리티 실행을 위한 로드맵


주	ics2migrate는 Sun ONE Calendar Server 5.1.1 다운로드와 함께 번들로 제공됩니다. 그리고 csmig와 csvdmig는 Sun Java System Calendar Server 6 2004Q2와 함께 번들로 제공됩니다. Netscape Calendar Server 3.5가 있는 경우에는 ncs4migrate를 사용하기 전에 Netscape Calendar Server 4.x로 마이그레이션해야 합니다. 이 마이그레이션 유틸리티는 Sun 기술 지원에서 구할 수 있습니다.

Calendar Server 6.x를 설치하고 cs5migrate를 실행한 후에는 다른 마이그레이션 유틸리티 중에 실행해야 하는 유틸리티를 결정합니다. 그림 4-2는 다른 구성 시나리오와 각각의 경우에 실행해야 하는 마이그레이션 유틸리티를 보여 줍니다.

마이그레이션 웹 사이트

특정 사이트의 적절한 선택을 돕기 위해 추가 정보와 유틸리티 다운로드를 기술 지원에서 알려 주는 웹 사이트에서 구할 수 있습니다.

웹 사이트에서는 사용할 유틸리티의 결정과 마이그레이션 프로세스로 인해 예상되는 중단 시간을 계산하는 데 도움이 되는 짧은 설문에 대답해야 합니다.

경우에 따라 Sun Microsystems 기술 지원 또는 전문가 서비스에 문의하여 도움을 요청해야 할 수도 있습니다.


주의	사이트가 Calendar Server의 제한된 가상 도메인 모드 또는 여러 인스턴스로 구성된 경우에는 Sun Microsystems Inc. 영업 담당자에게 문의하여 마이그레이션 요구 사항을 평가하고 해당 요구 사항을 지원하는 마이그레이션 유틸리티를 사용하고 있는지 확인해야 합니다.


주	cs5migrate는 Calendar Server 제품과 번들로 제공되는 것처럼 보이지만 이 유틸리티를 실행하려고 하면 다음과 같은 메시지가 나타납니다. !!!!!!!!!!PLEASE NOTE!!!!!!!!!! To migrate to Calendar Server 6.0, please contact your Sun Microsystems Technical Support or Sales Account Representative to get the latest version of the utility.

ics2migrate

ics2migrate 유틸리티는 iPlanet Calendar Server 2.x 달력 데이터와 LDAP 사용자 기본 설정을 Sun ONE Calendar Server 5.x로 마이그레이션합니다.

마이그레이션 요구 사항

Calendar Server 2.x에서 6.x로 마이그레이션하려면 다음과 같은 하드웨어와 소프트웨어가 필요합니다.

소스 시스템 - 마이그레이션할 Calendar Server 2.x 데이터를 가지고 있습니다.

대상 시스템 - 마이그레이션된 데이터가 만들어지는 위치로, Calendar Server 6.0 이상이 설치되어 있어야 합니다.

ics2migrate 유틸리티 - 마이그레이션하기 전에 먼저 기술 지원 담당자나 영업 담당자에게 문의하여 최신 버전의 유틸리티를 사용하고 있는지 확인해야 합니다.

소스 시스템과 대상 시스템은 다른 서버일 수도 있고 같은 서버일 수도 있습니다. 지원 플랫폼 목록은 Sun Java System Calendar Server 릴리스 노트를 참조하십시오.

마이그레이션 내용

다음 표에서는 Calendar Server 2.x 데이터를 나열하며 ics2migrate가 데이터를 Calendar Server 6.x에 마이그레이션하는 방법을 설명합니다.

표 4-1 Calendar Server 2.x 데이터 마이그레이션
Calendar Server 2.x 데이터	Calendar Server 6.0 마이그레이션 결과
달력 등록 정보(calprops)	Calendar Server의 calprops 데이터베이스를 업데이트합니다.
이벤트	Calendar Server의 events 데이터베이스를 업데이트합니다.
수행할 작업	Calendar Server의 todos 데이터베이스를 업데이트합니다.
경보	이벤트 및 수행할 작업을 기록하는 중에 alarms 데이터베이스를 업데이트합니다.

다음 표에서는 Calendar Server 2.x LDAP 속성을 나열하고 ics2migrate가 Calendar Server 6.x로 속성을 마이그레이션하는 방법을 설명합니다.

표 4-2 LDAP 속성 마이그레이션
Calendar Server 2.x LDAP 속성	Calendar Server 6.0 LDAP 속성
nswcalUser *	icsCalendarUser *
nswcalCalID	icsCalendar
nswcalExtendedUserPrefs	icsExtendedUserPrefs
ceCalList **	icsSubscribed
ceAgendaList **	icsSet
ceDefaultAgenda **	icsDefaultSet
ceDefaultTZID **	icsTimeZone
ceFirstDayWeek **	icsFirstDay
* 객체 클래스 ** 원래 nswcalExtendedUserPrefs의 일부

마이그레이션 프로세스

2.x Berlely Database에서 db_recover 실행

Calendar Server 5.1.1 다운로드 및 설치

2.x 달력 데이터베이스 업그레이드

데이터 마이그레이션(ics2migrate 실행)

마이그레이션 결과 확인

2.x Berlely Database에서 db_recover 실행


주의	ics2migrate를 실행하기 전에 csbackup, Sun StorEdge Enterprise Backup™ 소프트웨어 또는 Legato Networker® 등의 유틸리티를 사용하여 달력 데이터베이스를 백업합니다. db_upgrade는 현재 디렉토리에 있는 데이터베이스를 업그레이드하므로 달력 데이터베이스를 백업하는 것이 매우 중요합니다. 업그레이드 중에 문제가 발생하면 데이터베이스는 복구할 수 없는 상태가 될 수 있습니다.

Berkeley DB db_recover 유틸리티를 실행하여 로그 파일 트랜잭션을 변환하기 전에 데이터베이스에 병합합니다. 이 유틸리티를 사용하지 않으면 병합되지 않은 트랜잭션이 손실됩니다.

Calendar Server 5.1.1 다운로드 및 설치

다음 위치에 있는 iPlanet Calendar Server 5.1 Installation Guide를 참조하십시오.

2.x 달력 데이터베이스 업그레이드

Calendar Server 5.1.1을 사용하려면 Sleepycat Software의 Berkeley DB 버전 3.2.9가 있어야 합니다. ics2migrate를 실행하기 전에 Berkeley DB db_upgrade 유틸리티를 사용하여 달력 데이터베이스를 버전 3.2.9로 업그레이드해야 합니다. Calendar Server 5.x의 다음 디렉토리에는 Berkeley DB 유틸리티가 포함되어 있습니다.

Berkeley DB 유틸리티에 대한 자세한 내용은 다음 웹 사이트를 참조하십시오.

데이터베이스를 버전 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 사용자 기본 설정만 마이그레이션하는 경우


주	구문을 표시하려면 ics2migrate를 아무 옵션 없이 입력합니다.

표 4-3은 ics2migrate 옵션과 각 옵션에 대한 설명을 나열합니다.

표 4-3 ics2migrate 옵션
ics2migrate 옵션	설명
[-q]	quiet 모드에서 실행합니다. 마이그레이션이 성공하면 ics2migrate는 정보를 콘솔에 표시하지 않습니다. 마이그레이션에 실패하면 ics2migrate는 오류만 표시합니다. 기본값은 verbose 모드입니다.
[-m db\|ldap]	db - 달력 데이터베이스만 마이그레이션합니다. ldap - LDAP 사용자 기본 설정만 마이그레이션합니다. 기본값은 달력 데이터베이스와 LDAP 사용자 기본 설정을 모두 마이그레이션하는 것입니다.
[-s def\|none]	def - 사용자의 기본 달력에 대해서만 예약 액세스 권한을 부여합니다. none - 모든 사용자의 달력에 대해 예약 액세스 권한을 거부합니다. 기본값은 모든 달력에 대해 예약 액세스 권한을 부여하는 것입니다.
[-f def\|none]	def - 사용자의 기본 달력에 대해서만 사용 가능/사용 중 액세스 권한을 부여합니다. none - 모든 사용자의 달력에 대해 사용 가능/사용 중 액세스 권한을 거부합니다. 기본값은 모든 달력에 대해 사용 가능/사용 중 액세스 권한을 부여하는 것입니다.
[-l min\|max]	min - 최소 데이터 마이그레이션 통계 즉, 달력 아이디, 주 소유자 및 각 달력의 이벤트와 수행할 작업 수를 기록합니다. max - 최대 데이터 마이그레이션 통계 즉, 최소 통계에 참석자 수, 각 이벤트 및 수행할 작업에 대한 경보 수를 더하여 기록합니다. ics2migrate는 cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리의 ics2migrate.log에 통계를 기록합니다. 기본적으로 ics2migrate는 마이그레이션 통계를 콘솔에 표시하며 로그 파일을 생성하지 않습니다.
source	Calendar Server 2.x 데이터베이스 파일이 있는 디렉토리입니다. 데이터베이스를 마이그레이션하려면 -m db 옵션의 지정 또는 -m 옵션의 제외 여부에 관계 없이 source를 반드시 지정해야 합니다.
target	Calendar Server 6.0 데이터베이스 파일이 있는 디렉토리입니다. 데이터베이스를 마이그레이션하려면 -m db 옵션의 지정 지정 또는 -m 옵션의 제외 여부에 관계 없이 target을 반드시 지정해야 합니다.

마이그레이션 결과 확인

ics2migrate.log 파일에서 다음 메시지(마이그레이션 선택 사항에 따라 다름)를 확인합니다.

Database migration successfully completed.
LDAP user preference migration successfully completed.

데이터베이스가 손상되었을 가능성이 있으면 csdb 유틸리티의 check 명령을 실행합니다.

마이그레이션 예

Quiet 모드에서 마이그레이션

달력 데이터베이스만 마이그레이션

LDAP 사용자 정보만 마이그레이션

달력 데이터베이스와 LDAP 사용자 정보를 모두 마이그레이션

Quiet 모드에서 마이그레이션

앞의 예와 동일한 마이그레이션을 quiet 모드에서 수행합니다. ics2migrate는 마이그레이션 통계를 콘솔에 표시하지 않으며 로그 파일도 생성하지 않습니다.

달력 데이터베이스만 마이그레이션

2x_db 디렉토리(현재 디렉토리에 대한 상대 경로)에 저장된 2.x 달력 데이터베이스만 마이그레이션하며 /var/opt/SUNWics5/50_db 디렉토리에 6.0 데이터베이스를 만듭니다.

LDAP 사용자 정보만 마이그레이션

Calendar Server 2.x LDAP 사용자 정보만 6.0 버전 형식으로 마이그레이션합니다.

달력 데이터베이스와 LDAP 사용자 정보를 모두 마이그레이션

LDAP 사용자 정보와 Calendar Server 2.x 데이터베이스를 모두 마이그레이션합니다. Calendar Server 2.x 데이터베이스는 /var/opt/SUNWicsrv/2x_db 디렉토리에 저장되어 있고 6.0 데이터베이스는 /var/opt/SUNWics5/50_db 디렉토리에 저장되어 있습니다.

모든 달력에 대해 예약 및 사용 가능/사용 중 액세스 권한을 부여하고 ics2migrate.log라는 로그 파일에 최소 마이그레이션 통계를 기록합니다.

csmig

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

csmig 유틸리티가 호스트된(가상) 도메인 및 LDAP 달력 조회 데이터베이스(CLD) 플러그 인을 지원하면 이 플러그 인을 사용하여 마이그레이션된 데이터베이스의 달력에 액세스할 수 있습니다. LDAP CLD 플러그 인은 달력을 여러 백엔드 서버에 분산할 수 있게 함으로써 달력 데이터베이스의 수평 확장성을 제공합니다. LDAP CLD 플러그 인에 대한 자세한 내용은 Sun Java System Calendar Server 6 2004Q2 관리 설명서를 참조하십시오.

csmig 기능

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

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

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

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

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

자원 달력 이름에 콜론이 포함되어 있으면 콜론이 밑줄로 변환됩니다.

csmig 요구 사항

달력 데이터베이스가 손상되지 않아야 합니다. csdb check 명령을 사용하여 달력 데이터베이스를 점검하고 필요한 경우 csdb rebuild 명령을 실행하여 데이터베이스를 다시 만듭니다. 이 명령에 대한 자세한 내용은 Sun Java System Calendar Server 관리 설명서를 참조하십시오.

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

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

Calendar Server를 중지해야 합니다.

csmig 구문

-t DestinationDB는 csmig에서 생성하는 대상 데이터베이스를 지정합니다. 기본값은 MigratedDB입니다.

-b Backend-DWPHost는 DWP 백엔드 호스트 서버의 이름을 지정합니다. 이 이름은 ics.conf 파일에서 지정한 DWP 백엔드 호스트 서버 이름과 일치해야 합니다.

-o OutputFile은 발생한 오류뿐 아니라 csmig 화면 출력을 캡처하는 출력 파일을 지정합니다. 기본값은 MigrateOut입니다.

-e ErrorFile은 csmig에서 해결할 수 없는 오류 또는 데이터베이스 항목을 기록하는 파일입니다. 데이터베이스 항목을 해결할 수 없는 경우에는 대상 데이터베이스에 기록하지 않습니다. 기본값은 MigrateError입니다.

-m MappingFile은 dryrun 모드에서 생성되며 변경이 필요한 LDAP 스키마의 항목을 나열하는 출력 매핑 파일입니다. 예를 들면 다음과 같습니다.

매핑 파일은 LDAP 스키마에서 수행할 변경 사항 목록만 제공합니다. csmig는 실제로 스키마를 변경하지는 않습니다.

-c calendarOwner는 소유자가 없는 사용자 달력에 소유자를 지정합니다.

-r resourceOwner는 소유자가 없는 자원 달력에 소유자를 지정합니다.

csmig 마이그레이션 단계

구성에 포함된 모든 서버에 Calendar Server 6.0을 설치하고 나면 csmig를 실행하여 기존 Calendar Server 및 LDAP 데이터를 새로운 Calendar Server 6.0 및 LDAP 데이터로 마이그레이션해야 LDAP CLD 플러그 인이 제대로 작동할 수 있습니다. 이 단계에 따라 csmig를 사용하여 달력을 마이그레이션합니다.

LDAP 디렉토리 서버 구성 - 색인을 추가하면 마이그레이션 성능 및 LDAP 데이터의 달력 검색 성능을 크게 향상시킬 수 있습니다.

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

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

LDAP 디렉토리 서버 구성

성능을 향상하려면 다음 두 가지 새로운 색인을 slapd.ldbm.conf 파일에 추가해 볼 수 있습니다.

index icscalendar pres,eq,sub - 마이그레이션 프로세스에서 icsCalendar 속성을 검색하는 데 사용합니다.

index icscalendarowned pres,eq,sub - 마이그레이션 프로세스에는 필요하지 않지만 LDAP CLD 플러그 인이 활성화된 경우 LDAP 데이터에 대해 달력 검색을 수행하는 데(가입 작업을 위해) 사용합니다.

slapd.ldbm.conf 파일에서의 색인 생성에 대한 자세한 내용은 해당 디렉토리 서버 설명서를 참조하십시오.

테스트 건실행 수행

스테이징 서버에서 수행한 테스트 건실행은 마이그레이션될 내용을 보고하기만 하고 작업 데이터베이스를 실제로 마이그레이션하지는 않습니다. 건실행을 사용하여 작업 데이터베이스의 마이그레이션 계획을 세울 수 있습니다. 예를 들어, 소유자가 없는 "고아" 달력을 처리하는 방법을 결정할 수 있습니다.

csmig를 사용하여 테스트 건실행을 수행하려면 다음 단계를 수행합니다.

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

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

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

작업 LDAP 환경과 비슷하게 LDAP 서버를 설치합니다. 해당 서버에 slapd.ldbm.conf 파일의 새로운 색인과 함께 LDAP 데이터베이스 스냅샷을 설치합니다.

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 문제 또는 오류를 해결합니다. 실제로 마이그레이션하기 전에 미해결 달력을 처리하는 방법을 결정합니다. 다음과 같은 방법을 사용할 수 있습니다.

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

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

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

실제 작업 달력 데이터베이스를 마이그레이션하기 전에 스테이징 서버에서 달력 데이터베이스를 마이그레이션합니다. 이 단계를 통해 작업 데이터베이스를 마이그레이션하기 전에 데이터 마이그레이션 방법을 정확하게 파악하고 문제를 수정할 수 있습니다.

예를 들어, 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 디렉토리로 복사합니다. 또는 마이그레이션된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다. 그런 후 다음과 같은 확인 작업을 수행합니다.

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

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

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

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

작업 데이터 마이그레이션

csmig를 사용하여 작업 데이터베이스를 마이그레이션하려면 다음 단계를 수행합니다.

cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리로 변경합니다.

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

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

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

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

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

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

오류 파일에서 미해결 달력이 있는지 확인하고 테스트 건실행 수행의 단계 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입니다.

이 디렉토리가 올바른지 확인합니다. 또는 CDL 캐시 위치를 다르게 설정하려면 이 매개 변수를 수정합니다.

LDAP CLD 플러그 인의 구성 매개 변수 설정에 대한 자세한 내용은 Sun Java System Calendar Server 6 2004Q2 관리 설명서를 참조하십시오.

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

Calendar Server에 로그인하고 마이그레이션된 여러 달력을 점검하여 구성이 제대로 작동하는지 확인합니다. 점검 중 경보를 비활성화하려면 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*)) 필터를 사용하는 ldapsearch

(icscalendarowned=*substr*) 필터를 사용하는 ldapsearch

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

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

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

5개의 이벤트가 있는 basketball

10개의 이벤트가 있는 jsmith:basketball

건실행에 따르면 마이그레이션 과정에서 두 달력이 병합되며 그 결과 달력은 다음과 같습니다.

jsmith가 소유자이며 총 15개의 이벤트가 있는 jsmith:basketball

해결책

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

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

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

해결책

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

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

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

해결책

달력 사용자를 이동시키려면 원본 서버에서 사용자의 달력을 각각 내보낸 후 두 번째 서버로 해당 달력을 가져옵니다. 달력을 이동하고 나면 원본 서버의 달력을 삭제할 수 있습니다. 사용자 이동의 세부 단계는 Sun Java System Calendar Server 6 2004Q2 관리 설명서를 참조하십시오.

csvdmig

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

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

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

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

csvdmig 구문


주의	csvdmig 유틸리티는 실제로 데이터를 다른 위치로 마이그레이션하지는 않습니다. 현재 위치에 있는 달력 데이터베이스와 LDAP 디렉토리 서버를 수정합니다. 따라서 csvdmig를 실행하기 전에 Calendar Server 데이터베이스와 LDAP 디렉토리 서버 데이터베이스를 백업하십시오.

-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 디렉토리 서버(LDAP)의 수정 여부를 지정합니다. 기본값은 달력 데이터베이스(DB)입니다.

이전 목차 색인 다음
Sun Java System Calendar Server 관리 설명서