Univention Bugzilla – Bug 31172
sync from ucs: 'otherTelephone': no such attribute for delete
Last modified: 2017-08-23 14:17:08 CEST
During the initial sync of the S4 connector on a DC Master tracebacks like the following occur for a couple of users in a specific customer environment. We should identify the cause and try to avoid this in den connector code: ============================================================================ 23.04.2013 11:34:15,3 LDAP (PROCESS): sync from ucs: [ user] [ add] cn=user123,cn=users,ou=ou1,dc=foo,dc=bar 23.04.2013 11:34:15,54 LDAP (WARNING): sync failed, saved as rejected 23.04.2013 11:34:15,54 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 753, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2243, in sync_from_ucs self.lo_s4.lo.modify_ext_s(compatible_modstring(object['dn']), compatible_modlist(modlist), serverctrls=ctrls) 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) NO_SUCH_ATTRIBUTE: {'info': "attribute 'otherTelephone': no such attribute for delete on 'CN=user123,CN=users,OU=ou1,DC=foo,DC=bar'", 'desc': 'No such attribute'} ============================================================================
Level 4 log in upload_haU3bS.bz2 attached to Ticket#: 2013041821001047. Unfortunately due to Bug 31133 the modlist is not logged. ldifs of the example can by found in the Ticket as well.
I have the same problem. I can i resolve it?
(In reply to Thomas Manninger from comment #2) > I have the same problem. I can i resolve it? after a univention-s4-connector restart, it works correctly.
Also seen at 2014041721010635, Latest UCS@School at UCS 3.2-1 while initially syncing exam-users to s4. This causes a persistent reject as exam users will be removed after exam.
(In reply to Arvid Requate from comment #1) > Level 4 log in upload_haU3bS.bz2 attached to Ticket#: 2013041821001047. > Unfortunately due to Bug 31133 the modlist is not logged. ldifs of the > example can by found in the Ticket as well. We have modlists at the referenced ticket - relevant snip: [(1, 'otherTelephone', None), (2, 'streetAddress', [u'F...and so on...
Created attachment 5884 [details] con_other_attribute_DEL.patch Untestet patch proposal. No idea why this doesn't occur for the primary attribute "telephoneNumber".
Also reported at Ticket #2014062621000429.
I've fixed this while writing a test case for Bug #35391. It doesn't make sense to add a MOD_DELTE to the modlist for a new object. UCS 3.2-3: r53315 UCS 4.0-0: r53316 YAML: r53318
Changing the phone number in in windows adds the old number to "otherTelephone". -> univention-ldapsearch cn=Administrator| grep -i phoneNu telephoneNumber: 126 -> univention-s4search cn=Administrator| grep -i phoneNu telephoneNumber: 126 Modified telephon number via windows RSAT to 127 Modified telephon number via windows RSAT to 128 -> univention-s4search cn=Administrator| grep -i phone telephoneNumber: 128 otherTelephone: 128 otherTelephone: 127 -> univention-ldapsearch cn=Administrator| grep -i phone telephoneNumber: 128 telephoneNumber: 127
(In reply to Felix Botner from comment #9) > Changing the phone number in in windows adds the old number to > "otherTelephone". Good catch. The problem is independent from my change. However, it is a bug and it should have been fixed with: UCS 3.2-3: r53462 UCS 4.0-0: r53463 YAML: r53464
This part of commits r53315 and r53316 looks strange: Index: modules/univention/s4connector/lockingdb.py =================================================================== --- modules/univention/s4connector/lockingdb.py (Revision 53314) +++ modules/univention/s4connector/lockingdb.py (Revision 53315) @@ -220,6 +220,10 @@ print 'E: uuid1 is locked for UCS' l.lock_ucs(uuid1) + l.lock_ucs(uuid1) + l.lock_ucs(uuid1) + l.lock_ucs(uuid1) + l.lock_ucs(uuid1)
(In reply to Arvid Requate from comment #11) > This part of commits r53315 and r53316 looks strange: > > > Index: modules/univention/s4connector/lockingdb.py > =================================================================== > --- modules/univention/s4connector/lockingdb.py (Revision 53314) > +++ modules/univention/s4connector/lockingdb.py (Revision 53315) > @@ -220,6 +220,10 @@ > print 'E: uuid1 is locked for UCS' > > l.lock_ucs(uuid1) > + l.lock_ucs(uuid1) > + l.lock_ucs(uuid1) > + l.lock_ucs(uuid1) > + l.lock_ucs(uuid1) That's only test code. I tested if it is possible to lock a uuid multiple times.
Ok, works. * Created a udm user with two phone numbers: sync ok * Created a udm user with one phone number: sync ok * Added another phone number via RSAT: sync ok * Removed the primary phone number in RSAT: sync ok, otherTelephoneNumber remains * Added another phone number via udm: sync ok, set as primary Advisory is ok as well.
http://errata.univention.de/ucs/3.2/199.html