How to Disable EDIR/AUTHSERV Updates

Original Author: Beth Mercer - 20081031

EDIR, AUTHSERV and their shared update back end are configured to look for a lock file before presenting a form that supports directory updates. The lock file name is configured in the runtime_common.cfg or runtime.cfg files of the three applications:

~iplanet/UPDATE<INST>/config/runtime_common.cfg ~ldapgw/AUTH<INST>/config/runtime*.cfg ~ldapgw/EDIR<INST>/config/runtime*.cfg

Though the lock file can be separately configured, in practical terms all three applications must reference the same file. That is because scheduled processes that create and remove the lock file obtain the name from the UPDATE<INST>/config/runtime_common.cfg file.

As of September 2008, updates of userPassword, uakSecQuestion and uakSecResponse were configured to bypass the Oracle registry (to address significant outage related to weekly cold backups of registry databases). When that change was implemented, the test for the lock file had to be moved or alter in underlying code. Otherwise when the registry went down for backups, the presence of the lock file would have prohibited updates to attributes which didn't rely on the registry.

That issue should be resolved in some graceful manner. Perhaps through creation of a secondary lock file applicable to attributes that bypass the registry. In the meantime, the only way to insure that no updates are performed (actually, always the only way to insure no updates are performed) is to disable updates to all directory instances using the iPlanet console.

To disable directory updates regardless of source:

<<ssh to iplanet account on an "e" box>> <<start admin server and console>> <<navigate console and open a directory instance>> <<click on configuration tab>> <<highlight server:port line in left most frame>> <<check Server is Read Only box in Settings tab>> <<click Save>> <<repeat for all "e" boxes>>

To disable updates via the EDIR/AUTHSERV web gateways on all "e" boxes from either iplanet or ldapgw accounts (disables all updates excepting userPassword, uakSecQuestion and uakSecResponse):

At this writing (2/16/2010) the iplanet-owned version of disable_updates.ksh will not work because it looks for the all_servers configuration variable in runtime.cfg; all-servers is defined in runtime_common.cfg. The ldapgw-owned version of disable_updates.ksh will not work because ldapgw cannot ssh to elfin without providing a password, which the script requires.

<<ssh to iplanet account on an "e" box>> $HOME/local/ldap/scripts/disable_updates.ksh test $HOME/local/ldap/scripts/disable_updates.ksh prep $HOME/local/ldap/scripts/disable_updates.ksh prod

-OR-

<<ssh to ldapgw account on an "e" box>> $HOME/local/scripts/disable_updates.ksh test $HOME/local/scripts/disable_updates.ksh prep $HOME/local/scripts/disable_updates.ksh prod

To enable updates via the EDIR/AUTHSERV web gateway on all "e" boxes from either iplanet or ldapgw accounts:

At this writing (2/16/2010) the enable_update scripts will not work for the same reasons as their disable_update counterparts.

<<ssh to iplanet account on an "e" box>> $HOME/local/ldap/scripts/enable_updates.ksh test $HOME/local/ldap/scripts/enable_updates.ksh prep $HOME/local/ldap/scripts/enable_updates.ksh prod

-OR-

<<ssh to ldapgw account on an "e" box>> $HOME/local/scripts/enable_updates.ksh test $HOME/local/scripts/enable_updates.ksh prep $HOME/local/scripts/enable_updates.ksh prod

As of 10/26/2007, the process of shutting down and then starting the registry databases (RPTT, RPTQ and RPTS) now results in EDIR/AUTHSERV updates being disabled (before database shutdown) and then re-enabled (after database startup). The scripts called as part of the shutdown/startup process are these:

<<ssh to iplanet account on an "e" box>> $HOME/local/ldap/scripts/oracle_disable_updates.ksh test $HOME/local/ldap/scripts/oracle_disable_updates.ksh prep $HOME/local/ldap/scripts/oracle_disable_updates.ksh prod

-OR-

<<ssh to iplanet account on an "e" box>> $HOME/local/ldap/scripts/oracle_enable_updates.ksh test $HOME/local/ldap/scripts/oracle_enable_updates.ksh prep $HOME/local/ldap/scripts/oracle_enable_updates.ksh prod

The oracle_[en|dis]able_updates.ksh script differ from the [en|dis]able_updates.ksh scripts in that the oracle scripts will NOT enable updates if the disable was performed by some process other than the oracle_[en|dis]able_updates.ksh script. If someone manually touches the gateway_updates_disabled file or runs the disable_updates.ksh script, then the disabled file must removed manually or by running the enable_updates.ksh script.

####################### DOCUMENT CHANGE HISTORY

20081028 elm Expanded on processes for disabling updates particularly since change that

allows userPassword, uakSecQuestion and uakSecResponse updates to bypass the registry.

20081031 elm corrected typos