Bug 50891 - Failing "udm create" of computer leaves uid locks behind causing creation of computer with same name to fail
Summary: Failing "udm create" of computer leaves uid locks behind causing creation of ...
Status: RESOLVED DUPLICATE of bug 41711
Alias: None
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
Version: UCS 4.4
Hardware: Other Linux
: P5 normal
Target Milestone: ---
Assignee: UMC maintainers
QA Contact: UMC maintainers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-03 12:02 CET by Valentin Heidelberger
Modified: 2020-03-03 22:10 CET (History)
1 user (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.114
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Customer ID:
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Valentin Heidelberger univentionstaff 2020-03-03 12:02:39 CET
If a computer object's name is already in use and one tries to create another computer object of the same name on the CLI with udm, the creation fails with:

E: Object exists: (uid) : <name>$

This error creates a uid lock object for <name>$ underneath cn=uid,cn=temporary,cn=univention,dc=ldap,dc=base
Even if one then deletes the existing computer object the lock remains and causes the creation of a computer object of that name to fail until it has been removed manually.

# udm computers/windows create --position cn=computers,dc=ucs,dc=demo --set name="testwin"
Object created: cn=testwin,cn=computers,dc=ucs,dc=demo

# udm computers/windows create --position cn=computers,dc=ucs,dc=demo --set name="testwin"
E: Object exists: (uid) : testwin$

# udm computers/windows remove --dn cn=testwin,cn=computers,dc=ucs,dc=demo
Object removed: cn=testwin,cn=computers,dc=ucs,dc=demo

# udm computers/windows create --position cn=computers,dc=ucs,dc=demo --set name="testwin"
E: Object exists: (uid) : testwin$

# univention-ldapsearch -LLL "(|(uid=testwin$)(cn=testwin)(cn=testwin$))" 
dn: cn=testwin$,cn=uid,cn=temporary,cn=univention,dc=ucs,dc=demo
objectClass: lock
objectClass: top
lockTime: 1583233128
cn: testwin$

# ldapdelete -D "uid=Administrator,cn=users,dc=ucs,dc=demo" -w univention "cn=testwin$,cn=uid,cn=temporary,cn=univention,dc=ucs,dc=demo"

# udm computers/windows create --position cn=computers,dc=ucs,dc=demo --set name="testwin"
Object created: cn=testwin,cn=computers,dc=ucs,dc=demo


By increasing the log level one can see that the CLI indeed removes other locks such as uidNumber or sid in cn=temporary but not the uid:

# ucr set directory/manager/cmd/debug/level='4'

# cat /var/log/univention/directory-manager-cmd.log
[...]
03.03.20 11:59:39.880  LDAP        ( ALL     ) : add dn=cn=testwin$,cn=uid,cn=temporary,cn=univention,dc=ucs,dc=demo al=[('objectClass', ['top', 'lock']), ('cn', ['testwin$']), ('lockTime', ['1583233479'])]
03.03.20 11:59:39.880  LDAP        ( INFO    ) : uldap.add dn=cn=testwin$,cn=uid,cn=temporary,cn=univention,dc=ucs,dc=demo
03.03.20 11:59:39.883  LDAP        ( INFO    ) : uldap.search filter=(|(&(cn=testwin$)(|(objectClass=univentionGroup)(objectClass=sambaGroupMapping)(objectClass=posixGroup)))(uid=testwin$)) base=dc=ucs,dc=demo scope=sub attr=['dn'] unique=0 required=0 timeout=-1 sizelimit=0
03.03.20 11:59:39.884  ADMIN       ( WARN    ) : cancel: release (uidNumber): 2018
03.03.20 11:59:39.884  LDAP        ( INFO    ) : uldap.delete cn=2018,cn=uidNumber,cn=temporary,cn=univention,dc=ucs,dc=demo
03.03.20 11:59:39.884  LDAP        ( INFO    ) : delete
03.03.20 11:59:39.885  ADMIN       ( WARN    ) : cancel: release (sid): S-1-5-21-605621511-3795675953-190842196-5036
03.03.20 11:59:39.885  LDAP        ( INFO    ) : uldap.delete cn=S-1-5-21-605621511-3795675953-190842196-5036,cn=sid,cn=temporary,cn=univention,dc=ucs,dc=demo
03.03.20 11:59:39.885  LDAP        ( INFO    ) : delete
03.03.20 11:59:39.887  ADMIN       ( WARN    ) : cancel: release (uidNumber): 2018
03.03.20 11:59:39.887  LDAP        ( INFO    ) : uldap.delete cn=2018,cn=uidNumber,cn=temporary,cn=univention,dc=ucs,dc=demo
03.03.20 11:59:39.887  LDAP        ( INFO    ) : delete
03.03.20 11:59:39.888  ADMIN       ( WARN    ) : cancel: release (sid): S-1-5-21-605621511-3795675953-190842196-5036
03.03.20 11:59:39.888  LDAP        ( INFO    ) : uldap.delete cn=S-1-5-21-605621511-3795675953-190842196-5036,cn=sid,cn=temporary,cn=univention,dc=ucs,dc=demo
03.03.20 11:59:39.888  LDAP        ( INFO    ) : delete
03.03.20 11:59:39.893  ADMIN       ( INFO    ) : daemon [6927] connection closed [12871]
Comment 1 Valentin Heidelberger univentionstaff 2020-03-03 12:08:08 CET
The problem seems to be specific to the CLI and I can reproduce it at least with computers/windows and computers/linux. The UMC doesn't seem to cause the same issue when one tries to create a computer object with an existing name.
Comment 2 Valentin Heidelberger univentionstaff 2020-03-03 13:44:45 CET
I was able to reproduce it now with the UMC as well.
Comment 3 Florian Best univentionstaff 2020-03-03 22:10:07 CET

*** This bug has been marked as a duplicate of bug 41711 ***