Skip Headers
Oracle® Calendar Administrator's Guide
10g Release 1 (10.1.1)

Part Number B14472-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

12 Managing Calendar Nodes

This chapter contains the following sections:

About Calendar Nodes

A node is a database containing agendas and information for users, resources and event calendars. A node network is a set of two or more connected nodes. More than one node can exist on a single calendar host. This situation commonly occurs where a group of users requires a different time zone, or when there is a logical division that the administrator wants to maintain within a group of users.

Creating a Calendar Node

Each node is identified by a unique numeric key called the node-ID. Most administrators set one or more descriptive node aliases that may also be used when connecting to the calendar server. A SYSOP (node administrator) password restricts access to the calendar account used for all node management tasks. Each node has it's own default time zone.

To create a node, you will need the following information:

To create a node:

  1. Use the unistop utility introduced in Chapter 5, "Introduction to Oracle Calendar Server Administration", to bring down the calendar server. Please note that the server must be down in order to create a node.

  2. Run the uniaddnode utility. For more information about the use and syntax of the unistop and uniaddnode utilities, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  3. Use the unistart utility introduced in Chapter 5, "Introduction to Oracle Calendar Server Administration", to restart the calendar server. For more information about the use and syntax of the unistart utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

Example To create a node with a node-ID of 144 and alias "Publications":

% uniaddnode -n 144 -a publications 
Please enter Sysop password:
uniaddnode: Database initialization done
uniaddnode: node [144] has been successfully initialized

An entry similar to the following would now exist in the $ORACLE_HOME/ocal/misc/unison.ini file. Note that the name and version fields are for internal use and are automatically generated during node creation. The values of parameters in the node section should not be modified.

[144]
name = N2
version = A.06.10
timezone = EST5EDT
aliases = publications

Deleting a Calendar Node

Deleting a node manually requires an advanced knowledge of the calendar server. Before attempting to remove a node, familiarize yourself with the contents of the chapters referenced in the following procedure.

To delete a node manually:

  1. Back up all of the nodes in your node network using the unidbbackup utility. For more information about how to back up the entire Calendar database, see "Server Backup and Restore" in Chapter 14.

  2. Remove the node from the node network (if it is part of one) by editing the $ORACLE_HOME/ocal/misc/nodes.ini file and applying the change. Understand the contents of Chapter 14, "Calendar Node Networks", before attempting to do this.

  3. If Oracle Calendar was deployed with Oracle Collaboration Suite, run the unioidconf utility with the -deletenode option. For more information about the the unioidconf utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

    If your Calendar server has been deployed with a third party directory server, delete all users, resources and event calendars on the node (using uniuser -ex). For more information about the uniuser utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  4. Shut down the calendar server.

  5. Delete the entire $ORACLE_HOME/ocal/db/nodes/<Nx> directory, where <Nx> is the value of the name parameter in the appropriate node section of the $ORACLE_HOME/ocal/misc/unison.ini file. For example, if you are deleting the node with node-ID 144, <Nx> is the value of the name parameter in the [144] section of the unison.ini file. For details on unison.ini parameters, see "Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual.

  6. Delete the corresponding node section in the $ORACLE_HOME/ocal/misc/unison.ini file. For example, if you are deleting the node with node-ID 144, delete the [144] section of unison.ini.

  7. Restart the calendar server.

    Note:

    If you are using a third-party directory server, you may want to remove all references to reserved calendar users for the deleted node. Use your directory server's ldapmodify utility or other tools available with your directory server.

Connecting Nodes

The network configuration is stored in one file ($ORACLE_HOME/ocal/misc/nodes.ini), and is managed using the uninode utility. 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 uninode utility is used to connect or disconnect nodes in the node network, and to set the number of TCP/IP connections between the nodes, which are maintained by the Synchronous Network Connection (SNC) daemon/service.

The number of connections to establish between each pair of nodes in a node network is dependent in large part on the size and configuration of your installation. As a general guideline, smaller implementations are well served by a configuration in which a single node has two connections to each node in the network. All connections are one-way, so a network of three nodes would have a total of 12 connections:

A different set of guidelines applies to larger installations which fit within the following configuration parameters:

For any installation in this category, the general recommendation is to establish four connections each way between a local node and a node on a remote machine, and three connections each way between nodes on the same machine. Most installations can probably optimize this further.

The uninode utility is used for all node management tasks for the calendar server. For more information about the use and syntax of the uninode utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

