Sun Java System Calendar Server 6.3 관리 설명서

3 Calendar Server 구성 사용자 정의

이 부분에는 구성 파일(ics.conf)을 편집하여 구성할 수 있는 다양한 기능에 대한 정보가 수록되어 있습니다.

이 부분은 다음 장으로 구성됩니다.

4장 Calendar Server 사용자 정의

설치 및 설치 후 구성을 수행했다면 Calendar Server를 그대로 실행할 수 있습니다. 그러나 ics.conf 파일을 편집하면 시스템의 기능을 사용자 정의(시스템 재구성)할 수 있습니다.

주 –

ics.conf 파일에서는 중복 매개 변수가 허용됩니다. 시스템은 파일의 마지막 매개 변수 인스턴스의 값을 사용합니다.

최상의 방법: 혼동을 피하려면 파일에서 이런 용도로 만든 섹션 끝에 사용자 정의 항목을 추가하십시오. 예를 들어, 다음과 같은 텍스트로 주석 줄을 만들 수 있습니다. ! My ics.conf Changes. 그런 다음 새 매개 변수 또는 수정할 매개 변수를 추가하고 해당 값을 지정합니다. 각 매개 변수에 변경한 이유와 현재 날짜를 주석으로 추가하십시오. 이렇게 하면 시스템에 대한 변경 기록을 나중에 참조할 수 있습니다.

많은 부분을 사용자 정의한 경우 처리 효율이 향상되도록 대체한 원본 매개 변수를 주석으로 처리하는 것을 고려해 볼 수 있습니다. 또한 주기적으로 파일을 검토하고 더 이상 사용되지 않은 중복 매개 변수를 주석으로 처리하십시오.

이 장과 제3부, Calendar Server 구성 사용자 정의 다음에 나오는 장들은 Calendar Server를 다시 구성하는 데 사용할 수 있는 지침과 정보를 제공합니다.

다음 디렉토리에서 ics.conf 파일을 찾을 수 있습니다.

Solaris: /etc/opt/SUNWics5/cal/config

Linux: /etc/opt/sun/calendar/config

주 –

구성 파일을 편집하기 전에 다음 작업을 완료하십시오.

Calendar Server 6 2006Q3을 설치하거나 이 버전으로 업그레이드합니다.
설치 후 구성 프로그램 comm_dssetup.pl 및 csconfigurator.sh를 실행합니다.
기존 달력 데이터베이스에 대해 필요한 경우 csmig, csvdmig, cs5migrate, csmigrate 및 commdirmig를 실행합니다. 3 장, Calendar Server 6.3용 데이터베이스 마이그레이션 유틸리티을 참조하십시오.

이 장에서는 구성과 관련된 다음과 같은 내용을 설명합니다.

4.1 Communications Express를 위한 구성

이 절에서는 Communications Express에 대해 구성할 두 가지 파일 매개 변수에 대해 설명합니다.

Communications Express를 사용하려면 다음과 같은 작업이 필요합니다.

프록시 인증 구성

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.http.allowadminproxy

"yes"로 설정하면 관리자 프록시 인증이 가능하게 됩니다. 기본값은 "yes"입니다.

service.http.admins

Calendar Server에 대한 관리 권한이 있는 사용자 아이디를 나열합니다. 기본값은 “calmaster”입니다. 여러 값이 있는 공백으로 구분된 목록이 나타날 수 있습니다. 값 중 하나는 uwconfig.properties 파일에 지정된 calendar.wcap.adminid 값이어야 합니다.

service.siteadmin.userid

calmaster의 사용자 아이디입니다. 이 값은 uwcconfig.properties 파일의 calendar.wcap.adminid 매개 변수에 있는 사용자 아이디와 같아야 합니다.

service.siteadmin.cred

calmaster의 비밀번호입니다. 이 값은 uwcconfig.properties 파일의 calendar.wcap.passwd 매개 변수에 있는 비밀번호와 같아야 합니다.

주 –
uwcconfig.properties 파일은 comms-express-svr-base/WEB-INF/config 디렉토리에 있습니다. 여기서 comm-express-svr-base는 Communications Express가 설치된 디렉토리입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

참조

Communications Express 구성에 대한 자세한 내용은 Sun Java System Communications Express 6.3 Customization Guide를 참조하십시오.

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

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.wcap.anonymous.allowpubliccalendarwrite

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

service.wcap.allowpublicwritablecalendars

사용자가 공개적으로 쓰기 가능한 달력을 소유할 수 있습니다. 기본적으로 활성화됩니다("yes"로 설정).

service.http.allowanonymouslogin

필요한 경우 이 매개 변수를 "yes"로 설정하여 익명 액세스(로그인)를 가능하게 합니다. 기본값은 "yes"입니다.

service.calendarsearch.ldap

보안상 익명 로그인이 가능하게 한 상태에서 이 매개 변수를 "no"(기본값)로 설정하여 달력 검색을 수행할 때 LDAP를 통한 검색을 사용 불가능하게 할 수 있습니다.

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

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

Communications Express 구성에 대한 지침은Sun Java System Communications Express 6.3 Administration Guide를 참조하십시오.

4.2 달력 구성

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

사용자 달력을 구성하려면

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 표시된 매개 변수 중 하나 이상을 편집합니다.
calstore.calendar.default.acl
사용자가 달력을 만들 때 사용되는 기본 액세스 제어 권한을 지정합니다. 형식은 세미콜론을 사용하여 구분한 액세스 제어 항목(ACE) 인수 문자열 목록에 의해 지정됩니다. 기본값은 다음과 같습니다.
```
"@@o^a^r^g;@@o^c^wdeic^g;
@^a^fs^g;@^c^^g;@^p^r^g"
```
ACE 형식에 대한 자세한 내용은 15.4 달력 액세스 제어 Calendar Server 유틸리티를 참조하십시오. D.5 cscal을 참조하십시오.
calstore.calendar.owner.acl

달력 소유자에 대한 기본 액세스 제어 설정을 지정합니다. 기본값은 다음과 같습니다. "@@o^a^rsf^g;@@o^c^wdeic^g"

calstore.freebusy.include.defaultcalendar

사용자의 기본 달력을 사용자의 사용 가능/사용 중 달력 목록에 포함할 것인지 여부를 지정합 니다. 기본값은 “yes”입니다.

calstore.freebusy.remove.defaultcalendar

사용자의 기본 달력을 사용 가능/사용 중 달력 목록에서 제거할 수 있는지 여부를 지정합니다. 기본값은 “no”입니다.

service.wcap.freebusy.redirecturl

다른 데이터베이스에 있는 달력을 검색하는 데 사용할 URL을 지정합니다. 이 URL은 달력 데이터베이스를 마이그레이션하는 동안에만 사용됩니다. 달력이 서로 다른 두 데이터베이스로 분할되는 동안 현재 Calendar Server 데이터베이스 이외의 URL을 지정할 수 있습니다. Calendar Server 달력 데이터베이스를 먼저 검색한 다음 사용자를 찾을 수 없는 경우 URL 리디렉션이 사용 가능한지 확인합니다. get_freebusy 명령을 사용하여 noredirect 매개 변수를 1로 설정하면 이 기능을 해제할 수 있습니다.

calstore.subscribed.include. defaultcalendar

사용자의 기본 달력을 사용자의 가입 달력 목록에 포함할 것인지 여부를 지정합니다. 기본값은 “yes”입니다.

service.wcap.login.calendar.publicread

값이 "yes"이면 기본 사용자 달력이 기본적으로 공용 읽기/개별 쓰기로 설정됩니다. 값이 "no"이면 기본 사용자 달력은 기본적으로 개별 읽기/개별 쓰기로 설정됩니다. 기본값은 “no”입니다.

user.allow.doublebook
사용자 달력에서 동일한 기간 동안 여러 이벤트를 예약할 수 있는지를 결정합니다.
- "no"로 설정하면 이중 예약이 금지됩니다.
- "yes"(기본값)로 설정하면 이중 예약이 허용됩니다.
  
  이 매개 변수는 사용자 달력이 만들어질 때만 사용됩니다. 이후 Calendar Server는 달력 등록 정보 파일(ics50calprops.db)을 검사하여 이중 예약이 허용되는지 여부를 확인합니다.
  
  이중 예약 달력 등록 정보 값을 변경하려면 cscal을 -k 옵션과 함께 사용합니다.
user.invite.autoprovision

초대를 수신했을 때 기본 달력이 없는 경우 사용자 달력을 자동으로 만들지를 결정합니다. 기본값은 이 옵션을 활성화("yes")하는 것입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

자원 달력을 구성하려면

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 표시된 매개 변수 중 하나 이상을 편집합니다.
resource.allow.doublebook
회의실 또는 장비와 같은 한 자원에 속한 달력에 대해 이 달력이 만들어진 때와 같은 시간에 둘 이상의 이벤트를 예약할 수 있는지 여부를 결정합니다.
- "no"는 이중 예약을 방지하며 기본값입니다.
- "yes"를 설정하면 이중 예약이 허용됩니다.
- 이 매개 변수는 자원 달력이 만들어질 때만 사용됩니다.
  
  자원 달력이 만들어진 후 Calendar Server는 달력 등록 정보(ics50calprops.db)를 검사하여 이중 예약이 허용되는지 확인합니다.
  
  자원 달력에서 이중 예약을 허용 또는 금지하도록 달력 등록 정보를 변경해야 할 경우 csresource를 -k 옵션과 함께 다시 실행합니다.
resource.default.acl
자원 달력이 만들어질 때 사용되는 기본 액세스 제어 권한을 지정합니다. 기본값은 다음과 같습니다.
```
"@@o^a^r^g;@@o^c^wdeic^g;
@^a^rsf^g"입니다.)
```
resource.invite.autoaccept

자원에 대해 초대를 수신했을 때 자동으로 수락한 것으로 표시할지를 결정합니다. 기본값은 "yes"입니다.

resource.invite.autoprovision

이벤트에 자원을 초대했을 때 자원에 달력이 없는 경우 자동 제공할 것인지를 결정합니다.

기본값은 "yes"입니다.

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

Calendar Server를 다시 시작합니다.
```
cal-svr-base/SUNWics5/cal/sbin/start-cal
```

그룹 달력을 구성하려면

그룹 달력은 사용자 달력과 비슷한 이벤트로 예약할 수 있습니다. 하지만 그룹 달력에는 사용자가 로그인할 수 없습니다. 그룹 달력을 보려면 그룹에 가입해야 합니다. 그룹 달력을 구성하려면 다음 단계에 나와 있는 대로 ics.conf 파일을 편집합니다.

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

group.allow.doublebook

그룹 달력을 이중 예약할 수 있는지 여부를 지정합니다. 기본값은 yes입니다.

group.default.acl

그룹 달력의 기본 ACL을 지정합니다.

"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

group.invite.autoprovision

자동 제공 기능을 활성화 또는 비활성화합니다. 기본값은 "yes"(활성화)입니다.

group.invite.autoaccept

그룹 초대 시 자동으로 PARTSTAT=ACCEPTED를 설정할 것인지 지정합니다.

group.invite.expand

초대에 대해 그룹을 확장할지 결정합니다.

“yes”일 경우 calstore.group.attendee.maxsize 매개 변수의 제약 조건을 충족하면 목록이 확장됩니다. 확장이 실패하거나 이 매개 변수가 "no"로 설정되면 그룹 이름만 참석자 목록에 표시되고 RSVP는 필요하지 않습니다.

calstore.group.attendee.maxsize

그룹의 확장 가능 여부를 지정합니다. "0" 값은 확장에 제한이 없음을 의미합니다. 어떤 크기의 그룹도 확장이 가능합니다.

확장이 허용되어 있는 경우에는 제한이 있습니다. 매개 변수 값은 확장된 그룹에서 허용되는 최대 참석자 수를 나타냅니다. 그룹 내의 참석자 수가 최대 크기를 초과하는 경우 그룹은 확장되지 않습니다.

"-1" 값은 확장이 허용되지 않음을 의미합니다.

최대 크기를 초과하기 때문에 확장이 허용되지 않는 경우 참석자 목록에 그룹 이름만 표시되고 주최자에게 오류가 반환됩니다.

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

Calendar Server를 다시 시작합니다.
```
cal-svr-base/SUNWics5/cal/sbin/start-cal
```

참조

그룹 구성에 대한 지침은 그룹에 대해 Calendar Server를 구성하려면을 참조하십시오.

달력 자동 제공 기능을 비활성화하려면

사용자, 자원 및 그룹 달력 자동 제공은 기본적으로 활성화됩니다. 즉, 로그인 중인 사용자에게 기본 달력이 없는 경우 기본 설정을 사용하여 사용자 달력이 만들어집니다.

사용자, 자원 또는 그룹이 이벤트에 초대되었지만 기본 달력이 없는 경우 기본 설정을 사용하여 자원 또는 그룹 달력을 만들어집니다.

이러한 달력이 자동 제공되지 않도록 하려면 다음 단계에 나와 있는 대로 ics.conf 파일에서 해당 매개 변수를 변경합니다.

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 매개 변수를 편집하여 사용자, 자원 및 그룹 달력 자동 제공을 비활성화합니다.

local.autoprovision

사용자 달력의 자동 제공 기능을 활성화(“yes”)할 것인지 또는 비활성화(“no”)할 것인지 지정합니다. 기본값은 “yes”입니다.

resource.invite.autoprovision

자원 달력의 자동 제공 기능을 활성화(“yes”)할 것인지 또는 비활성화(“no”)할 것인지 지정합니다. 기본값은 “yes”입니다.

group.invite.autoprovision

그룹 달력의 자동 제공 기능을 활성화(“yes”)할 것인지 또는 비활성화(“no”)할 것인지 지정합니다. 기본값은 “yes”입니다.

autoprovisioning

사용자 달력의 자동 초대 기능을 활성화(“yes”)할 것인지 또는 비활성화(“no”)할 것인지 지정합니다. 기본값은 “yes”입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

사용 가능/사용 중 조회를 구성하려면

사용 가능/사용 중 보기가 여러 용도로 사용됩니다. 약속 있음/약속 없음 보기를 생성하는 방법을 사용자 정의할 수 있는 많은 ics.conf 매개 변수가 있습니다.

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

stop-cal을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

service.wcap.freebusybegin

get_freebusy 범위 시작에 대한 현재 시간으로부터의 오프셋을 일 단위로 지정합니다. 기본값은 "30"입니다.

service.wcap.freebusyend

get_freebusy 범위의 끝에 대한 현재 시간으로부터의 오프셋을 일 단위로 지정합니다. 기본값은 "30"입니다.

calstore.freebusy.include.defaultcalendar

사용자의 기본 달력을 사용자의 사용 가능/사용 중 달력 목록에 포함할 것인지 여부를 지정합 니다. 기본값은 "yes"입니다.

calstore.freebusy.remove.defaultcalendar

사용자의 기본 달력을 사용 가능/사용 중 달력 목록에서 제거할 수 있는지 여부를 지정합니다. 기본값은 "no"입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

4.3 LDAP 사용자, 그룹 및 자원 달력 구성

이 절에서는 LDAP 사용자, 그룹 및 자원 구성에 대한 지침을 제공합니다.

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

달력 사용자 구성

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

local.lookupldapsearchattr.aclgroup

사용자, 그룹 또는 자원이 ACL 평가를 위해 어떤 그룹의 구성원인지 지정하는 속성입니다. 기본값은 "aclgroupaddr" 입니다. 이 옵션은 동적 그룹을 계산하는 데 사용됩니다.

service.wcap.allowchangepassword

값이 "yes"이면 사용자가 비밀번호를 변경할 수 있습니다. 기본값은 "no"입니다.

service.wcap.allowpublicwritablecalendars

값이 "yes"이면 사용자가 공개적으로 쓸 수 있는 달력을 소유할 수 있습니다. 기본값은 "yes"입니다.

calstore.subscribed.remove.defaultcalendar

사용자의 기본 달력을 사용자의 가입 달력 목록에서 제거할 수 있는지 여부를 지정합니다. 기본값은 "no"입니다.

service.wcap.allowcreatecalendars

값이 "yes"이면 관리 권한이 없는 사용자가 달력을 만들 수 있습니다. 기본값은 "yes" 입니다.

service.wcap.allowdeletecalendars

값이"yes"이면 관리 권한은 없지만 해당 달력에 대한 삭제 권한이 있는 사용자가 달력을 삭제할 수 있습니다. 기본값은 "yes"입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

달력 사용자 기본 설정 지정

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

service.wcap.allowsetprefs.cn

값이 "yes"이면 set_userprefs로 사용자 기본 설정 "cn"(LDAP 사용자의 공통 이름)을 수정할 수 있습니다. 기본값은 "no"입니다.

service.wcap.allowsetprefs.givenname

값이 "yes"이면 set_userprefs로 사용자 기본 설정 "givenname"(LDAP 사용자의 이름)을 수정할 수 있습니다. 기본값은 “no”입니다.

service.wcap.allowsetprefs.icsCalendar

값이 "yes"이면 set_userprefs로 사용자 기본 설정 “icsCalendar"(사용자의 기본 달력 식별자)를 수정할 수 있습니다. 기본값은 “no”입니다.

service.wcap.allowsetprefs.mail

값이 "yes"이면 set_userprefs로 사용자 기본 설정 "mail"(사용자의 전자 메일 주소)을 수정할 수 있습니다. 기본값은 “no”입니다.

service.wcap.allowsetprefs. preferredlanguage

값이 "yes"이면 set_userprefs로 사용자 기본 설정 "preferredlanguage""(LDAP 사용자의 기본 언어)를 수정할 수 있습니다. 기본값은 “no”입니다.

service.wcap.allowsetprefs.sn

값이 "yes"이면 set_userprefs로 사용자 기본 설정 "sn"(LDAP 사용자의 성)을 수정할 수 있습니다. 기본값은 “no”입니다.

service.wcap.userprefs.ldapproxyauth

값이 "yes"이면 get_userprefs의 LDAP 프록시 인증을 활성화합니다. 값이 "no"이면 익명 LDAP 검색이 수행됩니다. 기본값은 “no”입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

그룹에 대해 Calendar Server를 구성하려면

Calendar Server에서는 이름이 지정된 사용자의 모음인 LDAP 그룹을 지원합니다. 그룹 구성원은 정적 또는 동적으로 만들 수 있습니다. 그룹은 중첩할 수 있습니다. 그룹에는 사용자의 uid와 비슷한 groupid가 있습니다. 그룹에는 전자 메일 주소가 있습니다.

또한 그룹에는 groupid@sesta.com과 같이 도메인을 추가한 groupid에 해당하는 calid를 가진 기본 달력이 있습니다. 그룹 달력의 사용자 인터페이스 기본 설정은 기본 설정 데이터베이스에 저장되지 않습니다. 대신 그룹 생성 시 사용되는 icsDefaultacl 속성이 LDAP 항목에 포함되어 있습니다.

그룹은 icsCalendarGroup의 인스턴스로 LDAP 항목에 정의되어 있습니다. 그룹 달력에서 사용할 수 있는 다른 속성에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Schema Reference를 참조하십시오.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

local.lookupldapsearchattr.owner

그룹 및 자원에 사용할 소유자 속성입니다. 기본값은 "owner"입니다.

local.lookupldapsearchattr.coowner

그룹 및 자원을 위한 보조 소유자 속성입니다. 기본값은 "icsSecondaryowners"입니다.

local.lookupldapsearchattr.groupid

고유한 그룹 아이디를 저장하는 데 사용되는 속성입니다. 기본값은 "groupid"입니다.

local.lookupldapsearchattr.defaultacl

자동 제공 시 각 그룹 달력에 제공되는 기본 ACL을 저장하는 데 사용되는 속성입니다. 기본값은 "icsDefaultacl"입니다.

local.lookupldapsearchattr.doublebook

그룹 달력에서 이중 예약이 허용되는지 여부를 지정하는 속성입니다. 기본 그룹 달력이 자동으로 생성될 때 사용되는 속성입니다. 기본값은 "icsDoublebooking"입니다.

local.lookupldapsearchattr.autoaccept

그룹 달력에 대한 초대를 자동으로 수락할지 여부를 지정하는 속성입니다. 기본 그룹 달력이 자동으로 생성될 때 사용되는 속성입니다. 기본값은 "icsAutoaccept"입니다.

local.lookupldapsearchattr.timezone

자동 생성된 그룹 달력의 표준 시간대를 지정하는 데 사용되는 속성입니다. 기본값은 "icsTimezone"입니다.

local.lookupldapsearchattr.aclgroup

사용자, 그룹 또는 자원이 ACL 평가를 위해 어떤 그룹의 구성원인지 지정하는 속성입니다. 기본값은 "aclgroupaddr" 입니다. 그룹의 경우 이것은 중첩 그룹을 의미합니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

참조

그룹에 대해 달력을 사용하려면 그룹 달력을 구성해야 합니다. 그룹 달력을 구성하려면을 참조하십시오.

그룹을 사용하는 경우 그룹 LDAP 항목에서 다음 도메인 수준 기본 설정을 지정해야 합니다.

icsAllowRights — 그룹 달력 이중 예약에 대한 도메인 수준 기본 설정을 지정하려면 15번 비트를 설정합니다.
icsExtendedDomainPrefs — 도메인의 그룹 달력에 사용할 기본 ACL을 결정하는 groupdefaultacl 속성을 설정합니다.

그룹에 대해 Calendar Server 도메인을 구성하는 방법에 대한 자세한 내용은 11.1 Calendar Server 버전 6.3의 그룹에 대한 도메인 기본 설정 구성을 참조하십시오.

4.4 Calendar Server 구성

이 절에서는 ics.conf 파일을 편집하여 서버측 구성을 사용자 정의하기 위한 절차를 설명합니다.

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

서버 동작을 구성하려면

달력 저장소는 기본적으로 다음 표에 표시된 대로 구성되어 있습니다. 저장소를 다시 구성하려면 다음 단계를 수행합니다.

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

stop-cal을 사용하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표의 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명과 기본값
`calstore.calendar.create.lowercase`	새 달력을 만들거나 LDAP CLD 플러그 인을 사용하여 달력을 조회할 때 Calendar Server가 달력 아이디(`calid` )를 소문자로 변환할 것인지 여부를 지정합니다. 기본값은 `"no"`입니다.
`calstore.default.timezoneID`	파일을 가져올 때 사용할 표준 시간대 아이디입니다. 이벤트, 달력, 사용자 등에 대한다른 표준 시간대 아이디는 없습니다. 기본값은 `"America/New_York"`입니다. 유효하지 않은 값을 설정하면 GMT(그리니치 표준시) 표준 시간대가 사용됩니다.
`calstore.filterprivateevents`	Calendar Server가 개별 및 비밀(시간 및 날짜만) 이벤트 및 작업을 필터링(인식)할 것인지 지정합니다.값을 `"no"`로 설정하면 Calendar Server가 이러한 이벤트 및 작업을 공용 이벤트 및 작업과 동일하게 처리합니다. 기본값은 `"yes"`입니다.
`calstore.group.attendee.maxsize`	그룹을 확장할 때 허용되는 최대 구성원 수입니다. `"0"`(기본값)은 그룹이 크기에 관계없이 확장될 수 있음을 의미합니다. `"-1"` 값은 그룹 확장이 허용되지 않음을 의미합니다.
`calstore.recurrence.bound`	반복 확장에 의해 만들 수 있는 최대 이벤트 수기본값은 `"60"`입니다.
`calstore.userlookup.maxsize`	사용자 검색의 LDAP 조회에서 반환된 최대 결과 수. 값이 `"0"`이면 아무 제한이 없음을 의미합니다. 기본값은 `"200"`입니다.
`calstore.unqualifiedattendee.fmt1.type`	이벤트 참석자를 위한 디렉토리 조회를 수행할 때 Calendar Server가 `jdoe` 또는 `jdoe:tv`와 같은 문자열을 처리하는 방법을 지정합니다. 허용되는 값은 `uid`, `cn`, `gid`, `res`, `mailto`, `cap`입니다. 기본값은 `"uid"`입니다.
`calstore.unqualifiedattendee.fmt2.type`	이벤트 참석자를 위한 디렉토리 조회를 수행할 때 Calendar Server가 `jdoe@sesta.com`과 같이 at 기호(`@`)가 있는 문자열을 처리하는 방법을 지정합니다. 허용되는 값은 `uid`, `cn`, `gid`, `res`, `mailto`, `cap`입니다. 기본값은 `"mailto"`입니다.
`calstore.unqualifiedattendee.fmt3.type`	이벤트 참석자를 위한 디렉토리 조회를 수행할 때 Calendar Server가 `john doe`와 같이 공백이 있는 문자열을 처리하는 방법을 지정합니다. 허용되는 값은 `uid`, `cn`, `gid`, `res`, `cap`입니다. 기본값은 `"cn"`입니다.
`service.wcap.validateowners`	`"yes"`이면 서버에서 달력의 각 소유자가 LDAP 디렉토리에 있는지 검사해야 합니다. 기본값은 `"no"`입니다.
`service.wcap.freebusy.redirecturl`	요청된 달력이 로컬 달력 데이터베이스에 없는 경우 이 매개 변수에 있는 URL을 대신 사용하여 검색을 다른 데이터베이스로 리디렉션할 수 있습니다. 특히, 두 데이터베이스 사이에서 마이그레이션할 때 두 데이터베이스가 모두 사용 중인 경우 만들어진 스크립트에 대해 이 방법을 사용합니다. 그런 다음 `get_freebusy.wcap` 명령을 사용하여 다른 데이터베이스를 조사할지 여부를 지정할 수 있습니다. Sun Java System Calendar Server 6.3 WCAP Developer’s Guide에서 `get_freebusy` 명령에 대한 설명을 참조하십시오.
`store.partition.primary.path`	달력 정보가 저장된 기본 디스크 분할 영역의 위치기본값은 `"/var/opt/SUNWics5/csdb"`입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

달력 로깅을 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	설명과 기본값
`logfile.admin.logname`	이 로그 파일에는 실행된 관리 도구 명령의 내역이 포함되어 있습니다. 기본값은 `"admin.log"`입니다.
`logfile.buffersize`	로그 버퍼의 크기(바이트)입니다. 기본값은 `"0"`입니다. 로그 파일에 있는 각 항목의 크기를 지정합니다. 버퍼가 지나치게 빠르게 채워질 경우 버퍼의 크기를 늘리십시오.
`logfile.dwp.logname`	DWP(데이터베이스 와이어 프로토콜) 관련 관리 도구 로깅을 위한 로그 파일의 이름입니다. 기본값은 `"dwp.log"`입니다. 프런트엔드 서버별로 하나씩 지정합니다.
`logfile.expirytime`	로그 파일이 만료되기까지의 시간(초)입니다. 기본값은 `"604800"`입니다. 이 시간이 지나면 정리 루틴이 로그를 제거합니다. 로그를 아카이브하려면 사용자 루틴을 작성해야 합니다.
`logfile.flushinterval`	버퍼를 로그 파일로 비우기까지의 시간(초)입니다. 기본값은 `"60"`입니다. 시스템에 로그 정보가 많아 버퍼가 60초 이전에 채워질 경우 정보가 손실됩니다. 그럴 경우 이 간격을 줄이십시오. 간격을 줄이면 시스템 오버헤드가 줄어듭니다.
`logfile.http.logname`	`cshttpd` 서비스를 위한 현재 로그 파일의 이름입니다. 기본값은 `"http.log"`입니다.
`logfile.http.access.logname`	현재 http 액세스 로그 파일의 이름입니다.
`logfile.logdir`	로그 파일의 디렉토리 위치입니다. 기본값은 `"/var/opt/SUNWics5/logs"`입니다.
`logfile.loglevel`	서버가 로그에 기록할 세부 정보의 수준을 결정합니다. 각 로그 항목마다 `CRITICAL`, `ALERT`, `ERROR`, `WARNING`, `NOTICE` , `INFORMATION` 및 `DEBUG` 수준(심각도순) 중 하나를 지정합니다. 기본값은 `“NOTICE”`입니다. `CRITICAL`로 설정하면 Calendar Server는 가장 적은 양의 세부 정보를 기록합니다. 가장 많은 양의 세부 정보를 기록하려면 `DEBUG`를 지정합니다. 로그 수준을 지정하면 해당 수준보다 심각도가 높은 모든 로그 수준이 기록됩니다. 예를 들어, `WARNING`으로 설정하면 `CRITICAL`, `ERROR` 및 `WARNING` 수준 로그 항목만 기록됩니다. `DEBUG`로 설정하면 모든 수준이 기록됩니다.
`logfile.maxlogfiles`	로그 디렉토리의 최대 로그 파일 수입니다. 기본값은 `"10"` 입니다. 11번째 로그를 만들기 전에 정리 루틴이 실행되어 이전 로그 파일이 제거됩니다.
`logfile.maxlogfilesize`	모든 로그 파일을 위한 최대 디스크 공간(바이트)입니다. 기본값은 `"2097152"` 입니다. 다음 로그 파일을 만들면 이 제한에 위반되는 경우 가장 오래된 로그를 삭제하여 사용 가능한 디스크 공간을 확보합니다.
`logfile.minfreediskspace`	로깅을 위해 사용할 수 있어야 하는 최소한의 사용 가능 디스크 공간(바이트)이 값에 도달하면 Calendar Server는 이전 로그 파일을 만료하여 사용 가능한 디스크 공간을 확보합니다. 공간을 확보할 수 없으면 로깅이 일시 중지됩니다. 기본값은 `"5242880"`입니다.
`logfile.notify.logname`	`csnotifyd` 서비스를 위한 로그 파일 이름입니다. 기본값은 `"notify.log"`입니다.
`logfile.rollovertime`	로그 파일이 순환되기까지의 시간(초)즉, 새 로그 파일을 만들어서 열 때까지의 간격입니다. 기본값은 `"86400"`입니다.
`logfile.store.logname`	달력 저장소를 위한 로그 파일 이름입니다. 기본값은 `"store.log"`입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

