Chris Hiestand wrote:
Part 1: Readability
I know you veterans are probably sick to death of us late-comers asking questions about cn=config. I understand but please hear me out because I feel I have done due diligence; but I still have some concerns with the transition. Workflow has been discussed before, but I suspect it hasn't been fleshed out because the switch from editing schema and ACLs in flat files to LDAP entries reduces readability. I have no problem using cn=config for most configuration attributes, but it gets a lot less user friendly when the value is, what used to be in slapd.conf, a multi-line string. But I could just be missing something. Your help is appreciated.
Attached are some screenshots of editing ACLs and a custom schema via 3 methods:
- cn=config via ldap client (ie apache directory studio)
- cn=config via ldif
- old style slapd.conf
Look at the pictures and pick which method you'd like to use to edit ACLs or a schema:
http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldap.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldif.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-slapd.conf.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldap.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldif.png http://snl.salk.edu/~chiestand/openldap/schema-via-slapd.conf.png
I think the choice is clearly old style slapd.conf. Otherwise you miss comments and ordering (until Howard Chu's X-ORDERED ldap extension is implemented), and unlimited whitespace to substantially improve readability.
The LDIF files are a mess because of the way words are split unpredictably by new lines. You can't use a simple search and replace with any hope of it working. Readability would be vastly improved with new lines before keywords (eg to, filter, attrs …) but I don't think it's possible to have ldapsearch output this way.
As an LDAP Admin you're going to have to learn to deal with LDIF anyway. This is the most trivial of complaints and seems to be dealt with every couple of years on these mailing lists.
http://www.openldap.org/lists/openldap-technical/201009/msg00140.html
Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better).
The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks.
Am I just missing workflow techniques or key concepts that improves readability? Or is your advice to just suck it up and get used to it?
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific.
Not likely.
What about whole schema deletes? From a sysadmin perspective, I should be able to add, modify, or delete anything from the configuration. For QA reasons, you want to be have the exact configuration you want; not the configuration you want plus legacy boogers.
I understand if this isn't trivial to achieve from the developer perspective. Granted I don't have the whole picture here, but I'd argue that it's worth it.
The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone.
On the other hand, we should certainly provide a slapdelete tool for removing things while slapd is offline. If you have screwed up your configuration so badly that you need to delete something from it, you might as well restart the server anyway.
Lastly, I thank everyone who contributes to OpenLDAP.