3장 Calendar Server 관리

이 장에서는 Sun™ ONE Calendar Server를 구성하고 관리하는 방법을 설명합니다.

명령줄 유틸리티를 실행하고 ics.conf 구성 파일을 편집하는 방법을 통해 Calendar Server를 관리합니다.

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

Calendar Server 시작 및 중지

start-cal 및 stop-cal 유틸리티 사용


주	Calendar Server는 오로지 이전 릴리스와의 호환성을 위해 csstart 및 csstop 유틸리티를 제공합니다. Calendar Server를 시작하고 중지하려면 start-cal 유틸리티와 stop-cal 유틸리티를 사용하는 것이 좋습니다.

start-cal 및 stop-cal 유틸리티는 cal_svr_base/opt/SUNWics5/cal/sbin 디렉토리에 있습니다. Calendar Server가 설치된 로컬 시스템에서 이러한 유틸리티들을 실행해야 합니다. 문제가 발생할 경우 "start-cal 및 stop-cal 유틸리티 문제 해결"을 참조하십시오.

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

enpd - 이벤트 알림 서비스(ENS)

csnotifyd - 알림 서비스

csadmind - 관리 서비스

csdwpd - 원격 Calendar Server 데이터베이스 구성에서만 시작되는 분산 데이터베이스 서비스인 데이터베이스 와이어 프로토콜(DWP) 서비스

cshttpd - HTTP 서비스

이 서비스에 대한 자세한 설명은 "Calendar Server 서비스"를 참조하십시오.

start-cal 명령을 사용하여 Calendar Server를 시작하는 방법

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

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

다음을 사용하여 Calendar Server를 시작합니다.

./start-cal

stop-cal 명령을 사용하여 Calendar Server를 중지하는 방법

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

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

다음을 사용하여 Calendar Server를 중지합니다.

./stop-cal

start-cal 및 stop-cal 유틸리티 문제 해결

Calendar Server를 시작하고 중지할 때 다음 문제가 발생할 수 있습니다.

start-cal 유틸리티가 모든 Calendar Server 프로세스를 시작하는 것은 아닙니다. 예를 들어, start-cal은 enpd, csnotifyd 및 csadmind 프로세스를 시작할 수 있지만 cshttpd는 시작하지 않습니다. 이 경우 Calendar Server를 다시 시작하기 전에 모든 Calendar Server 프로세스를 중지해야 합니다.

stop-cal 유틸리티는 모든 Calendar Server 프로세스를 중지하지는 않습니다. 예를 들어, stop-cal은 cshttpd 부모 프로세스를 중지할 수 있지만 cshttpd 자식 프로세스는 중지할 수 없습니다. 이 경우 나머지 Calendar Server 프로세스를 중지해야 합니다.

Solaris 시스템에서 Calendar Server 프로세스를 중지하는 방법

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

각 서비스마다 ps 명령을 입력하여 나머지 Calendar Server 프로세스의 프로세스 아이디(PID)를 확인합니다.

ps -elf | grep cs-process

여기서 cs-process는 enpd, csnotifyd, csdwpd, csadmind 또는 cshttpd입니다. 예를 들면 다음과 같습니다.

ps -elf | grep cshttpd

아직 실행 중인 각 프로세스의 PID를 사용하여 프로세스를 종료시킬 pkill -15 명령을 입력합니다. 예를 들면 다음과 같습니다.

pkill -15 9875

각 ps 명령을 다시 입력하여 모든 Calendar Server 프로세스가 중지되었는지 확인합니다.

Calendar Server 프로세스가 아직 실행 중이라면 pkill -9 명령을 입력하여 종료합니다. 예를 들면 다음과 같습니다.

pkill -9 9875


주의	모든 Calendar Server 프로세스를 중지하고 나서 Calendar Server를 다시 시작하기 전에 csdb utility check 명령을 실행하여 달력 데이터베이스가 손상되지 않았는지 확인해 보는 것이 좋습니다. check 명령에 대한 자세한 내용은 "달력 데이터베이스 검사 및 다시 만들기"를 참조하십시오.

Calendar Server 시간 초과 값 구성

csadmind의 시간 초과 값 구성

최종 사용자에 대한 HTTP 시간 초과 값 구성

csadmind의 시간 초과 값 구성

표 3-1에서는 관리(csadmin) 서비스에서 사용하는 ics.conf 파일의 Calendar Server 시간 초과 매개 변수를 설명합니다.

표 3-1 관리 서비스(csadmin)의 HTTP 시간 초과 값
매개 변수	설명
service.admin.idletimeout	csadmind 서비스가 유휴 HTTP 연결 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 120초(2분)입니다.
service.admin.resourcetimeout	csadmind 서비스가 자원 달력에 대한 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 900초(15분)입니다.
service.admin.sessiontimeout	csadmind 서비스가 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 1800초(30분)입니다.

