Univention Bugzilla – Bug 50278
gidNumber synchronisation raises valueMayNotChange
Last modified: 2021-03-24 15:58:53 CET
We recently added "gidNumber" to the S4-Connector mapping. The property gidNumber in UCS is not changeable. Not even to the same values as it currently is: >>> udm_object['gidNumber'] = udm_object['gidNumber'] → raises valueMayNotChange() (yes, stupid Bug #50053) In my dev-environment I saw that the connector-s4.log contains the following lines: (INFO ): __set_values: mapping for attribute: gidNumber (INFO ): __set_values: Set: gidNumber (INFO ): __set_values: set attribute, ucs_key: gidNumber - value: [u'5001'] (INFO ): set key in ucs-object gidNumber to value: u'5001' (ERROR ): Value may not change: key=gidNumber old=None new=5001 (uid=syby94782b,cn=users,l=school,l=dev) At least the error handling here is error prone. __set_values() is called with multiple values and the exception handling of valueMayNotChange in sync_to_ucs() prevents that any other value is set. Of course the error handling returns False then which causes in most cases that a reject is stored. But for example delete_in_ucs() also calls sync_to_ucs() without storing a reject for that object, if that fails. I think it would be saver to add specific handling for gidNumber, to only set it in a safe way in certain cases.
A customer has this kind of reject in his environment on his slaves. 24.11.2020 15:25:07.343 LDAP (PROCESS): sync to ucs: [ user] [ add] u'uid=michael.schanze,cn=users,ou=selfmade,dc=example,dc=int' 24.11.2020 15:25:07.842 LDAP (ERROR ): Value may not change: key=gidNumber old=None new=5001 (u'uid=michael.schanze,cn=users,ou=selfmade,dc=example,dc=int') The setup is very strange, the customer set up and joined a central slave but added an ou for this server. I am not even sure, if this setup is supported in any way, but since then this error occurs, when adding a new user. (At least it looks like that)
Happend again, a customer moved an object via RSAT tools in an other ou. This move ist shown in the listener as an delete, and the object was deleted in openLDAP. Now resyncing the object from s4 to openLDAP this reject occurs: 07.12.2020 14:19:43.376 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=Chris Schein,OU=Graphics-Design,OU=Marketing,OU=Employees,OU=Users,OU=EXAMPLE,DC=schein,DC=intern 07.12.2020 14:19:43.384 LDAP (PROCESS): sync to ucs: [ user] [ add] u'uid=cschein,OU=Graphics-Design,OU=Marketing,OU=Employees,OU=Users,OU=EXAMPLE,dc=schein,dc=intern' 07.12.2020 14:19:43.695 LDAP (ERROR ): Value may not change: key=gidNumber old=None new=50000 (u'uid=cschein,OU=Graphics-Design,OU=Marketing,OU=Employees,OU=Users,OU=EXAMPLE,dc=schein,dc=intern’) Temporary setting the connector/s4/mapping/user/attributes/ignorelist=gidNumber helped to resolve the reject, and get the user resynced to openLdap again. In the customer environment, the variable was not set at all. Comparing this with my testenvironment, in my testenvironment there are a lot of attributes on this ignore list.
not sure it is this bug or the other gidNumber bug, but the connector seems to be upset 18.03.2021 01:43:33.941 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=ucs-sso,CN=Users,DC=autotest091c,DC=local 18.03.2021 01:43:33.950 LDAP (PROCESS): sync to ucs: [ user] [ modify] u'uid=ucs-sso,cn=users,dc=AutoTest091c,dc=local' 18.03.2021 01:43:34.101 LDAP (ERROR ): Unknown Exception during sync_to_ucs 18.03.2021 01:43:34.101 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1562, in sync_to_ucs result = self.modify_in_ucs(property_type, object, module, position) File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1297, in modify_in_ucs self.__set_values(property_type, object, ucs_object) File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 1263, in __set_values ud.debug(ud.LDAP, ud.PROCESS, '__set_values: Skip %s mode attribute %s ' % (self.property[property_type].attributes[attr_key].sync_mode, attr_key)) KeyError: 'gidNumber'
(In reply to Felix Botner from comment #4) > not sure it is this bug or the other gidNumber bug, but the connector seems > to be upset > > 18.03.2021 01:43:33.941 LDAP (PROCESS): sync to ucs: Resync rejected > dn: CN=ucs-sso,CN=Users,DC=autotest091c,DC=local > 18.03.2021 01:43:33.950 LDAP (PROCESS): sync to ucs: [ > user] [ modify] u'uid=ucs-sso,cn=users,dc=AutoTest091c,dc=local' > 18.03.2021 01:43:34.101 LDAP (ERROR ): Unknown Exception during > sync_to_ucs > 18.03.2021 01:43:34.101 LDAP (ERROR ): Traceback (most recent call > last): > File > "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line > 1562, in sync_to_ucs > result = self.modify_in_ucs(property_type, object, module, position) > File > "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line > 1297, in modify_in_ucs > self.__set_values(property_type, object, ucs_object) > File > "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line > 1263, in __set_values > ud.debug(ud.LDAP, ud.PROCESS, '__set_values: Skip %s mode attribute %s ' > % (self.property[property_type].attributes[attr_key].sync_mode, attr_key)) > KeyError: 'gidNumber' Jupp, already fixed that yesterday but still, the old package was used in the tests..
Fixed in Bug #50766 *** This bug has been marked as a duplicate of bug 50766 ***
OK
<https://errata.software-univention.de/#/?erratum=4.4x935>