참조

달력 데이터베이스에 대한 트랜잭션 로깅을 구성하려면 9 장, 자동 백업 구성을 참조하십시오.

삭제된 이벤트와 작업에 대한 삭제 로그를 구성할 필요는 없습니다. 18 장, 삭제 로그 데이터베이스 관리을 참조하십시오.

WCAP 명령을 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명과 기본값
`service.wcap.format`	명령의 기본 출력 형식을 지정합니다. 지원되는 형식은 다음 두 가지입니다. `"text/calendar"`(기본값) `"text/xml"` Connector for Microsoft Outlook을 사용하는 경우 `text/calendar`를 사용해야 합니다.
`service.wcap.version`	WCAP 버전

매개 변수

설명과 기본값

service.wcap.format

명령의 기본 출력 형식을 지정합니다. 지원되는 형식은 다음 두 가지입니다.

"text/calendar"(기본값)
"text/xml"

Connector for Microsoft Outlook을 사용하는 경우 text/calendar를 사용해야 합니다.

service.wcap.version

WCAP 버전

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

전자 메일 알림을 활성화하려면

세 가지 유형의 전자 메일 알림을 활성화할 수 있습니다.

이벤트에 초대된 참석자에게 전자 메일 알림 보내기
이벤트가 취소되었을 때 참석자에게 전자 메일 알림 보내기
참석자가 회신했을 때 주최자에게 전자 메일 알림 보내기

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명과 기본값
`ine.invitation.enable`	`"yes"`(기본값) - 참석자에게 초대에 대한 알림을 보냄 `"no"` - 참석자에게 초대에 대한 알림을 보내지 않음
`ine.cancellation.enable`	`"yes"`(기본값) - 참석자에게 이벤트 취소에 대한 알림을 보냄 `"no"` - 참석자에게 취소에 대한 알림을 보내지 않음
`ine.reply.enable`	`"yes"`(기본값) - 초대에 대해 참석자가 회신했을 때 주최자에게 알림을 보냄 `"no"` - 초대에 대해 참석자가 회신했을 때 주최자에게 알림을 보내지 않음

매개 변수

설명과 기본값

ine.invitation.enable

"yes"(기본값) - 참석자에게 초대에 대한 알림을 보냄

"no" - 참석자에게 초대에 대한 알림을 보내지 않음

ine.cancellation.enable

"yes"(기본값) - 참석자에게 이벤트 취소에 대한 알림을 보냄

"no" - 참석자에게 취소에 대한 알림을 보내지 않음

ine.reply.enable

"yes"(기본값) - 초대에 대해 참석자가 회신했을 때 주최자에게 알림을 보냄

"no" - 초대에 대해 참석자가 회신했을 때 주최자에게 알림을 보내지 않음

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

참조

알림 구성에 대한 자세한 내용은 E.4.1 Calendar Server 전자 메일 알림 구성 매개 변수 및 형식 파일을 참조하십시오.

4.5 로그인 및 인증 구성

이 절에서는 로그인 및 인증을 구성하기 위한 지침을 제공합니다.

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

프록시 관리자 로그인을 구성하려면

Communications Express에 대한 프록시 로그인을 구성해야 합니다. Communications Express에 대한 프록시 로그인을 구성하는 방법에 대한 자세한 내용은 4.1 Communications Express를 위한 구성을 참조하십시오.

Communications Express 외부 Calendar Server에 대한 관리자 프록시 로그인을 허용하려면 다음 단계를 수행합니다.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 매개 변수를 편집합니다.

service.http.allowadminproxy

관리자에게 사용자 달력 관리를 위한 프록시 로그인을 허용할지 여부를 지정합니다. "yes"를 지정하면 프록시 로그인이 허용됩니다. "no"를 지정하면 프록시 로그인이 허용되지 않습니다. 기본값은 "yes"입니다.

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

다음 WCAP 명령을 사용하여 관리자 프록시 로그인이 제대로 작동하는지 확인합니다.
http://server[:port]/login.wcap? user=admin-user&password=admin-password &proxyauth=calendar-user&fmt-out=text/html
다음 목록에서는 이전 예에서 사용된 각 변수에 대한 설명을 제공합니다.
- server는 Calendar Server가 실행 중인 서버의 이름입니다.
- port는 Calendar Server 포트 번호입니다. 기본 포트는 80입니다.
- admin-user는 Calendar Server 관리자입니다. 예를 들어, calmaster입니다.
- admin-password는 admin-user의 비밀번호입니다.
- calendar-user는 Calendar Server 사용자의 calid입니다.
- fmt-out은 컨텐트 출력 형식의 사양입니다. 예를 들어 텍스트 또는 HTML을 사용할 수 있습니다.
명령이 성공하면 Calendar Server는 calendar-user의 달력을 표시합니다. 문제가 발생하면 Calendar Server는 “Unauthorized”라는 메시지를 표시합니다.

오류의 원인은 다음과 같습니다.
- admin-user에게 Calendar Server 관리자 권한이 없습니다.
- admin-password가 올바르지 않습니다.
- calendar-user가 유효한 Calendar Server 사용자가 아닙니다.

인증을 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	설명/기본값
`local.authldapbasedn`	LDAP 인증을 위한 기본 DN. 지정하지 않으면 `local.ugldapbasedn`이 사용됩니다.
`local.authldaphost`	LDAP 인증을 위한 호스트. 이 값을 지정하지 않을 경우 서버는 `local.ugldaphost` 값을 사용합니다. 기본값은 `"localhost"`입니다.
`local.authldapbindcred`	`local.authldapbinddn`에 지정된 사용자의 바인딩 자격 증명(비밀번호)
`local.authldapbinddn`	사용자의 DN 검색을 위한 LDAP 인증 호스트 바인드에 사용되는 DN. 이 값을 지정하지 않거나 비워두면(`" "`) 익명 바인드로 간주됩니다.
`local.authldapport`	LDAP 인증을 위한 포트. 이 값을 지정하지 않을 경우 서버는 `local.ugldapport` 값을 사용합니다. 기본값은 `"389"`입니다.
`local.authldappoolsize`	LDAP 인증을 위해 유지되는 최소 LDAP 클라이언트 연결 수. 이 값을 지정하지 않을 경우 서버는 `local.ugldappoolsize` 값을 사용합니다. 기본값은 `"1"`입니다.
`local.authldapmaxpool`	LDAP 인증을 위해 유지되는 최대 LDAP 클라이언트 연결 수. 이 값을 지정하지 않을 경우 서버는 `local.ugldapmaxpool` 값을 사용합니다. 기본값은 `"1024"`입니다.
`local.user.authfilter`	사용자 조회에 사용되는 인증 필터를 지정합니다. 기본값은 `"(uid=%U)"`입니다. 이 값은 도메인 항목의 `inetDomainSearchFilter` 속성에 저장됩니다. 다른 속성에서 필터링할 수 있습니다. 예를 들어, 이 매개 변수를 `"(mail=%U)"`로 설정할 수 있습니다. 인증된 사용자의 `uid`는 인증에 사용된 속성에 관계 없이 모든 다른 함수에 해당 사용자에 대한 ID로 전달됩니다.
`service.plaintextloginpause`	일반 텍스트 비밀번호를 사용하여 사용자를 성공적으로 인증한 후 지연되는 시간(초)입니다. 기본값은 `"0"`입니다.

인증 캐시를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.authcachesize

Calendar Server에서 캐시에 유지 관리할 인증된 사용자 아이디(uid) 및 비밀번호의 최대 수입니다. 기본값은 “10000”입니다.

service.authcachettl

마지막 액세스 이후 uid와 비밀번호를 캐시에서 제거할 때까지의 시간(초)입니다. 기본값은 “900”입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

로그인할 때 클라이언트 IP 주소 검사를 활성화하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.dnsresolveclient

"yes"로 설정하면 HTTP 액세스가 허용될 때 DNS에 대해 클라이언트 IP 주소를 검사합니다. 기본값은 “no”입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

4.6 달력 서비스(데몬) 구성

이 절에서는 달력 서비스(데몬)을 구성하는 방법에 대한 지침을 제공합니다.

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

정보 –

9 장, 자동 백업 구성을 참조하십시오.

서비스 시작 및 중지를 구성하려면

start-cal 및 stop-cal 명령은 쉽게 Calendar Server를 시작 및 중지할 수 있게 해주는 래퍼 스크립트입니다. 이 유틸리티는 부록 D, Calendar Server 명령줄 유틸리티 참조 에 정의되어 있습니다.

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

stop-cal 명령을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	설명과 기본값
`local.serveruid`	런타임 사용자 아이디(`uid`). 기본값은 `"icsuser"`입니다. 수퍼유저 권한이 필요하지 않을 때 사용하는 사용자 아이디입니다.
`local.servergid`	런타임 그룹 아이디(`gid`). 기본값은 `"icsgroup"`입니다. 수퍼유저 권한이 필요하지 않을 때 사용하는 그룹 아이디입니다.
`local.autorestart`	이 매개 변수를 `"yes"`로 설정하면 `watcher`와 연결된 서비스가 올바르게 연결 해제되지 않고 종료될 경우 자동으로 다시 시작됩니다.
`local.autorestart.timeout`	자동 다시 시작 시간 초과 간격을 정의합니다. 지정한 간격 내에 서비스가 두 번 종료될 경우 자동 시작 시 무제한 다시 시작되는 것을 방지하기 위해 다시 시작되지 않습니다. 기본값은 10분입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 감시자 프로세스 구성

감시자 프로세스인 watcher는 실패한 소켓 연결을 모니터링하며 Calendar Server 및 Messaging Server에서 모두 사용됩니다. Calendar Server 매개 변수를 설정하여 감시자를 구성하려면 다음 단계를 수행하십시오.

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

stop-cal 명령을 실행하여 Calendar Server 서비스를 중지합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	설명과 기본값
`local.watcher.enable`	이 매개 변수를 `"yes"`로 설정하면 시작 프로그램이 다른 서비스보다 먼저 `watcher`를 시작합니다. 데몬은 소켓 연결을 통해 감시자에 연결됩니다. 기본값은 `"no"`이지만 구성 프로그램을 사용하여 `"yes"`로 변경할 수 있습니다.
`local.watcher.port`	`watcher`가 수신하는 포트입니다. Messaging Server는 포트 `49994`를 사용합니다. Calendar Server의 경우에는 `49995`와 같은 다른 포트를 사용해야 합니다.
`local.watcher.config.file`	`watcher`용 구성 파일입니다. 상대 경로일 경우 `config` 디렉토리에 대한 상대 경로입니다. 기본값은 `watcher.cnf`입니다.
`service.autorestart`	`"yes"`로 설정하면 감시자는 올바르게 연결 해제되지 않고 종료된 모든 등록된 서비스를 자동으로 다시 시작합니다. 서비스가 10분 내에 두 번 종료되면 감시자는 이를 다시 시작하지 않습니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

참조

감시자 프로세스에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Guide를 참조하십시오. 4장과 23장에 이와 관련된 정보가 있습니다.

주 –

감시자를 활성화하는 경우 감시자가 모니터링하는 모든 서비스를 감시자 프로세스에 등록해야 합니다. 이 작업은 Calendar Server 데몬에서 자동으로 그리고 내부적으로 처리됩니다. 또는 데몬이 cal-svr-base/data/proc 디렉토리에 각 서비스의 프로세스 아이디와 해당 상태("init" 또는 "ready")가 포함된 pid 파일을 만듭니다.

관리 서비스(csadmind)를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	설명과 기본값
`local.store.checkpoint.enable`	값이 `"yes"`이면 `csadmind` 데이터베이스 검사점 스레드를 시작합니다. 값이 `"no"`이면 검사점 로그 파일을 생성하지 않습니다. 기본값은 `"yes"`입니다.
`service.admin.dbcachesize`	관리 세션을 위한 Berkeley 데이터베이스의 최대 캐시 크기(바이트). 기본값은 `"8388608"`입니다.
`local.store.deadlock.enable`	값이 `"yes"`이면 `csadmind` 데이터베이스 교착 상태 감지 스레드를 시작합니다. 기본값은 `"yes"`입니다.
`service.admin.diskusage`	값이 `"yes"`이면 `csadmind` 디스크 공간 부족 모니터 스레드를 시작합니다. 기본값은 `"no"`입니다. 디스크 사용량은 기본적으로 모니터링되지 않습니다.
`service.admin.enable`	값이 `"yes"`이면 모든 서비스를 시작할 때 `csadmind` 서비스를 시작하고 모든 서비스를 중지할 때 `csadmind` 서비스를 중지합니다. 기본값은 `“yes”`입니다.
`service.admin.maxthreads`	관리 세션 당 실행되는 최대 스레드 수. 기본값은 `“10”`입니다.
`service.admin.resourcetimeout`	관리 연결 시간이 초과되기까지의 시간(초). 기본값은 `“900”`입니다.
`service.admin.serverresponse`	값이 "yes"이면 csadmind 서비스 응답 스레드를 시작합니다. 기본값은 `“no”`입니다.
`service.admin.sessiondir.path`	관리 세션 요청을 위한 임시 디렉토리. 기본값은 없습니다.
`service.admin.sessiontimeout`	`csadmind`의 HTTP 세션 시간이 초과되기까지의 시간(초). 기본값은 `“1800”`입니다.
`service.admin.sleeptime`	시작, 중지 또는 준비된 달력 서비스 검사 간에 기다리는 시간(초). 기본값은 `“2”`입니다.
`service.admin.starttime`	달력 서비스가 시작하기를 기다리는 시간(초). 기본값은 `“300”`입니다.
`service.admin.stoptime`	달력 서비스가 중지되기를 기다리는 시간(초). 기본값은 `“300”`입니다.
`service.admin.stoptime.next`	달력 서비스에 중지 명령을 보내는 사이 기다리는 시간(초). 기본값은 `“60”`입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 HTTP 서비스(cshttpd)를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	설명과 기본값
`service.http.admins`	Calendar Server에 대해 관리 권한이 있는 사용자 아이디의 공백으로 구분된 목록. 기본값은 `"calmaster"`입니다.
`service.http.allowadminproxy`	기본값인 `"yes"`를 사용하면 프록시를 통한 로그인이 허용됩니다.
`service.http.allowanonymouslogin`	값이 "yes"이면 익명(인증 없음) 액세스가 허용됩니다. 지정된 제한 액세스(주로 공용 달력에 대한 읽기 전용 액세스)만 허용되는 특별한 로그인 유형입니다. 기본값은 `"yes"`입니다.
`service.http.calendarhostname`	HTML 문서를 검색하기 위한 HTTP 호스트. 사용자가 정규화된 호스트 이름을 사용하여 달력 데이터에 액세스하려면 이 값이 `mycal@sesta.com`과 같이 시스템 이름, DNS 도메인 및 접미어가 포함되어 있으며 Calendar Server가 실행되고 있는 시스템의 정규화된 호스트 이름이어야 합니다. 지정하지 않으면 로컬 HTTP 호스트가 사용됩니다.
`service.http.commandlog`	이 매개 변수는 디버깅에만 사용됩니다. `"yes"`로 설정하면 수신된는 모든 명령이 `http.commands` 로그 파일에 기록됩니다. 프로덕션 런타임 중에는 이 매개 변수를 사용하지 마십시오. 로그 파일이 빠르게 채워지고 성능 저하가 발생할 수 있습니다.
`service.http.commandlog.all`	이 매개 변수는 디버깅에만 사용됩니다. `"yes"`로 설정하면 모든 HTTP 요청이 `http.access` 로그 파일에 기록됩니다. 프로덕션 런타임 중에는 이 매개 변수를 사용하지 마십시오. 로그 파일이 빠르게 채워지고 성능 저하가 발생할 수 있습니다.
`service.http.cookies`	서버에 쿠키 지원 여부를 알려줍니다(yes/no). 단일 사인온을 사용하려면 `"yes"`로 설정해야 합니다. 기본값은 `"yes"`입니다.
`service.http.dbcachesize`	HTTP 세션을 위한 Berkeley 데이터베이스의 최대 캐시 크기. 기본값은 `"8388308"`입니다.
`service.http.domainallowed`	이 매개 변수가 지정되었지만 공백(`" "`)이 아닐 경우, 필터링을 통해 TCP 도메인을 기반으로 하는 액세스를 허용합니다. 예를 들어, `"ALL: LOCAL.sesta.com`"으로 설정하면 `sesta.com` 도메인의 누구에게나 로컬 액세스를 허용합니다. 여러 개의 필터는 `CR-LF`(줄바꿈)로 구분합니다. 기본값은 공백(`""`)입니다.
`service.http.domainnotallowed`	이 매개 변수가 지정되었는데 공백(`" "`)이 아닐 경우, 필터링을 통해 TCP 도메인을 기반으로 하는 액세스를 허용합니다. 예를 들어, `"ALL: LOCAL.sesta.com"`으로 설정하면 `sesta.com` 도메인의 누구에게나 액세스를 거부합니다. 여러 개의 필터는 `CR-LF`(줄바꿈)로 구분합니다. 기본값은 공백(`" "`)입니다.
`service.http.attachdir.path`	가져온 파일을 임시로 저장할 `local.queuedir`에 상대적인 디렉토리 위치(또는 절대 경로 지정)이며기본값은 현재 디렉토리(`"."`)입니다.
`service.http.ipsecurity`	값이 `"yes"`이면 기존 세션을 참조하는 모든 요청이 같은 IP 주소에서 온 것으로 확인됩니다. 기본값은 `“yes”`입니다.
`service.http.enable`	값이 `"yes"`이면 모든 서비스를 시작할 때 `cshttpd` 서비스를 시작하고 모든 서비스를 중지할 때 `cshttpd` 서비스를 중지합니다. 기본값은 `“yes”`입니다. 주의 – 이 매개 변수로 HTTP 서비스를 비활성화하면 HTTPS도 비활성화됩니다.
`service.http.idletimeout`	HTTP 연결 시간이 초과되기까지의 시간(초)기본값은 `“120”`입니다.
`service.http.listenaddr`	HTTP 서비스가 클라이언트 요청을 수신할 TCP 주소를 지정합니다. 기본값은 `"INADDR_ANY"`이며 임의의 주소를 나타냅니다.
`service.http.logaccess`	값이 `"yes"`이면 서버에 대한 HTTP 연결이 모두 기록됩니다. 기본값은 `“no”`입니다.
`service.http.maxsessions`	cshttpd 서비스에 있는 HTTP 세션의 최대 수기본값은 `“5000”`입니다.
`service.http.maxthreads`	`cshttpd` 서비스에서 HTTP 요청을 처리하는 최대 스레드 수. 기본값은 `“20”`입니다.
`service.http.numprocesses`	한 서버에서 실행되어야 하는 최대 동시 실행 HTTP 서비스(`cshttpd` ) 프로세스 수이며 기본값은 `“1”`입니다. 여러 개의 CPU가 있는 서버의 경우 21.8 여러 CPU에 걸쳐 로드 균형 조정 사용을 참조하십시오.
`service.http.port`	Calendar Server 사용자의 HTTP 요청을 위한 포트. 기본값은 `“80”`입니다.
`service.http.proxydomainallowed`	이 매개 변수가 지정되었는데 `""`이 아닐 경우 필터링을 통해 TCP 도메인을 기반으로 한 프록시 로그인을 허용합니다. `service.http.domainallowed`와 동일한 구문입니다. 기본값은 `""`입니다.
`service.http.resourcetimeout`	HTTP 세션 시간이 초과되기까지의 시간(초). 기본값은 `“900”`입니다.
`service.http.sessiondir.path`	HTTP 세션 데이터베이스의 디렉토리입니다. 기본값은 `“http”` 입니다.
`service.http.sessiontimeout`	`cshttpd` 서비스의 HTTP 세션이 시간 초과될 때까지의 시간(초). 기본값은 `“1800”`입니다.
`service.http.sourceurl`	파일에 대한 모든 URL 참조가 저장되는 실행 프로그램과 관련된 디렉토리. 기본값은 `""`(null)입니다.
`service.http.tmpdir`	HTTP 세션을 위한 임시 디렉토리. 기본값은 `"/var/opt/SUNWics5/tmp"`입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server Version 6.3의 경보 알림 구성

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 ics.conf 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명과 기본값
`alarm.diskstat.msgalarmdescription`	디스크 공간 부족 메시지와 함께 보내는 설명 기본 설명은 `“percentage calendar partition diskspace available”`입니다.
`alarm.diskstat.msgalarmstatinterval`	디스크 공간 모니터링 사이의 시간(초). 기본값은 `“3600”`입니다.
`alarm.diskstat.msgalarmthreshold`	경고 메시지 전송을 트리거하는 사용 가능한 디스크 공간의 비율. 기본값은 `“10”`입니다.
`alarm.diskstat.msgalarmthresholddirection`	`alarm.diskstat.msgalarmthreshold`가 비율보다 큰지 또는 작은지를 나타냅니다. `-1`이면 비율보다 작고 `1`이면 비율보다 큽니다. 기본값은 `“-1”`입니다.
`alarm.diskstat.msgalarmwarninginterval`	디스크 공간 부족에 대한 경고 메시지 전송 사이의 시간. 기본값은 `“24”`입니다.
`alarm.msgalarmnoticehost`	서버 경보를 보내는 데 사용되는 SMTP 서버의 호스트 이름. 기본값은 `“localhost”`입니다.
`alarm.msgalarmnoticeport`	서버 경보를 보내는 데 사용되는 SMTP 포트. 기본값은 `“25”`입니다.
`alarm.msgalarmnoticercpt`	서버 경보를 보내는 전자 메일 주소. `“Postmaster@localhost”`
`alarm.msgalarmnoticesender`	서버가 경보를 보낼 때 보내는 사람으로 사용되는 전자 메일 주소. 기본값은 `“Postmaster@localhost”`입니다.
`alarm.msgalarmnoticetemplate`	전자 메일 경보를 보내는 데 사용되는 기본 형식은 다음과 같습니다. `"From: %s\nTo: %s\nSubject: ALARM: %s of \"%s\" is n\n%s\n"`
`alarm.responsestat.msgalarmdescription`	서비스 응답 없음 메시지와 함께 보내는 설명. 기본값은 `“calendar service not responding”`입니다.
`alarm.responsestat.msgalarmstatinterval`	서비스 모니터링 사이의 시간(초). 기본값은 `“3600”`입니다.
`alarm.responsestat.msgalarmthreshold`	기본값은 `“100”`(서비스가 응답하지 않는 경우에만 경고 메시지 보내기 트리거)으로 시작해야 합니다.
`alarm.responsestat.` `msgalarmthresholddirection`	`alarm.responsestat.msgalarmthreshold`가 비율보다 큰지 또는 작은지를 지정합니다. -1이면 비율보다 작고 1이면 비율보다 큽니다. 기본값은 `“-1”`입니다.
`alarm.responsestat.` `msgalarmwarninginterval`	서비스 응답이 없다는 경고 메시지 사이의 시간. 기본값은 `“24”`입니다.
`local.rfc822header.allow8bit`	이 서버에서 보내는 전자 메일 메시지에 8비트 헤더를 허용(`"y"`)하거나 허용하지 않습니다(`"n"`).
`service.admin.alarm`	관리 도구를 위한 경보 알림을 사용 가능(`"yes"`) 또는 사용 불가능(`"no"`)하게 합니다. 기본값은 `“yes”`입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

4.7 Calendar Server 버전 6.3에서 Berkeley를 위한 주기적인 교착 상태 검사 구성

Berkeley 데이터베이스의 교착 상태를 주기적으로 검사하도록 Calendar Server를 구성할 수 있습니다.

Berkeley 데이터베이스가 교착 상태가 되어 액세스를 못할 수 있습니다. 교착 상태를 가능한 빨리 검색하려면 교착 상태에 대한 주기 검사를 활성화합니다.

Berkeley 데이터베이스의 교착 상태 주기 검사를 활성화하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

local.caldb.deadlock.autodetect

Berkeley 데이터베이스가 교착 상태에 있는지 정기적으로 검사하고 교착 상태에 있을 경우 데이터베이스에 재설정을 지시합니다. 기본값은 “no”(사용 불가능)입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

일반 오류

교착 상태가 된 후에 Berkeley 데이터베이스를 재설정하는 방법에 대한 자세한 내용은 문제 해결 장에서 22.5.2 데이터베이스 손상 검색 22.5.1.2 사용 가능한 도구 목록을 참조하십시오.

4.8 Calendar Server 버전 6.3의 LDAP 구성

이 절에서는 LDAP를 위해 Calendar Server를 구성하기 위한 지침을 제공합니다.

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

Calendar Server 버전 6.3의 LDAP에 대한 익명 액세스를 구성하려면

일반적으로 익명 액세스는 기본적으로 허용됩니다. 익명 액세스를 제한하려면 해당 매개 변수를 변경합니다.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명/기본값
`calstore.anonymous.calid`	익명 로그인 달력 식별자(`calid`)를 지정합니다. 기본값은 `"anonymous"`입니다.
`service.http.allowanonymouslogin`	로그인 없는 익명 액세스가 허용되는지 여부를 지정합니다. 기본값은 `“yes”`입니다. 이 값을 설정하면 전자 메일로 보낸 달력 URL의 수신자가 로그인하지 않고 달력의 사용 가능/사용 중 버전에 액세스할 수 있습니다.
`service.wcap.anonymous.` `allowpubliccalendarwrite`	익명 사용자에게 공개적으로 쓸 수 있는 달력에 대한 쓰기를 허용할지 여부를 지정합니다. 기본값은 `“yes”`입니다.
`service.wcap.userprefs.ldapproxyauth`	사용자 기본 설정에 사용된 LDAP에 대한 익명 검색을 사용 가능하게 합니다. 기본값은 `“no”`이며 익명 액세스를 허용합니다. `“yes”`를 지정하면 검색 수행을 위한 프록시 인증을 사용합니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 LDAP 참석자 조회를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표의 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명/기본값
`local.lookupldap.search.` `minwildcardsize`	참석자 조회 검색에서 와일드카드 검색을 위한 최소 문자열 크기를 지정합니다. 제로(`0`)는 항상 와일드카드 검색을 한다는 것을 의미합니다.
`sasl.default.ldap.searchfilter`	사용자 조회를 위한 인증 필터를 지정합니다. 기본값은 다음과 같습니다. `"(uid=%s)"`
`local.lookupldapbasedn`	LDAP 참석자 조회를 위한 DN을 지정합니다. 지정하지 않으면 `local.ugldapbsedn` 이 사용됩니다. 기본값은 없습니다
`local.lookupldapbinddn`	LDAP 참석자 조회에 사용되는 호스트에 바인드할 DN을 지정합니다. 이 값을 지정하지 않고 기본값 `““`이 사용되면 익명 바인드인 것으로 간주됩니다.
`local.lookupldapbindcred`	`local.lookupldapbinddn` 에 식별된 사용자를 위한 자격 증명(비밀번호)입니다. 기본값은 없습니다
`local.lookupldaphost`	LDAP 참석자 조회를 위한 호스트 이름입니다. 지정하지 않으면 `local.ugldaphost`이 사용됩니다.
`local.lookupldapmaxpool`	LDAP 참석자 조회를 위해 유지되는 LDAP 클라이언트 연결 수를 지정합니다. 지정하지 않으면 `local.ugldapmaxpool`이 사용됩니다. 기본값은 `“1024”`입니다.
`local.lookupldappoolsize`	LDAP 참석자 조회를 위해 유지되는 LDAP 클라이언트 연결의 최대 수를 지정합니다. 지정하지 않으면 `local.ugldappoolsize`가 사용됩니다. 기본값은 `"1"`입니다.
`local.lookupldapport`	LDAP 참석자 조회에 사용할 포트를 지정합니다. 지정하지 않으면 `local.ugldapport`이 사용됩니다.
`local.lookupldapsearchattr.calid`	참석자 조회를 위한 calid 속성을 지정합니다. 기본값은 `icsCalendar`입니다.
`local.lookupldapsearchattr.mail`	참석자 조회를 위한 메일 속성을 지정합니다. 기본값은 `mail`입니다.
`local.lookupldapsearchattr.` `mailalternateaddress`	참석자 조회를 위한 대체 메일 주소 속성을 지정합니다. 기본값은 `mailalternateaddress`입니다.
`local.lookupldapsearchattr.` `mailequivalentaddres`	참석자 조회를 위한 동일한 주소 메일 속성을 지정합니다. 기본값은 `mailequivalentaddress`입니다.
`local.lookupldapsearchattr.` `calendar`	참석자 조회를 위한 달력 속성을 지정합니다. 기본값은 `icsCalendar`입니다.
`local.lookupldapsearchattr.cn`	참석자 조회를 위한 공통 이름 속성을 지정합니다. 기본값은 `cn`입니다.
`local.lookupldapsearchattr.` `objectclass`	참석자 조회를 위한 객체 클래스 속성을 지정합니다. 기본값은 `objectclass`입니다.
`local.lookupldapsearchattr.` `objectclass.caluser`	달력 사용자에 대한 객체 클래스를 지정합니다. 기본값은 `icsCalendarUser`입니다.
`local.lookupldapsearchattr.` `objectclass.calresource`	달력자원에대한객체클래스를지정합니다. 기본값은 `icsCalendarResource`입니다.
`local.lookupldapsearchattr.` `objectclass.group`	그룹에 대한 객체 클래스를 지정합니다. 기본값은 `icsCalendarGroup`입니다.
`local.lookupldapsearchattr.` `objectclass.person`	개인에 대한 객체 클래스를 지정합니다. 기본값은 `person`입니다.
`local.lookupldapsearchattr.` `memberurl`	참석자 조회를 위한 구성원 URL 속성을 지정합니다. 기본값은 `memberurl`입니다.
`local.lookupldapsearchattr.` `uniquemember`	참석자 조회를 위한 고유 구성원 속성을 지정합니다. 기본값은 `uniquemember`입니다.
`local.lookupldapsearchattr.` `givenname`	참석자 조회를 위한 이름 속성을 지정합니다. 기본값은 `givenname`입니다.
`local.lookupldapsearchattr.sn`	참석자 조회를 위한 화면 이름 속성을 지정합니다. 기본값은 `sn`입니다.
`local.smtp.defaultdomain`	전자 메일 주소와 일치하는 참석자의 달력 아이디를 조회하는 데 사용되는 기본 도메인의 이름입니다. 예를 들어, 이 설정 값이 `"sesta.com"`이면 jsmith는 `jsmith@sesta.com`으로 결정됩니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 LDAP 참석자 조회용 검색 필터를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표의 매개 변수 중 하나 이상을 편집합니다.

