Univention Bugzilla – Bug 40514
Initialize ldap handler without listener (a simple slapadd instead of replication.py)
Last modified: 2019-04-24 14:23:32 CEST
The univention-directory-listener was forked for customer. Changes: * Initialize handlers only. Issue #570 * "fake" listener handler initialization. Issue #570 * Added database copy support (From the changelog). * Performance in univention-get-ldif-from-master.py (From the changelog) * Prevent certain LDAP objects from being stored in the local Listener cache. Issue #2387 Goal is to create an API or merge the fork to the product.
(In reply to Michel Smidt from comment #0) > The univention-directory-listener was forked for customer. > Changes: > * Initialize handlers only. Issue #570 > * "fake" listener handler initialization. Issue #570 Bug #35165 > * Added database copy support (From the changelog). > * Performance in univention-get-ldif-from-master.py (From the changelog) Bug #35170 > * Prevent certain LDAP objects from being stored in the local Listener > cache. Issue #2387 Already implemented via Bug #38823
Please provide more information about the goal and split these issues into separate bugs.
(In reply to Stefan Gohmann from comment #2) > Please provide more information about the goal and split these issues into > separate bugs. Only one change left: * Performance in univention-get-ldif-from-master.py (From the changelog) Asked author for more information.
(In reply to Michel Smidt from comment #3) > (In reply to Stefan Gohmann from comment #2) > > Please provide more information about the goal and split these issues into > > separate bugs. > > Only one change left: > * Performance in univention-get-ldif-from-master.py (From the changelog) > > Asked author for more information. There is a new script python/univention-get-ldif-from-master.py in the univention-directory-listener source package, This script is used during the fake ldap initialization (if no ldif or database backend file is provided) to create a local ldif of the masters ldap database. The commits a8376edbdc566aea4ccd919f32b9a0662034f3fb ce122e862d78ffc03a1e1c4ba42f625ca2e23221 improved the performance of the ldap search script (univention-get-ldif-from-master.py) and the import of the ldif in 03univention-directory-listener.inst.
Intention of this changes and the related bugs #35165, #35170 and #38823 was to initialize handlers without listeners. The initialization of the listener handlers will be skipped and in some cases initialized differently or just don't initialized. For the LDAP the script python/univention-get-ldif-from-master.py was introduced. This script basically read the ldap from the DC master, create a ldif file and update the local schema. This bug is about this "fake replication" and the optimizations.
In addition: the main goal here is to join in an environment that has more entries in LDAP than the sizelimit/timelimit allows to replicate during join. By initializing the replication listener plugin "manually" and deploy the LDAP based on an LDIF we avoid to run into timeouts. Similar processing is needed for other listener plugins.
Generally we should adjust the listener to use paging during the initial search but I understand there's still a performance issue with very large data sets. Also Felix reminded me that the listener sorts the returned DNs, but I doubt that that's still necessary with current OpenLDAP versions.
(In reply to Arvid Requate from comment #7) > Also Felix reminded me that the listener sorts the returned DNs, but I doubt > that that's still necessary with current OpenLDAP versions. The "sorting" is used to guarantee that parent nodes are pulled before their children, e.g. "pre-order". AFAIK ldapsearch doesn't guarantee any ordering by default, so "post-order" is allowed by the spec: <https://tools.ietf.org/html/rfc4511#section-4.5.2> > The SearchResultEntry and SearchResultReference messages may come in any order. Sorting by »len(dn)« would be enough.
*** Bug 35170 has been marked as a duplicate of this bug. ***
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
There is a Customer ID set so I set the flag "Enterprise Customer affected".