This section contains tables that list of the more important known issues at the time of the Calendar Server 6.3 release:
The following limitations are known at this time:
Configuration Program Puts Wrong Value in DWP ics.conf Parameter
After Upgrade, Can't Login on Linux Platform: “Backend Host Unresolvable”
Provisioning Users for Communications Express in Schema 1 Mode
Must Enter Both Fully Qualified and Non-fully Qualified Host Names in Configuration File
The enpd Process Crashes When Opening and Closing Connections Rapidly and Concurrently
Events Between March 11, 2007 and April 1, 2007 Off by One Hour
Import of Calendar Data Only Works for Data from the Same calid
If you use the high availability feature (using the Calendar Server HA package SUNWcsics), then after you upgrade from an older version of Calendar Server to the Calendar Server 6.3 version, you need to perform the following workaround to avoid problem 6560681.
Workaround:
Manually remove the SUNWscics package that comes with Calendar Server 6.3.
Use pkgadd to add the SUNWscics package bundled with the Java Enterprise System software.
If you are deploying Calendar Server with front-end and back-end servers, which requires the use of the DWP protocol, the configuration program asks you to add the host name of the back-end server. When it stores this value in the ics.conf parameter caldb.dwp.server.hostname.ip , it stores it as an IP Address instead of the fully qualified host name that should be stored there. This means that the system can't find the back-end server.
Workaround:Replace the IP Address with the fully qualified back-end server host name. This can be done by simply editing the ics.conf file, which is a text file.
Correct instructions on what values to use for this and other parameters used to configure front-end and back-end servers can be found in Chapter 5, Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3, in Sun Java System Calendar Server 6.3 Administration Guide in the Sun Java System Calendar Server Administration Guide.
This problem is reported as problem number 6542989 in the following section of this Release Note: Reported Problems in Calendar Server 6.3 .
On the Linux operating system, after upgrading to Calendar Server 6.3, there are error messages in the http.log file after running start-cal:
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.
Also, after attempting to log in, the following error message is given:
Backend Host Unresolvable Please try again
Fix: This problem is fixed in Calendar Server 6.3 Update 1, patch number 121658-17.
This is the same as problem number 6516438 in the following section:Reported Problems in Calendar Server 6.3 .
Duplicate parameters are allowed in the configuration file, ics.conf . This can lead to some confusion about the value of the parameter. To determine which instance of a parameter is used by the system, find the last instance in the file. The system uses the value of the last instance of the parameter that it finds when processing the file.
Best practices: Add all changes to the end of the ics.conf file in a section labeled something like # My Parameter Changes. To keep a history of changes made, add a comment describing the reason for the change, and the date.
Periodically, comment out old changes that are no longer used, or if you do not care about a history of changes, delete old unused duplicates, leaving only the latest change in the file.
In this version, string substitution in XSL files is no longer being done in a preprocessing step of packaging. Therefore, the strings are substituted in real time, which degrades performance for the Calendar Express user interface.
Workaround: You can perform the string substitution before running Calendar Server by processing all of the XSL files and manually inserting the correct language strings. To perform the substitution, you need to add the perl script (xslvarparser.pl ) that can be found in the { CAL_SERVER_BASE}/tools/unsupported/bin directory. Instructions to run the script are provided in the script itself.
For your convenience, the instructions provided in the script are as follows:
Use the perl script xslvarparser.pl to substitute variables in the XSL files to speed up XSL rendering.
Copy this file to the /opt/SUNWics5/cal/html directory, which is default on Solaris.
And then run it as $ perl xslvarparser.pl.
The resulting files are put under an out directory in each locale.
Replace the XSL files in each locale by the files in the out directory.
It is recommended that you save the original files before doing this substitution.
This issue is the same as described in problem number 6385495 in Reported Problems in Calendar Server 6.3 .
Each set_userprefs command removes only one instance of a multi-valued preference.
Workaround: To remove all instances of a multi-valued user preference, you must issue one set_userpref command per instance.
For example: Perform a get_userprefs to list all of the user preferences. If there are multiple values for a preference, such as icsSubscribed , then you must issue one set_userprefs command to delete the preference for each of the values listed.
There is no cluster specific showrev command that will show what is installed on the individual nodes of the cluster. (This is a generic problem, not just Calendar Server specific. You would run into the same difficulty with any product installed on a global file system.)
This is a problem when you want to update Calendar Server. You need to apply the patch to every node where Calendar Server was already installed. In addition you can’t apply the patch to a node if Calendar Server hasn’t already been installed on it. If you don’t know which nodes have Calendar Server installed and which do not, at the least, it will be confusing and cost you time trying to discover where Calendar Server is installed.
Workaround: Run the following command to see all of the nodes where Calendar Server is installed: pkgparam -v SUNWics5 | grep ACTIVE_PATCH
Certain Calendar Server windows will not display if you have a pop-up blocker enabled.
Workaround: Disable pop-up blockers for the Calendar URL to ensure all Calendar Server windows will display.
Exception: Neither the Norton Inet Security AD_BLOCKER nor the Mozilla built-in POP_BLOCKER will affect Calendar Server windows.
The csuser utility does not enable users it creates for Address Book.
Workaround: Enable the user using ldapmodify.
The configuration program, csconfigurator.sh, configures only a single domain.
Workaround: If you need a multiple domain calendar environment (called either Virtual Domains or Hosted Domains), you must do two things:
Enable hosted domains.
Add the domains yourself using Delegated Administrator, or the csdomain utility if you are still using Sun LDAP Schema 1.
See Chapter 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment, in Sun Java System Calendar Server 6.3 Administration Guide and Chapter 13, Administering Calendar Server Domains, in Sun Java System Calendar Server 6.3 Administration Guide.
(Issue Number 4777792) Cache can fill up, causing errors. Calendar Server does not expire the LDAP cache data.
Workaround: Periodically remove contents of file. Then restart Calendar Server.
The configuration file asks for the hostname twice. Once fully qualified and the second time not fully qualified. For example:
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"
If there is non-RFC compliant data in an X-Token, it must be quoted. For example, a colon in an X-Token must appear as ":".
The Calendar Server utility cscal does not validate users before adding them to the owners list as secondary owners.
The Calendar Server migration utility csmig does not update icsSubscribed with the owners calendars.
This must be done manually.
The Event Notification Service has been deprecated. This will not be fixed. Use the Sun Java System Message Queue product in its place.
When a user modifies an event and chooses the option to modify today’s event and all future events, all previous events are deleted and will no longer display in the UI.
SSL initialization fails in SSLv2 mode. Unable to make use of SSLv2 client.
For Schema 1, you must create the DC tree nodes prior to creating or otherwise managing calendars.
Error messages are vague because the error message originates several levels down and could be caused by many different circumstances. The next higher level program does not interpret the error message before bubbling it up to the level above it.
If you start a description with a leading blank, the blank is not stored with the text and will not appear when the event is displayed.
This is an RFE that has not been implemented for this release.
Remaining lock files prevent it from restarting. Delete the lock files before restarting.
Lock files can be found in the following directory:
/opt/sun/calendar/lib/lock/__db.001
By law the Daylight Savings Time changeover dates were changed. The Calendar Server 6.3 software contains the new corrected timezone tables. All events and tasks created going forward will have the correct times. However, the preexisting events and tasks that fall between the old and new changeover dates will be off by one hour. This problem occurs twice for each year you have in your calendar, once for the Spring Standard Time to Daylight Savings Time changeover, and again when the Fall Daylight Savings Time to Standard Time changeover occurs.
This is the same problem as problem number 6502376 described in Reported Problems in Calendar Server 6.3 , later in this document.
Fix:The standard fix for this problem is to allow users to adjust the times for any events in their calendars that are effected.
There is a fix program that technical support can supply by request.
You can not use the import function to move data between calendars. It can only be imported into the same calendar (same calid) that it was exported from.
This limitation is the one documented as number 6461183 in the Reported Problems in Calendar Server 6.3 section of this document.
The following is a list of problems reported on the product:
For a hosted domain environment, csexport requires the calid to be fully qualified. For example, in the format uid@domain.
State file not created.
When csconfigurator.sh is called with the -saveState option, the state file specified doesn't include a path the state file is not created. For example:
/opt/sun/calendar/sbin/csconfigurator.sh -saveState cs.state
Workaround: Always specify the full path name, where the state file should be created.
Invitations Status by default should be “Accepted” for resource calendars.
Invitations Status by default should be "Accepted" for resource calendars. Since resource calendars cannot accept invitations, it is possible that users who are subscribed to resource calendars will not see these invitations (if users choose to view only accepted invitations in Communications Express->Options->Calendar view).
Workaround:The server level autoaccept is determined by the ics.conf parameter resource.invite.autoaccept = "yes". It can also be determined on a per resource level using the icsAutoaccept LDAP attribute.
Problem with recurring events.
Sending in dtstart and dtend parameters with non-date-field modifications (using storeevents) causes data corruption.
Workaround: Do not provide dtstart and dtend on modify store commands that require non date field modifications.
If Directory Server is Schema 2, and no domain has been created, the Calendar Server configuration program will display an error message and not allow the configuration against such a Directory Server.
This was fixed for the GUI version of the configuration program only. For the command-line version, you must created the domain in Delegated Administrator before configuring Calendar Server.
After upgrading from Java ES 2005Q1, single sign-on using Access Manger does not work. For example, when you log in to the Portal Server desktop and then try to access the Calendar Server, the login page appears instead of being automatically authenticated through single sign-on.
Workaround:There is no workaround for this problem.
After upgrading a Calendar Server deployment that includes front-end and back-end installations, communicating using DWP, attempts to start the front-end installations fail, generating various errors in the log. This problem occurs because the cache directories were not copied to the new installation.
Workaround:Copy the cld_cache and ldap_cache directories from /var/opt/SUNWics5/csdb.old to /var/opt/SUNWics5/csdb. Then, set the owner and group of the new directories to icsuser and icsgroup.
Database log files accumulating in csdb.
The store daemon is not reading the correct configuration file parameter. It is looking for caldb.berkeley.*.enable which does not exist. It then takes the default for circular logging which is disabled. This also causes other troubles, including hot backup not to happen. The correct ics.conf parameter is caldb.berkeleydb.*.enable.
Workaround:Restart services. csstored takes care of the log accumulation problem by removing the accumulated log files.
Can not use export/import to move data between calendars with different calids. The data imported must have the same calid as the calendar you are importing to.
csrestore don't take care about personal user calendar.
After creating a personal calendar and successfully running a backup, manually delete the personal calendar. Then, restore the personal calendar using the restore command. From the log files, you can view that the calendar has been successfully restored. But, cannot be able to see or manage personal calendar when logging to the UWC or Calendar Express interface. The problem is that csrestore does not take care about the user LDAP entries, subscribed, or own calendar.
Workaround:Manually edit or delete the multi valued attribute, icsSubscribed for each user, which was deleted and restored using csrestore.
Session database corruption causing login failures and excessive session timeout messages.
Workaround:
Stop the services
Remove the session database
Start the services
There is no JMQ client bundled with Calendar Server packages. Use the JMQ client from the installed Messaging Server. Failing to install the JMQ client could result in abnormal termination of the admind
process when JMQ is enabled.
Workaround:Copy the JMQ client from the Messaging Server bundle.
Calendar events off by 1 hour from March 11, 2007 to April 1, 2007
This happens because the dates for switching to Daylight Savings Time and back to Standard Time have been changed in order to extend the Daylight Savings Time period. The changeover dates now occur earlier in the Spring (March) and later in the Fall (November) than in earlier years. The timezone file distributed with Calendar Server 6.3 was updated to reflect these changes.
For Communications Express, which uses JVM timezone information instead of the Calendar Server timezone file, you must update your JVM to get the new timezone changes. Sun recommends using the latest Sun Java SE JDK/JRE update release as the preferred vehicle for delivering both timezone data updates and other product improvements such as security fixes. Use the JVM update program as described in the following document:
http://java.sun.com/javase/tzupdater_README.html
After your timezone information has been updated, events scheduled before the timezone update will show a one hour discrepancy for the days between the old and new changeover dates.
There is a fix executable available from technical support by request.
Another approach is to simply ask your users to update the times on their events that fall between the old and new changeover dates. Or, run your own script to process the database for those few events that need updating.
Location of LDAP tools have changed
If you have installed the earlier (beta) version of Java Enterprise System, you need to remove the SUNWldapcsdk-tools package prior to installing the released (RR) version of Java Enterprise System 5. This is due to the change in location of the SUNWldapcsdk-tools package in the released version. If you do not remove this package and try to start up Calendar or Messaging server after installing the released version, you will get the error message:
Could not find .../bin/ldapsearch utility Please install the ldapcsdk-tools package |
This error message is due to the change in the location of LDAP tools.
Workaround:Remove the SUNWldapcsdk-tools package prior to installing the released version of Java Enterprise System 5. To check the SUNWldapcsdk-tools version, run the command pkgparam -v SUNWldapcsdk-tools VERSION.
You must have a version that is 6.00,REV=2006.12.11.00.08 or later. Otherwise, you will get an error message that the LDAP search utility is not found.
Use the pkgrm SUNWldapcsdk-tools command, to remove the SUNWldapcsdk-tools package.
If you have already run the Java Enterprise System 5 installer, you can manually remove the SUNWldapcsdk-tools package and install it using the command:
cd <jes5_distro>/Solaris_sparc/Product/shared_components/Packages pkgadd -d . SUNWldapcsdk-tools |
Can't start csmfagent server on Linux platform.
Calendar binaries can't locate the shared libraries for the Monitoring Framework on Linux version. The proper path for the monitoring framework files is: /opt/sun/mfwk/share/lib, but Calendar Server is expecting it to be in /opt/sun/calendar/lib.
Workaround:Add a symbolic link to the proper library in the Calendar Server library, as shown in the following example:
# cd /opt/sun/calendar/lib # ln -s /opt/sun/mfwk/share/lib/*.so .
Another way to do this is to start calendar services from the Monitoring Framework library, for example: /opt/sun/mfwk/share/lib
On Linux platform, after upgrading to Calendar Server 6.3, can't log in.
This is patched in Calendar Server 6.3 Upgrade 1, patch number 121658-17. For more information about this problem, see the following section of these Release Notes: Calendar Server Known Limitations.
When you use the configuration program to set up a back-end server, it erroneously places the IP Address, instead of the fully qualified host name, into the following parameter:
caldb.dwp.server.hostname.ip
You must edit the ics.conf file to correct the parameter value, otherwise the system can't find the back-end server. The correct value is the fully qualified host name of the back-end server.
The high availability package, SUNWcsics, requires some updates to work correctly. The package used in the Java Enterprise System software bundle is correct. Until a patch is available to fix this problem, you must use the following workaround:
Manually removed the SUNWcsics package from your Calendar Server distribution.
Do a pkgadd, using the SUNWcsics package from the Java Enterprise System software distribution.