최종 사용자에 대한 HTTP 시간 초과 값 구성

표 3-2에서는 최종 사용자에게 적용되는 ics.conf 파일의 Calendar Server HTTP 시간 초과 매개 변수를 설명합니다.

표 3-2 최종 사용자용 ics.conf의 HTTP 시간 초과 값(cshttpd 서비스)
매개 변수	설명
service.http.idletimeout	cshttpd 서비스가 유휴 HTTP 연결 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 120초(2분)입니다.
service.http.resourcetimeout	cshttpd 서비스가 달력 자원의 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 900초(15분)입니다.
service.http.sessiontimeout	cshttpd 서비스가 HTTP 세션 시간 초과까지 대기하는 시간을 초 단위로 지정합니다. 기본값은 1800초(30분)입니다.

단일 사인 온(SSO) 구성

단일 사인 온(SSO)에서는 사용자가 한 번만 인증하면 다시 인증할 필요 없이 신뢰할 수 있는 여러 응용 프로그램을 사용할 수 있습니다. Calendar Server와 Messaging Server를 비롯하여 Sun ONE 통신 서버는 다음과 같이 SSO를 구현할 수 있습니다.

Identity Server를 통한 SSO 구성

통신 서버 Trusted Circle Technology를 통한 SSO 구성

Identity Server를 통한 SSO 구성

Calendar Server 및 Messaging Server를 비롯하여 Sun ONE 서버는 Sun ONE Identity Server 6.1 이상을 사용하여 SSO를 구현할 수 있습니다.

Identity Server는 Sun ONE 서버를 위한 SSO 게이트웨이 역할을 합니다. 즉 Identity Server에 로그인한 사용자는 SSO가 제대로 구성된 다른 Sun ONE 서버에 액세스할 수 있습니다.

Sun ONE Identity Server 및 Sun ONE Directory Server가 설치 및 구성되어야 합니다. 이 제품들의 설치 및 구성에 대한 자세한 내용은 Sun Java Enterprise System 설치 설명서를 참조하십시오.

Calendar Server의 SSO를 구성하려면 표 3-3의 매개 변수를 설정하고 Calendar Server를 다시 시작해야 이 값들이 적용됩니다. 필요하다면 각 매개 변수를 설정할 때 주석 문자(!)를 제거합니다.

주 local.calendar.sso.amnamingurl 매개 변수 설정 시 정규화된 Identity Server 이름을 사용해야 합니다.

Messaging Server의 SSO를 구성하려면 Sun ONE Messaging Server 6.0 관리자 설명서를 참조하십시오.

사용자는 Directory Server LDAP 사용자 아이디 및 비밀번호를 사용하여 Identity Server에 로그인합니다. Calendar Server나 Messaging Server와 같은 다른 서버를 통해 로그인하는 사용자는 SSO를 사용하여 다른 Sun ONE 서버에 액세스할 수 없습니다.

로그인한 사용자는 적합한 URL을 사용하여 Calendar Express를 통해 Calendar Server에 액세스할 수 있습니다. 또한 Messaging Server와 같은 다른 Sun ONE 서버도 SSO가 제대로 구성되었다면 액세스할 수 있습니다.

표 3-3 Identity Server의 SSO를 사용하기 위한 Calendar Server 구성 매개 변수
매개 변수	설명
local.calendar.sso.amnamingurl	Identity Server SSO 이름 지정 서비스의 URL을 지정합니다. 기본값은 "http://IdentityServer:port/amserver/namingservice"입니다. 여기서 IdentityServer는 Identity Server의 정규화된 이름이며 port는 Identity Server 포트 번호입니다.
local.calendar.sso.amcookiename	Identity Server SSO 쿠키의 이름을 지정합니다. 기본값은 "iPlanetDirectoryPro"입니다.
local.calendar.sso.amloglevel	Identity Server SSO의 로그 수준을 지정합니다. 범위는 1(무음)부터 5(세부 정보 표시)입니다. 기본값은 "3"입니다.
local.calendar.sso.logname	Identity Server SSO API 로그 파일의 이름을 지정합니다. 기본값은 "am_sso.log"입니다.
local.calendar.sso.singlesignoff	Calendar Server에서 Identity Server로의 단일 사인 온(SSO)을 사용 가능("yes") 또는 사용 불가능("no")하게 합니다. 사용 가능한 경우, Calendar Server에서 로그아웃한 사용자는 Identity Server에서도 로그아웃되며 Identity Server를 통해 시작했던 다른 모든 세션(Messaging Server webmail 세션 등)도 종료합니다. Identity Server는 인증 게이트웨이이므로 단일 사인 온(SSO)은 항상 Identity Server에서 Calendar Server로 사용 가능하게 설정됩니다. 기본값은 "yes"입니다.

