Managing a Node Network

A node network is a series of two or more connected nodes. Once a connection between two or more nodes has been defined, all user searches produce listings of configured users and resources from both local and remote nodes. This basic information is maintained on each of the computers in the node network. All calendaring data for each user and resource, however, resides only on that entity's local node, thus eliminating the space and consistency problems created by replicated databases. All exchanges of this information between nodes is done in real-time, making the scheduling of meetings with people or resources on remote nodes completely transparent to the user.

When setting up a node it is important to note that the Node-ID cannot be changed once the node has been created. Furthermore, an existing local node will be deleted if a new local node is given a Node-ID currently in use on the same computer. A warning prompt will be issued before this action is taken. Node-IDs must be unique not only locally, but also across the enterprise. If two nodes in a network are assigned the same Node-ID, connection between the two nodes will not be possible.

In this chapter the following node network management tasks are detailed:

• Connecting nodes


• Moving a node
• Migration from a non-LDAP node
• Coexistence of LDAP and non-LDAP nodes
• Caveat: LDIF differences UNIX and NT

Connecting nodes

The network configuration is stored in one file (/users/unison/misc/nodes.ini) managed using the centralized administration tool described below. The file must reside on only one of the host members of the node network, and commands can only be executed from this host. The administration tool can be used to add or delete nodes to the node network and set the number of TCP/IP connections between the nodes.

To connect two or more Calendar nodes:

1. Select Node Management|Connect Nodes to open the "Connect Nodes" form.
2. Enter the host to be added to the node network in the indicated edit box and click Add.
3. In the Edit node configuration (nodes.ini) edit box, replace the "-" with a "+" in the column to the left of the node(s) you want to add. If you wish to delete a node from the network, replace the "+" with a "-" in the column to the left of the node(s) you want to delete. See the following section "Syntax" for a more detailed discussion.
4. From the list box following Apply node configuration to the, select a rule to apply.

Three predefined groups can be used:

• all refers to all included (+) nodes
• out refers to all excluded (-) nodes
• ALL refers to all nodes (included or excluded)

 
5. Enter the SYSOP password in the indicated box.
6. Click Connect to make the configuration changes to your node network. Save Changes will save the configuration changes to a file until they are applied during a Connect operation.

Warning:

Connecting nodes is a potentially long action. In a test connection of six nodes, the total elapsed time before completion of the task was 5 minutes, 45 seconds.

• The uninode script is used for all node management tasks for the Calendar Server. See full documentation for this script in Appendix G.

Syntax

The nodes.ini file contains the list of the nodes and the list of rules that describe the network configuration. The minimal syntax for a node is:

+ H=HOSTNAME/N=NODE-ID

or

- H=HOSTNAME/N=NODE-ID

A node can either be included (+) in the network or excluded (-) from the network.

The following fields can be used to specify a node:

H	Host name	mandatory
N	Node-ID	mandatory
ALIAS	Alias for Node-ID	optional
GR	Group name	optional
S	Surname	optional
G	Given name	optional
OU1	Organizational unit 1	optional
OU2	Organizational unit 2	optional
OU3	Organizational unit 3	optional
OU4	Organizational unit 4	optional
O	Organization	optional
C	Country	optional
A	Administration domain	optional
P	Private domain	optional

If the ALIAS field is specified, it will be easier for users on all servers to identify on what servers remote users are located, as this information will be displayed by the client.

The group name is given by the administrator and will be used as an alias for a group of nodes. The interaction between the nodes of a specific group should be greater than with nodes of other groups. Most of the time, a group name will represent a geographical area or a company sub division.

Three predefined groups can be used:

all refers to all included (+) nodes

out refers to all excluded (-) nodes

ALL refers to all nodes (included or excluded)

Connections and Rules

Two kinds of rules can be used. The first kind is used to specify the default number of connections between all nodes or between nodes within a group.

Using the predefined group all in configuring our four nodes, we can easily specify that two SNC connections be established between all of our nodes:

+H=mis-can1/N=1

+H=mis-usa1/N=2

+H=mis-eur1/N=3

+H=mis-eur2/N=4

all:2

The second kind of rule specifies the number of connections, from one node or group to another node or group.

N1->N2:N

N1 and N2 could either be host names, node-IDs, or group names. N could either be a absolute number of connections (0, 1, 2, 3...), or a relative number of connections (+1, -1, +2, ...). Rules are interpreted from the first to the last rule of the file so that a rule of position "i" has precedence over the rules of position i-1, i-2, i-3, ... Consequently, the rules should be arranged from the most general to the most specific.

For example, to specify a more specific rule to this set of nodes, the group (GR) field can be useful in selecting these nodes.

+H=mis-can1/N=1/GR=Canada

+H=mis-usa1/N=2/GR=USA

+H=mis-eur1/N=3/GR=Europe

+H=mis-eur2/N=4/GR=Europe

all:2

Europe:+1

In the above example, we are able to add an additional SNC connection (for a total of 3) to each of the European nodes relative to the absolute value defined on the line above.

Had we not wanted to use groups, we could also have said:

+H=mis-can1/N=1

+H=mis-usa1/N=2

+H=mis-eur1/N=3

+H=mis-eur2/N=4

all:2

mis-eur1 ->mis-eur2:3

mis-eur2 ->mis-eur1:3

Note that in this case we must specify the number of connections in each direction as the SNC connections are unidirectional.

Adding (including) a node to the network

Replace the exclusion sign (-) of the host with the inclusion sign (+).

Deleting (excluding) a node from the network

Replace the inclusion sign (+) of the host with the exclusion sign (-).

Please note that deleting a node from the node network, even temporarily, will result in the loss of data. Removing this node will effectively delete all remote records which were created on this node.