정보 –

다음에 나오는 모든 매개 변수 설명에서 %s는 단일 참석자만 허용합니다.

매개 변수	설명/기본값
`local.lookupldap.calid.direct`	직접 조회를 사용하는 calid 검색 유형을 위한 검색 필터입니다. 기본값은 다음과 같습니다. `"(icsCalendar=%s)"` %s – 참석자 문자열
`local.lookupldap.cn.direct`	간접 조회에서 cn 검색 유형을 위한 검색 필터입니다. 기본값은 다음과 같습니다. "(&(cn=%s) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person)))" `%s` – 참석자 문자열
`local.lookupldap.cn.search`	검색 대화 상자 조회에서 cn 검색 유형을 위한 검색 필터입니다. 단일 참석자 문자열(`%s`)을 위한 기본값: "(&(cn=%s) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person)))" 와일드카드 검색(다중 검색 문자열): "(&(cn=%w) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person)))" `%w` – 참석자 문자열 목록으로 확장합니다. 예를 들면 다음과 같습니다. `%w=”Mary Ann Smith”`는 (& (cn=Mary) (cn=”Ann”) (cn=Smith*)로 확장합니다.
`local.lookupldap.gid`	`gid` 검색 유형을 위한 검색 필터입니다. 기본값은 다음과 같습니다. "(&(cn=%s) (objectclass=groupofuniquenames))" `%s` — 단일 참석자 문자열
`local.lookupldap.mailto.indomain`	`local.smtp.defaultdomain`에 지정된 도메인에서 mailto 검색 유형을 위한 검색 필터입니다. 기본값은 다음과 같습니다. "(\|(mail=%s)(mail=%h)(mail=<%s\>) (uid=%o))" `%s` – 참석자 문자열 `%o` – 참석자 `uid` `%h` – 도메인 부분이 없는 쿼리 문자열 예를 들면 다음과 같습니다. `%s=jdoe@sesta.com`, `%o=jdoe@sesta.com` 및 `%h=jdoe`이면 값은 다음과 같습니다. (\|(mail=jdoe@varrius.com) (mail=jdoe) (mail=<jdoe@varrius.com\>) (uid=jdoe@varrius.com))
`local.lookupldap.mailto.outdomain`	`local.smtp.defaultdomain`에 지정되지 않은 도메인에서 mailto 검색 유형을 위한 검색 필터입니다. 기본값은 다음과 같습니다. `"(\|(mail=%s)(uid=%s))"` `%s` – 참석자 문자열
`local.lookupldap.res`	`res` 검색 유형(자원 검색)을 위한 검색 필터입니다. 기본값은 다음과 같습니다. "(&(cn=%s) (objectclass=icsCalendarResource))" `$s` – 참석자 문자열
`local.lookupldap.res.ugldap`	사용자/그룹 LDAP 서버 전용 `res` 검색 유형(자원 검색)을 위한 검색 필터입니다. `local.lookupldap.resource.use.ugldap`가 `”yes“`로 설정될 경우에만 사용합니다. 기본값은 다음과 같습니다. "(&(cn=%s) (objectclass=icsCalendarResource))" `%s` – 참석자 문자열
`local.lookupldap.uid.direct`	직접 조회를 사용하는 `uid` 검색 유형을 위한 검색 필터입니다. 기본값은 다음과 같습니다. "(\|(uid=%s)(&(cn=%s) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person))))" `%s` – 참석자 문자열
`local.lookupldap.uid.search`	검색 대화 상자를 사용하는 `uid` 검색 유형 조회를 위한 검색 필터입니다. 기본값은 다음과 같습니다. "(\|(uid=%o)(&(cn=%w) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person))))" `%s` – 참석자 문자열 `%w` – 와일드카드가 있는 참석자 문자열 `%o` – 와일드카드가 없는 참석자 문자열

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 LDAP 자원 조회를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

local.lookupldap.resource.use.ugldap

자원 조회를 위해 사용자/그룹 LDAP 서버를 사용하는지 조회 서버를 사용하는지 여부를 나타냅니다.

“yes” – 사용자/그룹 LDAP 서버를 사용합니다.

“no” – 조회 서버를 사용합니다. 기본값은 “no”입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 LDAP Mail-to-Calid 조회를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표의 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명/기본값
`local.lookupldap.mailtocalid.search`	mail-to-calid 조회에 사용할 메일 속성을 지정합니다. 기본값은 `"(\|(mail=%s)(mailalternateaddress=%s))”`입니다. `mailalternateaddress` 대신 `mailequivalentaddress` 속성으로 대체할 수 있습니다.
`local.ugldapbasedn`	mail-to-calid 조회를 위한 기본 DN을 지정합니다.
`local.authldapbinddn`	mail-to-calid 조회에 사용되는 호스트에 바인드할 DN을 지정합니다. 이 값을 지정하지 않고 기본값 `""`이 사용되면 익명 바인드인 것으로 간주됩니다.
`local.authldapbindcred`	`local.authldapbinddn`에 지정된 사용자를 위한 바인드 자격 증명(비밀번호). 기본값은 없습니다.
`local.ugldaphost`	mail-to-calid 조회에 사용되는 LDAP 호스트를 지정합니다.
`local.ugldapmaxpool`	mail-to-calid 조회에 대해 유지되는 최대 클라이언트 연결 수를 지정합니다. 기본값은 `“1024”`입니다.
`local.ugldappoolsize`	mail-to-calid 조회에 대해 유지할 최소 클라이언트 연결 수를 지정합니다. 기본값은 `“1”`입니다.
`local.ugldapport`	LDAP mail-to-calid 조회를 위한 포트를 지정합니다. 기본값은 없습니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 사용자 기본 설정 LDAP 디렉토리를 구성하려면

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표의 매개 변수 중 하나 이상을 편집합니다.

매개 변수	설명/기본값
`local.enduseradmincred`	LDAP 사용자 기본 설정 인증을 위한 바인드 자격 증명(비밀번호). 기본값은 없습니다.
`local.enduseradmindn`	LDAP 사용자 기본 설정 호스트를 바인드하는 데 사용되는 DN. 이 매개 변수는 반드시 지정해야 합니다. 이 값을 공백(`" "`)으로 두거나 지정하지 않으면 익명 바인드로 간주됩니다.
`local.ugldappoolsize`	LDAP 사용자 기본 설정을 위해 유지되는 최소 LDAP 클라이언트 연결 수. 기본값은 `“1”`입니다.
`local.ugldapmaxpool`	LDAP 사용자 기본 설정을 위해 유지되는 최대 LDAP 클라이언트 연결 수. 기본값은 `“1024”`입니다.
`service.wcap.userprefs.ldapproxyauth`	사용자 기본 설정에 사용된 LDAP에 대한 익명 검색을 사용 가능하게 합니다. 기본값은 `“no”`이며 익명 액세스를 허용합니다. `“yes”`를 지정하면 검색 수행을 위한 프록시 인증을 사용합니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 사용자 기본 설정을 구성하려면

기본값 목록에서 값을 제거하여 사용자가 설정할 수 있는 기본 설정을 제한할 수 있습니다.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 표시된 대로 매개 변수의 사용자 기본 설정 목록을 편집합니다.

매개 변수	사용자 기본 설정 기본 목록	설명
`local.` `ugldapicsextendeduserprefs`	`"ceColorSet,` `ceFontFace,` `ceFontSizeDelta,` `ceDateOrder,` `ceDateSeparator,` `ceClock,` `ceDayHead,` `ceDayTail,` `ceInterval,` `ceToolText,` `ceToolImage,` `ceDefaultAlarmStart,` `ceSingleCalendarTZID,` `ceAllCalendarTZIDs,` `ceDefaultAlarmEmail,` `ceNotifyEmail,` `ceNotifyEnable,` `ceDefaultView,` `ceExcludeSatSun,` `ceGroupInviteAll"`	사용자 기본 설정 값은 LDAP에 보관됩니다. 이 매개 변수는 LDAP의 `icsExtendedUserPrefs` 속성에 보관되는 사용자 기본 설정을 정의합니다.

매개 변수

사용자 기본 설정 기본 목록

설명

local.

ugldapicsextendeduserprefs

"ceColorSet,

ceFontFace,

ceFontSizeDelta,

ceDateOrder,

ceDateSeparator,

ceClock,

ceDayHead,

ceDayTail,

ceInterval,

ceToolText,

ceToolImage,

ceDefaultAlarmStart,

ceSingleCalendarTZID,

ceAllCalendarTZIDs,

ceDefaultAlarmEmail,

ceNotifyEmail,

ceNotifyEnable,

ceDefaultView,

ceExcludeSatSun,

ceGroupInviteAll"

사용자 기본 설정 값은 LDAP에 보관됩니다. 이 매개 변수는 LDAP의 icsExtendedUserPrefs 속성에 보관되는 사용자 기본 설정을 정의합니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3의 LDAP 데이터 캐시를 활성화 및 구성하려면

시작하기 전에

LDAP 데이터 캐시에 대한 개요 정보는 1.7 Calendar Server 버전 6.3의 LDAP 데이터 캐시 옵션을 참조하십시오.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 표시된 대로 매개 변수를 편집하여 LDAP 데이터 캐시를 활성화합니다.

매개 변수	설명과 기본값
`local.ldap.cache.enable`	LDAP 캐시를 사용 가능/사용 불가능하게 합니다. `“yes”`이면 캐시가 사용 가능하게 됩니다. `“no”`이면 캐시가 사용 불가능하게 됩니다. 기본값은 `“no”`입니다.
`local.ldap.cache.checkpointinterval`	검사점 스레드가 일시 정지하는 시간을 초 단위로 지정합니다. 기본값은 60초입니다.
`local.ldap.cache.circularlogging`	처리된 후 데이터베이스 로그 파일을 제거할지 지정합니다. 기본값은 `"yes"` 입니다.
`local.ldap.cache.homedir.path`	LDAP 데이터 캐시 데이터베이스의 물리적 위치를 지정합니다. 기본값은 다음과 같습니다. cal-svr-base/var/opt/SUNWics5 /csdb/ldap_cache
`local.ldap.cache.logfilesizemb`	검사점 파일의 최대 크기를 메가바이트 단위로 지정합니다. 기본값은 10MB입니다.
`local.ldap.cache.maxthreads`	LDAP 데이터 캐시 데이터베이스를 위한 스레드의 최대 수를 지정합니다. 기본값은 `"1000"`입니다.
`local.ldap.cache.mempoolsizemb`	공유 메모리의 크기를 메가바이트 단위로 지정합니다. 기본값은 `"4"`MB입니다.
`local.ldap.cache.entryttl`	현재 구현되어 있지 않습니다. LDAP 데이터 캐시 항목을 위한 지속 시간(TTL)을 초 단위로 지정합니다. 기본값은 `"3600"`초(1시간)입니다.
`local.ldap.cache.stat.enable`	LDAP 데이터 캐시 액세스 로그 여부 및 로그 파일의 통계 인쇄 여부를 지정합니다. 기본값은 no입니다. 주 – 이 매개 변수는 디버그 모드에만 적용됩니다.
`local.ldap.cache.stat.interval`	각 통계 보고서가 로그 파일에 기록되는 간격을 초 단위로 지정합니다. 기본값은 `"1800"`초(30분)입니다.
`local.ldap.cache.cleanup.interval`	각 데이터베이스 정리 사이의 간격을 초 단위로 지정합니다. 기본값은 `"1800"`초(30분)입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

참조

LDAP 데이터 캐시 조정에 대한 자세한 내용은 21.5 LDAP 데이터 캐시의 성능 개선을 참조하십시오.

주의 –

Calendar Server 또는 Calendar Server가 실행되고 있는 서버가 제대로 종료되지 않은 경우에는 ldap_cache 디렉토리에 있는 모든 파일을 수동으로 삭제하여 이후에 다시 시작할 때 문제가 될 수 있는 데이터베이스 손상을 방지해야 합니다.

Calendar Server 버전 6.3의 LDAP SDK 캐시를 활성화 및 구성하려면

LDAP SDK 캐시는 기본적으로 사용 불가능합니다.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.ldapmemcache

값이 "yes"이면 LDAP SDK 캐시가 사용 가능하게 됩니다. 기본값은 “no”입니다.

service.ldapmemcachettl

service.ldapmemcache가 "yes"이면 이 매개 변수는 항목을 캐시할 수 있는 최대 시간(초)을 설정하는 데 사용됩니다. 이 값이 “0”이면 한 항목을 캐시에 저장할 수 있는 시간 제한이 없습니다. 기본값은 “30”입니다.

service.ldapmemcachesize

service.ldapmemcache가 "yes"인 경우, 이 매개 변수는 캐시가 사용할 최대 메모리 양(바이트)을 설정하는데 사용됩니다. “0”이면 캐시에는 크기 제한이 없습니다. 기본값은 “131072”입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3을 위한 사용 가능/사용 중 검색의 날짜 범위 설정

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.wcap.freebusybegin

get_freebusy 범위 시작에 대한 현재 시간으로부터의 오프셋을 일 단위로 지정합니다. 기본값은 “30” 입니다.

service.wcap.freebusyend

get_freebusy 범위의 끝에 대한 현재 시간으로부터의 오프셋을 일 단위로 지정합니다. 기본값은 “30” 입니다.

Save the file as ics.conf.

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3을 위한 달력 등록 정보의 와일드카드 LDAP 검색 활성화

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 표시된 대로 매개 변수를 편집합니다.
service.calendarsearch.ldap. primaryownersearchfilter
검색 문자열과 정확히 일치하는 항목을 찾기 위해 search_calprops 검색에 사용되는 기본 검색 필터입니다. 검색 문자열이 등록 정보 값에 포함된 일치 항목을 찾는 와일드카드 검색을 허용하려면 이 매개 변수의 주석 처리를 제거합니다. 다음 검색 필터를 사용할 수 있습니다.
```
"(&(|(uid=*%s*)(cn=*%s*))
(objectclass=icsCalendarUser))"
```
이 검색 필터를 사용하면 성능에 부정적인 영향을 줄 수 있습니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base /SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3에서 LDAP 루트 접미어 설정

LDAP 조직 트리(Schema 버전 2) 또는 도메인 구성 요소 트리(Schema 버전 1)에 대한 루트 접미어를 다시 설정할 수 있지만 주의해서 수행해야 합니다. 이 작업은 구성 프로그램을 다시 실행하여 수행하는 것이 좋습니다.

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

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

service.dcroot

디렉토리에 있는 DC 트리의 루트 접미어입니다. Schema 버전 1을 사용한 다중 도메인 지원 및 Schema 버전 2 호환성 모드(1.5)에 필요합니다. 기본값은 "o=internet"입니다.

10.2 Calendar Server 버전 6.3에서 처음으로 다중 도메인 환경 설정을 참조하십시오.

service.schema2root

Schema 버전 2에 대한 DIT(조직 트리)의 루트 접미어이며 기본값은 없습니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

5장 Calendar Server 버전 6.3에서 여러 시스템 간 달력 데이터베이스 배포 구성

이 장에서는 여러 백엔드 서버에서 달력 데이터베이스 배포를 가능하게 하는 달력 조회 데이터베이스(CLD) 플러그 인 사용 방법에 대해 설명합니다. CLD 플러그 인을 활성화하고 구성해야 합니다.

주의 –

프런트엔드 서버와 백엔드 서버에서 동일한 버전의 Calendar Server를 실행해야 합니다.

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

정보 –

CLD 플러그 인의 성능을 향상시키는 방법에 대한 자세한 내용은 21 장, Calendar Server 성능 조정을 참조하십시오.

5.1 Calendar Server 버전 6.3용 CLD 플러그 인 배경 정보

이 절에서는 CLD 플러그 인을 실제로 활성화하고 구성하기 전에 이해하면 도움이 되는 유용한 개요 및 배경 정보를 제공합니다.

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

5.1.1 Calendar Server 버전 6.3용 CLD 플러그 인 개요

달력 조회 데이터베이스(CLD) 플러그 인에서는 단일 달력 인스턴스에서 사용자 및 자원 달력을 여러 백엔드 서버에 분산할 수 있게 함으로써 달력 데이터베이스의 수평 확장성을 제공합니다. 달력 데이터베이스가 여러 백엔드 서버에 분산된 경우 Calendar Server는 CLD 플러그 인을 사용하여 달력이 실제로 저장된 서버를 확인합니다.

Calendar Server는 데이터 와이어 프로토콜(DWP)을 사용하여 백엔드 서버의 달력 데이터에 액세스합니다. DWP는 csdwpd 서비스로 실행되는 내부 프로토콜이며 달력 데이터베이스를 위한 네트워킹 기능을 제공합니다.

5.1.2 Calendar Server 버전 6.3용 CLD 플러그 인 작동 방법

Calendar Server는 다음과 같이 백엔드 서버의 달력 데이터에 액세스합니다.

최종 사용자가 Communications Express를 통해 달력에 액세스하면 CLD 플러그 인은 달력의 calid에서 userid를 추출한 후 LDAP 디렉토리 데이터베이스 또는 CLD 데이터 캐시(활성화된 경우)에서 달력 소유자를 조회합니다. 프런트엔드 시스템을 구성하는 방법에 대한 자세한 내용은 CLD를 위한 프런트엔드 서버 구성을 참조하십시오.
이 플러그 인은 달력 소유자를 찾은 후 소유자의 icsDWPHost LDAP 속성 값을 사용하여 달력이 있는 백엔드 서버의 호스트 이름을 확인합니다. 이 이름은 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다.
이 호스트 이름을 사용하는 Calendar Server는 데이터베이스 와이어 프로토콜(DWP)을 사용하여 백엔드 서버의 달력 데이터에 액세스합니다.
Calendar Server는 DWP를 사용하여 달력 데이터가 사용자 인터페이스 중 하나에서 렌더링될 수 있도록 사용자가 로그인한 서버로 해당 데이터를 보냅니다.

정보 –

사이트에서 CLD 플러그 인을 사용하는 경우에는 같은 사용자에 대해 만든 모든 달력이 LDAP 사용자 항목의 icsDWPHost LDAP 속성에 표시된 서버와 동일한 백엔드 서버에 있어야 합니다. 다른 백엔드 서버에서 달력을 만들려고 할 경우 Calendar Server는 오류를 반환합니다.

5.1.3 Calendar Server 버전 6.3용 CLD 플러그 인에서 지원되는 구성

이 절에서는 CLD 플러그 인에 대한 개요 정보를 제공합니다.

CLD 플러그 인은 다음 Calendar Server 구성을 지원합니다.

정보 –

이 모든 구성에서 각 프런트엔드 서버 및 백엔드 서버는 다음 조건을 만족해야 합니다.

동일한 하드웨어 플랫폼에 위치
같은 운영 체제 실행
패치를 포함하여 같은 Calendar Server 릴리스 실행
같은 DWP 포트 번호(service.dwp.port 매개 변수) 사용. 기본 포트 번호는 “59779”입니다.

5.1.3.1 Calendar Server 버전 6.3의 여러 프런트엔드 서버 및 백엔드 서버

그림 5–1에서는 단일 Calendar Server 인스턴스가 실행되는 두 대의 프런트엔드 서버와 두 대의 백엔드 서버를 보여 줍니다. 또한 필요에 따라 3대 이상의 프런트엔드 또는 백엔드 서버를 구성할 수 있습니다.

이 구성에서 서버는 LDAP 및 달력 데이터베이스에 대한 액세스를 제한하는 방화벽으로 보호할 수 있습니다. 달력 데이터베이스는 2대의 백엔드 서버에 분산됩니다.

프런트엔드 서버는 CPU를 많이 사용하며, 최종 사용자용 달력 데이터를 렌더링하는 데 대부분의 CPU 시간이 소요됩니다. 백엔드 서버는 디스크를 많이 사용하며, 달력 데이터베이스에 액세스하는 데 대부분의 CPU 시간이 소요됩니다.

구성 지침에 대해서는 5.2 CLD 및 DWP를 위한 Calendar Server 구성을 참조하십시오.

그림 5–1 다중 프런트엔드 서버와 다중 백엔드 서버

이 예에서는 다중 백엔드 및 프런트엔드 서버를 모두 포함하는 시스템을 보여 줍니다.

5.1.3.2 Calendar Server 버전 6.3의 여러 시스템이 프런트엔드 및 백엔드 서버로 작동

그림 5–2에서는 프런트엔드 및 백엔드 서버 둘 다로 작동하는 세 대의 시스템을 보여 줍니다. 각 시스템은 달력 데이터베이스에 연결됩니다. 이 구성에서는 달력의 지역적인 분산이 가능합니다. 달력 소유자(최종 사용자)는 달력이 위치한 시스템에 로그인합니다. 구성 지침에 대해서는 서버를 프런트엔드 및 백엔드 둘 다로 구성하려면을 참조하십시오.

그림 5–2 프런트엔드/백엔드 둘 다로 작동하는 여러 서버

이 그림은 프런트엔드 및 백엔드 시스템 둘 다로 작동하는 시스템의 예를 보여 줍니다.

5.1.4 Calendar Server 6.3 저장소 요구 사항에 대한 간단한 크기 지정 방법

이 절에서는 보통 사용 프로필을 바탕으로 몇 가지 간단한 수식을 사용하여 크기를 지정하는 방법에 대해 설명합니다. 이를 통해 필요한 프런트엔드 및 백엔드 서버 수와 저장소 용량을 알 수 있습니다.

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

5.1.4.1 Calendar Server 6.3 배포를 위한 보통 사용 프로필의 정의

추정값을 계산하기 위해 다음과 같이 가정합니다.

모든 클라이언트는 웹 클라이언트입니다.

따라서 총 사용자 수와 동시 처리 백분율에 대한 입력만 사용합니다.
평균 크기의 달력 이벤트 크기는 5K입니다.
각 사람은 주당 10개의 이벤트 또는 작업을 만듭니다.
80%의 CPU 활용도
900MHz의 CPU
CPU당 1GB RAM
시스템에 2년 동안의 달력 데이터가 저장되어 있습니다.
스토리지에 6개의 핫 백업이 저장되어 있습니다.

5.1.4.2 프런트엔드 CPU의 수

수식은 다음과 같습니다.

CPU의 수 = 동시 사용자 수를 4800으로 나눈 값

5.1.4.3 백엔드 CPU의 수

수식은 다음과 같습니다.

CPU의 수 = 500,000명의 구성된 사용자당 CPU 4개

5.1.4.4 필요한 저장소 크기

수식은 다음과 같습니다.

사용자당 저장소 양 = 주당 100개의 전자 메일 * 연간 52주 * 전자 메일당 5K * 데이터를 온라인으로 유지해야 하는 년 수 * 온라인으로 유지해야 하는 복사본 수(5개의 백업 + 1개의 작업 복사본) = 100*52*5K*2*(5+1) = 사용자당 65MB의 저장소

즉, 연간 사용자당 온라인으로 유지해야 하는 복사본마다 2.6MB가 필요합니다.

주 –

최종 크기는 온라인으로 유지하는 핫 백업 또는 아카이브 백업의 수에 따라 달라집니다. 이 예에서는 백업 복사본이 5개 사용되었습니다.

5.2 CLD 및 DWP를 위한 Calendar Server 구성

이 절에서는 CLD 및 DWP용으로 서버를 구성하기 위한 지침을 제공합니다.

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

CLD를 위한 프런트엔드 서버 구성

모든 프런트엔드 서버에서 구성 변경 권한이 있는 관리자로 로그인합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

설명

csapi.plugin.loadall

모든 프런트엔드 서버에 대해 cs_로 시작하는 플러그 인을 모두 cal-svr-base/SUNWics5/cal/bin/plugins 디렉토리로 로드하려면 해당 값을 “y”로 설정합니다.

해당 이름을 csapi.plugin.calendarlookup.name에서 찾을 수 있는 특정 플러그 인만 로드하려면 "n"으로 설정합니다.

csapi.plugin.calendarlookup

이 매개 변수를 "yes"로 설정합니다.

csapi.plugin.calendarlookup.name

이 매개 변수를 "calendarlookup"라는 플러그 인 이름으로 설정합니다. 또는 모든 플러그 인을 로드하려면 매개 변수를 "*"로 설정합니다.

caldb.cld.type

이 매개 변수는 달력이 여러 백엔드에 분산될지(값이 “directory”로 설정) 아니면 달력을 Calendar Server가 설치된 동일한 서버에 저장할지(값이 기본값인 “local”로 설정) 지정합니다.

service.dwp.enable

프런트엔드 서버가 백엔드 시스템으로 작동하지 않는 한, 프런트엔드 서버에 대해 DWP 서비스를 비활성화합니다. 예를 들면 다음과 같습니다. service.dwp.enable="no"

service.dwp.port

기본 포트는 “59979”입니다. 포트 번호는 모든 프런트엔드 서버 및 백엔드 서버에서 동일해야 합니다.

service.store.enable

이 매개 변수는 기본적으로 활성화("yes")되며구성 파일(ics.conf)에는 표시되지 않습니다.

비활성화("no")하려는 경우에는 구성 파일에 추가해야 합니다.

caldb.dwp.server. backend-server-n.ip
여러 값을 갖는 매개 변수입니다. Calendar Server 배포의 각 백엔드 서버에 대해 하나의 ics.conf 매개 변수를 만듭니다. 이 매개 변수 값은 백엔드 서버 호스트 이름입니다. 서버 이름은 정규화된 이름이어야 하며 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다. 서버 이름은 매개 변수 이름과 값 둘 다에서 동일하며 정규화되어야 합니다.

예를 들면 다음과 같습니다.
```
caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
```
```
caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
```
caldb.dwp.server.default
사용자 또는 자원 LDAP 항목에 icsDWPHost 속성이 없으면 시스템에 사용되는 기본 DWP 서버 이름을 설정합니다. 서버 이름은 정규화된 이름이어야 하며 DNS에서 확인할 수 있어야 합니다.

예를 들면 다음과 같습니다.
```
caldb.dwp.sever.default="calendar1.sesta.com"
```
local.authldaphost

디렉토리 서버가 설치되어 있는 호스트 이름입니다. 기본값은 "localhost"입니다.

local.ugldaphost

LDAP 사용자 기본 설정이 저장되어 있는 호스트 이름입니다. 사용자 기본 설정을 별도의 LDAP 호스트에 보관하지 않는 경우 local.authldaphost와 같은 값으로 설정해야 합니다.

service.ens.enable

이 프런트엔드 서버에 대해 ENS(enpd)를 비활성화하려면 이 매개 변수를 "no"로 설정합니다.

ENS는 백엔드 서버에서만 활성화해야 합니다.

caldb.serveralarms

값을 "0"으로 설정하여 프런트엔드 서버에 대해 서버 경보를 비활성화합니다.

백엔드 서버에서만 서버 경보를 활성화해야 합니다("1").

caldb.serveralarms.dispatch

경보 디스패치를 비활성화하려면 이 매개 변수를 "no"로 설정합니다.

경보 디스패치는 백엔드 서버에서만 활성화해야 합니다("yes").

service.notify.enable

알림 서비스를 비활성화하려면 이 매개 변수를 "no"로 설정합니다.

알림 서비스는 백엔드 서버에서만 활성화해야 합니다("yes").

caldb.berkeleydb.archive.enable

자동 아카이브 백업 서비스를 비활성화하려면 이 매개 변수를 "no"로 설정합니다. 프런트엔드 시스템에서는 아카이브를 구성할 필요가 없습니다.

caldb.berkeleydb.hotbackup.enable

자동 핫 백업 서비스를 비활성화해야 합니다("no"). 프런트엔드 시스템에서는 핫 백업이 필요하지 않습니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

CLD 및 DWP를 위한 백엔드 서버 구성

모든 백엔드 서버에서 구성 변경 권한이 있는 관리자로 로그인합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 것처럼 ics.conf 매개 변수를 편집합니다.
매개 변수

설명

service.http.enable

이 매개 변수를 "no"로 설정합니다.

백엔드 서버에서는 HTTP가 필요하지 않습니다.

service.admin.enable

이 매개 변수를 기본값인 "yes"로 설정하여 관리 서비스(csadmind)를 활성화합니다.

caldb.cld.type

이 컴퓨터가 백엔드 전용 컴퓨터인 경우 "local"로 설정하고프런트엔드와 백엔드 둘 모두로 사용되는 경우 "directory"로 설정합니다.

csapi.plugin.calendarlookup

이 매개 변수를 "no"로 설정합니다.

백엔드 서버에는 플러그 인이 필요하지 않습니다.

service.dwp.enable

이 매개 변수를 "yes"로 설정하여 DWP를 활성화합니다.

service.dwp.port

기본 포트는 “59979”입니다. 포트 번호는 모든 프런트엔드 서버 및 백엔드 서버에서 동일해야 합니다.

caldb.dwp.server. backend-server-n.ip
여러 값을 갖는 매개 변수입니다. Calendar Server 배포의 각 백엔드 서버에 대해 하나의 ics.conf 매개 변수를 만듭니다. 이 매개 변수 값은 백엔드 서버 호스트 이름입니다. 서버 이름은 정규화된 이름이어야 하며 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다. 서버 이름은 매개 변수 이름과 값 둘 다에서 동일하며 정규화되어야 합니다.

예를 들면 다음과 같습니다.
```
caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
```
```
caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
```
caldb.dwp.server.default
사용자 또는 자원 LDAP 항목에 icsDWPHost 속성이 없으면 시스템에서 사용하는 기본 DWP 서버 이름을 설정합니다. 서버 이름은 정규화된 이름이어야 하며 DNS에서 확인할 수 있어야 합니다.

예를 들면 다음과 같습니다.
```
caldb.dwp.sever.default="calendar1.sesta.com"
```
local.authldaphost

디렉토리 서버가 설치되어 있는 호스트 이름입니다. 기본값은 "localhost"입니다.

local.ugldaphost

LDAP 사용자 기본 설정이 저장되어 있는 호스트 이름입니다. 사용자 기본 설정을 별도의 LDAP 호스트에 보관하지 않는 경우 local.authldaphost와 같은 값으로 설정해야 합니다.

service.ens.enable

이 백엔드 서버에 대해 ENS(enpd)를 활성화하려면 이 매개 변수를 "yes"로 설정합니다.

caldb.serveralarms

백엔드 서버에서 서버 경보를 활성화해야 합니다("1").

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

서버를 프런트엔드 및 백엔드 둘 다로 구성하려면

모든 서버에서 구성 변경 권한이 있는 관리자로 로그인합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 것처럼 ics.conf 매개 변수를 편집합니다.
매개 변수

설명

csapi.plugin.loadall

모든 프런트엔드 서버에 대해 cs_로 시작하는 플러그 인을 모두 cal-svr-base/SUNWics5/cal/bin/plugins 디렉토리로 로드하려면 해당 값을 “y”로 설정합니다.

해당 이름을 csapi.plugin.calendarlookup.name에서 찾을 수 있는 특정 플러그 인만 로드하려면 "n"으로 설정합니다.

csapi.plugin.calendarlookup

이 매개 변수를 "yes"로 설정합니다.

csapi.plugin.calendarlookup.name

모든 플러그 인을 로드하려면 이 매개 변수를 "*"로 설정합니다.

CLD 플러그 인만 로드하려면 이 매개 변수를 플러그 인의 이름 "calendarlookup"으로 설정합니다.

caldb.cld.type

이 매개 변수는 달력이 여러 백엔드에 분산될지(값이 “directory”로 설정) 아니면 달력을 Calendar Server가 설치된 동일한 서버에 저장할지(값이 기본값인 “local”로 설정) 지정합니다.

service.dwp.enable

이 매개 변수를 "yes"로 설정하여 DWP를 활성화합니다.

service.dwp.port

기본 포트는 “59979”입니다. 포트 번호는 모든 프런트엔드 서버 및 백엔드 서버에서 동일해야 합니다.

caldb.dwp.server. backend-server-n.ip
여러 값을 갖는 매개 변수입니다. Calendar Server 배포의 각 백엔드 서버에 대해 하나의 ics.conf 매개 변수를 만듭니다. 이 매개 변수 값은 백엔드 서버 호스트 이름입니다. 서버 이름은 정규화된 이름이어야 하며 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다. 서버 이름은 매개 변수 이름과 값 둘 다에서 동일하며 정규화되어야 합니다.

예를 들면 다음과 같습니다.
```
caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
```
```
caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
```
caldb.dwp.server.default
사용자 또는 자원 LDAP 항목에 icsDWPHost 속성이 없으면 시스템에 사용되는 기본 DWP 서버 이름을 설정합니다. 서버 이름은 정규화된 이름이어야 하며 DNS에서 확인할 수 있어야 합니다.

예를 들면 다음과 같습니다.
```
aldb.dwp.sever.default="calendar1.sesta.com"
```
local.authldaphost

디렉토리 서버가 설치되어 있는 호스트 이름입니다. 기본값은 "localhost"(프런트엔드와 동일한 서버에 있음)입니다.

local.ugldaphost

LDAP 사용자 기본 설정이 저장되어 있는 호스트 이름입니다. 사용자 기본 설정을 별도의 LDAP 호스트에 보관하지 않는 경우 local.authldaphost와 같은 값으로 설정해야 합니다.

service.ens.enable

이 매개 변수 값을 "yes"로 설정하여 ENS를 활성화합니다.

caldb.serveralarms

백엔드 서버에서 서버 경보를 활성화해야 합니다("1").

caldb.serveralarms.dispatch

백엔드 서버에서 경보 디스페처를 활성화해야 합니다("yes").

service.notify.enable

백엔드 서버에서 알림 서비스를 활성화해야 합니다("yes").

caldb.berkeleydb.archive.enable

백엔드 시스템에서 자동 아카이브 백업 서비스를 활성화해야 합니다("yes").

caldb.berkeleydb.hotbackup.enable

백엔드 시스템에서 자동 핫 백업 서비스를 활성화해야 합니다("yes").

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

5.3 Calendar Server 버전 6.3용 프런트엔드 및 백엔드 서버 간 보안 유지

프런트엔드와 백엔드 서버 사이에 비밀번호 인증을 구성할 수 있습니다. 이 절에서는 두 서버 사이에 안전한 통신을 설정하는 방법과 작동 방식을 설명합니다.

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

5.3.1 Calendar Server 버전 6.3에서 인증 구현 방법

프런트엔드 서버는 데이터베이스 와이어 프로토콜(DWP)을 사용하여 백엔드 서버와 통신합니다. DWP는 전송 메커니즘으로 HTTP를 사용하므로 Calendar Server는 구성 매개 변수를 사용하여 프런트엔드와 백엔드 서버 사이의 DWP 연결에 대한 인증을 제공합니다.

프런트엔드 서버는 처음 백엔드 서버에 연결하면 ics.conf 파일에 지정된 사용자 아이디와 비밀번호를 보냅니다. 백엔드 서버는 ics.conf 파일에서 매개 변수를 확인하며 두 매개 변수가 일치하면 인증이 성공한 것입니다. 그런 다음 백엔드 서버는 프런트엔드 서버로 세션 아이디를 보냅니다. 프런트엔드 서버는 이후 백엔드 서버에 DWP 명령을 보낼 때 이 세션 아이디를 사용합니다.

이후 같은 프런트엔드 서버에서 연결할 경우에는 백엔드 서버가 다시 시작되었거나 두 서버 간의 활동이 없어 세션이 만료되지 않은 한 다시 인증할 필요가 없습니다.

여러 대의 프런트엔드 서버 및 백엔드 서버가 있다면 각 서버에 동일한 사용자 아이디 및 비밀번호를 사용할 수 있습니다.

백엔드 서버에서 사용자 아이디와 비밀번호를 지정하지 않은 경우에는 인증이 수행되지 않습니다.

Calendar Server 버전 6.3에서 프런트엔드 서버의 DWP 연결 인증 설정

시작하기 전에

주의 –

이러한 매개 변수는 설치된 ics.conf 파일 버전에는 포함되어 있지 않습니다. DWP 연결에 인증을 사용하려면 각 프런트엔드 서버의 ics.conf 파일에 필수 매개 변수를 추가해야 합니다.

모든 프런트엔드 서버에서 구성 변경 권한이 있는 관리자로 로그인합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 목록에 나와 있는 대로 ics.conf 매개 변수를 추가합니다.

매개 변수

설명

caldb.dwp.server.back-end-server.admin

프런트엔드 서버에서 백엔드 서버에 대한 DWP 연결 인증에 사용되는 관리자의 사용자 아이디를 지정합니다. 여기서 back-end-server는 서버의 이름입니다.

caldb.dwp.server.back-end-server.cred

프런트엔드 서버에서 백엔드 서버에 대한 DWP 연결을 인증하는 데 사용되는 비밀번호를 지정합니다. 여기서 back-end-server는 서버의 이름입니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

Calendar Server 버전 6.3에서 백엔드 서버의 DWP 연결 인증 설정

시작하기 전에

주의 –

이러한 매개 변수는 설치된 ics.conf 파일 버전에는 포함되어 있지 않습니다. DWP 연결에 대한 인증을 사용하려면 각 프런트엔드 서버 및 백엔드 서버의 ics.conf 파일에 필수 매개 변수를 추가해야 합니다.

모든 백엔드 서버에서 구성 변경 권한이 있는 관리자로 로그인합니다.

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

ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

다음 표에 나와 있는 대로 ics.conf 매개 변수를 추가합니다.

매개 변수

설명

service.dwp.admin.userid

백엔드 서버에서 DWP 연결을 인증하는 데 사용되는 사용자 아이디를 지정합니다. 백엔드 서버에서 사용자 아이디를 지정하지 않은 경우에는 인증이 수행되지 않습니다.

service.dwp.admin.cred

백엔드 서버에서 DWP 연결을 인증하는 데 사용되는 비밀번호를 지정합니다. 백엔드 서버에서 비밀번호를 지정하지 않은 경우에는 인증이 수행되지 않습니다.

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

6장 고가용성 Calendar Server 6.3 소프트웨어 구성(페일오버 서비스)

이 장에서는 Sun Cluster 3.0 또는 3.1을 사용하여 고가용성 Calendar Server 6.3 소프트웨어를 설치 및 구성하는 방법을 설명합니다.

고가용성(HA) Calendar Server 구성에서는 소프트웨어 및 하드웨어 장애 모니터링과 복구를 지원합니다. Calendar Server HA 기능은 페일오버 서비스로 구현됩니다. 이 장에서는 Sun Cluster 소프트웨어를 사용하여 두 가지 Calendar Server HA(대칭 및 비대칭)를 구성하는 방법을 설명합니다.

이 장은 Calendar Server HA를 설치 및 구성하는 방법을 설명하며, 다음 내용으로 구성됩니다.

부록 C, Calendar Server 구성 워크시트에서 Calendar Server HA 구성 계획을 도와주는 워크시트 모음이 제공됩니다.

6.1 Calendar Server 버전 6.3의 고가용성 구성 방법 선택 개요

고가용성은 여러 가지 방법으로 구성할 수 있습니다. 이 절에서는 세 가지 고가용성 구성 방법을 간략히 설명하고 사용자 요구에 맞는 방법을 선택하는 데 도움이 되는 정보를 제공합니다.

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

6.1.1 Calendar Server 버전 6.3의 비대칭형 고가용성에 대한 이해

이 그림에서는 간단한 비대칭형 HA Calendar Server 설치 방법을 보여 줍니다.

간단한 비대칭형 고가용성 시스템에는 두 개의 물리적 노드가 있습니다. 일반적으로 주 노드가 활성 상태이며, 주 노드에서 오류가 발생한 경우 다른 노드가 백업 노드의 역할을 수행하여 문제를 해결합니다. 페일오버를 수행하기 위해 공유 디스크 어레이가 백업 노드의 마스터로 전환됩니다. 오류가 발생한 주 노드에서 Calendar Server 프로세스가 중지되고 백업 노드에서 시작됩니다.

이러한 유형의 고가용성 시스템에는 다양한 장점이 있습니다. 그 중 하나는 백업 노드를 주 노드 전용으로 완전히 예약하여 사용할 수 있다는 점입니다. 따라서 페일오버가 발생한 경우 백업 노드에서 자원 경합이 발생하지 않습니다. 또 다른 장점은 롤링 업그레이드를 수행하는 기능입니다. 이를 통해 한 노드를 업그레이드하면서 다른 노드에서 Calendar Server 소프트웨어를 계속 실행할 수 있습니다. 시작 시에는 구성 파일이 읽기 전용이므로 첫 번째 노드를 업그레이드하는 동안 ics.conf 파일을 변경해도 다른 노드에서 실행 중인 다른 Calendar Server 소프트웨어 인스턴스를 방해하지 않습니다. 달력 프로세스를 중지했다가 다시 시작해야 새 구성이 적용됩니다. 다른 노드를 업그레이드하려면 업그레이드된 주 노드에 대해 페일오버를 수행하고 보조 노드에서 업그레이드를 진행합니다.

주 –

물론, 보조 노드를 먼저 업그레이드한 다음 주 노드를 업그레이드할 수도 있습니다.

비대칭형 고가용성 모델에는 몇 가지 단점도 있습니다. 우선, 백업 노드가 대부분의 시간을 유휴 상태로 머물러 활용되지 않습니다. 다른 단점은 단일 저장소 어레이 문제입니다. 이 경우 간단한 비대칭형 고가용성 시스템에서 디스크 어레이 오류가 발생하는 경우 사용 가능한 백업이 없다는 것입니다.

6.1.2 대칭형 고가용성 Calendar Server 버전 6.3에 대한 이해

이 그림에서는 간단한 대칭형 Calendar Server HA 시스템을 보여 줍니다. 두 노드에 활성 상태의 Calendar Server 인스턴스가 있습니다.

간단한 대칭형 고가용성 시스템에는 활성 상태의 물리적 노드가 두 개 있습니다. 각 노드는 두 개의 저장소 볼륨이 포함된 자체 디스크 어레이를 가지고 있는데, 한 볼륨은 로컬 달력 저장소로 사용되고 다른 볼륨은 다른 노드의 달력 저장소에 대한 미러 이미지로 사용됩니다. 각 노드는 다른 노드의 백업 노드 역할을 합니다. 한 노드에서 자신의 백업 노드로 페일오버를 수행하면 Calendar Server의 두 인스턴스가 백업 노드에서 동시에 실행되는데, 각각 자신의 설치 디렉토리에서 실행되고 자신의 달력 저장소에 액세스합니다. 유일하게 백업 노드의 계산 능력이 공유됩니다.

이런 유형의 고가용성 시스템이 가진 장점은 두 노드가 동시에 활성 상태이므로 시스템 자원을 충분히 활용할 수 있다는 점입니다. 그러나 오류가 발생한 경우에는 두 노드에서 Calendar Server에 대한 서비스를 실행하기 때문에 백업 노드에서 더 많은 자원 경합이 발생하게 됩니다.

또한 대칭형 고가용성은 백업 저장소 어레이를 제공합니다. 디스크 어레이에 오류가 발생한 경우 백업 노드의 서비스가 중복 이미지를 선택할 수 있습니다.

주 –

대칭형 고가용성 시스템을 구성하려면 공유 디스크에 Calendar Server 바이너리를 설치하십시오. 이렇게 하면 롤링 업그레이드를 수행하지 않고도, 향후 Calendar Server 릴리스에서 계획된 기능에 대해 최소한 가동 중지 시간으로 또는 가동 중지 시간 없이 Calendar Server 패치 릴리스로 시스템을 업그레이드할 수 있습니다.

6.1.3 N+1(N Over 1): Calendar Server 버전 6.3의 여러 비대칭형 고가용성에 대한 이해

이 구성은 일련의 비대칭형 HA Calendar Server로, 각각 동일한 예비 노드로 페일오버를 수행합니다.

이 장에서 설명한 두 가지 유형의 고가용성 시스템과 더불어 이 두 유형의 하이브리드 형태인 세 번째 유형도 제공됩니다. 세 번째 유형은 다중 노드의 비대칭형 고가용성 시스템입니다. 이 유형에서 “N”개의 디스크 어레이와 “N”개의 노드는 모두 예약되어 있고 보통 비활성 상태인 동일한 백업 노드를 사용합니다. 이 백업 노드는 모든 “N”개 노드에 대해 Calendar Server를 실행할 수 있습니다. 이전 그림에 나와 있는 것처럼 “N”개 노드의 각 디스크 어레이를 공유합니다. 여러 노드에서 동시에 오류가 발생하는 경우 백업 노드는 최대 “N”개의 Calendar Server 인스턴스를 동시에 실행할 수 있어야 합니다. “N”개의 노드에는 각각 자신의 디스크 어레이가 있습니다.

N+1 모델의 장점은 Calendar Server의 부하를 여러 노드로 분산할 수 있으며, 발생 가능한 모든 노드 오류를 지원하기 위해 하나의 백업 노드만 필요하다는 데 있습니다.

이 유형의 단점은 비대칭형 시스템처럼 백업 노드가 대부분의 시간을 유휴 상태로 있다는 점입니다. 또한 N+1 고가용성 시스템 백업 노드는 여러 Calendar Server 인스턴스를 호스팅해야 하는 경우 용량을 추가해야 합니다. 따라서 시스템이 유휴 상태임에도 비용이 더 들게 됩니다. 그러나 시스템 유휴 비율은 1:1이 아닌1:N입니다(단일 비대칭형 시스템의 경우).

이러한 유형의 시스템을 구성하려면 “N” 노드 및 백업 노드를 위한 비대칭형 고가용성 시스템에 대한 지침을 참조하십시오. 매번 다른 주 노드에서 동일한 백업 노드를 사용합니다.

6.1.4 Calendar Server 버전 6.3 배포를 위한 고가용성 모델 선택

다음 표에는 각 고가용성 모델의 장단점이 요약되어 있습니다. 이 정보를 사용하여 배포에 적합한 모델을 결정할 수 있습니다.

표 6–1 두 고가용성 모델의 장단점


모델	장점	단점	권장되는 사용자
비대칭형	간단한 구성 백업 노드가 100% 예약됨 가동 중지 시간 없는 롤링 업그레이드	시스템 자원을 충분히 활용할 수 없음	향후 확장 계획이 있는 소규모 서비스 공급자
대칭형	시스템 자원의 활용도가 높음 더 높은 가용성	백업 노드에서 자원 경합 발생 HA에 완전하게 이중화된 디스크 필요	단일 서버 오류 발생 시 성능상의 단점을 수용할 수 있는 소규모 기업 배포
N+1	부하 분산 용이한 확장	복잡한 관리 및 구성	자원에 제약이 없이 분산되어야 하는 대규모 서비스 공급자

6.1.5 Calendar Server 6.3 배포 시 고가용성을 위한 시스템 가동 중지 시간 계산

다음 표에서는 지정된 날짜에 시스템 오류로 인해 달력 서비스를 사용할 수 없게 될 확률을 보여 줍니다. 시스템 손상 또는 서버 중단으로 인해 평균적으로 3개월마다 하루씩 서버가 다운되고 해당 저장 장치가 12개월마다 하루씩 다운된다고 가정합니다. 또한 두 노드가 동시에 다운될 수 있는 작은 확률은 무시합니다.

표 6–2 시스템 가동 중지 시간 계산


모델	서버 가동 중지 시간 확률
단일 서버(고가용성 아님)	Pr(다운) = (시스템 다운 4일 + 저장소 다운 1일)/365 = 1.37%
비대칭형	Pr(다운) = (시스템 다운 0일 + 저장소 다운 1일)/365 = 0.27%
대칭형	Pr(다운) = (시스템 다운 0일 + 저장소 다운 0일)/365 = (거의 0)
N + 1 비대칭형	Pr(다운) = (시스템 다운 5시간 + 저장소 다운 1일)/(365xN) = 0.27%/N

6.2 Calendar Server 버전 6.3 배포를 위한 HA 환경의 사전 요구 사항

이 절에서는 HA 환경에 Calendar Server를 설치하기 위한 사전 요구 사항에 대해 설명합니다.

다음과 같은 사전 요구 사항이 적용됩니다.

클러스터의 모든 노드에 Solaris 9 또는 Solaris 10 운영 체제가 필수 패치와 함께 설치되어야 합니다.
클러스터의 모든 노드에 Sun Cluster 3.0 또는 3.1이 설치되어야 합니다.
Java Enterprise System 설치 프로그램을 사용하여 클러스터의 모든 노드에 Calendar Server HA 에이전트 패키지(SUNWscics)를 설치해야 합니다.
로컬 파일 시스템을 HAStoragePlus 페일오버 파일 시스템(FFS) 또는 HAStorage 클러스터 파일 시스템(CFS)으로 지정합니다.

주 –
2001년 12월 이전 날짜의 Sun Cluster 3.0 버전이 있는 경우 HAStorage 클러스터 파일 시스템(CFS)으로 지정된 전역 파일 시스템을 사용해야 합니다.
대칭형 고가용성 시스템에 해당하는 논리적 볼륨을 작성 중인 경우 Solstice DiskSuite 또는 Veritas Volume Manager를 사용합니다.

6.2.1 Calendar Server 6.3 HA 배포용 HAStoragePlus 정보

HAStoragePlus 자원 유형을 사용하여 Sun Cluster 환경 내에 로컬로 마운트된 파일 시스템을 충분히 사용할 수 있습니다. Sun Cluster 전역 장치 그룹에 있는 모든 파일 시스템을 HAStoragePlus와 함께 사용할 수 있습니다. HAStoragePlus 파일 시스템은 특정 시점에 하나의 클러스트 노드에서만 사용할 수 있습니다. 이렇게 로컬로 마운트된 파일 시스템은 페일오버 모드 및 페일오버 자원 그룹에서만 사용할 수 있습니다. HAStoragePlus는 이전 전역 파일 시스템(GFS) 또는 클러스터 파일 시스템(CFS)을 지원할 뿐만 아니라 페일오버 파일 시스템(FFS)을 제공합니다.

HAStoragePlus는 이전의 HAStorage에 비해 많은 이점이 있습니다.

HAStoragePlus는 전역 파일 서비스 계층을 완벽하게 통과합니다. 이러한 특징때문에 디스크 액세스 횟수가 많은 데이터 서비스의 경우 성능이 크게 향상됩니다.
HAStoragePlus는 전역 파일 서비스 계층에서 작동하지 않아도 모든 파일 시스템(예: UFS, VxFS 등)에서 작동 가능합니다. Solaris 운영 체제에서 지원하는 파일 시스템의 경우 HAStoragePlus와 함께 작동됩니다.

주 –

데이터 서비스 자원 그룹에서 2002년 5월 이후의 Sun Cluster 3.0 릴리스로 HAStoragePlus 자원을 사용하십시오.

HAStoragePlus에 대한 자세한 내용은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS를 참조하십시오.

6.3 Calendar Server 6.3 소프트웨어를 사용한 비대칭형 고가용성 배포를 위한 고수준 작업 목록

다음은 비대칭형 고가용성 Calendar Server를 설치 및 구성하는 데 필요한 작업 목록입니다.

노드를 준비합니다.
1. 클러스터의 모든 노드에 Solaris 운영 체제 소프트웨어를 설치합니다.
2. 클러스터의 모든 노드에 Sun Cluster 소프트웨어를 설치합니다.
3. Java Enterprise System 설치 프로그램을 사용하여 클러스터의 모든 노드에 Calendar Server HA 에이전트 패키지(SUNWscics)를 설치합니다.
4. 공유 디스크에 파일 시스템을 만듭니다.
5. Communications Suite 5 설치 프로그램을 사용하여 클러스터의 주 노드 및 보조 노드에 Calendar Server를 설치합니다.
Directory Server LDAP 디렉토리가 있는 시스템에서 Directory 준비 스크립트 comm_dssetup.pl을 실행합니다.
첫 번째(주) 노드를 설치 및 구성합니다.
1. Sun Cluster 명령줄 인터페이스를 사용하여 주 노드에 HA를 설정합니다.
2. 주 노드에서 Calendar Server 구성 프로그램(csconfigurator.sh)을 실행합니다.
3. Sun Cluster 명령줄 인터페이스를 사용하여 보조 노드로 전환합니다.
주 노드의 Calendar Server config 디렉토리에서 공유 디스크의 config 디렉토리로 심볼릭 링크를 만듭니다.
두 번째(보조) 노드를 설치 및 구성합니다.
1. 주 노드를 구성할 때 만든 상태 파일을 다시 사용하여 보조 노드에서 Calendar Server 구성 프로그램을 실행합니다.
2. 구성 파일 ics.conf를 편집합니다.
3. Sun Cluster 명령줄 인터페이스를 사용하여 Calendar Server의 자원 그룹을 구성 및 활성화합니다.
4. Sun Cluster 명령줄 인터페이스를 사용하여 자원 그룹이 성공적으로 생성되었는지 테스트하고 주 노드로 페일오버를 수행합니다.

단계별 지침은 6.6 비대칭형 고가용성 환경에 Calendar Server 6.3 소프트웨어 설치 및 구성을 참조하십시오.

6.4 Calendar Server 6.3 소프트웨어를 사용한 대칭형 고가용성 배포를 위한 고수준 작업 목록

다음은 대칭형 고가용성 Calendar Server를 설치 및 구성하는 데 필요한 작업 목록입니다.

노드를 준비합니다.
1. 클러스터의 모든 노드에 Solaris 운영 체제 소프트웨어를 설치합니다.
2. 클러스터의 모든 노드에 Sun Cluster 소프트웨어를 설치합니다.
3. 6개의 파일 시스템을 클러스터 파일 시스템(전역 파일 시스템) 또는 페일오버 파일 시스템(로컬 파일 시스템)으로 만듭니다.
4. 필요한 디렉토리를 만듭니다.
5. Java Enterprise System 설치 프로그램을 사용하여 클러스터의 모든 노드에 Calendar Server HA 에이전트 패키지(SUNWscics)를 설치합니다.
첫 번째 노드를 설치 및 구성합니다.
1. Communications Suite 5 설치 프로그램을 사용하여 클러스터의 첫 번째 노드에 Calendar Server를 설치합니다.
2. Directory Server LDAP 데이터베이스가 있는 시스템에서 Directory 준비 스크립트(comm_dssetup.pl)를 실행합니다.
  
  주 –
  두 노드의 Calendar Server 인스턴스가 동일한 LDAP 서버를 공유하는 경우 두 번째 노드에 Calendar Server 소프트웨어를 설치한 후에는 이 단계를 반복하지 않아도 됩니다.
3. Sun Cluster 명령줄 인터페이스를 사용하여 첫 번째 노드에서 HA를 구성합니다.
4. 첫 번째 노드에서 Calendar Server 구성 프로그램(csconfigurator.sh)을 실행합니다.
5. Sun Cluster 명령줄 인터페이스를 사용하여 두 번째 노드로 페일오버합니다.
6. 첫 번째 노드에서 구성 파일(ics.conf)을 편집합니다.
7. Sun Cluster 명령줄 인터페이스를 사용하여 첫 번째 노드에서 Calendar Server의 자원 그룹을 구성 및 활성화합니다.
8. Sun Cluster 명령줄 인터페이스를 사용하여 첫 번째 노드에 대한 자원 그룹을 만들고 활성화합니다.
9. Sun Cluster 명령줄 인터페이스를 사용하여 자원 그룹이 성공적으로 생성되었는지 테스트하고 첫 번째 노드로 페일오버를 수행합니다.
두 번째 노드를 설치 및 구성합니다.
1. Communications Suite 5 설치 프로그램을 사용하여 클러스터의 두 번째 노드에 Calendar Server를 설치합니다.
2. Sun Cluster 명령줄 인터페이스를 사용하여 두 번째 노드에서 HA를 구성합니다.
3. 첫 번째 노드를 구성할 때 만든 상태 파일을 다시 사용하여 두 번째 노드에서 Calendar Server 구성 프로그램(csconfigurator.sh)을 실행합니다.
4. Sun Cluster 명령줄 인터페이스를 사용하여 첫 번째 노드로 페일오버합니다.
5. 두 번째 노드에서 구성 파일(ics.conf)을 편집합니다.
6. Sun Cluster 명령줄 인터페이스를 사용하여 두 번째 노드에서 Calendar Server의 자원 그룹을 만들고 활성화합니다.
7. Sun Cluster 명령줄 인터페이스를 사용하여 자원 그룹이 성공적으로 생성되었는지 테스트하고 두 번째 노드로 페일오버를 수행합니다.

단계별 지침은 6.7 대칭형 고가용성 Calendar Server 시스템 구성을 참조하십시오.

6.5 Calendar Server 버전 6.3 고가용성 구성을 위한 배포 예제에서 모든 예제에 사용된 명명 규칙

정보 –

이 절을 인쇄하여 HA 설치 및 구성 과정에 사용한 값을 기록해 두십시오.

이 절은 모든 예제에서 사용된 변수 이름을 보여주는 4개의 표로 구성됩니다.

표 6–3 비대칭형 예제에 사용된 디렉토리 이름 변수
표 6–4 대칭형 예제에 사용된 디렉토리 이름 변수
표 6–5 비대칭형 예제에 사용된 자원 이름 변수
표 6–6 대칭형 예제에 사용된 자원 이름 변수
표 6–7 비대칭형 예제에 사용된 IP 주소의 변수 이름
표 6–8 대칭형 예제에 사용된 IP 주소의 변수 이름

표 6–3 비대칭형 예제에 사용된 디렉토리 이름 변수


예제 이름	디렉토리	설명
`install-root`	`/opt`	Calendar Server가 설치된 디렉토리
`cal-svr-base`	`/opt/SUNWics5/cal`	모든 Calendar Server 파일이 들어 있는 디렉토리
`var-cal-dir`	`/var/opt/SUNWics5`	/var 디렉토리
`share-disk-dir`	`/cal`	전역 디렉토리. 즉, 비대칭형 고가용성 시스템에서 노드 간에 공유되는 디렉토리

표 6–4 대칭형 예제에 사용된 디렉토리 이름 변수


예제 이름	디렉토리	설명
`install-rootCS1` `install-rootCS2`	`/opt/Node1` `/opt/Node2`	Calendar Server 인스턴스가 설치된 디렉토리
`cal-svr-baseCS1` `cal-svr-baseCS2`	`/opt/Node1/SUNWics5/cal` `/opt/Node2/SUNWics5/cal`	노드에 대한 모든 Calendar Server 파일이 들어 있는 디렉토리
`var-cal-dirCS1` `var-cal-dirCS2`	`/var/opt/Node1/SUNWics5` `/var/opt/Node2/SUNWics5`	각 노드에 대한 /var 디렉토리
`share-disk-dirCS1` `share-disk-dirCS2`	`/cal/Node1` `/cal/Node2`	각 Calendar Server 인스턴스가 페일오버 노드와 공유하는 전역(공유) 디렉토리. 대칭형 고가용성 시스템에 사용됩니다.

표 6–5 비대칭형 예제의 자원 이름 변수


변수 이름	설명
`CAL-RG`	달력 자원 그룹
`LOG-HOST-RS`	논리적 호스트 이름 자원
`LOG-HOST-RS-Domain.com`	정규화된 논리적 호스트 이름 자원
`CAL-HASP-RS`	HAStoragePlus 자원
`CAL-SVR-RS`	Calendar Server 자원 그룹

표 6–6 대칭형 예제의 자원 이름 변수


변수 이름	설명
`CAL-CS1-RG`	Calendar Server의 첫 번째 인스턴스에 대한 달력 자원 그룹
`CAL-CS2-RG`	Calendar Server의 두 번째 인스턴스에 대한 달력 자원 그룹
`LOG-HOST-CS1-RS`	Calendar Server의 첫 번째 인스턴스에 대한 논리적 호스트 이름 자원
`LOG-HOST-CS1-RS-Domain.com`	Calendar Server의 첫 번째 인스턴스에 대한 정규화된 논리적 호스트 이름 자원
`LOG-HOST-CS2-RS`	Calendar Server의 두 번째 인스턴스에 대한 논리적 호스트 이름 자원
`LOG-HOST-CS2-RS-Domain.com`	Calendar Server의 두 번째 인스턴스에 대한 정규화된 논리적 호스트 이름 자원
`CAL-HASP-CS1-RS`	Calendar Server의 첫 번째 인스턴스에 대한 HAStoragePlus 자원
`CAL-HASP-CS2-RS`	Calendar Server의 두 번째 인스턴스에 대한 HAStoragePlus 자원
`CAL-SVR-CS1-RS`	Calendar Server의 첫 번째 인스턴스에 대한 Calendar Server 자원 그룹
`CAL-SVR-CS2-RS`	Calendar Server의 두 번째 인스턴스에 대한 Calendar Server 자원 그룹

표 6–7 비대칭형 예제에 사용된 IP 주소의 변수 이름


논리적 IP 주소	설명
`IPAddress`	`chsttpd` 데몬이 수신하는 포트의 IP 주소. 표준 IP 형식이어야 합니다. 예: "123.45.67.890"

표 6–8 대칭형 예제에서 사용된 IP 주소의 변수 이름


논리적 IP 주소	설명
`IPAddressCS1`	Calendar Server의 첫 번째 인스턴스에 대해 `chsttpd` 데몬이 수신하는 포트의 IP 주소. 표준 IP 형식이어야 합니다. 예: "123.45.67.890"
`IPAddressCS2`	Calendar Server의 두 번째 인스턴스에 대해 `chsttpd` 데몬이 수신하는 포트의 IP 주소. 표준 IP 형식이어야 합니다. 예: "123.45.67.890"

6.6 비대칭형 고가용성 환경에 Calendar Server 6.3 소프트웨어 설치 및 구성

이 절에서는 비대칭형 고가용성 Calendar Server 클러스터를 구성하는 방법에 대해 설명합니다.

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

6.6.1 Calendar Server 6.3 HA 배포를 위한 파일 시스템 만들기

공유 디스크에 파일 시스템을 만듭니다. /etc/vfstab는 클러스터의 모든 노드에서 동일해야 합니다.

CFS의 경우 다음 예와 유사합니다.

## Cluster File System/Global File System ##
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /cal ufs 2 yes global,logging

예를 들어, FFS의 경우 다음과 같습니다.

## Fail Over File System/Local File System ##
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /cal ufs 2 no logging

주 –

이 명령에서 필드는 공백이 아닌 탭으로 구분됩니다.

6.6.2 Calendar Server 6.3 HA 배포에서 클러스터의 모든 공유 디스크에 달력 디렉토리 만들기

클러스터의 모든 노드에 대해 구성 및 데이터가 저장되는 /Cal 디렉토리를 만듭니다. 예를 들어 각 공유 디스크에 대해 다음 명령을 수행합니다.

mkdir -P /Cal

6.6.3 Calendar Server 6.3 소프트웨어의 고가용성 설치 및 구성

이 절에서는 Calendar Server의 고가용성 설치 및 구성에 포함되는 작업에 대한 지침을 제공합니다.

구성을 완료하려면 다음 각 작업을 차례로 수행합니다.

클러스터의 각 노드를 준비하려면

Communications Suite 5 설치 프로그램을 사용하여 클러스터의 주 노드 및 보조 노드에 Calendar Server를 설치합니다.

주 –
모든 노드에서 동일한 설치 루트를 지정해야 합니다.
1. 설치 디렉토리 지정 패널에서 두 노드에 대한 설치 루트를 지정합니다.
  
  그러면 /install-root/SUNWics5/cal 디렉토리에Calendar Server 바이너리가 설치됩니다. 이 디렉토리를 Calendar Server 기본(cal-svr-base)이라고 합니다.
2. 나중에 구성 옵션을 선택합니다.
3. 설치가 완료되면 해당 파일이 설치되었는지 확인합니다.
```
# pwd
/cal-svr-base

# ls -rlt

total 16
drwxr-xr-x   4 root     bin          512 Dec 14 12:52 share
drwxr-xr-x   3 root     bin          512 Dec 14 12:52 tools
drwxr-xr-x   4 root     bin         2048 Dec 14 12:52 lib
drwxr-xr-x   2 root     bin         1024 Dec 14 12:52 sbin
drwxr-xr-x   8 root     bin          512 Dec 14 12:52 csapi
drwxr-xr-x  11 root     bin         2048 Dec 14 12:52 html
```

기존 Directory Server LDAP에 대해 Directory 준비 스크립트(comm_dssetup.pl)를 실행합니다.

이 스크립트는 새로운 LDAP 스키마, 인덱스 및 구성 데이터를 설정하여 Directory Server를 준비합니다.

comm_dssetup.pl 실행에 대한 자세한 내용은 Sun Java Communications Suite 5 Installation Guide의 8 장, Directory Preparation Tool (comm_dssetup.pl)를 참조하십시오.

주 노드를 설정하려면

첫 번째 노드에서 HA를 설정했을 때처럼 Sun Cluster 명령줄 인터페이스를 사용합니다.

주 –

예제의 디렉토리 이름 및 Sun Cluster 자원 이름에 대한 키로 6.5 Calendar Server 버전 6.3 고가용성 구성을 위한 배포 예제에서 모든 예제에 사용된 명명 규칙 을 참조하십시오.

Calendar Server 및 HAStoragePlus 자원을 등록합니다.

./scrgadm -a -t SUNW.HAStoragePlus
./scrgadm -a -t SUNW.scics

페일오버 Calendar Server 자원 그룹을 만듭니다.

예를 들어 다음 명령은 Node1을 주 노드로, Node2를 보조(또는 페일오버) 노드로 하여 달력 자원 그룹 CAL-RG를 만듭니다.
```
./scrgadm -a -g CAL-RG -h node1,node2
```

Calendar Server 자원 그룹에 논리적 호스트 이름 자원 그룹을 만들고 자원 그룹을 온라인으로 가져옵니다.

예를 들어, 다음 명령은 논리적 호스트 이름 자원 LOG-HOST-RS를 만든 다음 자원 그룹 CAL-RG를 온라인으로 가져옵니다.
```
./scrgadm -a -L -g CAL-RG -l LOG-HOST-RS
./scrgadm -c -j LOG-HOST-RS -y    \
      R_description="LogicalHostname resource for LOG-HOST-RS"
./scswitch -Z -g CAL-RG
```

HAStoragePlus 자원을 만들고 활성화합니다.

예를 들어, 다음 명령은 HAStoragePlus 자원 CAL-HASP-RS를 만들고 활성화합니다.

scrgadm -a -j CAL-HASP-RS -g CAL-RG -t 
     SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/cal
scrgadm -c -j CAL-HASP-RS -y 
     R_description="Failover data service resource for SUNW.HAStoragePlus:4"
scswitch -e -j CAL-HASP-RS

주 노드에서 구성 유틸리티(csconfigurator.sh)를 실행하려면

구성 프로그램을 실행합니다.

예를 들어, /cal-svr-base/sbin 디렉토리에서 다음을 실행합니다.
```
# pwd
     /cal-svr-base/sbin

# ./csconfigurator.sh
```
구성 스크립트 실행에 대한 자세한 내용은 이 설명서의 2 장, Calendar Server 6.3 소프트웨어의 초기 런타임 구성 프로그램(csconfigurator.sh)을 참조하십시오.

런타임 구성 패널에서 두 Calendar Server 시작 옵션을 선택 해제합니다.

디렉토리 패널에서 공유 디스크의 모든 디렉토리를 구성합니다. 다음 위치를 사용합니다.

구성 디렉토리

/share-disk-dir/config

데이터베이스 디렉토리

/share-disk-dir/csdb

첨부 파일 저장 디렉토리

/share-disk-dir/store

로그 디렉토리

/share-disk-dir/logs

임시 파일 디렉토리

/share-disk-dir/tmp

디렉토리를 지정한 후에는 [디렉토리 만들기]를 선택합니다.

아카이브 및 핫 백업 패널에서 다음 선택 항목을 지정합니다.

아카이브 디렉토리

/share-disk-dir/csdb/archive

핫 백업 디렉토리

/share-disk-dir/csdb/hotbackup

디렉토리를 지정한 후에는 [디렉토리 만들기] 옵션을 선택합니다.

구성에 성공했는지 확인합니다.

구성 출력 끝에 “모든 작업이 성공했습니다.” 라는 메시지가 있는지 확인합니다.다음 예는 구성 출력의 마지막 부분을 보여 줍니다.
```
...
모든 작업이 성공했습니다. 자세한 내용은 설치 로그
/var/sadm/install/logs/Sun_Java_System_Calendar_Server_install.B12141351
을(를) 확인하십시오.
```
더 많은 샘플 출력은 6.11 달력 구성 프로그램의 출력 예(일부)를 참조하십시오.

[다음]을 눌러 구성을 완료합니다.

보조 노드를 구성하려면

보조 노드로 전환합니다.

Sun Cluster 명령줄 인터페이스를 사용하여 보조 노드로 전환합니다. 예를 들어, 다음 명령은 자원 그룹을 보조(페일오버) 노드(Node2)로 전환합니다
```
scswitch -z -g CAL-RG -h Node2
```

Calendar Server config 디렉토리에서 공유 파일 시스템의 config 디렉토리로 심볼릭 링크를 만듭니다.

예를 들어, 다음 명령을 수행합니다.
```
# pwd
/cal-svr-base

# ln -s /share-disk-dir/config .  
```
주 –
ln 명령의 끝에 마침표(.)를 잊지 마십시오.

주 노드를 구성한 상태 파일을 사용하여 보조 노드에서 Calendar Server를 구성합니다.

구성 프로그램을 실행했을 때 만든 상태 파일을 실행하여 주 노드의 구성을 공유합니다.

예를 들어, 다음 명령을 실행합니다.
```
# /cal-svr-base/sbin/csconfigurator.sh -nodisplay -noconsole -novalidate
```
모든 작업이 처음 구성 프로그램을 실행했을 때 전달되었는지 확인합니다.

구성 파일(ics.conf)를 편집합니다.

파일 끝에 다음 매개 변수를 추가하여 ics.conf 파일을 편집합니다. 달력 자원의 논리적 호스트 이름은 LOG-HOST-RS입니다.

주 –

이 단계를 수행하기 전에 ics.conf 파일을 백업하십시오.

! 다음은 Calendar Server의 가용성을 높이기 위한 변경
! 사항입니다.
!
local.server.ha.enabled="yes"
local.server.ha.agent="SUNWscics"
service.http.listenaddr="IPAddress"
local.hostname="LOG-HOST-RS"
local.servername="LOG-HOST-RS"
service.ens.host="LOG-HOST-RS"
service.http.calendarhostname="LOG-HOST-RS-Domain.com"
local.autorestart="yes"
service.listenaddr="IPAddress"

Calendar Server 자원 그룹을 만들고 활성화합니다.

이 예에서 자원 그룹 이름은 CAL-SVR-RS입니다. 또한 논리적 호스트 자원 이름 및 HAStoragePlus 자원 이름도 제공해야 합니다.
```
./scrgadm -a -j CAL-SVR-RS -g CAL-RG 
     -t SUNW.scics -x ICS_serverroot=/cal-svr-base 
     -y Resource_dependencies=CAL-HASP-RS,LOG-HOST-RS

./scrgadm -e -j CAL-SVR-RS
```

페일오버를 수행하여 달력 자원 그룹이 성공적으로 생성되었는지 테스트합니다.
```
./ scswitch -z -g CAL-RG -h Node1
```
이 단계를 끝마치면 Calendar Server에 대한 비대칭형 고가용성 시스템 생성 및 구성을 완료한 것입니다. 다음 절에서는 디버그 용도로 Sun Cluster에서 로깅을 설정하는 방법에 대해 설명합니다.

이제 비대칭형 Calendar Server HA 시스템의 설치 및 구성을 완료했습니다.

6.7 대칭형 고가용성 Calendar Server 시스템 구성

이 절에서는 대칭형 고가용성 Calendar Server 시스템을 구성하는 방법에 대해 설명합니다.

대칭형 고가용성 Calendar Server 시스템을 구성하려면 다음 절의 지침을 따릅니다.

6.7.1 초기 작업

해당 노드에 Calendar Server를 설치하기 전에 완료해야 하는 두 가지의 준비 작업이 있습니다.

준비 작업은 다음과 같습니다.

주 –

예제의 다양한 위치에서 각 노드에 대한 설치 디렉토리(cal-svr-base)를 제공해야 합니다. 대칭형 HA 시스템의 경우 cal-svr-base는 비대칭형 HA 시스템과 다릅니다. 대칭형 HA 시스템에서 cal-svr-base의 형식은 /opt/node/SUNWics5/cal입니다. 여기서 /opt/node는 Calendar Server가 설치된 루트 디렉토리(install-root)의 이름입니다.

예제에 사용할 용도로, 그리고 두 Calendar Server 인스턴스의 설치 디렉토리를 구분하기 위해 cal-svr-baseCS1 및 cal-svr-baseCS2로 지정했습니다.

이 예에서는 두 Calendar Server 인스턴스의 설치 루트를 구분하기 위해 install-rootCS1 및 install-rootCS2로 지정했습니다.

파일 시스템 만들기

클러스터 파일 시스템(전역 파일 시스템) 또는 페일오버 파일 시스템(로컬 파일 시스템)을 사용하여 6개의 파일 시스템을 만듭니다.

다음은 전역 파일 시스템의 예이며 /etc/vfstab 파일의 내용은 다음과 같습니다. 필드는 모두 탭으로 구분되어 있습니다.

# Cluster File System/Global File System ##
/dev/md/penguin/dsk/d500  /dev/md/penguin/rdsk/d500  
    /cal-svr-baseCS1  ufs  2  yes  logging,global
/dev/md/penguin/dsk/d400  /dev/md/penguin/rdsk/d400  
    /share-disk-dirCS1  ufs  2  yes  logging,global
/dev/md/polarbear/dsk/d200  /dev/md/polarbear/rdsk/d200  
    /cal-svr-baseCS2  ufs  2  yes  logging,global
/dev/md/polarbear/dsk/d300  /dev/md/polarbear/rdsk/d300
    /share-disk-dirCS2  ufs  2  yes logging,global
/dev/md/polarbear/dsk/d600  /dev/md/polarbear/rdsk/d300 
    /var-cal-dirCS1  ufs  2   yes  logging,global
/dev/md/polarbear/dsk/d700  /dev/md/polarbear/rdsk/d300  
    /var-cal-dirCS2  ufs   2   yes  logging,global

다음은 페일오버 파일 시스템의 예이며 /etc/vfstab 파일의 내용은 다음과 같습니다. 필드는 모두 탭으로 구분되어 있습니다.

# Failover File System/Local File System ##
/dev/md/penguin/dsk/d500  /dev/md/penguin/rdsk/d500  
    /cal-svr-baseCS1  ufs  2  yes  logging
/dev/md/penguin/dsk/d400  /dev/md/penguin/rdsk/d400  
    /share-disk-dirCS1  ufs  2  yes  logging
/dev/md/polarbear/dsk/d200  /dev/md/polarbear/rdsk/d200 
   /cal-svr-baseCS2  ufs  2  yes  logging
/dev/md/polarbear/dsk/d300  /dev/md/polarbear/rdsk/d300 
    /share-disk-dirCS2  ufs  2  yes  logging
/dev/md/polarbear/dsk/d600  /dev/md/polarbear/rdsk/d300 
    /var-cal-dirCS1  ufs  2   yes  logging
/dev/md/polarbear/dsk/d700  /dev/md/polarbear/rdsk/d300
   /var-cal-dirCS2  ufs  2   yes  logging

클러스터의 모든 노드에서 다음 필수 디렉토리를 만듭니다.

# mkdir -p /install-rootCS1 share-disk-dirCS1 
     install-rootCS2 share-disk-dirCS2 var-cal-dirCS1 
     var-cal-dirCS2

6.7.1.1 Calendar Server HA 패키지 설치

클러스터의 모든 노드에 Calendar Server HA 패키지(SUNWscics)를 설치합니다.

Java Enterprise System 설치 프로그램을 사용하여 설치해야 합니다.

Java Enterprise System 설치 프로그램에 대한 자세한 내용은 Sun Java Enterprise System 5 Installation and Configuration Guide를 참조하십시오.

6.7.2 Calendar Server의 첫 번째 인스턴스 설치 및 구성

이 절의 지침에 따라 Calendar Server의 첫 번째 인스턴스를 설치 및 구성합니다. 이 절은 다음 내용으로 구성되어 있습니다.

Calendar Server를 설치하려면

파일이 마운트되었는지 확인합니다.

주 노드(Node1)에서 다음 명령을 입력합니다.

df -k

다음은 표시되는 출력의 예입니다.

/dev/md/penguin/dsk/d500     35020572   
     34738 34635629   1%   /install-rootCS1
/dev/md/penguin/dsk/d400     35020572   
     34738 34635629   1%   /share-disk-dirCS1
/dev/md/polarbear/dsk/d300   35020572   
     34738 34635629   1%   /share-disk-dirCS2
/dev/md/polarbear/dsk/d200   35020572   
     34738 34635629   1%   /install-rootCS2
/dev/md/polarbear/dsk/d600   35020572   
     34738 34635629   1%   /var-cal-dirCS1
/dev/md/polarbear/dsk/d700   35020572   
     34738 34635629   1%   /var-cal-dirCS2

Sun Java Systems Communications Suite 설치 프로그램을 사용하여 주 노드에서 Calendar Server를 설치합니다.
1. 설치 디렉토리 지정 패널에서 설치 루트(install-rootCS1)를 지정합니다.
  
  예를 들어, 주 노드의 이름이 red이고 루트 디렉토리가 dawn이면 설치 루트는 /dawn/red가 됩니다. 이 디렉토리는 첫 번째 노드에서 Calendar Server를 설치하는 디렉토리입니다.
2. [나중에 구성]을 선택합니다.

Directory Server가 있는 시스템에서 Directory 준비 도구 스크립트를 실행합니다.

첫 번째 노드에서 Sun Cluster를 구성하려면

Sun Cluster 명령줄 인터페이스로 다음 단계를 수행하여 첫 번째 노드에서 Sun Cluster를 구성합니다.

다음 자원 유형을 등록합니다.

./scrgadm -a -t SUNW.HAStoragePlus
./scrgadm -a -t SUNW.scics

페일오버 자원 그룹을 만듭니다.

다음 예에서 자원 그룹은 CAL-CS1-RG이고 두 노드의 이름은 Node1(주 노드) 및 Node2(페일오버 노드)입니다.
```
./scrgadm -a -g CAL-CS1-RG -h Node1,Node2
```

이 노드의 논리적 호스트 이름 자원을 만듭니다.

달력 클라이언트가 이 논리적 호스트 이름에서 수신합니다. 다음 예에서는 실제 호스트 이름을 대체할 위치에 LOG-HOST-CS1-RS를 사용합니다.
```
./scrgadm -a -L -g CAL-RG -l LOG-HOST-CS1-RS
./scrgadm -c -j LOG-HOST-CS1-RS -y R_description=
     "LogicalHostname resource for LOG-HOST-CS1-RS"
```

자원 그룹을 온라인 상태로 만듭니다.
```
scswitch -Z -g CAL-CS1-RG
```

HAStoragePlus 자원을 만들고 페일오버 자원 그룹에 추가합니다.

이 예에서 자원은 CAL-HASP-CS1-RS이며사용자의 자원 이름으로 대체할 수 있습니다. 이 설명서에서는 보기 쉽도록 이 예의 한 줄을 두 줄로 표시습니다.
```
./scrgadm -a -j CAL-HASP-CS1-RS -g CAL-CS1-RG -t 
     SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/install-rootCS1,
     /share-disk-dirCS1,/cal-svr-baseCS1
./scrgadm -c -j CAL-HASP-CS1-RS -y R_description="Failover data 
     service resource for SUNW.HAStoragePlus:4"
```

HAStoragePlus 자원을 활성화합니다.
```
./scswitch -e -j CAL-HASP-CS1-RS
```

Calendar Server의 첫 번째 인스턴스를 구성하려면

주 노드에서 구성 프로그램을 실행합니다.
```
# cd /cal-svr-baseCS1/sbin/

# ./csconfigurator.sh
```
구성 스크립트 실행에 대한 자세한 내용은 Sun Java System Calendar Server 6.3 관리 설명서를 참조하십시오.

런타임 구성 패널에서 두 Calendar Server 시작 옵션을 선택 해제합니다.

구성 및 데이터 파일을 저장할 디렉토리 패널에서 다음 목록에 표시된 것처럼 공유 디스크 디렉토리를 제공합니다.

구성 디렉토리

/share-disk-dirCS1/config

데이터베이스 디렉토리

/share-disk-dirCS1/csdb

첨부 파일 저장 디렉토리

/share-disk-dirCS1/store

로그 디렉토리

/share-disk-dirCS1/logs

임시 파일 디렉토리

/share-disk-dirCS1/tmp

디렉토리를 지정한 후에는 [디렉토리 만들기]를 선택합니다.

아카이브 및 핫 백업 패널에서 다음 목록에 표시된 것처럼 공유 디스크 디렉토리 이름을 제공합니다.

아카이브 디렉토리

/share-disk-dirCS1/csdb/archive

핫 백업 디렉토리

/share-disk-dirCS1/csdb/hotbackup

이러한 디렉토리를 지정한 후 [디렉토리 만들기]를 선택합니다.

구성에 성공했는지 확인합니다.

구성 프로그램에서 일련의 메시지가 표시됩니다. 메시지가 모두 PASSED로 시작되는 경우 구성에 성공한 것입니다. 표시되는 출력 예는 6.11 달력 구성 프로그램의 출력 예(일부)를 확인하십시오.

첫 번째 인스턴스의 최종 구성 단계를 수행하려면

Sun Cluster 명령줄 인터페이스를 사용하여 두 번째 노드로 페일오버를 수행합니다.

예를 들면 다음과 같습니다.
```
# /usr/cluster/bin/scswitch -z -g CAL-CS1-RG -h Node2
```

다음 예에 나와 있는 대로 매개 변수를 추가하여 구성 파일 ics.conf를 편집합니다.

주 –

이 단계를 시작하기 전에 ics.conf 파일을 백업하십시오.

! 다음은 Calendar Server의 고가용성을 구성하기 위한 변경
! 사항입니다.
!
local.server.ha.enabled="yes"
local.server.ha.agent="SUNWscics"
service.http.listenaddr="IPAddressCS1"
local.hostname="LOG-HOST-CS1-RS"
local.servername="LOG-HOST-CS1-RS"
service.ens.host="LOG-HOST-CS1-RS"
service.http.calendarhostname="LOG-HOST-CS1-RS-Domain.com"
local.autorestart="yes"
service.listenaddr = "IPAddressCS1"

주 –

service.http.calendarhostname의 값은 정규화된 호스트 이름이어야 합니다.

Sun Cluster 명령줄 인터페이스를 사용하여 Calendar Server 자원 그룹을 만듭니다.

달력 자원 그룹을 만들고 활성화합니다.

예를 들면 다음과 같습니다.

./scrgadm -a -j CAL-SVR-CS1-RS -g CAL-CS1-RG
      -t SUNW.scics  -x ICS_serverroot=/cal-svr-baseCS1
      -y Resource_dependencies=CAL-HASP-CS1-RS,LOG-HOST-CS1-RS

./scrgadm -e -j CAL-SVR-CS1-RS

Sun Cluster 명령줄 인터페이스를 사용하여 Calendar Server 자원 그룹이 성공적으로 생성되었는지 확인하고 주 노드인 첫 번째 노드로 페일오버를 수행합니다.

예를 들면 다음과 같습니다.
```
./scswitch -z -g CAL-CS1-RG -h Node1
```

6.7.3 Calendar Server의 두 번째 인스턴스 설치 및 구성

두 번째 Calendar Server 인스턴스의 주 노드는 보조 노드(Node2)입니다.

보조 노드에 Calendar Server를 설치하려면

파일이 마운트되었는지 확인합니다.

주 노드(Node2)에서 다음 명령을 입력합니다.

df -k

다음은 표시되는 출력의 예입니다.

/dev/md/penguin/dsk/d500     35020572   
     34738 34635629   1%   /install-rootCS1
/dev/md/penguin/dsk/d400     35020572   
     34738 34635629   1%   /share-disk-dirCS1
/dev/md/polarbear/dsk/d300   35020572   
     34738 34635629   1%   /share-disk-dirCS2
/dev/md/polarbear/dsk/d200   35020572   
     34738 34635629   1%   /install-rootCS2
/dev/md/polarbear/dsk/d600   35020572   
     34738 34635629   1%   /var-cal-dirCS1
/dev/md/polarbear/dsk/d700   35020572   
     34738 34635629   1%   /var-cal-dirCS2

Sun Java Systems Communications Suite 설치 프로그램을 사용하여 새로운 주 노드(보조 노드)에서 Calendar Server를 설치합니다.
1. 설치 디렉토리 지정 패널에서 보조 노드의 설치 루트(/install-rootNode2)를 지정합니다.
  
  예를 들어, Node 2 시스템의 이름이 blue이고 루트 디렉토리가 ocean이면 설치 디렉토리는 /ocean/blue가 됩니다.
2. [나중에 구성] 옵션을 선택합니다.

두 번째 인스턴스에 대해 Sun Cluster를 구성하려면

Sun Cluster 명령줄 인터페이스를 사용하여 다음 단계에 설명된 대로 Calendar Server의 두 번째 인스턴스를 구성합니다.

페일오버 자원 그룹을 만듭니다.

다음 예에서 자원 그룹은 CAL-CS2-RG이고 두 노드의 이름은 Node2(주 노드) 및 Node1(페일오버 노드)입니다.
```
./scrgadm -a -g CAL-CS2-RG -h Node2,Node1
```

논리적 호스트 이름 자원을 만듭니다.

달력 클라이언트가 이 논리적 호스트 이름에서 수신합니다. 다음 예에서는 실제 호스트 이름을 대체할 위치에 LOG-HOST-CS2-RS를 사용합니다.
```
./scrgadm -a -L -g CAL-CS2-RG -l LOG-HOST-CS2-RS
./scrgadm -c -j LOG-HOST-CS2-RS -y R_description="LogicalHostname 
     resource for LOG-HOST-CS2-RS"
```

자원 그룹을 온라인 상태로 만듭니다.
```
scswitch -Z -g CAL-CS2-RG
```

HAStoragePlus 자원을 만들고 페일오버 자원 그룹에 추가합니다.

이 예에서 자원은 CAL-SVR-CS2-RS이며사용자의 자원 이름으로 대체할 수 있습니다.

./scrgadm -a -j CAL-SVR-CS2-RS -g CAL-CS2-RG -t 
     SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/install-rootCS2,
     /share-disk-dirCS2,/var-cal-dirCS2
./scrgadm -c -j CAL-HASP-CS2-RS -y R_description="Failover data 
     service resource for SUNW.HAStoragePlus:4"

HAStoragePlus 자원을 활성화합니다.
```
./scswitch -e -j CAL-HASP-CS2-RS
```

Calendar Server의 두 번째 인스턴스를 구성하려면

보조 노드에서 구성 프로그램을 다시 실행합니다.
```
# cd /cal-svr-baseCS2/sbin/

# ./csconfigurator.sh
```
구성 스크립트 실행에 대한 자세한 내용은 Sun Java System Calendar Server 6.3 관리 설명서를 참조하십시오.

런타임 구성 패널에서 두 Calendar Server 시작 옵션을 선택 해제합니다.

구성 및 데이터 파일을 저장할 디렉토리 패널에서 다음 목록에 나와 있는 것처럼 적절한 디렉토리를 제공합니다.

구성 디렉토리

share-disk-dirCS2/config

데이터베이스 디렉토리

/share-disk-dirCS2/csdb

첨부 파일 저장 디렉토리

/share-disk-dirCS2/store

로그 디렉토리

/share-disk-dirCS2/logs

임시 파일 디렉토리

/share-disk-dirCS2/tmp

디렉토리를 지정한 후에는 [디렉토리 만들기]를 선택합니다.

아카이브 및 핫 백업 패널에서 다음 목록에 나와 있는 것처럼 적절한 디렉토리 이름을 제공합니다.

아카이브 디렉토리

/share-disk-dirCS2/csdb/archive

핫 백업 디렉토리

/share-disk-dirCS2/csdb/hotbackup

이러한 디렉토리를 지정한 후 [디렉토리 만들기]를 선택합니다.

구성에 성공했는지 확인합니다.

구성 프로그램에서 일련의 메시지가 표시됩니다. 메시지가 모두 PASSED로 시작되는 경우 구성에 성공한 것입니다. 표시되는 출력 예는 6.11 달력 구성 프로그램의 출력 예(일부)를 확인하십시오.

두 번째 인스턴스의 최종 구성 단계를 수행하려면

Sun Cluster 명령줄 인터페이스를 사용하여 첫 번째 노드로 페일오버를 수행합니다.

예를 들면 다음과 같습니다.
```
# /usr/cluster/bin/scswitch -z -g CAL-CS2-RG -h Node1
```

다음 예에 나와 있는 대로 매개 변수를 추가하여 구성 파일 ics.conf를 편집합니다.

주 –

표시된 값은 예로 든 것입니다. 이 예에 사용된 값을 사용자 자신의 정보로 대체해야 합니다.

이 단계를 시작하기 전에 ics.conf 파일을 백업하십시오.

! 다음은 Calendar Server의 고가용성 구성을 위한 변경
! 사항입니다.
!
local.server.ha.enabled="yes"
local.server.ha.agent="SUNWscics"
service.http.listenaddr="IPAddressCS2"
local.hostname="LOG-HOST-CS2-RS"
local.servername="LOG-HOST-CS2-RS"
service.ens.host="LOG-HOST-CS2-RS"
service.http.calendarhostname="LOG-HOST-CS2-RS-Domain.com"
local.autorestart="yes"
service.listenaddr = "IPAddressCS2"

주 –

service.http.calendarhostname의 값은 정규화된 호스트 이름이어야 합니다.

Sun Cluster 명령줄 인터페이스를 사용하여 Calendar Server 자원 그룹을 만듭니다.

Calendar Server 자원 그룹을 만들고 활성화합니다.

예를 들면 다음과 같습니다.
```
./scrgadm -a -j CAL-SVR-CS2-RS -g CAL-CS2-RG
      -t SUNW.scics -x ICS_serverroot=/cal-svr-baseCS2
      -y Resource_dependencies=CAL-HASP-CS2-RS,LOG-HOST-CS2-RS

./scrgadm -e -j CAL-SVR-CS2-RS
```

Sun Cluster 명령줄 인터페이스를 사용하여 달력 자원 그룹이 성공적으로 생성되었는지 확인하고 이 Calendar Server 인스턴스의 주 노드인 두 번째 노드로 페일오버를 수행합니다.

예를 들면 다음과 같습니다.
```
./scswitch -z -g CAL-CS2-RG -h Node2
```
이제 대칭형 HA Calendar Server의 설치 및 구성을 완료했습니다.

6.8 Calendar Server HA 서비스 시작 및 중지

다음 명령을 사용하여 Calendar Server HA 서비스를 시작, 페일오버, 비활성화, 제거 및 다시 시작할 수 있습니다.

Calendar Server HA 서비스를 활성화하고 시작하려면

# scswitch -e -j CAL-SVR-RS

Calendar Server HA 서비스를 페일오버하려면

# scswitch -z -g CAL-RG -h Node2

Calendar Server HA 서비스를 비활성화하려면

# scswitch -n -j CAL-SVR-RS

Calendar Server 자원을 제거하려면

# scrgadm -r -j CAL-SVR-RS

Calendar Server HA 서비스를 다시 시작하려면

# scrgadm -R -j CAL-SVR-RS

6.9 Calendar Server 구성에서 HA 제거

이 절에서는 Sun Cluster에 대한 HA 구성을 실행 취소하는 방법을 설명하며이 장에서 설명한 간단한 비대칭형 예제 구성을 사용합니다. 이 시나리오를 사용자의 설치 환경에 맞게 활용해야 합니다.

HA 구성 요소를 제거하려면

수퍼유저가 됩니다.

주 –
다음 Sun Cluster 명령을 실행하려면 수퍼유저로 실행 중이어야 합니다.

자원 그룹을 오프라인 상태로 만듭니다. 다음 명령을 사용하여 자원 그룹의 모든 자원을 종료합니다(예: Calendar Server 및 HA 논리적 호스트 이름).
# scswitch -F -g CAL-RG

개별 자원을 비활성화합니다.

다음 명령을 사용하여 자원 그룹에서 자원을 하나씩 제거합니다.
# scswitch -n -j CAL-SVR-RS # scswitch -n -j CAL-HASP-RS # scswitch -n -j LOG-HOST-RS

다음 명령을 사용하여 자원 그룹을 제거합니다.
# scrgadm -r -g CAL-RG

자원 유형을 제거합니다(선택 사항). 클러스터에서 자원 유형을 제거하려면 다음 명령을 사용합니다.
# scrgadm -r -t SUNW.scics # scrgadm -r -t SUNW.HAStorage

6.10 Sun Cluster 디버깅

Calendar Server Sun Cluster 에이전트는 두 가지의 서로 다른 API를 사용하여 메시지를 기록합니다.

scds_syslog_debug() — Calendar Server 에이전트에서 사용합니다. 메시지는 daemon.debug 수준으로 기록됩니다.
scds_syslog() — Calendar Server 에이전트 및 Sun Cluster 데이터 서비스에서 사용합니다. 메시지는 daemon.notice, daemon.info 및 daemon.error 수준으로 기록됩니다.

로깅을 활성화하려면

/var/adm 파일을 공유할 수 없으므로 각 HA 노드에서 다음 작업을 수행해야 합니다. 이 파일은 각 노드의 루트 파티션에 있습니다.

Calendar Server 에이전트의 로깅 디렉토리를 만듭니다.
```
mkdir -p /var/cluster/rgm/rt/SUNW.scics
```

디버그 수준을 9로 설정합니다.

echo 9 >/var/cluster/rgm/rt/SUNW.scics/loglevel

다음 예는 디렉토리에서 확인할 수 있는 로그 메시지를 보여 줍니다. 마지막 행에서 ICS-serverroot는 cal-svr-base 또는 설치 디렉토리를 확인하는 것입니다.

Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,cal-rs,ics_svc_start]: 
     [ID 831728 daemon.debug] Groupname icsgroup exists.
Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]: 
     [ID 383726 daemon.debug] Username icsuser icsgroup
Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]: 
     [ID 244341 daemon.debug] ICS_serverroot = /cal-svr-base