Identity Server의 SSO 사용 시 고려 사항

Identity Server 세션이 유효한 경우에만 달력 세션이 유효합니다. 사용자가 Identity Server에서 로그아웃하면 달력 세션은 자동으로 종료됩니다(단일 사인 오프).

SSO 응용 프로그램은 동일한 도메인에 있어야 합니다.

SSO 응용 프로그램은 Identity Server 인증 URL(이름 지정 서비스)에 액세스할 수 있어야 합니다.

브라우저는 쿠키를 지원해야 합니다.

Sun ONE Portal Server 게이트웨이를 사용하는 경우 다음 Calendar Server 매개 변수를 설정합니다.

service.http.ipsecurity="no"

render.xslonclient.enable="no"

통신 서버 Trusted Circle Technology를 통한 SSO 구성

통신 서버 Trusted Circle Technology를 통해(즉 Identity Server를 거치지 않고) SSO를 구성할 경우 다음 사항을 고려합니다.

신뢰할 수 있는 각 응용 프로그램은 SSO가 구성되어야 합니다.

default.html 페이지가 브라우저의 캐시에 있다면 SSO는 제대로 실행되지 않습니다. SSO를 사용하기 전에 반드시 브라우저에 default.html 페이지를 다시 로드합니다. 예를 들어, Netscape Navigator에서는 Shift 키를 누른 채로 Reload를 누릅니다.

SSO는 기본 URL에 대해서만 실행됩니다. 예를 들어, http://servername에서는 실행되지만 http://servername/command.shtml?view와 같은 URL에 대해서는 실행되지 않습니다.

표 3-4에서는 통신 서버 Trusted Circle Technology를 사용하는 SSO를 위한 Calendar Server 구성 매개 변수를 설명합니다.

표 3-4 통신 서버 Trusted Circle Technology를 사용하는 Calendar Server SSO 매개 변수
매개 변수	설명
sso.enable = "1"	SSO를 사용 가능하게 하려면 이 매개 변수는 "1"(기본값)로 설정되어야 합니다. "0"이면 SSO를 사용할 수 없습니다.
sso.appid = "ics50"	이 매개 변수는 특정 Calendar Server 설치의 고유 응용 프로그램 아이디를 지정합니다. 또한 신뢰할 수 있는 각 응용 프로그램은 고유 응용 프로그램 아이디를 가져야 합니다. 기본값은 "ics50"입니다.
sso.appprefix = "ssogrp1"	이 매개 변수는 SSO 쿠키 형식 지정에 사용될 접두어 값을 지정합니다. 신뢰할 수 있는 모든 응용 프로그램에서 동일한 값을 사용해야 합니다. Calendar Server는 이 접두어를 갖는 SSO 쿠키만 인식하기 때문입니다. 기본값은 "ssogrp1"입니다.
sso.cookiedomain = ".sesta.com"	이 매개 변수는 브라우저가 특정 도메인의 서버로만 쿠키를 보내게 합니다. 이 값은 반드시 마침표(.)로 시작해야 합니다.
sso.singlesignoff = "true"	값이 "true"(기본값)이면 클라이언트가 로그아웃할 때 해당 클라이언트 중 sso.appprefix에서 구성한 값과 일치하는 접두어 값을 가진 모든 SSO 쿠키를 지웁니다.
sso.userdomain = "sesta.com"	이 매개 변수는 사용자 SSO 인증의 일부로 도메인을 설정합니다.
sso.appid.url = "verifyurl" 예: sso.ics50.url = "http://sesta.com:8883/VerifySSO?" sso.msg50.url = "http://sesta.com:8882/VerifySSO?"	이 매개 변수는 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입니다.

표 3-5에서는 통신 서버 Trusted Circle Technology를 사용하는 SSO를 위한 Messaging Server SSO 구성 매개 변수를 설명합니다.