To connect two or more calendar server nodes:

  1. Select the server which will be used to manage your node network.

    Note:

    When Oracle Calendar is deployed with Oracle Collaboration Suite, the first Calendar server installed is automatically chosen as the one that will manage your node network.
  2. In a standalone installation, run uninode -init to create and initialize a $ORACLE_HOME/ocal/misc/nodes.ini file. In an Oracle Collaboration Suite installation, this file is created automatically.

    % uninode -init 
    checking password for node 24, please wait... 
    Enter SysOp password: 
    
    connected to clio, node 24 
    extracted existing connection information 
    
    created the "$ORACLE_HOME/ocal/misc/nodes.ini" file 
    initialization succeeded 
    
    
  3. The newly created $ORACLE_HOME/ocal/misc/nodes.ini file contains the following header with a summary of uninode syntax and connection rules.

    #Description    File (nodes.ini) 
    #-------------------------------------------------------
    #INCLUDE NODE:  + H=Vancouver/N=10/ALIAS=Finance 
    #EXCLUDE NODE:  - H=Toronto/N=20 
    #NODE FOR MAIL: + H=Montreal/N=30/S=unison/G=unison/OU1=CS&T/OU2=R&D
    #ABSOLUTE RULE: all:2 
    #RELATIVE RULE: Vancouver->Montreal:+1 
    
    

    (In an Oracle Collaboration Suite installation, all is set to 3.)

  4. Use a text editor to add the nodes to be connected and the rules governing the connections to the nodes.ini file. See "Syntax" and "Connections and Rules" later in this chapter for a discussion of the nodes.ini syntax, connections, and rules. Once you exit the text editor, uninode will prompt for confirmation of changes to be done to the network and automatically apply them.

    Run uninode -edit and use a text editor to add the nodes and the rules governing their connections to the nodes.ini file. See "Syntax" and "Connections and Rules" later in this chapter for a discussion of the nodes.ini syntax, connections, and rules.

    + H=clio:5730/N=24 
    + H=clio:5730/N=25 
    included:2 
    ~ 
    no errors detected 
    2 node(s) to ADD 
    edit the temporary node file again? (y/n) n 
    LAST CHANCE TO ABORT, process changes? (y/n) y
    
    checking if all nodes are up
    connected to clio, node 24
    connected to clio, node 25
    
    Processing node 24
    connected to clio, node 24
    connected to clio, node 25
    added 24->25, TCP/IP connection
    
    Processing node 25
    connected to clio, node 25
    connected to clio, node 24
    added 25->24, TCP/IP connection
    Do you want to update the directory of items (Actual = 0/Expected = 7)? (y/n) y
    placed a request in the CWS queue to get node 24 user directory
    0 connection error(s), 0 processing error(s)
    Applying connection configuration: Successful
    
    

Syntax

The $ORACLE_HOME/ocal/misc/nodes.ini file contains the list of nodes and the list of rules that describe the network configuration. Any lines in the file that begin with the symbol "#" are considered comments and are ignored.

The minimal syntax for a node is:

+ H=<HOSTNAME>:<ENG_PORT>/N=<NODE-ID> 

or

- H=<HOSTNAME>:<ENG_PORT>/N=<NODE-ID> 

The <HOSTNAME> can be either a fully qualified domain name, or a numeric IP address. Do not, however, mix these in the same nodes.ini file. If you choose to use fully qualified domain names, you must continue to use fully qualified domain names throughout the file to avoid problems.

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

Table 12-1 lists the fields that can be used to specify a node

Table 12-1 Node Specification

Field Description Mandatory or Optional

H

Host name:eng_port

mandatory

N

Node-ID

mandatory

ALIAS

Alias for Node-ID

optional

GR

Group name

optional


If an alias is specified, it will be easier for users on all nodes of the network to identify where remote users are located, as this information will be displayed by the Calendar client.

The group name is given by the administrator and is used to refer to a group of nodes. The interaction between the nodes of a specific group should be greater than with nodes of other groups. In most cases, a group name will represent a geographical area or a company subdivision.

Three predefined groups can be used:

Connections and Rules

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

For example, say we have the following nodes in our nodes.ini file:

+H=mis-can1:5730/N=1 
+H=mis-usa1:5730/N=2 
+H=mis-eur1:5730/N=3 
+H=mis-eur2:5730/N=4 

To specify that two connections be established from each node to each of the other nodes, we use the predefined group "included" and add the following line:

included:2

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

N1->N2:X

N1 and N2 may either be host names, node-IDs, or group names. X may either be an 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. Consequently, the rules should be arranged from the most general to the most specific.

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

+H=mis-can1:5730/N=1/GR=Canada 
+H=mis-usa1:5730/N=2/GR=USA 
+H=mis-eur1:5730/N=3/GR=Europe 
+H=mis-eur2:5730/N=4/GR=Europe 
included:2 
Europe:+1

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

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

+H=mis-can1:5730/N=1 
+H=mis-usa1:5730/N=2 
+H=mis-eur1:5730/N=3 
+H=mis-eur2:5730/N=4 
included: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 SNC connections are unidirectional.

Note:

When applying absolute and relative rules in the nodes.ini file, absolute rules must always be specified before relative rules. As in the preceding example, we see that the absolute rule (included:2) precedes the relative rules (mis-eur1 ->mis-eur2:3 and mis-eur2 ->mis-eur1:3).

Adding a node to the network

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

Deleting a node from the network

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

Warning:

Deleting a node from the node network, even temporarily, will result in the loss of all remote attendees in existing events 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 entry. It is possible to add, delete, or modify a rule entry.

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

angeles->cupertino:+2  

Setting Up a Master Node

You can set up a master node for your node network to control network management and ease the finding of user accounts on installations spanning multiple nodes and hosts. Use of a master node is optional. When deployed with Oracle Collaboration Suite, a master node is automatically configured at the time of installation.

Note:

Your node network may not at any time contain more than one master node.

To set up a master node:

  1. Stop all calendar servers that host the nodes in your network.

  2. Edit the unison.ini file on the calendar server host that contains the node you want to configure.

  3. Set the value of the [CLUSTER] masternode parameter to the node-ID of the desired node.

  4. Restart your calendar servers.

Coexistence of Nodes With and Without Oracle Mobile Collaboration

If a master node is present in your node network, clients will query that master node for available server functionality such as wireless capabilities. If your master node server is set up with Oracle Mobile Collaboration but the other nodes in your network are not, then clients of users whose accounts reside on those other nodes will behave as if wireless capabilities are enabled, but users will encounter errors trying to use those capabilities. Likewise, if your master node is not set up with Oracle Mobile Collaboration but the other nodes in your network are, then all users' clients will hide or disable wireless capabilities (because the master node tells them no wireless capabilities are enabled on the server).

It is therefore recommended that you ensure that your master node has the same wireless capabilities as the other nodes in your network.

Moving a Node

Entire nodes can be moved from one host to another. The following must be taken into account when moving a node:

Big-Endian Versus Little-Endian Hosts

Moving a node between a big-endian host and a little-endian host (or vice versa) requires a database conversion. Contact Oracle support for more information about the conversion utilities unib2lendian (big-endian to little-endian), and unil2bendian (little-endian to big-endian) utilities.

Table 12-2 displays which platforms are big-endian, and which platforms are little-endian.

Table 12-2 Oracle Calendar Server Platforms

Big-endian Little-endian (Intel processors)

Solaris

Linux

HP-UX

Windows

IBM-AIX

Compaq Tru64


Node Network

The procedure for moving a node between node networks differs from that for moving a node within a node network. This difference is in the utilities the procedure uses to update the node network information.

While most node network management is performed using uninode or the Calendar administrator, removing a node from a node network using either of these tools results in data loss. Namely, any calendar data created by a user in the node that is removed is deleted from all other nodes in the network. This is fine when moving a node between node networks. However, when you move a node within a node network, you want all nodes in the network to preserve all data related to the node. In this case you prevent the data loss by using the unidbfix utility to update the node network configuration. See Performing the Move later in this chapter for the exact procedure to follow in each case.

Note:

If you are running a directory server, all nodes in a node network must point to the same directory server.

Moving from and Internal Directory to an External Directory

If you are moving a node from a calendar server that uses an internal directory to one that uses an LDAP directory server (or vice versa), you should consult Oracle Support for assistance.

Performing the Move

The following procedures describe moving a node between hosts that are:

  • both either big-endian or little-endian

  • both running the same version of the calendar server

  • both using the internal directory or both using a directory server

The first procedure describes moving a node within a node network. The second procedure describes moving a node from one network to another. Although both procedures describe moving a single node, each can be adapted to moving several nodes.

To move a node within a node network:

  1. Stop both calendar servers. Do not restart either until instructed to do so later in this procedure.

  2. Run unidbfix -c on the node you want to move to ensure that the database is not corrupted. For more information about the unidbfix utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  3. Make an archive file of the $ORACLE_HOME/ocal/db/nodes/<Nx> directory, where <Nx> is the value of the name parameter that appears in the section of the unison.ini file configuring the node you want to move.

    Caution:

    To avoid overwriting an existing node, be certain that the name of the node you are moving does not already exist on the new host.
  4. Copy the archive file to the new host and, using the same archiving tool, restore the directory. Verify that the $ORACLE_HOME/ocal/db/nodes/<Nx> directory now exists on the new host.

    If a node with the <Nx> name already exists on the target server, you may choose to rename the node you are moving. Use the lowest unused letter-number combination. For example, if the last node on the target server is named N6, rename the new node N7.

  5. Remove the section configuring the node from the $ORACLE_HOME/ocal/misc/unison.ini file on the old host and add it to the $ORACLE_HOME/ocal/misc/unison.ini file on the new host.

    Remember that if you chose to rename the node in Step 4, you must also rename the section configuring the node. Use the same letter-number combination you selected in Step 4.