Sun Cluster 데이터 서비스 로깅을 활성화합니다.

다음 행을 추가하여 syslog.conf 파일을 편집합니다.
```
daemon.debug /var/adm/clusterlog
```
이 명령은 모든 디버그 메시지를 daemon.debug /var/adm/clusterlog 파일에 기록합니다.

syslogd 데몬을 다시 시작합니다.

pkill -HUP syslogd

다음 메시지 앞에 모든 syslog 디버그 메시지가 표시됩니다.

SC[resourceTypeName, resourceGroupName, resourceName, methodName]

다음 예제 메시지는 보기 쉽도록 여러 행으로 나눈 것입니다.

Dec 11 15:55:52 Node1 SC
      [SUNW.scics,CAL-RG,CalendarResource,ics_svc_validate]:
      [ID 855581 daemon.error] Failed to get the configuration info
Dec 11 18:24:46 Node1 SC
      [SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]:
      [ID 833212 daemon.info] Attempting to start the data service under 
      process monitor facility.

6.11 달력 구성 프로그램의 출력 예(일부)

이 절에서는 구성 프로그램의 출력 내용을 부분적으로 설명합니다. 실제 출력 내용은 훨씬 깁니다. 끝에 “모든 작업이 성공했습니다.” 라는 메시지가 있는지 확인합니다. 로그 파일을 확인하십시오. 파일 위치는 출력의 끝에 지정됩니다.