표 3-5 통신 서버 Trusted Circle Technology를 사용하는 Messaging Server SSO 매개 변수
매개 변수	설명
local.webmail.sso.enable = 1	SSO를 사용하려면 이 매개 변수가 0이 아닌 값으로 설정되어야 합니다.
local.webmail.sso.prefix = ssogrp1	이 매개 변수는 HTTP 서버가 설정하는 SSO 쿠키의 형식 지정에 사용할 접두어를 지정합니다.
local.webmail.sso.id = msg50	이 매개 변수는 Messaging Server의 고유 응용 프로그램 아이디(msg50)를 지정합니다. 신뢰할 수 있는 각 응용 프로그램도 고유 응용 프로그램 아이디를 가져야 합니다.
local.webmail.sso.cookiedomain = sesta.com	이 매개 변수는 HTTP 서버가 설정하는 모든 SSO 쿠키의 쿠키 도메인 값을 지정합니다.
local.webmail.sso.singlesignoff = 1	값이 0이 아니면 클라이언트가 로그아웃할 때 해당 클라이언트 중 local.webmail.sso.prefix에서 구성한 값과 일치하는 접두어 값을 가진 모든 SSO 쿠키를 지웁니다.
local.sso.appid.url = "verifyurl" 예: local.sso.ics50.verifyurl = http://sesta.com:8883/VerifySSO? local.sso.msg50.verifyurl = http://sesta.com:8882/VerifySSO?	이 매개 변수는 Messaging Server 구성에서 피어 SSO 호스트의 확인 URL 값을 설정합니다. 신뢰할 수 있는 각각의 피어 SSO 호스트에 대해 하나의 매개 변수가 필요합니다. 이 매개 변수는 다음 항목을 포함합니다. 응용 프로그램 아이디(appid)는 SSO 쿠키가 받아들여지는 각각의 피어 SSO 호스트를 식별합니다. URL 확인("verifyurl")에는 호스트 URL, 호스트 포트 번호 및 VerifySSO?(끝부분의 ? 포함)가 포함됩니다. 이 예에서 Messaging Server 응용 프로그램 아이디는 msg50, 호스트 URL은 sesta.com, 그리고 포트는 8882입니다. Calendar Server 응용 프로그램 아이디는 ics50, 호스트 URL은 sesta.com, 그리고 포트는 8883입니다.

Messaging Server의 SSO 구성에 대한 자세한 내용은 Sun ONE Messaging Server 6.0 관리자 설명서를 참조하십시오.

LDAP 달력 조회 데이터베이스(CLD) 플러그 인 구성

LDAP CLD 플러그 인에서는 단일 달력 인스턴스에서 사용자 및 자원 달력을 여러 백엔드 서버에 분산시키는 방법으로 달력 데이터베이스의 수평 확장성을 제공합니다. LDAP CLD 플러그 인은 icsDWPHost 속성을 사용하여 달력이 위치한 백엔드 서버를 확인합니다.


주	Calendar Server 5.1.1 및 이후 릴리스에서는 CLD 플러그 인의 주 버전 번호가 1에서 2로 변경되었습니다. 부 버전 번호는 그대로 0입니다. 자체적으로 CLD 플러그 인을 작성한 경우 새로운 주 버전 번호를 지원하도록 플러그 인을 수정해야 합니다.

LDAP CLD 플러그 인의 실행 방식

Calendar Server의 LDAP CLD 플러그 인 구성

프런트엔드와 백엔드 서버 간의 보안 유지 관리

LDAP CLD 플러그 인 성능 향상

CLD 캐시 지우기

다른 백엔드 서버로 달력 이동

LDAP CLD 플러그 인의 실행 방식

LDAP CLD 플러그 인에서는 달력 데이터베이스를 여러 백엔드 서버에 분산시킬 수 있습니다. 데이터베이스의 각 달력은 다음 형식의 고유 달력 아이디(calid)로 식별합니다.

userid는 Calendar Server 인스턴스의 고유 사용자 아이디입니다.

domain은 사용자를 위한 선택적 도메인 이름입니다.

calendar-name은 특정 사용자 고유의 선택적 달력 이름입니다.

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

Calendar Express 최종 사용자가 달력에 액세스할 때 LDAP CLD 플러그 인은 달력의 calid에서 userid를 추출한 다음 LDAP 서버 데이터베이스에서 달력 소유자를 조회합니다.

이 플러그 인은 달력 소유자를 찾은 후 소유자의 icsDWPHost LDAP 속성을 사용하여 달력이 위치한 백엔드 서버의 호스트 이름을 확인합니다. 이 이름은 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다.

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

Calendar Server는 사용자가 로그인한 서버에 DWP를 사용하여 달력 데이터를 보내고, 그런 다음 Calendar Express는 최종 사용자의 브라우저에 데이터를 렌더합니다.



주	사이트에서 LDAP CLD 플러그 인을 사용하고 cscal 유틸리티를 사용하여 새 달력이 만들어지는 경우, 해당 사용자의 달력이 위치한(또는 위치하게 될) 백엔드 서버(사용자의 icsDWPHost LDAP 속성으로 확인)에 새 달력을 만들어야 합니다. 다른 백엔드 서버에서 달력을 만들려고 할 경우 Calendar Server는 오류를 반환합니다. 자세한 내용은 "cscal"을 참조하십시오.

Calendar Server의 LDAP CLD 플러그 인 구성

다중 프런트엔드 서버와 다중 백엔드 서버

다중 프런트엔드/백엔드 서버 구성

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

같은 Solaris 운영 체제 실행

