Problem: S4-Connector reject about "Object has been removed before but became visible again

Problem:

The s4-connector generates this rejects when modifiying objects

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/univention/s4connector/__init__.py", line 837, in __sync_file_from_ucs
    if not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new, restored=restored):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/univention/s4connector/s4/__init__.py", line 2046, in sync_from_ucs
    if self.restore_in_s4(object, property_type):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/univention/s4connector/s4/__init__.py", line 2467, in restore_in_s4
    self.lo_s4.lo.modify_ext_s(
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 400, in modify_ext_s
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 543, in result3
    resp_type, resp_data, resp_msgid, decoded_resp_ctrls, retoid, retval = self.result4(
                                                                           ^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 553, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 128, in _ldap_call
    result = func(*args,**kwargs)
             ^^^^^^^^^^^^^^^^^^^^
ldap.UNWILLING_TO_PERFORM: {'msgtype': 103, 'msgid': 416, 'result': 53, 'desc': 'Server is unwilling to perform', 'ctrls': [], 'info': '00002035: Trying to restore not deleted object\n at ../../source4/dsdb/samdb/ldb_modules/tombstone_reanimate.c:376'} | x_filename=/var/lib/univention-connector/s4/1773052849.989480

Investigation:

The S4 Connector maintains several database tables; two of them are relevant here: the “UCS deleted” table and the newer “uoid2guid” table.

The uoid2guid table contains a mapping between the univentionObjectIdentifier (key) in LDAP and the objectGUID (value) in Samba4.

The “UCS deleted” table contains a mapping from the LDAP entryUUID / UOI to the objectGUID of deleted objects.

Entries may look like the following examples:

8a1126c0-aedf-103a-9bca-ff269e4955f9|224443b3-cb29-4028-a664-7518c949614f
ceb76276-6e01-1040-9283-776241f997ad|objectGUID

If there is a discrepancy between the entries in uoid2guid and UCS deleted, this may indicate potential issues.

Checking the object:

univention-ldapsearch -LLL uid=lilly$ univentionObjectIdentifier
dn: cn=LILLY,cn=computers,dc=schein,dc=com
8a1126c0-aedf-103a-9bca-ff269e4955f9

univention-s4search samaccountName=lilly$ 1.1
# record 1
dn: CN=LILLY,CN=Computers,DC=schein,DC=com

checking the database for univentionObjectIdentifier to objectGUID mapping:

sqlite3 /etc/univention/connector/s4internal.sqlite
sqlite> select value from 'uoid2guid' where key like '8a1126c0-aedf-103a-9bca-ff269e4955f9';
b5dc4721-de33-454a-8dee-bad24bec6c17

This entry matched to:

univention-s4search --cross-ncs --show-deleted objectGUID=b5dc4721-de33-454a-8dee-bad24bec6c17 1.1
# record 1
dn: CN=LILLY,CN=Computers,DC=schein,DC=com

Now check the UCS deleted table for deleted mapping

sqlite> select * from 'UCS deleted' where key like '8a1126c0-aedf-103a-9bca-ff269e4955f9';
8a1126c0-aedf-103a-9bca-ff269e4955f9|224443b3-cb29-4028-a664-7518c949614f

There is an entry in the UCS deleted table, which is not present in samba4 anymore:

univention-s4search --cross-ncs --show-deleted objectGUID=224443b3-cb29-4028-a664-7518c949614f

Nothing found.

Solution:

What happened her is, that the s4-connector looks in the UCS deleted table for deleted objects to restore, and found an entry, which is no longer present, and ignores completely that there is a propper mapping and object in samba4.
So we have to remove the database entry to get the reject resolve. The connector does not find a suitable entry anymore and synchronizes the object.

Delete the outdated entry:

sqlite> delete from 'UCS deleted' where key='8a1126c0-aedf-103a-9bca-ff269e4955f9'

see also Bug 59113
The script attached to the Bug might come handy to analyse the state of the UCS deleted database table of the s4-connector

1 Like