Calendar Server 6.3에는 다음 변경 사항 및 새로운 기능이 포함되어 있습니다.
comm_dssetup.pl: Calendar Server 6.3에서 비밀번호 파일의 새 옵션을 통해 보안 향상
Calendar Server 6.3 유틸리티 csdb, cscal 및 csuser가 cal/sbin으로 이동
이전에는 Delegated Administrator 콘솔이 아니라 Delegated Administrator 유틸리티를 사용하여 스키마 2에 대해 Calendar Server를 관리할 수 있었습니다. 이 릴리스 이전에 콘솔은 Messaging Server만 관리하는 데 사용하는 웹 그래픽 사용자 인터페이스였습니다. 이제는 달력 LDAP 항목을 관리하는 데에도 콘솔을 사용할 수 있습니다. 콘솔을 사용하여 달력 사용자, 그룹, 자원 및 도메인에 대한 LDAP 항목을 추가하거나 삭제 또는 수정할 수 있습니다. Calendar Server 지원을 위해 새 화면과 메뉴 항목이 콘솔에 추가되었습니다. 인터페이스 사용 방법에 대한 자세한 내용은 Delegated Administrator 온라인 도움말을 참조하십시오. 일부 정보는 Sun Java System Calendar Server 6.3 Administration Guide에서 확인할 수도 있습니다.
첨부 파일 지원을 위해 WCAP 명령에 새로운 매개 변수와 값이 추가되었습니다.
범용 웹 클라이언트(Communications Express) 및 Connector for Microsoft Outlook 사용자는 이벤트와 작업에 첨부 파일을 배치하거나 초대와 함께 첨부 파일을 보낼 수 있습니다.
첨부 파일을 지원하기 위해 WCAP에 다음과 같은 변경 사항이 적용되었습니다.
fetchattachment.wcap: 첨부 파일을 쉽게 가져올 수 있도록 새 명령이 추가되었습니다. 첨부 파일만 가져오며 이벤트나 작업 데이터는 가져오지 않습니다.
deleteattach: storeevents 명령에 새로 추가된 인수로 이벤트나 작업 자체는 삭제하지 않고 기존 첨부 파일을 삭제하는 데 사용됩니다.
fetchattach: 이벤트 및 작업 데이터뿐 아니라 첨부 파일도 반환할 수 있도록 모든 fetch_by_* 명령에 새로 추가된 매개 변수입니다.
sendattach: storeevents 명령에 새로 추가된 매개 변수로 iTIP 초대와 함께 실제 첨부 파일을 보낼지 여부를 지정하는 데 사용됩니다.
X-S1CS-CLIENT-ATTACH-ID: 첨부 파일의 고유 아이디가 들어 있는 X-Token입니다. 이 X-Token은 첨부 파일을 저장할 때 클라이언트가 첨부 파일 아이디를 제공한 경우에만 생성됩니다. 그렇지 않으면 실제 첨부 파일이 이벤트와 함께 전송됩니다.
storeevents 및 storetodos 명령의 더 이상 사용되지 않는 attachments 인수는 Calendar Server 데이터 저장소의 외부에 저장된 첨부 파일에 대한 URL 참조를 저장할 수 있습니다. 이와 같이 첨부 파일을 사용하는 방법은 이전 버전과의 호환성을 위해 이 릴리스에서는 유지되지만 이후 릴리스에서는 배포에서 제거됩니다.
첨부 파일에 대한 자세한 내용은 Sun Java System Calendar Server 6.3 WCAP Developer’s Guide를 참조하십시오.
이제 Delegated Administrator를 사용하여 LDAP 그룹을 만들 수 있습니다. 이러한 그룹은 다음과 같은 기능을 갖습니다.
그룹은 사용자의 목록입니다. 그룹은 목록에 있는 사용자를 "포함"하지는 않습니다. 그룹은 컨테이너가 아닙니다.
그룹은 그룹 달력을 가질 수 있습니다.
그룹에 전송된 초대는 그룹 달력뿐 아니라 모든 구성원의 달력에 배치됩니다.
그룹의 모든 구성원은 그룹 달력에 대한 동일한 액세스 권한을 공유합니다.
그룹 달력의 주 소유자는 없습니다.
Calendar Server 소프트웨어의 초기 버전에서는 도메인 구조가 없었습니다. 모든 사용자 및 그룹 LDAP 레코드는 루트 아래에 있었습니다. 이후 버전에서는 호스트된 도메인 또는 가상 도메인과 같이 다양한 하나 이상의 도메인을 설정하도록 선택할 수 있게 되었습니다. Calendar Server 6.3 소프트웨어의 릴리스에서는 모든 설치에서 기본적으로 다중 도메인 모드를 사용해야 합니다. 즉, 루트 도메인 아래에 적어도 하나의 기본 도메인이 있어야 합니다. 모든 사용자 및 그룹 LDAP 항목이 이 기본 도메인 아래에 있어야 하며 더 많은 도메인을 설정하도록 선택할 수 있습니다. 다중 도메인 모드에서 각 정규 도메인은 고유한 사용자 및 그룹 아이디를 포함해야 합니다. 다중 도메인에 대한 자세한 내용은 Sun Java System Calendar Server 6.3 관리 설명서(특히 Sun Java System Calendar Server 6.3 Administration Guide의 10 장, Setting Up a Multiple Domain Calendar Server 6.3 Environment)를 참조하십시오.
런타임 환경을 제공하기 위해 실행해야 하는 csconfigurator.sh 구성 프로그램은 기본 도메인의 이름을 묻는 메시지를 표시합니다. 기본 도메인이 없으면 프로그램에서 자동으로 도메인을 만듭니다.
이전 Calendar Server 배포에서 다중 도메인을 사용하지 않았거나 단일 도메인만 사용한 경우 사용자 및 그룹 LDAP 레코드를 새 기본 도메인 아래로 이동해야 합니다.
스키마 버전 2 환경에서 추가 도메인을 만들려면 Sun Java System Delegated Administrator 콘솔 또는 유틸리티를 사용합니다. Delegated Administrator에 대한 자세한 내용은 Sun Java System Delegated Administrator 6.4 관리 설명서를 참조하십시오.
스키마 버전 1을 사용하고 있고 스키마 버전 2로 마이그레이션하지 않을 경우 Calendar Server 유틸리티 csdomain을 사용하여 추가 도메인을 만들 수 있습니다.
구성 프로그램에 다음과 같은 화면이 추가되었습니다.
이번 릴리스부터는 루트 아래에 항상 최소한 하나의 도메인이 있으며, 이 도메인이 기본 도메인이 됩니다. 이제 구성 프로그램에서 다중 도메인 환경에 대한 기본 도메인의 이름을 지정할 수 있습니다.
이제 DWP 프로토콜과 CLD 플러그 인을 사용하는 분산 데이터베이스 환경에 대해 프런트엔드 및 백엔드 시스템의 이름을 지정할 수 있습니다. 달력 데이터베이스를 하나 이상의 백엔드 시스템에 배포하고 이러한 시스템을 하나의 프런트엔드 시스템에 연결할 수 있습니다. 새 구성 프로그램 화면을 사용하여 백엔드 시스템의 이름을 지정한 다음 이 시스템을 프런트엔드 시스템에 연결할 수 있습니다.
기본 도메인 화면에 달력 수퍼유저(calmaster)의 전자 메일 주소를 입력할 수 있는 새 필드가 추가되었습니다.
반복 이벤트의 경우 참석자에게 전송되는 전자 메일 초대에는 이제 반복 세부 정보가 포함됩니다.
이제 csstored 데몬이 다양한 Calendar Server 데이터베이스를 관리합니다. 저장소에 액세스하는 각 서비스는 이 저장소 서비스가 성공적으로 시작된 경우에만 사용할 수 있으므로 Calendar Server 시스템이 실행 중일 때 저장소가 모든 서버(프런트엔드 및 백엔드)에서 계속 실행 중이어야 합니다. 다른 데몬과 마찬가지로 일반 시작 및 종료 명령(start-cal 및 stop-cal)을 사용하여 csstored를 시작 및 중지합니다.
이전 버전에서는 자동 백업을 구성하지 않을 경우 PERL 스크립트 csstored.pl을 실행할 필요가 없었습니다. 이 스크립트는 필요에 따라 시작하고 중지할 수 있었습니다. 이러한 PERL 스크립트는 더 이상 지원되지 않으며 대신 csstored 데몬이 사용됩니다. 자동 백업을 구성할지의 여부에 관계없이 이 데몬 실행은 더 이상 선택 사항이 아닙니다.
이전에는 ics.conf 매개 변수 local.store.enable을 "no"로 설정하여 스크립트 실행을 비활성화할 수 있었습니다. 하지만 이제는 local.store.enable을 "yes"(기본값)로 설정하여 csstored를 항상 활성화된 상태로 유지해야 합니다.
Calendar Server와 Messaging Server는 이제 동일한 중지 및 시작 메커니즘을 사용합니다. start-cal 명령은 watcher 프로세스를 시작한 다음 다른 모든 프로세스를 시작합니다. watcher 프로세스는 다른 서비스 간의 종속성을 인식하며 이 순서대로 서비스가 시작됩니다.
등록된 각 서비스(프로세스)는 관찰자에 연결합니다. 연결을 제대로 끊지 않고 프로세스가 종료되면 관찰자는 자동으로 이 프로세스를 다시 시작합니다. 정의된 간격 내에 프로세스가 두 번 종료되면 관찰자는 프로세스를 다시 시작하지 않습니다. 이 시간 초과 간격을 직접 구성할 수 있습니다.
관찰자에 대한 추가 내용은 다음을 참조하십시오.
관찰자는 관찰자에 등록된 모든 서비스를 모니터링합니다. Calendar Server의 경우 등록된 프로세스는 cshttpd, csadmind, csdwpd, csnotifyd 및 csstored입니다.
csstored 데몬을 활성화해야 합니다. 구성 매개 변수 local.store.enable을 "y"로 설정하십시오. 이전 버전의 Calendar Server에서는 csstored를 활성화하는 작업이 선택 사항이었지만 이번 버전에서는 필수 사항입니다. csstored 데몬이 성공적으로 시작되어야 저장소에 액세스하는 각 서비스가 시작할 수 있습니다. 이 프로세스가 중지되면 종속 프로세스도 중지한 다음 다시 시작해야 합니다.
관찰자는 기본적으로 활성화되어 있습니다. 관찰자 프로세스를 관리하기 위해 ics.conf 파일에 다음과 같은 새 매개 변수가 추가되었습니다.
local.watcher.enable = "y": 시작 프로그램(csservice)이 다른 서비스를 시작하기 전에 관찰자를 시작하려고 합니다. 이 매개 변수를 "n"으로 설정하면 관찰자 프로그램이 비활성화됩니다.
service.autorestart = "y": 관찰자가 중지된 서비스를 자동으로 다시 시작합니다. "n"으로 설정하면 관찰자는 중지된 서비스를 다시 시작하지 않습니다. 이 매개 변수를 "n"으로 설정해도 관찰자는 서비스를 모니터링하고 실패 또는 무응답 오류 메시지를 콘솔 및 cal-svr-base/data/log 파일에 전송합니다.
local.autorestart.timeout = "600": 두 번째 서버 오류로 인해 관찰자가 다시 시작 시도를 중지하도록 트리거되는 기본 시간입니다.
local.watcher.port: 기본 포트는 "49994"이지만, Messaging Server를 사용하는 경우 이 서버도 또한 이 포트를 통해 수신하므로 Calendar Server와 충돌하게 됩니다. 충돌이 발생하지 않도록 하려면 관찰자가 다른 포트를 수신하도록 선택하는 것이 안전합니다.
관찰자는 cal-svr-base/data/log/watcher.log라는 단일 로그에 기록합니다. 이 로그에는 다음과 같은 정보가 포함되어 있습니다.
관리 콘솔로 전송된 실패 알림 및 무응답 오류 메시지
모든 서버 중지 및 시작에 대한 레코드
시간 초과 기간 내에 서버가 두 번 실패하면 시스템은 서버 다시 시작 시도를 중지합니다. HA 시스템에서는 Calendar Server가 종료되고 다른 시스템으로의 페일오버가 발생합니다.
csservice의 공용 인터페이스는 start-cal 및 stop-cal입니다. 이 절에서는 이러한 각 래퍼 스크립트의 사용법을 보여 주고 각 옵션에 대한 설명과 시작 또는 중지할 구성 요소 목록을 제공합니다.
start-cal 사용법은 다음과 같습니다.
./start-cal [options...] [components...]
다음은 옵션 목록입니다.
이 도움말 목록을 표시합니다.
디버깅 모드를 활성화합니다.
사용중인 서비스를 나열합니다.
활성화된 서비스를 나열합니다.
모든 서비스를 나열합니다.
다음은 구성 요소 목록입니다.
watcher |
ens |
store |
notify |
admin |
http |
dwp |
구성 요소를 나열하지 않으면 start-cal은 활성화된 모든 서비스를 시작합니다.
stop-cal 사용법은 다음과 같습니다.
./stop-cal [options...] [components...]
다음은 옵션 목록입니다.
이 도움말 목록을 표시합니다.
디버깅 모드를 활성화합니다.
SIGKILL 사용을 강제로 중지합니다. 이 옵션은 UNIX® 플랫폼에서만 작동합니다.
다음은 구성 요소 목록입니다.
watcher |
mfagent |
ens |
store |
notify |
admin |
http |
dwp |
구성 요소를 나열하지 않으면 stop-cal은 활성화된 모든 서비스를 중지합니다.
이 절에서는 Calendar Server에서 모니터링 프레임워크를 구현하는 방법을 설명하며 다음과 같은 항목을 다룹니다.
Java Enterprise System Monitoring Framework에 대한 자세한 내용은 Sun Java Enterprise System 5 Monitoring Guide를 참조하십시오.
Calendar Server와 Messaging Server는 Java Enterprise System용 모니터링 프레임워크에 최소한으로 통합됩니다. 모니터링 프레임워크는 실행 중에 operationalStatus 속성을 주기적으로 확인합니다. 이 속성의 상태는 OK(시스템이 실행 중임을 의미) 또는 DOWN(시스템이 실행 중이 아님을 의미)일 수 있습니다.
새 프로세스인 모니터링 프레임워크 에이전트(csmfagent)는 시스템 시작(start-cal)과 함께 시작됩니다. 이 프로세스는 첫 번째로 시작되는 프로세스입니다. 이 프로세스는 응용 프로그램을 인스턴스화하고 상태를 OK라고 가정합니다. 또한 SIGTERM을 찾아내고 찾아내는 동시에 상태를 DOWN으로 가정하고 종료됩니다.
이와 비슷하게 관찰자가 구성되어 실행 중인 경우 시스템의 일부가 실패하거나 응답하지 않으면 관찰자는 SIGTERM 신호를 보내고 이는 csmfagent를 중지합니다.
다음 매개 변수를 포함하도록 구성 파일 ics.conf를 편집합니다.
local.csmfagent.enable = "y"
다음 두 단계를 수행합니다.
/opt/SUNWcsgar/config/com.sun.cmm.cs.xml을 /opt/SUNWmfwk/xml에 복사합니다.
제조 프레임워크 프로세스를 중지했다가 다시 시작합니다.
모니터링 프레임워크를 사용하기 위한 두 가지 요구 사항은 다음과 같습니다.
JESMF(Java Enterprise System Monitoring Framework)를 설치해야 합니다.
JESMF가 설치되어 있지 않으면 csmfagent가 실행되지 않습니다.
Calendar Server가 필요한 라이브러리를 찾을 수 있어야 합니다.
Calendar Server는 /opt/SUNWics5/lib에서 심볼릭 링크를 사용하여 라이브러리를 찾습니다.
다음은 JESMF 라이브러리입니다.
/opt/SUNWmfwk/lib/libMfTransaction.so |
/opt/SUNWmfwk/lib/libMfRelations.so |
/opt/SUNWmfwk/lib/libMflog4c.so |
/opt/SUNWmfwk/lib/libMfMEServer.so |
/opt/SUNWmfwk/lib/libmfBeepConnectorServer.so |
/opt/SUNWmfwk/lib/libMfRserver.so |
/opt/SUNWmfwk/lib/libMfMEInstrum.so |
/opt/SUNWmfwk/lib/libMfDiscovery.so |
/opt/SUNWmfwk/lib/libMfHashTable.so |
/opt/SUNWmfwk/lib/libMflog.so |
/opt/SUNWmfwk/lib/libasn1cebuf.so |
/opt/SUNWmfwk/lib/libbeepcore.so |
/opt/SUNWmfwk/lib/libbeepxmlutil.so |
/opt/SUNWmfwk/lib/libbptostransport.so |
/opt/SUNWmfwk/lib/libbptosutil.so |
/opt/SUNWmfwk/lib/libbptoswrapper.so |
/opt/SUNWmfwk/lib/libbputil.so |
/opt/SUNWmfwk/lib/libcmm_native.so |
/opt/SUNWmfwk/lib/libmfCserver.so |
/opt/SUNWmfwk/lib/libmfNotificationProfile.so |
/opt/SUNWmfwk/lib/libmfRequestResponseProfile.so |
/opt/SUNWmfwk/lib/libmfTimers.so |
/opt/SUNWmfwk/lib/libmfTimersJNI.so |
/opt/SUNWmfwk/lib/libmfUtils.so |
/opt/SUNWmfwk/lib/libmfber.so |
/opt/SUNWmfwk/lib/libmfberj.so |
/opt/SUNWmfwk/lib/libxmlglobal.so |
이는 모든 JESMF 라이브러리의 목록입니다. 모니터링 프레임워크의 Calendar Server 부분을 구현하는 데 이 중 일부는 필요하지 않을 수도 있습니다.
이 릴리스에는 이벤트 알림과 경보를 위한 두 가지 알림 서비스인 Sun JMQ(Java System Message Queue) 및 ENS(Event Notification System)가 있습니다. 이후 릴리스부터 Communications Services 제품은 JMQ를 단독으로 사용하고 ENS는 제거될 것입니다. 그러나 이번 릴리스에서 Communications Services 제품(Messaging Server, Calendar Server 및 Instant Messaging)은 ENS에 대해 내부적으로 종속되어 있으며, 알림 및 경고를 위해 ENS를 사용할 수 있습니다.
ENS 대신 JMQ를 사용하려면 Sun Java System Message Queue를 설치하고 구성해야 합니다. 또한 Calendar Server 6.3에서는 알림이 제공되지 않으므로 알림을 직접 작성해야 합니다.
Sun Java Enterprise System 설치 프로그램을 사용하여 제품을 설치합니다. Message Queue 구성에 대한 자세한 내용은 Message Queue 설명서(http://docs.sun.com/coll/1307.2 및 http://docs.sun.com/coll/1406.2)를 참조하십시오.
JMQ에 대해 Calendar Server를 구성하려면 ics.conf 파일에 다음 줄을 추가해야 합니다.
local.server.csmfagent.enable = "yes"
caldb.serveralarms.jmqlib = "/opt/SUNWics5/cal/lib/libmqcrt.so" (Solaris의 경우)
또는
caldb.serveralarms.jmqlib = "/opt/sun/calendar/lib/libmqcrt.so" (Linux의 경우)
caldb.serveralarms.dispatchtype = "jmq"
caldb.serveralarms.jmqhost = "localhost"
caldb.serveralarms.jmqport = "7676"
caldb.serveralarms.jmqUser = "guest"
caldb.serveralarms.jmqPWD = "guest"
caldb.serveralarms.jmqTopic = "JES-CS"
각 알림에는 MQ_MESSAGE_TYPE_HEADER_PROPERTY 등록 정보가 있어야 합니다. 이 등록 정보는 알림의 종류를 식별합니다.
또한 알림은 다음 표와 같은 다른 등록 정보를 가질 수 있습니다.
이 알림이 생성하는 작업의 유형을 나타내는 문자열 등록 정보입니다. 이 등록 정보의 값은 "EMAIL", "AUDIO", "DISPLAY", "PROCEDURE", "FLASHING"일 수 있습니다.
경고 ID를 포함하는 문자열 등록 정보입니다.
달력 ID를 포함하는 문자열 등록 정보입니다.
구성 요소의 유형을 나타내는 문자열 등록 정보입니다. 값은 "event" 또는 "todo"입니다.
반복 ID를 포함하는 정수 등록 정보입니다.
구성 요소 ID(즉, 이벤트 ID 또는 수행할 작업 ID(작업 ID))를 포함하는 문자열 등록 정보입니다.
알림의 유형에는 이벤트 및 수행할 작업에 대한 경고 알림 및 업데이트 알림이 있습니다.
경고 알림의 경우 MQ_MESSAGE_TYPE_HEADER_PROPERTY의 값은 "alarm"입니다.
업데이트 알림의 경우 MQ_MESSAGE_TYPE_HEADER_PROPERTY의 값은 알림을 트리거한 작업 유형에 따라 다릅니다. 표 2–2에는 트리거 작업과 이 등록 정보에 해당하는 값이 나열되어 있습니다.
표 2–2 업데이트 알림 값
트리거 |
업데이트 알림 값 |
---|---|
달력 삭제 |
DELETECAL |
이벤트 수정 |
MODIFYEVENT |
수행할 작업(작업) 수정 |
MODIFYTODO |
이벤트 만들기 |
CREATEEVENT |
수행할 작업(작업) 만들기 |
CREATETODO |
이벤트 새로 고침 |
REFRESHEVENT |
수행할 작업(작업) 새로 고침 |
REFRESHTODO |
이벤트에 응답 |
REPLYEVENT |
수행할 작업에 응답 |
REPLYTODO |
이제 참석자가 초대에 응답하면 주최자에게 전자 메일 알림을 보낼 수 있습니다.
ics.conf 매개 변수를 ine.reply.enable로 설정하여 이 기능을 구성합니다. 전체 시스템에 대해 이 기능을 활성화하려면 이 매개 변수를 "y"로 설정합니다. 이 기능을 비활성화하려면 매개 변수를 "n"으로 설정합니다. 이 기능은 기본적으로 활성화됩니다.
응답 유형에는 수락, 거절, 임시 수락의 세 가지가 있습니다. 알림은 응답이 단일 초대에 대한 것인지 반복 이벤트에 대한 것인지 여부를 나타냅니다. 다음과 같은 새로운 메시지 형식 파일 매개 변수가 추가되었으며 해당하는 형식 파일도 추가되었습니다.
calmail.imipeventacceptnotification.fname= "mail_eventacceptnotification.fmt"
calmail.imipeventdeclinenotification.fname= "mail_eventdeclinenotification.fmt"
calmail.imipeventtentativeacceptnotification.fname= "mail_eventtentativeacceptnotification.fmt"
calmail.imipeventacceptnotificationrecur.fname= "mail_eventacceptnotificationrecur.fmt"
calmail.imipeventdeclinenotificationrecur.fname= "mail_eventdeclinenotificationrecur.fmt"
calmail.imipeventtentativeacceptnotificationrecur.fname= "mail_eventtentativeacceptnotificationrecur.fmt"
이 기능은 사용자 기본 설정이 아닙니다. 즉, 시스템 전체 구성 매개 변수이므로 초대를 보내는 모든 사용자에게 적용됩니다.
전자 메일 알림에 대해 Calendar Server를 구성하는 방법에 대한 자세한 내용은 Sun Java System Calendar Server 6.3 Administration Guide의 To Enable Email Notifications을 참조하십시오.
요약 및 설명 필드를 포함하여 참석자의 달력 이벤트 복사본을 수정할 수 있도록 WCAP 인터페이스가 변경되었습니다.
Calendar Server 6.3 유틸리티 rename은 달력 데이터의 이름을 바꿀 때 삭제된 항목을 포함합니다.
거절한 이벤트는 더 이상 사용 가능-사용 중 달력에서 사용 중으로 표시되지 않습니다.
이전 버전의 Calendar Server에서는 Calendar Express(이전 사용자 인터페이스)가 자동으로 설치되어 활성화되었습니다. 이 인터페이스를 사용하지 않는 경우에도 비활성화할 수 없었습니다. Calendar Server 6.3으로 업그레이드하는 경우 업그레이드 프로세스 중에 ics.conf 파일에 service.http.ui.enable="y"가 추가됩니다. 이 버전에서는 이전 UI를 사용하려는 경우 활성화된 상태로 유지되므로 별도의 추가 작업이 필요하지 않습니다.
Calendar Express를 비활성화하려면 ics.conf 파일에서 service.http.ui.enable 값을 "n"으로 설정합니다.
Calendar Express는 새로 설치할 때 더 이상 자동으로 설치되지 않습니다. Calendar Server 6.3을 새로 설치하지만 Calendar Express를 사용자 인터페이스로 사용하려면 Communications Suite 5 설치 프로그램을 사용하여 Calendar Express를 명시적으로 설치해야 합니다. 그런 다음 ics.conf 파일에 service.http.ui.enable="y"를 추가하여 Calendar Express를 구성해야 합니다. 새로 설치에 대한 기본 내부 설정은 "n"이므로 이 설정을 "y"로 명시적으로 설정해야 합니다.
이전 버전의 Calendar Server를 업그레이드할 경우 업그레이드 과정에서 이 값을 "y"로 설정하여 ics.conf에 추가하므로 어떠한 변경 작업 없이 레거시 사용자 인터페이스를 계속해서 사용할 수 있습니다. 이 사용자 인터페이스를 비활성화하려면 이 매개 변수를 "n"으로 설정합니다.
이전에는 분산 데이터베이스 환경(DWP와 CLD 플러그 인 사용)의 경우 빅 엔디언(big endian)-리틀 엔디언(little endian) 문제로 인해 프런트엔드 및 백엔드 프로세스를 동일한 하드웨어 플랫폼에 설치해야 했습니다. 이제 더 이상 이렇게 하지 않아도 됩니다. 이제 프런트엔드 및 백엔드 프로세스를 서로 다른 하드웨어 플랫폼에 설치할 수 있습니다.
예를 들어, 프런트엔드 시스템은 X-86 플랫폼 시스템인 반면 백엔드 시스템은 SPARC 플랫폼 시스템일 수 있습니다.
Calendar Server에서 보낸 메시지는 이제 iTIP와 호환됩니다(Microsoft Outlook 상호 운용성).
이제 보안 향상을 위해 comm_dssetup.pl을 실행할 때 텍스트 비밀번호 대신 비밀번호 파일을 지정할 수 있습니다. 새로운 -j <passwordfilename> 옵션을 사용하여 비밀번호를 보호하고 보안을 향상시킬 수 있습니다. 이 옵션은 특히 스크립트에 유용합니다. 현재 비밀번호를 표시하는 스크립트가 있는 경우 스크립트를 변경하려면 -w < password> 옵션을 삭제한 다음 이 새 옵션으로 대체합니다.
이는 #6392093 문제에 대한 해결책입니다.
이전 버전의 Calendar Server에서 csdb, cscal 및 csuser는 cal/bin 디렉토리에 있었지만 이제는 cal/sbin 디렉토리에 있습니다.
Calendar Server 프로그램 코드의 변경으로 인해 ics.conf 파일이 다음과 같이 변경되었습니다.