|
| |
| Sun Java System Calendar Server 6 2005Q1 관리 설명서 | |
4장
데이터베이스 마이그레이션 유틸리티Calendar Server 6 2005Q1을 설치하고 설치 후 구성을 수행한 후에도 이전 버전의 Calendar Server(5.11 및 이전 버전)가 있다면 구성 요소 데이터베이스와 LDAP 데이터베이스를 마이그레이션해야 합니다.
이 장의 올바른 유틸리티 선택 절은 정확한 유틸리티를 선택하여 실행하는 데 도움이 됩니다.
이 장은 다음 내용으로 구성되어 있습니다.
사후 설치 데이터베이스 마이그레이션 유틸리티Calendar Server 6 2005Q1을 설치한 후에도 이전에 설치된 Calendar Server 5.1.1 달력 데이터베이스와 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 – Access Manager 6.1 이상에서의 사용에 대비하여 LDAP 데이터를 Schema 1에서 Schema 2로 마이그레이션합니다. 이 유틸리티는 Access Manager와 함께 제공됩니다.
올바른 유틸리티 선택선택할 수 있는 유틸리티가 많으므로 그림 4-1에서는 어떤 유틸리티를 어떤 순서로 실행할 것인지 보여주고 다양한 구성 시나리오를 소개합니다.
그림 4-1 실행할 마이그레이션 유틸리티 선택
csmigcsmig 유틸리티는 달력 데이터베이스의 각 달력에 소유자를 할당하며 필요한 경우 각 달력 아이디(calid)를 소유자에 매핑합니다.
csmig 유틸리티는 호스트된(가상) 도메인 및 LDAP 달력 조회 데이터베이스(CLD) 플러그 인을 지원합니다. LDAP CLD 플러그 인을 사용하여 마이그레이션된 데이터베이스의 달력에 액세스할 수 있습니다. LDAP CLD 플러그 인에 대한 자세한 내용은 6장, "여러 시스템에서 달력 데이터베이스 배포 구성"을 참조하십시오.
이 절에서는 다음 항목에 대해 설명합니다.
csmig 기능
csmig 마이그레이션 유틸리티는 다음 기능을 수행합니다.
- csmig는 icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet 및 uid를 포함하여 LDAP 항목과 관련된 모든 LDAP 속성을 업데이트합니다. csmig는 LDAP Directory Server 데이터베이스의 각 달력에 대해 icsDWPHost 속성을 만듭니다. icsDWPHost는 달력이 상주하는 백엔드 서버의 호스트 이름을 지정합니다.
- csmig는 달력 데이터베이스의 각 달력에 소유자를 할당하며 필요한 경우 각 달력 아이디(calid)를 소유자에 매핑합니다. 모든 기본 calid는 그대로 유지되며 아무 것도 변경되지 않습니다. 다른 달력은 다음과 같이 매핑됩니다.
csmig 요구 사항
csmig를 사용하려면 다음 요구 사항을 충족시켜야 합니다.
- 달력 데이터베이스가 손상되지 않아야 합니다. csdb check 명령을 사용하여 달력 데이터베이스를 점검하고 필요한 경우 csdb rebuild 명령을 실행하여 데이터베이스를 재구축합니다. 이 명령에 대한 자세한 내용은 부록 D, "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 }
표 4-1에서는 유틸리티 옵션을 나열하고 각각의 설명과 기본값을 제공합니다.
csmig 마이그레이션 단계
Calendar Server 6.x를 설치하고 구성한 후, csmig를 실행하여 기존 Calendar Server 및 LDAP 데이터를 마이그레이션해야 합니다. LDAP CLD 플러그 인이 제대로 작동하려면 LDAP 데이터의 마이그레이션이 필요합니다. 이 단계에 따라 csmig를 사용하여 달력을 마이그레이션합니다.
- comm_dssetup.pl을 사용하여 Directory Server를 구성합니다.
comm_dssetup.pl을 사용하여 LDAP 속성을 색인화하지 않았다면 지금 수행하십시오. 그러면 LDAP 데이터 마이그레이션의 성능이 크게 향상됩니다.
- (작업 서버가 아닌)스테이징 서버를 사용하여 테스트 건실행을 수행합니다.
건실행은 실제 마이그레이션 과정에서 csmig가 수행할 작업을 보고하며 데이터를 마이그레이션하지는 않습니다. 건실행을 수행한 후 실제로 마이그레이션하기 전에 오류를 수정하고 미해결 달력을 처리할 계획을 세울 수 있습니다.
건실행 수행 방법에 대한 지침은 테스트 건실행을 수행하려면을 참조하십시오.
- 작업 데이터를 마이그레이션합니다.
작업 실행 중 csmig는 달력 데이터베이스(.db 파일) 및 LDAP 데이터(사용자 및 그룹 기본 설정 데이터), icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet 및 uid(자원 달력)를 마이그레이션합니다. 마이그레이션이 끝나면 모든 달력 자원에 대해 LDAP 항목이 만들어집니다.
작업 데이터 이전 방법에 대한 지침은 작업 데이터를 마이그레이션하려면을 참조하십시오.
테스트 건실행을 수행하려면
- Calendar Server 6.x를 스테이징 서버에 설치합니다(필요한 경우).
- 달력 데이터베이스의 스냅샷을 스테이징 서버에 복사합니다.
- 다음과 같이 수행하여 스테이징 서버를 작업 LDAP 환경을 비슷하게 만듭니다.
- comm_dssetup.pl을 실행하여 스테이징 Directory Server를 구성합니다.
- csconfigurator.sh를 실행하여 스테이징 Calendar Server를 구성합니다.
- icsuser로 로그인합니다(또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디로 로그인). csmig를 수퍼유저(root)로 실행하는 경우에는 마이그레이션된 파일에 대한 권한을 재설정해야 할 수도 있습니다.
- cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- csdb check 명령을 사용하여 데이터베이스가 손상되었는지 점검합니다. 손상이 발견된 경우에는 csdb rebuild를 실행하여 데이터베이스를 재구축합니다.
- 소유자가 없는 달력에 대해 포괄적인 calid를 만들 수도 있습니다. 예를 들어, 다음 명령은 calid가 orphan인 사용자를 만듭니다.
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan
- stop-cal 명령을 사용하여 Calendar Server를 중지합니다(필요한 경우).
cal_svr_base/SUNWics5/cal/sbin/stop-cal
- dryrun 옵션을 사용하여 csmig를 실행합니다. 예를 들어, 다음과 같이 입력할 수 있습니다.
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
이 명령은 소유자가 없는 사용자 달력(고아 달력)을 소유자 orphan에 할당하고 소유자가 없는 자원 달력을 소유자 calmaster에게 할당합니다.
- 출력 매핑 파일(csmig.map)을 확인합니다. 매핑 파일에서는 LDAP 스키마에서 업데이트해야 하는 항목을 나열합니다.
- 출력, 매핑 및 오류 파일을 확인합니다. 발견한 LDAP 문제 또는 오류를 해결합니다. 실제로 마이그레이션하기 전에 미해결 달력을 처리하는 방법을 결정합니다. 다음과 같은 방법을 사용할 수 있습니다.
- 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
- 테스트 마이그레이션이 끝나면 이 단계를 수행하여 새롭게 마이그레이션된 달력 데이터베이스를 확인합니다.
- 새로 마이그레이션된 데이터베이스를 caldb.berkeleydb.homedir.path 매개 변수에서 지정한 /csdb 디렉토리로 복사합니다. 또는 마이그레이션된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다.
- 새 달력 데이터베이스에서 csdb check를 실행합니다. 마이그레이션된 데이터베이스의 이벤트 및 수행할 작업 수가 마이그레이션 전의 합계와 일치해야 합니다.
- icsCalendarOwned 항목을 검색하고 이 항목이 마이그레이션 전의 달력 수와 일치하는지 확인합니다.
- Calendar Express 또는 Communications Express에 로그인하여 마이그레이션된 데이터베이스에서 일부 달력을 확인합니다.
테스트 마이그레이션이 성공하면 작업 데이터베이스를 마이그레이션할 준비가 된 것입니다.
작업 데이터를 마이그레이션하려면
- icsuser(또는 구성 중에 지정된 Calendar Server 런타임 사용자 아이디)로 로그인합니다. csmig를 수퍼유저(root)로 실행하는 경우에는 마이그레이션된 파일에 대한 권한을 재설정해야 할 수도 있습니다.
- cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다.
- stop-cal 명령을 사용하여 Calendar Server를 중지합니다(필요한 경우).
cal_svr_base/SUNWics5/cal/sbin/stop-cal
- 다음 데이터를 백업합니다.
- 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
- 오류 파일(csmig.errors)에서 미해결 달력이 있는지 확인하고 테스트 건실행을 수행하려면의 단계 13에서 세운 계획에 따라 결정합니다.
- csdb check 명령을 실행하여 마이그레이션된 데이터베이스를 확인합니다. 손상이 발견된 경우에는 csdb rebuild를 실행하여 데이터베이스를 재구축합니다.
- 새로 마이그레이션된 데이터베이스를 caldb.berkeleydb.homedir.path 매개 변수에서 지정한 /csdb 디렉토리로 복사합니다. 또는 마이그레이션된 데이터베이스의 새 위치를 가리키도록 이 매개 변수를 편집합니다.
- 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장, "여러 시스템에서 달력 데이터베이스 배포 구성"을 참조하십시오.
- start-cal 명령을 사용하여 Calendar Server를 다시 시작합니다.
- 달력 사용자 인터페이스(Calendar Express 또는 Communications Express)로 로그인하여 마이그레이션된 여러 달력을 확인하여 구성이 작동하는지 확인합니다.
점검 중 경보를 비활성화하려면 ics.conf 파일의 다음 매개 변수를 “no”로 설정합니다.
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 데이터에서 서로 다른 두 가지 검색을 수동으로 실행하고 출력 내용을 비교합니다.
서버에서 icsCalendarUser 객체 클래스가 포함된 필터를 사용하기 때문에 스키마 점검이 비활성인 상태로 LDAP 서버가 배포되었을 가능성이 있고 icsCalendarUser 객체 클래스 없이 일부 달력 항목이 관리되었을 수 있습니다.
csmig 건실행이 중복된 달력 이름을 보여주는 경우
문제의 예
csmig 건실행 매핑 파일과 출력 파일에 따르면 중복된 달력 이름이 있습니다. 예를 들어, 원본 데이터베이스에서 jsmith가 다음 달력을 소유합니다.
건실행에 따르면 마이그레이션 과정에서 두 달력이 병합되며 그 결과 달력은 소유자가 jsmith이고 총 15개의 이벤트가 있는 jsmith:basketball이 됩니다.
출력 파일은 다음 경고 메시지를 포함합니다.
Error modifying calendar properties, error=2
해결책의 예
두 달력이 병합되지 않게 하려면 마이그레이션을 실행하기 전에 basketball의 소유자를 jsmith가 아닌 다른 사용자로 변경합니다. 그러면 서로 다른 두 달력의 데이터 무결성이 보존됩니다.
고아 달력을 다른 소유자에게 할당하려는 경우
문제
기본적으로 csmig는 모든 고아 달력을 한 소유자에게 할당하지만 일부 고아 달력을 다른 소유자에게 할당하려 합니다.
해결책
csmig는 명령줄에서 매핑 파일을 사용할 수 없습니다. 그러나 마이그레이션을 실행하기 전에 원본 데이터베이스에서 고아 달력에 소유자를 할당할 수 있습니다. 모든 고아 달력에 대해 건실행 매핑 파일을 점검합니다. 그리고 마이그레이션을 실행하기 전에 cscal 유틸리티를 사용하여 고아 달력에 소유자를 할당합니다. dryrun 모드에서 csmig를 다시 실행하여 새 소유자를 확인합니다.
달력 사용자를 다른 백엔드 서버로 이동하려는 경우
문제
사용자를 한 백엔드 서버에서 다른 서버로 이동시키는 방법은 무엇입니까?
해결책
달력 사용자를 이동하려면 원본 서버의 사용자 달력 각각을 export한 다음 두 번째 서버로 import합니다. 달력을 이동하고 나면 원본 서버의 달력을 삭제할 수 있습니다. 달력을 이동하는 방법에 대한 지침은 다른 백엔드 서버로 달력을 이동하려면 또는 다른 백엔드 서버로 달력을 이동하려면을 참조하십시오.
csvdmigcsvdmig 유틸리티는 호스트된(가상) 도메인을 사용할 사이트의 Calendar Server 데이터베이스와 LDAP Directory Server 데이터베이스를 수정합니다.
이 절은 다음 내용으로 구성되어 있습니다.
csvdmig 기능
csvdmig 유틸리티는 다음과 같이 도메인 이름을 사용자 아이디에 추가합니다.
csvdmig 구문
csvdmig 유틸리티는 다음 구문을 사용합니다.
표 4-2는 csvdmig에서 사용한 옵션을 나열하며 각각의 설명을 제공합니다.
표 4-2 csvdmig 옵션
옵션
설명과 기본값
-m MappingFile
매핑 파일을 지정하는 입력 매개 변수입니다. 매핑 파일에 대한 자세한 내용은 매핑 파일을 참조하십시오. 기본값은 MigrateMapping입니다.
-c ConfigFile
Calendar Server 구성 파일을 지정하는 입력 매개 변수입니다. 기본값은 ics.conf 파일입니다.
-t DestinationDB
데이터베이스의 위치를 지정하는 출력 매개 변수입니다. 기본값은 MigratedDB입니다. 대상 DB를 참조하십시오.
-e ErrorFile
해결할 수 없는 오류의 오류 파일 이름을 지정하는 출력 매개 변수입니다. 기본값은 MigrateError입니다.
DB|LDAP
수정할 데이터베이스를 지정합니다.
DB – Calendar Server 데이터베이스
LDAP – LDAP 디렉토리기본값은 달력 데이터베이스(DB)입니다.
매핑 파일
매핑 파일은 기존 사용자를 해당 도메인에 매핑하는 입력 텍스트 파일입니다. csvdmig를 실행하기 전에 먼저 매핑 파일을 만들어야 합니다. 기존 값과 새 값 사이에 공백을 사용하여 각 행마다 하나씩 항목을 지정합니다. 예를 들면 다음과 같습니다.
user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
...
user-n user-n@siroe.com대상 DB
변수의 이름이 DestinationDB이고 기본값이 MigratedDB이지만 csvdmig는 별도로 마이그레이션된 데이터베이스를 만들지 않습니다. 이 옵션으로 지정한 원본 데이터베이스를 현재 위치에서 업데이트합니다.
csvdmig 예
commdirmigcommdirmig 유틸리티는 인증 서비스를 위한 Access Manager 사용에 대비하여 LDAP 데이터를 Sun LDAP Schema 1에서 Schema 2로 마이그레이션합니다.
이 절은 다음 내용으로 구성되어 있습니다.
유틸리티 실행 담당자
이전에 Messaging Server 5.x 또는 Calendar Server 5.x를 사용한 경우에는 LDAP 항목이 Sun LDAP Schema 1용으로 포맷되어 있습니다. 새 Calendar Server 6 2005Q1 환경에서의 인증에 Access Manager를 사용하려면 이 유틸리티를 실행하여 LDAP 항목을 Schema 2로 변환해야 합니다.
Schema 2는 LDAP를 사용하는 모든 Java Enterprise System 제품에서 기본 LDAP 모드이므로 Access Manager를 사용 중이 아니라면 LDAP 데이터 마이그레이션을 고려해야 합니다. 앞으로 새로운 버전의 통신 제품(Calendar, Messaging 및 Instant Messaging)에서는 Schema 1을 지원하지 않습니다. 하지만 당장 Access Manager를 사용할 계획이 아니라면 나중에 더 편리한 시점에 마이그레이션을 진행해도 됩니다.
유틸리티 실행 시간
이전 Java Enterprise System 버전에 해당하는 Calendar Server를 마이그레이션하는 경우에는 cs5migrate, csmig 및 csvdmig를 실행한 후에 이 유틸리티를 실행합니다.
설명서 위치
이 마이그레이션 유틸리티에는 특별한 준비와 계획이 필요합니다. 이는 별도의 설명서에 자세히 설명되어 있습니다. 다음 위치에서 Sun Java System Communications Services Schema Migration Guide를 참조하십시오.
http://docs.sun.com/coll/CalendarServer_05q1
유틸리티 위치
Sun Java Enterprise System 2005Q1의 경우 이 유틸리티는 사용자 관리 유틸리티 commadmin과 함께 Access Manager 2005Q1에 번들 제공됩니다.
Access Manager를 업데이트하지 않고 Calendar Server 마이그레이션 유틸리티만 필요한 경우에는 기술 지원에 문의하여 해당 유틸리티의 패치만 구할 수 있습니다.