/usr/jdk/entsys-j2se/bin/java -cp /opt/Node2/SUNWics5/cal/share/lib:
     /opt/Node2/SUNWics5/cal/share -Djava.library.path=
     /opt/Node2/SUNWics5/cal/lib configure -nodisplay -noconsole -novalidate
# ./csconfigurator.sh -nodisplay -noconsole -novalidate
/usr/jdk/entsys-j2se/bin/java -cp /opt/Node2/SUNWics5/cal/share/lib:
     /opt/Node2/SUNWics5/cal/share -Djava.library.path=
     /opt/Node2/SUNWics5/cal/lib configure -nodisplay -noconsole -novalidate
GNOME용 Java Accessibility Bridge가 로드되었습니다.

기본 등록 정보 로드 중...

디스크 공간 확인 중...

작업 시퀀스 시작
===== Mon Dec 18 15:33:29 PST 2006 =====
Running /bin/rm -f /opt/Node2/SUNWics5/cal/config
/opt/Node2/SUNWics5/cal/data

===== Mon Dec 18 15:33:29 PST 2006 =====
Running /usr/sbin/groupadd icsgroup

===== Mon Dec 18 15:33:29 PST 2006 =====
Running /usr/sbin/useradd -g icsgroup -d / icsuser

===== Mon Dec 18 15:33:30 PST 2006 =====
Running /usr/sbin/usermod -G icsgroup icsuser

