IBM(R) DISTRIBUTED COMPUTING ENVIRONMENT (DCE) VERSION 3.2 FOR AIX(R) AND SOLARIS README ADDENDA ===================================================== (C) Copyright IBM Corporation 2001. All rights reserved. NOTE: See 12.0 NOTICES for complete copyright citation. ===================================================== CONTENTS 1.0 ABOUT THIS README ADDENDA 2.0 LDAP CONSIDERATIONS 2.1 e-fix for IBM SecureWay(R) Directory server 2.2 Concurrent read/write requirement 2.3 Change LDAP size limit for dcecp catalog commands in IBM SecureWay Directory server 2.4 CreatorsName attribute using ldif2db and replication 2.5 Errors during schema modification 3.0 AIX CONSIDERATIONS 3.1 Considerations when running customer applications on AIX 3.2 dcf_ulimit command added to dcecp 3.3 dcf_ulimit command 4.0 DCE 3.2 PERFORMANCE CONSIDERATIONS AND TUNING TIPS 4.1 Tuning secd 4.1.1 Tuning multiple connections to the LDAP server 4.1.2 Tuning the number of propagation threads 4.1.3 Tuning which secd is the initiator of an init_rep 4.2 Tuning DB2(R) when using IBM SecureWay LDAP 4.3 Tuning LDAP 4.3.1 Tuning the IBM SecureWay LDAP server 4.3.2 Tuning the iPlanet/Netscape LDAP server 4.4 Hardware 4.5 Network 4.6 Initial migration expectations 4.7 DCE application considerations 4.8 User tasks (login, chpasswd) 4.9 Admin tasks (user create, user delete) 5.0 LOCALE CONSIDERATIONS 5.1 Solaris LDAP client problem with UTF-8 (Solaris only) 5.2 LDAP failures related to unsupported locale settings 6.0 REQUIRED REGISTRY VERSION MODIFICATION 6.1 Ensure that all replicas have the same registry version number before migrating to the LDAP master 6.2 Registry modify -version attempts to wait for sequence numbers to match 7.0 MIGRATION CONSIDERATIONS AND POSSIBLE ERROR SITUATIONS 7.1 Registry migrate requires some parameters to be fully qualified 7.2 Stopping registry migrate does not stop propagation of DCE data to LDAP 7.3 LDAP slave migration failures 7.4 LDAP master migration failure 7.5 Messages after ticket expires while migrating 8.0 CONDITIONS FOR SECD RESTART 8.1 Restart secd to change key database files with SSL 8.2 LDAP_SERVER_DOWN condition 9.0 REGISTRY SELECTION WITH THE TRY PE_SITE ENVIRONMENT VARIABLE 9.1 Always point the CDS primary server to an in-service security server 9.2 Must have additional security server IP address in pe_site file on a force migration 10.0 REGISTRY LIMITATIONS USING LDAP 10.1 Naming restrictions 10.2 Cannot delete preexisting LDAP accounts 11.0 MISCELLANEOUS 11.1 Manually back up files that dceback cannot back up 11.2 Changing the IP address in a split config environment 11.3 DCE documentation - start_dcedoc 12.0 NOTICES 12.1 Trademarks and service marks ===================================================== 1.0 ABOUT THIS README ADDENDA This file contains additional changes and updates to the README file shipped with DCE Version 3.2 for AIX and Solaris. Note: Do not include the quotation marks in commands. ===================================================== 2.0 LDAP CONSIDERATIONS ===================================================== 2.1 e-fix for IBM SecureWay(R) Directory server In the "DCE Security Registry and LDAP Integration Guide", "Chapter 2, Planning Considerations", in the section "Supported versions of LDAP", the following sentence is incorrect: "The IBM SecureWay Directory client requires a minimum e-fix of 3.2.2-SWD-0001". The preceding sentence must be substituted with the following: "The IBM SecureWay Directory server requires a minimum e-fix of 3.2.1-SWD-004". In addition, if you are running in the UTF-8 locale on Solaris, e-fix 3.2.1-SWD-005 is required. See Section 5.1 for more details. e-fixes are available on the IBM SecureWay Web site at www.ibm.com/secureway/directory. ===================================================== 2.2 Concurrent read/write requirement If you are using the IBM SecureWay Directory server as a backing store, the LDAP server must be set up to use concurrent read/write. If this is not done, deadlocks between LDAP and DCE might occur. Modify the following stanza in your slapd32.conf file to add the LDAP_CONCURRENTRW attribute: dn: cn=Front End, cn=Configuration cn: Front End ibm-slapdSetenv: LDAP_CONCURRENTRW=ON objectClass: top objectClass: ibm-slapdFrontEnd With an iPlanet/Netscape Directory, concurrent read/write is the default configuration. ===================================================== 2.3 Change LDAP size limit for dcecp catalog commands in IBM SecureWay Directory server dcecp catalog commands such as "dcecp -c principal cat" and "dcecp -c account cat" might not return all the principal data if the value of ibm-slapdSizeLimit is set too low. The default value is 500, which enables information to be returned for approximately 480 principals. The ibm-slapdSizeLimit is defined in /usr/ldap/etc/slapd32.conf. ===================================================== 2.4 CreatorsName attribute using ldif2db and replication The krbTrustedAdmObject attribute or the krbKdcServiceObject attribute must contain Distinguished Names (DNs) for all users or applications that are expected to create DCE data in LDAP. This includes all DCE security servers, Network Authentication Service KDC servers, and other LDAP administrative applications. If the LDAP directory for the DCE cell is restored using a directory import tool, the krbTrustedAdmObject attribute or the krbKdcServiceObject attribute of the LDAP entry for the cell must be updated to include the authorization DN used by the tool prior to starting DCE. In the case of using ldif2db to restore an IBM SecureWay directory, this is the DN of the LDAP directory administrator. In addition, if any directory server's replication feature is used to provide LDAP replicas of the registry, the krbTrustedAdmObject and krbKdcServiceObject attributes for the cell entry at the LDAP master server must be updated to include the DN used by the LDAP supplier, or consumer, for each replica. ===================================================== 2.5 Errors during schema modification When modifying the schema for the iPlanet Directory server, an error might be reported on the attempted modification of the passwordMinAge and gecos attributes. These modifications deal with either the OID or syntax of the attribute. Neither of these errors affect the operation of DCE or any other application using the iPlanet Directory server. ===================================================== 3.0 AIX CONSIDERATIONS ===================================================== 3.1 Considerations when running customer applications on AIX If your application encounters the message (or exception): No memory for RPC (dce/rpc) it is possible your application has reached the default datasize limit of 128 MB. Increase the datasize limit for the application in order to overcome this problem. In addition, you might need to consider using the AIX large memory model for applications that have a larger footprint than 256 MB. ===================================================== 3.2 dcf_ulimit command added to dcecp If you want to change the datasize ulimit for DCE only and not for any other applications running on the system, you can use the "dcecp -c dcf_ulimit" command within the /opt/dcelocal/tcl/user_cmd.tcl file. A sample of how to use this command in a user_cmd.tcl file can be found in /opt/dcelocal/tcl/user_cmd.sample.tcl. Refer to Section 3.3 for the syntax of this command. ===================================================== 3.3 dcf_ulimit command A command has been added to dcecp called dcf_ulimit. dcf_ulimit acts much like ulimit. It takes multiple command line parameters. If -?, -help, or help are entered with the dcf_ulimit command, the following is displayed: dcf_ulimit [-S|-H] -f -c -t -d -s -m -n You can use the ulimit -a command from within dcecp (or a tcl script) to view the current ulimit settings. However, the -a parameter is not supported with dcf_ulimit. The ulimit command in the operating system takes 64-bit values. Because dcecp is a 32-bit program, it is restricted by the size of the integer it must pass to the setrlimit API. Here are the maximum values that can be passed in using the dcf_ulimit command: -f FSIZE 4194303 -c CORE 4194303 -t CPU 2147483647 -d DATA 2097151 -s STACK 2097151 -m RSS 2097151 -n NOFILE 2147483647 The keyword "unlimited" is also permitted as a value for any of the parameters. In general, The dcf_ulimit command acts the same way as the ulimit command. ===================================================== 4.0 DCE 3.2 PERFORMANCE CONSIDERATIONS AND TUNING TIPS ===================================================== Using the DCE 3.2 feature to migrate DCE security information to an LDAP directory has certain performance considerations. Moving the DCE security registry from an in-memory database (the model in legacy DCE) to an on-disk LDAP database has performance impacts. These impacts vary depending on what stage of migration a cell is in. Customers might see higher performance impacts in a hybrid cell (meaning a cell containing both legacy security servers and LDAP servers that co-exist) versus a cell that has been fully migrated to LDAP. This is due to the overhead associated with propagating updates to LDAP as well as to the legacy DCE security servers. In general, it is recommended that customers with DCE applications that make frequent updates to the security registry and then expect to immediately access those updates do one of the following: o Avoid running in a hybrid environment for an extended period of time. o Use security preferencing to direct security requests made by these applications to legacy DCE security servers. There are a number of additional performance tuning considerations associated with the LDAP integration feature as described in the following sections. ===================================================== 4.1 Tuning secd ===================================================== 4.1.1 Tuning multiple connections to the LDAP server The MAX_CONNECTIONS environment variable determines the number of connections a security server has to the LDAP database. The current default is 8, and this is sufficient for most customer environments. However, there are scenarios that might require additional connections. One example is an environment which sustains a significant concurrent login workload. In a multiprocessor environment, you might also want to increase the number of connections to take advantage of the increased system capacity. Anytime the MAX_CONNECTIONS environment variable is modified, the security server on that system must be restarted. The maximum number of supported connections is 64. ===================================================== 4.1.2 Tuning the number of propagation threads To have simultaneous propagation to a legacy replica and the LDAP migration server in cell which only has 3 security servers, set the existing MAX_SEC_PROP_THREADS environment variable on the master security server to 2. If there are more than 3 security servers in the cell, the number of threads is automatically increased to 2 by secd. ===================================================== 4.1.3 Tuning which secd is the initiator of an init_rep Use the SEC_REP_INIT_FROM_UUID environment variable on the master security server to specify the legacy replica from which the security registry is received during the migration to LDAP. Set this variable to the Universal Unique Identifier (UUID) of a legacy replica before issuing the dcecp registry migrate command on the migration server. To get the UUID, issue the "sec_admin" command, then type "lr -all". The UUID is the Instance ID of the server. After setting this environment variable, you must stop and restart the master security server. Using this environment variable prevents the legacy master from being used for the initialization. If the legacy master is used for the initialization, it is put into maintenance mode for the duration of the migration. Although legacy security replicas can perform this function, LDAP servers cannot. Don't set the SEC_REP_INIT_FROM_UUID environment variable to the UUID of an LDAP slave. ===================================================== 4.2 Tuning DB2(R) when using IBM SecureWay LDAP Note: The instructions in this section assume that you are using the default LDAP DB2 user id (ldapdb2). If you are using a different LDAP DB2 user id, please make the appropriate substitutions. It is not always the case that the bigger the DB2 cache, the fewer the I/O accesses. A better strategy is to increase the capacity of the LDAP caches. In general, minimize the size of the DB2 buffer pool and maximize the LDAP entry and filter caches. The following examples use AIX commands. Use the applicable operating system commands depending on where your LDAP server is located. Example Steps - DB2 (when using IBM SecureWay LDAP) 1. Login as the DB2 superuser ldapdb2, for example: su -ldapdb2 2. Check the existing SHEAPTHRES (the sort heap threshold), for example: db2 get dbm config | grep SHEAP 3. Reset the existing SHEAPTHRES to 20000, for example: db2 update db manager config using SHEAPTHRES 20000 4. Start DB2, for example: db2start 5. Connect to LDAP/DB2, for example: db2 connect to ldapdb2 6. Check the existing BUFFPAGE (the buffer pool size), for example: db2 get db config for ldapdb2 | grep BUFF 7. Get the system memory size (in MB), for example: lsattr -E -l mem0 8. The default BUFFPAGE shipped with DB2 is 1000 (4 KB pages) which may not be big enough for a large database. If your system has a great deal of memory (1 GB or greater) then use a common sense approach to figure the amount of memory (probably not 50%) you allocate for the BUFFPAGE amount. If you are running with approximately 512 MB of memory or less, following the algorithm will be useful. To reset BUFFPAGE: db2 update db config for ldapdb2 using BUFFPAGE nnnnn where nnnnn is calculated as follows (50% of system allocated to buffer pool): nnnnn = system memory MB * 50% / 4KB (Since 1 page = 4 KB) 9. If you increase the BUFFPAGE parameter, you should also increase the DBHEAP size by 1 for every 30 incremented in the BUFFPAGE parameter. To check the existing DBHEAP (the database heap), for example: db2 get db config for ldapdb2 | grep DBHEAP 10. As an example, to reset the DBHEAP to 1700 you would run the following command: db2 update db config for ldapdb2 using DBHEAP 1700 11. Check the existing SORTHEAP (the sort list heap), for example: db2 get db config for ldapdb2 | grep SORTHEAP 12. Use the DB2 Database Monitor tool to figure out an appropriate value for the SORTHEAP parameter. To reset the SORTHEAP: db2 update db config for ldapdb2 using SORTHEAP nnnn where nnnn = increase by BUFFPAGE / 30 13. Check the existing MAXLOCKS (the percent of lock lists per application), for example: db2 get db config for ldapdb2 | grep MAXLOCKS 14. Use the DB2 Database Monitor tool to figure out an appropriate value for the MAXLOCKS parameter. For example, to reset the MAXLOCKS to 100: db2 update db config for ldapdb2 using MAXLOCKS 100 15. Reset the bufferpool, for example: db2 alter bufferpool ibmdefaultbp size -1 Note: -l is a "one", not an L 16. Restart db2 to enable the above changes, for example: db2stop db2start For more information on tuning DB2, see www.software.ibm.com/data/db2/library ===================================================== 4.3 Tuning LDAP LDAP performance can be affected by various things. Tuning and making changes to the default configuration is essential to increasing performance. Priming of the LDAP (and DB2 caches if using IBM SecureWay LDAP) is necessary before the benefits of these caches are realized. There are several LDAP cache types including entry and filter. Choose the number of entries to cache based on the specific customer environment. Some experimentation might be necessary to find the best size. In general, minimize the size of the DB2 buffer pool and maximize the LDAP entry and filter caches. The DCE 3.2 database is automatically indexed when you load the DCE schema into IBM SecureWay LDAP. If you are using an iPlanet/Netscape Directory server, you must manually index the schema. It is recommended that LDAP be run with concurrent read/write. You must set concurrent read/write on (LDAP_CONCURRENTRW=ON) if you are using IBM SecureWay Directory. It is on by default if you are using iPlanet/Netscape Directory. After you set concurrent read/write, you must restart slapd. ===================================================== 4.3.1 Tuning the IBM SecureWay LDAP server Note: The instructions in this section assume that you are using the default slapd configuration file (/usr/ldap/etc/slapd32.conf on AIX) and the default slapd error log file (/tmp/slapd.errors on AIX). If your LDAP server does not use these defaults, please make the appropriate substitutions. If the IBM SecureWay slapd.errors file (/tmp/slapd.errors on AIX; /var/ldap/slapd.errors on Solaris; C:\Program Files\IBM\LDAP\tmp\slapd32.errors on NT) gets large, LDAP performance can degrade. It is not expected that you will get many errors; however, in long-running environments, this file is sometimes overlooked. It can be deleted or renamed while LDAP is running. A new slapd.errors file is automatically created if it is deleted or renamed. There are four environment variables that directly affect the cache sizes on an IBM SecureWay LDAP server cache. These values are dependent on the platform, memory size, workload, etc., in a particular environment. The preferred way to set the values for the variables is by way of the /usr/ldap/etc/slapd32.conf file. Example Steps - IBM SecureWay LDAP 1. Add the following to the LDAP configuration file /usr/ldap/etc/slapd32.conf: #ADDED LDAP TUNING dn: cn=Front End, cn=Configuration objectclass: top objectclass: ibm-slapdFrontEnd #Turn on concurrent read/write. This can prevent race conditions #that could result in entries being returned that no longer #match the search filter. This locking mechanism can have a #dramatic impact on the performance of LDAP searches when #update operations are in progress. Default is FALSE. #Note that this variable can be set to ON or TRUE in v3.2.2 #of IBM SecureWay LDAP. ibm-slapdSetEnv: LDAP_CONCURRENTRW=ON #RDBM_CACHE_SIZE=; Default is 1000. #Specifies the maximum numbers of entries to keep in the Entry cache. ibm-slapdSetEnv: RDBM_CACHE_SIZE=100000 #RDBM_FCACHE_SIZE=; Default is one fourth of the size of the #RDBM_CACHE_SIZE. #Specifies the maximum number of entries to keep in the search filter #cache. ibm-slapdSetEnv: RDBM_FCACHE_SIZE=100000 #ACLCACHE=; Default is YES. #Controls whether or not the server caches ACL information. ibm-slapdSetEnv: ACLCACHE=YES #ACLCACHESIZE=; Default is = RDBM_CACHE_SIZE. #Specifies the maximum number of entries to keep in the ACL cache. ibm-slapdSetEnv: ACLCACHESIZE=25000 2. Stop the LDAP server. 3. On AIX, export the following environment variable before restarting the LDAP server: export MALLOCMULTIHEAP=heaps:n where n = #of processors for this LDAP host machine + 1 4. Start the LDAP server. ===================================================== 4.3.2 Tuning the iPlanet/Netscape LDAP server If you are using the iPlanet/Netscape Directory server, review the tuning information and tips in the documentation available for that product. Specifically, the "iPlanet Directory Server Performance Tuning Guide", dated May 2001, contains a "Top 10 List of Performance Tuning Tips". The schema must be indexed manually when using the iPlanet/Netscape Directory server. The iPlanet/Netscape Directory server caches data in memory. This in memory cache is also tunable. Example Steps - iPlanet/Netscape LDAP Configure the following DCE LDAP attributes as equality index attributes: - krbRealmName-v2 - krbPrincipalName - krbPolicyName - krbKeyVersion - dceDirName - dceXattrName - dceGroupName - dceUUID - unixID Before you perform any DCE LDAP migration, calculate and set the maximum entry cache size and the database cache size values with iPlanet/Netscape LDAP. The entry cache size (cachesize) specifies the number of entry items per cache, not the memory size of the cache. The basic rule is to dedicate 75% of cache memory to dbcachesize and 25% to the entry cache size. See "The iPlanet Market Maker 1.0 Deployment Guide", Chapter 6, "Performance Tuning and Monitoring". Be sure to update cachesize and dbcachesize in the LDAP server configuration file to have the new values. Restart the LDAP server to activate the previous adjustments. See http://docs.iplanet.com/docs/manuals/directory.html for specifics on tuning 4.13, 5.0, and other recommendations for iPlanet/Netscape. ===================================================== 4.4 Hardware Higher speed machines and additional memory have made a significant difference in performance while testing this feature. IBM test scenarios show that the performance of a DCE cell using LDAP for the security registry is directly correlated with the capacity of the system running LDAP. IBM stress tests were run using an IBM eServer pSeries(TM) 620 Model 6F1 with 4 GB of memory as the LDAP/DB2 server machine. Sufficient memory is needed for both the LDAP and DB2 caches. The minimum recommended memory configuration is 128 MB. To help improve I/O performance, consider adding additional drives on your LDAP/DB2 server machine. You can monitor (for example, by using the vmstat utility) the percentage of time spent waiting on I/O. If it is not 0%, this might suggest that the database is I/O bound, which can indicate that LDAP is effectively saturated. Increasing the size of the database buffer until the I/O wait time approaches 0% generally is the most effective approach. ===================================================== 4.5 Network Running an LDAP server and the DCE security migration server on the same machine can improve performance, especially during migration. Using SSL over a network might have significant performance impacts; propagation and update activity times can increase. ===================================================== 4.6 Initial migration expectations Initial migration of the security registry into LDAP by way of the migration server takes significantly longer than the initialization of a legacy replica. Where a 10,000 principal/account registry environment might take a few minutes to migrate to a legacy replica, in an LDAP environment this can take close to 15 hours. ===================================================== 4.7 DCE application considerations In a hybrid cell, replication, specifically propagation of security information, takes longer to get into the LDAP database. Customer applications that update security information and then immediately access that data might generate "Registry Object Not Found" errors. This is because of the propagation delay necessary to get the information into LDAP. Several approaches can be used to mitigate this problem. One method is to use the pe_site file. Use the TRY_PE_SITE environment variable, and order your security servers such that the LDAP migration server is not first in the pe_site file. The application then binds to a legacy secd server where the propagation delay is not significant. Another method is to add code to your existing applications to retry on error after an update to allow for the time needed to propagate. Once the cell is fully migrated to LDAP, propagation no longer occurs. ===================================================== 4.8 User tasks (login, chpasswd) IBM has implemented support for multiple connections to the LDAP server, thereby helping improve performance of concurrent login activity. See the preceding "Tuning secd" section for a discussion of the environment variable MAX_CONNECTIONS. Users might occasionally experience the propagation delay when changing their password and immediately logging in. An initial failure might occur if the password change has not yet been propagated to LDAP. The user can try again and login should succeed. ===================================================== 4.9 Admin tasks (user create, user delete) Because of the way the "dcecp -c user create" command does lookups, it is typically slower in LDAP than doing the steps involved separately. It is recommended you run the following separate dcecp commands instead: principal create group create org create group add member org add member account create The same recommendation is true for "dcecp -c user delete". If you run scripts that use the "dcecp -c user create" command, see the pe_site discussion in the preceding "DCE application considerations" section. Using the pe_site file to "direct" requests to legacy secd servers and away from the migration server during migration might mitigate some of the propagation delays. ===================================================== 5.0 LOCALE CONSIDERATIONS ===================================================== 5.1 Solaris LDAP client problem with UTF-8 (Solaris only) The IBM SecureWay Directory V3.2.1 client for Solaris supports running in UTF-8 locales with e-fix 3.2.1-SWD-005 installed. If you attempt to use DCE with LDAP while running in a Solaris UTF-8 locale without the e-fix installed, DCE will fail with LDAP encoding errors similar to the following: 2001-07-09-15:47:53.898-05:00I----- secd ERROR sec ldap ldap_errors.c 666 0xfe8af9bc msgID=0x17122F9F ldap_simple_bind_s returned LDAP_ENCODING_ERROR during rgy_bind_to_ldap_server (1134). ===================================================== 5.2 LDAP failures related to unsupported locale settings The IBM SecureWay Directory V3.2.1 client does not run correctly if the operating system's locale environment variables LANG and LC_ALL are set to values that are not supported on the local host machine. Incorrect settings cause LDAP errors that result in DCE errors similar to the following: 2001-11-02-14:29:12.435-06:00I----- secd ERROR sec ldap ldap_errors.c 666 0xfea8f904 msgID=0x17122F9F ldap_simple_bind_s returned LDAP_ENCODING_ERROR during rgy_bind_to_ldap_server (1332). 2001-11-02-14:29:12.814-06:00I----- secd ERROR sec rs_ns rs_master_LDAP.c 550 0xfea8fbac msgID=0x17122084 Invalid data record To work around this problem, set the values of LANG and LC_ALL to ones that are supported on the machine. To see the current locale settings, run the operating system command "locale" in the DCE session. On AIX, the command "locale -a" shows the valid locale settings for the local machine. If the current locale settings are not listed, you must reset LANG and LC_ALL to values that are listed. On Solaris, you can detect an incorrect setting because the operating system displays the warning message "couldn't set locale correctly" while executing system commands. ===================================================== 6.0 REQUIRED REGISTRY VERSION MODIFICATION ===================================================== 6.1 Ensure that all replicas have the same registry version number before migrating to the LDAP master Before migrating to the LDAP master, you must raise the DCE security registry version to 1.3. Because this might require two version modifications, ensure that all replicas have the same version number before beginning migration to the LDAP master. You must run "lr -all" to verify that the update has occurred on all replicas before proceeding. Issue the "sec_admin" command, then type "lr -all". When all of the replicas are at the 1.3 version and have the same sequence number, it is safe to migrate to the LDAP master. ===================================================== 6.2 Registry modify -version attempts to wait for sequence numbers to match In prior releases of DCE, it was unusual for the registry version to be modified twice in a short period of time. When migrating to use the LDAP functionality in DCE 3.2, if the cell registry version is not already at secd.dce.1.2.2a (for Public Key), it is necessary for the registry version to be modified at least twice: from secd.dce.1.2.2 to secd.dce.1.2.2a and then from secd.dce.1.2.2a to secd.dce.1.3 DCE does not support moving more than one version at a time, and it needs time to completely change to one version before a change to another version is initiated. The security replicas must process the first version change by way of propagation before the second is started, otherwise, the security replicas return errors indicating that the version is being changed by multiple versions at a time. Before attempting to change the registry version, use sec_admin with the subcommand lr -all to verify that all security replica sequence numbers are up to date. When all of the sequence numbers match, the registry version can be safely changed. Perform this check before each of the "dcecp -c registry modify -version" commands. The "dcecp -c registry modify -version" command attempts to perform this check itself, by the use of sec_rgy_wait_until_consistent. It attempts to force the master to wait for the replicas to have all updates before processing the version update. If the security replicas are not all up to date, you should see the following: Waiting up to 600 seconds for "sec_rgy_wait_until_consistent" to complete. You get this message if dcecp has to wait more than 15 seconds for sec_rgy_wait_until_consistent to return. dcecp times out after 10 minutes if the sec_rgy_wait_until_consistent API does not return. If this happens, the following message displays: 0x11315bbd The software timed out waiting for "sec_rgy_wait_until_consistent" to complete. version = secd.dce.1.2.2a The current registry version is displayed so that you can know if dcecp timed out on sec_rgy_wait_until_consistent before or after updating the registry version. If the version displayed is not the desired version, wait a few minutes and attempt the registry modify again. In most cases the "dcecp -c registry modify -version" command will wait for the version update to be propagated to all security replicas. There may be times though that dcecp will be unable to detect that some of the security replicas did not get all of the updates. For example, the Master Security server has pushed an update out, but the replica has not processed it, or a replica is not currently running. If the registry version is updated before all of the security replicas are up to date, version errors may be reported by some of the replicas. If the security replica server reporting the error is a legacy security replica, that replica will have to be reconfigured. If the security replica server reporting the error is an LDAP security replica, copy the /opt/dcelocal/var/security/rgy_data/master_info file from an error-free LDAP slave or migration slave. Be sure to save the original version of the master_info file in case errors are made. ==================================================== 7.0 MIGRATION CONSIDERATIONS AND POSSIBLE ERROR SITUATIONS ==================================================== 7.1 Registry migrate requires some parameters to be fully qualified The "dcecp -c registry migrate" command requires fully qualified path names for the -dce_master_key and -keyring parameters. If a path name is provided that is not fully qualified for one of these parameters, you get the following message: The value, '', for the