패치를 포함하여 같은 Calendar Server 릴리스 실행

같은 DWP 포트 번호(service.dwp.port 매개 변수) 사용. 기본 포트 번호는 “59779”입니다.

다중 프런트엔드 서버와 다중 백엔드 서버

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

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

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

프런트엔드 서버 구성

프런트엔드 서버를 구성하려면 각 프런트엔드 서버의 ics.conf 파일에서 다음 매개 변수를 설정합니다.

달력 데이터베이스 조회 플러그 인을 사용 가능하게 합니다.

csapi.plugin.calendarlookup = "y"

Calendar Server가 모든 플러그 인을 로드하도록 지정합니다.

csapi.plugin.calendarlookup.name = "*"

LDAP CLD 플러그 인을 위한 달력 조회 플러그 인의 유형을 설정합니다.

caldb.cld.type = "directory"

DWP 서비스(csdwpd)의 포트 번호를 설정합니다.

service.dwp.port = "59779"

기본값은 "59779"입니다. 포트 번호는 구성된 모든 프런트엔드 및 백엔드 서버에서 동일해야 합니다.

구성에 포함된 각 백엔드 서버의 서버 이름을 설정합니다.

caldb.dwp.server.backend-server-1.ip = "backend-server-1"
caldb.dwp.server.backend-server-2.ip = "backend-server-2"
...
caldb.dwp.server.backend-server-n.ip = "backend-server-n"

서버 이름은 정규화된 이름이어야 하며 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다. 매개 변수의 각 부분에서 서버 이름이 같아야 하며 정규화되어야 합니다. 예를 들면 다음과 같습니다.

caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

또한 서버 이름은 적용 가능한 달력 소유자의 icsDWPHost LDAP 속성에 사용된 이름과 일치해야 합니다.

기본 DWP 서버 이름을 설정합니다.

caldb.dwp.server.default = "server-name"

여기서 server-name은 LDAP 서버 데이터베이스의 사용자 또는 자원 항목에 icsDWPHost 속성이 없는 경우 Calendar Server에서 사용하는 정규화된 기본 서버 이름입니다. 이 이름은 DNS(Domain Name Service)에서 유효한 IP 주소로 확인할 수 있어야 합니다. 예를 들면 다음과 같습니다.

caldb.dwp.server.default = "calendar.sesta.com"

변경 내용을 적용하려면 Calendar Server를 다시 시작합니다.

프런트엔드 서버의 구성 매개 변수의 예

다음 예에서는 calendar.sesta.com 및 calendar.siroe.com이라는 이름의 백엔드 서버 2대가 있는 프런트엔드 서버의 구성 매개 변수를 보여 줍니다. 기본 DWP 서버는 calendar.sesta.com입니다.

백엔드 서버 구성

백엔드 서버를 구성하려면 각 백엔드 서버에서 ics.conf 파일의 다음 매개 변수를 설정합니다.

DWP 서비스를 사용 가능하게 하고(csdwpd) DWP 포트 번호를 설정합니다.

service.dwp.enable = "y"
service.dwp.port = "59779"

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

백엔드 서버에서는 HTTP 서비스가 필요하지 않으므로 이 서비스를 사용 불가능하게 합니다. 이때 관리 서비스는 기본값 "yes"로 설정되어야 합니다.

service.http.enable = "no"
service.admin.enable = "yes"

LDAP CLD 플러그 인을 위한 달력 조회 플러그 인의 유형을 설정합니다.

caldb.cld.type = "local"

백엔드 서버는 달력 데이터를 조회할 필요가 없으므로 csapi.plugin.calendarlookup을 "n"으로 설정합니다.

csapi.plugin.calendarlookup = "n"

변경 내용을 적용하려면 Calendar Server를 다시 시작합니다.

백엔드 서버의 구성 매개 변수의 예

다음 예에서는 백엔드 서버의 구성 매개 변수를 보여 줍니다.

다중 프런트엔드/백엔드 서버 구성

다음 그림에서는 각각 하나의 달력 데이터베이스에 연결된 3대의 프런트엔드/백엔드 서버를 보여 줍니다. 이 구성에서는 그 소유자가 Calendar Server에 로그인한 서버에 각 달력이 위치하는 방식으로 달력을 지역적으로 분산시킬 수 있습니다.

프런트엔드/백엔드 서버 구성

프런트엔드/백엔드 서버를 구성하려면 각 서버에서 ics.conf 파일의 다음 매개 변수를 설정합니다.

DWP 서비스를 사용 가능하게 합니다(csdwpd).

service.dwp.enable = "y"

DWP 서비스(csdwpd)의 포트 번호를 설정합니다.

service.dwp.port = "59779"

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

달력 조회 플러그 인을 사용 가능하게 합니다.

