Univention Bugzilla – Bug 35973
Last modified: 2015-01-21 12:24:09 CET
Seen on different customer Systems (UCS@School Slaves) and test environments as "UCS rejected":
1: UCS DN: cn=Subschema
S4 DN: <not found>
22.09.2014 04:37:25,373 LDAP (WARNING): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 904, in resync_rejected_ucs
if self.__sync_file_from_ucs(filename, append_error=' rejected'):
File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 711, in __sync_file_from_ucs
entryUUID = new.get('entryUUID')
TypeError: 'NoneType' object is unsubscriptable
Also reported from another customer.
This looks very similar to Bug 35628 but still it must have a different cause.
I adjusted two things in the connector:
a) Don't attempt to sync cn=Subschema
b) Log an error if EntryUUID is missing in a pickle file but continue
(In reply to Arvid Requate from comment #2)
> I adjusted two things in the connector:
> a) Don't attempt to sync cn=Subschema
> b) Log an error if EntryUUID is missing in a pickle file but continue
I'm unsure if it is the right way. I prefer not to continue, leave it as rejected and check the objects. Do we know which DNs / objects don't contain the UUID?
Ok, objects without entryUUID will be treated as rejects.
Package is rebuilt and advisory is updated.
> Do we know which DNs / objects don't contain the UUID?
"Servers SHALL generate and assign a new UUID to each entry upon its addition to the directory and provide that UUID as the value of the 'entryUUID' operational attribute." -- https://tools.ietf.org/html/rfc4530
So, elements that are not added to but instead generated by the LDAP server (like rootDSE and cn=Subschema) don't necessarily offer this attribute. The purpose of the attribute is to identify object wich may get (re)moved, so it makes sense that it's not assigned to rootDSE and cn=Subschema.
Code review: OK