===== Mon Dec 18 15:33:30 PST 2006 =====
Running /bin/sh -c /usr/bin/crle


===== Mon Dec 18 15:33:32 PST 2006 =====
Running /bin/chown icsuser:icsgroup /etc/opt/Node2/SUNWics5/config/watcher.
cnf


...

시퀀스 완료됨

PASSED: /bin/rm -f /opt/Node2/SUNWics5/cal/config
/opt/Node2/SUNWics5/cal/data : status = 0

PASSED: /usr/sbin/groupadd icsgroup : status = 9

PASSED: /usr/sbin/useradd -g icsgroup -d / icsuser : status = 9


...

모든 작업이 성공했습니다. 자세한 내용은 설치 로그
/var/sadm/install/logs/Sun_Java_System_Calendar_Server_install.B12181533을(를) 확인하십시오.

6.12 관련 문서

Sun Cluster에 대한 자세한 내용은 docs. sun.com의 여러 문서에 나와 있습니다.

다음은 문서 제목 중 일부입니다.

Solaris OS용 Sun Cluster 개념 안내서에서는 Sun Cluster 소프트웨어, 데이터 서비스 및 용어 자원 유형, 자원 및 자원 그룹에 대한 일반적인 배경 정보를 제공합니다.
Sun Cluster Data Services Planning and Administration Guide for Solaris OS에서는 데이터 서비스 계획 및 관리에 대한 일반 정보를 제공합니다.
Solaris OS용 Sun Cluster 시스템 관리 설명서에서는 Sun Cluster 구성을 관리하는 소프트웨어 절차를 제공합니다.
Sun Cluster Reference Manual for Solaris OS에서는 SUNWscman 및 SUNWccon 패키지에만 있는 명령을 포함하여 Sun Cluster 소프트웨어에서 사용 가능한 명령 및 유틸리티에 대해 설명합니다.

7장 SSL 구성

SSL(Secure Socket Layer)은 SSL 기능을 사용하여 클라이언트와 서버 간 보안 연결을 통해 데이터를 암호화 및 해독하기 위한 프로토콜입니다. 서버는 디지털 인증서 및 암호화를 위한 공개 키를 클라이언트로 전송하는 역할을 합니다. 클라이언트가 서버의 인증서를 신뢰하는 경우 SSL 연결을 설정할 수 있습니다. 한 쪽에서 다른 쪽으로 전달되는 모든 데이터는 암호화됩니다. 클라이언트와 서버는 데이터를 해독할 수만 있습니다.

Sun Java System 서버는 디지털 인증서 검사를 통해 사용자 인증을 지원합니다. 클라이언트는 서버와의 SSL 세션을 설정할 때 비밀번호 대신 사용자 인증서를 사용합니다. 인증서가 검증되면 사용자가 인증됩니다. Calendar Server는 달력 클라이언트 최종 사용자와 Calendar Server 간의 데이터 암호화를 위해 SSL 프로토콜을 지원합니다. SSL을 지원하기 위해 Calendar Server는 NSS(Netscape Security Services) certutil 도구의 SSL 라이브러리를 사용하는데, Sun Java System Messaging Server에서도 이 라이브러리를 사용합니다. NSS certutil 도구는 Calendar Server 제품의 sbin 디렉토리에 번들로 제공됩니다.

Calendar Server 로그인 및 비밀번호만 암호화하거나 전체 달력 세션을 암호화하도록 ics.conf 파일에서 Calendar Server를 구성할 수 있습니다.

이 장에서는 SSL을 구성하는 데 필요한 세 가지 단계와 문제 해결 방법을 소개합니다.

주 –

Calendar Server는 클라이언트 기반 SSL 인증을 지원하지 않습니다.

7.1 Calendar Server에 대해 SSL 구성

이 절에서는 Calendar Server에 대해 SSL을 구성하기 위한 지침을 제공합니다.

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

인증서 데이터베이스를 만들려면

게이트웨이에서는 자신의 공개 키를 클라이언트로 전송하기 위해 인증서를 필요로 합니다. 인증서에는 게이트웨이의 공개 키, 게이트웨이의 인증서와 연결된 고유 이름, 일련 번호 또는 인증서 발급 날짜 및 만료 날짜가 포함됩니다. 인증서는 게이트웨이의 Identity를 검증하는 인증 기관(CA)에서 발급합니다. CA는 한 명 이상의 사용자가 신뢰하는 기관으로, X.509 공개 키 인증서 및 CARL 또는 CRL(Certification Revocation List)을 발행 및 관리합니다. CA는 PKI(공개 키 인프라)의 기본 빌딩 블록입니다. 한편, PKI는 공개 키 인증서의 발행, 유지 관리 및 해지 기능을 포함하여 인증서 및 공개-개인 키 쌍을 관리할 목적으로 사용되는 정책, 프로세스, 서버 플랫폼, 소프트웨어 및 워크스테이션 집합이기도 합니다.

CA는 자신의 이름을 모든 인증서 및 생성한 CRL에 삽입하고 개인 키를 사용하여 인증서를 디지털 서명합니다. 직접 또는 인증 경로를 통해 CA에 대한 신뢰가 구축되면 CA에서 발행한 인증서를 신뢰할 수 있습니다. 이름을 비교하여 CA에서 발행한 인증서를 쉽게 파악할 수 있습니다. 그러나 공개 키는 해당 인증서가 유효한지 확인하는 데만 사용할 수 있습니다.

CA는 다음 4가지의 기본적인 PKI 기능을 수행합니다.

인증서를 발행(생성 및 서명)합니다.
인증서 상태 정보를 유지 관리하고 CRL을 발행합니다.
현재 만료되지 않은 인증서 및 CRL을 게시합니다.
만료된 인증서에 대한 상태 정보 아카이브를 유지 관리합니다.

사용자 서버의 인증서 및 키 쌍은 사용자 서버의 Identity를 나타내며서버 내부 또는 외부의 이동식 하드웨어 카드(스마트카드)에 보관할 수 있는 인증서 데이터베이스에 저장됩니다. Calendar Server를 위해 SSL을 구현하려면 인증서 데이터베이스가 필요합니다. 인증서 데이터베이스는 인증 기관(CA) 및 Calendar Server용 인증서를 정의해야 합니다. 이 절에서는 개념 및 작업 정보를 제공합니다.

시작하기 전에

인증서 데이터베이스를 만들기 전에 다음에 익숙해져야 합니다.

Mozilla 도구

이 릴리스에는 다음 Mozilla 도구가 포함되어 있습니다.
- 인증서 데이터베이스를 만들고 관리하는 인증서 데이터베이스 도구(certutil). 자세한 내용은 다음 웹 사이트를 참조하십시오.
  
  http://mozilla.org/projects/security/pki/nss/tools/certutil.html
  
  정보 –
  인증서 데이터베이스를 생성하기 전에 도구 구문을 잘 알고 있어야 합니다.
- 사용 가능한 보안 모듈에 대한 정보를 표시하는 보안 모듈 데이터베이스 도구(modutil). 자세한 내용은 다음 웹 사이트를 참조하십시오.
  
  http://mozilla.org/projects/security/pki/nss/tools/modutil.html
  
  이 유틸리티는 다음 디렉토리에서 사용할 수 있습니다.
  
  /opt/SUNWics5/cal/lib
  
  또는 웹 사이트에서 최신 버전을 다운로드할 수 있습니다.
라이브러리 경로 변수

Mozilla 도구를 사용하기 전에 LD_LIBRARY_PATH 변수를 적절하게 설정합니다. 예를 들면 다음과 같습니다.
```
setenv LD_LIBRARY_PATH /opt/SUNWics5/cal/lib
```
예제 파일 및 디렉토리

이 장의 예에서는 다음 파일 및 디렉토리를 사용합니다.
- /etc/opt/SUNWics5/config는 인증서 데이터베이스가 있는 디렉토리입니다.
  
  정기적으로 인증서 데이터베이스를 백업하십시오. 다른 디렉토리에 인증서 데이터베이스를 만들도록 선택할 수도 있습니다. 다른 디렉토리에 만들 경우 인증서 비밀번호 파일도 같은 디렉토리에 보관해야 합니다.
- sslpassword.conf는 인증서 데이터베이스 비밀번호를 포함하는 텍스트 파일입니다.
  
  이 파일은 Calendar Server가 아니라 certutil 유틸리티가 사용합니다. 다음 디렉토리에sslpassword.conf를 만듭니다.
  
  /etc/opt/SUNWics5/config
- /etc/passwd에 있는 파일에서는 난수 생성을 위한 엔트로피를 만듭니다. 즉, 이 디렉토리는 난수 생성기에서 실제로 무작위한 결과를 얻을 수 있도록 도와주는 다양하고 고유한 시드를 생성하는 데 사용됩니다.

수퍼유저(root)로 로그인합니다.

/etc/opt/SUNWics5/config/sslpassword.conf에서 인증서 데이터베이스 비밀번호를 지정합니다.

예를 들면 다음과 같습니다.
# echo "password file entry" /etc/opt/SUNWics5/config/sslpassword.conf
비밀번호 파일 항목의 형식은 다음과 같습니다.

Internal (Software) Token: password

인증서 데이터베이스 디렉토리를 만듭니다. 예를 들면 다음과 같습니다.
# cd /var/opt/SUNWics5 # mkdir alias

bin 디렉토리로 변경하고 인증서 데이터베이스(cert8.db)와 키 데이터베이스(key3.db)를 만듭니다. 예를 들면 다음과 같습니다.
# cd /opt/SUNWics5/cal/bin # ./certutil -N -d /etc/opt/SUNWics5/config -f /etc/opt/SUNWics5/config/sslpassword.conf
주 –
certutil 유틸리티를 실행해야 하는 경우에는 다음 예를 정확하게 따르거나 certutil 도움말 페이지를 참조하여 구문을 이해해야 합니다.

예를 들어, 이 경우에는 -d / 파일 정보를 함께 지정하지 않고는 -N 옵션과 함께 유틸리티를 실행하지 마십시오.

자체 서명된 기본 루트 인증 기관 인증서를 생성합니다. 예를 들면 다음과 같습니다.

# ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
 -s "CN=My Sample Root CA, O=sesta.com" -m 25000
 -o /etc/opt/SUNWics5/config/SampleRootCA.crt
 -d /etc/opt/SUNWics5/config
 -f /etc/opt/SUNWics5/config/sslpassword.conf -z
 /etc/passwd

호스트를 위한 인증서를 생성합니다. 예를 들면 다음과 같습니다.

# ./certutil -S -n SampleSSLServerCert -c SampleRootCA 
 -t "u,u,u"
 -s "CN=hostname.sesta.com, O=sesta.com" -m 25001
 -o /etc/opt/SUNWics5/config/SampleSSLServer.crt
 -d /etc/opt/SUNWics5/config 
 -f /etc/opt/SUNWics5/config/sslpassword.conf
 -z /etc/passwd

여기서 hostname.sesta.com은 서버 호스트 이름입니다.

인증서를 검증합니다. 예를 들면 다음과 같습니다.

# ./certutil -V -u V -n SampleRootCA  
    -d /etc/opt/SUNWics5/config
 # ./certutil -V -u V -n SampleSSLServerCert 
   -d /etc/opt/SUNWics5/config

인증서를 나열합니다. 예를 들면 다음과 같습니다.

# ./certutil -L -d /etc/opt/SUNWics5/config
 # ./certutil -L -n SampleSSLServerCert 
   -d /etc/opt/SUNWics5/config

modutil을 사용하여 사용 가능한 보안 모듈을 나열합니다(secmod.db). 예를 들면 다음과 같습니다.
# ./modutil -list -dbdir /etc/opt/SUNWics5/config

별칭 파일의 소유자를 icsuser 및 icsgroup(또는 Calendar Server를 실행할 사용자 및 그룹 아이디)으로 변경합니다. 예를 들면 다음과 같습니다.
# find /etc/opt/SUNWics5/config -exec chown icsuser {}; # find /etc/opt/SUNWics5/config -exec chgrp icsgroup {};

7.1.1 자체 서명된 인증서

자체 서명된 인증서는 게이트웨이의 자체 개인 키를 사용하여 서명되는 인증서를 말합니다. 자체 서명된 인증서는 안전하지 않지만 실제 서명된 인증서를 사용하기 전, 인증서가 필요한 응용 프로그램을 테스트하는 데 사용할 수 있습니다. 자체 서명된 인증서는 CA의 서명이 아닌 자체 인증서 요청을 서명으로 사용합니다.

PKI를 통해 자체 서명된 인증서를 만드는 경우 10개의 공통 필드가 있는데, 이 중 6개는 필수이고 4개는 선택 필드입니다. 일련 번호, 인증서 서명 알고리즘 식별자, 인증서 발행자 이름, 인증서 유효 기간, 공개 키 및 주체 이름은 필수 필드입니다. 선택 필드는 버전 번호, 2개의 고유 식별자 및 확장자입니다. 이러한 선택 필드는 버전 2 및 3 인증서에만 나타납니다.

필수 유효 기간 필드는 인증서가 유효하게 되는 날짜와 만료되는 날짜를 나타냅니다. NSS certutils에서 제공하는 기본 만료 날짜는 3개월입니다. 그러나 인증서의 유효 기간 데이터는 만료 날짜에 도달하기 전에 신뢰할 수 없게 됩니다. X.509 CRL 메커니즘은 인증서 만료 날짜에 주의할 수 있도록 발행한 인증서의 상태 업데이트를 제공합니다. 또한 CA는 인증서 만료를 1-2년으로 강제 적용합니다.

인증서가 만료되거나 유효 날짜가 지나면 인증서를 갱신해야 합니다. 갱신은 새 인증서를 발행하여 공개 키 인증서로 논리 검사된 데이터 바인딩의 유효성을 연장하는 작업 또는 프로세스입니다. 다음 명령을 사용하여 인증서의 유효성을 검사할 수 있습니다.

-V -n certname -b validity-time -u certusage [-e] [-l] [-d certdir]

다음 예는 인증서의 유효성을 검사하는 명령의 사용 방법을 보여 줍니다.

certutil -V -n jsmith@netscape.com -b 9803201212Z -u SR -e -l -d certdir.

인증서 데이터베이스 도구에서 다음과 유사한 결과가 표시됩니다.

Certificate:'jsmith@netscape.com' is valid.

또는

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Expired certificate

또는

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Certificate not approved for this operation

루트 인증 기관에 인증서 요청 및 가져오기

다음 단계에서는 인증서 요청을 생성하고 이를 PKI(Public Key Infrastructure)웹 사이트에 제출하고 나서 해당 인증서를 가져오는 방법을 설명합니다. 여기서는 인증서 데이터베이스를 config 디렉토리에 저장했다고 가정합니다.

시작하기 전에

인증서 데이터베이스와 비밀번호 파일은 같은 디렉토리에 있어야 합니다. 여기서 표시되는 기본값은 config 디렉토리이지만 다른 경로 매개 변수를 구성해야 하는 경우 다음 절차에 나와 있는 대로 다른 디렉토리를 선택할 수 있습니다.

수퍼유저(root)로 로그인합니다.

bin 디렉토리로 이동합니다.

# cd /opt/SUNWics5/cal/bin

certutil을 사용하여 인증 기관이나 PKI(Public Key Infrastructure) 웹 사이트를 기반으로 인증서 요청을 만듭니다. 예를 들면 다음과 같습니다.

# ./certutil -R -s "CN=hostname.sesta.com, 
OU=hostname/ SSL Web Server, O=Sesta, 
C=US" -p "408-555-1234" -o hostnameCert.req 
-g 1024  -d /etc/opt/SUNWics5/config 
-f /etc/opt/SUNWics5/config/sslpassword.conf  -z /etc/passwd -a

여기서 “hostname.sesta.com”은 호스트 이름입니다.

인증 기관이나 PKI(Public Key Infrastructure) 웹 사이트에 SSL 웹 서버에 대한 테스트 인증서를 요청합니다. hostnameCert.req 파일의 내용을 복사하여 인증서 요청에 붙여넣습니다.

인증서가 서명되어 찾아갈 수 있게 되면 관리자에게 알립니다.

인증 기관 인증서 체인 및 SSL 서버 인증을 텍스트 파일로 복사합니다.

CA 인증서 체인을 인증서 데이터베이스로 가져와서 인증 체인을 설정합니다. 예를 들면 다음과 같습니다.

# ./certutil -A -n "GTE CyberTrust Root"
    -t "TCu,TCu,TCuw" 
    -d /etc/opt/SUNWics5/config 
    -a 
    -i /export/wspace/Certificates/CA_Certificate_1.txt
    -f /etc/opt/SUNWics5/config/sslpassword.conf
# ./certutil -A -n "Sesta TEST Root CA" 
    -t "TCu,TCu,TCuw" 
    -d /etc/opt/SUNWics5/config 
    -a 
    -i /export/wspace/Certificates/CA_Certificate_2.txt
    -f /etc/opt/SUNWics5/config/sslpassword.conf

서명된 SSL 서버 인증서를 가져옵니다.

# ./certutil -A -n "hostname SSL Server Test Cert"
    -t "u,u,u" -d /etc/opt/SUNWics5/config 
    -a 
    -i /export/wspace/Certificates/SSL_Server_Certificate.txt
    -f /etc/opt/SUNWics5/config/sslpassword.conf

인증서 데이터베이스의 인증서를 나열합니다.

# ./certutil -L -d /etc/opt/SUNWics5/config

ics.conf 파일의 SSL Server 별명이 서명된 SSL 서버 인증서가 되도록 구성합니다. 예: “hostname SSL Server Test Cert”.

주 ics.conf 파일에 있는 service.http.calendarhostname 및 service.http.ssl.sourceurl 매개 변수의 호스트 이름이 SSL 인증서의 호스트 이름과 일치해야 합니다(시스템에 별명이 여러 개 있는 경우). 예를 들면 다음과 같습니다. calendar.sesta.com

`ics.conf` 파일의 SSL 매개 변수를 구성하려면

Calendar Server에 SSL을 구현하려면 ics.conf 파일에서 특정 매개 변수를 설정해야 합니다. 다음 표에 나열된 매개 변수 중에서 ics.conf 파일에 없는 변수가 있는 경우에는 파일에 해당 변수를 추가하고 값을 지정합니다. ics.conf는 시스템을 시작할 때(start-cal을 시작할 때)에만 읽히기 때문에 Calendar Server를 다시 시작할 때까지 새 값이 적용되지 않습니다. SSL 매개 변수에 대한 자세한 내용은 E.2.10 Calendar Server SSL 구성 매개 변수를 참조하십시오.

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

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