csapi.plugin.calendarlookup = "y"

Calendar Server가 모든 플러그 인을 로드하게 합니다.

csapi.plugin.calendarlookup.name = "*"

Calendar Server가 사용하는 달력 조회 플러그 인의 유형을 지정합니다.

caldb.cld.type = "directory"

기본 DWP 서버 이름을 설정합니다.

caldb.dwp.server.default = "server-name"

caldb.dwp.server.default = "calendar.sesta.com"

로컬 서버를 비롯하여 구성에 포함된 모든 프런트엔드/백엔드 서버의 서버 이름을 설정합니다.

caldb.dwp.server.server-1.ip = "server-1"
caldb.dwp.server.server-2.ip = "server-2"
...
caldb.dwp.server.server-n.ip = "server-n"

caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

또한 서버 이름은 적용 가능한 달력 소유자의 icsDWPHost LDAP 속성에 사용된 이름과 일치해야 합니다.

변경 내용을 적용하려면 Calendar Server를 다시 시작합니다.

각 프런트엔드/백엔드 서버의 구성 매개 변수의 예

다음 예에서는 각 프런트엔드/백엔드 서버의 구성 매개 변수를 보여 줍니다. 서버들은 sesta.com, siroe.com 그리고 varrius.com입니다. 기본 DWP 서버는 sesta.com입니다.

코드 예 3-3 각 프런트엔드/백엔드 서버의 LDAP CLD 구성 매개 변수

프런트엔드와 백엔드 서버 간의 보안 유지 관리

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

이 매개 변수는 선택 사항이며 기본적으로 ics.conf 파일에 포함되지 않습니다. DWP 연결에 대한 인증을 사용하려면 각 프런트엔드 및 백엔드 서버의 ics.conf 파일에 필수 매개 변수를 추가해야 합니다.

표 3-6 DWP 연결 인증을 위한 백엔드 구성 매개 변수
매개 변수	설명
service.dwp.admin.userid	백엔드 서버에서 DWP 연결을 인증하는 데 사용되는 사용자 아이디를 지정합니다. 백엔드 서버에서 사용자 아이디를 지정하지 않은 경우에는 인증이 수행되지 않습니다.
service.dwp.admin.cred	백엔드 서버에서 DWP 연결을 인증하는 데 사용되는 비밀번호를 지정합니다. 백엔드 서버에서 비밀번호를 지정하지 않는 경우에는 인증이 수행되지 않습니다.

표 3-7 DWP 연결 인증을 위한 프런트엔드 구성 매개 변수
매개 변수	설명
caldb.dwp.server.back-end-server.admin	프런트엔드 서버에서 백엔드 서버에 대한 DWP 연결을 인증하는 데 사용되는 사용자 아이디를 지정합니다. 여기서 back-end-server는 서버의 이름입니다.
caldb.dwp.server.back-end-server.cred	프런트엔드 서버에서 백엔드 서버에 대한 DWP 연결을 인증하는 데 사용되는 비밀번호입니다. 여기서 back-end-server는 서버의 이름입니다.

프론트엔드와 백엔드 서버 간의 DWP 연결 인증을 설정하려면 다음 단계를 수행합니다.

각 프런트엔드 서버의 ics.conf 파일에서 다음과 같은 매개 변수를 추가합니다.

caldb.dwp.server.back-end-server.admin = "userid"
caldb.dwp.server.back-end-server.cred = "password"

여기서 back-end-server는 백엔드 서버의 이름이며 userid와 password는 Calendar Server가 연결 인증에 사용할 사용자 아이디와 비밀번호입니다.

back-end-server로 표시되는 각 백엔드 서버의 ics.conf 파일에 다음 매개 변수를 추가합니다.

service.dwp.admin.userid = "userid"
service.dwp.admin.cred = "password"

여기서 userid 및 password는 프런트엔드 서버에서 지정한 사용자 아이디 및 비밀번호와 동일합니다.

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

이후 같은 프런트엔드 서버에서 연결될 때 다음 경우를 제외하고는 다시 인증할 필요가 없습니다.

백엔드 서버가 다시 시작한 경우

두 서버 간의 활동이 없어 세션이 만료된 경우

다중 프런트엔드 및 백엔드 서버가 있는 경우 각 서버에 동일한 사용자 아이디 및 비밀번호를 사용할 수 있습니다.

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

LDAP CLD 플러그 인 성능 향상

LDAP CLD 플러그 인의 Calendar Server 성능을 향상시키려면 다음 구성 매개 변수를 "yes" (각 매개 변수의 기본값)로 설정해야 합니다.

caldb.cld.cache.enable은 CLD 캐시 옵션을 활성화합니다. 이 옵션은 달력 사용자의 DWP 호스트 서버 정보(icsDWPHost LDAP 속성)를 저장하는 방법으로 LDAP 디렉토리 서버에 대한 호출을 줄입니다.

