Sun Java System Calendar Server 6 2005Q4 관리 설명서

파트 IV Calendar Server 관리

12장 Calendar Server 관리

이 장과 Messaging Server가 만든 도메인 사용 이후에 나오는 장들은 Calendar Server의 관리 방법을 설명하며 다음 절로 구성되어 있습니다.

Delegated Administrator 유틸리티(이전 User Management 유틸리티) 또는 Calendar Server 명령줄 유틸리티를 실행하거나 ics.conf 구성 파일을 편집하여 Calendar Server를 관리할 수 있습니다.

명령줄 유틸리티를 실행하려면 Calendar Server가 실행되고 있는 시스템에 대해 관리 권한을 가진 사용자로 로그인해야 합니다.

자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

주 –

추가 관리 항목에 대해서는 별도의 장에서 설명합니다. 별도의 장은 다음 내용으로 구성되어 있습니다.

Calendar Server 시작 및 중지

이 절에서는 start-cal 및 stop-cal 사용 방법을 설명하며, 다음 내용으로 구성되어 있습니다.

start-cal 및 stop-cal 정보

start-cal 및 stop-cal 명령을 사용하여 Calendar Server를 시작하고 중지할 수 있습니다. start-cal 및 stop-cal 유틸리티는 cal_svr_base/SUNWics5/cal/sbin 디렉토리에 있습니다. Calendar Server가 설치된 로컬 시스템에서 이러한 유틸리티들을 실행해야 합니다.

주 –

Calendar Server는 이전 릴리스와의 호환성을 위해서만 csstart 및 csstop 유틸리티를 제공합니다. 가능한 경우 Calendar Server 시작과 중지에는 start-cal 및 stop-cal 유틸리티를 사용하는 것이 좋습니다.

start-cal 유틸리티는 다음 순서대로 Calendar Server 서비스를 시작합니다.

enpd— 이벤트 알림 서비스(ENS)
csnotifyd— 알림 서비스
csadmind— 관리 서비스
csdwpd— 원격 Calendar Server 데이터베이스 구성에서만 시작되는 분산 데이터베이스 서비스인 DWP(데이터베이스 와이어 프로토콜) 서비스
cshttpd— HTTP 서비스
csstored— 자동 백업 서비스

이러한 서비스에 대한 설명을 보려면 Calendar Server 서비스를 참조하십시오.

start-cal을 사용하여 Calendar Server를 시작하려면

단계

시스템에 관리 권한이 있는 사용자로 로그인합니다.

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

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

stop-cal을 사용하여 Calendar Server를 중지하려면

단계

Calendar Server가 실행되고 있는 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

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

다음을 사용하여 Calendar Server를 중지합니다.
./stop-cal

자동 백업 활성화 또는 비활성화

자동 백업은 start-cal을 실행하면 자동으로 시작되는 csstored 프로세스에 의해 관리됩니다. 하지만 원하는 대로 자동 백업을 활성화/비활성화할 수 있습니다. 기본값은 자동 백업 비활성화입니다. csstored 프로세스는 자동 백업이 비활성화된 경우에도 실행됩니다.

자동 백업에는 핫 백업과 아카이브 백업의 두 가지 종류가 있습니다. 두 백업을 각각 활성화/비활성화할 수 있습니다.

start-cal을 실행하기 전에 csstored 프로세스를 구성해야 합니다. 그렇지 않으면 csstored를 구성하지 않았다는 오류 메시지를 받게 됩니다. 이후 csstored가 구성될 때까지 24시간마다 동일한 메시지를 받게 됩니다.

자동 백업에 대한 정보와 csstored 구성 지침을 보려면 10 장, 자동 백업 구성(csstored)을 참조하십시오.

다음은 자동 백업을 활성화 및 비활성화하기 위한 태스크 목록입니다.

핫 백업을 활성화하려면

단계

명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.

cd /etc/opt/SUNWics5/config

다음 ics.conf 매개 변수를 “yes”로 설정하여 핫 백업을 활성화합니다.

caldb.berkeleydb.hotbackup.enable="yes"

핫 백업 디렉토리에 대한 디렉토리 경로를 지정합니다.
```
caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory
```
기본값은 현재 디렉토리입니다.

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.
```
cal_svr_base/SUNWics5/cal/sbin/start-cal
```
ics.conf 파일을 편집하기 위해 달력 서비스를 중지할 필요는 없지만 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

아카이브 백업을 활성화하려면

단계

명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.

cd /etc/opt/SUNWics5/config

다음 ics.conf 매개 변수를 “yes”로 설정하여 아카이브 백업을 활성화합니다.

caldb.berkeleydb.archive.enable=”yes”

아카이브 백업 디렉토리의 디렉토리 경로를 지정합니다.
```
caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/hotbackup_directory
```
기본값은 현재 디렉토리입니다.

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.
```
cal_svr_base/SUNWics5/cal/sbin/start-cal
```
ics.conf 파일을 편집하기 위해 달력 서비스를 중지할 필요는 없지만 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

핫 백업을 비활성화하려면

백업은 기본적으로 비활성화되어 있습니다. 이전에 활성화한 백업을 비활성화하려면 다음 단계를 수행합니다.

단계

명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.

cd /etc/opt/SUNWics5/config

다음 ics.conf 매개 변수를 "no"로 설정하여 핫 백업을 비활성화합니다.

caldb.berkeleydb.hotbackup.enable="no"

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.
```
cal_svr_base/SUNWics5/cal/sbin/start-cal
```
ics.conf 파일을 편집하기 위해 달력 서비스를 중지할 필요는 없지만 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

아카이브 백업을 비활성화하려면

백업은 기본적으로 비활성화되어 있습니다. 이전에 활성화된 백업을 비활성화하려면 다음 단계를 수행합니다.

단계

명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.

cd /etc/opt/SUNWics5/config

다음 ics.conf 매개 변수를 "no"로 설정하여 아카이브 백업을 비활성화합니다.

caldb.berkeleydb.archive.enable="no"

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.
```
cal_svr_base/SUNWics5/cal/sbin/start-cal
```
ics.conf 파일을 편집하기 위해 달력 서비스를 중지할 필요는 없지만 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

그룹 예약 엔진 대기열 관리

그룹 예약 엔진(GSE)에는 구성 요소 데이터베이스의 업데이트에 사용되는 이벤트 대기열이 있습니다. 관리자는 시간 초과 값을 변경하여 Calendar Server에서 대기열을 스캔하는 시간 간격을 조정할 수 있습니다. 필요한 경우에는 대기열에 있는 이벤트를 나열하거나 특정 이벤트를 삭제할 수도 있습니다.

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

GSE 정보

GSE에서는 Calendar Server 사용자가 이벤트를 만들고 다른 참가자를 초대할 수 있습니다. 참석자가 같은 Calendar Server에 있을 경우 참석자의 달력에 이벤트가 예약됩니다. 같은 Calendar Server에 있지 않으면 전자 메일을 통해 초대가 보내집니다. 그러고 나면 참가자가 초대를 승인 또는 거부하고 GSE에서 응답으로 이벤트를 업데이트할 수 있습니다.

GSE 대기열 정보

GSE 대기열은 실제로는 GSE가 관리하는 별도의 데이터베이스에 있습니다. Calendar Server에서는 대기열을 스캔하여 구성 요소 데이터베이스에 필요한 업데이트를 찾습니다.

이 스캔의 빈도를 조정하면 Calendar Server를 조정할 수 있습니다. ics.conf 파일에서 gse.belowthresholdtimeout의 시간 초과 값을 변경하면 됩니다. 21 장, Calender Server 성능 조정을 참조하십시오.

GSE 대기열 항목은 csschedule을 사용하여 관리(나열 및 삭제)할 수 있습니다. Calendar Server가 설치된 로컬 시스템에서 csschedule을 실행해야 합니다.

GSE 대기열의 항목 나열

GSE 대기열의 항목을 나열하려면 csschedule 유틸리티 listlist 명령을 사용합니다.

예를 들어, GSE 대기열의 모든 항목을 나열하려면 다음 명령을 사용합니다.

csschedule list

GSE 대기열에 저장된 처음 10개 항목을 나열하려면 다음 명령을 사용합니다.

csschedule -c 10 list

GSE 대기열에서 calid가 Holiday_Schedule인 모든 항목을 나열하려면 다음 명령을 사용합니다.

csschedule -v list Holiday_Schedule

GSE 대기열의 항목 삭제

GSE 대기열에서 항목을 삭제하려면 csschedule 유틸리티 delete 명령을 사용합니다.

예를 들어, GSE 대기열의 모든 항목을 삭제하려면 다음 명령을 사용합니다.

csschedule -v delete

GSE 대기열에서 calA 달력에 대해 처음 예약 시간이 11/30/2001의 13:30:45, 오프셋 번호가 1, 고유 아이디가 1111, 반복 아이디가 0, 그리고 시퀀스 번호가 0인 항목을 삭제하려면 다음 명령을 사용합니다.

csschedule -v -t 20011130T133045Z -o 1 -u 1111 -r 0 -n 0 delete calA

Calendar Server 모니터링

일상 작업 과정에서 시스템 작업을 모니터할 수 있습니다. csmonitor, csstats, cstool 등과 같은 몇 가지 유틸리티 도구를 사용하여 Calendar Server 작동을 모니터링할 수 있습니다. 또한 시스템 사용을 모니터하는 데 도움되는 많은 로그 파일을 설정할 수 있습니다.

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

csmonitor 정보

이 Calendar Server 유틸리티는 bash가 필요한 쉘 스크립트입니다. 이 유틸리티는 호출되면 다음과 같은 기능을 수행합니다.

ics.conf 파일에 지정된 로그 수준에 따라 csadmind, csnotifyd, cshttpd, enpd 등과 같은 프로세스를 모니터링하고 기록합니다.
cshttpd가 명령을 적용 중인지 확인합니다.
시스템에 LDAP 연결이 있는지 확인합니다.
순환 로깅이 사용 가능한 경우 트랜잭션 파일이 두 개 이상 있는지 확인한 다음 그렇다면 전자 메일 경고를 보냅니다.
달력 데이터베이스에서 작업을 제대로 수행하는 데 충분한 디스크 공간이 있는지 확인합니다.
이 유틸리티는 오류가 발생할 경우 해당 오류를 기록하고 ics.conf 매개 변수 service.monitor.emailaddress.to에 지정된 관리자에게 전자 메일로 알립니다.

디버깅을 위해 매우 짧은 간격으로 연속 루프에서 실행하도록 모니터를 구성할 수 있습니다. 그렇게 하려면 많은 시스템 자원이 필요하기 때문에 일반 작업 중에는 이 모드에서 유틸리티를 실행하지 않습니다.

일반 환경에서 csmonitor를 사용하려면 선택한 간격으로 실행하도록 유틸리티를 설정해야 합니다.

csmonitor 유틸리티에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

csmonitor를 구성하려면

단계

구성 변경 권한이 있는 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 표에 표시된 ics.conf 매개 변수 중 하나 이상을 편집하십시오.

