[python-ldap] Problems with Syncrepl in refresh and persist mode when reconnecting after database changes
bcooksley at kde.org
Sun May 27 22:53:28 CEST 2012
I am currently experimenting with the Syncrepl demo application, and
when I test the following scenario, I can reliably get it to bail out:
- Perform a first start, and let it settle and sync it's database. Any
changes made while it is running will be handled correctly
- Stop the demo, and make a change to one of the previously monitored items
- Starting the demo again will now cause it to fail with this error:
SingleValueConstraint(0, 1)) failed at: "SingleValueConstraint(0, 1)
failed at: "-1"" at Boolean
Prior to it failing, it outputs the following:
I will also note that the Perl LDAP bindings also fail when attempting
to operate in this manner - but not with a decoding failure.
Instead, the syncUUIDs values it provides are too short (15 characters
instead of 16 - a RFC violation), and corrupted (when decoded into a
text representation, only numbers are given instead of the usual
letters and numbers, and the strings are too short as well)
If I bind as the root DN, then this issue does not occur, however it
seems to be merely avoided as the Intermediate Sync Control isn't
sent, instead it sends LDAP Entries for each changed item (even if
multiple items are changed).
Is this a bug in both the Python and Perl LDAP bindings, or in OpenLDAP?
For both, the user being used here has sufficient permissions to read
and write the entries that are being modified. They are handled
properly if the Python or Perl processes are running when the
modification is made.
OpenLDAP 2.4.26 (OpenSUSE 12.1) and OpenLDAP 2.4.23 (Debian Squeeze)
were the two servers I tested against, both using the 'syncprov'
overlay, with the following options:
syncprov-checkpoint 100 10
I tested with pyasn1 0.1.3 and python-ldap 2.4.9.
Any pointers as to why this is not working would be fantastic.
More information about the python-ldap