Univention Bugzilla – Bug 37259
GPO rejects SINGLE-VALUE attribute attribute specified more than once versionNumber, gPCUserExtensionNames, gPCMachineExtensionNames
Last modified: 2015-09-18 14:43:51 CEST
I saw rejects on two customer systems till now ... (2014120121000455, 2014120921000253). GPO's get rejected with the following Traceback: 09.12.2014 06:25:38,410 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-connector/s4/1418057385.014873 09.12.2014 06:25:38,411 LDAP (PROCESS): sync from ucs: [ msGPO] [ modify] cn={322c2f1e-721d-4ef2-9240-fb72b9d04b63},cn=policies,cn=system,dc=domain,dc=de 09.12.2014 06:25:38,420 LDAP (ERROR ): sync_from_ucs: traceback during modify object: cn={322c2f1e-721d-4ef2-9240-fb72b9d04b63},cn=policies,cn=system,dc=domain,dc=de 09.12.2014 06:25:38,420 LDAP (ERROR ): sync_from_ucs: traceback due to modlist: [(0, 'versionNumber', set([u'524288']))] 09.12.2014 06:25:38,428 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1418057385.014873 09.12.2014 06:25:38,430 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 785, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2505, in sync_from_ucs self.lo_s4.lo.modify_ext_s(compatible_modstring(object['dn']), compatible_modlist(modlist), serverctrls=self.serverctrls_for_add_and_modify) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 808, in modify_ext_s return self._apply_method_s(SimpleLDAPObject.modify_ext_s,*args,**kwargs) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 766, in _apply_method_s return func(self,*args,**kwargs) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 295, in modify_ext_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) TYPE_OR_VALUE_EXISTS: {'info': '0000200D: SINGLE-VALUE attribute versionNumber on CN={322C2F1E-721D-4EF2-9240-FB72B9D04B63},CN=Policies,CN=System,DC=domain,DC=de specified more than once', 'desc': 'Type or value exists'} The object itself seems already equal in ldap and s4.
I wasn't able to reproduce it till now
First seen in 3.2-4 - I suppose it was introduced then
Seen again - School environment on a school slave: 2015030621000087
(In reply to Tim Petersen from comment #3) > Seen again - School environment on a school slave: 2015030621000087 3.2-4-errata267
*** Bug 38056 has been marked as a duplicate of this bug. ***
Created attachment 6864 [details] connector.s4.log Bug 38056 reported this for Ticket#2014112021000242 Reported again via Ticket#2015042921000345 for versionNumber and gPCMachineExtensionNames Don't know how it happened but I just noticed the versionNumber traceback in one of my test environments as well. Debuglevel 4 log attached
Created attachment 6865 [details] ldap.ldif
Created attachment 6866 [details] s4.ldif
Created attachment 6867 [details] single_value.patch Yes, big fail of some unknown author. Patch attached fixes this: All of those attributes need to be marked single_value=True in the mapping file. Maybe this should be the default in the S4-Connector to begin with, because most attributes in the mapping are marked as such. For the record: Whenever we add a new attribute the the mapping we need to check this: univention-s4search -b "cn=Schema,cn=Configuration,$samba4_ldap_base" \ lDAPDisplayName=gPCMachineExtensionNames isSingleValued
(In reply to Arvid Requate from comment #9) > Created attachment 6867 [details] > single_value.patch > > Yes, big fail of some unknown author. Patch attached fixes this: Well, well. Patch from some unknown author fixes fail of some unknown author at least in my test env. :-) 4.0-1-errata as this will hit all AD environments sooner or later.
We need to take care here that the S4-Connector doesn't overwrite attribute values in Samba4 which changed (e.g. via RSAT tools) in the time interval between reject and <now>. The issue can bee seen directly in the connector-s4.log of Comment 6 and the ldif attached to Comment 7: * The reject want's to write versionNumber=4 to Samba4 * Samba4 already has versionNumber=24 * OpenLDAP also has msGPOVersionNumber=24 Interestingly, OpenLDAP and Samba4 are in Sync already (because the last change has been in Samba4 and the sync to OpenLDAP works), so the reject must not be applied in this case! We need to write another script to fix this. Maybe we can even learn a general point for the S4-Connector from this: When treating rejects, the S4-Connector (c|sh)ould check if the "old" value is still valid in the source directory. If not, then the change could be ignored. I created enhancement Bug 38450 for that.
I attached a reproducer and a patch for Comment 11 to Bug #38450.
The solution for this bug is targeted for 4.0-2 errata Comment 11 mentions UCS 3.2-4 In http://forum.univention.de/viewtopic.php?f=48&t=3835&p=14306#p14306 another customer asks if there is/will be a solution for UCS 3.2
Technically I see no issues in backporting the patch once it's done for 4.0-2.
Reported again by Ticket#2015052921000512
In postinst we now call a script "remove_obsolete_gpo_and_wmi_rejects" which looks at each UCS rejected change file. If the change affects one of the attributes which were affected by this bug, then it compares the *current* values of those attributes in OpenLDAP with those in Samba4. If they already are "in sync", then the reject is removed. Advisory: 2015-06-03-univention-s4-connector.yaml This still needs some testing.
Created attachment 6941 [details] produce_a_resolvable_conflict_like_bug_37259.sh Reproducer script.
Created attachment 6942 [details] produce_a_unresolvable_conflict_like_bug_37259.sh A different reproducer, which creates a conflict that cannot be resolved by the adjust_obsolete_gpo_and_wmi_rejects script which is the improved version of the remove_obsolete_gpo_and_wmi_rejects script mentioned in Comment 16.
The remove_obsolete_gpo_and_wmi_rejects script has benn improved and renamed to adjust_obsolete_gpo_and_wmi_rejects. It now doesn't remove the reject but only fix the attribute value in question (if it can be fixed automatically). That way, the reject disappears the next time the S4-Connector is started. It could contain additional changes which should not been thrown away. The two reproducer scripts above can be used to produce rejects that are (a) fixable and (b) not fixable by this script. The not fixable ones are left as they are. (Theoretically one could do something with timestamps but this is a lot of additional work and not really required here. The (b) case should not appear in the wild.). I added a ucs-test case to generally check that all Samba4 attributes used in the mapping are configured as single-value if they are declared as such in the Samba4/AD schema: * 52_s4connector/402check_mapping_for_single_value_samba4_attributes
Ticket#2015060821000505 "adjust_obsolete_gpo_and_wmi_rejects" successfully adjusted ~30 rejects in customer environment.
The test case 402check_mapping_for_single_value_samba4_attributes fails in jenkins: http://jenkins.knut.univention.de:8080/job/UCS-4.0/job/UCS-4.0-2/job/Autotest%20MultiEnv/SambaVersion=s4,Systemrolle=master/lastCompletedBuild/testReport/52_s4connector/402check_mapping_for_single_value_samba4_attributes/test/ Logfile: *** BEGIN *** ['/usr/bin/python', '402check_mapping_for_single_value_samba4_attributes'] *** *** 52_s4connector/402check_mapping_for_single_value_samba4_attributes *** S4-connector check the mapping for single-value Samba4 attributes *** *** START TIME: 2015-06-13 04:21:15 *** INFO: Checking if all Samba4 attributes in the S4-Connector mapping are properly declared as Single-Value ### FAIL ### ERROR: Some single valued Samba4 attributes are not configured properly in the S4-Connector mapping. ### ### *** END TIME: 2015-06-13 04:21:16 *** *** TEST DURATION (H:MM:SS.ms): 0:00:00.839408 *** *** END *** 1 ***
Ok, fixed a trivial bug in the test.
please add the post_attributes to the test.
Done.
OK - ucs test OK - update, resolve GPO and WMI SINGLE-VALUE rejects OK - missing single value config for GPO and WMI OK - YAML
<http://errata.univention.de/ucs/4.0/211.html>