In addition to the SSO and MetaData Repository components, we are also configuring the OID server to be highly available, thus enabling all the 3 components Viz. SSO webserver, MetaData Repository, OID server for High Availability. As part of the OID server high availability setup, I have installed a new Infrastructure node oid_serv2 with the OID and DIP components along with 'High Availability and Replication' in the installation option list.
Problem
A good way to test whether the new node serves Single Sign-On (SSO) requests is to shutdown the other existing OID server oid_serv1 in the Identity Management (IM) cluster. In addition, the OID server name has to be changed from oid_serv1 to oid_serv2 in the MetaData Repository database by running $ORACLE_HOME/sso/admin/plsql/sso/ssooconf.sql on the SSO server. However, I started recieving 'Error:Internal Server Error. Please try the operation later'.
Upon further investigation, I found the following errors in the $ORACLE_HOME/sso/log/ssoServer.log
Wed Feb 25 15:44:14 CST 2009 [ERROR] AJPRequestHandler-ApplicationServerThread-7 DirContextPool: OID connection not available. OID Server, oid_serv1.mycompany.com:636 may be down ...
Wed Feb 25 15:44:14 CST 2009 [ERROR] AJPRequestHandler-ApplicationServerThread-7 Communication Exception received. Cleaning up the stale connectionjavax.naming.CommunicationException: Could not get the connection. OID Server may be down
Solution
Changing the OID server name in $ORACLE_HOME/sso/admin/plsql/sso/ssooconf.sql alone does not seem to be enough for the SSO webserver to recognize the new OID server. I searched the configuration files in the SSO ORACLE_HOME and found a couple of additional references to the existing OID server, needing replacement with the newly installed OID server oid_serv2.
On the SSO ORACLE_HOME, change the following files, replacing oid_serv1 with oid_serv2 and then bouncing the processes using the opmnctl command.
- $ORACLE_HOME/config/ias.properties (OIDhost)
- $ORACLE_HOME/ldap/admin/ldap.ora (DIRECTORY_SERVERS)
Conclusion
The SSO Administration Guide mentions that running ssooconf.sql alone is enough to recognize the new OID server. However, as mentioned above, the SSO server does not seem to read the change from the database, but instead from its configuration files to get this working.