Bug 41868 - computer object modification fails if shadowAccount is missing in objectclasses
computer object modification fails if shadowAccount is missing in objectclasses
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.2
Assigned To: Felix Botner
Stefan Gohmann
: interim-3
Depends on:
Blocks: 43742 43083
  Show dependency treegraph
 
Reported: 2016-07-28 14:00 CEST by Felix Botner
Modified: 2017-04-04 18:29 CEST (History)
5 users (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?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number: 2016072921000169
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 Felix Botner univentionstaff 2016-07-28 14:00:56 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)
Comment 1 Nico Stöckigt univentionstaff 2016-07-29 10:56:39 CEST
Ticket#2016072921000169 seems to address a problem which is very related to this behavior
Comment 2 Felix Botner univentionstaff 2016-07-29 11:23:22 CEST
(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.
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2016-08-11 16:28:08 CEST
(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
Comment 4 Stefan Gohmann univentionstaff 2016-10-04 07:23:42 CEST
(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?
Comment 5 Florian Best univentionstaff 2016-10-04 11:34:17 CEST
(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.
Comment 6 Florian Best univentionstaff 2016-10-04 11:40:40 CEST
(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.
Comment 7 Florian Best univentionstaff 2016-10-11 10:38:29 CEST
@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.
Comment 8 Felix Botner univentionstaff 2017-03-02 10:31:46 CET
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
Comment 9 Florian Best univentionstaff 2017-03-02 11:51:02 CET
(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?
Comment 10 Florian Best univentionstaff 2017-03-06 16:22:47 CET
It would be good to add this code also to the preup of UCS 4.1.
Comment 11 Felix Botner univentionstaff 2017-03-07 09:48:47 CET
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
Comment 12 Stefan Gohmann univentionstaff 2017-03-20 07:10:28 CET
Changelog: OK

Code review: Fail, please redirect the ldapmodify output to the logfile
Comment 13 Felix Botner univentionstaff 2017-03-20 09:09:36 CET
(In reply to Stefan Gohmann from comment #12)
> Changelog: OK
> 
> Code review: Fail, please redirect the ldapmodify output to the logfile

done
Comment 14 Stefan Gohmann univentionstaff 2017-03-20 15:51:42 CET
OK, looks good now. I've successfully updated a very old environment.
Comment 15 Stefan Gohmann univentionstaff 2017-04-04 18:29:48 CEST
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".