Increasing or decreasing the number of connections between nodes

To modify the number of connections between nodes make the necessary changes to the rule lines. It is possible to add, delete or modify a rule line.

Example: To increase the number of connections from Los Angeles to Cupertino, add the following rule to the end of the file:

angeles->cupertino:+2

Moving a node

Complete nodes can be moved from one server to another.

Note:

The instructions below document moving nodes between Intel hosts or UNIX hosts. The following procedure will not work between a UNIX host and an Intel host unless a database conversion utility is used. Please refer to the Release Notes for this product for more information about this utility.

To move an entire node from one computer to another:

1. Stop all Calendar daemons / services.
2. Perform a full copy backup of the /users/unison/db/nodes/Nx directory where Nx contains the node that you are moving.
3. Copy the backup file to the new host and, using the same backup tool, restore the file.
4. Modify the unison.ini file on both systems to reflect the changes that you have made (i.e. Computer A has lost a node and Computer B has gained a node).
5. Start all Calendar daemons / services.
6. Update the computer name of the moved node on the other computers in the node network.

Migration from a non-LDAP node

Note: Calendar Server 1.0x and 3.x nodes cannot coexistence on the same machine. All nodes on a server must be either 1.0x or 3.x.

To migrate a node to Calendar Server 3.5:

1. [UNIX only] Extract the Netscape Calendar Server 3.5 package to a tmp directory
2. [UNIX] Run ns-setup-migration to install migration tools in the /users/unison directory.

[NT] Run setup-migration; make certain that you extract to the root directory for NCS 1.0x.
The following files will be extracted to:
/users/unison/bin/ctdb2ldif.exe
/users/unison/misc/ctdb2ldif.ini
/users/unison/migration.htm
3. Edit the file /users/unison/misc/ctdb2ldif.ini to include the required values for the Directory Server host, port and basedn. See the documentation for ctdb2ldif in Appendix G for more details.
4. While Calendar Server 1.0x is still up, run /users/unison/bin/ctdb2ldif to create LDIF files. Repeat this procedure for each node on server.
5. Copy all LDIF files from /users/unison/tmp to another directory as the Calendar Server root directory  (/users/unison) will be deleted during the upgrade to Calendar Server 3.5
6. Stop the Calendar Server
7. Backup previous version of  Calendar Server 1.0x and all relevant data:
[UNIX] uniarch -f<filename>
[NT] Run Windows NT backup or another third party backup tool to perform a full copy backup of the /users/unison/ directory.
8. Move the backup out of the Calendar Server root directory as the /users/unison directory will be deleted during installation of Calendar Server 3.5.
9. Install the Directory Server (if not already installed)
10. Update /etc/services to include an entry for:
unidas    5732/tcp
11. Install Calendar Server 3.5

[UNIX] Run ns-setup
• the behavior of the installation programme will be modified in two ways:
• it will query for the backup file created by uniarch for the purpose of restoring all files in /users/unison/misc, (except /users/unison/misc/timezone.ini) and /users/unison/db
• it will apply parameter entries found in unison10to35.ini or unison30to35.ini to /users/unison/misc/unison.ini depending on whether the previous version was 1.0x or 3.0
• the Create Calendar Server instance phase will be modified:
• to check if a node already exists; if a node does not exist the "Create New Node" form will open
• it will add the Calendar administrators' group as well as the related ACI
[NT] Run the installation programme setupex.exe
• Make sure the backup of Calendar Server 1.0x directories (/users/unison) has been done and moved as /users/unison will be deleted.
• When prompted during installation, you must answer "Y"  (yes) to delete the /users/unison directory.
• Create new nodes using the node-IDs used before in the previous installation.
• Copy from backup (Rollback) the /users/unison/db directories and the user.ini and resource.ini files from /users/unison/misc. To preserve the previous Calendar Server 1.0x configuration, you will have to merge parameter changes in the backup of Calendar Server 1.0x into the current /users/unison/misc/unison.ini
12. Import each LDIF file created in the previous step using ldapmodify. The LDIF files:
• will contain entries to add the SYSOP as a unique member to the group that was created during installation

Coexistence of LDAP and non-LDAP nodes

1. Backup all nodes in the existing node network. See "Backup procedures" in Chapter 8 for more instructions.
2. Shut down all servers hosting Calendar nodes that use a directory server (where the parameter in the unison.ini file [DAS] enable=TRUE).
3. From the Calendar Server Manager, select Server Preferences  | Manage Calendar Server to open the "Profile Editor" form.
4. Edit the parameter dir_internal_nodes in the [ENG] section of the unison.ini file to include a list of all non-LDAP or internal directory nodes.
eg. With four Calendar nodes in your network, nodes 10000 and 10001 on the Calendar Server 3.5 server and nodes 10002 and 10003 on Netscape Calendar 1.0x servers, the unison.ini file would contain the following parameter:
[ENG]
dir_internal_nodes = {10002, 10003}
5. Bring up all servers once changes are complete.
6. Run ctxdirsynch to synchronize the LDAP or external directory and the non-LDAP or internal directory.
7. Run uninode -import on the non-LDAP nodes to import the remote directory of items from the LDAP nodes.
8. Run ctxdirsynch on a regular basis (at least once a week for most installations) to keep the LDAP and non-LDAP directories synchronized.

Note: All nodes on a given host must use either an internal or an external directory. Thus, the parameter dir_internal_nodes cannot contain any  local nodes.
 

Caveat: LDIF differences UNIX and NT

1. Any control characters are removed (must change CR/LF to LF)
2. The "NT User" Object Class is removed

[Previous] [Next] [First] [Last]