Univention Bugzilla – Full Text Bug Listing |
Summary: | Initialize ldap handler without listener (a simple slapadd instead of replication.py) | ||
---|---|---|---|
Product: | UCS | Reporter: | Michel Smidt <michelsmidt> |
Component: | Listener (univention-directory-listener) | Assignee: | UCS maintainers <ucs-maintainers> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P5 | CC: | botner, gohmann, hahn, requate, steuwer |
Version: | UCS 4.4 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | Linux | ||
What kind of report is it?: | Feature Request | What type of bug is this?: | --- |
Who will be affected by this bug?: | --- | How will those affected feel about the bug?: | --- |
User Pain: | Enterprise Customer affected?: | Yes | |
School Customer affected?: | ISV affected?: | ||
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | Bug group (optional): | Forked for project | |
Max CVSS v3 score: | |||
Bug Depends on: | 35165, 35170, 38823 | ||
Bug Blocks: |
Description
Michel Smidt
2016-01-27 14:17:47 CET
(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". |