Steps 6 to 11 update the node network information

  1. Stop all other calendar servers in the node network. Do not restart any of these until instructed to do so later in this procedure.

  2. Run unidbfix -export -n all on each of the hosts in the node network. This creates a remotenode.ini file in each of the node database directories (i.e. in each $ORACLE_HOME/ocal/db/nodes/<node>/perm directory). This file contains information about all nodes remote to node <node>. For more information about the unidbfix utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  3. Edit the node entry for the moved node in the remotenode.ini file of each node in the node network, replacing the old host name with the new host name.

  4. Run unidbfix -import -n all on each host in the node network. This updates the node database for each node in the node network. For more information about the unidbfix utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  5. Run unidbfix -k on the newly moved node to create the key files. For more information about the unidbfix utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  6. Edit the $ORACLE_HOME/ocal/misc/nodes.ini file for the node network to reflect the host name change.

  7. If you are running a directory server, update the directory server using the ldapmodify tool, changing the old host name to the new host name on the moved node. This attribute exists for each SYSOP special user.

  8. Remove the $ORACLE_HOME/ocal/db/nodes/<Nx> directory on the old host.

  9. Start all calendar servers stopped during this procedure.

To move a node between node networks:

  1. Remove the node from its current network. Run uninode -edit to edit the nodes.ini file and apply the change. For more information about the uninode utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

  2. Stop both calendar servers. Do not restart either until instructed to do so later in this procedure.

  3. Run unidbfix -c on the node you want to move to ensure that the database is not corrupted.

  4. Make an archive file of the $ORACLE_HOME/ocal/db/nodes/<Nx> directory where <Nx> is the name of the node you are moving.

    Caution:

    To avoid overwriting an existing node, be certain that the name of the node you are moving does not already exist on the new host.
  5. Copy the archive file to the new host and, using the same archiving tool, restore the directory. Verify that the $ORACLE_HOME/ocal/db/nodes/<Nx> directory now exists on the new host.

  6. Remove the section configuring the node from the $ORACLE_HOME/ocal/misc/unison.ini file on the old host and add it to the $ORACLE_HOME/ocal/misc/unison.ini file on the new host.

  7. If you are running a directory server, update the directory server using the ldapmodify tool, changing the old host name to the new host name on the moved node. This attribute exists for each SYSOP special user.

  8. Remove the $ORACLE_HOME/ocal/db/nodes/<Nx> directory on the machine that originally contained the node.

  9. Start all calendar servers stopped during this procedure.

  10. Add the node to the node network. Run uninode -edit to edit the nodes.ini file and apply the change. For more information about the uninode utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.

Connecting LDAP and Non-LDAP Nodes

Note:

This procedure applies to Oracle Calendar servers installed in standalone mode only.

For nodes with and without LDAP connections to coexist in a network, the most recent version of the calendar server in the node network must manage that network. Furthermore, if there is more than one of the most recent version of the Calendar Server, and any use a directory server, one of them must manage the node network. Recall that all nodes in a node network must point at the same directory server.

The following procedure outlines the steps you must execute when you have a node network where all nodes currently connect to an external directory, and you want to introduce internal-directory nodes into the network. All calendar servers are assumed to be the most recent version.

To integrate the new internal-directory nodes into the node network, execute the following steps:

  1. Back up all nodes in the existing node network. See Server Backup and Restore in Chapter 14, "Calendar Server Maintenance and Monitoring", for more instructions.

  2. Shut down all servers hosting nodes that use a directory server (where the unison.ini parameter [DAS] enable=TRUE).

  3. Edit the parameter [ENG] dir_internal_nodes in the unison.ini file, on all calendar servers in the node network which use a directory server, to include all non-LDAP nodes.

    Example:

    With four nodes in your network, nodes 10000 and 10001 on the calendar server using a directory server, and nodes 10002 and 10003 on calendar servers using internal directories, the unison.ini file on the calendar server using a directory server would contain the following parameter:

    [ENG] 
    dir_internal_nodes = {10002, 10003} 
    

    Warning:

    Incorrect use of the [ENG] dir_internal_nodes parameter can have serious consequences.

  4. Bring up all servers once the changes are complete.

  5. Run unidssync to synchronize the LDAP nodes with the directory server.

  6. Run uninode to add the non-LDAP nodes to the node network.

  7. Run unidssync on a regular basis (at least once a week for most installations) to keep the LDAP nodes synchronized with the directory server.

Caveat: LDIF Differences Between UNIX and Windows

You must understand the Slight differences in the UNIX and Windows LDIF file formats in order to successfully transfer data from an Windows to a UNIX server. Before importing Windows-generated LDIF files to UNIX, ensure that any control characters are removed (must change CR/LF to NL).