Bug 50278 - gidNumber synchronisation raises valueMayNotChange
gidNumber synchronisation raises valueMayNotChange
Status: CLOSED DUPLICATE of bug 50766
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-7-errata
Assigned To: Julia Bremer
Felix Botner
:
Depends on: 50033
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-26 16:12 CEST by Florian Best
Modified: 2021-03-24 15:58 CET (History)
5 users (show)

See Also:
What kind of report is it?: Development Internal
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?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2020112421000492, 2020120721000316
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 Florian Best univentionstaff 2019-09-26 16:12:31 CEST
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.
Comment 1 Christina Scheinig univentionstaff 2020-11-25 15:56:18 CET
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)
Comment 2 Christina Scheinig univentionstaff 2020-12-07 15:11:38 CET
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.
Comment 4 Felix Botner univentionstaff 2021-03-18 08:57:00 CET
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'
Comment 5 Julia Bremer univentionstaff 2021-03-18 09:08:15 CET
(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..
Comment 6 Julia Bremer univentionstaff 2021-03-24 11:24:15 CET
Fixed in Bug #50766

*** This bug has been marked as a duplicate of bug 50766 ***
Comment 7 Felix Botner univentionstaff 2021-03-24 11:34:21 CET
OK