service.calendarsearch.ldap은 LDAP나 사용자 기본 설정 플러그 인을 사용하여 달력 검색을 수행하도록 지정합니다.

CLD 캐시 지우기

CLD 캐시 옵션을 사용하고 있으며 ics.conf 매개 변수의 서버 이름을 업데이트했거나 달력을 다른 백엔드 서버로 이동한 경우, 서버 이름을 제거하려면 CLD 캐시를 지워야 합니다. CLD 캐시에 이전 버전의 항목이 있으면 프런트엔드 서버가 정확한 백엔드 서버로 연결을 설정하지 못하게 되거나 Calendar Server가 옮겨진 후에 달력을 찾을 수 없게 됩니다.

Calendar Server를 중지합니다.

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

Calendar Server를 다시 시작합니다.

다른 백엔드 서버로 달력 이동

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

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

csuser disable bkamdar

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

csexport -c bkamdar calendar bkamdar.ics

사용자가 2개 이상의 달력을 갖고 있다면 각 달력마다 이 작업을 수행해야 합니다.

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

새 서버에서 csimport 유틸리티를 사용하여 파일에서 달력 데이터베이스로 달력을 가져옵니다. 예를 들면 다음과 같습니다.

csimport -c bkamdar calendar bkamdar.ics

역시 내보낸 달력 각각에 대해 이 단계를 수행해야 합니다.

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

csattribute -a icsDWPHost delete bkamdar
csattribute -a icsDWPHost=sesta.com add bkamdar

새 서버에서 사용자 달력의 경우 csuser 유틸리티를 사용하여, 자원 달력의 경우 csresource 유틸리티를 사용하여 달력 사용자를 사용 가능하게 합니다. 예를 들면 다음과 같습니다.

csuser enable bkamdar

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

cscal -v -o bkamdar list bkamdar
...
csattribute -v list bkamdar

원본 서버에서 방금 옮긴 각 달력을 삭제합니다 예를 들면 다음과 같습니다.

cscal -o bkamdar delete bkamdar

-o 옵션은 주 소유자가 bkamdar인 모든 달력을 삭제합니다.

LDAP 속성 관리

Calendar Server가 사용하는 LDAP 속성을 관리하려면 csattribute 유틸리티를 사용합니다.

LDAP 속성 나열


주	LDAP CLD 플러그 인을 사용하는 사이트인 경우에는 새 백엔드 호스트 서버를 지정하기 위해 csattribute를 사용하여 icsDWPHost 속성을 변경하지 마십시오. icsDWPHost를 변경하면 새 백엔드 호스트에 새 달력이 만들어지지 않습니다. 자세한 내용은 "LDAP 달력 조회 데이터베이스(CLD) 플러그 인 구성"을 참조하십시오.

사용자 또는 자원에 대한 LDAP 속성을 나열하려면 csattribute 유틸리티 add 명령을 사용합니다. 예를 들어, 사용자 TChang의 LDAP 속성을 나열하려면 다음 명령을 사용합니다.

LDAP 속성 추가

LDAP 서버에 속성을 추가하려면 csattribute 유틸리티 add 명령을 사용합니다. 예를 들어, LDAP 속성 icsCalendar를 Conference_Schedule이라는 값으로 TChang 사용자에게 추가하려면 다음 명령을 사용합니다.

LDAP 속성 삭제

LDAP 서버의 속성을 삭제하려면 csattribute 유틸리티 delete 명령을 사용합니다. 예를 들어, LDAP 속성 icsCalendar를 TChang으로부터 삭제하려면 다음 명령을 사용합니다.

그룹 예약 엔진(GSE) 대기열 관리

그룹 예약에서는 Calendar Server 사용자가 회의와 같은 이벤트를 만들고 다른 참석자를 초대할 수 있습니다. 사용자는 사용 가능/사용 중 조회 기능을 사용하여 초대 받은 사람이 언제 이벤트 참석이 가능한지 확인할 수 있습니다.

참석자가 같은 Calendar Server에 있을 경우 참석자의 달력에 이벤트가 예약됩니다. 같은 Calendar Server에 있지 않으면 전자 메일을 통해 초대가 보내집니다. 그러면 참석자는 초대를 받아들이거나 거절할 수 있습니다.

또한 Calendar Server 사용자는 참석자의 달력을 나란히 조회하면서 그룹 일정을 비교할 수 있습니다.

GSE 대기열의 항목을 관리하려면 csschedule 유틸리티를 사용합니다. Calendar Server가 설치된 로컬 시스템에서 csschedule을 실행해야 합니다.

GSE 대기열의 항목 나열

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

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

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