이전 ics.conf 파일을 복사한 다음 이름을 변경하여 저장합니다.

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

매개 변수	값
`encryption.rsa.nssslactivation`	`"on"`
`encryption.rsa.nssslpersonalityssl`	`"SampleSSLServerCert"`
`encryption.rsa.nsssltoken`	`"internal"`
`service.http.tmpdir`	`"/var/opt/SUNWics5/tmp"`
`service.http.uidir.path`	`"html"`
`service.http.ssl.cachedir`	`"."`
`service.http.ssl.cachesize`	`"10000"`
`local.ssldbpath`	`"/etc/opt/SUNWics5/config"`
`service.http.ssl.port.enable`	`"yes"`
`service.http.ssl.port`	`"443"`(기본 SSL 포트) 주 – HTTP 기본 포트인 포트 `"80"`은 아닙니다.
`service.http.securesession`	`"yes"`(전체 세션 암호화)
`service.http.ssl.sourceurl`	`"https://localhost:port"`(로컬 호스트의 이름과 `service.http.ssl.port` 값 입력)로 시작해야 합니다.
`service.http.ssl.ssl3.ciphers`	`"rsa_red_40_md5,` `rsa_rc2_40_md5,` `rsa_des_sha,` `rsa_rc4_128_md5,` `rsa_3des_sha"`
`service.http.ssl.ssl3.sessiontimeout`	`"0"`
`service.http.sslusessl`	`"yes"`

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

변경 내용을 적용하려면 Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

7.2 Calendar Server 6.3 소프트웨어의 SSL 문제 해결

우선 복구 불가능한 문제가 발생할 경우를 대비하여 정기적으로 인증서 데이터베이스를 백업합니다. 이 절에서는 데이터베이스를 백업한 후 고려해야 할 사항에 대해 설명합니다.

SSL에 문제가 있을 경우 다음 내용을 확인하십시오. 7.2.1 cshttpd 프로세스 점검
7.2.2 인증서 검증
7.2.3 Calendar Server 로그 파일 검토
7.2.4 SSL 포트에 연결
7.2.5 cshttpd가 일반 HTTP 포트를 수신하지 못하게 만들기

7.2.1 `cshttpd` 프로세스 점검

SSL을 사용하려면 Calendar Server cshttpd 프로세스가 실행 중이어야 합니다. cshttpd가 실행 중인지 확인하려면 다음 명령을 사용합니다.

# ps -ef | grep cshttpd

7.2.2 인증서 검증

인증서 데이터베이스의 인증서를 나열하고 해당 유효 일자를 확인하려면 다음 명령을 사용합니다.

# ./certutil -L -d /etc/opt/SUNWics5/config

7.2.3 Calendar Server 로그 파일 검토

Calendar Server 로그 파일에 SSL 오류가 있는지 확인합니다.

7.2.4 SSL 포트에 연결

브라우저와 다음 URL을 사용하여 SSL 포트에 연결합니다.

https:// server-name:ssl-port-number

여기서,

server-name은 Calendar Server가 실행 중인 서버 이름입니다.

ssl-port-number는 ics.conf 파일의 service.http.ssl.port 매개 변수가 지정하는 SSL 포트 번호입니다. 기본값은 443입니다.

7.2.5 cshttpd가 일반 HTTP 포트를 수신하지 못하게 만들기

HTTP 및 HTTPS는 다른 포트를 수신합니다(SSL의 경우 443, HTTP의 경우 80). 따라서 둘 다 동일한 포트를 수신하게 할 수 없습니다. 현재 cshttpd가 일반 HTTP 포트를 수신하지 못하게 할 방법은 없습니다. 그러나 관리자는 service.http.port를 미공개 번호로 변경할 수 있습니다.

주의 –

cshttpd가 HTTP를 수신하지 못하게 하려면 service.http.enable ="no"로 설정하지 마십시오. 이렇게 하면 HTTPS도 실패합니다. SSL이 제대로 구성되도록 하려면 service.http.enable과 service.http.ssl.port.enable을 모두 "yes"로 설정해야 합니다.

8장 Calendar Server 6.3 시스템에서 단일 사인온 구성

이 장에서는 단일 사인 온(SSO)을 구성하는 방법을 설명합니다.

단일 사인온에서는 사용자가 한 번만 인증하면 다시 인증할 필요 없이 신뢰할 수 있는 여러 응용 프로그램을 사용할 수 있습니다.

Calendar Server와 Messaging Server를 비롯한 Sun Java System 통신 서버는 다음과 같이 SSO를 구현할 수 있습니다.

8.1 Access Manager를 통한 SSO 구성

Calendar Server와 Messaging Server를 포함하는 Sun Java Enterprise System 서버에서는 Sun Java System Access Manager(릴리스 6 2003Q4) 이상)를 사용하여 SSO를 구현할 수 있습니다.

Access Manager는 Sun Java Enterprise System 서버를 위한 SSO 게이트웨이 역할을 합니다. 즉 서버에 SSO가 제대로 구성된 경우 Access Manager에 로그인한 사용자는 다른 Sun Java Enterprise System 서버에 액세스할 수 있습니다.

Calendar Server에서 SSO를 사용하려면

Access Manager와 Directory Server가 설치 및 구성되어 있는지 확인합니다. 이러한 제품의 설치 및 구성에 대한 자세한 내용은 Sun Java Enterprise System 5 Installation Guide for UNIX를 참조하십시오.

Calendar Server 서비스를 중지한 후 8.1 Access Manager를 통한 SSO 구성에 나와 있는 매개 변수를 설정하여 Calendar Server에서 SSO를 구성합니다. 값을 적용하려면 Calendar Server 서비스를 다시 시작해야 합니다.

주 –
local.calendar.sso.amnamingurl 매개 변수를 설정하는 경우 Access Manager 소프트웨어가 설치된 호스트의 정규화된 이름을 사용해야 합니다.

Messaging Server에서 SSO를 구성하려면 Sun Java System Messaging Server 6.3 Administration Guide를 참조하십시오.

사용자는 Directory Server LDAP 사용자 아이디 및 비밀번호를 사용하여 Access Manager에 로그인합니다. Calendar Server나 Messaging Server와 같은 다른 서버를 통해 로그인하는 사용자는 SSO를 사용하여 다른 Sun Java Enterprise System 서버에 액세스할 수 없습니다.

로그인한 사용자는 적합한 URL을 사용하여 Communications Express를 통해 Calendar Server에 액세스할 수 있습니다. 또한 서버에 SSO가 제대로 구성되었다면 Messaging Server와 같은 다른 Communications Suite 서버에도 액세스할 수 있습니다.

매개 변수	설명
`local.calendar.sso.amnamingurl`	Access Manager SSO 이름 지정 서비스의 URL을 지정합니다. 기본값은 다음과 같습니다. `http://AccessManager:port/amserver/namingservice` 여기서 `AccessManager`는 Access Manager의 정규화된 이름이며 `port`는 Access Manager 포트 번호입니다.
`local.calendar.sso.amcookiename`	Access Manager SSO 쿠키의 이름을 지정합니다. 기본값은 `"iPlanetDirectoryPro"`입니다.
`local.calendar.sso.amloglevel`	Access Manager SSO의 로그 수준을 지정합니다. 범위는 1(무음)부터 5(세부 정보 표시)입니다. 기본값은 “3”입니다.
`local.calendar.sso.logname`	Access Manager SSO API 로그 파일의 이름을 지정합니다. 기본값은 다음과 같습니다. `am_sso.log`
`local.calendar.sso.singlesignoff`	Calendar Server에서 Access Manager로의 단일 사인 온을 사용 가능(“yes”) 또는 사용 불가능(“no”)하게 합니다. 사용 가능한 경우, Calendar Server에서 로그아웃한 사용자는 Access Manager에서도 로그아웃되며 Access Manager를 통해 시작했던 다른 모든 세션(Messaging Server webmail 세션 등)도 종료합니다. Access Manager는 인증 게이트웨이이므로 SSO(단일 사인 온)는 항상 Access Manager에서 Calendar Server로 활성화됩니다. 기본값은 “yes”입니다.

정보 –

ics.conf 파일을 변경하는 가장 좋은 방법은 매개 변수와 새 값을 파일 끝에 추가하는 것입니다. 그러면 시스템에서 전체 파일을 읽고 마지막으로 발견한 매개 변수 값을 사용합니다.

8.1.1 Access Manager에서 단일 사인온 사용 시 고려 사항

이 절에서는 Access Manager에서 단일 사인온 사용 시 고려해야 할 몇 가지 사항에 대해 설명합니다.

고려 사항은 다음과 같습니다.

Access Manager 세션이 유효한 경우에만 달력 세션이 유효합니다. 사용자가 Access Manager에서 로그아웃하면 달력 세션은 자동으로 종료됩니다(단일 사인 오프).
SSO 응용 프로그램은 동일한 도메인에 있어야 합니다.
SSO 응용 프로그램은 Access Manager 인증 URL(이름 지정 서비스)에 액세스할 수 있어야 합니다.
브라우저는 쿠키를 지원해야 합니다.
Sun Java System Portal Server 게이트웨이를 사용하는 경우 다음 Calendar Server 매개 변수를 설정합니다.
- service.http.ipsecurity="no"
- render.xslonclient.enable="no"

8.1.2 통신 서버 Trusted Circle 기술을 통한 SSO 구성

Communications Servers Trusted Circle 기술을 통해(즉 Access Manager를 거치지 않고) SSO를 구성할 경우 다음 사항을 고려합니다.

신뢰할 수 있는 각 응용 프로그램은 SSO가 구성되어야 합니다.
default.html 페이지가 브라우저의 캐시에 있는 경우 SSO가 제대로 실행되지 않습니다. SSO를 사용하기 전에 반드시 브라우저에 default.html 페이지를 다시 로드하십시오. 예를 들어, Netscape Navigator에서는 Shift 키를 누른 채로 Reload를 누릅니다.
SSO는 기본 URL에 대해서만 실행됩니다. 예를 들어 다음과 같습니다. http://servername .

다음 표에서는 통신 서버 Trusted Circle 기술을 사용하는 SSO를 위한 Calendar Server 구성 매개 변수를 설명합니다.

표 8–1 통신 서버 Trusted Circle 기술을 사용하는 Calendar Server SSO 매개 변수


매개 변수	설명
`sso.enable`	SSO를 사용 가능하게 하려면 이 매개 변수를 기본값인 "1"로 설정해야 합니다. "0"이면 SSO를 사용할 수 없습니다.
`sso.appid`	이 매개 변수는 특정 Calendar Server 설치의 고유 응용 프로그램 아이디를 지정합니다. 신뢰할 수 있는 각 응용 프로그램도 고유 응용 프로그램 아이디가 있어야 합니다. 기본값은 다음과 같습니다. `"ics50"`
`sso.appprefix`	이 매개 변수는 SSO 쿠키 형식 지정에 사용될 접두어 값을 지정합니다. 신뢰할 수 있는 모든 응용 프로그램에서 동일한 값을 사용해야 합니다. Calendar Server는 이 접두어를 갖는 SSO 쿠키만 인식하기 때문입니다. 기본값은 다음과 같습니다. `"ssogrp1"`
`sso.cookiedomain`	이 매개 변수는 브라우저가 특정 도메인의 서버로만 쿠키를 보내게 합니다. 이 값은 반드시 마침표(.)로 시작해야 합니다.
`sso.singlesignoff`	`“true”`(기본값)를 지정하면 클라이언트가 로그아웃할 때 `sso.appprefix`에 구성된 값과 접두어 값이 일치하는 클라이언트에 있는 모든 SSO 쿠키를 지웁니다.
`sso.userdomain`	이 매개 변수는 사용자 SSO 인증의 일부로 도메인을 설정합니다.
sso.`appid`.url = "`verifyurl`"	이 매개 변수는 Calendar Server 구성에서 피어 SSO 호스트에 대한 확인 URL 값을 설정합니다. 신뢰할 수 있는 각각의 피어 SSO 호스트에 대해 하나의 매개 변수가 필요합니다. 이 매개 변수는 다음 항목으로 구성됩니다. 응용 프로그램 아이디(`appid`)는 SSO 쿠키가 받아들여지는 각각의 피어 SSO 호스트를 식별합니다. URL 확인(`verifyurl`)에는 호스트 URL, 호스트 포트 번호 및 `VerifySSO?`(끝부분의 물음표(`?`) 포함)가 포함됩니다. 이 예에서 Calendar Server 응용 프로그램 아이디는 `ics50`이고, 호스트 URL은 `sesta.com`이며 포트는 `8883`입니다. Messenger Express 응용 프로그램 아이디는 `msg50`이고, 호스트 URL은 `sesta.com`이며 포트는 `8882`입니다. 예를 들면 다음과 같습니다. sso.ics50.url= "http://sesta.com:8883 /VerifySSO?" sso.msg50.url= "http://sesta.com:8882 /VerifySSO?"

다음 표에서는 통신 서버 Trusted Circle 기술을 사용하는 SSO를 위한 Messaging Server 구성 매개 변수를 설명합니다.

표 8–2 통신 서버 Trusted Circle 기술을 사용하는 Calendar Server SSO 매개 변수


매개 변수	설명
`local.webmail.sso.enable`	SSO를 사용하려면 이 매개 변수가 0이 아닌 값으로 설정되어야 합 니다.
`local.webmail.sso.prefix`	이 매개 변수는 HTTP 서버가 설정하는 SSO 쿠키의 형식 지정에 사용할 접두어를 지정합니다. 예를 들면 다음과 같습니다. `ssogrp1`
`local.webmail.sso.id`	이 매개 변수는 Messaging Server에 대해 고유한 응용 프로그램 아이디(예: `msg50`)를 지정합니다. 신뢰할 수 있는 각 응용 프로그램도 고유 응용 프로그램 아이디가 있어야 합니다.
`local.webmail.sso.cookiedomain`	이 매개 변수는 HTTP 서버가 설정하는 모든 SSO 쿠키의 쿠키 도메인 값을 지정합니다.
`local.webmail.sso.singlesignoff`	값이 0이 아니면 클라이언트가 로그아웃할 때 해당 클라이언트 중 `local.webmail.sso.prefix`에 구성된 값과 일치하는 접두어 값을 가진 모든 SSO 쿠키가 지워집니다.
`local.sso.appid.url=` `verifyurl`	이 매개 변수는 Messaging Server 구성에서 피어 SSO 호스트의 확인 URL 값을 설정합니다. 신뢰할 수 있는 각각의 피어 SSO 호스트에 대해 하나의 매개 변수가 필요합니다. 이 매개 변수는 다음 항목으로 구성됩니다. 응용 프로그램 아이디(`appid`)는 SSO 쿠키가 받아들여지는 각각의 피어 SSO 호스트를 식별합니다. URL 확인(`verifyurl`)에는 호스트 URL, 호스트 포트 번호 및 `VerifySSO?`(끝의 물음표( `?`) 포함)가 포함됩니다. 예를 들면 다음과 같습니다. `local.sso.ics50.verifyurl=` `http://sesta.com:8883/VerifySSO?` 이 예에서 Calendar Server 응용 프로그램 아이디는 `ics50`이고, 호스트 URL은 `sesta.com`이며 포트는 `8883`입니다. `local.sso.msg50.verifyurl=` `http://sesta.com:8882/VerifySSO?` 이 예에서 Messaging Server 응용 프로그램 아이디는 `msg50`이고, 호스트 URL은 `sesta.com`이며 포트는 `8882`입니다.

Messaging Server에 대해 SSO를 구성하는 방법에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Guide를 참조하십시오.

9장 자동 백업 구성

csconfigurator.sh 구성 프로그램 실행 시, 자동 백업인 핫 백업 및 아카이브 백업 유형을 모두 구성할 수 있습니다. 이때 자동 백업을 구성하도록 선택하지 않았더라도 다음에 언제든지 하나 또는 두 가지 자동 백업을 구성하도록 선택할 수 있습니다. 백업 시스템은 사용자의 데이터를 보호하고 작업 중단 시간을 최소화해야 합니다.

이 장에서는 자동 백업을 구성하는 방법과 다음 주제에 대한 정보를 설명합니다.

주 –

여기서 설명하는 자동 백업 프로세스를 사용하지 않도록 선택할 경우 사용자 백업 전략을 구현하여 데이터를 보호해야 합니다. 데이터 보호를 위해 다른 Calendar Server 도구를 사용하는 방법에 대한 자세한 내용은 17 장, Calendar Server 데이터 백업 및 복원을 참조하십시오.

csstored의 개요를 보려면 Sun Java Communications Suite 5 Deployment Planning Guide를 참조하십시오.

9.1 Calendar Server 저장소 서비스(csstored) 활성화

제대로 구성된 시스템은 달력 데이터베이스의 자동 백업을 생성합니다. csconfigurator.sh 구성 프로그램이 실행될 때 Calendar Server에서 자동 백업을 구성하거나 나중에 이 장의 절차를 따라 구성하면 됩니다.

자동 백업을 구성할 때 시스템은 다음을 수행합니다.

시스템 시작 시 그리고 그 후에는 24시간 간격(기본 간격)으로 라이브 Calendar Server 달력 데이터베이스의 스냅샷을 만듭니다. 간격은 구성 가능합니다. 시스템이 정지되고 다시 시작된 경우, 마지막 스냅샷 이후 구성된 간격이 경과하지 않는 한 다른 스냅샷을 만들지 않습니다.
백업 복사본에 대해 csdb verify를 실행하여 데이터베이스를 검증합니다.

검증 단계가 실패할 경우(데이터베이스 손상) 시스템은 관리자에게 알립니다. 관리자는 라이브 데이터베이스를 읽기 전용 모드로 설정하여 데이터베이스를 종료하지 않고서도 문제를 해결할 수 있게 합니다. 읽기 전용 모드에서는 수정 또는 삭제 트랜잭션이 승인되지 않습니다(로깅 없음). 읽기 전용 모드에 대한 자세한 내용은 22.5.4 데이터베이스가 손상된 경우 서비스 중단 방지(읽기 전용 모드)를 참조하십시오.

손상이 감지되면 관리자 작업이 필요합니다. 관리자에게 알림이 전송됩니다.

검증이 성공하면 시스템은 다음 추가 작업을 수행합니다.
- 아카이브 백업이 구성된 경우, 데이터베이스 스냅샷 및 이전 스냅샷 이후 여기에 적용된 모든 트랜잭션 로그 파일로 구성된 아카이브 백업이 생성됩니다.
- 핫 백업이 구성된 경우, 데이터베이스 스냅샷 및 여기에 적용된 트랜잭션 로그 파일로 구성된 핫 백업이 생성됩니다.
  
  라이브 데이터베이스가 손상된 경우 핫 백업은 데이터 손실 및 다운 타임을 최소화하면서 최신 버전의 데이터베이스 백업을 제공합니다.
  
  자동 백업 복사본을 복원하는 방법에 대한 자세한 내용은 22.5.8 자동 백업 복사본 복원을 참조하십시오.

9.2 Calendar Server 6.3 시스템의 자동 백업 개요

이 절에서는 Calendar Server 시스템에서 자동 백업을 구현하는 방법에 대해 설명합니다.

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

9.2.1 Calendar Server 6.3 시스템에서 자동 백업 작동 방법

Calendar Server 시스템은 달력 데이터베이스의 각 트랜잭션(달력 및 달력 등록 정보의 추가, 수정 또는 삭제)을 트랜잭션 로그 파일에 기록합니다. 미리 정의된 시간 간격을 두고 쓰기를 위해 로그 파일을 닫고 다른 로그 파일을 만듭니다. 그런 다음 시간이 허락될 때 가장 오래된 닫힌 트랜잭션 로그의 트랜잭션을 라이브 달력 데이터베이스에 적용합니다. 로그의 모든 트랜잭션이 데이터베이스에 적용되면 해당 로그가 “이미 적용됨”으로 표시됩니다.

핫 백업이 구성될 경우 라이브 데이터베이스 스냅샷이 24시간마다 만들어집니다. 그런 다음 이미 적용된 로그가 데이터베이스의 핫 백업 복사본에 적용됩니다. 핫 백업 데이터베이스는 트랜잭션 적용을 위해 계속 대기하면서 현재 상태로 유지됩니다.

주 –

자동 백업이 사용 불가능할 경우 순환 로깅 ics.conf 매개 변수인 caldb.berkeley.circularlogging을 "yes"로 설정해야 합니다. 그렇게 하면 이전 데이터베이스 트랜잭션 로그가 삭제되어 디스크 공간을 절약할 수 있습니다.

9.2.2 Calendar Server 6.3 시스템에서 순환 백업 작동 방법

자동 백업을 사용 가능하게 설정한 경우 시스템은 순환 백업 시스템을 사용하여 백업 데이터베이스 파일에 저장되는 백업 복사본의 수를 자동으로 관리합니다.

시스템은 허용된 최대 수의 백업 복사본이 누적되거나 허용된 최대 디스크 공간에 도달할 때까지 백업 데이터베이스 디렉토리에 백업을 저장합니다. 이때 시스템은 사용 중인 디스크 공간 용량이 디스크 공간 임계값 미만으로 유지되는 한 남아있는 복사본 수가 유지할 최소 복사본 수와 일치할 때까지 오래된 백업 복사본부터 제거를 시작합니다. 최소 복사본 수가 유지된 상태에서 디스크 공간 임계값이 초과하면 시스템은 임계값이 충족될 때까지 복사본을 추가로 제거합니다.

순환 백업을 제어하는 ics.conf 매개 변수 클러스터가 있으며 이러한 매개 변수는 기본값을 가지며 별도로 사용자 정의할 필요가 없습니다. 백업 작동 방법을 조정하려면 21.7 자동 백업 조정을 참조하십시오.

9.2.3 자동 백업을 활성화하기 위한 고급 단계

구성 파일을 실행할 때 자동 백업을 구성하지 않은 경우 나중에 설정할 수 있습니다. 이 절에는 구성 프로그램이 이미 실행된 후 Calendar Server 6.3시스템을 위한 자동 백업을 활성화하는 고급 단계가 목록으로 정리되어 있습니다.

다음은 고급 단계 작업 목록입니다.

9.3 Calendar Server 6.3 백업용 트랜잭션 로그 파일 설정

이 절에서는 트랜잭션 로그 파일을 설정하기 위한 개요와 지침을 제공합니다.

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

9.3.1 Calendar Server 6.3 백업용 트랜잭션 로그 파일의 이해

트랜잭션 로그 파일은 Calendar Server에서 최신 스냅샷 이후에 달력 데이터베이스에 수행된 모든 추가, 수정 및 삭제 작업을 캡처하는 데 사용됩니다. 트랜잭션은 쓰기를 위해 로그 파일이 닫힌 이후에 라이브 데이터베이스에 실제로 적용됩니다. 간격 매개 변수는 이전 로그 파일이 닫히고 새 로그 파일이 생성되는 빈도를 지정합니다.

로그 파일 이름은 구성 가능한 이름과 그 끝에 추가되는 고유한 번호로 구성됩니다.

로그 파일이 닫히면 해당 로그 파일이 라이브 데이터베이스에 적용될 수 있습니다. 이러한 과정은 비동기적으로 발생합니다. 즉, 로그 파일 생성과 트랜잭션 기록이 “실시간”으로 수행됩니다. 데이터베이스에 트랜잭션을 적용하는 프로그램은 로그 파일에 대한 트랜잭션 쓰기와 관계 없이 독립적으로 실행되고 있습니다. 시스템의 사용량이 많을 경우 데이터베이스에 적용하기 위해 대기 중인 로그 파일의 수가 늘어날 수 있습니다. 시스템의 사용량이 적어지면 프로그램이 밀려 있던 트랜잭션 적용을 마무리하여 유휴 상태로 다음 트랜잭션 로그를 대기할 수 있습니다.

트랜잭션은 라이브 데이터베이스에 적용된 후 핫 백업 스냅샷(사용 가능한 경우)에 적용됩니다. 또한 로그 파일이 스냅샷과 같은 아카이브 디렉토리에 작성됩니다.

트랜잭션 로그 파일 설정

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

cd /etc/opt/SUNWics5/config

트랜잭션 로그 이름을 지정합니다.

logfile.store.logname=storename.log

트랜잭션 로그 디렉토리에 대한 디렉토리 경로를 지정합니다.

기본값은 다음과 같습니다. logfile.logdir="logs"

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

9.4 Calendar Server 관리자의 전자 메일 주소 지정

이 절에서는 Calendar Server 관리자의 전자 메일 주소를 설정하기 위한 개요와 지침을 제공합니다.

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

9.4.1 관리자에게 보내는 전자 메일 메시지

특정 이벤트나 오류가 발생하면 전자 메일로 관리자에게 알립니다.

다음은 전자 메일 메시지를 생성하는 이벤트입니다.

자동 백업이 사용 가능하지 않거나 제대로 구성되지 않았습니다.

24시간 단위로 스냅샷을 생성할 때 자동 백업이 사용 불가능한 경우 csstored 프로세스는 자동 백업이 제대로 구성되어 있지 않다고 보고합니다.
디스크 공간 임계값이 초과되었습니다.

이 메시지는 해당 조건이 제거될 때까지 주기적으로 보내집니다.
서비스가 중지되었으며 다시 시작할 수 없습니다.

이 알림 전자 메일은 서비스를 시작하기 전에 수행해야 하는 필수 작업에 대해 설명합니다.

Calendar Server 6.3 시스템 관리자의 전자 메일 주소를 설정하려면

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

stop-cal 명령을 실행하여 Calendar Server 서비스를 중지합니다.

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

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

ics.conf 매개 변수를 편집하여 관리자의 전자 메일 주소를 지정합니다.

alarm.msgalarmnoticercpt="admin@email_address "

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

Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

9.5 Calendar Server 6.3 데이터베이스용 핫 백업 사용

이 절에서는 구성 프로그램을 실행할 때 핫 백업을 구성하지 않은 경우 Calendar Server 6.3 데이터베이스용 핫 백업을 사용하도록 설정하기 위한 개요와 지침을 제공합니다.

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

9.5.1 Calendar Server 버전 6.3의 핫 백업이란

이론상 핫 백업은 최신 스냅샷과 최신 스냅샷에 적용된 모든 트랜잭션 로그로 구성되며 현재 기록 중인 트랜잭션 로그는 제외됩니다. 시스템의 사용량에 따라 트랜잭션 로그 적용이 지연될 수 있습니다. 따라서 데이터베이스나 핫 백업에 적용되지 않은 상태로 남아 있는 로그 파일이 존재할 수 있습니다.

이 라이브 데이터베이스 중복은 재난 상황이 발생하거나 데이터베이스 손상이 감지될 때 중지 시간과 데이터 손실을 최소화하기 위한 것입니다.

새 핫 백업은 새 스냅샷이 생성되는 매 24시간마다 시작됩니다. 이전 핫 백업을 확인한 후 제거될 때까지 유지합니다. 자세한 내용은 9.2.2 Calendar Server 6.3 시스템에서 순환 백업 작동 방법을 참조하십시오.

Calendar Server 6.3 시스템에서 핫 백업을 사용하려면

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

stop-cal 명령을 실행하여 Calendar Server 서비스를 중지합니다.

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

cd /etc/opt/SUNWics5/config

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

caldb.berkeleydb.hotbackup.enable="yes"

핫 백업 디렉토리의 디렉토리 경로를 지정합니다.
```
caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory
```
Calendar Server의 기본 핫 백업 디렉토리는 Solaris의 경우 /var/opt/SUNWics5/csdb이고 Linux의 경우 /var/opt/sun/calendar/csdb입니다. Communications Suite 설치 프로그램은 기본적으로 미리 지정되어 있는 csdb 디렉토리에 아카이브 및 핫 백업 디렉토리를 저장합니다.

주 –
크기에 문제가 있으므로 아카이브 및 핫 백업을 csdb 디렉토리와는 다른 디스크, 볼륨 또는 파티션에 저장하는 것이 좋습니다.

아카이브 및 핫 백업 디렉토리의 수는 변경 가능합니다. 따라서 아카이브 및 핫 백업 디렉토리를 각각 6개씩 사용하도록 선택한 경우 csdb 디렉토리에 라이브 데이터베이스 복사본이 6 + 6 + 1개가 있게 됩니다. csstored 유틸리티는 csdb 디렉토리에 있는 컨텐츠 크기와 csdb 디렉토리가 있는 실제 디스크 크기를 바탕으로 필요한 아카이브 및 핫 백업의 크기를 계산합니다.

편의상 아카이브 및 핫 백업 디렉토리는 기본적으로 csdb 디렉토리에 설치됩니다. 그러나 실제 배포할 때는 csdb 이외의 디렉토리에 설치해야 합니다.

기본 디스크 드라이브의 하드웨어 오류에 대비하여 대체 디스크나 디스크 하위 시스템에 핫 백업을 저장하도록 선택할 수 있습니다. 그렇게 하면 기본 드라이브나 하위 시스템에서 경쟁을 줄일 수도 있습니다.

고가용성(HA) 구성이 있는 경우 경로를 공유 저장소(/global/cal/)의 하위 디렉토리로 지정합니다. 6 장, 고가용성 Calendar Server 6.3 소프트웨어 구성(페일오버 서비스)을 참조하십시오.

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

