이 절에는 Calendar Server 6.3 릴리스 당시 알려진 중요한 문제점이 나열된 표가 포함되어 있습니다.
현재 다음과 같은 제한 사항이 알려져 있습니다.
이전 버전의 Calendar Server를 Calendar Server 6.3으로 업그레이드한 후 발생한 고가용성 문제
업그레이드 후 "확인할 수 없는 백엔드 호스트입니다." 오류 메시지가 나타나면서 Linux 플랫폼에 로그인할 수 없습니다.
고가용성 기능을 사용하는 경우(Calendar Server HA 패키지 SUNWcsics 사용), 이전 버전의 Calendar Server를 Calendar Server 6.3 버전으로 업그레이드한 후 문제 6560681을 방지하기 위해 다음 해결 방법을 수행해야 합니다.
해결 방법:
Calendar Server 6.3과 함께 제공된 SUNWscics 패키지를 수동으로 제거합니다.
pkgadd를 사용하여 Java Enterprise System 소프트웨어에 번들로 제공된 SUNWscics 패키지를 추가합니다.
DWP 프로토콜을 사용해야 하는 프런트엔드 및 백엔드 서버에서 Calendar Server를 배포할 경우 구성 프로그램에 백엔드 서버의 호스트 이름을 추가할지를 묻는 메시지가 표시됩니다. 이 값을 ics.conf 매개 변수 caldb.dwp.server.hostname.ip에 저장할 경우 정규화된 호스트 이름 대신 IP 주소로 저장됩니다. 그러면 시스템에서 백엔드 서버를 찾을 수 없습니다.
해결 방법: IP 주소를 정규화된 백엔드 서버 호스트 이름으로 대체합니다. 그렇게 하려면 텍스트 파일인 ics.conf 파일을 편집하면 됩니다.
프런트엔드 및 백엔드 서버를 구성하는 데 사용되는 매개 변수에 사용할 값에 대한 정확한 지침은 Sun Java System Calendar Server 6.3 Administration Guide의 5 장, Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3을 참조하십시오.
이 문제는 이 릴리스 노트의 다음 절에 문제 번호 6542989로 보고되어 있습니다. Calendar Server 6.3의 보고된 문제 .
Linux 운영 체제에서 Calendar Server 6.3으로 업그레이드한 후 start-cal을 실행하면 http.log 파일에 다음과 같은 오류 메시지가 표시됩니다.
cshttpd[2984]: General Error: caldb: caldb_pvt_isLocalUrl: hostname of hostname.xyz.com is not resolvable. Please check that hostname is correct and that hostname resolver is correct.
로그인하려고 하면 다음과 같은 오류 메시지가 표시됩니다.
Backend Host Unresolvable Please try again
해결:이 문제는 Calendar Server 6.3 업데이트 1, 패치 번호 121658-17에서 해결되었습니다.
이 문제는 다음 절의 문제 번호 6516438과 동일합니다. Calendar Server 6.3의 보고된 문제 .
구성 파일 ics.conf에서는 중복 매개 변수가 허용됩니다. 이로 인해 매개 변수 값 사이에 혼동이 있을 수 있습니다. 시스템에서 사용하는 매개 변수의 인스턴스를 확인하려면 파일의 마지막 인스턴스를 찾습니다. 시스템은 파일을 처리할 때 매개 변수의 마지막으로 찾은 인스턴스의 값을 사용합니다.
유용한 정보: ics.conf 파일 끝의 # My Parameter Changes와 같은 레이블이 지정된 섹션에 모든 변경 사항을 추가합니다. 변경 내역을 유지하려면 변경 이유를 설명하는 주석과 날짜를 추가합니다.
더 이상 사용되지 않는 이전 변경 사항을 설명하는 주석을 주기적으로 제거합니다. 변경 내역을 유지하지 않으려면 파일의 최신 변경 사항만 남겨두고 사용되지 않는 이전 중복은 삭제합니다.
이 버전에서는 패키지화의 사전 처리 단계에서 XSL 파일의 문자열 대체가 더 이상 수행되지 않습니다. 따라서 문자열이 실시간으로 대체되므로 Calendar Express 사용자 인터페이스의 성능이 저하됩니다.
해결 방법: Calendar Server를 실행하기 전에 모든 XSL 파일을 처리하고 올바른 언어 문자열을 수동으로 삽입하여 문자열 대체를 수행할 수 있습니다. 대체를 수행하려면 {CAL_SERVER_BASE}/tools/unsupported/bin 디렉토리에 있는 Perl 스크립트(xslvarparser.pl)를 추가해야 합니다. 스크립트 실행 지침은 스크립트 자체에 제공됩니다.
스크립트에 제공되는 지침은 다음과 같습니다.
Perl 스크립트 xslvarparser.pl을 사용하여 XSL 파일의 변수를 대체하여 XSL 렌더링 속도를 높입니다.
이 파일을 /opt/SUNWics5/cal/html 디렉토리에 복사합니다(Solaris의 경우 기본적으로 수행).
그런 다음 $ perl xslvarparser.pl로 실행합니다.
결과 파일은 각 로켈의 out 디렉토리 아래에 배치됩니다.
각 로켈의 XSL 파일을 out 디렉토리의 파일로 대체합니다.
이 대체를 수행하기 전에 원본 파일을 저장하는 것이 좋습니다.
이 문제는 Calendar Server 6.3의 보고된 문제 의 문제 번호 6385495에서 설명된 것과 동일합니다.
각 set_userprefs 명령은 다중 값 기본 설정의 하나의 인스턴스만 제거합니다.
해결 방법: 다중 값 사용자 기본 설정의 모든 인스턴스를 제거하려면 인스턴스당 하나의 set_userpref 명령을 실행해야 합니다.
예를 들면 다음과 같습니다. get_userprefs를 수행하여 모든 사용자 기본 설정을 나열합니다. icsSubscribed와 같이 기본 설정에 여러 개의 값이 있는 경우 하나의 set_userprefs 명령을 실행하여 나열된 각 값의 기본 설정을 삭제해야 합니다.
클러스터의 각 노드에 설치된 항목을 보여주는 클러스터 특정 showrev 명령은 없습니다. (이 문제는 Calendar Server에만 해당되는 것이 아닌 일반적인 문제입니다. 전역 파일 시스템에 설치된 모든 제품에 동일한 문제가 있습니다.)
이것은 Calendar Server를 업데이트하려 할 때의 문제입니다. Calendar Server가 설치된 모든 노드에 패치를 적용해야 합니다. 또한 Calendar Server가 미리 설치되지 않은 경우 노드에 패치를 적용할 수 없습니다. Calendar Server가 설치된 노드와 설치되지 않은 노드를 알 수 없는 경우 혼동이 생기고 Calendar Server가 설치된 노드를 찾는 데 시간이 많이 소비됩니다.
해결 방법: Calendar Server가 설치된 모든 노드를 보려면 다음 명령을 실행하십시오. pkgparam -v SUNWics5 | grep ACTIVE_PATCH
팝업 차단기를 활성화한 경우 특정 Calendar Server 창이 표시되지 않습니다.
해결 방법: 모든 Calendar Server 창이 표시되도록 Calendar URL에 대해 팝업 차단기를 비활성화하십시오.
예외:Norton Inet Security AD_BLOCKER 및 Mozilla 내장 POP_BLOCKER는 Calendar Server 창에 영향을 주지 않습니다.
csuser 유틸리티에서 주소록에 대해 사용자를 만들 수 없습니다.
해결 방법: Enable the user using ldapmodify.
구성 프로그램 csconfigurator.sh는 하나의 도메인만 구성합니다.
해결 방법: 다중 도메인 달력 환경(가상 도메인 또는 호스트된 도메인이라고 함)이 필요한 경우 다음 두 가지를 수행해야 합니다.
호스트된 도메인을 활성화합니다.
Delegated Administrator를 사용하거나 아직 Sun LDAP 스키마 1을 사용하는 경우 csdomain 유틸리티를 사용하여 도메인을 직접 추가합니다.
Sun Java System Calendar Server 6.3 Administration Guide의 10 장, Setting Up a Multiple Domain Calendar Server 6.3 Environment 및 Sun Java System Calendar Server 6.3 Administration Guide의 13 장, Administering Calendar Server Domains를 참조하십시오.
(문제 번호 4777792) 캐시가 가득 차서 오류가 발생합니다. Calendar Server가 LDAP 캐시 데이터를 만료시키지 않습니다.
해결 방법: 주기적으로 파일 내용을 제거합니다. 그런 다음 Calendar Server를 다시 시작합니다.
구성 파일에서 호스트 이름을 두 번 묻습니다. 한 번은 정규화된 호스트 이름이고 다른 한 번은 정규화되지 않은 호스트 이름입니다. 예를 들면 다음과 같습니다.
caldb.dwp.server.skate.red.sesta.com.ip = "skate.red.sesta.com" caldb.dwp.server.skate.ip = "skate" caldb.dwp.server.test12.red.sesta.com.ip = "test12.red.sesta.com" caldb.dwp.server.test12.ip = "test12"
X-토큰에 비 RFC 호환 데이터가 있는 경우 따옴표를 붙여야 합니다. 예를 들어 X-토큰의 콜론은 ":"과 같아야 합니다.
Calendar Server 유틸리티 cscal이 사용자를 소유자 목록에 보조 사용자로 추가할 때 사용자를 검증하지 않습니다.
Calendar Server 마이그레이션 유틸리티 csmig가 icsSubscribed를 소유자 달력으로 업데이트하지 않습니다.
이 작업은 수동으로 수행해야 합니다.
이벤트 알림 서비스(ENS)는 더 이상 사용되지 않습니다. 이 문제는 해결되지 않습니다. 대신 Sun Java System Message Queue 제품을 사용하십시오.
사용자가 이벤트를 수정하고 오늘의 이벤트와 미래의 모든 이벤트를 수정하는 옵션을 선택하면, 이전 이벤트가 모두 삭제되고 UI에 더 이상 표시되지 않습니다.
SSLv2 모드에서 SSL 초기화가 실패합니다. SSLv2 클라이언트를 사용할 수 없습니다.
스키마 1의 경우 달력을 생성하거나 다른 방식으로 관리하기 전에 DC 트리 노드를 생성해야 합니다.
오류 메시지가 여러 수준 아래로 감소되고 다양한 환경이 원인이 될 수 있기 때문에 오류 메시지가 모호합니다. 다음 높은 수준의 프로그램이 더 높은 수준으로 메시지를 보내기 전에 오류 메시지를 해석하지 않습니다.
설명의 맨 앞을 공백으로 시작할 경우 공백은 텍스트와 함께 저장되지 않으므로 이벤트가 표시될 때 나타나지 않습니다.
이 릴리스에서 구현되지 않은 RFE입니다.
남아 있는 잠금 파일로 인해 서버가 다시 시작되지 않습니다. 잠금 파일을 삭제한 다음 다시 시작하십시오.
잠금 파일은 다음 디렉토리에 있습니다.
/opt/sun/calendar/lib/lock/__db.001
법률에 의해 일광 절약 시간 전환 날짜가 변경되었습니다. Calendar Server 6.3 소프트웨어에는 새로 교정된 표준 시간대 테이블이 포함되어 있습니다. 이후에 생성되는 모든 이벤트와 작업은 올바른 시간을 사용하게 됩니다. 그러나 이전 전환 날짜와 새 전환 날짜 사이에 생성된 기존 이벤트와 작업은 1시간씩 벗어나 있습니다. 이 문제는 달력을 기준으로 봄 표준 시간에서 일광 절약 시간으로 전환할 때와 가을 일광 절약 시간에서 표준 시간으로 전환할 때 한 번씩 1년에 두 번 발생합니다.
이 문제는 이 문서의 뒤에 나오는 Calendar Server 6.3의 보고된 문제 에 설명된 문제 번호 6502376과 동일한 문제입니다.
해결:이 문제에 대한 표준 해결 방법은 해당 달력의 이벤트에 맞게 시간을 조정하는 것입니다.
요청에 따라 기술 지원팀에서 제공할 수 있는 해결 문제가 있습니다.
가져오기 기능을 사용하여 달력 간에 데이터를 이동할 수 없습니다. 데이터를 원래 내보냈던 달력(동일한 calid)으로만 가져올 수 있습니다.
이 제한은 이 문서의 Calendar Server 6.3의 보고된 문제 절에 번호 6461183으로 설명되어 있습니다.
다음은 제품에 대해 보고된 문제의 목록입니다.
호스트된 도메인 환경의 경우 csexport는 calid를 정규화해야 합니다. 예를 들어, uid@domain 형식으로 정규화합니다.
상태 파일이 생성되지 않습니다.
-saveState 옵션으로 csconfigurator.sh가 호출되고 지정된 상태 파일에 경로가 없으면 상태 파일이 생성되지 않습니다. 예를 들면 다음과 같습니다.
/opt/sun/calendar/sbin/csconfigurator.sh -saveState cs.state
해결 방법: 상태 파일이 생성되는 전체 경로 이름을 항상 지정하십시오.
자원 달력에 대한 초대 상태가 기본적으로 "수락"입니다.
자원 달력에 대한 초대 상태가 기본적으로 "수락"입니다. 자원 달력은 초대를 수락할 수 없기 때문에 자원 달력에 가입한 사용자는 Communications Express->옵션->달력 보기에서 수락된 초대만 보도록 선택한 경우 이러한 초대를 볼 수 없습니다.
해결 방법: ics.conf 매개 변수 resource.invite.autoaccept = "yes"를 설정하여 서버 수준 자동 수락을 결정합니다. icsAutoaccept LDAP 속성을 사용하여 자원 수준으로 결정할 수도 있습니다.
반복 이벤트에 문제가 발생합니다.
(storeevents를 사용하여) 비 날짜 필드 수정으로 dtstart 및 dtend 매개 변수에서 전송하면 데이터가 손상됩니다.
해결 방법: 날짜 필드를 수정할 필요가 없는 modify store 명령에 dtstart 및 dtend를 제공하지 마십시오.
디렉토리 서버가 스키마 2이고 도메인이 생성되어 있지 않은 경우 Calendar Server 구성 프로그램이 오류 메시지를 표시하고 이러한 디렉토리 서버에 대한 구성을 허용하지 않습니다.
이 문제는 구성 프로그램의 GUI 버전에 대해서만 해결되었습니다. 명령줄 버전의 경우 Calendar Server를 구성하기 전에 Delegated Administrator에서 도메인을 만들어야 합니다.
Java ES 2005Q1에서 업그레이드한 후 Access Manger를 사용한 단일 사인 온(SSO)이 작동하지 않습니다. 예를 들어, Portal Server 데스크톱에 로그인한 다음 Calendar Server에 액세스하려고 하면 단일 사인 온(SSO)을 통해 자동으로 인증되지 않고 로그인 페이지가 나타납니다.
해결 방법: 이 문제는 해결 방법이 없습니다.
프런트엔드 및 백엔드 설치를 포함하는 Calendar Server 배포를 업그레이드한 후 DWP로 통신하면 프런트엔드 설치 시작 시도가 실패하고 로그에 다양한 오류가 생성됩니다. 이 문제는 캐시 디렉토리를 새 설치에 복사하지 않았기 때문에 발생합니다.
해결 방법: cld_cache 및 ldap_cache 디렉토리를 /var/opt/SUNWics5/csdb.old에서 /var/opt/SUNWics5/csdb로 복사합니다. 그런 다음 새 디렉토리의 소유자와 그룹을 icsuser 및 icsgroup으로 설정합니다.
csdb에 데이터베이스 로그 파일이 누적됩니다.
저장소 데몬이 올바른 구성 파일 매개 변수를 읽지 않고 존재하지 않는 caldb.berkeley.*.enable을 찾고 있습니다. 그런 다음 비활성화된 순환 로깅의 기본값을 가져옵니다. 이는 또한 핫 백업의 발생을 막는 것을 비롯하여 다른 문제의 원인이 됩니다. 올바른 ics.conf 매개 변수는 caldb.berkeleydb.*.enable입니다.
해결 방법: 서비스를 다시 시작합니다. csstored는 누적된 로그 파일을 제거하여 로그 누적 문제를 관리합니다.
내보내기/가져오기를 사용하여 서로 다른 calid를 가진 달력 간에 데이터를 이동할 수 없습니다. 가져온 데이터는 가져오기를 수행할 원본 달력과 동일한 calid를 사용해야 합니다.
csrestore가 개인 사용자 달력을 고려하지 않습니다.
개인 달력을 만들고 백업을 성공적으로 실행한 후 개인 달력을 수동으로 삭제합니다. 그런 다음 restore 명령을 사용하여 개인 달력을 복원합니다. 로그 파일에서 달력이 성공적으로 복원되었는지 확인할 수 있습니다. UWC 또는 Calendar Express 인터페이스에 기록할 경우에는 개인 달력을 보거나 관리할 수 없습니다. 이 문제는 csrestore가 사용자 LDAP 항목, 가입 또는 자체 달력을 고려하지 않기 때문입니다.
해결 방법: csrestore를 사용하여 삭제한 후 복원한 각 사용자에 대한 다중 값 속성인 icsSubscribed를 수동으로 편집하거나 삭제합니다.
세션 데이터베이스 손실로 인해 로그인이 실패하고 과도한 세션 시간 초과 메시지가 표시됩니다.
해결 방법:
서비스를 중지합니다.
세션 데이터베이스를 제거합니다.
서비스를 시작합니다.
Calendar Server 패키지에는 JMQ 클라이언트가 번들로 제공되지 않습니다. 설치된 Messaging Server의 JMQ 클라이언트를 사용하십시오. JMQ 클라이언트가 설치되지 않은 상태에서 JMQ를 활성화하면 admind
프로세스가 비정상적으로 종료될 수 있습니다.
해결 방법: Messaging Server 번들에서 JMQ 클라이언트를 복사합니다.
2007년 3월 11일부터 2007년 4월 1일까지 달력 이벤트가 1시간씩 벗어남
이 문제는 일광 절약 시간이 적용되는 기간을 확장하기 위해 일광 절약 시간으로 전환하는 날짜와 표준 시간으로 돌아오는 날짜를 변경했기 때문에 발생합니다. 전환 날짜가 봄(3월)에는 앞으로 당겨지고 가을(11월)에는 뒤로 연기되었습니다. 이러한 변경을 반영하도록 Calendar Server 6.3과 함께 배포된 표준 시간대 파일을 업데이트했습니다.
Communications Express에서는 Calendar Server 표준 시간대 파일 대신 JVM 표준 시간대 정보를 사용하므로 새 표준 시간대 변경 사항을 반영하도록 JVM을 업데이트해야 합니다. 표준 시간대 데이터 업데이트와 기타 제품 기능 향상(예: 보안 문제 해결)을 전달하는 기본 방식으로 최신 Sun Java SE JDK/JRE 업데이트 릴리스를 사용하는 것이 좋습니다. 다음 문서에 설명한 것처럼 JVM 업데이트 프로그램을 사용합니다.
http://java.sun.com/javase/tzupdater_README.html
표준 시간대 정보를 업데이트한 경우 표준 시간대 업데이트 이전에 예약된 이벤트는 이전 전환 날짜와 새 전환 날짜 사이의 기간 동안에는 1시간씩 다르게 표시됩니다.
기술 지원팀에 요청하여 사용할 수 있는 문제 해결 실행 파일이 있습니다.
다른 방법으로 사용자에게 이전 전환 날짜와 새 전환 날짜 사이에 해당되는 이벤트에 대한 시간을 업데이트하도록 요청합니다. 또는 사용자 스크립트를 실행하여 업데이트가 필요한 이벤트에 대한 데이터베이스를 처리합니다.
LDAP 도구 위치 변경
이전(베타) 버전의 Java Enterprise System을 설치한 후 릴리스(RR) 버전 Java Enterprise System 5를 설치하기 이전에 SUNWldapcsdk-tools 패키지를 제거해야 합니다. 릴리스 버전에서 SUNWldapcsdk-tools 패키지의 위치가 변경되었기 때문입니다. 이 패키지를 제거하지 않고 릴리스 버전을 설치한 후 Calendar 또는 Messaging Server를 시작하면 다음과 같은 오류 메시지가 표시됩니다.
Could not find .../bin/ldapsearch utility Please install the ldapcsdk-tools package |
이 오류 메시지는 LDAP 도구의 위치가 변경되었기 때문에 표시됩니다.
해결 방법: 릴리스 버전의 Java Enterprise System 5를 설치하기 전에 SUNWldapcsdk-tools 패키지를 제거합니다. SUNWldapcsdk-tools 버전을 확인하려면 pkgparam -v SUNWldapcsdk-tools VERSION 명령을 실행합니다.
6.00,REV=2006.12.11.00.08 이상 버전이어야 합니다. 그렇지 않으면 LDAP 검색 유틸리티가 없다는 오류 메시지가 표시됩니다.
pkgrm SUNWldapcsdk-tools 명령을 사용하여 SUNWldapcsdk-tools 패키지를 제거합니다.
Java Enterprise System 5 설치 프로그램을 이미 실행한 경우 SUNWldapcsdk-tools 패키지를 수동으로 제거한 후 다음 명령을 사용하여 설치할 수 있습니다.
cd <jes5_distro>/Solaris_sparc/Product/shared_components/Packages pkgadd -d . SUNWldapcsdk-tools |
Linux 플랫폼에서 csmfagent 서버를 시작할 수 없습니다.
이진 달력에서 Linux 버전의 모니터링 프레임워크를 위한 공유 라이브러리를 찾을 수 없습니다. 모니터링 프레임워크 파일에 적합한 경로는 /opt/sun/mfwk/share/lib이지만, Calendar Server에서는 해당 파일이 /opt/sun/calendar/lib에 있는 것으로 기대합니다.
해결 방법: 다음 예제와 같이 Calendar Server 라이브러리에 해당 라이브러리에 대한 심볼릭 링크를 추가합니다.
# cd /opt/sun/calendar/lib # ln -s /opt/sun/mfwk/share/lib/*.so .
또는 모니터링 프레임워크 라이브러리에서 달력 서비스를 시작합니다. 예를 들면 다음과 같습니다. /opt/sun/mfwk/share/lib
Linux 플랫폼에서 Calendar Server 6.3으로 업그레이드한 후 로그인할 수 없습니다.
Calendar Server 6.3 업그레이드 1, 패치 번호 121658-17에서 패치가 적용되었습니다. 이 문제에 대한 자세한 내용은 이 릴리스 노트의 Calendar Server 알려진 제한 사항 절을 참조하십시오.
구성 프로그램을 사용하여 백엔드 서버를 설정하는 경우 정규화된 호스트 이름 대신 IP 주소가 다음 매개 변수에 잘못 입력됩니다.
caldb.dwp.server.hostname.ip
ics.conf 파일을 편집하여 매개 변수 값을 수정해야 합니다. 그렇지 않으면 시스템에서 백엔드 서버를 찾을 수 없습니다. 올바른 값은 백엔드 서버의 정규화된 호스트 이름입니다.
고가용성 패키지인 SUNWcsics가 제대로 작동하려면 몇 가지 업데이트가 필요합니다. Java Enterprise System 소프트웨어 번들에 사용된 패키지가 올바릅니다. 이 문제를 해결할 수 있는 패치가 제공될 때까지 다음 해결 방법을 사용해야 합니다.
Calendar Server 배포의 SUNWcsics 패키지를 수동으로 제거합니다.
Java Enterprise System 소프트웨어 배포의 SUNWcsics 패키지를 사용하여 pkgadd를 실행합니다.