Bug 41837 - Inject ACL and schema extensions into Master slapd without restarting it
Inject ACL and schema extensions into Master slapd without restarting it
Status: REOPENED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.4
Other Linux
: P5 enhancement with 4 votes (vote)
: ---
Assigned To: UCS maintainers
:
Depends on: 43515
Blocks: 44925
  Show dependency treegraph
 
Reported: 2016-07-21 19:00 CEST by Arvid Requate
Modified: 2021-05-26 21:13 CEST (History)
3 users (show)

See Also:
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?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): API change, Further conceptual development, Troubleshooting
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2016-07-21 19:00:38 CEST
Currently the LDAP server on the DC Master gets restarted whenever a joining UCS system registers a LDAP ACL or schema. I'm not too sure if the joinscripts of the joining system are fault tolerant enough with respect to downtimes of the master LDAP server.

Maybe we can do this without restarting the master slapd by using the cn=config backend in OpenLDAP. If we would activate that on the master, we would have the possibility to inject ACL and schema changes into the running slapd. While switching completely to the cn=config backend as primary means of configuration seems to have too many strings attached (e.g. inclusion of slapd.conf.d subfiles) just activating cn=config as a secondary option could have some potential.

In that scenario, the ldap_extension listener would do the same steps as it does now: write the ACL of schema subfile, register it, commit slapd.conf, slaptest it for consistency and if all that worked, it would simply not restart slapd, but generate a suitable cn=config LDIF and apply that. This might be worth to try. Later, if the slad is restarted regularly at some point, it would simply pick up the usual slapd.conf file as usual.
Comment 1 Arvid Requate univentionstaff 2016-07-21 19:20:29 CEST
Bug 39619 might be a case that could be avoided with this strategy.
Comment 2 Stefan Gohmann univentionstaff 2019-01-03 07:20:11 CET
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact
your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
Comment 3 Arvid Requate univentionstaff 2019-03-20 18:50:49 CET
cn=config is now accessible (via LDAPI, Bug #43515).

As a next steht we would need a script that takes acl and schema subfiles, filters them though UCR and converts the result into an ldif (or modlist) that can be used for ldapmodify. For schema that is described here: http://www.zytrax.com/books/ldap/ch6/slapd-config.html#use-general
   
Before we invest in that we need to find out if we can get the line ordering (multivalued X-ORDERED attributes) right, so we can precisely inject the new ACLs where they should go.