9.6 Calendar Server 6.3 데이터베이스용 아카이브 백업 사용

이 절에서는 구성 프로그램을 실행할 때 아카이브 백업을 구성하지 않은 경우 Calendar Server 6.3 데이터베이스용 아카이브 백업을 사용하도록 설정하기 위한 개괄적인 자료와 지침을 제공합니다.

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

9.6.1 Calendar Server 버전 6.3의 아카이브 백업이란

아카이브 백업은 스냅샷과 스냅샷에 대해 생성된 로그 파일로 구성됩니다. 로그 파일은 스냅샷에 적용되지 않습니다. 아카이브 데이터베이스는 제거될 때까지 디스크에 남아 있습니다. 9.2.2 Calendar Server 6.3 시스템에서 순환 백업 작동 방법을 참조하십시오.

Calendar Server 6.3 시스템에서 아카이브 백업을 사용하려면

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

stop-cal 명령을 실행하여 Calendar Server 서비스를 중지합니다.

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

cd /etc/opt/SUNWics5/config

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

caldb.berkeleydb.archive.enable=”yes”

아카이브 백업 디렉토리의 디렉토리 경로를 지정합니다.
```
caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/archive_backup_directory
```
기본 디스크 드라이브의 하드웨어 오류에 대비하여 대체 디스크나 디스크 하위 시스템에 아카이브 백업을 저장하도록 선택할 수 있습니다. 그렇게 하면 기본 드라이브나 하위 시스템에서 I/O 경쟁을 줄일 수도 있습니다.

고가용성(HA) 구성이 있는 경우 경로를 공유 저장소(/global/cal/)의 하위 디렉토리로 지정합니다. 6 장, 고가용성 Calendar Server 6.3 소프트웨어 구성(페일오버 서비스)을 참조하십시오.

ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.

cal-svr-base/SUNWics5/cal/sbin/start-cal

ics.conf 파일을 편집하기 위해 달력 서비스를 중지할 필요는 없지만 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.

10장 다중 도메인 Calendar Server 6.3 환경 설정

이 장에서는 다중 도메인 환경을 처음 설정하는 방법에 대한 개요 자료 및 지침을 제공합니다.

정보 –

이전에는 다중 도메인 환경의 도메인을 호스트된 도메인 및 가상 도메인이라고 불렀습니다. 이들 용어는 이 문서에서 같은 의미로 사용됩니다.

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

10.1 Calendar Server 버전 6.3의 다중 도메인 개요

Calendar Server 6.3에서는 사용자 및 그룹 LDAP 항목을 구성하는 유일하고 기본적인 방법으로 다중 도메인을 제공합니다. 즉, 루트 노드 아래에 하나 이상의 도메인이 있고 모든 사용자 및 그룹 항목은 도메인 노드 아래에 있어야 합니다. 이전 버전의 Calendar Server에서는 사용자 및 그룹 항목을 포함하기 위해 도메인을 사용하는 것은 선택 사항이었습니다. 따라서 도메인을 사용하지 않고도 Calendar Server를 실행할 수 있었습니다. Calendar Server 6.3에서는 그렇지 않으며 하나 이상의 기본 도메인이 있어야 합니다.

다중 도메인 환경에서는 각 도메인이 동일한 Calendar Server 시스템의 인스턴스를 공유하므로, 여러 도메인이 하나의 서버에 존재할 수 있습니다. 각 도메인은 모든 사용자, 그룹 및 자원이 고유한 이름 공간을 정의합니다. 또한 각 도메인은 특별히 설정한 속성 및 기본 설정 집합을 갖습니다. 도메인의 모든 사용자 및 달력 아이디는 정규화되어야 합니다.

구성 프로그램에서는 기본 도메인을 설정하는 데 필요한 정보를 요청합니다. 구성 프로그램을 완료하고 필요한 모든 도메인을 만든 후 사용자 및 그룹 LDAP 항목을 원하는 도메인으로 복사하는 경우 마이그레이션 유틸리티를 실행하여 비도메인 사용자 및 그룹 LDAP 항목을 도메인 지원 사용자 및 그룹 항목으로 전환함으로써 사용자 및 그룹 항목을 준비해야 합니다. 실행할 유틸리티는 csmig와 csvdmig입니다.

비도메인 버전의 Calendar Server에서 Calendar Server 6.3으로 업그레이드하는 경우 몇 가지 선택 가능한 옵션이 있습니다.

단일 기본 도메인 모드로 전환할 수 있습니다.

이 경우에 LDAP의 도메인 노드 아래에 있는 사용자 및 그룹 레코드를 이동해야 합니다.
다중 도메인 모드로 전환하고 사용자 및 그룹을 다중 도메인에서 분산할 수 있습니다.

Delegated Administrator를 사용하여 추가 도메인을 만듭니다.

기존 사용자를 다중 도메인에 분산하려면 마이그레이션 유틸리티를 사용하여 정규화된 도메인 이름을 데이터베이스 사용자 아이디 및 달력 아이디에 추가해야 합니다. 이 방법을 통해 Delegated Administrator를 사용하여 만든 도메인에 사용자를 분산시킬 수 있습니다. 구성 프로그램을 실행하기 전에 도메인을 만듭니다.

현재 버전으로 업그레이드하기 전에 설정한 호스트된(다중) 도메인이 있는 경우 사용자 아이디 및 달력 아이디를 변경하지 않아야 합니다. 하지만 다음 절에서 나와 있는 것처럼 몇 가지 새로운 ics.conf 매개 변수를 구성해야 합니다. 10.4 Calendar Server 버전 6.3의 다중 도메인 모드에 필요한 추가 매개 변수.

주의 –

현재 사이트가 단일 시스템의 여러 Calendar Server 인스턴스에 대해 구성되어 있거나 제한된 가상 도메인 모드가 구현되어 있는 경우, Sun Microsystems 영업 담당자에게 문의하여 마이그레이션 요구 사항을 확인하십시오.

10.2 Calendar Server 버전 6.3에서 처음으로 다중 도메인 환경 설정

비도메인 또는 단일 도메인 환경에서 다중 도메인 환경으로 전환하는 경우 LDAP 항목을 만들기 전에 다음 작업을 수행해야 합니다.

데이터베이스 마이그레이션 유틸리티를 실행합니다.

Calendar Server 버전 5에서 마이그레이션하는 경우 다중 도메인을 설정하기 전에 csmig, csvdmig, cs5migrate 및 csmigrate를 미리 실행해야 합니다. 이러한 마이그레이션 유틸리티에 대한 자세한 내용은 3 장, Calendar Server 6.3용 데이터베이스 마이그레이션 유틸리티을 참조하십시오.
아직 comm_dsseetup.pl을 실행하지 않은 경우에는 실행합니다.
구성을 변경할 권한을 가지고 관리자로 로그인합니다.
stop-cal 명령을 실행하여 Calendar Server 서비스를 중지합니다.

ics.conf 파일을 편집하여 다중 도메인을 활성화합니다.

다음 표에는 다중 도메인 지원에 사용되는 ics.conf 파일의 구성 매개 변수가 정리되어 있습니다. 이 표에 나열된 매개 변수 중 ics.conf 파일에 없는 것이 있으면 해당 매개 변수와 해당 값을 파일에 추가하고 Calendar Server를 다시 시작하여 새 값을 적용합니다.

매개 변수	설명
`service.virtualdomain.support`	다중 도메인 지원을 활성화(`"yes"`)합니다. 기본값은 `"yes"`입니다. 주 – 단일 도메인에서 작동시키려는 경우에도 이 매개 변수는 `“no”`로 변경하지 마십시오. Calendar Server의 현재 버전에서는 이 매개 변수를`"yes"`로 설정해야 합니다.
`local.schemaversion`	LDAP 스키마의 버전을 지정합니다. 10.3.3 Calendar Server Version 6.3용 Sun LDAP 스키마 버전 1의 경우 `"1"`을 지정합니다. 또한 `service.dcroot`를 참조하십시오. 10.3.2 Calendar Server 버전 6.3용 Sun LDAP 스키마 버전 2의 경우 `"1.5"` 또는 `"2"`를 지정합니다. 또한 `service.schema2root`를 참조하십시오. 기본값은 `"2"`입니다.
`service.dcroot`	이 항목은 다중 도메인 지원을 위해 `local.ugldapbasedn` 및 `local.authldapbasedn`을 대체합니다. `local.schemaversion="1"` 또는 `local.schemaversion="1.5"`인 경우 모든 도메인이 있는 DC 트리의 루트 접미어를 지정합니다. 예를 들면 다음과 같습니다. `"o=internet"`.
`service.schema2root`	`local.schemaversion="2"`인 경우 모든 도메인이 있는 조직 트리의 루트 접미어를 지정합니다. 예를 들면 다음과 같습니다. `"o=sesta.com"`.
`service.defaultdomain`	Calendar Server의 해당 인스턴스에 대한 기본 도메인을 지정합니다. 로그인하는 중에 도메인 이름이 제공되지 않는 경우 사용됩니다. 예를 들면 다음과 같습니다. `"red.sesta.com"`.
`service.loginseparator`	Calendar Server가 `"userid[login-separator` `]domain"`을 구문 분석할 때 `login-separator`에 사용되는 구분자의 문자열을 지정합니다. Calendar Server에서는 각 구분자를 순서대로 구문 분석합니다. 기본값은 `"@+"`입니다.
`service.siteadmin.userid`	도메인 관리자의 사용자 아이디를 지정합니다. 예를 들면 다음과 같습니다. `DomainAdmin@sesta.com`.
`service.virtualdomain.scope`	도메인간 검색을 제어합니다. `"primary"` 사용자가 로그인한 도메인 내부에서만 검색합니다. `"select"` 검색이 허용된 모든 도메인에서 검색합니다. 기본값은 `"select"`입니다.
`local.domain.language`	도메인의 언어를 지정합니다. 기본값은 `"en`"(영어)입니다.

기본 도메인 항목을 만듭니다.

스키마 버전 2의 경우 Delegated Administrator 구성 프로그램(config-commda)에서 기본 도메인을 만듭니다.

스키마 버전 1의 경우, DC 트리 구조에 따라 DC 트리 루트 접미어로부터 한 단계 이상의 하위 수준에서 기본 도메인(다중 도메인 중 하나)을 만듭니다. 예를 들어, 10.3.3 Calendar Server Version 6.3용 Sun LDAP 스키마 버전 1에서 살펴본 것처럼 루트 접미어가 o=internet이면 그 다음 아래 수준의 노드는 com이 될 수 있습니다. 그러나 기본 도메인은 sesta.com처럼 한 노드 아래가 됩니다. 다음 예와 같이 csdomain을 사용하여 DC 트리 노드를 만듭니다.
```
csdomain -n o=com,dc=com,o=internet create comcsdomain
    -n o=sesta.com,dc=sesta,dc=com,o=internet create sesta.com
```
기본 도메인 항목에 대해 달력 서비스를 활성화합니다.

스키마 버전 1의 경우 csattribute를 사용하여 icsCalendarDomain 객체 클래스를 LDAP의 o=sesta.com 도메인 항목에 추가합니다.

스키마 버전 2의 경우 Delegated Administrator를 구성한 후에 Delegated Administrator 구성 프로그램을 통해 만들어진 기본 도메인을 수정하여 달력 및 메일 서비스를 추가합니다. 다음 예에서는 달력 및 메일 서비스가 도메인에 추가됩니다.

commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail
시스템에 원하는 만큼 도메인을 만듭니다.

스키마 버전 2 모드에서 도메인을 추가하는 방법에 대해서는 13.2 새 Calendar Server 도메인 만들기를 참조하십시오.

스키마 버전 1 도메인을 만들려면 다음 예와 같이 csdomain create를 사용합니다.
```
csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
   create red.sesta.com
```
새 도메인의 달력(필요한 경우 전자 메일 포함) 서비스를 추가합니다.
calmaster 사이트 관리자가 아직 없으면 만듭니다.

스키마 버전 2의 경우 다음 예에 나와 있는 것처럼 commadmin user create 명령을 사용하여 calmaster 사용자를 만듭니다.
```
commadmin user create -D admin -w passwd -F Calendar
    -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal
```
주 –
Delegated Administrator 콘솔의 새 사용자 만들기 마법사를 사용하여 calmaster를 만들려면 Delegated Administrator 온라인 도움말을 참조하십시오.

스키마 버전 1의 경우, 다음 예와 같이 csuser를 사용하여 조직 트리에 calmaster 사용자를 만듭니다.
```
csuser o=sesta.com,o=rootsuffix -d sesta.com
    -g Calendar -s Administrator -ycalmasterpasswordcreate calmaster
```
calmaster 사이트 관리자가 이전의 비도메인 환경(스키마 버전 1)에 존재하는 경우 다음 단계를 수행하여 기본 도메인으로 이동합니다.
1. 기존 calmaster LDAP 항목의 LDAP 덤프를 수행하고 /tmp/calmaster.ldif와 같은 임시 파일에 이를 저장합니다.
2. 다음과 같이 ldapdelete를 사용하여 조직 트리 루트 접두어에서 기존 calmaster LDAP 항목을 삭제합니다.
```
#ldapdelete -D "cn=Directory Manager" -w password 
   uid=calmaster,ou=People,o=rootsuffix
```
3. 달력 관리자의 그룹 항목(uniqueMember 속성 업데이트)을 수정하여 다음 예처럼 변경 사항을 적용합니다.
  dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix changetype:modifyreplace:uniqueMember uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix
  관리자의 그룹 항목을 도메인으로 옮길 필요는 없습니다.
WCAP 명령의 모든 달력 아이디(calid)가 정규화되도록 모든 관리 스크립트를 업데이트합니다. 따라서 각 calid에는 이제 도메인 이름이 포함되어야 합니다. 예를 들면 다음과 같습니다. jsmith@sesta.com.

10.3 Calendar Server 버전 6.3의 다중 도메인 기능이 스키마 선택에 주는 영향

이 절에서는 다중 도메인을 구현하는 프로세스를 보다 잘 이해하는 데 도움이 되는 개념 정보와 이것이 스키마 버전의 선택에 주는 영향에 대해 살펴봅니다.

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

10.3.1 다중 도메인의 개요 및 Calendar Server 버전 6.3에서 스키마 선택의 의미

다중 도메인 설치에서 LDAP 디렉토리는 공통 부분 없이 뚜렷이 구분되는 섹션들로 구성되며, 각 섹션은 DNS(Domain Name System)에 있는 도메인을 나타냅니다. 사용자, 그룹 및 자원의 고유 아이디는 각 도메인에서 고유합니다. 예를 들어, uid가 jdoe인 사용자는 각 도메인에 한 명만 있을 수 있습니다. 고유 이름(DN)은 정규화된 도메인 이름입니다.

Calendar Server는 이러한 두 LDAP 디렉토리 스키마 버전을 모두 지원합니다. 스키마 버전 1 및 스키마 버전 2. Directory Server 설정 스크립트(comm_dssetup.pl)를 실행할 때 LDAP 스키마 버전 1 또는 LDAP 스키마 버전 2 중에서 선택할 수 있습니다. 스키마 버전 1을 사용할 특별한 이유가 없다면 스키마 버전 2를 사용하십시오.

다음은 스키마 버전 1을 사용하는 두 가지 이유입니다.

스키마 버전 1이 이미 있고 LDAP를 채우는 데 Delegated Administrator를 사용할 계획이 없는 경우
스키마 버전 1이 이미 있고 Access Manager 기능을 사용할 계획이 없는 경우

10.3.2 Calendar Server 버전 6.3용 Sun LDAP 스키마 버전 2

다음 그림에서는 Sun LDAP 스키마 버전 2를 사용하는 다중 도메인 설치의 LDAP 디렉토리 조직을 보여 줍니다.

그림 10–1 LDAP 스키마 버전 2를 사용하는 LDAP 디렉토리 조직

이 다이어그램은 조직 트리만 있고 DC 트리는 없는 순수한 스키마 버전 2 환경의 예를 보여 줍니다.

LDAP 스키마 버전 2에서는 플랫 LDAP 디렉토리 조직을 사용합니다. 따라서 도메인은 모두 같은 수준에 위치하며 중첩되지 않습니다. 다중 도메인 설치의 경우 첫 번째 수준의 항목(그림의 varriusDomain, sestaDomain 및 siroeDomain)은 디렉토리 조직에서 병렬 관계가 되어야 합니다. 이 항목은 중첩될 수 없습니다.

단일 사인온과 같은 Access Manager 기능을 사용하거나 Delegated Administrator를 사용하여 사용자를 제공하려면 스키마 버전 2가 필요합니다. 그러나 DC 트리와 조직 트리를 모두 사용하는 2개의 트리 체계인 혼성 변형 스키마가 있습니다. 이 변형 스키마는 스키마 버전 1과 비슷하지만 스키마 버전 2 객체 클래스 및 속성을 사용합니다. 이것은 구성 프로그램(csconfigurator.sh)에서 스키마 버전 1.5라고 하는 스키마 버전 2 호환 모드입니다.

10.3.3 Calendar Server Version 6.3용 Sun LDAP 스키마 버전 1

다음에 나오는 그림은 Sun LDAP 스키마 버전 1을 사용하는 다중 도메인 설치에 대한 LDAP 디렉토리 조직의 예를 보여 줍니다.

이 조직은 도메인 관리를 위한 2개의 트리를 포함합니다.

트리
조직(OSI) 트리

그림 10–2 LDAP 스키마 버전 1을 사용하는 LDAP 디렉토리 조직

이 다이어그램은 두 개의 트리(스키마 버전 1, LDAP 조직)의 예를 보여 줍니다.

DC 트리(노드)는 DNS와 비슷하며 도메인 이름이 지정된 도메인 항목을 결정합니다. inetdomainbasedn LDAP 속성은 조직 트리(노드)에서 도메인의 사용자, 자원 및 그룹의 루트인 기본 DN을 가리킵니다. 각 도메인 내부에서 Calendar Server 사용자, 자원 및 그룹의 아이디는 고유해야 합니다.

주 –

이전 LDAP 구성에 DC 트리가 포함되지 않은 경우 스키마 버전 1 모드 또는 스키마 버전 2 호환 모드를 사용하려면 10.2 Calendar Server 버전 6.3에서 처음으로 다중 도메인 환경 설정에 설명된 대로 직접 DC 트리 노드를 만들어야 합니다. 하지만 스키마 버전 2 모드를 사용하는 것이 좋습니다.

LDAP 스키마 버전 1을 사용하는 다중 도메인 설치에서 디렉토리를 검색하려면 다음의 두 단계를 통해 항목을 찾아야 합니다.

DC 트리에서 검색 작업은 조직 트리에서 도메인의 기본 DN(inetDomainBaseDN 속성)을 가리키는 DN 값이 있는 도메인 항목을 찾습니다.
조직 트리에서 검색 작업은 도메인 항목을 찾고 이 항목의 기본 DN을 검색하여 도메인 내부의 사용자, 자원 또는 그룹을 찾습니다.

10.4 Calendar Server 버전 6.3의 다중 도메인 모드에 필요한 추가 매개 변수

Calendar Server 6 부터 모든 배포가 다중 도메인을 사용하도록 구성됩니다. 이전 버전의 Calendar Server에서 업그레이드하는 경우 호스트된(다중) 도메인을 구성하지 않으면 다음과 같이 스키마 모드에 대한 매개 변수를 추가해야 합니다.

10.4.1 Calendar Server 버전 6.3의 스키마 버전 1 추가 매개 변수

다음 목록에는 구성 파일(ics.conf)에 없는 경우 추가해야 하는 매개 변수가 정리되어 있습니다.

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support, "yes"로 설정

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion, "1"로 설정

10.4.2 Calendar Server 버전 6.3의 스키마 버전 2 추가 매개 변수

다음 목록에는 구성 파일(ics.conf)에 없는 경우 추가해야 하는 매개 변수가 정리되어 있습니다.

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support, "yes"로 설정

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion, "2"로 설정

service.schema2root

10.5 Calendar Server 6.3 로그인

다중 도메인 설치의 경우 각 사용자는 도메인 내부에서 고유한 사용자 아이디(uid )가 있어야 합니다. Calendar Server에 로그인할 때 다음 형식을 사용합니다.

userid[@domain-name]

domain-name을 생략하면 Calendar Server는 ics.conf 파일의 service.defaultdomain 매개 변수에서 지정한 기본 도메인 이름을 사용합니다. 따라서 사용자가 기본 도메인에 로그인하는 경우 userid만 필요합니다.

자동 제공이 활성화된 경우 사용자가 처음 로그인하면 Calendar Server에서 해당 사용자의 기본 달력을 만듭니다. 달력 생성에 대한 자세한 내용은 15 장, 달력 관리을 참조하십시오.

로그인 권한은 icsStatus 또는 icsAllowedServiceAccess 속성을 바탕으로 합니다. 자세한 내용은 D.9.3 LDAP 속성 및 등록 정보 이름을 참조하십시오.

10.6 Calendar Server 버전 6.3의 비도메인 환경에서 마이그레이션

Calendar Server 버전 5.0 및 이전 버전에는 도메인이 없습니다. 따라서 사용자 및 달력 아이디를 정규화할 필요가 없었습니다. 즉, 도메인 이름을 jdoe@domain.com과 같이 아이디의 일부로 사용하지 않아도 됩니다. 현재 버전의 Calendar Server를 설치하기 전에 uid 및 calid가 정규화되지 않은 경우 데이터를 변경할 필요가 없습니다. 시스템에서는 발견된 정규화되지 않은 uid 및 calid가 기본 도메인이 속해 있는 것으로 가정합니다. 다중 도메인을 구성하려면 각 사용자가 속해 있는 도메인을 나타내도록 LDAP 및 구성 요소 데이터베이스를 마이그레이션해야 합니다.

또한 데이터는 다른 방법으로 마이그레이션해야 할 수 있습니다. 다음과 같은 몇 가지 마이그레이션 프로그램이 있습니다. 3 장, Calendar Server 6.3용 데이터베이스 마이그레이션 유틸리티의 마이그레이션 정보를 확인하십시오.

11장 Calendar Server 6.3 시스템용 기존 도메인 사용자 정의

이 장에서는 기존 도메인을 사용자 정의하는 방법에 대한 개념 정보와 지침을 제공합니다.

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

11.1 Calendar Server 버전 6.3의 그룹에 대한 도메인 기본 설정 구성

LDAP에서 설정한 사용자 그룹을 사용하는 경우 이중 예약에 대한 도메인 수준의 기본 설정을 지정하고 기본 ACL을 설정할 수 있습니다.

11.1.1 Calendar Server 버전 6.3에서 이중 예약 도메인 기본 설정 지정

도메인 LDAP 항목에서 icsAllowRights 속성의 15번 비트를 설정합니다. 이중 예약이 허용되지 않는 경우 "0"을 사용합니다. 이중 예약이 허용되는 경우 "1"을 사용합니다.

11.1.2 Calendar Server 버전 6.3에서 그룹에 대한 기본 ACL 지정

그룹에 대한 기본 액세스 제어 권한을 다양한 수준으로 변경할 수 있습니다.

이 절은 다음 그룹 ACL 항목으로 구성되어 있습니다.

11.1.2.1 모든 그룹

임의 도메인의 그룹에 대한 기본 ACL은 ics.conf 파일 매개 변수 group.default.acl에 지정되어 있습니다. 기본 ACL은 다음과 같습니다.

"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

이 항목을 편집하여 ACL을 변경할 수 있습니다.

11.1.2.2 특정 도메인의 모든 그룹

특정 도메인의 그룹에 대한 기본 ACL을 변경하려면 해당 도메인 LDAP 항목을 편집해야 합니다. icsExtendedDomainPrefs 속성에서 groupdefaultacl 등록 정보 값을 변경합니다.

11.1.2.3 도메인의 특정 그룹

특정 그룹에 대한 기본 ACL을 변경하려면 그룹 LDAP 항목을 편집합니다. icsDefaultacl 속성 값을 변경합니다.

11.2 Calendar Server 6.3 시스템에서 도메인 간 검색

이 절에서는 도메인 간 검색을 설정하기 위한 개념 정보와 고급 작업에 대해 설명합니다.

기본적으로 사용자는 홈 도메인 내부에서만 이벤트에 초대할 사용자, 그룹 및 자원을 검색할 수 있습니다. 그러나 특정 요구 사항을 만족하면 도메인 간 검색을 통해 다른 도메인의 사용자, 그룹 및 자원도 검색할 수 있습니다.

다음은 도메인 간 검색을 구현하는 데 필요한 요구 사항 목록입니다.

각 도메인은 icsExtendedDomainPrefs 속성의 domainAccess 등록 정보에 다른 도메인으로부터의 도메인 간 검색을 허용하거나 거부하는 액세스 제어 목록(ACL)을 지정할 수 있습니다. 따라서 도메인은 특정 도메인이나 모든 도메인이 자신을 검색하는 것을 허용하거나 거부할 수 있습니다.

정보 –
둘 이상의 도메인을 지정하려면 domainAccess 등록 정보 값에서 도메인 이름을 세미콜론으로 구분하여 입력합니다.

주의 –
LDAP 도메인 항목에는 하나의 domainAccess 등록 정보 항목만 포함할 수 있습니다. LDAP 도구를 사용하여 도메인 항목에 ACL을 추가하려면 실수로 domainAccess 등록 정보를 복제하지 않았는지 확인해야 합니다.

domainAccess에 대한 자세한 내용은 D.9.3 LDAP 속성 및 등록 정보 이름을 참조하십시오. ACL에 대한 일반적인 정보는 1.8.3 Calendar Server 버전 6.3의 액세스 제어 목록(ACL)을 참조하십시오.
각 도메인마다 해당 사용자가 검색할 수 있는 외부 도메인을 지정할 수 있습니다. icsDomainNames LDAP 속성은 사용자와 그룹을 찾을 때 도메인 사용자가 검색할 수 있는 외부 도메인을 지정합니다(단, 외부 도메인의 ACL이 검색을 허용해야 함).

예를 들어 various.org 도메인의 icsDomainNames에서 sesta.com 및 siroe.com이 지정된 경우 various.org의 사용자는 sesta.com 및 siroe.com에서 도메인 간 검색을 수행할 수 있습니다. icsDomainNames에 대한 자세한 내용은 D.9.3 LDAP 속성 및 등록 정보 이름을 참조하십시오.

도메인 간 검색을 활성화하는 방법에 대한 자세한 내용은 13.3 도메인간 검색 활성화를 참조하십시오.

11.3 Calendar Server 버전 6.3에서 Messaging Server가 만든 도메인 사용

Messaging Server에서 이미 도메인을 만든 경우 Schema 버전 1 또는 Schema 버전 2 모드 중 하나에서 달력 서비스를 추가할 수 있습니다.

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

11.3.1 Calendar Server 버전 6.3의 Schema 버전 1 모드에서 메시징 도메인에 달력 서비스 추가

도메인에 달력 서비스를 추가하려면 다음 객체 클래스와 두 개의 속성을 도메인의 LDAP 항목에 추가합니다.

객체 클래스: icsCalendarDomain.
속성:icsStatus. 이 값을 "active"로 설정합니다.
속성: icsExtendedDomainPrefs. domainAccess 속성 옵션의 값을 액세스 제어에 사용할 ACL로 설정합니다.

다음의 두 가지 방법 중 하나로 이 작업을 수행할 수 있습니다. 다음 예에 나와 있는 것처럼 csattribute add 명령을 사용하거나 ldapmodify를 사용합니다.

dn:dc=sesta,dc=com,o=internet
 changetype:modify
 add:objectclass
 objectClass:icsCalendarDomain
 add:icsStatus
 icsStatus:active
 add:icsExtendedDomainPrefs
 icsExtendedDomainPrefs:domainAccess=@@d^a^slfrwd^g;anonymous^a^r^g;@^a^s^g

11.3.2 Calendar Server 버전 6.3의 Schema 버전 2 모드에서 메시징 도메인에 달력 서비스 추가

Messaging Server가 Schema 버전 2 모드에서 실행되는 경우 다음 두 단계를 수행하여 기존 도메인에 달력 서비스를 추가할 수 있습니다.

Delegated Administrator 유틸리티 명령 commadmin domain modify를 -S 옵션과 함께 사용하여 각 도메인에 달력 서비스를 추가합니다.

Delegated Administrator 콘솔을 사용하여 영향 받는 도메인에 달력 서비스가 들어 있는 서비스 패키지를 할당할 수도 있습니다. 이렇게 하려면 조직 목록 페이지에서 서비스 패키지 할당 버튼을 사용하십시오.
Delegated Administrator 유틸리티 명령 commadmin user modify를 -S 옵션과 함께 사용하여 달력에 대해 활성화된 각 도메인의 사용자에게 달력 서비스를 추가합니다.

Delegated Administrator 콘솔을 사용하여 영향 받는 도메인의 각 사용자에게 달력 서비스가 들어 있는 서비스 패키지를 지정할 수도 있습니다. 이 작업을 수행하려면 영향을 받는 조직의 각 사용자 목록 페이지에서 서비스 패키지 할당 버튼을 사용하십시오.

commadmin 명령에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide를 참조하십시오.

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

commdirmig 명령에 대한 자세한 내용은 Sun Java Communications Suite 5 Schema Migration Guide를 참조하십시오.