GSE 대기열의 항목 삭제

GSE 대기열에서 항목을 삭제하려면 csschedule 유틸리티 delete 명령을 사용합니다. 예를 들어, GSE 대기열의 모든 항목을 삭제하려면 다음 명령을 사용합니다.

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

Calendar Server 모니터링

Calendar Server 작동을 모니터하려면 csmonitor, csstats 및 cstool 유틸리티를 사용합니다. 이 절에서는 다음 작업을 설명합니다.

카운터 통계 나열

Calendar Server 로그 파일 모니터링

카운터 통계 나열

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

최대 동시 연결 수 및 전체 연결 수

전체 성공/실패한 로그인 및 연결 수

데이터베이스 읽기, 쓰기 및 삭제 수

통계 정보를 나열하려면 csstats 유틸리티 list 명령을 사용합니다. 예를 들어, 카운터 객체 및 사용 가능한 유형에 대한 기본 정보를 표시하려면 다음 명령을 사용합니다.

특별히 httpstat 카운터 객체에 대한 통계를 나열하려면 다음 명령을 사용합니다.

wcapstat 카운터 객체에 대한 통계를 1시간 동안 10초 간격으로 나열하려면 다음 명령을 사용합니다.

Calendar Server 로그 파일 모니터링

각 Calendar Server 서비스는 자체 로그 파일에 상태 정보를 기록합니다. 표 3-8과 같이 각 로그 파일은 해당 서비스 이름을 따라 명명됩니다.

표 3-8 Calendar Server 로그 파일
서비스 이름	로그 파일 이름
관리 서비스(csadmind),	admin.log
분산 데이터베이스 서비스(csdwpd)	dwp.log
HTTP 서비스(cshttpd)	http.log
알림 서비스(csnotifyd)	notify.log

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

각 로그 파일은 다음과 같이 구성 시간 및 크기 제한에 따라 새 이름의 새 로그 파일로 롤오버됩니다.

로그 이벤트 심각도 수준

Calendar Server는 표 3-9의 설명처럼 로그 파일에 보고된 이벤트에 대해 8가지 심각도 수준을 제공합니다.

표 3-9 Calendar Server 로그 오류 심각도 수준
심각도 수준	의미
긴급	시스템을 사용할 수 없습니다. 이 수준은 가장 높은(가장 심각한) 심각도의 이벤트를 나타냅니다.
경고	즉시 조치를 취해야 합니다.
심각	심각한 조건
오류	오류 조건
경고	경고 조건
알림	정상적이지만 통보 조건. 각 달력 서비스의 기본 보고 수준입니다.
정보	참조용
디버그	디버그 수준 메시지

로그 이벤트는 타임스탬프, 서버 호스트 이름, 심각도 수준, 프로세스 이름(프로세스 아이디), 이벤트 유형, 우선 순위 및 설명을 보여 주는 하나의 행으로 표시됩니다. ics.conf 파일의 특정 설정을 수정하는 방법으로 Calendar Server가 로그 파일에 보고하는 이벤트의 심각도 수준을 지정할 수 있습니다. 자세한 내용은 "달력 로그 정보 구성"을 참조하십시오.

정기적으로 로그 파일에서 긴급, 경고, 심각, 오류 및 경고 수준의 오류가 있는지 검사하고 그런 오류가 발견되면 해당 이벤트를 조사하여 Calendar Server 작업과 관련된 원인을 찾아야 합니다. 알림 및 정보 수준의 로그 이벤트는 정상적인 Calendar Server 작업 중에 발생하며 서버 작동을 모니터할 수 있도록 제공됩니다.


주	Calendar Server 기술 지원 요청 시 문제 해결에 도움이 될 로그 파일을 제공해야 하는 경우가 있습니다.

Calendar Server 핑(ping)

Calendar Server 서비스가 지정된 포트 번호를 수신 중인지 확인하려면 cstool 유틸리티 ping 명령을 사용합니다. 서비스 핑으로 해당 서비스가 실제 실행 중인지 확인할 수는 없지만 소켓 연결을 받아들일 수 있는지 여부를 알려 줍니다.

http - HTTP 서비스(cshttpd)

admin - 관리 서비스(csadmind)



주	현재 릴리스에서는 DWP 서비스(csdwpd), 이벤트 알림 서비스(enpd) 또는 알림 서비스(csnotifyd)를 핑할 수 없습니다.

예를 들어, 호스트 이름이 calserver인 시스템을 핑하여 cshttpd 서비스가 포트 80을 수신하는지 확인하려면 다음 명령을 사용합니다.

기본적으로 cstool은 응답이 올 때까지 120초 동안 대기하지만 -t timeout 옵션을 사용하여 값을 변경할 수 있습니다.

Calendar Server 구성 갱신

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