Oracle® Calendar Administrator's Guide 10g Release 1 (10.1.1) Part Number B14472-02 |
|
|
View PDF |
This chapter contains the following sections:
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.
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:
Node-ID: The node-ID can be any number between 1 and 49999. When setting up a node, it is important to note that the node-ID cannot be changed once the node has been created. To reuse a node-ID it must be deleted from the Calendar server, which in turn will remove references from Oracle Internet Directory, before adding a new node with the same node-ID. The -r
flag can be used to "reset" a node (delete it and recreate it with the same node-ID). A warning will be issued before this action is taken. Node-IDs are unique locally and across the node network. Two nodes with the same node-ID cannot be connected in a network.
Node Alias: A descriptive word of up to 32 characters containing no spaces. When multiple nodes are configured on a server, users may need to indicate which node they want to connect to. Because, in general, a name is easier to remember than a numeric node-ID, aliases can be configured.
Node Time Zone: Every node has a time zone associated with it. If you do not specify a time zone, your node will be created using the default time zone set during installation of the Calendar server. See Appendix F, "Time Zone Table," in the Oracle Calendar Reference Manual, for a complete list of countries with their corresponding time zone notation.
SYSOP Password: The password for the SYSOP, or node administrator. If you are not using a directory server, the password cannot be longer than 15 alphanumeric characters. Otherwise the limit is 63 characters.
Directory Manager Password: If you are using a directory server in a standalone calendar installation, the directory manager password must be provided when creating a node. This is the password associated with the LDAP directory server manager defined by the [LDAP]mgrdn
parameter. In Oracle Collaboration Suite, all nodes of an instance share the SYSOP password, which is actually the password of the Calendar instance administrator, an entity stored in Oracle Internet Directory for use by the whole server instance. Its password is set when Calendar is installed with Oracle Collaboration Suite.
To create a node:
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.
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.
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 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:
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.
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.
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.
Shut down the calendar server.
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.
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
.
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'sldapmodify
utility or other tools available with your directory server.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:
Node A has two connections to node B and two connections to node C
Node B has two connections to node A and two connections to node C
Node C has two connections to node A and two connections to node B
Total number of connections = 12
A different set of guidelines applies to larger installations which fit within the following configuration parameters:
logged-on users per node is greater than 250
hardware configuration adequately supports the demands of the software
clients used are not the Oracle Calendar Web Client (that is, Oracle Calendar Desktop Clients, or Oracle Connector for Outlook)
configured users per host does not exceed 5,000
logged-on users per host does not exceed 2,500
logged-on users per node does not exceed 1,000
connected nodes per host does not exceed four
number of nodes in a network does not exceed 10
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:
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.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
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
.)
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
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:
"all
" refers to all included (+) and all excluded (-) nodes
"included
" refers to all included (+) nodes
"excluded
" refers to all excluded (-) nodes
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 thenodes.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).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
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:
Stop all calendar servers that host the nodes in your network.
Edit the unison.ini
file on the calendar server host that contains the node you want to configure.
Set the value of the [CLUSTER]
masternode
parameter to the node-ID of the desired node.
Restart your calendar servers.
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.
Entire nodes can be moved from one host to another. The following must be taken into account when moving a node:
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.
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.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.
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:
Stop both calendar servers. Do not restart either until instructed to do so later in this procedure.
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.
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.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
.
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
Stop all other calendar servers in the node network. Do not restart any of these until instructed to do so later in this procedure.
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.
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.
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.
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.
Edit the $ORACLE_HOME/ocal/misc/nodes.ini
file for the node network to reflect the host name change.
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.
Remove the $ORACLE_HOME/ocal/db/nodes/
<Nx> directory on the old host.
Start all calendar servers stopped during this procedure.
To move a node between node networks:
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.
Stop both calendar servers. Do not restart either until instructed to do so later in this procedure.
Run unidbfix -c
on the node you want to move to ensure that the database is not corrupted.
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.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.
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.
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.
Remove the $ORACLE_HOME/ocal/db/nodes/
<Nx> directory on the machine that originally contained the node.
Start all calendar servers stopped during this procedure.
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.
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:
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.
Shut down all servers hosting nodes that use a directory server (where the unison.ini
parameter [DAS] enable=TRUE
).
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}
Bring up all servers once the changes are complete.
Run unidssync
to synchronize the LDAP nodes with the directory server.
Run uninode
to add the non-LDAP nodes to the node network.
Run unidssync
on a regular basis (at least once a week for most installations) to keep the LDAP nodes synchronized with the directory server.
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).