Univention Bugzilla – Bug 41868
computer object modification fails if shadowAccount is missing in objectclasses
Last modified: 2017-04-04 18:29:48 CEST
If a computer object (maybe user objects too, i don't know) has not set the shadowAccount LDAP objectclass, UDM modification to that object are no longer possible. -> univention-ldapsearch cn=master objectclass dn: cn=master,cn=dc,cn=computers,dc=w2k12,dc=test objectClass: krb5KDCEntry objectClass: krb5Principal objectClass: person objectClass: posixAccount objectClass: sambaSamAccount objectClass: top objectClass: univentionDomainController objectClass: univentionHost objectClass: univentionNagiosHostClass objectClass: univentionObject -> udm computers/domaincontroller_master modify --dn cn=master,cn=dc,cn=computers,dc=w2k12,dc=test --set description=a LDAP Error: Object class violation: object class 'posixAccount' requires attribute 'homeDirectory' Th reason is that the UDM module option "posix" is not activated during the initialization of the object. Therefore UDM wants to remove the "homeDirectory" attribute. But this LDAP attribute is requiered in the posixAccount objectclass. With bug 41580 the ldap objectclass -> udm options detection has been changed. The UDM univention.admin.option got an extra attribute objectClasses and during __init__ an UDM option is only activated if ALL classes from the univention.admin.option.objectClasses attribute are present in the current LDAP objectclasses (see univention.admin.options.matches). And the objectClasses attribute for the posix option for computer/* modules is ('posixAccount', 'shadowAccount'). The old code just simply said if 'posixAccount' in ocs: self.options.append( 'posix' ) nothing about shadowAccount here. This happened on billy (and applies only to very old systems)
Ticket#2016072921000169 seems to address a problem which is very related to this behavior
(In reply to Nico Stöckigt from comment #1) > Ticket#2016072921000169 seems to address a problem which is very related to > this behavior yep, in oxse4ucs/univention-ox/udm/handlers/oxmail/oxfetchmailmulti.py (and oxfetchmailsingle.py) the attribute localrecipient has "options=['posix']" set. I think this is wrong (copy&paste?) but with the new options handling UDM now wants to remove this attribute as there is no posix option for the object. This has to be fixed in the ox modules, but i think we also need to modify udm to remain backward compatible. Maybe univention.admin.handlers.base.diff() should ignore the "# remove properties which are disabled by options" block if there are the no options defined in the module.
(In reply to Felix Botner from comment #2) > (In reply to Nico Stöckigt from comment #1) > > Ticket#2016072921000169 seems to address a problem which is very related to > > this behavior > > yep, > > in oxse4ucs/univention-ox/udm/handlers/oxmail/oxfetchmailmulti.py (and > oxfetchmailsingle.py) the attribute localrecipient has "options=['posix']" > set. > > I think this is wrong (copy&paste?) but with the new options handling UDM > now wants to remove this attribute as there is no posix option for the > object. > > This has to be fixed in the ox modules, but i think we also need to modify > udm to remain backward compatible. > > Maybe univention.admin.handlers.base.diff() should ignore the "# remove > properties which are disabled by options" block if there are the no options > defined in the module. This will be fixed with OX AppSuite version 7.8.2
(In reply to Sönke Schwardt-Krummrich from comment #3) > This will be fixed with OX AppSuite version 7.8.2 Do we need to fix something in our UDM code?
(In reply to Stefan Gohmann from comment #4) > (In reply to Sönke Schwardt-Krummrich from comment #3) > > This will be fixed with OX AppSuite version 7.8.2 > > Do we need to fix something in our UDM code? Yes. Either add some workaround code to UDM or add a migration script which adjusts the very old LDAP entries.
(In reply to Florian Best from comment #5) > (In reply to Stefan Gohmann from comment #4) > > (In reply to Sönke Schwardt-Krummrich from comment #3) > > > This will be fixed with OX AppSuite version 7.8.2 > > > > Do we need to fix something in our UDM code? > > Yes. Either add some workaround code to UDM or add a migration script which > adjusts the very old LDAP entries. The bug only applies to systems which upgraded from smaller than UCS 2.0. The code which caused this was not yet present in UCS 2.0: https://billy.knut.univention.de/websvn/filedetails.php?repname=dev&path=%2Fbranches%2Fucs-2.0%2Fucs%2Fmanagement%2Funivention-directory-manager-modules%2Fmodules%2Funivention%2Fadmin%2Fhandlers%2Fcomputers%2Fdomaincontroller_slave.py I have no UCS 1.x checkout.
@Stefan: Is it okay if I write a migration script for the DC Master which adds the object class shadowAccount to all computer objects which have a uid attribute and the posixAccount object class? The bug affects only Systems upgraded from smaller than UCS 2.0.
This breaks some update tests (update from 1.2, univention-check-join-status fails because some join scripts fail, because they can't modify the master object, because of this bug). Can't we just add something like this to the updater preup/postup scripts to repair broken objects? eval "$(ucr shell)" if [ "domaincontroller_master" = "$server_role" -a -e /etc/ldap.secret ]; then while read dn; do echo "dn: $dn changetype: modify add: objectClass objectClass: shadowAccount" | ldapmodify -x -D "cn=admin,$ldap_base" -y /etc/ldap.secret done < <( \ univention-ldapsearch -LLL \ '(&(objectClass=univentionHost)(objectClass=posixAccount)(!(objectClass=shadowAccount)))' dn \ | ldapsearch-wrapper \ | sed -n 's/^dn: \(.*\)/\1/p') fi
(In reply to Felix Botner from comment #8) > This breaks some update tests (update from 1.2, univention-check-join-status > fails because some join scripts fail, because they can't modify the master > object, because of this bug). > > Can't we just add something like this to the updater preup/postup scripts to > repair broken objects? Yes, this would be the very best solution! I think we should add this also to the UCS 4.2 preup. Can you take this bug then?
It would be good to add this code also to the preup of UCS 4.1.
Added check in the preup (univention-updater). (In reply to Florian Best from comment #10) > It would be good to add this code also to the preup of UCS 4.1. Opened a new bug for that -> Bug #43742
Changelog: OK Code review: Fail, please redirect the ldapmodify output to the logfile
(In reply to Stefan Gohmann from comment #12) > Changelog: OK > > Code review: Fail, please redirect the ldapmodify output to the logfile done
OK, looks good now. I've successfully updated a very old environment.
UCS 4.2 has been released: https://docs.software-univention.de/release-notes-4.2-0-en.html https://docs.software-univention.de/release-notes-4.2-0-de.html If this error occurs again, please use "Clone This Bug".