Bug 15743 - Ldap-lock-objekte werden nach Anlegen von Computern nicht entfernt
Ldap-lock-objekte werden nach Anlegen von Computern nicht entfernt
Status: CLOSED WONTFIX
Product: UCS
Classification: Unclassified
Component: UMC - Computers
UCS 2.2
Other Linux
: P5 normal (vote)
: ---
Assigned To: UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-28 10:58 CEST by Daniel Hofmann
Modified: 2022-06-30 14:39 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Hofmann univentionstaff 2009-09-28 10:58:48 CEST
Getestet auf 2.2-2

root@master22:/# univention-directory-manager computers/domaincontroller_backup create --position "cn=computers,dc=univention,dc=test" --set "name"="q7a3418b7h3mgk3a7xaq3" --set "mac"="8:4:6:2:4:2" --set "ip"="10.0.3.4"
Object created: cn=q7a3418b7h3mgk3a7xaq3,cn=computers,dc=univention,dc=test

root@master22:/# ldapsearch -xLLL cn=8:4:6:2:4:2
dn: cn=8:4:6:2:4:2,cn=mac,cn=temporary,cn=univention,dc=univention,dc=test
objectClass: top
objectClass: lock
lockTime: 1254131583
cn: 8:4:6:2:4:2

root@master22:/# ldapsearch -xLLL cn=10.0.3.4
dn: cn=10.0.3.4,cn=aRecord,cn=temporary,cn=univention,dc=univention,dc=test
objectClass: top
objectClass: lock
lockTime: 1254131583
cn: 10.0.3.4

Ucs-Testfall folgt.
Comment 1 Daniel Hofmann univentionstaff 2009-09-28 11:15:19 CEST
Wenn das Rechnerobjekt anschließend gelöscht wird, verschwinden die Lock-objekte zwar, allerdings "leakt" zumindest das Mac-Adressen-Lock-objekt wenn mittels

root@master22:/# udm computers/domaincontroller_backup modify --set mac="1:2:3:4:5:6" --dn cn=q7a3418b7h3mgk3a7xaq3,cn=computers,dc=univention,dc=test

die alte Mac-adresse überschrieben wird. Daran ändert auch das Löschen mit "remove_referring", also das rekursive Löschen des Computerobjekts nichts:

root@master22:/# udm computers/domaincontroller_backup remove --remove_referring --dn cn=q7a3418b7h3mgk3a7xaq3,cn=computers,dc=univention,dc=test

root@master22:/# ldapsearch -xLLL cn=8:4:6:2:4:2
dn: cn=8:4:6:2:4:2,cn=mac,cn=temporary,cn=univention,dc=univention,dc=test
objectClass: top
objectClass: lock
lockTime: 1254132591
cn: 8:4:6:2:4:2

Anschließend kann dann (vermutlich bis die Lockzeit abgelaufen ist) kein Computer mit dieser Mac-addresse angelegt werden.

Das Problem tritt laut Sönke auch im Web-UDM auf.
Comment 2 Daniel Hofmann univentionstaff 2009-09-28 11:59:37 CEST
Testfall ist im Paket ucs-test-udm-computers: 15_temporary_locks
Comment 3 Lukas Walter univentionstaff 2013-07-03 11:39:42 CEST
Dieses Problem tritt, unzuverlässig reproduzierbar, auch weiterhin auf.

Neuer Testfall: 66_udm-computers/17_temporary_ip_and_mac_locks_all_roles.py.


In einigen udm-computers Tests gibt es derzeit einen WORKAROUND für dieses Problem. Wenn es endgültig behoben ist sollte der WORKAROUND entfernt werden.
Comment 4 Stefan Gohmann univentionstaff 2014-02-18 21:36:56 CET
This issue has been filed against UCS 2.2.

UCS 2.2 is out of maintenance and many UCS components have vastly changed in
later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug".
In this case please provide detailed information on how this issue is affecting
you.