Oracle® Collaboration Suite Migration and Coexistence Guide 10g Release 1 (10.1.1) Part Number B14486-02 |
|
|
View PDF |
To migrate calendar data from Netscape to Oracle Calendar, you must follow a specific migration path. This involves migrating calendar data from Netscape Calendar to CorporateTime and then upgrading from CorporateTime to Oracle Calendar. This chapter describes how to migrate calendar data from Netscape Calendar to Oracle Calendar.
The chapter contains the following migration scenarios:
Upgrading Oracle Calendar to Oracle Collaboration Suite with Coexistence
Upgrade Oracle Calendar to Oracle Collaboration Suite Without Coexistence
Before migrating from Netscape Calendar to CorporateTime 5.4, you need to shut down the Netscape Directory server and the Netscape Calendar server, and then back up the Netscape Calendar server database and configuration files.
The following are the tasks required when migrating from Netscape Calendar to CorporateTime 5.4:
To back up the Netscape Calendar server:
Stop the Netscape Directory server and Netscape Calendar server.
Back up the Netscape Calendar database and configuration files:
On Windows:
Copy the entire C:\unison
directory (and its subdirectories) to another drive or another computer.
Uninstall the Netscape Calendar server to remove all associated registry entries.
On UNIX:
Copy all the /users/unison/db/nodes/N
x
(where x is an integer from 0 to the number of nodes in the server) directories (and their subdirectories) to a safe location.
Copy the /users/unison/misc
directory to a safe location.
To extend the Netscape Directory server schema:
Extract the following files from the CorporateTime 5.4 installation package and copy them to the /
Netscape_Directory_Server_path
/
slapd-
server_name
/config
directory:
oracle-calendar-schema.conf
oracle-calendar-globopt.conf
Add the line in bold to the /Netscape_Directory_Server_path
/slapd-
server_name
/config/slapd.conf
file:
include /Netscape_Directory_Server_path/slapd-server_name/config/ns-schema.conf include /Netscape_Directory_Server_path/slapd-server_name/config/oracle-calendar-schema.conf
Edit the /
Netscape_Directory_Server_path
/slapd-
server
/config/slapd-ldbm.conf
file to include the following line at the bottom of the file:
include /Netscape_Directory_Server_server_path/slapd-server_name/config/oracle-calendar-globout.conf
Restart the Netscape Directory server to apply the configuration changes.
Stop the Netscape Directory server and extract the LDAP server data for editing:
$ ./stop-slapd $ cd /Netscape_LDAP_server_path/bin/slapd/server $ ./ns-slapd/db2ldif –f /Netscape_LDAP_server_path/slapd-server_name/config/slapd.conf –i /Netscape_LDAP_server_path/slapd-server_name/ldif/FILENAME
Edit FILENAME
as follows:
Replace all occurrences of nscal
with ctcal
.
Replace all occurrences of nsCal
with ctCal
.
Load FILENAME
into the Netscape LDAP server:
$ ./ns-slapd/ldif2db –f /Netscape_LDAP_server_path/slapd-Server_name/config/slapd.conf –C –i /Netscape_LDAP_server_path/slapd-Server_name/ldif/FILENAME $ ./start-slapd
To install CorporateTime 5.4:
Perform the installation process outlined in the CorporateTime Server 5.4 Readme, which is located at
http://www.steltor.com/notes/corptime-server/5_4/readme.htm#1001884
In the Readme file, follow the section "Installing CorporateTime Server with Internal Directory."
Modify the unison.ini
file so that it contains the appropriate node entries at the end of the file.
You can automatically upgrade CorporateTime or Oracle Calendar 3.x data to the new version of the Oracle Calendar application system.
Refer to Oracle Collaboration Suite Installation guides for directions on how to upgrade from CorporateTime to Oracle Calendar standalone.
This section outlines the upgrade process from Oracle Calendar standalone with a Lightweight Directory Access Protocol (LDAP) directory server, to Oracle Collaboration Suite 10g Release 1 (10.1.1) , which uses Oracle Internet Directory. In this scenario, the following LDAP directory servers are supported:
Netscape 4.x
iPlanet
Sun ONE 5.x
This scenario assumes that you have other applications that use a Netscape, iPlanet, or Sun ONE directory server and, therefore, you need to keep and manage this directory server along with the Oracle Internet Directory server. The Oracle Directory Integration Platform (DIP), a feature of Oracle Internet Directory, is used to keep the user data in both directory servers synchronized.
The section contains the following:
Some General Notes and Assumptions
Before you begin the procedure of upgrading to Oracle Collaboration Suite, take note of the following assumptions and limitations regarding this procedure.
You currently have Oracle Calendar and a iPlanet, Netscape, or Sun ONE directory server installed and running.
The synchronization will be one-way only (from iPlanet, Netscape, or Sun ONE to Oracle Internet Directory).
Once the migration is completed, you can only add new users through the iPlanet, Netscape, or Sun ONE directory server.
Note:
If you add a new user to a Calendar server node on the iPlanet, Netscape, or Sun ONE directory server, the user still appears as available when viewed from the Calendar server node on Oracle Internet Directory. Therefore, whenever you add a new user to the Calendar server node on Oracle Internet Directory, ensure that the user has not been already added to another node.You need to install Oracle Collaboration Suite and ensure that all the tiers of Oracle Collaboration Suite are running.
Refer to Oracle Collaboration Suite Installation Guide for Microsoft Windows for the installation details.
This section outlines how to migrate the directory data from the iPlanet, Netscape, or Sun ONE directory server to Oracle Internet Directory. This procedure involves exporting the directory entries from the iPlanet, Netscape, or Sun ONE directory server to an LDAP Data Interchange Format (LDIF) file, and then importing it into Oracle Internet Directory.
The following are the tasks that you require to perform to migrate directory entries:
Task 1: Exporting the Directory Entries from Netscape Directory Server
Task 2: Analyzing the LDIF Files for Any Required Schema Additions Referenced in the LDIF Data
Task 4: Removing Any Proprietary Directory Data from the LDIF File
Task 6: Removing Incompatible userPassword Attribute Values from the LDIF File
Task 7: Adding the Oracle Internet Directory Object Classes to the LDIF Files
Task 8: Running bulkload.sh to Find Any Remaining Schema Violations or Duplication Errors (Optional)
Task 9: Importing the Modified LDIF Files into the Oracle Internet Directory Server
Task 10: Converting the Directory Entries from Netscape to Oracle Internet Directory Format
Use the ldapsearch
command with the following syntax to export directory entries for resources:
$ORACLE_HOME/bin/ldapsearch -h Netscape_directory_server_hostname -p Netscape_directory_server_port -D manager_DN -w manager_DN_password -b baseDN "objectclass=ctcalresource" > resources_LDIFfile
Use the ldapsearch
command with the following syntax to export directory entries for users and event calendars:
$ORACLE_HOME/bin/ldapsearch -h Netscape_directory_server_hostname -p Netscape_directory_server_port -D manager_DN -w manager_DN_password -b baseDN "objectclass=inetorgperson" > users_LDIFfile
The entries in the resulting LDIF files should look similar to the following:
dn: uid=hmoore,ou=People, dc=ca,dc=oracle,dc=com uid:hmoore sn:Moore cn:Henry Moore objectclass:top objectclass:person objectclass:organizationalPerson objectclass:inetorgperson objectclass:ctCalUser givenname:Henry ctcalxitemid:00010:00259 ctcalpublishedtype:0 ...
Note:
With some older versions ofldapsearch
, the line beginning dn:
is not included in the file and all colons (:) are replaced by the equal to sign (=). In this case, modify the file so the user entries follow the same format as the example given.Before you import the LDIF files, you must add any attributes that are not in the Oracle Internet Directory base schema to the Oracle Internet Directory base schema.
If there were any modifications made to the base schema of your current directory server, you must make the same modifications to the base schema of the Oracle Internet Directory. However, this is only necessary if you also want to transfer the information in these attributes to the Oracle Internet Directory.
Some directory servers may support the use of configuration files for defining extensions to their base schema. However, Oracle Internet Directory does not. If you have a configuration file for your directory server, you can use it as a guideline for extending the base schema of the Oracle Internet Directory.
Use either the Oracle Directory Manager or the SchemaSynch tool to extend the schema in Oracle Internet Directory.
See Also:
Oracle Internet Directory Administrator's GuideVarious directory vendors implement access control item (ACI) policy objects in ways that do not translate well across vendor installations. Therefore, remove any ACI entries from the LDIF file.After the basic entry data has been imported from the cleaned up LDIF file to Oracle Internet Directory, you must explicitly reapply security policies in the Oracle Internet Directory environment. You can do this by using either Oracle Directory Manager, or command-line tools and LDIF files containing the desired access control policy (ACP) information.There may be other proprietary metadata unrelated to access control. You should remove this as well. Understanding the various Internet Engineering Task Force (IETF) Requests For Comments (RFCs) can help you determine which directory metadata is proprietary to a given vendor and which complies with the LDAP standards, and is portable using an LDIF file.
Remove the following four operational attributes from the LDIF file:
creatorsName
createTimestamp
modifiersName
modifyTimestamp
These standard operational attributes are automatically generated by Oracle Internet Directory whenever entries are created or imported. It is not possible to instantiate these values by importing an LDIF file. Therefore, you should remove these attributes before importing the file.
Oracle Internet Directory supports the following userPassword
attribute hash algorithms:
No encryption
MD4
MD5
SHA
UNIX Crypt
If the userPassword
attribute hash algorithm used by your directory server is not one of these, then remove all lines corresponding to the userPassword
attribute and value from the LDIF data file. After you import the LDIF data into Oracle Internet Directory, manually re-enter or upload the hashed userPassword
information into the directory.
Many of the Oracle Collaboration Suite applications expect the user entry to contain orclUser
and orclUserV2
object classes. Use the following script (convert.sh
) to add these object classes to each user entry in the LDIF file.
Note:
To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:Cygwin
MKS Toolkit
Visit http://www.datafocus.com/products/tk/default.asp
The convert.sh Script
#!/bin/sh SOURCEDN="ou=people, <basedn>" TARGETDN="cn=users, <basedn>" if [ "$1" = "" ] then echo "usage: convert.sh filename" exit 2; fi FILENAME=$1 while read XX do if [ ! -z "`echo $XX | grep "$SOURCEDN"`" ] then # add "dn: " if necessary if [ -z "`echo $XX | grep "^dn:"`" ] then echo -n "dn: " >> $FILENAME.$$ fi echo $XX | sed "s/$SOURCEDN/$TARGETDN/g" >> $FILENAME.$$ echo "objectclass: orclUser" >> $FILENAME.$$ echo "objectclass: orclUserV2" >> $FILENAME.$$ else echo $XX >> $FILENAME.$$ fi done < $FILENAME \mv $FILENAME.$$ $FILENAME
After you run convert.sh
, the user entries in the LDIF file should look similar to the following:
dn: uid=hmoore,cn=users,dc=ca,dc=oracle,dc=com objectclass: orclUser objectclass: orclUserV2 uid:hmoore sn:Moore cn:Henry Moore objectclass:top objectclass:person objectclass:organizationalPerson objectclass:inetorgperson objectclass:ctCalUser givenname:Henry ctcalxitemid:00010:00259 ctcalpublishedtype:0
You are now ready to import the directory entries into the Oracle Internet Directory server.
Before you import the LDIF files, you can use the bulkload utility in check mode to perform a check on the LDIF file. The bulkload output reports any inconsistencies in the data.
Note:
To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:Cygwin
MKS Toolkit
Visit http://www.datafocus.com/products/tk/default.asp
See Also:
Oracle Internet Directory Administrator's GuideImport the modified LDIF files into the Oracle Internet Directory server using the following:
$ORACLE_HOME/bin/ldapadd -h OID_hostname -p OID_port -D "cn=orcladmin" -w orcladmin_password -f LDIFfile
Configure the synchronization between Oracle Internet Directory and the iPlanet, Netscape, or Sun ONE directory server.
The following are the tasks that you require to perform to configure the synchronization:
Task 2: Creating a Retro Changelog Plugin on the iPlanet/Sun ONE 5.x Directory Server
Task 3: Configuring Synchronization with Oracle Internet Directory
The Oracle Internet Directory synchronization service needs to bind to a user account to access and optionally modify data on the iPlanet, Netscape, or Sun ONE directory server. Although it is possible to use an existing entry, it is highly recommended to create a new entry for this purpose. Take note of the distinguished name and the distinguished name password used for this entry.
Note:
Ensure the account password contains at least eight characters.The synchronization user account must have certain access rights so that the Oracle Internet Directory synchronization service can perform the required operations. For example, if you wish to establish a one-way synchronization from the iPlanet, Netscape, or Sun ONE directory server to Oracle Internet Directory, the user account needs to have read access to the subtree and to all object classes and attributes to be synchronized. On the other hand, if you wish to establish a two-way synchronization, this user account need only have write access to the subtree.
The DIP synchronization service relies on a changelog
capability to monitor any changes in the external directory server.
In the iPlanet or Sun ONE 5.x directory server, the changelog
format has been modified and it is no longer compatible with DIP synchronization service. You must enable the Retro Changelog Plugin capability in the iPlanet or Sun ONE 5.x directory server in order to use the DIP synchronization service.
To enable the Retro Changelog Plugin feature in the iPlanet or Sun ONE directory server:
Create an LDIF file with the following content:
dn: cn=Retro Changelog Plugin, cn=plugins,cn=config changetype: modify replace: nssldapd-pluginenabled nssldapd-pluginenabled: on
Apply the LDIF file using ldapmodify
as follows:
$ORACLE_HOME/bin/ldapmodify -h iplanethost -p iplanetport -D iplanetmgrdn -w iplanetmgrpassword -f ldif_filename
Navigate to the slapd-hostname
directory and run the following commands as root
to restart the directory server.
./stop-slapd ./start-slapd
Once the external directory server is up, proceed with the following steps to configure the Oracle Internet Directory synchronization:
Start the directory server console and log in as cn=manager
with the password as Directory.
Click the Server and Application tab.
In the navigation tree, expand the ServerGroup container.
Select the directory server instance to synchronize then click Open.
A window for managing the directory server instance you selected is displayed.
Click the Configuration tab.
Select the Replication container.
Click the Consumer Settings tab (Legacy Consumer Settings on iPlanet/Sun ONE 5.x directory server) and enter the synchronization user credentials.
In the Supplier DN field, enter the distinguished name of the synchronization user.
In the New Supplier Password field, enter the password for the synchronization user then click Confirm.
Take note of these credentials as you will need them for the Oracle Internet Directory synchronization profile.
Save the settings.
Click the Supplier Settings tab.
Set the Changelog Database Directory, if it has not been set.
Save the settings.
Obtain the value of the lastchangenumber
attribute as you will need this value later. Use the following command:
$ORACLE_HOME/bin/ldapsearch -h iPlanetHost -p iPlanetPort -D manager dn -w manager password -b "" -s base "objectclass=*" "lastchangenumber"
To log in to an LDAP-enabled application users need to enter a login attribute and a password. On Netscape, iPlanet, or Sun ONE servers, the uid
(user ID) attribute is the one that is typically used. On Oracle Internet Directory servers, the attribute is configurable and the default is the cn
attribute.
You can specify the uid
attribute as the login attribute on the Oracle Internet Directory server so that end-users can use the same login for LDAP-enabled applications connected to a Netscape, iPlanet, or Sun ONE directory server and for LDAP-enabled applications connected to an Oracle Internet Directory server.
To set uid
as a login attribute, use the following steps:
Create an LDIF file with the following contents.
dn: cn=Common, cn=Products, cn=OracleContext, <basedn> changetype: modify replace: orclcommonnicknameattribute orclcommonnicknameattribute: uid
Use the ldapmodify
command to change the login attribute to uid
as follows.
$ORACLE_HOME/bin/ldapmodify -h <OIDhost> -p <OIDport> -D cn=orcladmin -w <orcladminpassword> -f <LDIFfilename>
The mapping rules specify which attributes are synchronized between the Netscape, iPlanet, or Sun ONE server and Oracle Internet Directory. The rules are defined in a mapping file which resides on the Oracle Internet Directory server.
To set the mapping rules:
Using a text editor open the default mapping file at $ORACLE_HOME/ldap/odi/conf/iplanet.map.master
Edit the domain rule to match your directory hierarchy. For example, given a source DN of ou=people,dc=ca,dc=oracle,dc=com
and a target DN of cn=users,dc=oracle,dc=com
the domain rule will be: ou=people,dc=ca,dc=oracle,dc=com:cn=users,dc=oracle,dc=com
Edit the mapping file to define the mapping rules needed for your configuration.
The completed file should look similar to the following:
DomainRules ou=people,dc=ca,dc=oracle,dc=com:cn=users,dc=ca,dc=oracle,dc=com AttributeRules # Mapping rules to map the domains and containers o: : :organization: o: :organization ou: : :organizationalUnit: ou: : organizationalUnit dc: : :domain:dc: :domain # Mapping Rules to map users uid : : :person: uid: :inetOrgperson sn: : :person:sn: :organizationalperson cn: : :person:cn: :person cn: : :person:orclisVisible: :orclUserV2:"True" mail: : :inetorgperson: mail: :inetorgperson employeenumber: : :organizationalPerson: employeenumber: :organizationalperson c: : :country:c: :country l: : :locality: l: :locality telephonenumber: : :organizationalPerson: telephonenumber: :organizationalperson userpassword: : :person:userpassword: :person title: : :inetorgperson:title: :inetorgperson givenname: : :inetorgperson:givenname: :inetorgperson #Mapping rule to map calendar item cn: : :person:cn: :ctcaluser ctcalxitemid: : :ctcaluser:ctcalxitemid: :ctcaluser ctcalpublishedtype: : :ctcaluser:ctcalpublishedtype: :ctcaluser
Note:
Ensure you have no extra spaces at the end of each line and no extra blank lines at the end of the file.Save the edited file with a .map
extension (for example, iplanetmapfile.map
).
Once the mapping rules have been set, create an integration profile and register it to the Oracle Internet Directory server. This enables the synchronization service. The integration profile contains the information needed to synchronize data with the iPlanet directory server.
To configure an integration profile:
Use the following command to upload the mapping file to the Oracle Internet Directory server.
OracleHome_path/ldap/odi/admin/ldapUploadAgentFile.sh -name IplanetImport -LDAPhost OIDhostname -LDAPport OIDport -binddn cn=orcladmin -bindpass orcladminpassword -config 1 -attrtype "MAP" -filename fullpath/iplanetmapfile.map
Note:
Make $ORACLE_HOME/bin
the first path in the PATH environment variable.
Use the full path for the executable and the file location.
Start the Oracle Directory Manager. Use the following command:
$ORACLE_HOME/bin/oidadmin&
Establish a connection to the Oracle Internet Directory server and log in as the directory manager.
Expand the Server Management container.
Expand the Integration Server container and then select the appropriate configuration set. In most cases, this is the first configuration set.
Double-click the iPlanetImport profile.
The Integration Profile: IPlanetImport window is displayed.
Click the Execution tab.
In the Connected Directory Account and Connected Directory Account Password fields, enter the distinguished name and distinguished name password of the synchronization user account created earlier.
In the Connected Directory URL field, enter the hostname and port number of Netscape, iPlanet, or Sun ONE directory server. For example: iPlanet.oracle.com:589
.
Caution:
It is very important to leave the Agent Execution Command field blank.Click the Mapping tab.
Steps 11 and 12 prevent the same change from being exchanged between the two directories indefinitely.
In the Connected Directory Matching Filter field, enter the following:
modifiersname != <the distinguished name of the synchronization user>
In the OID Matching Filter field, enter the following:
modifiersname != orclodipagentname=iPlanetImport, cn=subscriber profile,cn=changelog subscriber, cn= oracle internet directory
Click the Status tab.
In the Last Applied Change Number field, enter the lastchangenumber
attribute value obtained from the iPlanet directory server earlier.
For the synchronization to be successful, the Oracle DIP agent requires access rights to the user entries in the Oracle Internet Directory. Use Oracle Directory Manager to grant the necessary access rights.
To grant access rights to the Oracle DIP agent:
In the Oracle Directory Manager interface, navigate to the System Objects navigation tree.
In the System Objects navigation tree navigate to Entry Management, cn=OracleContext, cn=Groups, cn=IASAdmins
.
Click the Properties tab.
In the uniquemember field, add the following user:
orclodipagentname=IplanetImport,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory
Repeat this procedure for the following groups:
cn=OracleDASCreateUser
cn=OracleDASDeleteUser
cn=OracleDASEditUser
You must also propagate the access controls that you have set up in the Netscape, iPlanet, or Sun ONE directory server. For example, if you have an access control that says "only users with the attribute ou=HR Department
is able to read the user salary attribute", you must create an equivalent access control in Oracle Internet Directory.
SeeAlso:
Oracle Internet Directory Administrator's Guide for more information on modifying access controlsThe Oracle Directory Integration Server provides the synchronization service.
See Also:
Oracle Internet Directory Administrator's Guide for more information on the Oracle Directory Integration ServerTo start the synchronization service:
Use the following command to start the Oracle Directory Integration Server.
$ORACLE_HOME/bin/oidctl connect=database_instance_name server=odisrv instance=1 configset=1 flags="port=OIDport" start
Note:
Ensure theORACLE_HOME
and ORACLE_SID
environment variables have been set.Click the General tab.
Ensure the Profile Status is set to ENABLE
.
Click the Status tab and verify that the Synchronization Status is Synchronization Successful.
The directory servers are now synchronized.
At this point, you have the following setup:
The old Calendar standalone server with a node network pointing to the iPlanet server
The new Oracle Collaboration Suite server installed and configured with a default node
A synchronization established between the Netscape, iPlanet, or Sun ONE Directory server and Oracle Internet Directory
Migrating the Calendar database involves moving a node from the Netscape, iPlanet, or Sun ONE server to the Oracle Collaboration Suite server then reconfiguring the node network to recognize this change. This section describes the steps required to complete the migration and reconfiguration for a node network.
The following are the tasks that you require to perform to migrate the Calendar database:
Task 3: Creating a Calendar Node Entry on Oracle Internet Directory
Task 4: Enabling the Replication of Calendar Data Between the Nodes
Task 5: Regenerating the nodes.ini Files on both Calendar Servers
If you only have a single node as opposed to a node network, perform the steps listed in "Task 1: Moving the Database" and "Task 3: Creating a Calendar Node Entry on Oracle Internet Directory".
To move the Calendar database from Netscape, iPlanet, or Sun ONE Directory server to the Oracle Collaboration Suite server:
Copy the master node directory ($ORACLE_HOME/ocal/db/nodes/N0
) of the database, from the Calendar standalone server to the new server in the Oracle Collaboration Suite.
Copy the [CLUSTER]masternode
entry from the unison.ini
file on the Calendar standalone server to the unison.ini
file on the Oracle Collaboration Suite.
Note:
Legacy systems with only a single node may not have this[CLUSTER]masternode
entry in the unison.ini
file. If this is the case, skip this step and the next.In the unison.ini
file on the Calendar standalone server, comment out the [CLUSTER]masternode
entry as shown in the following example:
#[CLUSTER] #masternode = 10
Copy the node information for the master node from the unison.ini
file on the Calendar standalone server to the unison.ini
file on the Oracle Collaboration Suite.
In the unison.ini
file on the Calendar standalone server, comment out the node information for the master node as shown in the following example:
#[10] #name = N0 #version = A.06.00 #timezone = EST5EDT #[CLUSTER] #masternode = 10 [21] name = N1 version = A.06.00 timezone = EST5EDT
In the unison.ini
file on the Oracle Collaboration Suite, comment out the information on the installed node (not the master node information that was just placed in the file).
The unison.ini
file should look similar to the following:
[CLUSTER] masternode=10 #This is the information for the database copied from the iPlanet server #calserver $ORACLE_HOME/ocal/db/nodes/N0 to the Oracle Internet Directory calendar server #$ORACLE_HOME/ocal/db/nodes/N0 [10] name = N0 version = A.06.00 timezone = EST5EDT #Here is the node ID that was installed with the Collaboration Suite Calendar #server. It has been replaced with the new node. #[11] #name = N0 #version A.06.00 #timezone = EST5EDT
To preserve the node network and the related events and attendees information update the remotenode.ini
file of each and every node in the Calendar node network. In the following procedure, the variable iplanet_node
represents the node that is kept on the old Netscape, iPlanet, or Sun ONE server and the variable OID_node
represents the node that was moved to the new Oracle Collaboration Suite server. The steps to update the node network information are:
On the Calendar standalone server, run the following command:
$ORACLE_HOME/ocal/bin/unidbfix -export -n iplanet_node
This creates the $ORACLE_HOME/ocal/db/nodes/N1/perm/remotenode.ini
. file
Open the $ORACLE_HOME/ocal/db/nodes/N1/perm/remotenode.ini
file.
The contents of the file should appear similar to the following:
[10] RN_NUMCONNECT = 2 RN_ACCESSMETHOD = 2 RN_SERVICENAME = "unieng" RN_HOSTNAME = "standalone.ca.acme.com:5802"
Modify the remotenode.ini
file with the new hostname and port of Oracle Collaboration Suite. The contents of the file should appear similar to the following:
[10] RN_NUMCONNECT = 2 RN_ACCESSMETHOD = 2 RN_SERVICENAME = "unieng" RN_HOSTNAME = "ocs.ca.acme.com:5872"
Update the remote host information with the following command:
$ORACLE_HOME/ocal/bin/unidbfix -import -n iplanet_node
On the Oracle Collaboration Suite server run the following command:
$ORACLE_HOME/ocal/bin/unidbfix -export -n OID_node
The variable OID_node
is the node ID of the node that was copied to the Oracle Collaboration Suite server. This creates the $ORACLE_HOME/ocal/db/nodes/N0/perm/remotenode.ini
file.
Use the Oracle Directory Manager to create an entry on the Oracle Internet Directory server for the node that was moved.
Navigate to Entry Management, cn=Oracle Context, cn=Products, cn=Calendar, cn=Node
installed_node
The variable installed_node
represents the node that was created when you installed Calendar.
Right-click cn=Node
installed_node
and select Create Like.
In the Distinguished Name field, change cn=Node
to installed_node
cn=Node
new_node
.
The variable new_node
represents the node that was copied to the Oracle Collaboration Suite server.
Click the Mandatory Properties tab.
In the cn
field, type Nodes
new_node.
Click the Optional Properties tab.
Set the value of orclCalendarStore
to new_node
and click OK.
In the unison.ini
file of the Oracle Collaboration Suite server set the [ENG]coexist_cwbasicauth
parameter to TRUE
.
To regenerate the nodes.ini
files:
Start both servers.
Rename the nodes.ini
file on the Calendar server pointing to the Netscape, iPlanet, or Sun ONE directory server to nodes.ini.old
.
Run the following command on the Oracle Collaboration Suite server:
uninode -init
This generates the nodes.ini
files with proper node network information on both servers.
The migration is now complete.
This scenario assumes that once the migration is complete the user accounts will be managed through the Oracle Internet Directory server. The section contains the following:
Note:
This procedure assumes that you have already upgraded the Oracle Calendar standalone installation to the latest release of Oracle Calendar.When you install the Oracle Collaboration Suite, use the same node network configuration (nodes and node IDs) as your current configuration.
Refer to Oracle Collaboration Suite Installation Guide for Microsoft Windows for installation details.
Once you have Oracle Collaboration Suite installed you can migrate the directory entries from the Netscape, iPlanet, or Sun ONE directory server to the Oracle Internet Directory server.
Perform the following tasks to migrate directory entries:
Task 3: Analyzing the LDIF Files for Any Required Schema Additions Referenced in the LDIF Data
Task 5: Removing Any Proprietary Directory Data from the LDIF File
Task 7: Removing Incompatible userPassword Attribute Values from the LDIF File
Task 8: Adding the Oracle Internet Directory Object Classes to the User and Event Calendar Entries
Task 10: Importing the Modified LDIF Files into the Oracle Internet Directory Server
Task 11: Converting the Directory Entries from iPlanet to Oracle Internet Directory Format
Use the unistop
utility to stop both the old standalone Oracle Calendar server and the new Oracle Collaboration Suite server.
Use the ldapsearch
command with the following syntax to export directory entries for resources:
ldapsearch -h
iplanet_hostname
-p
iplanet_port
-D manager_DN -w
manager_DN_password
-b
baseDN
"objectclass=ctcalresource"
> users_LDIFfile
Use the ldapsearch
command with the following syntax to export directory entries for users and event calendars:
ldapsearch -h
iplanet_hostname
-p
iplanet_port
-D manager_DN -w
manager_DN_password
-b
baseDN
"objectclass=inetorperson"
> resources_LDIFfile
The entries in the resulting LDIF files should look similar to the following:
dn: uid=hmoore,ou=People, dc=ca,dc=oracle,dc=com uid:hmoore sn:Moore cn:Henry Moore objectclass:top objectclass:person objectclass:organizationalPerson objectclass:inetorgperson objectclass:ctCalUser givenname:Henry ctcalxitemid:00010:00259 ctcalpublishedtype:0 ...
Note:
With some older versions ofldapsearch
, the line beginning dn:
is not included in the file and all colons (:) are replaced by the equal to sign (=). In this case, modify the file so the user entries follow the same format as the example given.This task is identical to "Task 2: Analyzing the LDIF Files for Any Required Schema Additions Referenced in the LDIF Data".
This task is identical to "Task 3: Extending the Schema in Oracle Internet Directory".
This task is identical to "Task 4: Removing Any Proprietary Directory Data from the LDIF File".
This task is identical to "Task 5: Removing Operational Attributes from the LDIF File".
This task is identical to "Task 6: Removing Incompatible userPassword Attribute Values from the LDIF File"
This task is identical to "Task 7: Adding the Oracle Internet Directory Object Classes to the LDIF Files".
This task is identical to "Task 8: Running bulkload.sh to Find Any Remaining Schema Violations or Duplication Errors (Optional)".
This task is identical to "Task 9: Importing the Modified LDIF Files into the Oracle Internet Directory Server".
Migrating the Calendar database involves moving the Calendar nodes from the Netscape, iPlanet, or Sun ONE server to the Oracle Collaboration Suite server then reconfiguring the node network to recognize this change. This section describes the tasks required to complete this migration and reconfiguration. The tasks are:
To move the Calendar database to Oracle Collaboration Suite:
On the new Calendar server rename the $ORACLE_HOME/ocal/db
directory to $ORACLE_HOME/ocal/db_blank
.
Copy the $ORACLE_HOME/ocal/db
directory from the old standalone Calendar server to $ORACLE_HOME/ocal/db
on the new Calendar server.
Copy the $ORACLE_HOME/ocal/misc/nodes.ini
file from the old standalone Calendar server to $ORACLE_HOME/misc/nodes.ini
on the new Calendar server.
If the hostname of the new server has changed, do the following on the new Calendar server:
Run the following command:
unidbfix -export -n all
This creates the $ORACLE_HOME/ocal/db/nodes/N
#
/perm/remotenode.ini
file, where N#
is the value of the name
parameter in the unison.ini
section corresponding to the target node.
Modify the generated remotenode.ini
file. Replace the old hostname and port with the new hostname and port. The remotenode.ini should be modified for each and every node in the Calendar node network.
Update the host information with the following command:
unidbfix -import -n all
Modify the $ORACLE_HOME/ocal/misc/nodes.ini
file. Replace the old hostname and port with the new hostname and port.
Start the new Calendar server.
The migration is now complete.