Environment
Novell Service Desk
Situation
After upgrading NSD from v6.5.4 to v7.0, users cannot be added from an LDAP
source.
Scenario when the issue occurs:
- This issue will occur only if a customer has imported users from an
LDAP source in NSD v6.5.4 and upgrades to NSD 7.0. Subsequent upgrade from v7.0
won't fix the issue automatically and will need to execute commands on the
database manually.
Scenarios when the issue does not occur:
- Fresh installation of NSD v7.0.
- Upgrading NSD from v6.5.4 to v7.0 without any users imported from an
LDAP source.
- Upgrading NSD from v6.5.4 directly to v7.0.1 (irrespective of users
imported from an LDAP source or not).
Resolution
- Automatic:
- Applicable if a customer upgrades NSD v6.5.4 directly to v7.0.1.
- Manual:
- Applicable if a customer has upgraded NSD v6.5.4 to v7.0.
- Applicable if a customer has upgraded NSD v6.5.4 to v7.0 and
subsequently to later versions.
- Involves running a script that corrects a record in the NSD database.
Can be run when the system is in v7.0 or new versions.
Cause
As part of NSD v7.0, a new feature was introduced to support multiple LDAP
sources. This added a new table LDAP_CLIENT by denormalizing CLIENT table. As
part of upgrade, data is copied from CLIENT to LDAP_CLIENT table. NSD uses its
own counter for primary keys. After copying the data to LDAP_CLIENT table, the
counter is not set properly for LDAP_CLIENT table and left with the default
value of 1. As part of LDAP sync if any new user object is added, insertion
fails as NSD tries to update the record with ID 1 and database throws primary
key constraint violation.
Additional Information
- Documentation of database commands that will rectify the counter value for
LDAP_CLIENT table so that the subsequent updates will happen to the first unused
index. These commands will be run by the administrator manually.
Connect to NSD DB and execute the following queries
a. SELECT MAX(ID) / 10 + 1 FROM LDAP_SOURCE;
b. SELECT MAX(ID) / 10 + 1 FROM LDAP_CLIENT;
c. SELECT MAX(ID) / 10 + 1 FROM LDAP_CLIENT_ROLE;
d. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_SOURCE';
e. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_CLIENT';
f. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_CLIENT_ROLE';
b. SELECT MAX(ID) / 10 + 1 FROM LDAP_CLIENT;
c. SELECT MAX(ID) / 10 + 1 FROM LDAP_CLIENT_ROLE;
d. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_SOURCE';
e. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_CLIENT';
f. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_CLIENT_ROLE';
a-c show what the values in the EO_PK_TABLE should be.
d-f show what the values currently are.
d-f show what the values currently are.
Note that if any of the queries above error, because fields do not exist,
etc, this would suggest an error in the upgrade process itself, or that they are
not on version 7, so in such cases, please refer back to us for the next course
of action.
If any of these values do not match, this should be where the error lies.
To get them to match, first backup the NSD database, and if possible run these
queries in a testing environment first. Then, run the following, replacing a,b
and c with the numbers returned in queries a,b and c above:
UPDATE EO_PK_TABLE SET PK = a WHERE NAME LIKE 'LDAP_SOURCE';
UPDATE EO_PK_TABLE SET PK = b WHERE NAME LIKE 'LDAP_CLIENT';
UPDATE EO_PK_TABLE SET PK = c WHERE NAME LIKE 'LDAP_CLIENT_ROLE';
UPDATE EO_PK_TABLE SET PK = b WHERE NAME LIKE 'LDAP_CLIENT';
UPDATE EO_PK_TABLE SET PK = c WHERE NAME LIKE 'LDAP_CLIENT_ROLE';
LiveTime/Tomcat/etc would need restarting and the users should import just
fine.