Netscape Calendar Server 4.0
This file was last updated on Jan 21, 2000
Thank you for choosing the Netscape Calendar Server. These release notes
contain caveats, known problems, and other important information about
the product. Please read these notes before using the product. For installation
instructions, see the readme
file. Please see the on-line Administrator's Guide for information
about administering your Netscape Calendar Server.
This version of Netscape Calendar Server is available for Windows NT
4.0 (Service Pack 4), Solaris 2.5.1/2.6, HPUX 10.20/11.0 and AIX 4.21/4.32
Contents of this file
What is included in this release
Netscape Calendar Server Daemons
The Calendar Server contains five daemons/services: Calendar Lock Manager
(unilckd), Calendar Engine (uniengd), Calendar Synchronous
Network Connection (unisncd), Calendar Corporate-Wide Services
(unicwsd), and Calendar Directory Access Server (unidasd).
Netscape Administration Server 3.5
Calendar Server 4.0 uses the web-based Netscape Administration Server 3.5
to configure and manage the product. The Administration Server 3.5 is installed
with Calendar Server. Instructions on the use of this administrative tool
are contained in the Calendar Server Administrator's Guide.
Command Line Utilities
Calendar Server 4.0 can also be managed using a full suite of command line
utilities found in the /users/unison/bin directory. See Appendix
G of the Administrator's Guide for more information on the function,
syntax and use of each utility.
What is new in this release
The following features are new to Calendar Server 4.0. Please see Calendar
Server 3.5x release
notes for an account of the functionality enhancements made between
the 3.0 release and the 3.5x releases.
Renamed utilities
| Old Name (CS 3.5x) |
New Name (CS 4.0) |
| ctxdirdiff |
unidsdiff |
| ctxdirsynch |
unidssync |
| slice |
unislice |
| snapshot |
unisnapshot |
| uniux2intel |
unib2lendian |
| uniintel2ux |
unil2bendian |
| (unidsattach) |
(functionality implemented through -add
and -ex options of uniuser and unires utilities) |
Move User utility (unimvuser)
The utility unimvuser allows Calendar administrators to move a
user and his/her agenda from one Calendar node to another. See Appendix
G "Utilities" of the Administrator's Guide for a full description
of the options and syntax.
On-line or 'hot' backup capability (unidbbackup)
Calendar Server now can be backed up without bringing the server down.
See Chapter 8 "Node Maintenance" of the Administrator's Guide for
more information on the use, through either the administrative GUI or the
command line, of the unidbbackup utility.
Database restore utility (unidbrestore)
A Calendar database backed up using unidbbackup now may be restored
using the complementary utility, unidbrestore. See Chapter 8 "Node
Maintenance" of the Administrator's Guide for more information on
the use, through either the administrative GUI or the command line, of
the unidbrestore utility.
Identify non-Calendar users in directory server
(unidssearch)
The unidssearch utility is used to list all users in a directory
server who are not Calendar users. Output from the command can be used
to create large files of directory server users to be attached to a Calendar
node using uniuser -ex
Synchronize remote with local node data (unirnsynch)
A utility to propagate deletions in the local information of one node to
another node in the network (used only when uninode -cws all reports
discrepancies).
Server Configuration Parameters
[ENG]
readlocktimeout
writelocktimeout
There are two parameters in the server configuration file that are strongly
believed to be a trigger of server hangs or freezes in large deployments
and/or where servers are busy. Large deployments would generally be 3000+
users per node and this could be a single or multi-node environment.
Please refer to technote
991220-2 for detailed information.
Performance improvements
Changes to the interaction between Calendar Server and Netscape Directory
Server have resulted in a noticeable performance improvement in terms of
the access and retrieval of data. The parameter [ENG] dac_itemget
(Database item retrieval) can be used to enable caching of directory server
data.
NOTE: The Admin Guide states that the default is set to TRUE,
which means that items are retrieved from the directory server and not
from cache. However, this is incorrect, as during an installation the
default is set to FALSE in the unison.ini which means that caching
is turned on. It is recommended that you keep this setting to
FALSE, especially in large deployments (3000+ users) or where servers
have extensive I/O activity. See chapter 7 of the Administrators
Guide for more details.
Extended UTF-8 capabilities
The conversion and storage of Calendar data in UTF-8 format has been extended
to all fields in the database and thus now extends to task and event fields.
Shift-JIS support
Calendar Server support for a Japanese environment has been enhanced, most
notably with the addition of Shift-JIS as a supported character set.
A Japanese version of the Calendar client is required to exploit this functionality.
See Appendix H, "International Support" in the Administrator's Guide
for the configuration of a Japanese Calendar Server.
UID logon
Calendar Server now supports the use of UID (user ID) logons.
Support for calendaring standards
Calendar Server 4.0 now supports the following calendar standards:
-
current iCal specifications
-
support for foreign invitees
-
support for foreign events, including storage and retrieval of all iCal
event attributes
-
interoperability between local and foreign events
-
e-mail notification on receipt of iCal event
-
meeting creator in reply to address of e-mail sent by server
How to report problems
Post any problems or questions to snews://secnews.netscape.com/netscape.server.calendar
. You can also contact Netscape Technical
Support.
Limitation, caveats, and known problems with this
release
This section describes the limitations, caveats, and known problems with
this release:
Must have enough disk space before attempting
to create a Calendar node
Before attempting to create another Calendar node, it is very important
that you have enough disk space. If you do not have enough disk space,
you will get error messages and the server will not restart. At this point,
you must follow the steps in How
to uninstall Calendar Server to clean-up references to the newly created
node.
NT node limit per server
Calendar Server 4.0 on the Windows NT platform can only support up to nine
nodes on one server, while 3.51 supported up to 14. If you have a Calendar
Server 3.51 with more than 9 nodes that you want to upgrade to Calendar
Server 4.0, Netscape recommends that you migrate the extra nodes to another
Calendar Server 3.51 on another Windows NT system.
A general outline for the steps are as follows:
1) Install the Calendar Server on your new server.
2) On the old server, stop all Calendar Services
3) Backup the database files that you want to move, \users\unison\db\nodes\Nx
ie: If you have 12 nodes, you will need to move 3 nodes.
4) Install the backed up nodes on your new server. (put the files into
\users\unison\db\nodes\Nx and update the users\unison\misc\unison.ini
file)
5) Remove the backed up nodes from your old server (\users\unison\db\nodes\Nx
as well as the \users\unison\misc\unison.ini)
6) On all nodes and the nodes.ini file, update the node network information
to reflect the new server name where the moved nodes are installed.
7) Startup the services.
8) Inform the users on the nodes you have moved of their new hostname.
These are very general instructions, please refer to the following
Technical
note for all details.
LDAP nested groups
Calendar Server does not support LDAP nested groups. Searches from Calendar
Client will only show users at the top level.
Ownership of log and temp files
Log and temp files created or modified by Calendar utilities must have
ownership set to unison. If ownership of these files is set to root, utilities
will fail as they will not have write permissions.
uniuser -edit errors
When using uniuser -edit to modify X.400 attributes that extend
past one line in length, you will receive an error when you save the file
containing the modifications; however, the changes will be processed correctly.
uninode -cws slow
uninode -cws is slow for operations involving the connection of
nodes with many users.
Maximum number of files open per user: [DB]
db_files
If, while monitoring performance, the Calendar administrator notices an
excessive number of file open and close operations, the value of [DB]
db_files should be recalculated. The default value of 15 can be increased
up to 125; however, it is possible that such a change will require a reconfiguration
of the operating system's kernel. See Appendix C: "System Specific Parameters"
in the Administrator's Guide for a discussion of the relevant
operating system parameters.
unidbfix version must be upgraded
with Calendar Server
Do not use older versions of unidbfix with Calendar Server 4.0.
Use the version supplied in the package or a newer version supplied by
your service provider. Verify your version with the command unidbfix
-v. The version number of the utility should be equal to or greater
than 1.25 with a database version of 2.6.
Use of unidbfix during node migration
& upgrade
As a precautionary measure, run unidbfix in check mode (unidbfix
-c), to verify the consistency of your database before migrating or
upgrading a node.
uninode -edit
uninode -edit does not work. To create or modify a node network,
select Node Management | Connect Nodes from the Calendar Server
administration GUI to open the "Connect Nodes" form, or follow the example
in the uninode documentation in Appendix G of the Administrator's
Guide.
Updating Nodes.ini with uninode
There are two problems with the utility uninode. They address different
issues and require different workarounds. Please review carefully.
1). Applying changes to a nodes.ini file using uninode where there is
a mixture of + and - nodes.
There is a problem with uninode where the flag -ALL doesn't completely
update all of the remote node information. If you are removing a
node from a node network, keep in mind that it is really a two step process:
1) connect to all '+' nodes and remove the '-' node from each of their
databases. 2) Next, connect to the '-' node and remove the
'+' nodes from that database.
-
The best possible workaround is to run uninode -apply ALL followed
by uninode -apply all
2). Applying changes to a nodes.ini file using uninode where there
is fine tuning of node connections (e.g. A->B: +1, etc.)
With this you are forced to use unidbfix -export to generate your remotenodes.ini
file, then you must manually edit this file as required, they run unidbfix
-import to update the remotenode.dat file.
-
Run unidbfix -export and then unidbfix -import to update
all the remote nodes with the new information.
Japanese DS 3.x
If you are using a Japanese version of Netscape Directory Server 3.x, you
will need to update your schema manually in order to add resources to your
node network. The nsCalResource Object Class in Directory
Server's schema is missing "sn and gn" attributes. You should add these
attributes to nsCalResource Object Class in the ns-calendar-schema.conf
file. For more information, see the online Directory
Server documentation, regarding extending
your schema.
Uniaddnode -- bind as "admin"
Bind as "admin" user versus "directory manager" when adding a node via
the command line. For example:
uniaddnode -n 10000 -t PST8PDT -w <adminPsw> -p
<sysOpPsw>
Unires -add requires password on the command
line
You must add the PSW field required by the Admin as a key=value pair under
the cn. For example:
unires -add "DID=cn=room2, ou=Calendar, ou=Netscape Servers,o=mcom.com/PSW=resoursePsw"
-n 18000 -p <sysopPsw>
Backup from the Admin Server GUI or command line
When you run a backup from the GUI, you can only place the backup files
one directory down in a relative path under the calendar-host/bak/
directory. If you use the default, the backup file will be placed
in a subdirectory named with a date/time stamp. When you backup from
the command line utility, unidbbackup, your may place the backup tar file
into a directory or your choice, but that directory must already exist
or the utility will fail.
Backup of multiple node network
To prevent or minimize inconsistencies between nodes, back up all nodes
on a multiple node network at the same time.
Client compatibility
We strongly urge you to use the 4.61 Calendar client with the 4.0 Calendar
Server. There are known problems with going offline when using the
4.5 client on any platform against the 4.0 Server. Both the 4.51 Windows
and the 4.52 motif clients have repaired this problem. The 4.6 motif
client is not able to run against the 4.0 Calendar Server.
Client (v4.03) offline problems
Mac Calendar 4.03 cannot work offline with version 4.0 server. If a user
attempts to either go off-line or login offline
they receive module errors. See complete details in the following
Technical
note .
Database conversion
As a general rule of thumb, the database conversion process during migration
and upgrade takes approximately as long as a unidbfix -f for each
individual database.
Installation character set error
During installation you may experience a character set installation error.
This is not a critical error and occurs if the installation script encounters
an unanticipated character set with the detected OS version.
UID Search
There is no search capability based on UIDs. Searching will only
work with first/last name input. This ability is only present for
logging-on to the Server.
Error Code Descriptions
The following link is a living document that will contain common DEXOTEK
Error codes with diagnosis and actions.
How to properly and completely delete a node
See Technote
http://help.netscape.com/kb/corporate/991112-6.html.
Documentation for SunOS
Kernel params
In Appendix C of the Calendar Administration Guide under Adjusting the
SunOS Kernel Parameters, there are some misspelling of the following
parameters:
|
Incorrect Parameter
|
Correct OS Parameter
|
| semsys:msginfo_semmni |
semsys:seminfo_semmni |
| semsys:msginfo_semmns |
semsys:seminfo_semmns |
How to properly set the num_connect parameter
in large deployments
Due to the new Directory Server cache feature in Calendar Server 4.0, a
lot less DAS connections are required and the total number should never
be set higher than 250. Our recommendations for num_connect are a maximum
of 5% of logged on users, however, 250 DAS connections is considered as
very high. Refer to technote http://help.netscape.com/kb/corporate/19980624-6.html.
Patch 1 Information
Patch location
Repairs and Bug fixes
Installation
Patch location
The Netscape Calendar Server Patch1, can be found on the following
website:
http://www.iplanet.com/downloads/patches/index.html
Repairs and Bug fixes included
in this Patch
The following utilities were modified to repair 5 bugs in the Netscape
Calendar Server 4.0 release: unimvuser, uninode, unidsdiff and
unisizeof. It was also necessary to modify the uniengd
daemon. These files constitute Patch 1 and will replace the existing
utilities of the same name.
Uninode -edit and uninode -apply were repaired, Uninode -edit
was not functional but could be accomplished by connecting nodes via the
GUI or by using an editor. Uninode -apply was not properly updating
remotenode data when special rules were stated. The workaround for
this problem was to stop the server and run unidbfix -export. Both
bugs have been repaired and the work arounds are no longer required.
Unisizeof had a minor problem that occurred when you ran the
utility unisizeof without specifying a node. The utility is supposed
to point to the default database which is always N0 and instead was pointing
to N1 which is actually the second node, and is legacy from 1.x.
This defect has been repaired.
Unidsdiff had a problem when run with the -d flag for delete,
and selected "n" for confirmation. For example if you ran
the following command: ./unidsdiff -d -n 14000
The utility is comparing the calendar store and the LDAP calendar entries
for differences. If differences are identified, a message similar
to this will appear
nsCalXItemId="14000:00256" ("uid=srama,ou=Test for Y2k,ou=People, o=netscape.com")
unidsdiff: do you want to delete the calendar object-class? (y/n)
if you select "n" the utility will not delete, and the following
message will be displayed.
unidsdiff: deletion not done
Unimvuser had a problem where if the move was unsuccessful, due
to the client being logged on, a bit would be set in the user's preferences
that deselected, a global "can invite me" permission. When the move
was complete the bit was to be reset to select the "can invite me" permission,
but it was not working properly. The problem has been fixed so that
the bit is reselected upon move completion without intervention from the
user.
Installation
Modules to be replaced, the platforms and their target location:
|
File name
|
Platform
|
Location
|
File to replace
|
| uninode (script) |
Unix |
users/unison/bin/ |
uninode |
| unisizeof (script) |
Unix |
users/unison/bin/ |
unisizeof |
| universion (script) |
Unix |
users/unison/bin/ |
universion (*) |
| universioninc (script) |
Unix |
users/unison/bin/ |
universion (*) |
| unidsdiff.exe |
NT |
\users\unison/bin\ |
unidsdiff.exe |
| unimvuser(.exe) |
Unix & NT |
users/unison/bin/ or \users\unison\bin |
unimvuser(.exe) |
| uniengd(.exe) |
Unix & NT |
users/unison/bin/ or \users\unison\bin |
uniengd(.exe) |
|
|
|
|
| (* required with new engine version) |
|
|
|
Installation procedure
-
Unzip and untar the patch file into a temporary directory.
-
Copy, for backout purposes, the files listed in the table above into a
backup directory which is not a temporary location.
-
Stop the Calendar Server.
-
Place the new scripts from the temp location to ../<server-root>/unison/bin
directory of the Calendar Server tree.
-
Start the server.