매개 변수	설명 및 기본값
service.monitor.continuous	csmonitor가 지속적으로 루프해야 하는지 여부를 지정합니다.`"0"` – 연속 루프를 수행하지 않습니다(기본값).`"1"` – 연속 루프를 수행합니다. csmonitor가 자동으로 실행되게 하려면 이 매개 변수를 `“1”`로 설정합니다.
service.monitor.loopsdelay	두 모니터링 루프 사이의 지연 시간을 초 단위로 지정합니다. 기본값은 “60”초입니다. 디버깅을 위해서는 간격을 짧게 설정하고 작업을 위해서는 간격을 길게 설정하는 것이 좋습니다.
service.monitor.emailaddress.from	`csmonitor`가 메시지를 보내는 전자 메일 주소를 지정합니다. 지정된 기본값은 없습니다.
service.monitor.emailaddress.to	`csmonitor`가 보내는 메시지를 받을 전자 메일 주소를 지정합니다. 지정된 기본값은 없습니다.
service.monitor.csdb.logthreshold	달력 데이터베이스(`csdb)`를 모니터링합니다. 최대 디스크 점유를 위한 총 디스크 공간의 백분율로 임계값을 지정합니다. `csdb` 디렉토리의 디스크 점유율이 이 값을 초과하는 경우 경고 전자 메일 메시지를 보냅니다. 기본값은 `“90”`입니다.
logfile.monitor.logname	`csmonitor` 로그 파일 이름을 지정합니다. 기본값은 `“csmonitor.log”`입니다.
logfile.monitor.maxlogfilesize	최대 로그 파일 크기를 지정합니다. 로그 파일이 이 크기를 초과하면 `csmonitor`는 해당 로그를 `csmonitor.log`.`timestamp`로 저장하고 현재 로그를 재설정합니다. 기본값은 `“2097152”` 입니다.
service.monitor.dbglevel	디버그 수준을 지정합니다. 범위는 `0`-`5`이며 이 값이 클수록 `csmonitor`는 더 정밀하고 상세한 메시지를 보냅니다. 기본값은 `“0”`이며 로깅을 지정하지 않습니다. 값 `“5”`는 디버그 로깅을 나타냅니다.

파일을 ics.conf로 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

카운터 통계 나열

csstats 유틸리티는 달력 구성( counter.conf) 파일에 정의된 카운터 객체의 통계 정보를 표시합니다. httpstat, authstat, wcapstat 또는 dbstat와 같은 카운터 객체는 다음과 같은 Calendar Server에 대한 정보를 표시합니다.

최대 동시 연결 수 및 전체 연결 수
전체 성공/실패한 로그인 및 연결 수
데이터베이스 읽기, 쓰기 및 삭제 수

Calendar Server 카운터 통계에 대한 자세한 내용은 부록 E, Calendar Server 구성 매개 변수 를 참조하십시오.

모니터링을 위한 cstool 사용

Calendar Server가 설치되는 시스템과 다음 서비스를 핑할 수 있습니다.

cshttpd
csadmind
enpd

cstool 사용에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

Calendar Server 로그 파일 사용

각 Calendar Server 서비스는 자체의 로그 파일에 상태 정보를 씁니다. 다음 표와 같이 각 로그 파일은 해당 서비스 이름을 따라 명명됩니다.

서비스 이름	로그 파일 이름
관리 서비스(csadmind)	admin.log
분산 데이터베이스 서비스(csdwpd)	dwp.log
HTTP 서비스(cshttpd)	http.log
알림 서비스(csnotifyd)	notify.log
단일 사인 온 로그	am_sso.log
시작 명령 로그	start.log
정지 명령 로그	stop.log
저장 명령 로그	store.log

Calendar Server 로그 파일은 다음 기본 디렉토리에 저장됩니다.

/var/opt/SUNWics5/logs

각 로그 파일은 고유한 번호로 식별되는 새 로그 파일로 롤오버됩니다. 예를 들면 다음과 같습니다.

admin.log.8.1083013284 http.log.8.1083013284

Calendar Server는 다음 표에 설명된 것처럼 로그 파일에 보고되는 이벤트에 대해 6가지 심각도 수준을 제공합니다. ics.conf 매개 변수 logfile.loglevel을 수정하여 Calendar Server가 로그 파일에 보고하는 이벤트의 심각도 수준을 지정할 수 있습니다.

심각도 수준	의미
CRITICAL	심각한 조건
ERROR	오류 조건
WARNING	경고 조건
NOTICE	정상. 통보 조건각 달력 서비스의 기본 보고 수준입니다.
INFORMATION	참조용
DEBUG	디버그 수준 메시지

로그 이벤트는 타임스탬프, 서버 호스트 이름, 심각도 수준, 프로세스 이름(프로세스 아이디), 이벤트 유형, 우선 순위 및 설명을 보여 주는 하나의 행으로 표시됩니다.

ics.conf 로그 설정에 대한 자세한 내용은 부록 E, Calendar Server 구성 매개 변수 를 참조하십시오.

CLD 캐시 지우기

CLD 캐시를 활성화한 경우 가끔씩 캐시를 지워야 합니다. 이 절은 다음 내용으로 구성되어 있습니다.

CLD 캐시를 지우는 이유

CLD 캐시는 다음과 같은 다양한 이유로 시스템 구성과 동기화되지 않을 수 있습니다.

서버를 추가, 삭제 또는 이름 변경한 경우
서버를 구성의 한 기능에서 다른 기능으로 이동한 경우
하나 이상의 달력을 다른 백엔드 서버로 이동한 경우

위와 같은 경우에 CLD 캐시를 새로 고치려면 CLD 캐시를 지워야 합니다.

CLD 캐시를 지우려면

단계

Calendar Server를 중지합니다.

/var/opt/SUNWics5/csdb/cld_cache 디렉토리의 모든 파일을 지우되 cld_cache 디렉토리 자체는 제거하지 않습니다.

Calendar Server를 다시 시작합니다.

서버 이름 변경

구성에서 서버 이름을 추가, 삭제 또는 변경한 경우 오류 방지를 위해 다음과 같은 몇 가지 작업 관리 단계를 수행해야 합니다.

CLD 캐시 지우기
이전 서버를 제거한 경우 해당 서버가 표시된 ics.conf 매개 변수에서 서버를 삭제합니다.

익명 액세스 구성

익명 액세스는 인증이 필요하지 않은 특수 로그인입니다. 익명 로그인을 사용 가능하게 하면 공용 달력에 대한 읽기 및 쓰기 액세스가 기본적으로 사용 가능해집니다. 공용 달력에 대한 쓰기 액세스를 거부할 수 있습니다. 이 절은 다음 내용으로 구성되어 있습니다.

주 –

Communications Express는 익명 로그인으로 쓰기 및 읽기가 모두 가능해질 것으로 예상합니다. Communications Express를 위한 구성을 참조하십시오.

익명 액세스를 활성화하려면

단계

구성 변경 권한이 있는 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

익명 액세스를 활성화하도록 ics.conf에서 다음 매개 변수를 편집합니다.

매개 변수	설명 및 기본값
`service.http.allowanonymouslogin`	필요한 경우 이 매개 변수를 `“yes”`로 설정하여 익명 액세스(로그인)를 가능하게 합니다. 기본값은 `“yes”`입니다.
`service.calendarsearch.ldap`	보안상 익명 로그인이 가능하게 한 상태에서 이 매개 변수를 `“no”`(기본값)로 설정하여 달력 검색을 수행할 때 LDAP를 통한 검색을 사용 불가능하게 할 수 있습니다.

주 –

Communications Express는 service.calendarsearch.ldap 매개 변수의 값이 “no”일 것으로 예상합니다. 이는 DWP 환경에서 최적의 성능을 위한 시스템 조정 지침과 충돌합니다. (데이터베이스가 여러 백엔드에 분산됨) DWP 환경의 달력 검색 성능 향상을 참조하십시오.

파일을 ics.conf로 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

익명 사용자가 공용 달력에 쓸 수 없게 하려면

단계

구성을 변경할 수 있는 권한을 가진 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 표에 표시된 ics.conf 매개 변수 중 하나 이상을 편집하십시오.

매개 변수	설명 및 기본값
`service.wcap.anonymous.` `allowpubliccalendarwrite`	익명 액세스 사용자의 공용 달력에 쓰기를 가능/사용 불가능하게 합니다. 값을 기본값인 `“yes”`로 설정하여 액세스를 가능하게 합니다.

매개 변수

설명 및 기본값

service.wcap.anonymous.

allowpubliccalendarwrite

익명 액세스 사용자의 공용 달력에 쓰기를 가능/사용 불가능하게 합니다. 값을 기본값인 “yes”로 설정하여 액세스를 가능하게 합니다.

파일을 ics.conf로 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

프록시 관리자 로그인 활성화

Communications Express에 대해 프록시 관리자 로그인(프록시 인증)을 활성화해야 합니다. Communications Express에 대한 프록시 인증 구성에 대한 자세한 내용은 Communications Express를 위한 구성을 참조하십시오.

그러나 Communications Express를 사용하지 않는 경우에도 프록시 인증을 가능하게 할 수 있습니다. 이 절에서는 Communications Express를 사용하지 않고 프로시 인증을 활성화하는 절차를 설명합니다.

Communications Express를 사용하지 않고 프록시 인증을 활성화하려면

단계

구성을 변경할 수 있는 권한을 가진 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 매개 변수를 설정하여 ics.conf 파일을 편집합니다.

service.http.allowadminproxy = "yes"

파일을 ics.conf로 저장합니다.

새 값을 적용하려면 Calendar Server를 다시 시작합니다.

프록시 인증이 작동하는지 검증하려면

단계

다음 WCAP 명령을 사용하여 관리자 프록시 로그인이 제대로 작동하는지 확인합니다.

http://server[:port]
/login.wcap?user=admin-user&password=admin-password
&proxyauth=calendar-user

여기서,

server– Calendar Server가 실행 중인 서버의 이름입니다.
- port– Calendar Server 포트 번호입니다. 기본 포트는 80입니다.
- admin-user – Calendar Server 관리자입니다. 예를 들어, calmaster입니다.
- admin-password – admin-user의 비밀 번호입니다.
- calendar-user – Calendar Server 사용자의 calid입니다.
  
  명령이 성공하면 Calendar Server는 calendar-user의 달력을 표시합니다. 문제가 발생하면 Calendar Server는 “Unauthorized”라는 메시지를 표시합니다. 다음이 원인이 될 수 있습니다.
- admin-user에게 Calendar Server 관리자 권한이 없습니다.
- admin-password가 올바르지 않습니다.
- calendar-user가 유효한 Calendar Server 사용자가 아닙니다.

Calendar Server 구성 새로 고침

현재 릴리스에서는 cstool refresh 명령을 사용하여 구성을 새로 고치지 마십시오. 그 대신 stop-cal 및 start-cal 명령을 사용합니다. 자세한 내용은 Calendar Server 시작 및 중지를 참조하십시오.

13장 호스트된 도메인 관리

이 장은 호스트된 도메인 관리에 대한 다음 내용으로 구성되어 있습니다.

정확한 사용자 관리 도구 선택

호스트된 도메인에 달력 설치를 구성하고 11 장, 호스트된 도메인 설정에 설명된 준비 작업을 수행하고 나면 새로 호스트된 도메인을 추가할 수 있습니다.

각 도메인은 설정한 속성 및 기본 설정 집합을 갖습니다. 이러한 속성은 icsCalendarDomain 객체 클래스의 일부입니다. 이 속성에는 액세스 권한, 액세스 제어 목록(ACL), 도메인 검색, 도메인 검색의 액세스 권한, 사용자 상태 및 프록시 로그인과 같은 기본 설정이 포함됩니다.

Calendar Server의 호스트된(또는 가상) 도메인을 관리하려면 다음 두 도구 집합 중 하나를 사용합니다.

Delegated Administrator 콘솔 또는 유틸리티 – 스키마 2 환경

Delegated Administrator는 Java Enterprise System 설치 프로그램에서 별도로 설치할 수 있는 구성 요소입니다. 이 유틸리티에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오. 콘솔에 대한 자세한 내용은 Delegated Administrator 콘솔 온라인 도움말을 참조하십시오.
Calendar Server 유틸리티 — (csdomain and csattribute) 스키마 1 환경

Calendar Server를 설치합니다. csdomain으로 속성을 추가 또는 삭제할 수 있지만 modify 명령은 없습니다. csattribute를 사용하여 기존 속성 값을 수정합니다. 또한 필요한 경우 ldapmodify를 사용하여 csdomain으로 만든 도메인의 객체 클래스를 추가 또는 삭제합니다.

csdomain 및 csattribute에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

특정한 객체 클래스와 속성에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Reference를 참조하십시오.

호스트된 도메인의 개요 및 기타 참조 정보를 보려면 11 장, 호스트된 도메인 설정을 참조하십시오.

주의 –

Calendar Server에서는 도메인 관리를 위한 Access Manager 콘솔을 지원하지 않습니다.

새 호스트된 도메인 만들기

스키마 2 또는스키마 1로 호스트된 도메인을 만듭니다.

호스트된 도메인(스키마 2) 추가 방법

다음과 같이 Delegated Administrator 콘솔이나 유틸리티를 사용할 수 있습니다.

콘솔 — 조직 목록 페이지에서 새 조직 만들기 마법사를 사용합니다.

자세한 내용은 Delegated Administrator 콘솔 온라인 도움말을 참조하십시오.
유틸리티 — commadmin domain create 명령을 사용합니다.

예를 들어, 도메인 sesta.com을 만들려면 다음 명령을 실행합니다.
```
commadmin domain create -D calmaster
    -d sesta.com -w calmasterpassword -S cal 
    -B backend.sesta.com
```
Delegated Administrator 유틸리티에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

호스트된 도메인(스키마 1) 추가

csdomain 유틸리티를 실행하려면 호스트된 도메인 모드에 있어야 합니다. 호스트된 도메인 활성화 방법에 대한 자세한 내용은 11 장, 호스트된 도메인 설정을 참조하십시오.

스키마 1에서 호스트된 도메인을 만들 때 csdomain create를 사용합니다. 예를 들어, west.sesta.com을 만들려면 다음 명령을 사용합니다.

csdomain create west.sesta.com

도메인간 검색 활성화

이 절은 도메인간 검색을 활성화하기 위해 필요한 두 가지 작업에 대해 설명합니다.

이 도메인의 검색이 허용된 각 도메인에 대한 LDAP 항목에 이 도메인 검색이 허용된 도메인의 이름 추가
이 도메인의 사용자가 이벤트 초대장을 보낼 때 이 도메인에서 검색할 도메인의 이름 추가

이 작업은 다음 도구를 사용하여 수행할 수 있습니다. ldapmodify(임의의 스키마 모드) 또는 Delegated Administrator 콘솔이나 유틸리티(스키마 2)

이 도메인 검색이 허용된 도메인의 이름 추가

각 도메인 LDAP 항목은 ACE에 icsExtendedDomainPrefs 속성의 domainAccess 매개 변수에 정의된 액세스 권한을 지정합니다. 다음의 두 가지 방법으로 외부 도메인이 이 도메인을 검색하도록 허용할 수 있습니다.

ACI의 구성은 달력 액세스 제어에 자세히 설명되어 있습니다.

특정 도메인이 이 도메인을 검색하도록 허용

이 작업은 다음의 세 가지 방법으로 수행할 수 있습니다.

ldapmodify를 사용하고 icsExtendedDomainPrefs의 domainAccess 기본 설정에 다음 ACE 문자열을 만듭니다.

@domain_being_allowed ^a^lsfr^g

이 도메인을 검색할 수 있는 도메인을 지정한 후 검색을 허용할 수 있는 권한을 지정하여 ACE를 구성합니다.
Delegated Administrator 유틸리티 명령 commadmin domain modify를 사용할 경우 icsExtendedDomainPrefs 속성의 domainAccess 기본 설정을 지정하여 ACE 문자열을 추가합니다.

예를 들어, 스키마 2 환경에서 sesta.com은 siroe.com으로부터의 검색을 허용합니다.
```
commadmin domain modify -D admin
   -w adminpassword -X hostmachine_1 -d sesta.com 
   -A +icsextendeddomainprefs:"domainAccess=@@d^a^slfrwd^g;
      @siroe.com^a^lsfrwd^g;anonymous^a^r^g;@^a^s^g"
```
Delegated Administrator 콘솔을 사용할 경우 조직의 등록 정보를 만들거나 편집할 때 이 조직의 사용자로부터의 초대 허용 목록에 도메인을 추가할 수 있습니다.

이렇게 하면 icsExtendedDomainPrefs 속성의 domainAccess 기본 설정이 업데이트됩니다.

주 –

나열된 처음 두 가지 방법에서는 도메인에 부여된 정확한 권한을 지정할 수 있지만 Delegated Administrator 콘솔을 사용할 경우에는 관리자에게 많은 제어 권한이 허용되지 않습니다. 권한 목록은 미리 설정되어 있습니다. 지정된 권한으로는사용 가능/사용 중 액세스 권한 및 이벤트 예약 액세스 권한이 있습니다. 해당 달력의 소유자가 모든 사용자가 달력을 읽을 수 있도록 하는 권한을 설정하지 않는 한, 사용자는 이벤트 세부 정보를 볼 수 없습니다.

모든 외부 도메인이 이 도메인을 검색하도록 허용

다음의 세 가지 방법으로 모든 도메인이 이 도메인을 검색할 수 있도록 허용할 수 있습니다.

ldapmodify를 사용하고 icsExtendedDomainPrefs의 domainAccess 기본 설정에 다음 ACE 문자열을 만듭니다.

@^a^slfr^g

모든 도메인이 검색을 수행할 권한을 갖도록 지정하여 ACE를 구성합니다.
Delegated Administrator 유틸리티 명령 commadmin domain modify를 사용할 경우 icsExtendedDomainPrefs 속성의 domainAccess 기본 설정을 지정하여 ACE 문자열을 추가합니다.

예를 들어, 스키마 2 환경에서, sesta.com은 모든 도메인에 의한 검색을 허용합니다.
```
commadmin domain modify -D admin 
   -w adminpassword -X hostmachine_1 -d sesta.com 
   -A +icsextendeddomainprefs:"domainAccess=@@d^a^slfrwd^g;
      anonymous^a^r^g;@^a^slfr^g"
```
주 –
문자 @@d는 주 소유자의 도메인을 나타냅니다.
Delegated Administrator 콘솔을 사용할 경우 조직의 등록 정보를 만들거나 편집할 때 이 조직의 사용자로부터의 초대 허용 목록에 도메인을 추가할 수 있습니다.

이렇게 하면 icsExtendedDomainPrefs 속성의 domainAccess 기본 설정이 업데이트됩니다.

주 –

이 도메인에서 검색할 도메인의 이름 추가

다음의 세 가지 방법으로 이 도메인에서 검색할 수 있는 외부 도메인을 추가할 수 있습니다.

ldapmodify를 사용할 경우 이 도메인의 사용자가 검색할 수 있는 각 외부 도메인에 대한 icsDomainNames의 단일 인스턴스를 추가합니다.

예를 들어, sesta.com은 도메인간 검색을 수행할 때 siroe.com 및 example.com에서 검색합니다. ldapmodify(스키마 1 또는 스키마 2)를 사용하여 다음 LDIF를 만들 수 있습니다.
```
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: icsDomainNames
icsDomainNames:siroe.com
icsDomainNames:example.com
```
Delegated Administrator 유틸리티 명령 commadmin domain modify를 사용할 경우 -A 옵션을 지정하여 검색할 도메인의 이름을 추가합니다.

예를 들면 다음과 같습니다.
```
commadmin domain modify -D admin 
   -w adminpassword -X hostmachine_1 -d sesta.com 
   -A +icsDomainNames:siroe.com 
   -A +icsDomainNames:example.com
```
Delegated Administrator 콘솔을 사용할 경우 조직의 등록 정보를 만들거나 편집할 때 이 조직의 달력 초대 목록에 도메인을 추가할 수 있습니다.

이렇게 하면 도메인 LDAP 항목에 icsDomainNames 속성이 추가됩니다. 이 도메인의 사용자가 이벤트에 초대장을 보낼 때는 검색할 각 외부 도메인에 대해 하나의 속성을 추가합니다.

자세한 내용은 Delegated Administrator 콘솔 온라인 도움말을 참조하십시오.

호스트된 도메인 사용

Calendar Server의 기본값은 호스트되지 않은 도메인입니다. Java Enterprise System 배포에서 Calendar Server 및 Messaging Server를 사용하는 경우 호스트된 도메인을 사용해야 합니다.

ics.conf 파일을 편집하면 설치 환경에서 호스트된 도메인을 활성화 또는 비활성화할 수 있습니다.

호스트된 도메인 사용 방법

단계

ics.conf 파일을 다음과 같이 편집합니다.

service.virtualdomain.support="yes"(기본값 "no")

Calendar Services를 다시 시작합니다.

호스트된 도메인 구현에 필요한 모든 ics.conf 매개 변수 목록을 보려면 호스트된 도메인 환경 설정을 참조하십시오.

호스트된 도메인 비활성화 방법

단계

다음과 같이 ics.conf 파일을 편집합니다.

service.virtualdomain.support="no"

Calendar Services를 다시 시작합니다.

14장 사용자 및 자원 관리

이 장에서는 Calendar Server 유틸리티를 사용하여 사용자 및 자원을 관리하는 방법을 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

사용자 관리 도구

다음 사용자 관리 도구 중 하나를 사용하여 달력 사용자와 자원을 관리할 수 있습니다.

Delegated Administrator 콘솔

이 GUI를 사용하여 Calendar Server에 대한 LDAP의 사용자 및 자원을 규정합니다. GUI 사용에 대한 자세한 내용은 Delegated Administrator 콘솔 온라인 도움말을 참조하십시오.
Delegated Administrator 유틸리티(commadmin)

이 도구들을 사용하여 Calendar Server에 대한 LDAP의 사용자 및 자원을 규정합니다. 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

주 –

Delegated Administrator는 달력을 관리하지 않습니다. 사용자 및 자원에 대한 달력을 만들려면 Calendar Server 유틸리티를 사용합니다.

Calendar Server 유틸리티(csuser 및 csresource)

이 유틸리티들을 사용하여 달력을 관리합니다. 또한 구성이 다음 기준을 모두 충족하면 사용자 및 자원 관리에 이 유틸리티를 사용합니다.
- Access Manager를 사용하지 않습니다.
- Sun LDAP Schema 1을 사용하는 이전 버전의 Calendar Server 또는 Messaging Server가 설치되어 있습니다.
- 스키마 1을 계속 사용할 계획입니다.
이 설명서 부록 D, Calendar Server 명령줄 유틸리티 참조 에서 명령줄 참조를 참조하십시오.

주 –

스키마 2와 Delegated Administrator를 사용하더라도 일부 Calendar Server 명령줄 유틸리티를 사용하여 특별한 기능을 수행하는 경우가 있습니다. 필요한 경우에는 이 설명서에 있는 작업 중심의 설명에서 사용할 유틸리티를 알려 줍니다.

사용자 및 자원 만들기

이 절에서는 새로운 Calendar Server 사용자 및 자원 관리에 대해 다음 정보를 제공합니다.

스키마 2에서 새 사용자 만들기

다음과 같이 Delegated Administrator 콘솔이나 유틸리티를 사용할 수 있습니다.

Delegated Administrator 콘솔

Delegated Administrator 콘솔에서 새 사용자 만들기 마법사를 사용합니다. (사용자가 위치할 조직에 대한 사용자 목록 페이지에서 새로 만들기를 누릅니다.)자세한 내용은 Delegated Administrator 콘솔 온라인 도움말을 참조하십시오.
Delegated Administrator 유틸리티

commadmin 유틸리티 user create 명령을 사용합니다. 예를 들어, sesta.com 도메인에서 사용자 jdoe를 추가하려면 다음 명령을 사용합니다.
```
commadmin user create -D calmaster -F John -n sesta.com 
   -k hosted -l jdoe -w calmasterpassword -W jdoepassword -L Doe -S cal
   -B red.sesta.com -E jdoe@sesta.com
```
commadmin 유틸리티에 사용할 수 있는 모든 옵션에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

스키마 1의 새 사용자 만들기

csuser 유틸리티를 사용합니다. 예를 들어, sesta.com 도메인에서 사용자 jdoe를 추가하려면 다음 명령을 사용합니다.

csuser -m jdoe@sesta.com -d sesta.com create jdoe

스키마 2의 새 자원 만들기

다음과 같이 Delegated Administrator 콘솔이나 유틸리티를 사용할 수 있습니다.

Delegated Administrator 콘솔

Delegated Administrator 콘솔에서 새 자원 만들기 마법사를 사용합니다. (자원이 위치할 조직에 대한 달력 자원 탭에서 새로 만들기를 누릅니다.)자세한 내용은 Delegated Administrator 콘솔 온라인 도움말을 참조하십시오.
Delegated Administrator 유틸리티

commadmin 유틸리티 rescource create 명령을 사용하여 LDAP 항목을 만듭니다. 예를 들어, 회의실 Conference_Room_100을 추가하려면 다음 명령을 사용합니다.
```
commadmin resource create -D calmaster 
   -w calmasterpassword -n sesta.com -c room100 
   -N Conference_Room_100
```
그런 후 csresource를 사용하여 실제 자원 달력을 만듭니다. 자원 달력을 만드는 방법에 대한 자세한 내용은 달력 만들기를 참조하십시오.

commadmin 유틸리티에 사용할 수 있는 모든 옵션에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

스키마 1의 새 자원 만들기

csresource 유틸리티를 사용하여 LDAP 항목과 자원 달력을 모두 만듭니다. 예를 들어, 프로젝터 p101을 추가하려면 다음 명령을 사용합니다.

csresource -m p101@siroe.com -c p101 create Projector_101

csresource에 대한 자세한 내용은 csresource를 참조하십시오.

필수 메일 속성 추가

Calendar Server에서는 사용자와 자원에 사용자 또는 자원의 전자 메일 주소가 들어 있는 mail 속성이 있어야 합니다. 이 속성이 있으면 전자 메일 주소 또는 calid를 사용하여 달력과 자원을 검색할 수 있습니다. Delegated Administrator에서 새 사용자를 만들면 mail 속성이 자동으로 추가됩니다. 사용자에게 메일 서비스가 할당되지 않은 경우에도 이 작업이 수행됩니다.

주 –

Calendar Server는 자원 달력에 대한 전자 메일 알림을 지원하지 않습니다.

mail 속성을 추가해도 사용자 달력에 대한 전자 메일 알림은 활성화되지 않습니다.

사용자 달력에 대해 전자 메일 알림을 활성화하려면 다음의 두 속성을 사용자의 LDAP 항목에 추가합니다.

icsExtendedUserPrefs:ceNotifyEnable=1 
icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com

사용자와 자원이 초기 버전의 Calendar Server에서 추가되었다면(mail 속성이 필수가 아니었을 때) mail 속성을 기존 사용자 및 자원 항목에 추가해야 합니다.

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

메일 속성 설정 여부 확인

속성이 설정되었는지 확인하려면 csattribute list 명령을 -v(세부 정보 표시) 옵션과 함께 사용합니다.

csattribute -v list Room100

메일 속성이 존재하는지 출력으로 확인합니다.

cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com
 has mail: Room100@sesta.com

기존 사용자와 자원에 Mail 속성 추가

기존 사용자와 자원에 mail 속성을 추가하려면 다음 방법 중 하나를 사용합니다.

Calendar Server csattribute 유틸리티를 사용합니다.

다음 예에서는 sesta.com 서버에서 Room100이라는 기존 회의실에 대해 LDAP mail 속성을 추가합니다.
```
csattribute -a mail=Room100@sesta.com add Room100
```
LDAP 항목에 직접 이 속성을 추가하려면 ldapmodify를 사용합니다.

사용자 관리

사용자를 만들었다면 csuser 유틸리티를 사용하여 다음 관리 작업을 수행할 수 있습니다.

사용자 정보 표시

모든 달력 사용자를 나열하거나 지정된 사용자의 달력 속성을 표시하려면 csuser 유틸리티 list 명령을 사용합니다.

예를 들어, 달력 사용이 가능한 모든 사용자를 표시하려면 다음 명령을 사용합니다.

csuser list

jsmith와 같이 단일 사용자의 달력 속성을 모두 표시하려면 다음 명령을 사용합니다.

csuser -v list jsmith

사용자 비활성화

사용자를 비활성화하는 목적은 사용자가 Calendar Server에 로그인하지 못하게 하기 위한 것입니다. 이 작업은 사용자를 만드는 데 사용한 사용자 관리 도구에 따라 약간 다르게 수행됩니다. Delegated Administrator 콘솔에서 만들어진 사용자는 이 콘솔을 통해 관리되어야 합니다. 마찬가지로 Delegated Administrator 유틸리티를 사용하여 사용자에게 달력 서비스를 할당했으면 서비스 제거 시에도 이 유틸리티를 사용해야 합니다. 또한 호스트되지 않은 도메인 환경의 사용자는 Calendar Server 유틸리티를 통해서만 관리해야 합니다. 이로 인해 작업 상황에 약간씩 달라집니다.

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

Delegated Administrator 콘솔
Delegated Administrator 유틸리티(commadmin user delete)
Calendar Server 유틸리티(csuser disable)(Calendar Server 유틸리티)

Delegated Administrator 콘솔

Delegated Administrator 콘솔의 사용자 목록 페이지에서 사용자를 선택합니다. 이 사용자에 대한 등록 정보에서 달력 서비스가 있는 서비스 패키지를 삭제합니다. 이렇게 하면 사용자의 icsStatus가 inactive로 설정되는 것을 포함하여 사용자가 달력을 사용할 수 없게 비활성화됩니다.

주 –

패키지에 다른 서비스도 들어 있는 경우 달력이 들어 있지 않은 다른 패키지를 사용하여 해당 서비스를 다시 할당해야 합니다.

Delegated Administrator 유틸리티(commadmin user delete)

사용자가 달력 서비스에 액세스할 수 없게 하려면 다음 예와 같이 사용자 LDAP 항목에서 서비스를 제거합니다.

commadmin user delete jsmith -S cal

이렇게 하면 LDAP 항목이 완전히 제거되지 않고도 사용자가 달력을 사용할 수 없게 비활성화됩니다. 또한 이 명령을 사용하면 사용자의 icsStatus가 inactive로 변경됩니다.

Calendar Server 유틸리티(csuser disable)

disable 명령은 사용자가 달력 데이터에 액세스할 수 있게 하지만 LDAP 항목이나 Calendar Server 데이터베이스에서 사용자의 정보를 제거하지는 않습니다. 이 명령을 사용하면 icsStatus 속성이 active에서 inactive로 변경됩니다. 호스트되지 않은 도메인 모드에서는 달력 서비스와 같은 것이 없습니다.

예를 들어, jsmith가 Calendar Server에 액세스하지 못하게 하려면 다음 명령을 사용합니다.

csuser disable jsmith

jsmith가 현재 Calendar Server에 로그인된 상태라면 jsmith는 로그오프할 때까지 달력 데이터에 대한 액세스 권한을 보유합니다.

사용자 활성화

사용자를 활성화하려면 다음 도구 중 하나를 사용합니다.

Delegated Administrator 콘솔
Delegated Administrator(commadmin user create)(스키마 2)
Calendar Server 유틸리티(csuser enable)(스키마 1)

Delegated Administrator 콘솔

새 사용자와 기존 사용자를 모두 활성화할 수 있습니다.

새 사용자 — 사용자가 만들어지면 새 사용자 마법사를 사용하여 사용자에게 달력 서비스가 포함되어 있는 서비스 패키지를 할당합니다. 사용자는 자동으로 활성화됩니다.
기존 사용자 — 사용자 목록 페이지에서 사용자를 선택하고 서비스 패키지 지정 마법사를 사용하여 달력 서비스가 있는 서비스 패키지를 선택합니다. 사용자는 자동으로 활성화됩니다.

Delegated Administrator(commadmin user create)

사용자를 만들 때 다음 예와 같이 달력 서비스에 대해 해당 사용자를 활성화합니다.

commadmin user create jsmith -S cal

사용자 생성 시 달력 서비스에 대해 사용자를 활성화하지 않았다면 다음 예와 같이 나중에 modify 명령을 사용하여 사용자에게 달력 서비스를 추가할 수 있습니다.

commadmin user modify jsmith -S cal

Calendar Server 유틸리티(csuser enable)

사용자 항목을 만들 때 csuser create를 사용한 경우에는 사용자가 자동으로 활성화됩니다.

어떤 사용자가 달력을 사용할 수 없는 다른 사용자, 즉 기본 달력이 없는 사용자에게 요청을 보내는 경우 Calendar Server는 요청을 보낸 사용자에게 “Calendar not found”라는 오류를 반환합니다.

전자 메일 별칭 설정

달력 사용자에 대해 전자 메일 별칭을 설정해야 할 경우 사용자의 LDAP 항목에 mailalternateaddress 속성을 추가합니다. mail 속성은 기본 메일 주소를 제공하며 전자 메일 별칭에는 mailalternateaddress 속성이 사용됩니다. 두 속성 모두 메일 주소를 사용자의 달력 아이디(calid)와 매핑합니다.

Calendar Server 유틸리티 csattribute를 사용하거나 ldapmodify를 사용하여 LDAP를 직접 업데이트하여 이 속성을 추가할 수 있습니다. 다음 예에서는 csattribute를 사용합니다.

주 –

이 변경 사항을 사용 가능하게 하려면 별칭 테이블이나 구성을 재구축해 야 하는 경우도 있습니다. Messaging Server(또는 해당 전자 메일 제품)의 설명서 그리고 메일 서비스 변경에 대한 사이트별 설명서 및 절차를 참조하십시오. Messaging Server 설명서는 다음 웹 사이트에서 사용 가능합니다.http://docs.sun.com/coll/1312.1 및 http://docs.sun.com/coll/1407.1

예 14–1 csattribute를 사용하여 전자 메일 별칭 추가

예를 들어, 이름이 John Smith인 사용자에 대해 다음 값을 사용하여 mailalternateaddress 속성을 추가할 수 있습니다.

사용자 아이디(uid) 및 calid: johnsmith
password: John Smith의 비밀번호
전자 메일 주소: john.smith@sesta.com
전자 메일 별칭: johns@sesta.com and jsmith@sesta.com

csattribute -a mailalternateaddress=johns@sesta.com add johnsmith
 csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith

사용자의 달력 사용 가능 여부 확인

디렉토리 서버에 특정 사용자가 존재하며 Calendar Server 데이터에 액세스할 수 있는지 확인하려면 csuser 유틸리티 check 명령을 사용합니다.

예를 들어, jsmith가 달력을 사용할 수 있는지 확인하려면 다음 명령을 사용합니다.

csuser check jsmith

check 명령을 실행한 결과 사용자가 LDAP 디렉토리 서버에 존재하지 않는다면 해당 사용자에 대해 디렉토리 서버 항목을 만들어야 합니다.

LDAP에서 사용자 삭제

호스트된 도메인에서 사용자를 삭제할지, 호스트되지 않은 도메인에서 사용자를 삭제할지에 따라 다른 도구를 사용합니다.

주의 –

undelete 명령은 없습니다.

Delegated Administrator를 사용하여 호스트된 도메인에서 삭제된 사용자는 처음부터 새로 삭제한 후 다시 추가해야 합니다. 삭제가 수행될 때까지 사용자 이름을 다시 사용할 수 없습니다.

호스트되지 않은 도메인의 경우 호스트되지 않은 도메인에만 해당: 삭제됨으로 표시되어 있지만 제거되지 않은 사용자의 삭제 취소를 참조하십시오.

Delegated Administrator를 사용하여 스키마 2에서 사용자 삭제

Delegated Administrator 인터페이스를 사용하여 사용자를 삭제됨으로 표시할 수 있습니다. 그러나 Delegated Administrator 콘솔을 사용할 경우 LDAP에서 사용자를 삭제할 수 없습니다. 이 작업은 Delegated Administrator 유틸리티를 사용하여 수행해야 합니다. 다음 작업은 LDAP에서 사용자를 삭제하는 단계를 나열합니다. 마지막 단계가 완료될 때까지 사용자는 실제로 LDAP에서 제거되지 않습니다.

단계

사용자를 삭제됨으로 표시합니다.

Delegated Administrator 콘솔에서 다음을 수행합니다. 사용자 목록 페이지에서 삭제할 사용자를 선택하고 삭제를 누릅니다.

Delegated Administrator 유틸리티에서 다음을 수행합니다. commadmin user delete 명령을 사용합니다. 예를 들면 다음과 같습니다.
```
commadmin user delete -D chris -n siroe.com 
-w bolton -l jsmith
```
두 경우에 사용자 LDAP 항목의 icsStatus 속성은 active에서 deleted로 변경됩니다.

다음 예와 같이 Calendar Server 유틸리티 csclean을 사용하여 하나 또는 전체 도메인에서 삭제된 모든 사용자의 달력을 전부 제거합니다.

csclean clean “*”

또는 한 도메인에서 삭제된 모든 사용자에게 속해 있는 달력을 제거하려면 다음 예와 같이 실제 도메인을 지정합니다. csclean clean sesta.com

정보 –
사용자의 달력을 삭제하기 전에 LDAP에서 실수로 사용자를 제거한 경우 사용자 달력 관리의 설명대로 cscal 유틸리티를 사용하여 나중에 해당 사용자를 완전히 제거할 수 있습니다.

Delegated Administrator 유틸리티 명령 commadmin domain purge를 사용하여 삭제될 것으로 표시되어 있는 모든 사용자의 도메인을 제거합니다.

예를 들면 다음과 같습니다.
```
commadmin domain purge -D chris -d sesta.com -n siroe.com -w bolton
```
이 예에서 삭제됨으로 표시된 sesta.com의 모든 사용자가 삭제됩니다. 즉, 영구적으로 제거됩니다.

정보 –
때때로 이 유틸리티를 수동으로 실행하여 LDAP 디렉토리를 정리합니다. 이 명령에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

스키마 1 환경에서 사용자 삭제

지정된 사용자의 LDAP 항목과 사용자의 기본 달력을 제거하려면 delete 명령과 함께 Calendar Server 유틸리티 csuser를 사용합니다.

예를 들어, 사용자 jsmith에 대해 기본 달력과 LDAP 항목을 삭제하려면 다음 명령을 사용합니다.

csuser delete jsmith

이 사용자에게 속해 있는 다른 달력을 제거하려면 사용자 달력 관리에 설명된 것처럼 cscal을 사용해야 합니다.

호스트되지 않은 도메인에만 해당: 삭제됨으로 표시되어 있지만 제거되지 않은 사용자의 삭제 취소

호스트되지 않은 도메인의 경우 삭제됨으로 표시되어 있지만 아직 제거되지 않은 사용자의 삭제를 취소하려면 사용자의 icsStatus 속성을 active로 재설정해야 합니다. ldapmodify를 사용하여 LDAP 항목을 직접 변경하거나 Calendar Server 유틸리티 csattribute를 사용하여 이 작업을 수행할 수 있습니다.

그러나 호스트되지 않은 도메인에서 사용자를 일단 제거하면 백업에서 복원하는 방법으로만 LDAP 서버 정보를 복구할 수 있습니다.

사용자 속성 재설정

특정 사용자에 대한 모든 달력 LDAP 속성의 기본 설정을 복원하려면 csuser 유틸리티 reset 명령을 사용합니다.

예를 들어, jsmith의 모든 달력 속성을 기본 구성 설정으로 재설정하려면 다음 명령을 사용합니다.

csuser reset jsmith

주 –

달력 사용자를 재설정하면 모든 달력 속성이 icsCalendarUser(객체 클래스), icsSubscribed, icsCalendarOwned, icsCalendar 및 icsDWPHost(사용자가 LDAP CLD 설정에 있는 경우)를 포함한 사용자의 LDAP 항목에서 제거됩니다. Calendar Server 관리자는 사용자를 대신하여 달력을 만들 수 없습니다.

이 속성들은 다음과 같은 경우에 사용자의 LDAP 항목에 복원됩니다.

사용자가 다시 Calendar Server에 로그인한 경우
Calendar Server 관리자가 해당 사용자에 대해 csuser enable 명령을 실행한 경우(단, 이 경우에 icsDWPHost 속성은 복원되지 않음)

사용자 이름 변경

하나 이상의 사용자 아이디를 변경해야 할 경우 csrename 유틸리티를 실행합니다. 이 유틸리티는 다음과 같은 단계를 수행합니다.

Calendar Server LDAP 속성(ics 접두어가 붙은 속성)에서 사용자 아이디를 변환합니다. LDAP 디렉토리가 현재 위치에서 업데이트됩니다.
Calendar Server 데이터베이스 파일의 이벤트와 작업에서 사용자의 이름을 바꿉니다. 대상 디렉토리에 새 데이터베이스를 기록합니다. 기존 데이터베이스 파일은 수정되지 않습니다.

주 –

사용자 아이디를 하나라도 변경하면 데이터베이스 전체를 다시 써야 합 니다. 따라서 이 유틸리티는 실행하기 번거롭습니다.

csrename 유틸리티 실행 방법에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

사용자가 공용 쓰기 가능한 달력을 가질 수 없도록 설정

단계

구성을 변경할 권한을 가지고 관리자로 로그인합니다.

/etc/opt/ SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 표에 표시된 ics.conf 매개 변수 중 하나 이상을 편집하십시오.

매개 변수	설명 및 기본값
`service.wcap.` `allowpublicwritablecalendars`	사용자가 공용 쓰기 가능한 달력을 가질 수 있습니다. 기본적으로 활성화됩니다(`“yes”`로 설정).

매개 변수

설명 및 기본값

service.wcap.

allowpublicwritablecalendars

사용자가 공용 쓰기 가능한 달력을 가질 수 있습니다. 기본적으로 활성화됩니다(“yes”로 설정).

파일을 ics.conf로 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

자원 관리

추가한 자원은 csresource를 사용하여 관리할 수 있습니다.

자원 나열

단계

/sbin 디렉토리로 변경합니다.

csresource list 명령을 사용하여 하나 또는 모든 자원을 나열합니다.

예를 들어, 모든 자원에 대한 모든 정보를 나열합니다.

./csresource -v list

자원 활성화

단계

/sbin 디렉토리로 변경합니다.

csresource enable 명령을 사용하여 하나 이상의 자원을 활성화합니다.

예를 들어, ConfRm12 자원을 활성화하려면 다음 명령을 사용합니다.

./csresource -v enable ConfRm12

자원 비활성화

단계

/sbin 디렉토리로 변경합니다.

csresource disable 명령을 사용하여 하나 이상의 자원을 비활성화합니다. 예를 들어, ConfRm12 자원을 비활성화하려면 다음 명령을 사용합니다.

./csresource -v disable ConfRm12

자원 삭제

단계

/sbin 디렉토리로 변경합니다.

csresource delete 명령을 사용하여 하나 이상의 자원을 삭제합니다. 예를 들어, ConfRm12 자원을 삭제하려면 다음 명령을 사용합니다.

./csresource -v delete ConfRm12

자원 전자 메일의 Bitbucket 채널 설정

이 절에는 Messaging Server와 Sendmail에 대해 bitbucket 채널을 설정하는 지침이 포함되어 있습니다. bitbucket 채널은 자원 달력에 대해 생성된 전자 메일을 삭제하는 방법 중 하나입니다. 이 예에서는 sesta.com 서버에 있는 Room100이라는 자원을 사용합니다. bitbucket 채널(또는 동등한 것)을 설정하지 않은 경우 자원 달력에 보낸 전자 메일 메시지를 정기적으로 삭제해야 합니다.

이절은 다음 절차로 구성되어 있습니다.

Messaging Server Bitbucket 채널 설정

단계

bitbucket 채널이 imta.cnf 파일에 정의되어 있는지 확인합니다.

메시지를 bitbucket 채널로 전송하려면 csattribute 유틸리티를 사용하여 해당 자원의 전자 메일 주소를 만듭니다.
csattribute -a mail=Room100@bitbucket.sesta.com add Room100

Sendmail Bitbucket 채널 설정

단계

해당 호스트의 /etc/aliases 파일에 다음과 같이 항목을 추가합니다.
Resource/Conference room aliases Room100: /dev/null

csattribute 유틸리티를 사용하여 해당 자원의 전자 메일 주소를 LDAP 디렉토리에 추가합니다.
csattribute -a mail=Room100@sesta.com add Room100

사용자 및 자원 LDAP 속성 관리

csattribute 유틸리티 또는 ldapmodify를 사용하여 Calendar Server에서 사용되는 LDAP 속성을 관리합니다. csattribute로 속성을 나열, 추가 또는 삭제할 수 있습니다. 속성을 수정하려면 ldapmodify를 사용합니다. 이 절은 다음 내용으로 구성되어 있습니다.

LDAP 항목 속성 나열

단계

설치 중에 지정한 Calendar Server가 실행되고 있는 사용자와 그룹(icsuser, icsgroup 등) 또는 root로 로그인된 상태이어야 합니다.

/sbin 디렉토리로 변경합니다.

csattribute list 명령을 사용하여 사용자 또는 자원의 속성을 나열합니다. 예를 들어, tchang@sesta.com에 대한 속성을 나열하려면다음 명령을 실행합니다.

./csattribute -t user -d sesta.com list tchang

LDAP 항목 속성 추가

단계

설치 중에 지정한 Calendar Server가 실행되고 있는 사용자와 그룹(icsuser, icsgroup 등) 또는 root로 로그인된 상태이어야 합니다.

이 속성 변경이 즉시 인식되게 하려면 Calendar Server를 중지합니다. 그렇지 않으면 Calendar Server를 중지할 필요가 없습니다.

/sbin 디렉토리로 변경합니다.

csattribute add 명령을 사용하여 속성을 사용자 또는 자원에 추가합니다. 예를 들어, LDAP 속성 icsCalendar를 Conference_Schedule이라는 값으로 tchang 사용자에서 삭제하려면 다음 명령을 사용합니다.

./csattribute -a icsCalendar=Conference_Schedule add tchang@sesta.com

LDAP 항목 속성 삭제

단계

설치 중에 지정한 Calendar Server가 실행되고 있는 사용자와 그룹(icsuser, icsgroup 등) 또는 root로 로그인된 상태이어야 합니다.

이 속성 변경이 즉시 인식되게 하려면 Calendar Server를 중지합니다. 그렇지 않으면 Calendar Server를 중지할 필요가 없습니다.

/sbin 디렉토리로 변경합니다.

csattribute delete 명령을 사용하여 사용자 또는 자원에서 속성을 삭제합니다. 예를 들어, LDAP 속성 icsCalendar를 Conference_Schedule이라는 값으로 tchang 사용자에서 삭제하려면 다음 명령을 사용합니다.
```
./csattribute -a icsCalendar=Conference_Schedule -t user 
   -d sesta.com delete tchang
```

LDAP 항목 속성 수정

LDAP 항목 속성을 수정하려면 ldapmodify를 사용합니다. 예를 들어, 다음과 같이 uid=tchang인 사용자의 상태를 ldapmodify를 통해 변경합니다.

dn:uid=tchang,ou=people,o=sesta.com
 changetype: modify
 add: objectclass
 objectClass: icsCalendarUser
 add: icsStatus
 icsStatus: active

주 –

사이트에서 LDAP CLD 플러그 인을 사용하는 경우에는 csattribute를 사용하여 icsDWPHost 값을 변경함으로써 사용자 달력을 백엔드 호스트에서 다른 호스트로 이동하지 않아야 합니다. icsDWPHost를 수정하면 새 백엔드 호스트에 달력이 만들어지지 않습니다. 한 백엔드 서버에서 다른 백엔드 서버로 달력을 이동하는 방법에 대한 자세한 내용은 사용자 달력 관리를 참조하십시오.

15장 달력 관리

이 장은 Calendar Server 명령줄 유틸리티를 사용하여 달력을 생성하고 관리하는 방법을 설명하는 다음 내용으로 구성되어 있습니다.

달력 관리 개요

Delegated Administrator로는 달력을 만들거나 관리할 수 없습니다. 부록 D, Calendar Server 명령줄 유틸리티 참조 에 설명된 Calendar Server 유틸리티를 사용해야 합니다.

달력을 만들기 전에 다음 정보를 알고 있어야 합니다.

사용자 달력과 자원 달력이라는 두 가지 유형의 달력이 있습니다.

사용자 달력은 사람의 활동을 예약할 때 사용됩니다. 자원 달력은 회의실 비디오 장치 등 무생물 객체의 예약에 사용됩니다.
두 유형의 달력은 모두 고유 달력 아이디(calid)로 식별됩니다.
cscal을 사용하여 사용자 달력을 만듭니다. (또는 로그인 시 자동 제공을 허용할 수 있습니다.) 사용자 달력 자동 생성
csresource를 사용하여 자원 달력을 만듭니다. (자원 달력 자동 제공 기능은 사용할 수 없습니다.)

cscal 또는 csresource를 실행하려면 Calendar Server가 실행되는 시스템에 대해 관리 권한을 가진 사용자로 로그인해야 합니다. 이러한 명령들은 /opt/SUNWics5/cal/sbin 디렉토리에서 실행해야 합니다. 즉 경로를 지정하여 다른 디렉토리에서 실행할 수 없으며 반드시 sbin 디렉토리로 변경해야 합니다.

달력 고유 아이디(calid) 만들기

Calendar Server 데이터베이스의 각 달력은 고유한 달력 아이디, 즉 calid로 식별됩니다. 달력을 만들 때에는 calid를 지정해야 합니다.

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

Calid 구문

데이터베이스의 각 달력은 고유 달력 아이디( calid)로 식별됩니다. 다음 calid 구문은 세 부분으로 이루어집니다.

userid[@domain][:calendar-name]

세 부분은 다음과 같습니다.

userid

이 Calendar Server 인스턴스의 도메인에 대해 고유한 사용자 아이디입니다.

domain

사용자의 도메인 이름입니다.

호스트된 도메인이 없는 경우에는 사용자가 있는 도메인이 명확하기 때문에 도메인 부분이 선택 사항이 됩니다.

호스트된 도메인이 있는 경우에는 도메인 부분을 지정하지 않으면 Calendar Server에서 해당 도메인의 ics.conf 매개 변수 service.defaultdomain에 지정된 값을 사용합니다. 사용자가 기본 도메인에 있지 않은 경우에는 도메인 부분을 지정해야 합니다.

호스트된 도메인(가상 도메인이라고도 함)에 대한 자세한 내용은 11 장, 호스트된 도메인 설정과 13 장, 호스트된 도메인 관리을 참조하십시오.

calendar-name

특정 사용자에게 고유한 선택적 달력 이름입니다. 소유자의 기본 달력은 하나뿐이지만 다양한 목적으로 다른 달력을 가질 수도 있습니다. 기본 달력이 아닌 각 달력은 달력 이름으로 구분합니다. 예를 들어 사용자 John Doe의 uid가 jdoe이면 기본 달력은 jdoe@sesta.com이 될 수 있습니다. 그가 코치를 맡고 있는 Little League 팀의 야구 시합 기록을 남기기 위해 사용하는 보조 달력은 jdoe@sesta.com:baseball과 같은 calid를 가질 수 있습니다.

달력 아이디 만들기 규칙

calid를 만들 때에는 다음 규칙을 염두에 두어야 합니다.

달력 아이디는 대소문자를 구분합니다. 예를 들어, JSMITH는 jsmith와 다르게 인식됩니다. (이러한 구분은 대소문자를 구분하지 않는 전자 메일 주소와 다릅니다. 예를 들어, jsmith@sesta.com은 JSMITH@SESTA.COM과 동일한 것으로 인식됩니다.)
달력 아이디는 공백을 포함할 수 없으며 다음 문자만 사용할 수 있습니다.
- 알파벳(a-z, A-Z) 및 숫자(0-9)(비 ASCII 문자 사용 불가)
- 특수 문자: 마침표(.), 밑줄(_), 하이픈 또는 대시(-), at 기호(@), 아포스트로피('), 백분율 기호(%), 슬래시(/), 느낌표(!)
  
  사용자 아이디는 calid의 일부이므로 공백을 포함할 수 없습니다(예: jsmith). 사용자 아이디에 공백이 포함되어 있을 경우 Calendar Server에 로그인할 수 있지만, 이 공백이 나중에 문제를 일으킬 수 있습니다.
  
  올바른 달력 아이디의 예:
```
jsmithjsmith:private_calendar
jsmith@calendar.sesta.com:new-cal
```

호스트되지 않은 calid를 호스트된 도메인 형식의 calid로 변환

도메인을 호스트하기 전에 만든 calid가 있으며 호스트되지 않은 도메인 calid를 호스트된 도메인 calid로 변환하려면 csvdmig 유틸리티를 사용하여 기존의 calid에 도메인 부분을 추가할 수 있습니다. 이 유틸리티 사용 방법은 csvdmig를 참조하십시오.

사용자 달력 자동 생성

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

자동 달력 생성 기능

Calendar Server는 사용자가 처음 로그인할 때 사용자의 기본 달력을 자동으로 생성합니다. 이 기능을 자동 제공이라고 합니다. 자동 제공은 기본적으로 활성화됩니다. 단, 자동 제공은 사용자 달력에만 적용되며 자원 달력은 명시적으로 만들어야 합니다.

Calendar Server에서는 동일한 이름의 달력이 이미 존재하지 않는 한 사용자 아이디를 사용하여 새 기본 달력의 달력 아이디(calid)를 만듭니다.

예를 들어, 사용자 아이디가 jsmith인 John Smith가 처음으로 Calendar Server에 로그인하면 Calendar Server는 자동으로 calid가 jsmith인 기본 달력을 만듭니다. 그 후에 John Smith가 만드는 달력의 calid에는 jsmith:가 앞에 추가됩니다. 예를 들어, John Smith가 나중에 이름이 meetings인 새 달력을 만들면 호스트되지 않은 환경에서 새 달력의 calid는 jsmith:meetings가 됩니다.

주 –

기본 달력이 없는 사용자를 참가자로 지정하면 Calendar Server에서 달력을 찾을 수 없습니다 오류를 반환합니다.

자동 제공을 활성화하려면

자동 제공은 기본적으로 활성화됩니다. 그러나 비활성화한 후에는 다음 단계에 따라 다시 활성화해야 합니다.

단계

구성을 변경할 수 있는 권한을 가진 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 표에 표시된 것처럼 Calendar Server 구성 파일 ics.conf에서 다음 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명 및 기본값
`local.autoprovision`	“yes”로 설정하면 사용자가 처음으로 로그인할 때 자동으로 기본 달력이 생성됩니다. 자동 제공은 기본적으로 활성화됩니다. 이 기능을 사용하지 않으려면 값을 “no”로 설정하십시오.

매개 변수

설명 및 기본값

local.autoprovision

“yes”로 설정하면 사용자가 처음으로 로그인할 때 자동으로 기본 달력이 생성됩니다. 자동 제공은 기본적으로 활성화됩니다.

이 기능을 사용하지 않으려면 값을 “no”로 설정하십시오.

달력에 대해 사용자의 LDAP 항목이 활성화되어 있는지 확인합니다.

항목에는 icsCalendarUser 객체 클래스가 포함되어 있어야 합니다. 사용자의 LDAP 항목에 클래스가 없는 경우에는 추가합니다.

사이트에서 호스트된 도메인을 사용하고 있는 경우 자동 제공을 작동하기 전에 사용자의 도메인에서 달력이 활성화되어 있어야 합니다. 도메인 항목에는 icsCalendarDomain 객체 클래스가 포함되어 있어야 합니다.

파일을 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

자동 제공을 비활성화하려면

단계

구성을 변경할 권한을 가지고 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 표에 표시된 것처럼 Calendar Server 구성 파일 ics.conf에서 다음 매개 변수 중 하나 이상을 편집합니다.

매개 변수

설명 및 기본값

local.autoprovision

매개변수를 no로 설정하면 사용자 달력의 자동 제공이 비활성화됩니다.

파일을 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

주 –
자동 제공이 비활성화된 경우에 사용자가 성공적으로 로그인하려면 해당 사용자의 달력을 명시적으로 만들어야 합니다.

매개 변수	설명 및 기본값
`local.autoprovision`	매개변수를 `no`로 설정하면 사용자 달력의 자동 제공이 비활성화됩니다.

달력 액세스 제어

Calendar Server에서는 액세스 제어 목록(ACL)을 사용하여 달력, 달력 등록 정보 그리고 이벤트, 수행할 작업과 같은 달력 구성 요소의 액세스 제어를 결정합니다.

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

액세스 제어용 구성 매개 변수

다음 표에서는 Calendar Server가 액세스 제어에 사용하는 ics.conf 파일의 구성 매개 변수를 설명합니다.

표 15–1 액세스 제어 구성 매개 변수


매개 변수	설명
`calstore.calendar.default.acl`	사용자가 달력을 만들 때 사용하는 기본 액세스 제어 설정을 지정합니다. 기본값은 다음과 같습니다. `"@@o^a^r^g;@@o^c^wdeic^g;` `@^a^fs^g;@^c^^g;@^p^r^g"`
`calstore.calendar.owner.acl`	달력 소유자에 대한 기본 액세스 제어 설정을 지정합니다. 기본값은 다음과 같습니다. `"@@o^a^rsf^g;@@o^c^wdeic^g"`
`resource.default.acl`	자원 달력이 만들어질 때 사용하는 기본 액세스 제어 설정을 지정합니다. 기본값은 다음과 같습니다. `"@@o^a^r^g;@@o^c^wdeic^g;` `@^a^rsf^g"`

공개 및 개인 이벤트와 태스크 필터

새 이벤트나 태스크를 만들 때 사용자는 공개, 개인 또는 시간 및 날짜만(비밀) 이벤트나 태스크인지 지정할 수 있습니다.

공개: 사용자의 달력에 대해 읽기 권한을 가진 누구라도 해당 이벤트나 태스크를 볼 수 있습니다.
개인: 달력의 소유자만 해당 이벤트나 태스크를 볼 수 있습니다.
시간 및 날짜만: 비밀 이벤트 및 태스크입니다. 달력의 소유자만 해당 이벤트나 태스크를 볼 수 있습니다. 달력에 대해 읽기 권한을 가진 다른 사용자는 해당 달력에서 제목이 없는 이벤트만 볼 수 있으며 이 제목은 활성 링크가 아닙니다.

calstore.filterprivateevents는 Calendar Server가 개인 이벤트, 시간 및 날짜만 이벤트(비밀) 및 태스크를 필터링(인식)할 것인지 여부를 결정합니다. 기본적으로 이 매개 변수는 "yes"로 설정됩니다. calstore.filterprivateevents를 "no"로 설정한 경우 Calendar Server는 개인 그리고 시간 및 날짜만 이벤트와 태스크가 공개 이벤트와 태스크인 것처럼 취급합니다.

액세스 제어용 명령줄 유틸리티

다음 표에서는 Calendar Server 액세스 제어를 위해 ACL을 설정하거나 수정할 수 있게 하는 명령줄 유틸리티를 설명합니다.

표 15–2 액세스 제어용 명령줄 유틸리티


유틸리티	설명
`cscal`	특정 사용자 또는 자원 달력의 ACL을 설정하려면 `create` 및 `modify` 명령을 `-a` 옵션과 함께 사용합니다.
`csresource`	스키마 1 모드에서 `csresource`를 사용하여 자원 달력을 만드는 경우에는 `csresource` 유틸리티와 `-a` 옵션을 함께 사용하여 자원 달력의 ACL을 설정합니다.
`commadmin user` `csuser`	스키마 2 `commadmin` 유틸리티를 사용하여 사용자가 달력을 만들 때 사용되는 기본 ACL을 변경합니다. 스키마 1 `csuser` 유틸리티를 `-a` 옵션과 함께 사용하여 사용자가 달력을 만들 때 사용되는 기본 ACL을 변경합니다.

주 –

Delegated Administrator 콘솔에서 액세스 권한을 설정하려면 Organization Properties 페이지나 Create New Organization 마법사에서 Advanced Rights 버튼을 눌러 이 콘솔에서 관리할 수 있는 액세스 권한 목록을 봅니다.

달력 만들기

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

cscal을 사용하여 사용자 달력 만들기

새 달력을 만들려면 cscal 유틸리티 create 명령을 사용합니다. 사용자 또는 자원 항목이 LDAP 디렉토리에 이미 있어야 합니다. LDAP 디렉토리에 사용자 및 자원을 추가하는 방법에 대한 자세한 내용은 14 장, 사용자 및 자원 관리을 참조하십시오.

사이트에서 LDAP 달력 조회 데이터베이스(CLD) 플러그 인을 사용하는 경우에는 특정 사용자 또는 자원에 해당하는 모든 달력을 사용자 또는 자원 항목의 icsDWPHost LDAP 속성에 표시된 서버와 동일한 백엔드 서버에 만들어야 합니다. 다른 백엔드 서버에서 달력을 만들려고 하면 cscal 유틸리티는 오류를 반환합니다. LDAP CLD 플러그 인에 대한 자세한 내용은 6 장, 여러 시스템에서 달력 데이터베이스 배포 구성을 참조하십시오.

예를 들어, 달력 아이디(calid) jsmith로 새 달력을 만들려면 다음 명령을 사용합니다.

cscal -o jsmith -n JohnSmithCalendar create jsmith

여기서,

-o jsmith는 새 달력의 주 소유자를 나타냅니다.
-n JohnSmithCalendar는 새 달력의 조회 가능한 이름을 지정합니다.
기본 액세스 제어 설정은 ics.conf 파일의 calstore.calendar.default.acl에서 정의합니다.

조회 가능한 이름 Hobbies를 가지고 John Smith가 소유하며 그룹 예약의 기본 액세스 제어 설정을 사용하는 달력을 만들려면 다음 명령을 사용합니다.

cscal -n Hobbies -o jsmith create Personal

여기서,

-n Hobbies는 조회 가능한 달력 이름을 나타냅니다.
-o jsmith는 주 소유자의 사용자 아이디를 나타냅니다.
Personal은 달력 아이디(calid)의 두 번째 부분으로 사용됩니다. 예를 들면 다음과 같습니다. jsmith:Personal

다음 예에서는 이전 예와 비슷하게 새 달력을 만들지만, 이 달력을 sports라는 이름의 범주와 연관시켜 이중 예약을 가능하게 하고 Ron Jones를 또 다른 소유자로 지정합니다.

cscal -n Hobbies -o jsmith -g sports -k yes -y rjones create Personal

여기서,

-g sports는 이 달력을 sports라는 범주와 연관시킵니다.
-y rjones는 달력의 또 다른 소유자를 지정합니다.
-k yes는 이중 예약을 가능하게 합니다. (-k no 이면 이중 예약 사용 불가)

다음 예에서는 이전 예와 비슷하게 달력을 만들지만, 그룹 일정에 대한 특별한 액세스 제어 설정도 지정합니다.

cscal -n Hobbies -o jsmith -a "@@o^a^sfr^g" create Personal

여기서 -a "@@o^a^sfr^g"는 다른 소유자들에게 이 달력의 구성 요소 및 달력 등록 정보에 대해 그룹 예약을 위한 예약, 사용 가능/사용 중 그리고 읽기 액세스 권한을 부여합니다.

자원 달력 만들기 준비

자원 달력은 회의실, 노트북 컴퓨터, 오버헤드 영사기 및 기타 장치와 같이 예약할 수 있는 물건에 연관됩니다. 자원 달력에는 액세스 제어 목록이 필요합니다.

표 15–3에 표시된 것처럼 ics.conf 파일에 있는 두 개의 구성 매개 변수가 자원 달력에 적용됩니다.

resource.default.acl– 기본 액세스 제어 목록
resource.allow.doublebook– 이중 예약을 허용 또는 금지하는 매개 변수

사용자 달력을 이중 예약하는 것은 좋을 수 있지만 자원을 이중 예약하는 것은 좋지 않으므로 기본값은 "no"입니다. 하지만 필요한 경우에는 "yes"로 값을 변경할 수 있습니다.

이 매개 변수의 기본값을 변경하려면(표 15–3 참조) ics.conf 파일을 편집합니다. 기본값의 변경 사항은 새 자원 달력에만 적용되며 기존 자원의 값은 변경되지 않습니다.

스키마 1의 경우 Calendar Server 유틸리티 cscal을 사용하여 기존 자원 달력 값을 변경합니다. csresource 유틸리티에는 modify 명령이 없습니다.

스키마 2의 경우 Delegated Administrator 유틸리티 명령 commadmin resource modify를 사용합니다. Delegated Administrator 콘솔에서는 달력 자원에 대해 해당 값을 변경할 수 없습니다.

주 –

Calendar Server 알림 소프트웨어는 자원이 아닌 사용자에게만 알림을 보내도록 프로그램되어 있습니다.

표 15–3 ics.conf 파일의 자원 달력 구성 매개 변수


매개 변수	설명 및 기본값
`resource.default.acl`	이 매개 변수는 자원 달력이 만들어질 때 사용되는 기본 액세스 제어 권한을 결정합니다. 기본 권한은 다음 액세스 제어 목록(ACL)에서 지정합니다. `"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"` 이 ACL은 모든 달력 사용자에게 구성 요소와 등록 정보를 포함하여 달력에 대해 읽기, 예약 및 사용 가능/사용 중 액세스를 부여합니다. 자원의 사용 권한을 변경하려면 `csresource` 유틸리티 create 명령을 사용하여 달력을 만들 때 `-a` 옵션을 사용합니다.
`resource.allow.doublebook`	이 매개 변수는 자원 달력에 이중 예약이 허용되는지 여부를 결정합니다. 이중 예약을 사용하면 자원 달력은 같은 시간에 둘 이상의 이벤트를 예약할 수 있습니다. 기본값은 `"no"`이며, 즉 이중 예약을 허용하지 않습니다. 자원 달력에서 이중 예약을 허용하려면 `csresource` 유틸리티 create 명령을 사용하여 달력을 만들 때 `-k` 옵션을 사용합니다.

자원 달력 만들기

Calendar Server에는 자원 달력에 대한 자동 제공 기능이 제공되지 않습니다. 사이트에 필요한 모든 자원에 대해 다음 방법을 사용해야 합니다.

스키마 1의 경우 Calendar Server 유틸리티 명령 csresource create를 사용합니다.

이 유틸리티는 자원에 대한 LDAP 항목과 기본 달력을 만듭니다.

예를 들어, 기본 설정을 지정하여 자원 LDAP 항목과 달력 아이디가 aud100이고 표시 가능 이름이 Auditorium(LDAP cn 속성)인 달력을 만들려면 다음 명령을 사용하십시오.
```
csresource -m aud100@siroe.com -c aud100 create Auditorium
```
스키마 2의 경우 Delegated Administrator 유틸리티 명령 commadmin resource create 조합을 사용하여 LDAP 항목을 만듭니다. 그런 후 Calendar Server 유틸리티 명령 csresource create를 사용하여 기본 달력을 만듭니다.
스키마 2의 경우 Delegated Administration 콘솔을 사용하여 자원 LDAP 항목을 만듭니다. 그런 후 Calendar Server 유틸리티 명령 csresource create를 사용하여 기본 달력을 만듭니다.

이 콘솔에서 LDAP 자원을 만들려면 조직 목록에서 이 자원이 위치할 조직을 선택합니다. 이 조직에 대한 달력 자원 페이지에서 새로 만들기를 눌러 새 달력 자원 만들기 마법사를 실행합니다.

주 –

자원에 대해 기존 LDAP 항목이 있는 경우 csresource는 달력만 만듭니다. 중복된 LDAP 항목은 만들지 않습니다.

Delegated Administrator 유틸리티에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

Delegated Administrator 콘솔에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

csresource에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

자원 달력의 이중 예약

기본적으로 Calendar Server는 자원 달력의 이중 예약(resource.allow.doublebook 매개 변수)을 허용하지 않습니다. 이 기본 설정은 회의실과 장비와 같은 자원에 대한 예약 충돌을 방지합니다. 그러나 자원 달력에 대해 이중 예약을 허용하려면 달력을 만들 때 csresource -k 옵션을 “yes”로 설정합니다.

다음 명령은 자원 LDAP 항목 및 달력을 만들지만 -k 옵션은 달력에 대해 이중 예약을 허용하고, -o 옵션은 bkamdar을 달력의 소유자로 지정하고, -y 옵션은 또 다른 소유자로 jsmith를 지정합니다.

csresource -m aud100@siroe.com -c aud100 -k yes
    -o bkamdar -y jsmith create Auditorium

자원 달력에 대한 액세스 제한

특정 자원의 예약 가능자를 제어하려면 자원 달력에 대해 쓰기 액세스를 갖는 사용자를 제한하는 방법을 고려할 수 있습니다. 예를 들어, 특정 사용자들만 회의실이나 장비를 예약하게 할 수 있습니다.

자원 달력의 소유자를 지정하지 않으면 ics.conf 파일의 service.admin.calmaster.userid 매개 변수에서 값을 가져옵니다.

사용자 달력 관리

사용자 달력이 만들어지면 cscal 유틸리티를 사용하여 다음 관리 작업을 수행할 수 있습니다.

달력 표시

모든 달력, 사용자가 소유한 모든 달력 또는 특정 달력의 등록 정보를 표시하려면 cscal 유틸리티 list 명령을 사용합니다.

예를 들어, 달력 데이터베이스의 모든 달력을 나열하려면 다음 명령을 사용합니다.

cscal list

jsmith가 소유한 모든 달력을 나열하려면 다음 명령을 사용합니다.

cscal -o jsmith list

달력 아이디가 jsmith:meetings인 달력의 모든 등록 정보를 나열하려면 다음 명령을 사용합니다.

cscal -v list jsmith:meetings

달력 삭제

Calendar Server에서 하나 이상의 달력을 삭제하려면 cscal 유틸리티 delete 명령을 사용합니다. 이 유틸리티는 달력을 삭제하지만 사용자를 디렉토리 서버에서 삭제하지는 않습니다.

주의 –

delete 명령은 달력 데이터베이스로부터 모든 달력 정보를 제거하며 실행 취소할 수 없습니다. 달력을 삭제한 후에는 백업된 경우에만 달력 데이터를 복구할 수 있습니다. 자세한 내용은 17 장, Calendar Server 데이터 백업 및 복원 을 참조하십시오.

cscal 유틸리티를 사용하여 하나의 달력 또는 여러 개의 달력을 삭제할 수 있습니다.

예를 들어, 달력 아이디가 jsmith:meetings인 달력을 삭제하려면 다음 명령을 사용합니다.

cscal delete jsmith:meetings

기본 소유자가 jsmith인 모든 달력을 삭제하려면 다음 명령을 사용합니다.

cscal -o jsmith delete

삭제된 사용자의 달력 제거

Calendar Server 유틸리티 명령 csuser delete나 Delegated Administrator 콘솔 또는 유틸리티를 사용하여 하나 이상의 사용자를 삭제한 경우 해당 사용자가 소유한 달력이 데이터베이스에 계속 남아 있을 수 있습니다.

따라서 다음 두 가지 방법 중 하나를 사용하여 사용자의 달력을 제거해야 합니다. 사용자를 삭제한 방법에 따라 달력 삭제 방법이 달라집니다.

csuser

csuser 유틸리티는 LDAP 디렉토리에서 사용자를 제거하고 사용자의 기본 달력을 제거하지만 사용자가 소유한 다른 달력은 제거하지 않습니다. cscal을 사용하여 이러한 달력을 제거하는 방법에 대한 자세한 내용은 csuser를 사용하여 삭제한 사용자의 달력을 모두 제거하려면을 참조하십시오.

Delegated Administrator

Delegated Administrator로 달력을 제거할 수는 없습니다. Delegated Administrator를 사용하여 사용자를 위임 대상으로 표시한 후 Calendar Server 유틸리티 csclean을 사용하여 위임 대상으로 표시된 사용자의 달력을 제거합니다.

csclean을 사용하여 삭제된 사용자의 달력을 제거하는 방법에 대한 자세한 내용은 Delegated Administrator로 삭제한 사용자의 달력을 모두 제거하려면을 참조하십시오.

Delegated Administrator 유틸리티 사용에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

Delegated Administrator 콘솔 사용에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

csuser를 사용하여 삭제한 사용자의 달력을 모두 제거하려면

단계

cscal list를 실행하여 삭제된 소유자 uid의 달력을 모두 찾습니다.

cscal -o owner list

cscal을 사용하여 해당 소유자의 달력을 모두 제거합니다.

cscal -o owner delete

csuser list를 다시 실행하여 달력이 모두 제거되었는지 확인합니다.

주 –
commadmin을 사용하여 사용자를 삭제됨으로 표시했고 사용자의 LDAP 항목이 이미 지워진 경우에 한해 이 절차를 사용합니다.

Delegated Administrator로 삭제한 사용자의 달력을 모두 제거하려면

Delegated Administrator로 달력을 제거할 수는 없습니다. csclean 유틸리티를 사용하여 Delegated Administrator에서 삭제됨으로 표시된 모든 사용자의 달력을 모두 제거합니다.

단계

csclean을 사용하여 삭제됨으로 표시되었지만 아직 지워지지 않은 사용자의 달력을 모두 제거합니다.

예를 들어, 지난 10일 동안 sesta.com 도메인에서 삭제됨으로 표시된 사용자의 달력을 모두 제거하려면 다음 명령을 사용합니다.
```
csclean -g 10 clean sesta.com
```

사용자가 이미 LDAP에서 지워진 경우에는 cscal을 사용해야 합니다.

자세한 내용은 csuser를 사용하여 삭제한 사용자의 달력을 모두 제거하려면을 참조하십시오.

달력 활성화

사용자가 달력에 액세스할 수 있게 달력을 활성화하려면 cscal 유틸리티 enable 명령을 사용합니다.

예를 들어, 기본 구성 설정을 사용하여 jsmith:meetings 달력을 활성화하려면 다음 명령을 사용합니다.

cscal enable jsmith:meetings

jsmith:meetings 달력을 활성화하되 이중 예약을 허용하지 않으려면 다음 명령을 사용합니다.

cscal -k no enable jsmith:meetings

달력 비활성화

사용자가 달력에 액세스할 수 없게 하려면 cscal 유틸리티 disable 명령을 사용합니다. disable 명령은 사용자가 달력에 액세스할 수 없게 하지만, 달력 데이터베이스에서 정보를 제거하지는 않습니다.

예를 들어, 사용자가 jsmith:meetings에 액세스할 수 없게 하려면 다음 명령을 사용합니다.

cscal disable jsmith:meetings

달력 등록 정보 수정

달력 등록 정보를 수정하려면 cscal 유틸리티 modify 명령을 사용합니다.

예를 들어, AllAdmins의 그룹 예약 액세스 제어 설정을 변경하고 RJones를 다른 소유자로 지정하려면 다음을 수행합니다.

cscal -a "@@o^c^wd^g" -y RJones modify AllAdmins

여기서,

-a "@@o^c^wd^g"는 소유자에게 AllAdmins의 구성 요소(이벤트 및 태스크)에 대한 쓰기 및 삭제 액세스 권한을 부여합니다.
-y RJones는 이 사용자 아이디를 또 다른 소유자로 지정합니다.

달력에서 등록 정보 제거

달력에서 등록 정보 값을 제거하려면 cscal 유틸리티 modify 명령을 사용하고 옵션 값으로 큰따옴표( "") 2개를 지정합니다.

예를 들어, jsmith:meetings에서 설명을 제거하려면 다음을 수행합니다.

cscal -d "" modify jsmith:meetings

jsmith:meetings에서 모든 범주를 제거하려면 다음 명령을 사용합니다.

cscal -g "" modify jsmith:meetings

jsmith:meetings에서 다른 소유자를 제거하려면 다음 명령을 사용합니다.

cscal -y "" modify jsmith:meetings

손실된 기본 달력 복구

사용자의 기본 달력이 Communications Express Current Calendar 드롭다운 목록에 나타나지 않지만 데이터베이스에는 아직 존재할 경우, 사용자의 LDAP 항목에서 다음 속성을 업데이트하여 달력을 복구할 수 있습니다.

icsCalendar:default_calid
icsSubscribed:default_calid

여기서 default_calid는 사용자의 기본 달력 아이디(calid)입니다.

스키마 2의 경우 다음 방법 중 하나를 사용하여 속성을 업데이트합니다.

ldapmodify Directory Server 유틸리티를 사용합니다.
Calendar Server 유틸리티 명령 csuser reset을 사용합니다.
Delegated Administrator 유틸리티 명령 commadmin user modify를 사용합니다.
Delegated Administrator 콘솔에서 을 사용하여 User Properties 페이지를 편집하여 기본 달력 이름을 추가합니다.

스키마 1의 경우 csattribute add 명령을 사용하여 속성을 업데이트합니다.

다른 백엔드 서버로 달력을 이동하려면

사용자 달력을 한 백엔드 서버에서 다른 백엔드 서버로 옮기려면 다음 단계를 수행합니다.

단계

원본 서버에서 csuser 유틸리티를 사용하여 달력 사용자를 비활성화합니다. 예를 들어, 사용자 아이디와 calid bkamdar이 있는 사용자를 사용 불가능하게 하려면 다음 명령을 사용합니다.
csuser disable bkamdar

원본 서버에서 csexport 유틸리티를 사용하여 달력 데이터베이스에서 파일로 각 사용자의 달력을 내보냅니다. 예를 들면 다음과 같습니다.
csexport -c bkamdar calendar bkamdar.ics

내보낸 달력(*.ics) 파일을 원본 서버에서 새 서버로 복사합니다.

새 서버에서 내보낸 각 달력에 대해 csimport 유틸리티를 사용하여 파일에서 달력 데이터베이스로 달력을 가져옵니다. 예를 들면 다음과 같습니다.
csimport -c bkamdar calendar bkamdar.ics

LDAP 디렉토리 서버에서 csattribute 유틸리티를 사용하여 새 백엔드 서버를 가리키도록 달력 소유자의 icsDWPHost LDAP 속성을 업데이트합니다. 속성을 업데이트하려면 먼저 해당 속성을 삭제한 다음 새 값으로 그 속성을 추가해야 합니다. 예를 들어, 새 서버 이름을 sesta.com으로 설정하려면 다음 명령을 사용합니다.
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar

새 서버에서 사용자 달력에 대해 csuser 유틸리티를 사용하여 달력 사용자를 활성화합니다. 예를 들면 다음과 같습니다.
csuser enable bkamdar

새 서버에서는 다음 명령을 사용하여 속성이 올바른지 그리고 각 달력이 올바르게 이동되었는지 확인합니다. 예를 들면 다음과 같습니다.
cscal -v -o bkamdar list bkamdar ... csattribute -v list bkamdar

원본 서버에서 방금 이동한 각 달력을 삭제합니다. 예를 들면 다음과 같습니다.
cscal -o bkamdar delete bkamdar
-o 옵션은 주 소유자가 bkamdar인 모든 달력을 삭제합니다.

주 –
CLD 캐시 옵션을 사용하고 있는 경우에는, 달력을 다른 백엔드 서버로 이동한 다음 반드시 CLD 캐시를 제거하여 서버 이름을 제거해야 합니다. CLD 캐시의 오래된 항목 때문에 프런트엔드 서버가 이동된 달력을 찾지 못할 수 있습니다. CLD 캐시를 지우려면 다음 단계를 수행합니다.
- Calendar Server를 중지합니다.
- /var/opt/SUNWics5/csdb/cld_cache 디렉토리의 모든 파일을 지우되, cld_cache 디렉토리 자체는 제거하지 않습니다.
- Calendar Server를 다시 시작합니다.

자원 달력 관리

자원 달력을 만든 후 csresource 유틸리티를 사용하여 관리합니다. 다음은 자원 달력을 관리하는 절차입니다.

자원 달력 및 속성 표시

자원 달력을 표시하려면 csresource 유틸리티 list 명령을 사용합니다.

예를 들어, 모든 Calendar Server 자원 달력과 해당 LDAP 속성을 목록으로 표시하려면 다음 명령을 사용합니다.

csresource list

Auditorium이라는 자원 달력의 모든 LDAP 속성 목록을 표시하려면 다음 명령을 사용합니다.

csresource -v list Auditorium

자원 달력 수정

자원 달력을 수정하려면 cscal 유틸리티 modify 명령을 사용합니다(csresource에는 modify 명령이 없음).

예를 들어, 소유자를 tchang으로 설정하고 mwong라는 이름의 또 다른 소유자를Auditorium 자원 달력에 추가하려면 다음 명령을 사용합니다.

cscal -o tchang -y mwong modify aud100

이 예에서 cscal 유틸리티는 달력 이름(Auditorium)보다 calid(aud100)가 필요합니다.

자원 달력 비활성화 또는 활성화

사용자가 이벤트를 예약할 수 없도록 자원 달력을 비활성화해야 하는 경우가 있습니다. 예를 들어, 리모델링때문에 회의실을 사용할 수 없거나 오버헤드 영사기가 수리 중일 수 있습니다.

자원 달력을 비활성화하거나 활성화하려면 csresource 유틸리티 enable 또는 disable 명령을 사용합니다.

예를 들어, Auditorium이라는 이름의 자원 달력을 비활성화하려면 다음 명령을 사용합니다.

csresource disable Auditorium

그리고 나중에 자원 달력을 활성화하려면 다음 명령을 사용합니다.

csresource enable Auditorium

자원 달력을 삭제하려면

자원 달력을 삭제하려면 csresource 유틸리티 delete 명령을 사용합니다.

예를 들어, Auditorium 자원 달력을 삭제하려면 다음 명령을 사용합니다.

csresource delete Auditorium

Calendar Server는 다음 메시지를 표시합니다.

Do you really want to delete this resource (y/n)?

달력을 삭제하려면 “y”를 입력하고 작업을 취소하려면 “n”을 입력합니다.

“y”를 입력하면 Calendar Server는 달력을 삭제하고 이를 알리는 메시지를 표시합니다.

다른 백엔드 서버로 자원 달력을 이동하려면

사용자 또는 자원 달력을 한 백엔드 서버에서 다른 백엔드 서버로 옮기려면 다음 단계를 수행합니다.

단계

원본 서버에서 csresource 유틸리티를 사용하여 달력 자원을 비활성화합니다. 예를 들어, 일반 이름 Auditorium을 사용하여 자원을 비활성화하려면 다음 명령을 사용합니다.
csresource disable Auditorium

원본 서버에서 csexport 유틸리티를 사용하여 각 자원 달력을 달력 데이터베이스에서 파일로 내보냅니다. 예를 들면 다음과 같습니다.
csexport -c aud100 calendar aud100.ics

내보낸 달력(*.ics) 파일을 원본 서버에서 새 서버로 복사합니다.

새 서버에서는 내보냈던 각 달력을 csimport 유틸리티를 사용하여 파일에서 달력 데이터베이스로 가져옵니다. 예를 들면 다음과 같습니다.
csimport -c bkamdar calendar bkamdar.ics

LDAP 디렉토리 서버에서 csattribute 유틸리티를 사용하여 새 백엔드 서버를 가리키도록 달력 소유자의 icsDWPHost LDAP 속성을 업데이트합니다. 속성을 업데이트하려면 먼저 해당 속성을 삭제한 다음 새 값으로 그 속성을 추가해야 합니다. 예를 들어, 새 서버 이름을 sesta.com으로 설정하려면 다음 명령을 사용합니다.
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar

새 서버에서 csresource 유틸리티를 사용하여 달력 자원을 활성화합니다. 예를 들면 다음과 같습니다.
csresource enable bkamdar

새 서버에서는 다음 명령을 사용하여 속성이 올바른지 그리고 각 달력이 올바르게 이동되었는지 확인합니다. 예를 들면 다음과 같습니다.
cscal -v -o bkamdar list bkamdar csattribute -v list bkamdar

원본 서버에서 방금 이동한 각 달력을 삭제합니다. 예를 들면 다음과 같습니다.
cscal -o bkamdar delete bkamdar
-o 옵션은 주 소유자가 bkamdar인 모든 달력을 삭제합니다.

주 –
CLD 캐시 옵션을 사용 중이고 달력을 다른 백엔드 서버로 이동한 경우 서버 이름을 제거하려면 CLD 캐시를 지워야 합니다. CLD 캐시의 오래된 항목 때문에 프런트엔드 서버가 이동된 달력을 찾지 못할 수 있습니다. CLD 캐시를 지우려면 다음 단계를 수행합니다.
- Calendar Server를 중지합니다.
- /var/opt/SUNWics5/csdb/cld_cache 디렉토리의 모든 파일을 지우되, cld_cache 디렉토리 자체는 제거하지 않습니다.
- Calendar Server를 다시 시작합니다.

달력 링크 만들기

하나 이상의 사용자 또는 자원 달력에 대한 링크를 만들 수 있습니다. 단, 각 달력마다 읽기 액세스를 허용하는 권한이 설정되어 있어야 합니다. 예를 들어, 웹 페이지나 전자 메일 메시지에 달력 링크를 내장할 수 있습니다. 그러면 다른 사용자가 Calendar Server에 로그인하지 않고서도 해당 달력을 익명으로 볼 수 있습니다.

하나 이상의 사용자 달력에 대한 링크를 만들려면 다음 구문을 사용하십시오.

http://CommunicationsExpresshostname:
CommunicationsExpressport/uwc/
   ?calid=calid-1[; ... ;calid-n]

여러 달력을 지정할 경우 각 달력 아이디(calid)를 세미콜론(;)으로 구분합니다.

예를 들어, jsmith@sesta.com 및 jdoe@siroe.com에 대한 기본 달력으로 연결되는 링크를 만들려면 다음을 입력합니다.

http://calendar.sesta.com:8080/?calid=jsmith@sesta;jdoe@siroe.com

calid가 overhead_projector10인 오버헤드 영사기 자원 달력에 대한 링크를 만들려면 다음 명령을 사용합니다.

http://calendar.sesta.com:8080/uwc/?calid=overhead_projector10

달력 데이터 가져오기 및 내보내기

달력 데이터를 파일로 내보내거나 파일에서 가져오려면 csexport 및 csimport 유틸리티를 사용합니다. 달력 데이터는 iCalendar(.ics) 또는 XML(.xml) 형식이 가능합니다.

csexport 및 csimport는 Calendar Server가 설치된 시스템에서 로컬로 실행해야 합니다. Calendar Server가 실행되고 있거나 중지되어 있을 수 있습니다.

달력 데이터 가져오기

csexport 유틸리티를 사용하여 저장했던 파일로부터 달력 데이터를 가져오려면 csimport를 사용합니다. 가져오기 파일의 파일 이름 확장명(.ics 또는 .xml)은 달력이 저장된 형식을 나타냅니다.

예를 들어, iCalendar(text/calendar MIME) 형식으로 저장했던 jsmith.ics 파일로부터 달력 아이디(calid) jsmithcal로 달력 데이터를 가져오려면 다음 명령을 사용합니다.

csimport -c jsmithcal calendar jsmith.ics

XML(text/xml MIME) 형식으로 저장했던 jsmith.xml 파일로부터 jsmithcal 달력으로 데이터를 가져오려면 다음 명령을 사용합니다.

csimport -c jsmithcal calendar jsmith.xml

달력 데이터 내보내기

달력 데이터를 파일로 내보내려면 가져가려면 csexport를 사용합니다. 출력 파일에 대해 지정한 파일 이름 확장자(.ics 또는 .xml)에 따라 사용되는 형식이 결정됩니다.

예를 들어, 달력 아이디(calid)가 jsmithcal인 달력을 iCalendar(text/calendar MIME) 형식으로 jsmith.ics라는 파일에 내보내려면 다음 명령을 사용합니다.

csexport -c jsmithcal calendar jsmith.ics

달력 jsmithcal을 XML(text/xml MIME) 형식으로 jsmith.xml이라는 파일로 내보내려면 다음 명령을 사용합니다.

csexport -c jsmithcal calendar jsmith.xml

16장 csdb를 사용하여 Calendar Server 데이터베이스 관리

Calendar Server는 여러 디렉토리에 많은 데이터베이스 파일을 유지합니다. 10 장, 자동 백업 구성(csstored)에 설명된 자동 백업 프로세스를 구현하거나 백업 시스템을 직접 구현하여 데이터베이스 파일을 보호해야 합니다. csdb 유틸리티를 사용하여 데이터베이스 파일을 관리할 수 있습니다.

이 장에서는 csdb를 사용하는 Calendar Service 데이터베이스 관리 방법을 설명하며, 다음 내용으로 구성되어 있습니다.

csdb를 이용한 달력 데이터베이스 관리

데이터베이스 파일을 관리하려면 Calendar Server 유틸리티 csdb 를 사용합니다. 이 절은 다음 내용으로 구성되어 있습니다.

csdb 그룹 데이터베이스 파일

달력 데이터베이스 유틸리티 csdb는 데이터베이스 파일을 3개의 논리적 데이터베이스로 처리합니다.

달력 데이터베이스(caldb)

caldb는 데이터베이스 디렉토리에 있는 모든 .db 파일 및 _db.* 파일로 구성됩니다. 다음은 달력 데이터베이스 파일(cld_cache 및 ldap_cache 하위 디렉토리 포함)에 대한 기본 위치입니다.

/var/opt/SUNWics5/csdb

원할 경우 Calendar Server 구성 프로그램(csconfigurator.sh) 실행 시 다른 디렉토리를 지정할 수 있습니다. 구성 프로그램에 대한 자세한 내용은 3 장, Calendar Server 구성 프로그램(csconfigurator.sh) 을 참조하십시오.

다음 표에서는 달력 데이터베이스(caldb) 파일에 대해 설명합니다.

표 16–1 Calendar Server 데이터베이스 파일


파일	설명
ics50calprops.db	모든 달력용 달력 등록 정보. 달력 아이디(`calid` ), 달력 이름, 액세스 제어 목록(ACL) 및 소유자를 포함합니다.
ics50events.db	모든 달력용 이벤트
ics50todos.db	모든 달력용 수행할 작업(태스크)
ics50alarms.db	모든 이벤트 및 수행할 작업(태스크)의 경보
ics50gse.db	그룹 예약 엔진(GSE)에 대한 예약 요청 대기열
ics50journals.db	달력 저널. 현재 릴리스에서는 저널이 구현되지 않습니다.
ics50caldb.conf	데이터베이스 버전 아이디
ics50recurring.db	반복 이벤트
ics50deletelog.db	삭제된 이벤트 및 수행할 작업(태스크). 18 장, 삭제 로그 데이터베이스 관리을 참조하십시오.

세션 데이터베이스(sessdb)

세션 데이터베이스는 /opt/SUNWics5/cal/lib/admin/session/ 및 /opt/SUNWics5/cal/lib/http/session/ 디렉토리에 있는 모든 파일로 구성됩니다.

통계 데이터베이스(statdb)

통계 데이터베이스는 counter 디렉토리에 있는 모든 파일로 구성됩니다.

/opt/SUNWics5/cal/lib/counter/

csdb 대상별 데이터베이스

csdb 유틸리티 -t 옵션을 사용하여 대상 데이터베이스를 지정할 수 있습니다.

-t caldb – 달력 데이터베이스
-t sessdb – 세션 데이터베이스
-t statdb – 통계 데이터베이스

-t 옵션을 포함하지 않은 경우 csdb는 세 가지 데이터베이스 모두에서 실행됩니다. 단, check 및 rebuild는 달력 데이터베이스에서만 실행됩니다.

csdb 관리 작업

이 절에서는 csdb 유틸리티를 사용하여 다음 관리 작업을 수행하는 방법을 사용합니다.

주 –

csdb 유틸리티를 실행하려면 Calendar Server가 실행되고 있는 시스템에 대해 관리 권한을 가진 사용자로 로그인해야 합니다. 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

데이터베이스 그룹 상태를 나열하려면

데이터베이스 그룹(caldb, sessdb, statdb)의 상태를 보려면 csdb 유틸리티 list 명령을 사용합니다.

데이터베이스 상태를 나열하려면

단계

Calendar Server가 설치된 시스템에 대해 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server는 실행 중이어도 되고 중지해도 되지만 가능하면 Calendar Server를 중지하는 것이 좋습니다.

/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin

하나 또는 모든 데이터베이스 그룹에 대해 list 명령을 실행합니다. 예를 들어, 세 데이터베이스 그룹 모두의 상태 및 통계를 나열하려면 다음 명령을 사용합니다.

./csdb list

다음 코드는 샘플 출력을 나타냅니다.

Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Calendar database version: 3.0.0 [BerkeleyDB]
Total database size in bytes: 57344

Session database version: 1.0.0 [BerkeleyDB]
Total database size in bytes: 0

Counter database version: 1.0.0 [Memory Mapped Files]
Total database size in bytes: 118792

또는 세부 정보 표시 모드를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

./csdb -v list

다음 샘플 코드는 세부 정보 표시 출력을 나타냅니다.

Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Calendar database version: 3.0.0 [BerkeleyDB]
Total database size in bytes: 57344
Total number of calendars:    2
Total number of events:       0
Total number of tasks:        0
Total number of alarms:       0
Total number of gse entries:  0
Total number of master component entries:  0
Total number of deletelog entries:  0
Total logfile size in bytes:  5779919

Session database version: 1.0.0 [BerkeleyDB]
Total database size in bytes: 0
Total logfile size in bytes:  0

Counter database version: 1.0.0 [Memory Mapped Files]
Total database size in bytes: 118792

또는 -t 옵션을 사용하여 하나의 대상 데이터베이스 그룹(caldb, sessdb 또는 statdb)을 지정합니다. 예를 들어, 달력 데이터베이스의 데이터베이스 상태 및 통계만 보려면 다음 명령을 사용합니다.

csdb -t caldb list

달력 데이터베이스 손상을 검사하려면

check 명령을 사용하여 달력 등록 정보(calprops) 및 이벤트와 작업(태스크)을 포함한 달력 데이터베이스에서 손상을 검색합니다. check 명령이 해결할 수 없는 비일관성 오류가 발견된 경우에는 출력으로 상황을 보고합니다.

check 명령은 경보나 그룹 예약 엔진(GSE) 데이터베이스의 손상을 확인하지 않습니다.

데이터베이스 손상을 검사하려면

단계

Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server는 실행 중이어도 되고 중지해도 되지만 가능하면 Calendar Server를 중지하는 것이 좋습니다.

아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다. 데이터베이스(.db) 파일만 복사합니다. 공유(__db.*) 또는 로그(log.*) 파일은 복사할 필요가 없습니다.

cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin

달력 데이터베이스의 복사본에 대해 check 명령을 실행합니다.
./csdb check dbdir \> /tmp/check.out 2\>&1
dbdir을 지정하지 않은 경우 check는 현재 디렉토리의 데이터베이스를 사용합니다.

check 명령은 많은 정보를 생성할 수 있으므로 이번 예와 같이 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.

check를 마치면 출력 파일을 검토합니다.

데이터베이스가 손상되었다면 핫 백업 복사본과 교체할 수 있습니다. 또는 rebuild 명령을 실행하여 손상된 복사본을 재구축할 수도 있습니다.

달력 데이터베이스(caldb)를 재구축하려면 - GSE 없음

손상된 달력 데이터베이스(caldb)를 복구하려면 csdb 유틸리티 rebuild 명령을 사용합니다. rebuild 명령은 손상이 있는지 모든 달력 데이터베이스를 스캔합니다. rebuild 명령이 비일관성을 발견한 경우 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 달력 데이터베이스를 재구축합니다(.db 파일).

rebuild 명령은 많은 정보를 생성할 수 있으므로 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.

다음 지침에서 rebuild 명령은 그룹 예약 엔진(GSE) 데이터베이스를 재구축하지 않습니다.

GSE 데이터베이스 없이 달력 데이터베이스를 재구축하려면 다음 작업을 수행합니다.

단계

Calendar Server가 설치된 시스템에 대해 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server를 중지합니다.

아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다. 데이터베이스(.db) 파일과 로그(log.*) 파일을 복사합니다. 공유(__db.*) 파일은 복사할 필요가 없습니다.

cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin
sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.

달력 데이터베이스의 복사본에 대해 rebuild 명령을 실행합니다.
./csdb rebuild /tmp/db /tmp/
데이터베이스 디렉토리를 지정하지 않는 경우, rebuild는 현재 디렉토리의 데이터베이스를 사용합니다. 이전 예에서 /tmp/ 매개 변수는 재구성된 데이터베이스에 대해 대상 디렉토리를 지정합니다.

주 –
항상 최신 백업 복사본을 사용하여 달력 데이터베이스를 재구축합니다.

그러나 심각한 데이터 손실이 발생했고 그 동안 정기적으로 데이터베이스를 백업했으며 2개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 재구축합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다.

예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.
1. ./csdb rebuild db_0629
  
  Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
2. ./csdb rebuild db_0615
  
  Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
3. ./csdb rebuild db_0601
  
  ... etc.
rebuild 명령은 다시 만든 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.

rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다. 해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt

rebuild가 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.

손상된 데이터베이스에 공유(__db.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.

Calendar Server를 다시 시작합니다.

달력 데이터베이스를 재구축하려면 - GSE 데이터베이스 포함

사이트에서 그룹 예약을 구현했다면 재구축에 GSE 데이터베이스를 포함해야 합니다.

달력 데이터베이스와 GSE 데이터베이스를 재구축하려면 다음 작업을 수행합니다.

단계

csschedule -v list 명령을 실행하여 GSE 데이터베이스에 항목이 있는지 확인하고 GSE가 항목 처리를 마치게 합니다.

Calendar Server가 설치된 시스템에 대해 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server를 중지합니다.

아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다.

데이터베이스(.db) 파일과 로그( log.*) 파일을 복사합니다. 공유(__db.*) 파일은 복사할 필요가 없습니다.

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

예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.

cd /opt/SUNWics5/cal/sbin

sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.

달력 데이터베이스 복사본에 대해 rebuild 명령을 실행합니다.

./csdb -g rebuild /tmp/db /tmp/

데이터베이스 디렉토리를 지정하지 않는 경우, rebuild는 현재 디렉토리의 데이터베이스를 사용합니다. 이전 예에서 /tmp/ 매개 변수는 재구성된 데이터베이스에 대해 대상 디렉토리를 지정합니다.

주 –
항상 최신 백업 복사본을 사용하여 달력 데이터베이스를 재구축합니다.

그러나 심각한 데이터 손실이 발생했고 그 동안 정기적으로 데이터베이스를 백업했으며 2개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 재구축합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다.

예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601
그러면 rebuild 명령은 재구축된 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.

rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다.

해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt

rebuild가 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.

손상된 데이터베이스에 공유(__db.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.

Calendar Server를 다시 시작합니다.

예 16–1 샘플 재구축 출력

이전 샘플 출력에서는 이벤트와 작업 데이터베이스가 각각 두 번씩 검색되었습니다. 이는 오류가 아닙니다. 처음 검색에서는 calprops 데이터베이스 정보를 확인합니다. 재검색에서는 calprops를 달력 데이터베이스에서 액세스할 수 있는지 확인합니다.

다음 예에서는 명령과 해당 출력을 보여 줍니다.

# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

데이터베이스 그룹을 삭제하려면

달력 데이터베이스를 삭제하려면 csdb 유틸리티 delete 명령을 사용합니다. Calendar Server를 중지해야 합니다.

대상 데이터베이스( caldb, sessdb 또는 statdb)를 지정하려면 -t 옵션을 사용합니다. 그렇지 않으면 csdb는 세 가지 데이터베이스를 모두 삭제합니다.

예를 들어, 달력 데이터베이스를 삭제하려면 다음 명령을 사용합니다.

csdb -t caldb delete

csdb 유틸리티는 데이터베이스를 삭제하기 전에 경고 메시지를 표시합니다.

17장 Calendar Server 데이터 백업 및 복원

Calendar Server에서 제공하는 자동 백업 기능( csstored 사용)을 사용하지 않는 경우에는 백업 절차를 수행하여 데이터를 보호해야 합니다. 이 장에서는 Calendar Server 및 다른 Sun 도구를 사용하여 수동 백업을 수행하고 달력 데이터베이스 파일을 복원하는 방법을 설명합니다.

Calendar Server 데이터를 /var/opt/SUNWics5/csdb 디렉토리에 백업하고 복원하려면 다음 명령줄 유틸리티를 사용합니다.

csbackup 유틸리티는 달력 데이터베이스, 특정 달력 또는 사용자의 기본 달력을 백업합니다. 백업할 디렉토리는 런타임 사용자(icsuser)가 소유해야 하며 그렇지 않은 경우 데이터를 복원하려고 하면 오류 메시지가 발생합니다.
csrestore 유틸리티는 csbackup 을 사용하여 지정했던 달력 데이터베이스, 개별 달력 또는 사용자의 기본 달력을 복원합니다.

주 –

db_recover와 같이 Berkeley 데이터베이스 도구를 사용하는 기존 사용자 정의 스크립트가 있는 경우에는 Calendar Server 6으로 업그레이드한 후에 해당 도구가 작동하지 않을 수 있습니다. Calendar Server 2004Q4 이전 버전에서는 이 도구가 정적 라이브러리를 사용하여 컴파일되었습니다. 이 릴리스 이후에는 동적 라이브러리를 사용하여 컴파일됩니다.

이러한 변경 사항에 맞도록 다음과 같이 동적 링크 라이브러리를 사용하도록 사용자 정의 스크립트를 변경하십시오. 전역 변수인 LD_LIBRARY_PATH를 동적 라이브러리 이름(libdb-4.2.so )으로 변경합니다.

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

주의 –

Calendar Server 2 데이터는 현재 제품과 호환되지 않습니다. Calendar Server 2 backup 유틸리티로 백업한 달력 데이터의 복원을 시도하지 마십시오. 데이터 손실이 발생할 수 있습니다.

현재 릴리스로 이동할 2 달력 데이터가 있는 경우 기술 지원 부서에 해당 마이그레이션 유틸리티에 대해 문의하십시오.

Calendar Server 데이터 백업

csbackup 유틸리티는 달력 데이터베이스, 지정된 달력 또는 사용자의 기본 달력을 백업할 수 있습니다. 이 절은 다음 내용으로 구성되어 있습니다.

달력 데이터베이스를 디렉토리로 백업하려면

단계

데이터베이스 파일 소유자(예: icsuser)로 로그인합니다.

csbackup 유틸리티 database 명령을 사용합니다.

예를 들어, backupdir이라는 디렉토리로 달력 데이터베이스를 백업하려면 다음 명령을 사용합니다.
csbackup -f database backupdir

백업 디렉토리에서 ics50caldb.conf 버전 파일을 검토하여 올바른 버전의 데이터베이스가 백업되었는지 확인하십시오.

주 –
대상 백업 디렉토리가 이미 존재하고 -f 옵션을 지정하지 않은 경우 csbackup 유틸리티는 실패합니다. 예를 들어, backupdir이 존재한다면 그 디렉토리가 비어 있더라도 다음 명령은 실패합니다.
csbackup database backupdir
따라서 이미 존재하는 대상 백업 디렉토리를 지정할 경우 -f 옵션을 포함시켜 csbackup을 실행합니다.

또한 존재하지 않는 대상 백업 디렉토리를 지정하고 csbackup이 해당 디렉토리를 만들게 할 수 있습니다.

파일에 특정 달력을 백업하려면

단계

데이터베이스 소유자(icsuser)로 로그인합니다.

파일에 iCalendar 또는 XML 형식으로 달력을 백업하려면 csbackup 유틸리티 calendar 명령을 사용합니다.

백업 파일의 파일 이름 확장자(.ics 또는 .xml)는 달력이 저장된 형식을 나타냅니다.

예를 들어, jsmithcal이라는 달력을 iCalendar 형식(text/calendar MIME)으로 backupdir 디렉토리의 jsmith.ics 파일에 백업하려면 다음 작업을 수행합니다.
csbackup -c jsmithcal calendar backupdir/jsmith.ics
또는 jsmithcal 달력을 XML 형식(text/XML)으로 backupdir 디렉토리의 jsmith.xml 파일에 백업하려면 다음 작업을 수행합니다.
csbackup -c jsmithcal calendar backupdir/jsmith.xml

파일에 사용자의 기본 달력을 백업하려면

단계

데이터베이스 소유자(icsuser)로 로그인합니다.

사용자의 기본 달력을 iCalendar 또는 XML 형식으로 텍스트 파일에 백업하려면 csbackup 유틸리티 def cal 명령을 사용합니다. 출력 파일에 대해 지정한 파일 이름 확장자((.ics 또는 .xml)에 따라 사용되는 형식이 결정됩니다.

예를 들어, 달력 사용자 jsmith의 기본 달력을 iCalendar(text/calendar MIME) 형식으로 백업 디렉토리의 파일 jsmith.ics에 백업하려면 다음을 수행합니다.
csbackup -a jsmith defcal backupdir/jsmith.ics
또는 달력 사용자 jsmith의 기본 달력을 XML(text/xml MIME) 형식으로 백업 디렉토리의 파일 jsmith.xml에 백업하려면 다음을 수행합니다.
csbackup -a jsmith defcal backupdir/jsmith.xml

Calendar Server 데이터 복원

csrestore 유틸리티는 csbackup을 사용하여 저장한 달력 데이터베이스, 개별 달력 또는 사용자의 기본 달력을 복원합니다. Calendar Server가 설치된 로컬 시스템에서 csrestore 유틸리티를 실행해야 하며, 이를 위해서는 먼저 Calendar Server를 중지해야 합니다. (그러나 데이터베이스 백업 시에는 Calendar Server를 실행해도 됩니다.)

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

달력 데이터베이스를 복원하려면

단계

데이터베이스 소유자(icsuser)로 로그인합니다.

csbackup 유틸리티를 사용하여 백업 디렉토리에 저장한 달력 데이터베이스를 복원하려면 csrestore 유틸리티 database 명령을 사용합니다.

예를 들어, backupdir이라는 백업 디렉토리에 저장했던 달력 데이터베이스를 복원하려면 다음 작업을 수행합니다.
csrestore database backupdir

백업 디렉토리에서 달력을 복원하려면

단계

데이터베이스 소유자(icsuser)로 로그인합니다.

csbackup 유틸리티를 사용하여 백업 디렉토리로 저장한 데이터베이스에서 특정 달력을 복원하려면 -c 옵션과 함께 csrestore 유틸리티 database 명령을 사용합니다.

예를 들어, jsmithcal 달력을 backupdir 백업 데이터베이스 디렉토리에서 복원하려면 다음 작업을 수행합니다.
csrestore -c jsmithcal calendar backupdir

파일에서 달력을 복원하려면

단계

데이터베이스 소유자(icsuser)로 로그인합니다.

csbackup 유틸리티를 사용하여 백업 파일에 저장한 특정 달력을 복원하려면 -c 옵션과 함께 csrestore 유틸리티 calendar 명령을 사용합니다.

백업 파일의 파일 이름 확장명(.ics 또는 .xml)은 달력이 저장된 형식을 나타냅니다.

예를 들어, iCalendar(text/calendar MIME) 형식으로 backupdir 디렉토리의 jsmith.ics 파일에 저장했던 jsmithcal 달력을 복원하려면 다음 작업을 수행합니다.
csrestore -c jsmithcal calendar backupdir/jsmith.ics
또는 XML(text/calendar MIME) 형식으로 bcakupdir 디렉토리의 jsmith.xml 파일에 저장했던 jsmithcal 달력을 복원하려면 다음 작업을 수행합니다.
csrestore -c jsmithcal calendar backupdir/jsmith.xml

사용자의 기본 달력을 복원하려면

단계

데이터베이스 소유자(icsuser)로 로그인합니다.

csbackup 유틸리티를 사용하여 백업 파일에 저장한 사용자의 기본 달력을 복원하려면 csrestore 유틸리티 defcal 명령을 사용합니다.

백업 파일의 파일 이름 확장명(.ics 또는 .xml))은 달력이 저장된 형식을 나타냅니다.

예를 들어, backupdir 백업 디렉토리에 있는 jsmith.ics 파일에 iCalendar(text/calendar MIME) 형식으로 저장한 달력 사용자 jsmith의 기본 달력을 복원하려면 다음을 수행합니다.
csrestore -a jsmith defcal backupdir/jsmith.ics
backupdir 백업 디렉토리에 있는 jsmith.xml 파일에 XML(text/xml MIME) 형식으로 저장한 달력 사용자 jsmith의 기본 달력을 복원하려면 다음을 수행합니다.
csrestore -a jsmith defcal backupdir/jsmith.xml

Sun StorEdge Enterprise Backup^TM 또는 Legato Networker® 사용

Sun StorEdge Enterprise Backup 소프트웨어(이전 명칭은 Solstice Backup)나 Legato Networker를 사용하여 Calendar Server 데이터를 백업하고 복원할 수도 있습니다. Sun StorEdge Enterprise Backup 소프트웨어 및 Legato Networker는 비슷하며, 이 절의 지침은 두 제품에 모두 적용됩니다.

그러나 Calendar Server를 백업하기 전에 Sun StorEdge Enterprise Backup 또는 Legato Networker 설명서를 읽어 보십시오.

Sun StorEdge Enterprise Backup 소프트웨어 설명서는 http://docs.sun.com 사이트에 있습니다.

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

StorEdge 또는 Legato 도구

Calendar Server는 Sun StorEdge나 Legato 백업 소프트웨어에서 사용하도록 /opt/SUNWics5/cal/sbin 디렉토리에서 다음 파일들을 제공합니다.

icsasm: Calendar Server Application Specific Module(ASM)ASM은 Sun StorEdge나 Legato 백업 소프트웨어에서 데이터 백업 및 복원을 위해 호출할 수 있는 프로그램입니다.
legbackup.sh: csbackup 유틸리티를 호출하는 스크립트
legrestore.sh: –csrestore 유틸리티를 호출하는 스크립트

Sun StorEdge Enterprise Backup 소프트웨어나 Legato Networker를 사용하여 달력 데이터를 백업하려면

Sun StorEdge나 Legato 백업 소프트웨어를 사용하여 달력 데이터베이스를 백업하려면 다음 작업을 수행합니다.

단계

Sun StorEdge 또는 Legato nsrfile 이진 파일을 /usr/lib/nsr 디렉토리에 복사합니다.

/usr/lib/nsr 디렉토리에 다음 심볼릭 링크를 만듭니다.

icsasm -\> /opt/SUNWics5/cal/sbin/icsasm nsrfile -\> /usr/lib/nsr/nsrfile

/opt/SUNWics5/cal/sbin 디렉토리로 변경하여 csbackup 유틸리티를 -l 옵션과 함께 실행합니다. 예를 들면 다음과 같습니다.
cd /opt/SUNWics5/cal/sbin ./csbackup -l
-l 옵션은 현재 디렉토리에 백업 디렉토리 이미지를 만듭니다. 이 디렉토리의 파일은 비어 있으며 백업 매체에서 달력이 저장되는 방법에 대한 정보를 백업 프로그램에게 제공하는 용도로만 사용됩니다. 백업 디렉토리가 이미 존재하는 경우 현재 디렉토리 구조와 동기화됩니다.

save 명령을 사용하여 달력 데이터를 백업합니다. 예를 들면 다음과 같습니다.
/usr/bin/nsr/save -s /opt/SUNWics5/cal/sbin/budir
또한 Sun StorEdge나 Legato backup GUI에서 정기적으로 데이터베이스를 백업하도록 클라이언트 저장 세트를 설정하여 백업을 예약할 수 있습니다.

주: .nsr 파일은 수정하지 마십시오. 이렇게 생성된 파일은 백업 과정에서 save 명령과 icsasm 명령이 해석하는 지시문을 포함하고 있습니다.

Calendar Server는 증분 백업 기능을 지원하지 않습니다. 백업 디렉토리는 폴더 구조의 이미지에 해당될 뿐 실제 데이터를 포함하지 않으므로 이 기능을 사용하지 마십시오.

ASCII가 아닌 문자나 슬래시(/)를 포함하는 이름으로 달력을 백업할 수 없습니다.

백업 절차를 자동화합니다.

이전 단계에서는 백업을 수동으로 실행하는 방법을 설명합니다. 자동화된 백업 프로세스를 실현하려면 백업 프로그램의 save 명령을 실행하기 전에 백업 프로그램의 backup 명령을 설정하여 Calendar Server csbackup 명령줄 유틸리티를 실행합니다.

Sun StorEdge Enterprise Backup 소프트웨어나 Legato 소프트웨어를 사용하여 달력 데이터를 복원하려면

달력 데이터를 복원하려면

단계

Sun StorEdge Enterprise Backup 소프트웨어 nwrestore 기능 또는 recover 명령을 사용하여 백업된 달력 정보를 복원합니다.

nwrestore를 사용하는 경우 다음 메시지가 표시됩니다.
"파일이 이미 있습니다. 덮어쓰기, 건너뛰기, 백업 또는 이름을 바꾸시겠습니까?"

overwrite를 선택합니다.

이 메시지는 백업 트리가 디렉토리 계층에 불과하기 때문에 표시됩니다. 즉, 빈 파일들로 구성되며 영구적으로 그 상태를 유지합니다.

18장 삭제 로그 데이터베이스 관리

Calendar Server에는 삭제된 이벤트 및 수행할 작업(태스크)을 저장하는 삭제 로그 데이터베이스(ics50deletelog.db )가 있습니다.

이전 릴리스의 Calendar Server에서는 삭제된 이벤트 및 태스크의 데이터베이스를 관리하지 않았습니다. 사용자는 삭제된 구성 요소를 확인하려면 이벤트 또는 수행할 작업(태스크)의 고유 아이디(uid)나 반복 아이디(rid)를 저장해야 했습니다. 이러한 제한은 WCAP 명령을 사용하여 클라이언트 사용자 인터페이스(UI)를 개발하는 설치 환경에 직접적으로 영향을 미쳤습니다. 이 제한을 해결하기 위해 삭제 로그 데이터베이스가 마련되었습니다.

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

삭제 로그 데이터베이스 만들기

Calendar Server는 csdb 디렉토리에 다른 Calendar Server 데이터베이스 파일과 함께 삭제 로그 데이터베이스(ics50deletelog.db)를 자동으로 만듭니다. Calendar Server는 삭제 로그 데이터베이스에 다음과 같이 이벤트 및 수행할 작업을 기록합니다.

반복하지 않는 이벤트 및 수행할 작업

반복하지 않는 이벤트나 수행할 작업이 삭제되는 경우 Calendar Server는 이벤트 데이터베이스( ics50events.db)나 수행할 작업 데이터베이스(ics50todos.db)에서 해당 항목을 제거하고 이를 삭제 로그 데이터베이스(ics50deletelog.db)에 기록합니다.
반복 이벤트 및 수행할 작업

반복 이벤트나 태스크의 개별 인스턴스가 삭제되는 경우 Calendar Server는 해당 이벤트나 태스크의 삭제된 인스턴스 각각을 삭제 로그 데이터베이스(ics50deletelog.db)에 기록합니다.

반복 이벤트나 수행할 작업의 모든 인스턴스가 삭제되는 경우 Calendar Server는 이벤트나 수행할 작업 데이터베이스에서 마스터 구성 요소를 삭제하고 이를 삭제 로그 데이터베이스에 기록합니다. 삭제 로그 데이터베이스의 마스터 구성 요소는 rrules, rdates, exrules 및 exdates 반복 매개 변수를 포함합니다.

삭제 로그 데이터베이스 쿼리

삭제 로그 데이터베이스에서 항목을 가져오려면 확장 모드나 압축 모드에서 fetch_deletedcomponents WCAP 명령을 사용합니다.

확장 모드(recurring = 0)

recurring 매개 변수가 0인 경우 fetch_deletedcomponents는 기준과 일치하는 반복 이벤트의 모든 인스턴스를 반환하지만 반복 이벤트의 마스터 구성 요소는 반환하지 않습니다.
압축 모드(recurring = 1)

recurring 매개 변수가 1인 경우 fetch_deletedcomponents는 반복하지 않는 이벤트 그리고 반복 이벤트의 마스터 구성 요소를 반환하지만, 개별 반복 이벤트는 반환하지 않습니다.

반복 체인의 모든 인스턴스가 삭제되는 경우 마스터 구성 요소는 dtstart, dtend, rrules, rdates, exrules, exdates 및 uid 매개 변수를 반환합니다.

또한 fetch_deletedcomponents는 삭제된 반복 인스턴스와 연관되지만 아직 활성 상태인 마스터 구성 요소를 반환하지 않습니다. 활성 마스터 구성 요소를 반환하려면 fetchcomponents_by_lasmod WCAP 명령을 사용합니다. fetch_deletedcomponents 명령은 fetchcomponents_by_lasmod 명령과 함께 사용해야 합니다.

WCAP 명령에 대한 자세한 내용은 Sun Java System Calendar Server 6 2005Q4 Developer’s Guide를 참조하십시오.

삭제 로그 데이터베이스 제거

Calendar Server는 삭제 로그 데이터베이스 자동 제거와 삭제 로그 데이터베이스 수동 제거를 모두 제공합니다.

삭제 로그 데이터베이스 자동 제거

필요한 경우에는 Calendar Server에서 삭제 로그 데이터베이스의 항목을 자동으로 제거하도록 할 수 있습니다.

다음 표에서는 자동 제거를 제어하는 ics.conf 파일의 매개 변수에 대해 설명합니다.

표 18–1 삭제 로그 데이터베이스 자동 제거를 위한 구성 매개 변수


매개 변수	설명
service.admin.purge.deletelog	삭제 로그 데이터베이스(`ics50deletelog.db`) 항목의 자동 제거를 사용 가능(`"yes"`) 또는 불가능(`"no"`)하게 합니다. 기본값은 `"no"`입니다.
caldb.berkeleydb.purge.deletelog.interval	삭제 로그 데이터베이스(`ics50deletelog.db`)의 항목을 자동으로 제거하는 간격을 초 단위로 지정합니다. 기본값은 `60`초입니다.
caldb.berkeleydb.purge.deletelog.beforetime	삭제 로그 데이터베이스(`ics50deletelog.db`)의 항목을 제거할 때까지의 시간을 초 단위로 지정합니다. 기본값은 `86400`초(1일)입니다.

예를 들어, Calendar Server가 5분(600초)마다 이틀(172800초)이 지난 삭제 로그 데이터베이스 항목을 자동으로 제거하도록 하려면 삭제 로그 데이터베이스 자동 제거의 매개 변수를 다음과 같이 설정합니다.

service.admin.purge.deletelog="yes"
 caldb.berkeleydb.purge.deletelog.interval=600
 caldb.berkeleydb.purge.deletelog.beforetime=172800

이 매개 변수를 설정한 다음 새 값을 적용하려면 Calendar Server를 다시 시작합니다.

삭제 로그 데이터베이스 수동 제거

삭제 로그 데이터베이스(ics50deletelog.db )의 항목을 수동으로 제거하려면 cspurge 유틸리티를 사용합니다.

cspurge -e endtime -s starttime

여기서 endtime 및 starttime은 줄루 시간(또는 GMT나 UTC로 표시)으로 종료 및 시작 시간을 지정합니다.

cspurge를 실행하려면 Calendar Server가 실행 중인 사용자 및 그룹(기본값은 icsuser 및 icsgroup) 또는 root로 로그인해야 합니다.

예를 들어, 2003년 7월 1일부터 2003년 7월 31일까지의 항목을 제거하려면 다음 작업을 수행합니다.

cspurge -e 20030731T235959Z -s 20030701T120000Z

자세한 내용은 cspurge를 참조하십시오.

삭제 로그 데이터베이스에 대해 Calendar Server 유틸리티 사용

다음 표에서는 삭제 로그 데이터베이스(ics50deletelog.db)를 지원하는 Calendar Server 유틸리티를 나열합니다.

표 18–2 삭제 로그 데이터베이스를 지원하는 유틸리티


유틸리티	설명
cspurge	삭제 로그 데이터베이스 항목의 수동 제거를 허용합니다.
csbackup 및 csrestore	삭제 로그 데이터베이스의 백업 및 복원을 지원합니다.
csstats	삭제 로그 데이터베이스 통계를 보고합니다.
csdb	삭제 로그 데이터베이스 재구축, 복구 및 점검 작업을 지원합니다.
cscomponents	삭제 로그 데이터베이스 항목의 번호를 나열합니다(읽기 전용).

이러한 유틸리티 구문을 포함한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

19장 Calendar Server 표준 시간대 관리

이 부록에서는 Calendar Server가 표준 시간대를 정의하고 처리하는 방법에 대해 설명합니다. 이 부록은 다음 내용으로 구성되어 있습니다.

표준 시간대 등록 정보 및 매개 변수에 대한 자세한 내용은 다음에서 RFC 2445, Internet Calendaring and Scheduling Core Object Specification(iCalendar)을 참조하십시오.

http://www.ietf.org/rfc/rfc2445.txt

Calendar Server 표준 시간대 개요

timezones.ics 파일에는 Calendar Server가 지원하는 표준 시간대 표시가 포함되어 있습니다. 이 파일은 다음 디렉토리에 있습니다.

cal_svr_base/SUNWics5/cal/data

Calendar Server는 시작할 때 timezones.ics 파일을 읽어 표준 시간대 데이터를 생성한 다음 그 데이터를 메모리에 저장합니다. 따라서 표준 시간대 데이터는 Calendar Server가 실행되는 동안 메모리에 보관됩니다. 결과적으로 새 표준 시간대를 추가하거나 기존 표준 시간대를 변경할 경우에는 Calendar Server를 중지하고 다시 시작해야 변경 내용이 적용됩니다.

timezones.ics 파일의 표준 시간대는 TZID 매개 변수에 의해 표시됩니다. 예를 들어, Calendar Server는 예 19–1에 나타난 것처럼 America/Los_Angeles TZID 를 사용하여 Pacific Standard Time(PST/PDT) 시간대를 식별합니다. TZNAME 등록 정보는 America/Los_Angeles 표준 시간대를 PST(Pacific Standard Time)로 표시하는 등 표준 시간대의 약어 표시입니다.

America/Los_Angeles와 같이 일광 절약 시간(DST)을 인식하는 표준 시간대는표준 시간을 나타내는 STANDARD와 DST를 나타내는 DAYLIGHT의 두 하위 구성 요소를 포함합니다. X-NSCP-TZCROSS 목록에는 표준 시간대가 DST(DAYLIGHT) 및 표준(STANDARD) 시간으로 변경될 때를 나타내는 일련의 날짜들이 포함되어 있습니다.

RRULE 등록 정보는 STANDARD 및 DAYLIGHT 규칙의 패턴을 정의합니다. TZOFFSETFROM 및 TZOFFSETTO 등록 정보는 DST에서 표준 시간으로 또는 표준 시간에서 DST로 변경되는 전과 후의 GMT 오프셋을 정의합니다. Communications Express 사용자 인터페이스는 X-NSCP-TZCROSS의 날짜를 사용하여 표준 시간대 변경을 표시할 때를 결정합니다.

표준 시간대 아이디인 tzid 매개 변수를 포함하는 WCAP 명령은 timezones.ics 파일에 정의된 유효한 표준 시간대를 참조해야 합니다. Calendar Server는 해당 표준 시간대를 사용하여 데이터를 반환합니다. WCAP 명령이 인식되지 않는 표준 시간대를 지정하면 Calendar Server는 기본적으로 데이터를 GMT 표준 시간대로 반환합니다. WCAP에 대한 자세한 내용은 Sun Java System Calendar Server 6 2005Q4 Developer’s Guide를 참조하십시오.

예 19–1 timezones.ics 파일의 아메리카/로스앤젤레스 표준 시간대 표시

다음 예에서는 timezones.ics 파일의 아메리카/로스앤젤레스 표준 시간대 표시를 보여 줍니다.

BEGIN:VTIMEZONE
TZID:America/Los_Angeles
BEGIN:STANDARD
DTSTART:19671025T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
END:DAYLIGHT
X-NSCP-TZCROSS:
  19880403T100000Z;19881030T090000Z;19890402T100000Z;19891029T090000Z;
  19900401T100000Z;19901028T090000Z;19910407T100000Z;19911027T090000Z;
  19920405T100000Z;19921025T090000Z;19930404T100000Z;19931031T090000Z;
  19940403T100000Z;19941030T090000Z;19950402T100000Z;19951029T090000Z;
  19960407T100000Z;19961027T090000Z;19970406T100000Z;19971026T090000Z;
  19980405T100000Z;19981025T090000Z;19990404T100000Z;19991031T090000Z;
  20000402T100000Z;20001029T090000Z;20010401T100000Z;20011028T090000Z;
  20020407T100000Z;20021027T090000Z;20030406T100000Z;20031026T090000Z;
  20040404T100000Z;20041031T090000Z;20050403T100000Z;20051030T090000Z;
  20060402T100000Z;20061029T090000Z;20070401T100000Z;20071028T090000Z;
  20080406T100000Z;20081026T090000Z;20090405T100000Z;20091025T090000Z;
  20100404T100000Z;20101031T090000Z;20110403T100000Z;20111030T090000Z;
  20120401T100000Z;20121028T090000Z;20130407T100000Z;20131027T090000Z;
  20140406T100000Z;20141026T090000Z;20150405T100000Z;20151025T090000Z;
  20160403T100000Z;20161030T090000Z;20170402T100000Z;20171029T090000Z;
  20180401T100000Z;20181028T090000Z;20190407T100000Z;20191027T090000Z;
  20200405T100000Z;20201025T090000Z;20210404T100000Z;20211031T090000Z;
  20220403T100000Z;20221030T090000Z;20230402T100000Z;20231029T090000Z;
  20240407T100000Z;20241027T090000Z;20250406T100000Z;20251026T090000Z;
  20260405T100000Z;20261025T090000Z;20270404T100000Z;20271031T090000Z;
  20280402T100000Z;20281029T090000Z;20290401T100000Z;20291028T090000Z;
  20300407T100000Z;20301027T090000Z;20310406T100000Z;20311026T090000Z;
  20320404T100000Z;20321031T090000Z;20330403T100000Z;20331030T090000Z;
  20340402T100000Z;20341029T090000Z;20350401T100000Z;20351028T090000Z;
  20360406T100000Z;20361026T090000Z;20370405T100000Z;20371025T090000Z;
  20360406T120000Z;20361026T110000Z;20370405T120000Z;20371025T110000Z
END:VTIMEZONE

Calendar Server 표준 시간대 관리

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

새 표준 시간대 추가

이 절에서는 Calendar Server에 새 표준 시간대를 추가하여 Communications Express 사용자 인터페이스에서 사용할 수 있도록 하는 방법에 대해 설명합니다. 예를 들어, 아메리카/마이애미를 위한 새 표준 시간대를 추가할 수 있습니다.

정보 –

새 표준 시간대를 추가하는 가장 간단한 방법은 다음 단계에 설명된 각 파일에서 추가하려는 표준 시간대와 비슷한 표준 시간대 항목을 복사하여 편집하는 것입니다. 예를 들어, 아메리카/마이애미를 위한 표준 시간대를 추가하려면 각 파일에서 아메리카/뉴욕을 위한 표준 시간대 항목을 복사하여 집합니다.

새 표준 시간대를 추가하는 방법

단계

다음 파일에서 새 표준 시간대를 위한 표준 시간대 블록을 추가합니다.
cal_svr_base/SUNWics5/cal/data/timezones.ics
새 표준 시간대 블록을 추가하는 가장 간단한 방법 또한 일광 절약 시간(DST) 오프셋을 비롯하여 추가하려는 표준 시간대와 비슷한 기존 블록을 복사한 다음 새 표준 시간대를 위해 변경하여 새 표준 시간대 블록을 편집하는 것입니다. 새 표준 시간대에 DST가 포함되어 있는 경우에는 비슷한 것을 찾으십시오.

다음 파일에서 getDisplayNameofTZID 템플리트를 수정합니다.
cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file
여기서 language는 사이트에서 사용하는 언어를 위한 디렉토리를 지정합니다. 예를 들어영어는 en, 프랑스어는 fr로 지정합니다.

i18n.xsl 파일에 다음과 같이 새 항목을 추가합니다.
<xsl:when test="$tzid=’TimeZoneArea/ TimeZoneName’"TimeZoneArea/ TimeZoneName</xsl:when\>
여기서,

TimeZoneArea는아프리카, 아메리카, 아시아, 대서양, 오스트레일리아, 유럽, 태평양 지역 중 하나입니다.

TimeZoneName은 새 표준 시간대의 이름입니다.

예를 들면 다음과 같습니다.
<xsl:when test="$tzid='America/Miami'"\>America/Miami</xsl:when\>

다음 XML 파일을 수정합니다.
cal_svr_base/SUNWics5/cal/html/change_timezone.xml cal_svr_base/SUNWics5/cal/html/new_cal.xml cal_svr_base/SUNWics5/cal/html/new_group.xml
각 파일에 다음 행을 추가합니다.
<timezone type="TimeZoneType" tzid="TimeZoneArea/TimeZoneName" offset="offset">
여기서,

TimeZoneType은 "americas" ,"europeAfrica" 또는 "asiaPacific"입니다.

TimeZoneArea 및 TimeZoneName은 새 표준 시간대 추가에서 정의됩니다.

offset은 새 표준 시간대가 GMT보다 앞(+)이거나 뒤(-)인 시간 수입니다. 예를 들어, 새 표준 시간대가 GMT보다 4시간 뒤이면 오프셋은 "-04:00"입니다.

예를 들면 다음과 같습니다.
<timezone type="americas" tzid="America/Miami" offset="-05:00" daylightOffset="-04:00">

새 표준 시간대를 사용자 기본 설정을 위한 기본 시간 표준대로 사용하려면 다음 파일의 timezone 항목을 수정합니다.
cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml

필요한 경우 Calendar Server를 중지한 다음 다시 시작하여 새 표준 시간대를 적용합니다.

기존 표준 시간대 수정

이 절에서는 기존 표준 시간대를 수정하는 방법에 대해 설명합니다. 예를 들어, 표준 시간대의 이름을 “아메리카/피닉스”에서 “미국/아리조나”로 변경할 수 있습니다.

기존 표준 시간대를 수정하는 방법

단계

다음 파일에서 변경하려는 표준 시간대를 위한 표준 시간대 블록을 수정합니다.
cal_svr_base/SUNWics5/cal/data/timezones.ics
표준 시간대 이름을 변경하는 경우에는 TZID 항목을 새 이름으로 변경합니다.

다음 파일에서 getDisplayNameofTZID 템플리트를 수정합니다.
cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file
여기서,language는 사이트에서 사용하는 언어를 위한 디렉토리를 지정합니다. 예를 들면 다음과 같습니다. 영어는 en, 프랑스어는 fr로 지정합니다.

이름을 변경하는 경우에는 기존 표준 시간대 이름을 새 이름으로 변경합니다.

다음 XML 파일을 수정합니다.
cal_svr_base/SUNWics5/cal/html/change_timezone.xml cal_svr_base/SUNWics5/cal/html/new_cal.xml cal_svr_base/SUNWics5/cal/html/new_group.xml
이러한 파일에 포함된 항목에 대한 자세한 내용은 새 표준 시간대 추가를 참조하십시오.

변경 내용이 사용자 기본 설정을 위한 기본 표준 시간대에 영향을 주는 경우에는 다음 파일에서 “icsTimeZone” 항목을 수정합니다.
cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml

필요한 경우 Calendar Server를 중지한 다음 다시 시작하여 새 표준 시간대를 적용합니다.

20장 Instant Messaging 팝업 미리 알림 사용

Calendar Server는 Sun Java System Instant Messaging 6.0(또는 그 이상)과 통합되어 달력 이벤트와 태스크에 대한 자동 팝업 미리 알림을 제공합니다.

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

팝업 미리 알림 개요

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

팝업 미리 알림 작동

사용자는 달력에서 다가오는 이벤트와 태스크에 대해 Instant Messenger 팝업 미리 알림을 수신할 수 있습니다. 이러한 팝업 미리 알림을 활성화하려면 두 가지 작업이 필요합니다.

관리자는 팝업 알림을 허용하도록 Calendar Server와 Instant Messaging Server를 구성해야 합니다.
최종 사용자는 이벤트 알림 시스템에서 경보를 설정하는 Communications Express의 옵션 탭에서 전자 메일 미리 알림을 지정해야 합니다.
최종 사용자는 Instant Messenger에서 달력 미리 알림을 설정해야 합니다.

팝업을 활성화한 상태에서 임박한 이벤트나 태스크가 다가오면, 이벤트 알림 시스템에서 설정한 경보 기능 덕분에 Calendar Server는 전자 메일 알림을 보내고 Instant Messaging은 팝업 미리 알림을 표시합니다.

Calendar Server 관리자는 최종 사용자를 위해 전자 메일 알림과 팝업 미리 알림을 모두 구성하거나 둘 중 하나를 구성하도록 선택할 수 있습니다. 예를 들어, 전자 메일 미리 알림을 사용하지 않으려면 ics.conf 파일에 다음 매개 변수를 설정합니다.

caldb.serveralarms.binary.enable= "no"

팝업 미리 알림 구조 흐름

Instant Messaging 팝업 미리 알림이 구성된 경우에는 다음과 같은 구조 흐름을 따릅니다.

Instant Messaging JMS 가입자는 ENS(이벤트 알림 서비스)의 Calendar Server 이벤트 및 알림에 가입합니다.
Calendar Server는 text/xml 또는 text/calendar 형식의 이벤트 또는 태스크 알림을 ENS에 게시합니다.
Instant Messaging JMS 가입자는 달력 이벤트 또는 알림을 수신한 다음 text/calendar 형식으로 메시지를 생성합니다.
Instant Messaging Server는 최종 사용자가 온라인 상태인 경우 메시지를 달력 소유자에게 보냅니다.
수신자가 있는 경우, Instant Messenger는 메시지를 기반으로 최종 사용자의 데스크탑에 HTML 팝업 미리 알림을 생성합니다.

팝업 미리 알림 구성

이절에서는 다음 구성 지침을 소개합니다.

Instant Messaging Server 구성

편의를 위해 Instant Messaging에서 앞으로 표시될 팝업을 구성하는 데 필요한 태스크를 요약한 목록이 마련되었습니다. Instant Messaging를 구성하려면 다음 웹 사이트에서 제공하는 Instant Messaging 설명서를 참조하십시오.

http://docs.sun.com/coll/1309.2 및 http://docs.sun.com/coll/1405.1

단계

새 패키지 SUNWiimag를 설치합니다.

팝업을 표시하기 위해 Instant Messaging을 사용하려면 먼저 Java Enterprise System 설치 프로그램을 사용하여 Instant Messaging 패키지를 설치해야 합니다.

Instant Messaging이 설치된 시스템에서 다음 디렉토리로 변경합니다.

cd /etc/opt/SUNWiim/default/config

다음 표에 표시된 iim.conf 파일의 매개 변수 중 하나 이상을 편집합니다.

표시된 매개 변수 값은 이벤트와 태스크에 대해 팝업 미리 알림이 필요하다고 가정한 것입니다. 이 매개 변수가 iim.conf 파일에 존재하지 않는 경우 추가하십시오.

매개 변수	설명과 사용하기 알맞은 값
JMS 사용자 섹션
`jms.consumers`	경보의 이름입니다. 값을 `cal_reminder`를 설정합니다.
`jms.consumer.cal_reminder.destination`	경보의 대상입니다. 값을 enp:///ics/customalarm으로 설정합니다.
`jms.consumer.cal_reminder.provider`	공급자의 이름입니다. `ens`로 설정합니다. JMS 공급자 섹션에 있는 `jms.providers`와 같은 이름이어야 합니다.
`jms.consumer.cal_reminder.type`	설정할 경보의 유형입니다. 값을 `topic`으로 설정합니다.
`jms.consumer.cal_reminder.param`	경보 매개 변수입니다. 값을 `"eventtype=calendar.alarm"(따옴표 포함)`으로 설정합니다.
`jms.consumer.cal_reminder.factory`	C++ 팩토리 이름입니다. 값을 다음으로 설정합니다. com.iplanet.im.server. JMSCalendarMessageListener
JMS 공급자 섹션
`jms.providers`	공급자의 이름입니다. 값을 `ens`로 설정합니다. JMS 사용자 섹션에서 `jms.consumer.cal_reminder.provider`에 대한 나열된 값과 같아야 합니다.
`jms.provider.ens.broker=cal.example.com`	ENS가 수신하는 포트 번호입니다. `ics.conf` 파일 매개 변수 `service.ens.port`에 지정된 포트로 설정합니다. 기본값은 57997입니다.
`jms.provider.ens.factory`	사용할 C++ 팩토리입니다. `com.iplanet.ens.jms.EnsTopicConnFactory`로 설정합니다.
Calendar Server 일반 매개 변수
`iim_agent.enable`	달력 에이전트를 활성화합니다. 값을 따옴표를 포함하여 다음과 같이 설정합니다. `iim_agent.enable="true"`
`iim_agent.agent-calendar.enable`	달력 에이전트를 활성화하는 구성 요소를 로드합니다. 값을 따옴표를 포함하여 다음과 같이 설정합니다. `iim_agent.agent-calendar.enable="true"`
`agent-calendar.jid`	달력 에이전트의 JID입니다. 이 값을 다음과 같이 설정합니다. `agent-calendar.jid=calimbot.server` `.domain`
`agent-calendar.password`	달력 에이전트 비밀번호입니다. 이 값을 다음과 같이 설정합니다. `agent-calendar.password=password`
`iim_server.components`	이 값을 다음과 같이 설정합니다. `iim_server.components=agent-calendar`

imadmin 명령줄 유틸리티가 있는 디렉토리로 변경합니다.

cd /opt/SUNWiim/sbin

imadmin을 사용하여 달력 에이전트를 시작합니다.

imadmin start agent-calendar

달력 에이전트는 Calendar Server 사용자에게 팝업 기능을 제공하는 Instant Messaging 구성 요소입니다. Instant Messaging과 함께 제공되는 도구를 사용하여 달력 에이전트를 시작, 중지, 다시 시작하거나 달력 에이전트의 상태를 검사할 수 있으며 로그 파일을 통해 작업을 모니터링할 수 있습니다.

주 –
stop, start 및 refresh 명령이 포함된 스크립트가 있는 경우 달력 에이전트를 추가합니다.

imadmin and the Calendar agent에 대한 자세한 내용은 Sun Java System Instant Messaging 7 2005Q1 Administration Guide를 참조하십시오.

Calendar Server 구성

시작하기 전에

다음 표에 표시된 ics.conf 매개 변수에 표시된 값이 지정되었는지 확인합니다. 표시된 값이 지정되어 있지 않거나 해당 값을 사용자 정의하려면 다음 단계를 수행하십시오.

단계

구성을 변경할 권한을 가지고 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

다음 표에 표시된 ics.conf 매개 변수를 편집합니다.

매개 변수	설명 및 기본값
caldb.serveralarms	달력 경보 대기열이 사용 가능하게 합니다. 기본값은 `“yes”`(사용 가능)입니다.
caldb.serveralarms.contenttype	경보 내용의 출력 형식입니다. 기본값은 `"text/xml"`입니다.
caldb.serveralarms.dispatch	달력 경보가 디스패치 가능하게 합니다. 기본값은 `“yes”`입니다.
caldb.serveralarms.dispatchtype	디스패치할 서버 경보의 유형입니다. 기본값은 `"ens"`입니다.
caldb.serveralarms.url 형식의 도우미 전자 메일	경보 내용을 검색하는 경보 URL입니다. 기본값은 `"enp:///ics/customalarm"`입니다.

파일을 ics.conf로 저장합니다.

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

Instant Messenger 구성

Calendar Server 이벤트 및 태스크를 위한 팝업 미리 알림을 수신하려는 최종 사용자는 Instant Messenger를 다음과 같이 구성해야 합니다.

단계

주 창의 도구 메뉴에서 설정을 선택합니다.

설정 창에서 경고 탭을 누릅니다.

달력 미리 알림 표시 옵션을 선택합니다.

확인을 누릅니다.

21장 Calender Server 성능 조정

Calendar Server의 성능을 향상시키려면 다음 옵션을 사용할 것을 고려하십시오.

LDAP Directory Server 색인

Calendar Server가 LDAP Directory Server에 액세스할 때 성능을 향상시키려면 다음 속성을 위한 LDAP 구성 파일에 색인을 추가합니다.

icsCalendar: 이 속성은 달력 사용자 또는 자원의 기본 달력을 검색하는 데 사용됩니다. 존재(pres), 일치( eq) 및 하위 문자열(sub) 색인 유형을 지정합니다.
icsCalendarOwned: 이 속성은 사용자가 소유한 다른 달력을 검색하는 데 사용됩니다. 존재(pres), 일치(eq) 및 하위 문자열(sub) 색인 유형을 지정합니다. DWP 환경의 달력 검색 성능 향상을 참조하십시오.
mail, mailAlternateAddress: 이러한 속성은 사용자의 기본 및 대체 전자 메일 주소를 지정합니다. 사용자 및 자원 만들기 및 Calendar Server 유틸리티(csuser enable)를 참조하십시오.

디렉토리 서버 색인 추가에 대한 자세한 내용은 다음 위치의 Directory Server 설명서를 참조하십시오.

http://docs.sun.com/coll/1316.1 및 http://docs.sun.com/coll/1404.1

DWP 환경의 달력 검색 성능 향상

DWP 환경에 있는 경우, 즉 달력 데이터베이스가 여러 백엔드 서버 전체에 배포되었다면 달력 데이터베이스에서 달력 검색에 시간이 많이 걸릴 수 있습니다. 먼저 LDAP 항목을 보고 달력이 상주하는 DWP 호스트를 직접 찾는 것이 더 빠를 수 있습니다.

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

달력 검색에서 LDAP를 보도록 활성화

달력 검색에서 먼저 LDAP 디렉토리를 찾고 다음으로 달력 데이터베이스를 찾으려면 다음 단계를 수행합니다.

단계

ics.conf 파일에서 service.calendarsearch.ldap 매개 변수를 편집하고 아래와 같이 이 매개 변수를 기본값인 “yes”로 설정합니다.

service.calendarsearch.ldap="yes"

Calendar Service를 다음과 같이 다시 시작합니다.

start-cal

주 –
공용 달력에 익명 액세스를 허용하는 경우 달력 검색에서 LDAP를 보지 못하게 할 수도 있습니다. 실제로 Communications Express는 매개변수 값을 “no”로 예상합니다.

색인으로 검색 성능 개선

단계

달력 검색 성능이 색인으로 개선될 수 있는지 확인하려면 다음 LDAP 명령을 시도하십시오.
ldapsearch -b "base" "(&(icscalendarowned=*user*) (objectclass=icsCalendarUser))"
여기서 base는 Calendar Server에 대한 사용자 및 자원 데이터가 있는 LDAP 기본 DN이고 user는 최종 사용자가 검색 대화 상자에 입력할 수 있는 값입니다.

60,000개의 항목을 테스트한 결과, 위의 검색은 icsCalendarOwned에 색인이 없는 경우 약 50-55초 가량 걸립니다. 그러나 색인을 사용하면 1-2초 밖에 걸리지 않습니다.

comm_dssetup.pl을 실행하여 적절한 LDAP 속성 또는 최소한 icsCalendarOwned를 색인화합니다.

comm_dssetup.pl은 다양한 방식으로 성능을 개선하기 위해 이 속성과 다른 속성을 색인화합니다. comm_dssetup.pl을 실행하지 않거나 실행했지만 색인화를 수행하지 않은 경우, 다시 유틸리티를 실행하여 색인화를 수행하거나 Directory Server 도구를 사용하여 색인화를 수행할 수 있습니다.

comm_dssetup.pl로 색인화를 수행하는 방법에 대한 자세한 내용은 속성 색인을 참조하십시오.

디렉토리 서버 색인 추가에 대한 자세한 내용은 다음 위치의 Directory Server 설명서를 참조하십시오.

http://docs.sun.com/coll/1316.1 및 http://docs.sun.com/coll/1404.1

와일드카드 검색을 비활성화하여 달력 검색 성능 개선

기본적으로 와일드카드 검색은 Calendar Server에서 비활성화됩니다. 즉, 그래픽 사용자 인터페이스를 사용하여 달력을 검색할 때 또는 사용자 정의 인터페이스에서 search_calprops.wcap을 실행하는 경우 WCAP 명령으로 전달되는 검색 문자열과 정확하게 일치하는 값을 검색합니다.

ics.conf 파일에서 다음 행의 주석을 취소하여 와일드카드 검색을 활성화한 경우(시작 부분에서 느낌표(“!”) 제거) 성능에 부정적인 영향을 줄 수 있습니다.

!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"

성능에 대한 와일드카드 검색의 영향을 테스트하려면 앞에 느낌표(“!”)를 삽입해서 행을 다시 주석으로 처리합니다.

CLD 플러그 인 성능 향상

시스템이 달력 데이터베이스로부터 달력에 액세스하면 어떤 백엔드 시스템이 해당 사용자의 달력을 저장하는지 판단해야 합니다. 적절한 백엔드 시스템을 찾기 위해 시스템은 사용자의 항목에 대해 LDAP 디렉토리를 검색하고 icsDWPHost 속성을 선택합니다. 이 검색에는 시간이 걸리며 달력 데이터에 대한 모든 액세스에서 수행되어야 합니다. 모든 사용자 세션으로 인해 데이터베이스 액세스가 자주 발생하고 그로 인해 LDAP 검색이 자주 일어날 수 있습니다. 시간을 절약하고 성능을 개선하려면 ics.conf 파일을 다음과 같이 편집하여 OLD 데이터 캐시를 활성화합니다.

caldb.cld.cache.enable="yes"

LDAP 데이터 캐시는 사용자 아이디 및 해당 icsDWPHost 속성을 저장합니다. LDAP에서 사용자 항목을 검색하기 전에 시스템은 사용자 아이디가 있는지 캐시를 확인합니다. 캐시에 있다면 저장된 icsDWPHost 속성에서 백엔드 호스트 이름을 선택합니다. 캐시에 있지 않는 경우 시스템은 LDAP 검색을 수행하고 사용자 아이디와 속성을 OLD 캐시에 복사합니다. 이제부터는 캐시에서 사용자 아이디를 찾기 때문에 사용자 달력 데이터 액세스가 더 빨라집니다.

LDAP 데이터 캐시의 성능 개선

LDAP 데이터 캐시가 활성화되면 ics.conf 매개 변수를 사용하여 조정하고 다음 표에 나오는 하나 이상의 매개 변수를 조정할 수 있습니다.

주 –

LDAP 데이터 캐시는 기본적으로 활성화됩니다. 다음을 설정하여 비활성화할 수 있습니다. local.ldap.cache.enable="no"

표 21–1 LDAP 데이터 캐싱을 사용자 정의하기 위해 사용되는 ics.conf 매개 변수


매개 변수	설명값
`local.ldap.cache` `.checkpointinterval`	검사점 사이에 검사점스레드가일시정지하는시간(초단위)입니다. 기본값은 `“60”`입니다. 높은 활동 LDAP에서 캐시를 가능한 최신으로 유지하기 위해 간격을 줄일 수 있습니다. 또한 캐시를 자주 갱신할수록 시스템 오버헤드가 많이 발생합니다.
`local.ldap.cache.` `circularlogging`	처리된 후 LDAP 데이터 캐시 데이터베이스 로그 파일을 제거할지 지 정합니다. 기본값은 `“yes”`입니다. 이전 로그 파일을 제거할 사용자 정의 정리 루틴이 없다면 이 매개 변수를 바꾸지 마십시오.
`local.ldap.cache.` `logfilesizemb`	검사점 파일의 최대 크기를 MB 단위로 지정합니다. 기본값은 `"10”`MB입니다. 높은 활동 LDAP가 있는 경우 이 파일은 검사점 간격이 끝나기 전에 가득 찰 수 있습니다. 경험상 로그의 실제 크기와 가까운 숫자로 값을 설정해 보십시오.
`local.ldap.cache.` `maxthreads`	LDAP 데이터 캐시 데이터베이스를 위한 스레드의 최대 수를 지정합니다. 기본값은 `“1000”`입니다. 높은 활동 LDAP에서는 스레드의 수를 늘려야 하는 경우가 있습니다. CUP 사용률도 증가할 수 있습니다. LDAP 활동이 최소인 경우에만 스레드의 수를 줄입니다.
`local.ldap.cache.` `mempoolsizemb`	공유 메모리의 크기를 MB 단위로 지정합니다. 공유메모리의크기를메가바이트단위로지정합니다기본값은 `“4”`MB입니다.
`local.ldap.cache.` `entryttl`	LDAP 데이터 캐시 항목을 위한 “지속 시간”(TTL)을 초 단위로 지정합니다. 기본값은 `“3600”`초(1시간)입니다. 캐시가 너무 빨리 차게 되면(높은 활동), TTL 시간을 줄일 수 있습니다. 하지만 이렇게 하면 LDAP 데이터베이스 액세스 횟수가 전반적으로 줄어들어 시스템 다운도 줄어들 수 있습니다.
`local.ldap.cache.` `cleanup.interval`	각 캐시 데이터베이스 정리 사이의 간격을 초 단위로 지정합니다. 기본값은 `“1800”`초(30분)입니다. 시스템은 만료 항목을 제거합니다. 시간 간격은 항목 TTL 시간과 같을 필요는 없습니다. 하지만 이를 동기화하면 더욱 효율적일 수 있습니다.
`local.ldap.cache.` `stat.enable`	LDAP 데이터 캐시에 대한 액세스 로그 여부 및 로그 파일의 통계 인쇄 여부를 지정합니다. 기본값은 `“no”`입니다. 성능 개선을 위해 디버그 모드에서만 사용하십시오.
`local.ldap.cache.` `stat.interval`	각 통계 보고서가 로그 파일에 기록되는 간격을 초 단위로 지정합니 다. 기본값은 `“1800”`초(30분)입니다. 이것은 local.ldap.cache.stat.enable이 활성화되었을 때만 활성입니다. 간격을 줄이면 문제를 정확히 파악하는 데 도움이 됩니다. 간격을 늘리면 시스템 로드가 줄어듭니다.

주 –

Communications Express는 데이터 캐싱이 사용 불가능할 것으로 예상합니다.

LDAP SDK 캐시 조정

항목이 캐시에서 얼마나 오래 머무를 것인지 그리고 캐시가 얼마나 커질 수 있는지 조정하는 두 매개 변수가 있습니다.

캐시를 조정하려면 다음 표에 표시되는 매개 변수 중 하나 이상을 편집합니다.

표 21–2 LDAP SDK 캐시를 구성하는 ics.conf 매개 변수


매개 변수	설명 및 기본값
`service.ldapmemcachettl`	현재 구현되지 않은 매개 변수입니다. `ldap_cache` 디렉토리의 내용을 수동으로 제거한 후 Calendar Server를 다시 시작해야 합니다. `service.ldapmemcache`가 `"yes"`이면 이 매개 변수는 항목을 캐시할 수 있는 최대 시간(초)을 설정하는 데 사용됩니다. 이 값이 `“0”`이면 한 항목을 캐시에 저장할 수 있는 시간 제한이 없습니다. 기본값은 `“30”`입니다.
`service.ldapmemcachesize`	`service.ldapmemcache`가 `"yes"`인 경우, 이 매개 변수는 캐시가 사용할 최대 메모리 양(바이트)을 설정하는데 사용됩니다. `“0”`이면 캐시에는 크기 제한이 없습니다. 기본값은 `“131072”`입니다.

자동 백업 조정

디스크에서 보관하는 백업의 수 및 가용 디스크 공간을 초과하지 않을 필요성 사이에 균형점을 찾아야 합니다. 아카이브 및 핫 백업이 차지하는 디스크 공간 관리에 도움이 되도록 한번에 몇 개의 백업 복사본을 유지할 수 있는지 그리고 다른 복사본의 정리를 트리거할 디스크 공간 임계값이 있는지 결정하는 다양한 ics.conf 매개 변수의 설정을 바꿀 수 있습니다.

각 백업 유형, 즉 아카이브 및 핫 백업에 대해 조정할 수 있는 세 가지 유형의 매개 변수가 있습니다.

mindays – 디스크에 백업을 보관할 수 있는 최소 일 수입니다.
maxdays – 디스크에 백업을 보관할 수 있는 최대 일 수입니다.
threshold – 사용된 디스크 공간의 백분율입니다. 트리거 포인트로 사용됩니다.

Calendar Server는 디스크 공간의 임계값을 초과하지 않으면서 최대 일 수 동안 백업을 유지합니다. 그러므로 현재 백업으로 디스크 사용량이 임계값을 초과한다면 시스템은 가장 오래된 백업 복사본을 제거하고 디스크 공간이 임계값 아래로 떨어지는지 확인합니다. 다른 백업 복사본을 제거하여디스크 백업 수가 최소 백업 복사본 수 이하로 줄어들거나 디스크 사용량이 임계값 아래로 줄어들 때까지 오래된 백업 복사본을 계속 제거합니다.

그러므로 임계값 매개 변수로 백업의 디스크 공간 사용량을 관리할 수 있습니다. 그리고 반대로 허용된 복사본 수 및 디스크 공간의 양을 조정하여 디스크에 보관하는 백업 복사본 수를 관리할 수 있습니다.

다음 표에서는 디스크에 유지된 백업의 수와 디스크 공간을 제어하는 ics.conf 매개 변수를 나열합니다.

표 21–3 디스크에 유지할 백업의 수를 설정하기 위해 사용되는 ics.conf 매개 변수


ics.conf 매개 변수	기본 설정	설명
`caldb.berkeleydb.hotbackup.mindays`	3	디스크에 핫 백업이 보관되는 최소 일 수
`caldb.berkeleydb.hotbackup.maxdays`	6	디스크에 핫 백업이 보관되는 최대 일 수
`caldb.berkeleydb.hotbackup.threshold`	70	핫 백업에 사용되는 디스크 공간의 백분율초과되면 가장 오래된 복사본 제거를 트리거합니다.
`caldb.berkeleydb.archive.mindays`	3	디스크에 아카이브 백업이 보관되는 최소 일 수
`caldb.berkeleydb.archive.maxdays`	6	디스크에 아카이브 백업이 보관되는 최대 일 수
`caldb.berkeleydb.archive.threshold`	70	아카이브 백업에 사용되는 디스크 공간의 백분율초과되면 가장 오래된 복사본 제거를 트리거합니다.

여러 CPU에 걸쳐 로드 균형 조정 사용

서버에 여러 개의 CPU가 있는 경우 Calendar Server는 기본적으로 HTTP 서비스(cshttpd 프로세스) 및 분산 데이터베이스 서비스(csdwpd 프로세스)를 분산시킵니다.

service.http.numprocesses 및 service.dwp.numprocesses 매개 변수는 각 서비스를 위해 실행되는 실제 프로세스 수를 결정합니다. 기본적으로 이 두 매개 변수는 설치하는 동안 서버의 CPU 수로 설정되지만 값을 재설정할 수 있습니다. 예를 들어, 서버에 8개의 CPU가 있지만 4개의 CPU에서만 cshttpd 및 csdwpd 프로세스를 실행하려면 매개 변수를 다음과 같이 설정합니다.

service.http.numprocesses="4"
 service.dwp.numprocesses="4"

로드 균형 조정을 비활성화하려면 service.loadbalancing 매개 변수를 ics.conf 파일에 추가하고 “no”로 설정합니다. 변경 내용을 적용하려면 Calendar Server를 다시 시작합니다.

시간 초과 값 사용

Calendar Server 성능은 다양한 ics.conf 매개 변수의 시간 초과 값을 사용하여 조정할 수 있습니다.

다음과 같은 시간 초과 유형이 있습니다.

ics.conf 매개 변수 편집에 대한 자세한 내용은 ics.conf 구성 파일 편집을 참조하십시오.

csadmind의 시간 초과 값

다음 표에서는 관리(csadmin) 서비스에서 사용하는 ics.conf 파일의 Calendar Server 시간 초과 매개 변수를 설명합니다.

표 21–4 관리 서비스(csadmin)의 HTTP 시간 초과 값


매개 변수	설명
`service.admin.idletimeout`	csadmind 서비스가 유휴 HTTP 연결 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 120초(2분)입니다.
`service.admin.resourcetimeout`	csadmind 서비스가 자원 달력에 대한 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 900초(15분)입니다.
`service.admin.sessiontimeout`	csadmind 서비스가 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 1800초(30분)입니다.

최종 사용자의 HTTP 시간 초과 값

다음 표에서는 최종 사용자에게 적용되는 ics.conf 파일의 Calendar Server HTTP 시간 초과 매개 변수를 설명합니다.

표 21–5 최종 사용자용 ics.conf의 HTTP 시간 초과 값(cshttpd 서비스)


매개 변수	설명
service.http.idletimeout	`cshttpd` 서비스가 유휴 HTTP 연결 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 `"120"`초(2분)입니다.
service.http.resourcetimeout	`cshttpd` 서비스가 달력 자원의 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 `"900"`초(15분)입니다.
service.http.sessiontimeout	`cshttpd` 서비스가 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 `"1800"`초(30분)입니다.

GSE 대기열 시간 초과 값

다음 ics.conf 파일 매개 변수는 Calendar Server가 그룹 예약 엔진(GSE) 대기열에서 들어오는 작업을 스캔하기 전에 기다리는 시간을 초 단위로 지정합니다.

gse.belowthresholdtimeout="3"

할당된 최대 스레드보다 많은 작업이 대기열에 있으면 마지막 스레드는 항상 대기열을 다시 스캔합니다. 따라서 이러한 설정은 작업의 수가 할당된 최대 스레드보다 적을 때만 적용됩니다.

기본값은 "3"입니다. 이 숫자를 증가시키면 서버가 대기열을 검색하는 빈도가 감소하고 전체적인 성능이 향상될 수 있습니다. 하지만 이벤트의 크기가 증가하여 대기열이 너무 커지면 시간을 줄여 대기열의 처리 속도를 높일 수 있습니다. 그러면 전반적인 성능은 저하되지만 이벤트 업데이트 속도는 빨라집니다.

22장 문제 해결

이 장에서는 시스템에 문제가 있는지 여부와 문제의 원인을 확인하는 데 사용할 수 있는 몇 가지 문제 해결 기술에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

디버깅 정보 설정

전체 시스템을 “디버그 모드”로 실행하는 ics.conf 매개 변수는 없지만 이 절에서는 유용한 디버그 정보를 가져오는 몇 가지 방법을 설명합니다.

주 –

과도한 로깅과 모니터링은 성능에 부정적인 영향을 주므로 필요하지 않은 경우 해제하십시오.

로깅 수준 올리기

다음 표에 표시된 매개 변수를 사용하여 로깅의 세부 수준을 늘리십시오.

매개 변수	설명 및 기본값
`logfile.loglevel`	`CRITICAL`, `ALERT`, `ERROR`, `WARNING`, `NOTICE` 및 `INFORMATION`을 포함하여 모든 수준을 기록하려면 `DEBUG`로 설정합니다. 이 설정은 모든 로그에 적용됩니다.

사용 가능한 다른 로그에 대한 자세한 내용은 Calendar Server 로그 파일 사용을 참조하십시오.

LDAP 캐시에 대한 액세스 로깅 활성화

LDAP 데이터 캐시에 대한 모든 액세스를 기록하고 로그(보고서)를 출력하려면 다음 표에 표시된 ics.conf 매개 변수를 설정합니다.

매개 변수

설명 및 기본값

local.ldap.cache.stat.enable

LDAP 데이터 캐시에 대한 액세스 로그 여부 및 로그 파일의 통계 인 쇄 여부를 지정합니다. 기본값은 “no”(통계 기록 안 함)입니다. 통계 로깅을 사용 가능하게 하려면 “yes”로 설정합니다.

성능 개선을 위해 디버그 모드에서만 사용하십시오.

local.ldap.cache.stat.interval

각 통계 보고서가 로그 파일에 기록되는 간격을 초 단위로 지정합니 다. 기본값은 “1800”초(30분)입니다.

로깅이 사용 가능한 경우에만 활성화됩니다. 간격을 줄이면 문제를 정확히 식별하는데 도움이 됩니다. 간격을 늘리면 시스템 로드가 줄어듭니다.

LDAP 캐시 지우기

Calendar Server에는 현재 LDAP 캐시 데이터를 만료하기 위한 논리가 없습니다. ldap_cache 디렉토리의 내용을 수동으로 제거한 후 Calendar Server를 다시 시작해야 합니다.

LDAP 캐시 지우기

단계

Calendar Server를 중지합니다.

/var/opt/SUNWics5/csdb/ldap_cache 디렉토리의 모든 파일을 제거하되, ldap_cache 디렉토리 자체는 제거하지 않습니다.

Calendar Server를 다시 시작합니다.

Calendar Server 유틸리티를 사용하여 시스템 모니터

시스템을 모니터하려면 다음 Calendar Server 유틸리티를 사용합니다.

csmonitor – 필요한 디버그 수준을 지정합니다. 숫자가 클수록 메시지가 더 자세하게 표시됩니다.
csstats – list 명령을 사용하여 counter.conf 파일에 정의된 카운터 객체의 통계 정보를 표시합니다.
cstool – 이 유틸리티를 사용하여cshttpd, csadmind, enpd 등과 같은 서비스를 핑합니다.

Calendar Server 유틸리티에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

LDAP 문제 해결

호스트된 환경을 처음으로 만드는 경우 도메인, 컨테이너, 사용자 및 자원에 대한 해당 항목을 추가하여 LDAP의 DC 트리를 만들어야 합니다. cscal과 같은 Calendar Server 유틸리티를 사용할 때 DC 트리가 없으면 "Initialization failed .... exiting".과 같은 오류 메시지가 표시됩니다.

DC 트리 루트에 최소한 하나(기본값)의 도메인이 있는지 확인합니다. 새 호스트된 도메인 만들기의 지침에 따라 DC 트리 구조를 만듭니다.

마이그레이션 유틸리티 문제 해결

Calendar Server는 달력 데이터베이스 및 LDAP 디렉토리 마이그레이션을 위한 여러 가지 유틸리티를 제공합니다. 이 절은 다음 내용으로 구성되어 있습니다.

기술 지원부에 문의하기 전에 수행할 작업

일반적으로 마이그레이션 유틸리티 사용 문제가 있는 경우 다음과 같은 정보를 미리 수집한 상태에서 기술 지원부에 문의해야 합니다.

문제가 있는 데이터베이스에 대한 백업 복사본
관련된 모든 로그의 복사본
코어를 포함한 모든 오류 출력 메시지

마이그레이션 유틸리티 위치

다음 목록에 표시된 위치에서 다양한 마이그레이션 유틸리티와 해당 설명서를 찾을 수 있습니다.

스키마 마이그레이션 유틸리티(commdirmig): 이 유틸리티는 Delegated Administrator에 번들로 함께 제공되는 별도로 설치 가능한 구성 요소입니다. 이 유틸리티는 LDAP 디렉토리를 스키마 1에서 스키마 2로 마이그레이션합니다. 이 유틸리티에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Migration Guide를 참조하십시오.
Calendar Server 5 to Calendar Server 6 Migration 유틸리티(cs5migrate): 기술 지원부에서는 이 유틸리티가 들어 있는 마이그레이션 번들과 관련 설명서를 제공합니다.
Calendar Server Migration 유틸리티(csmig): 이 유틸리티는 Calendar Server와 함께 설치됩니다. 관련 설명은 문제 해결 절이 들어 있는 4 장, 데이터베이스 마이그레이션 유틸리티에 나와 있습니다. 호스트된 도메인 및 LDAP CLD(달력 조회 데이터베이스) 플러그 인을 사용하는 경우 이 유틸리티를 실행해야 합니다.
Calendar Server Virtual Domain Migration 유틸리티(csvdmig ): 이 유틸리티는 Calendar Server와 함께 설치됩니다. 관련 설명은 4 장, 데이터베이스 마이그레이션 유틸리티에 나와 있습니다. 이 유틸리티를 사용하여 호스트된 도메인에 대한 달력 데이터베이스 및 LDAP 디렉토리 항목을 준비합니다.
Calendar Server 2 to Calendar Server 6 Migration 유틸리티( ics2migrate): 이 유틸리티는 Calendar Server와 함께 설치됩니다. 관련 설명은 4 장, 데이터베이스 마이그레이션 유틸리티에 나와 있습니다. 이 유틸리티를 사용하여 Calendar Server 5와 호환되도록 Calendar Server 2 데이터베이스를 마이그레이션합니다.
Netscape Calendar Server 4 to Calendar Server 5 Migration 유틸리티(ncs4migrate): 이 유틸리티는 기술 지원부를 통해서만 구할 수 있습니다. 설명서는 유틸리티 패키지에 포함되어 있습니다. 이 유틸리티는 Netscape Calendar Server 4를 Calendar Server 5로 마이그레이션합니다. 이러한 마이그레이션을 수행할 경우 소스 데이터베이스의 데이터가 일관되지 못하므로 특별히 주의해야 합니다. 수동으로 처리해야 할 작업이 많습니다. 이 유틸리티는 기술 지원부에서만 구할 수 있습니다. 설명서는 유틸리티 패키지에 포함되어 있습니다. 이 유틸리티는 Netscape Calendar Server 4에서 Calendar Server 5로 마이그레이션합니다. 이러한 마이그레이션을 수행할 경우 특별히 주의해야 합니다. 이 유틸리티를 실행하려면 먼저 소스 파일로 여러 가지 작업을 수행해야 합니다. 전문가 서비스의 도움을 받아 마이그레이션을 계획할 수 있습니다.

Calendar Server 문제 해결

이 절에서는 비데이터베이스 문제에 대한 다양한 문제 해결 정보를 제공합니다. 다음 항목에 대해 설명합니다.

정보 –

또한 SSL 장에 SSL에 대한 문제 해결 절인

SSL 문제 해결이 나와 있습니다.

달력 서비스 핑

서비스가 지정된 포트 번호를 수신하는지 확인하려면 cstool 유틸리티 ping 명령을 사용합니다. 서비스 핑으로 해당 서비스가 실제 실행 중인지 확인할 수는 없지만 소켓 연결을 받아들일 수 있는지 여부를 알려 줍니다.

cstool의 서비스 옵션

Calendar Server 서비스 옵션은 다음과 같습니다.

http: HTTP 서비스(cshttpd)
admin: 관리 서비스(csadmind)
ens: 이벤트 알림 서비스(enpd)

주 –

DWP 서비스(csdwpd) 또는 알림 서비스(csnotifyd)는 핑할 수 없습니다.

cstool 예제

예를 들어, 호스트 이름이 calserver인 시스템을 핑하여 cshttpd 서비스가 포트 80을 수신하는지 확인하려면 다음 명령을 사용합니다.

cstool -p 80 -h calserver ping http

기본적으로 cstool은 응답이 올 때까지 120초 동안 대기하지만 -t timeout 옵션을 사용하면 값을 변경할 수 있습니다.

전체적인 유틸리티 참조 자료를 보려면 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

주 –

cstool을 실행하려면 Calendar Server가 실행 중이어야 합니다.

start-cal 문제 해결

start-cal을 실행할 때 모든 달력 서비스가 시작되지 않은 경우 시작된 서비스를 중지한 다음 다시 시작해야 합니다. 예를 들어, enpd, csnotifyd 및 csadmind는 시작되었지만 cshttpd는 시작되지 않았으면 enpd, csnotifyd 및 csadmind를 중지해야 합니다.

달력 서비스를 시작하려면

단계

Calendar Server가 실행되고 있는 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

start-cal을 사용하여 서비스를 중지한 다음 다시 시작합니다. 예를 들면 다음과 같습니다.

cal_svr_base/SUNWics5/cal/sbin/start-cal

start-cal은 다양한 달력 서비스를 시작하기 전에 stop-cal 명령을 실행합니다.

stop-cal이 중지되지 않는 경우 중지되지 않은 자식 프로세스가 있을 수 있습니다. 이 문제를 해결하려면 stop-cal 문제 해결을 참조하십시오.

stop-cal 문제 해결

Calendar Server가 종료될 경우에 고려해야 할 두 가지 사항이 있습니다.

자식 프로세스를 중지하려면

stop-cal을 실행한 후 일부 자식 프로세스가 중지되지 않았을 수 있습니다. 예를 들어, stop-cal은 cshttpd 부모 프로세스를 중지할 수 있지만 cshttpd 자식 프로세스는 중지할 수 없습니다. 이 경우 다음 절차를 사용하여 나머지 Calendar Server 프로세스를 개별적으로 중지해야 합니다.

단계

Calendar Server가 실행되고 있는 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

각 서비스마다 ps 명령을 입력하여 나머지 Calendar Server 프로세스의 프로세스 아이디(PID)를 확인합니다.
ps -elf | grep cs-process
여기서 cs-process는 enpd, csnotifyd, csdwpd, csadmind 또는 cshttpd입니다. 예를 들면 다음과 같습니다.
ps -elf | grep cshttpd

아직 실행 중인 각 프로세스의 PID를 사용하여 kill -15 명령을 입력하여 프로세스를 종료시킵니다. 예를 들면 다음과 같습니다. kill -15 9875

각 ps 명령을 다시 입력하여 모든 Calendar Server 프로세스가 중지되었는지 확인합니다.
If a Calendar Server process is still running, enter a kill -9 command to kill it. For example: kill -9 9875
주 –
Calendar Server를 실행하는 Linux 시스템에서 ps 명령을 사용하여 달력 프로세스를 검색하면 혼동되는 결과가 나올 수 있습니다. Linux에서 ps 명령은 프로세스 목록이 아니라 실행 중인 스레드의 목록을 반환합니다. 프로세스만 표시하는 해결 방법은 알려져 있지 않습니다.

잘못된 종료 후 복구하려면

Calendar Server가 제대로 종료되지 않은 경우 다음 단계를 수행합니다.

단계

이전 절차 stop-cal 문제 해결의 단계를 수행합니다.

LDAP 데이터 캐시 데이터베이스 디렉토리에서 모든 파일을 수동으로 삭제합니다.

남아 있는 이러한 파일이 데이터베이스를 손상시킬 수 있습니다. 파일을삭제하려면 다음을 수행합니다.
1. LDAP 데이터 캐시 디렉토리로 변경합니다.
  
  기본값은 /opt/SUNWics5/csdb/ldap_cache이지만 ics.conf 파일의 local.ldap.cache.homedir.path 매개 변수에 지정된 디렉토리를 사용합니다.
2. 디렉토리에서 모든 파일을 제거합니다.
  
  예를 들면 다음과 같습니다. rm *.*
3. 모든 파일이 제거되었는지 확인합니다.
  
  예를 들면 다음과 같습니다. ls

Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP 데이터 캐싱 구성 방법에 대한 자세한 내용은 LDAP를 위한 Calendar Server 구성을 참조하십시오. LDAP 데이터 캐시에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide를 참조하십시오.

백엔드 서버에 연결할 수 없음

백엔드 서버를 핑하여 서버가 응답하는지 확인합니다.

응답할 경우 3단계로 가고 응답하지 않는 경우 실패 원인을 확인하고 백엔드 서버가 다시 작동하는 경우 3단계의 작업을 계속합니다.
CLD 캐시를 지웁니다. CLD 캐시 지우기를 참조하십시오.

CLD 캐시 옵션을 사용하고 있으며 ics.conf 매개 변수의 서버 이름을 업데이트한 경우, 서버 이름을 제거하려면 CLD 캐시를 지워야 합니다. CLD 캐시에 이전 버전의 항목이 있으면 프런트엔드 서버가 정확한 백엔드 서버로 연결을 설정하지 못하게 되거나 Calendar Server가 옮겨진 후에 달력을 찾을 수 없게 됩니다.
Calendar Server를 다시 시작합니다.

달력을 찾을 수 없음

CLD 캐시 옵션을 사용 중이고 하나 이상의 달력을 다른 백엔드 서버로 이동했거나 백엔드 서버의 이름을 변경한 경우 다음 단계를 수행합니다.

다음의 달력 이동 절차를 따라야 합니다.

사용자 달력 관리
CLD 캐시를 지웁니다. CLD 캐시 지우기를 참조하십시오.

하나 이상의 달력을 다른 백엔드 서버로 이동한 경우 CLD 캐시가 이전 상태가 됩니다. CLD 캐시를 새로 고치려면 캐시를 지워 다시 작성해야 합니다.

프록시 인증을 사용하여 로그인하려고 할 때 “Unauthorized”라는 메시지가 표시됨

service.http.allowadminproxy가 “yes”로 설정되어 있는지 확인합니다.
admin-user에게 Calendar Server 관리자 권한이 있는지 확인합니다.
admin-password가 올바른지 확인합니다.
calendar-user가 올바른 Calendar Server 사용자인지 확인합니다.

올바르게 완료되지 않는 검색 문제 해결

LDAP 디렉토리 서버 구성의 nsslapd-sizelimit 및 nsLookthroughLimit 속성은 검색이 제대로 완료될 수 있을 만큼 커야 합니다. nsSizeLimit이 부족할 경우 끝이 잘려나갈 수 있으며 결과가 표시되지 않습니다. nsLookthroughLimit이 부족할 경우 검색이 완료되지 않을 수 있습니다.

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

제한 속성에 해당 값이 있는지 확인

단계

이러한 속성 값이 제대로 설정되어 있는지 확인하려면 다음 명령을 사용합니다.

ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

여기서 base는 Calendar Server에 대한 사용자 및 자원 데이터가 있는 LDAP 기본 DN이고 user는 최종 사용자가 사용자 인터페이스의 검색 대화 상자에 입력할 수 있는 값입니다.

LDAP 서버가 오류를 반환하면 nsSizeLimit 또는 nsLookthroughLimit 속성이 충분히 크게 설정되지 않았기 때문일 수 있습니다.

제한 속성을 적절한 값으로 설정하려면

이러한 속성의 DN은 다음과 같습니다.

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

단계

ldapmodify를 사용하여 nsLookthroughLimit 값을 동적으로 설정합니다.

이속성을 변경하려고 Directory Server를 중지했다가 다시 시작할 필요가 없습니다.

기본값은 5000입니다. 검색 결과가 보고되지 않는 경우 이 값을 늘릴 수 있습니다. 그러나, 그렇게 하면 LDAP 서버 속도가 느려질 수 있습니다.

제한이 사용되지 않게 하려면 제한을 -1로 설정할 수 있습니다. 그렇게 하면 시스템이 중단될 수 있으므로 주의하십시오

nsslapd-sizelimit을 더 높은 값으로 설정하려면 다음 단계를 수행해야 합니다.
1. Directory Server를 중지합니다.
2. Edit the dse.ldif file.
3. Directory Server를 다시 시작합니다.
  
  주 –
  ldapmodify를 사용하고 dse.ldif 파일을 편집하는 방법에 대한 자세한 내용은 다음에서 Directory Server 설명서를 참조하십시오.
  
  http://docs.sun.com/coll/1316.1 및 http://docs.sun.com/coll/1404.1

csstored에서 성가신 일상 메시지 해제

start-cal 명령은 csstored 프로세스가 구성되어 있지 않더라도 기본적으로 이 프로세스를 시작합니다. 구성되지 않은 csstored 프로세스는 csstored가 실행 중인 모든 시스템에서 해당 프로세스가 구성되지 않았다는 메시지를 24시간마다 표시합니다.

csstored가 구성되지 않은 프로세스를 실행하지 못하게 하여 메시지를 비활성화합니다. csstored 프로세스가 실행되지 않게 하려면 메시지가 표시되는 각 시스템에 표시된 다음 ics.conf 매개 변수를 설정합니다.

service.store.enable=”no”

자동 백업을 수행하도록 csstored를 구성한 시스템에서는 프로세스를 비활성화하지 않도록 주의하십시오.

데이터베이스 문제 처리

이 절은 Calendar Server 데이터베이스를 포함하여 다양한 문제에 대해 설명합니다.

Berkeley 데이터베이스 도구 찾기

많은 문제 해결 단계를 수행하려면 Berkeley 데이터베이스 유틸리티 프로그램에 액세스해야 합니다. 이러한 유틸리티 프로그램의 한 버전을 Calendar Server 번들에서 사용할 수 있지만 유틸리티 프로그램이 지원되지 않습니다. 자세한 내용은 Sleepycat Software(http://www.sleepycat.com)에서 직접 확인할 수 있습니다.

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

Berkeley 데이터베이스 유틸리티에 액세스하려면

LD_LIBRARY_PATH 환경 변수를 설정하고 내보내 다음 디렉토리를 반영합니다.

cal_svr_base/SUNWics5/cal/tools/unsupported/bin/

사용 가능한 도구 목록

다음 표에는 일반적으로 사용되는 Berkeley 데이터베이스 도구(유틸리티 프로그램)가 나열되어 있습니다.

데이터베이스 도구	설명
`db_archive`	더 이상 사용되지 않는 로그 파일의 경로 이름을 표준 출력에 한 줄당 하나씩 씁니다.
`db_checkpoint`	데이터베이스 로그를 모니터하고 검사점 루틴을 주기적으로 호출하여 검사하는 데몬 프로세스입니다.
`db_deadlock`	데이터베이스 환경 잠금 영역을 선회하고 교착 상태가 감지될 때마다 잠금 요청을 중지하거나 시간 초과된 잠금 요청을 중지합니다.
`db_dump`	`db_load` 유틸리티에서 인식되는 일반 텍스트 형식의 표준 출력에 지정된 파일을 씁니다.
`db_load`	표준 입력을 읽어 지정된 데이터베이스 파일로 로드합니다. 파일이 없는 경우 파일을 만듭니다.
`db_printlog`	로그 파일을 사람이 읽을 수 있는 형식으로 덤프하는 디버깅 유틸리티입니다.
`db_recover`	예상치 못한 응용 프로그램, 데이터베이스 또는 시스템 오류가 발생한 후 데이터베이스를 일관된 상태로 복원합니다.
`db_stat`	데이터베이스 환경에 대한 통계를 표시합니다.
`db_verify`	하나 이상의 파일과 해당 파일에 포함된 데이터베이스의 구조를 확인합니다.

데이터베이스 교착 상태 검색 및 수정

Berkeley 데이터베이스가 교착 상태인 경우 데이터베이스를 재설정해야 합니다. 이러한 조건은 가능한 빨리 검색해야 합니다

시스템에서 데이터베이스를 주기적으로 확인하여 교착 상태를 검색하고 관리자에게 알리게 하려면

단계

구성을 변경할 권한을 가지고 관리자로 로그인합니다.

/etc/opt/SUNWics5/cal/config 디렉토리로 변경합니다.

이전 ics.conf 파일을 복사하고 이름을 바꿔 저장합니다.

필요한 경우 ics.conf를 다음 값으로 편집합니다.

local.caldb.deadlock.autodetect=”yes”

주 –
이 매개 변수가 “yes”로 설정되어 있는 경우 잠금 영역을 모니터하는 db_deadlock 데몬이 시작됩니다.

데이터베이스 손상 검색

달력 데이터베이스 손상은시스템 자원 경쟁, 하드웨어 오류, 응용 프로그램 오류, 데이터베이스 오류 및 사람에 의한 실수 등 여러 가지 원인에 의해 발생할 수 있습니다. 이 절에서는 Calendar Database 손상을 검색하는 방법에 대해 설명합니다.

데이터베이스 손상 기본

누구도 손상 없는 데이터베이스를보장할수없습니다데이터 손실과 작업 중단 시간을 최소화할 수 있습니다. 데이터베이스와 Calendar Server를 자세히 모니터하여 손상을 조 기에 검색해야 합니다. 손상이 발견될 경우 복구할 수 있도록 전체 백업을 자주 수행해야 합니다.

달력 데이터베이스에는 다음과 같은 두 가지 수준의 손상이 발생할 수 있습니다.

응용 프로그램 수준–많은 데이터베이스 파일 중 하나에 있는 위반 항목이 서버가 실행되지 않게 합니다.
데이터베이스 수준–Berkeley 데이터베이스 페이지의 손상이 다양한 문제를 발생시킵니다. csdb check 실행 중의 루핑 현상이 공통 증상입니다. 또 다른 공통 증상으로 다음과 같은 오류 메시지가 발생합니다.
```
“illegal page type or format”, 
or “page 97895 doesn’t exist, create flag not set.”
```

로그 파일 모니터링

경보 로그를 포함하여 Calendar Server 로그 파일을 모니터하여 데이터베이스 손상을 나타내는 오류 메시지가 있는지 확인합니다. 로그 파일에 대한 자세한 내용은 Calendar Server 로그 파일 사용을 참조하십시오.

정기적으로 로그 파일에서 경보, 심각, 오류 및 경고 수준의 오류가 있는지 검사하고 그런 오류가 발견되면 해당 이벤트를 조사하여 Calendar Server 작업과 관련된 원인을 찾아야 합니다. 알림 및 정보 수준의 로그 이벤트는 정상적인 Calendar Server 작업 중에 발생하며 서버 작동을 모니터할 수 있도록 제공됩니다.

데이터베이스 디렉토리에서 어떤 트랜잭션 로그 파일도 제거하지 마십시오. 트랜잭션 로그 파일은 트랜잭션 업데이트(추가, 수정, 삭제)를 포함하고 있으므로 이 파일을 제거하면 복구 불가능한 달력 데이터베이스 손상을 발생시킬 수 있습니다.

주 –

Calendar Server 기술 지원 요청 시 문제 해결에 도움이 될 로그 파일을 제공해야 하는 경우가 있습니다.

csmonitor 사용

csmonitor 유틸리티를 사용하여 Calendar Server를 모니터합니다. 이 유틸리티는 여러 트랜잭션 로그 파일이 있거나 달력 데이터베이스의 디스크 공간 부족 등과 같은 문제가 검색될 경우 관리자에게 경고 전자 메일을 보냅니다. 자세한 내용은 csmonitor를 참조하십시오.

달력 데이터베이스 손상 검사 방법

check 명령을 사용하여 달력 등록 정보(calprops) 및 이벤트와 작업(태스크)을 포함한 달력 데이터베이스에서 손상을 검색합니다. check 명령이 해결할 수 없는 비일관성 오류가 발견된 경우에는 출력으로 상황을 보고합니다.

check 명령은 경보나 그룹 예약 엔진(GSE) 데이터베이스의 손상을 확인하지 않습니다.

단계

Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server는 실행 중이어도 되고 중지해도 되지만 가능하면 Calendar Server를 중지하는 것이 좋습니다.

아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다.

데이터베이스(.db) 파일만 복사합니다. 공유(__db.*) 또는 로그(log.*) 파일은 복사할 필요가 없습니다.

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

예를 들어, Solaris 운영 체제에서 기본 디렉토리에 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin

달력 데이터베이스의 복사본에 대해 check 명령을 실행합니다.
./csdb check dbdir /tmp/check.out
dbdir을 지정하지 않은 경우 check는 현재 디렉토리의 데이터베이스를 사용합니다.

check 명령은 많은 정보를 생성할 수 있으므로 이번 예와 같이 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.

check를 마치면 출력 파일을 검토합니다. 데이터베이스가 손상된 경우 rebuild 명령을 실행합니다.

손상된 달력 데이터베이스 재구축을 참조하십시오.

데이터베이스가 손상된 경우 서비스 중단 방지(읽기 전용 모드)

이 절에서는 복구 모드에서 손상된 데이터베이스를 액세스 가능한 상태로 유지하는 방법에 대해 설명하며, 다음 내용으로 구성되어 있습니다.

읽기 전용 모드 사용

데이터베이스 손상이 발생할 경우 서비스 중단을 방지하는 한 가지 방법은 데이터베이스를 읽기 전용 모드로 전환하는 것입니다. 읽기 전용 모드에서는 최종 사용자가 데이터베이스 항목을 읽을 수 있지만 항목을 추가, 수정 또는 삭제할 수 없습니다. 최종 사용자가 달력 데이터를 추가, 수정 또는 삭제하려고 하면 오류 메시지가 표시됩니다. 또한, 데이터베이스가 읽기 전용 모드인 동안에는 달력 이벤트와 할 일을 추가, 수정 또는 삭제하는 관리자 도구가 작동되지 않습니다.

주 –

읽을 수 없는 지점에서 데이터베이스가 손상된 경우 백업을 복원할 수 있을 만큼 충분한 시간 동안 서비스를 중단해야 합니다. 백업을 복원하는 가장 빠른 방법은 손상 없는 핫 백업을 사용하는 것입니다. 복원하기 전에를 참조하십시오.

데이터베이스를 읽기 전용 모드로 전환하려면

단계

필요하지 않은 경우 달력 서비스를 일시적으로 중지하여 데이터베이스의 추가 손상을 방지할 수 있습니다.

달력 서비스를 중지하려면

cal_svr_base/SUNWics5/cal/sbin/stop-cal

명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.

cd /etc/opt/SUNWics5/config

달력 데이터베이스에 대한 읽기 전용 모드를 지정합니다.

caldb.berkeleydb.readonly=”yes”

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.

cal_svr_base /SUNWics5/cal/sbin/start-cal

ics.conf 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

일반 데이터베이스 오류 처리

이 절에서는 일반적인 몇 가지 데이터베이스 오류에 대해 설명하고 치료 방법을 제안합니다. 이 절은 다음 내용으로 구성되어 있습니다.

csadmind가 시작되지 않거나 시작 중에 충돌함

csadmind는 그룹 예약 엔진(GSE)과 경보 디스패치 엔진을 모두 처리하는 서비스이기 때문에 GSE 대기열이나 경보 대기열의 위반 항목으로 인해 이러한 문제가 발생할 수 있습니다.

치료 방법

단계

csadmind가 실행 중이 아닌 경우 stop-cal을 즉시 실행합니다.

달력 서버를 실행된 상태로 두면 트랜잭션 로그가 누적되므로 데이터베이스에 추가 손상이 발생하여 트랜잭션 로그 파일을 데이터베이스에 맞게 조정하는 데 더 많은 시간이 걸릴 수 있습니다.

csadmind을 다시 시작해 보십시오(start-cal 다시 실행).

성공적으로 시작되면 다음을 수행하여 두 대기열이 작동하는지 확인합니다.
1. csschedule을 사용하여 GSE 대기열 검사
2. dbrig를 사용하여 경보 대기열 검사
  
  csschedule 및 dbrig 실행에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

csadmind가 덤프와 충돌하는 경우 pstack을 분석합니다.

추적 중에 GSE 관련 함수(GSE 문자가 포함되어 있음)가 발견되면 GSE 대기열의 첫번째 항목과 이벤트 데이터베이스의 참조 항목을 조사합니다. 대부분의 경우 GSE 항목에서 참조되는 이벤트가 위반 항목입니다. 이 문제를 해결하려면 다음을 수행합니다.
1. csschedule을 사용하여 GSE 항목을 제거합니다.
2. cscomponents를 사용하여 데이터베이스에서 위반 이벤트를 제거합니다.
  
  csschedule 및 cscomponents 실행에 대한 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.

항목이 손상되지 않은 경우 Calendar Server를 처리할 수 없는 특수한 경우일 수 있습니다.

다음 단계를 수행합니다.
1. 손상된 데이터베이스의 달력 환경 스냅샷을 만든 다음 고객 지원부에 문의하십시오.
  
  환경 백업을 만들려면
  1. 다음 위치에 있는 db_checkpoint 유틸리티를 사용합니다.
    
    cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint
  2. db_archive -s를 실행합니다.
    
    -s 옵션을 실행하여 모든 데이터베이스 파일을 식별한 다음 CD, DVD, 테이프 등과 같은 이동식 매체에 복사합니다.
  3. db_archive -l를 실행합니다.
    
    -l 옵션을 사용하여 모든 로그 파일을 식별하고 적용되지 않은 로그 파일을 이동식 매체에 복사합니다.
2. 서비스 중단을 방지하려면 달력 데이터베이스를 일시적으로 읽기 전용 상태로 전환하고 핫 백업 복사본으로 되돌립니다.
  - 달력 데이터베이스를 읽기 전용 상태로 전환하면 일시적으로 추가, 수정 또는 삭제 트랜잭션을 수행할 수 없게 됩니다. 최종 사용자가 달력 데이터를 추가, 수정 또는 삭제하려고 하면 오류 메시지가 표시됩니다. 또한, 데이터베이스가 읽기 전용 모드인 동안에는 달력 이벤트와 할 일을 추가, 수정 또는 삭제하는 관리자 도구가 작동되지 않습니다.
    
    달력 데이터베이스를 읽기 전용 모드로 전환하려면 ics.conf 파일을 편집하고 다음과 같이 매개 변수를 “yes”로 설정합니다.
    
    caldb.berkeleydb.readonly=”yes”
  - 자동 백업 복사본 복원에 나오는 지침에 따라 핫 백업 복사본으로 되돌립니다.
    
    csstored를 구성하여 활성화하면 몇 분 이내에 최신 상태의 핫 백업을 사용할 수 있습니다. 항상 핫 백업 복사본을 확인하여 복사본이 손상되지 않았는지 확인해야 합니다. (db_verify 실행)

기타 오류의 경우 덤프를 수행하고 절차를 다시 로드하여 데이터베이스를 복구할 수 있는지 확인합니다.

이 절차는 덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구 에 설명되어 있습니다.

서비스가 중단되어 최종 사용자가 연결할 수 없음–끊어진 잠금

이 문제는 Berkeley DB 데이터베이스 페이지 잠금을 보관하는 제어 스레드가 잠금을 해제하지 않고 종료되어 발생할 수 있습니다. 문제를 확인하려면 cshttpd 프로세스의 pstack 및 csadmind를 실행합니다. (pstack은/usr/bin/pstack에 있는 표준 UNIX 유틸리티임) 잠금을 위해 대기 중인 스레드가 표시됩니다.

문제를 해결하려면 다음과 같은 방법으로 Calendar Server를 다시 시작합니다.

단계

start-cal이 있는 디렉토리로 변경합니다.

cd cal_svr_base/SUNWics5/cal/sbin

start-cal 명령을 실행합니다.

./start-cal

csdb 재구축 완료 안 됨–데이터베이스 루핑

데이터베이스 루핑은 일반적으로 데이터베이스 파일이 손상되어 발생합니다. 데이터베이스가 손상되었기 때문에 복구할 수 없습니다. 다음과 같은 여러 가지 옵션이 있습니다.

단계

핫 백업으로 되돌립니다.

손상이 최근에 발생한 경우 핫 백업 중 하나를 사용할 수 있습니다.

재해 아카이브 복구 프로세스를 사용합니다.

제안되는 프로세스를 보려면 자동 백업 복사본 복원을 참조하십시오.

덤프를 사용하고 절차를 다시 로드합니다. 자세한 내용은 덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구 를 참조하십시오.

손상된 달력 데이터베이스 재구축

이 절에서는 csdb rebuild 명령 사용 방법을 설명하고 다음 내용으로 구성되어 있습니다.

재구축 개요

rebuild 명령은 달력 데이터베이스를 검사하고 달력 등록 정보(calprops) 이벤트 및 수행할 작업(태스크)이 손상되었는지 확인합니다. rebuild 명령이 비일관성을 발견한 경우 cal_svr_base /SUNWics5/cal/sbin/rebuild_db 디렉토리에 달력 데이터베이스(.db 파일)를 재구축합니다.

-g 옵션 없는 rebuild 명령은 그룹 예약 엔진(GSE) 데이터베이스를 제외하고 모든 데이터베이스를 재구축합니다. GSE 데이터베이스도 재구축하려면 -g 옵션을 포함시킵니다.

rebuild 명령을 사용하기 전에 GSE 데이터베이스에 항목이 있는지 확인하려면 csschedule -v list 명령을 실행한 다음 GSE가 항목 처리를 마치게 합니다.

달력 데이터베이스를 재구축하려면

단계

Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.

Calendar Server를 중지합니다.

달력 데이터베이스의 복사본을 만들어 /tmp/db 디렉토리에 넣습니다.

데이터베이스(.db) 파일과 로그(log.*) 파일을 복사합니다. 공유( __db.*) 파일은 복사할 필요가 없습니다.

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

예를 들어, Solaris 운영 체제에서 기본 디렉토리에 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin
주 –
sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.

달력 데이터베이스 복사본에 대해 rebuild 명령을 실행합니다.
./csdb rebuild /tmp/db /tmp/
데이터베이스 경로를 지정하지 않은 경우 rebuild는 현재 디렉토리를 사용합니다. /tmp/ 매개 변수는 다시 작성된 데이터베이스의 대상 디렉토리를 지정합니다.

GSE 데이터베이스도 재구축하려면 -g 옵션을 포함시킵니다.

rebuild 명령은 많은 정보를 생성할 수 있으므로 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.

주 –
항상 최신 백업 복사본을 사용하여 달력 데이터베이스를 재구축합니다.

그러나 심각한 데이터 손실이 발생했고 그 동안 정기적으로 데이터베이스를 백업했으며 2개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 재구축합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다.

예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601
그러면 rebuild 명령은 재구축된 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.

rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다.

해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt

이전 단계에서 rebuild가 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.

손상된 데이터베이스에 공유(__db.*) 또는 로그(log.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.

Calendar Server를 다시 시작합니다.

샘플 재구축 출력

다음 예에서는 이 명령과 그 결과 생성된 출력을 보여 줍니다.

# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

주 –

이전 샘플 출력에서는 이벤트와 할 일 데이터베이스가 각각 두 번씩 검색되었습니다. 이는 오류가 아닙니다. 먼저 달력 등록 정보 데이터베이스에서 정보를 확인한 다음 달력 등록 정보 데이터베이스에 액세스할 수 있는지 다시 확인합니다.

덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구

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

덤프 및 로드 개요

덤프 및 로드 절차를 사용하여 손상된 데이터베이스를 복구합니다. 덤프 및 로드 절차는 Berkeley 데이터베이스 db_dump 및 db_load 유틸리티를 사용하며, Calendar Server는 이러한 유틸리티를 다음 디렉토리에 보관합니다.

cal_svr_base/SUNWics5/cal/tools/unsupported/bin

db_dump 유틸리티는 데이터베이스 파일을 읽고 그 데이터베이스 항목을 db_load 유틸리티와 호환되는 형식을 사용하여 출력 파일에 기록합니다.

db_dump 및 db_load 유틸리티에 대한 설명서는 다음 Sleepycat Software 웹 사이트를 참조하십시오.

http://www.sleepycat.com/docs/utility/index.html

db_dump 및 db_load 유틸리티를 사용한 데이터베이스 복구의 성공 여부는 데이터베이스 손상 정도에 따라 결정됩니다. 데이터베이스를 성공적으로 복구하려면 db_dump 옵션을 여러 차례 시도해야 하는 경우도 있습니다. 그러나 데이터베이스가 심각하게 손상될 경우 복구가 불가능하고 따라서 데이터베이스의 손상 없는 최신 버전 핫 백업 또는 아카이브 백업으로 되돌려야할 수도 있습니다.

주 –

덤프 및 로드 절차를 수행하려면 달력 데이터베이스가 Berkeley DB 버전 3.2.9 이상이어야 합니다. 이전 버전인 경우에는 먼저 cs5migrate 유틸리티를 실행하여 달력 데이터베이스를 업그레이드합니다.

최신 버전의 cs5migrate를 구하려면 Sun 기술 지원에 문의하십시오.

덤프 및 로드 절차를 수행하려면

단계

Calendar Server가 실행되는 사용자 및 그룹(예: icsuser 및 icsgroup) 또는 수퍼유저( root)로 로그인합니다.

필요할 경우 Calendar Server를 중지합니다.

csbackup, Sun StorEdge Enterprise Backup^TM 소프트웨어 또는 Legato Networker® 같은 유틸리티를 사용하여 달력 데이터베이스를 백업합니다.

자세한 내용은 17 장, Calendar Server 데이터 백업 및 복원 을 참조하십시오.

db_dump 유틸리티를 사용하여 손상된 각 데이터베이스 파일을 덤프합니다.

데이터베이스 파일은 ics50calprops.db, ics50journals.db, ics50alarms.db, ics50events.db , ics50todos.db 및 ics50gse.db입니다.

데이터베이스가 복구될 때까지 또는 데이터베이스를 복구할 수 없음을 확인할 때까지 다음 옵션을 순서대로 사용하여 db_dump를 실행합니다.
- 옵션 없음 ? 심각하지 않은 데이터베이스 손상
- -r 옵션 보통 수준의 데이터베이스 손상
- -R 옵션 심각한 데이터베이스 손상-R 옵션은 부분 및 삭제된 레코드를 비롯하여 -r 옵션보다 더 많은 데이터를 손상된 데이터베이스로부터 덤프합니다.
  
  예를 들어, db_dump를 -r 옵션과 함께 실행하려면 다음 명령을 사용합니다.
  db_dump -r ics50events.db \> ics50events.db.txt

db_load 유틸리티를 사용하여 출력 파일을 새 데이터베이스 파일로 로드합니다.

예를 들면 다음과 같습니다.
db_load new.ics50events.db < ics50events.db.txt
db_load가 홀수 개수의 키나 데이터 항목을 보고할 경우 db_dump 출력 파일을 편집하여 홀수 키나 데이터 항목을 제거합니다. 그런 다음 db_load를 다시 실행합니다.

손상된 다른 데이터베이스 파일에 대해 앞의 두 단계를 반복합니다.

즉, 손상된 다른 데이터베이스 파일에 대해 db_dump를 실행합니다.

손상된 달력 데이터베이스 재구축에 설명된 대로 csdb rebuild 명령을 사용하여 복구된 데이터베이스 파일을 재구축합니다.

rebuild를 마치면 출력 파일에서 출력을 검토합니다. 해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt
csdb rebuild 명령이 성공하지 못한 경우 다음 db_dump 옵션(-r 또는 -R)을 사용하여 데이터베이스를 덤프합니다.

db_dump -R 옵션이 손상된 데이터베이스를 복구하지 못한 경우 Sun Microsystems 기술 지원 또는 영업 담당자에게 연락하여 도움을 받으십시오. 그 사이에 손상 없는 최신 데이터베이스 백업으로 되돌려야 할 수도 있습니다.

자동 백업 복사본 복원

10 장, 자동 백업 구성(csstored)에 설명된 자동 백업 기능을 사용한 경우 라이브 데이터베이스가 손상되었다면 핫 백업 복사본을 복원할 수 있습니다.

이 절에서는 서로 다른 두 자동 백업 복원 방법에 대해 설명합니다.

복원하기 전에

백업을 복원하기 전에 다음을 확인해야 합니다.

활성 데이터베이스를 손상시킨 트랜잭션을 진단했는지 여부
새 아카이브가 손상되지 않도록 손상 트랜잭션을 제거했거나 수정했는지 여부
손상된 데이터베이스를 다른 디렉토리나 이동식 매체에 복사하여 보관했는지 여부반드시 기술 지원부에 문의해야 합니다.

핫 백업 복원

라이브 데이터베이스가 손상된 경우 핫 백업을 가장 먼저 선택해야 합니다. 핫 백업을 복원하려면 다음 단계를 수행합니다.

단계

적용되지 않았거나 손상된 활성 데이터베이스 디렉토리에 쓰기 위해 열려 있는 로그 파일을 식별합니다.

쓰기 위해 열려 있는 로그를 닫습니다. 이 로그에는 최신 트랜잭션이 포함되어 있습니다.

새 (복구) 디렉토리를 만듭니다.

현재 핫 백업 복사본을 새 복구 데이터베이스 디렉토리에 복사합니다.

손상된 라이브 데이터베이스 디렉토리의 log.* 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.

데이터베이스의 아카이브 복사본을 저장하는 경우 경우 활성 데이터베이스에 적용되지 않은 로그를 아카이브 디렉토리에 복사하여 아카이브 백업 복사를 완료합니다.

새 복구 데이터베이스에 대해 지정된 -c -h 옵션과 함께 db_recover를 실행합니다.

예를 들어, 새 복구 디렉토리가 recoverydb인 경우 명령은 다음과 같습니다.

db_recover -c -h recoverydb

log.* 파일을 새 복구 디렉토리에 그대로 둡니다.

db_recover 프로그램이 로그 파일을 새 복구 데이터베이스에 적용했지만 버전 42부터 Berkeley DB는 로그 파일이 그대로 유지되는 것으로 기대합니다.

새 복구 디렉토리에 있는 데이터베이스 파일에 대해 db_verify를 실행합니다.

자세한 내용은 달력 데이터베이스 손상 검사 방법을 참조하십시오.

새 복구 디렉토리에 대해 csdb -v list를 실행합니다.

새 복구 디렉토리가 앞의 세 복구 단계를 모두 통과한 경우 손상된 이전 활성 데이터베이스를 새 복구 데이터베이스로 대체합니다.

새 스냅샷 역할을 하도록 새 라이브 데이터베이스를 핫 백업 디렉토리에 복사합니다.

다음에 정기 스냅샷을 찍을 때까지 모든 새 로그가 이 복사본에 적용됩니다.

Calendar Server를 시작합니다.

새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 핫 백업을 식별합니다.
1. 핫 백업에 대한 역방향 작업을 통해 db_verify 및 csdb -v list를 하나씩 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다.
2. 통과한 첫 번째 핫 백업 복사본을 라이브 데이터베이스 디렉토리에 복원할 수 있습니다.
  
  핫 백업 복원의 설명대로 손상된 라이브 데이터베이스를 손상 없는 핫 백업으로 대체합니다. (먼저 복원하기 전에를 읽으십시오.)
3. 핫 백업과 아카이브 백업이 없는 경우 기술 지원부에 문의하십시오. 아카이브 백업이 있는 경우 아카이브 백업을 복원하려면 다음에 나오는 절차를 따르십시오. (또한 복원하기 전에를 참조하십시오.)

아카이브 백업을 복원하려면

손상되지 않은 핫 백업이 없지만 아카이브 백업과 해당 트랜잭션 로그가 있는 경우 다음 단계를 수행하여 손상되지 않은 최신 아카이브 데이터베이스 버전을 복원할 수 있습니다.

단계

적용되지 않았거나 손상된 활성 데이터베이스 디렉토리에 쓰기 위해 열려 있는 로그 파일을 식별합니다.

쓰기 위해 열려 있는 로그를 닫습니다. 이 로그에는 최신 트랜잭션이 포함되어 있습니다.

새 (복구) 디렉토리를 만듭니다.

최신 아카이브 복사본과 해당 로그 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.

손상된 라이브 데이터베이스 디렉토리의 적용되지 않은 log.* 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.

새 복구 데이터베이스에 대해 지정된 -c -h 옵션과 함께 db_recover를 실행합니다.

예를 들어, 새 복구 디렉토리가 recoverydb인 경우 명령은 다음과 같습니다.

db_recover -c -h recoverydb

log.* 파일을 새 복구 디렉토리에 그대로 둡니다.

db_recover 프로그램이 로그 파일을 새 복구 데이터베이스에 적용했지만 버전 4.2부터 Berkeley DB는 로그 파일이 해당 위치에 그대로 있는 것으로 기대합니다.

새 복구 디렉토리에 있는 데이터베이스 파일에 대해 db_verify를 실행합니다.

자세한 내용은 달력 데이터베이스 손상 검사 방법을 참조하십시오.

새 복구 디렉토리에 대해 csdb -v list를 실행합니다.

새 복구 디렉토리가 앞의 세 복구 단계를 모두 통과한 경우 손상된 이전 활성 데이터베이스를 새 복구 데이터베이스로 대체합니다.

새 스냅샷 역할을 하도록 새 라이브 데이터베이스를 핫 백업 디렉토리에 복사합니다.

Calendar Server를 시작합니다.

새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 아카이브 백업을 식별합니다.
1. 아카이브 백업 복사본 역방향 작업을 통해 각각에 대해 세 복구 프로그램을 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다. db_recover -c-h, db_verify 및 csdb -v list.
2. 통과한 첫 번째 아카이브 복사본을 라이브 데이터베이스 디렉토리에 복원할 수 있습니다.
  
  아카이브 백업을 복원하려면에 표시된 것처럼 손상된 라이브 데이터베이스를 손상 없는 아카이브 백업으로 대체합니다.
3. 아카이브 백업이 수행되지 않으면 기술 지원부에 문의하십시오.

사용자 정의 백업 스크립트 복구

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

Berkeley 도구가 동적 라이브러리에 컴파일됨

db_recover와 같은 Berkeley 데이터베이스 도구를 사용하여 사용자 정의 백업 스크립트를 만든 경우 Calendar Server로 업그레이드하면 해당 스크립트가 더 이상 작동하지 않습니다. 이전 Calendar Server 버전에서는 정적 라이브러리를 사용하여 도구를 컴파일했기 때문입니다. 현재 버전에서는 도구를 동적 라이브러리 libdb-4.2.so에 컴파일합니다.

사용자 정의 백업 스크립트를 복구하려면

기존 사용자 정의 스크립트가 있는 새 동적 라이브러리를 사용하려면 다음 전역 변수를 설정합니다.

LD_LIBRARY_PATH=libdb-4.2.so