IBM Support

Message GLD014C in QUSRDIR LDAP Server Joblog After an OS Upgrade

Troubleshooting


Problem

After an OS upgrade the QUSRDIR LDAP server is unable to start and is throwing a GLD014C error in the joblog.

Cause

The LDAP server (QUSRDIR by default) at each OS release has a specific format for the schema data that is stored in the server configuration.  The first time the LDAP server is started after an OS upgrade this data should automatically be migrated to the most current format supported by the OS.  However, on some occasions this migration process fails and results in the LDAP server being unable to start.

Resolving The Problem

The following steps will outline an initial recovery solution along with a two part process to follow, should the initial recovery solution not resolve the problem.  

NOTE: Prior to going through the steps we need to run the following command to ensure that environment variable that would prevent the LDAP server data from migrating:

RMVENVVAR ENVVAR(QIBM_QGLD_NOMIGRATE) LEVEL(*SYS)

Initial Recovery Solution

In this set of recovery steps, we will rename a critical LDAP server configuration file.  The absence of the file will trigger the LDAP server to perform a data migration on startup:

1) On the IBM i command line run the following command:

RNM OBJ('/qibm/userdata/os400/dirsrv/idsslapd-QUSRDIR/etc/slapd.version') NEWOBJ(slapd.version.bak)

2) We will then start the LDAP server with the following command:

STRTCPSVR SERVER(*DIRSRV)

3) If we view the QUSRDIR joblog we should see indications that the data has migrated and if successful the server should stay active.   If the server fails with the same GLD014C error, we will need to perform Part 1 and Part 2 listed below.

Part 1

In this part we are going to trigger a new LDAP data migration by saving off your existing LDAP data, then removing the LDAP server and restoring your LDAP data. When we start the server after doing this it should trigger a new migration:

1) On the IBM i command line run the following commands to create the save files we need for the operation:

CRTSAVF FILE(QGPL/LDAP)

CRTSAVF FILE(QGPL/LDAP2)

CRTSAVF FILE(QGPL/LDAP3)

2) We will then run the following commands to save off the existing LDAP server configuration:

SAV DEV('/qsys.lib/qgpl.lib/ldap.file') OBJ(('/qibm/userdata/os400/dirsrv/*' *INCLUDE))

SAVLIB LIB(QUSRDIRDB) DEV(*SAVF) SAVF(QGPL/LDAP2)

SAVLIB LIB(QUSRDIRCF) DEV(*SAVF) SAVF(QGPL/LDAP3)

3) Next we will run the following command to remove the existing QUSRDIR LDAP server:

RMVDIRINST INSTANCE(QUSRDIR) DLTLIB(*YES)

4) We can now restore the LDAP configuration from the data that we saved off previously:

RST DEV('/qsys.lib/qgpl.lib/ldap.file') OBJ(('/qibm/userdata/os400/dirsrv/*' *INCLUDE))

RSTLIB SAVLIB(QUSRDIRDB) DEV(*SAVF) SAVF(QGPL/LDAP2)

RSTLIB SAVLIB(QUSRDIRCF) DEV(*SAVF) SAVF(QGPL/LDAP3)

5) Finally, we will start the LDAP server and this will trigger a migration of the LDAP data to an updated format:

STRTCPSVR SERVER(*DIRSRV)

NOTE: If we view the QUSRDIR joblog we should see that the data migration was successful, but the server will eventually fail to start and will throw a 'GLD0113 - Secure socket error occurred for directory server'. This is because the 'QIBM_DIRECTORY_SERVER_QUSRDIR' application ID in the Digital Certificate Manager *SYSTEM store was removed as part of the cleanup process. We can now proceed to Part 2.

Part 2

Now that the data migration has completed successfully, we will save this LDAP server configuration and take steps to create a new LDAP server configuration that will serve as a clean instance to restore our newly migrated data to:

1) We will run the following commands create new save files to contain our new configuration data:

CRTSAVF FILE(QGPL/LDAP4)

CRTSAVF FILE(QGPL/LDAP5)

CRTSAVF FILE(QGPL/LDAP6)

2) We will then run the following commands to save the new configuration:

SAV DEV('/qsys.lib/qgpl.lib/ldap4.file') OBJ(('/qibm/userdata/os400/dirsrv/*' *INCLUDE))

SAVLIB LIB(QUSRDIRDB) DEV(*SAVF) SAVF(QGPL/LDAP5)

SAVLIB LIB(QUSRDIRCF) DEV(*SAVF) SAVF(QGPL/LDAP6)

3) We can then run the following commands to delete the existing LDAP server and create a brand new pristine LDAP server, which will create the missing application ID in DCM (Replace 'password' with what you would like the 'cn=Administrator' password to be):

NOTE: For the 'SUFFIX' parameter, use the system's Fully Qualified Domain Name (FQDN) found in CFGTCP opt. 12.  The 'Host Name' plus the 'Domain Name' combined is the FQDN. 

For example:

Host Name = SYSTEMA

Domain Name = MYCOMPANY.COM

The Suffix parameter would be:

dc=SYSTEMA,dc=MYCOMPANY,dc=COM

RMVDIRINST INSTANCE(QUSRDIR) DLTLIB(*YES)

ADDDIRINST INSTANCE(QUSRDIR) ADMIN('cn=administrator' password) SUFFIX('dc=SYSTEMA,dc=MYCOMPANY,dc=COM')

4) Now that we have an empty shell of a new QUSRDIR server, we can restore our successfully migrated data into it using the following commands:

RST DEV('/qsys.lib/qgpl.lib/ldap4.file') OBJ(('/qibm/userdata/os400/dirsrv/*' *INCLUDE))

RSTLIB SAVLIB(QUSRDIRDB) DEV(*SAVF) SAVF(QGPL/LDAP5)

RSTLIB SAVLIB(QUSRDIRCF) DEV(*SAVF) SAVF(QGPL/LDAP6)

5) Lastly, we can start the LDAP server and it should remain active:

STRTCPSVR SERVER(*DIRSRV)

Once we have confirmed that the server is functioning properly the save files we created previously can be removed:

QGPL/LDAP

QGPL/LDAP2

QGPL/LDAP3

QGPL/LDAP4

QGPL/LDAP5

QGPL/LDAP6

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CJ2AAM","label":"IBM i Tivoli Directory Server"},{"code":"a8m0z0000000CKOAA2","label":"IBM i Tivoli Directory Server-\u003EUnable to Start"}],"ARM Case Number":"TS016997126","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]

Document Information

Modified date:
23 August 2024

UID

ibm17165920