On Dienstag, 15. Januar 2008, Howard Chu wrote: Yes, and I like it that way and I think any management tool should be completely optional and not changes this essential feature of back-config. A utility library that has some knowledge about back-config could make the creation of such UIs probably bit easier. That would be my whole point for such a library. Heh, and that's of course not where I want to go. On the other hand we have quite some customers demanding for tools to manage OpenLDAP, that's why I came here to find ways to improve that situation in a way that others could benefit from it as well. Yes, that's a good point. And something that we should of course avoid. Yes, that would probably worth a look as well. Though I have my issues with the huge framework in the back of Apache Directory Studio :). I probably have to come over that ;) Ok, that would throw XML out of the discussion :-). But seriously, do you think of something specialized on back-config? Or a generic approach that can replace LDIF? -- regards, Ralf

Ralf Haferkamp wrote: Ralf, at first one would have to define what "manage OpenLDAP" really means, by defining the use-cases needed. I'd distinguish the use-cases in categories: 1. Configuration (network config, backends, indexing, ACLs, etc.) 2. Directory user and group management related to access control 3. Maintaining the content retrieved by client applications. For 1. I usually ask my customers how they are going to implement the change management. After some discussion we usually end up with text-based config managed with version control. Something simple and handy. :-) Configuration changes in production are most times not that dynamic. Rather they are subject of a long-lasting change process. Tweaking text files is not the issue during this process. Dynamic reconfiguration if really needed for certain deployment situations (e.g. change of master/slave role) are implemented by home-grown scripts which must be thoroughly tested. Use cases in category 2. are much simpler than 1. If the number of changes is low and the change process itself is rather simple the existing tools cover this situation quite well. If specific workflows have to be followed there is not a single tool which covers all the variants you can find even within one company. ;-) Again a home-grown tool has to be implemented for more complex cases. 3. is most times done by home-grown tools or by syncing mass data from other sources. So like Howard I don't see much need for developing something like this. I rather see the need to teach the customers. ;-) Also bear in mind that an API might get very complex e.g. in case of tweaking things with special controls. Regarding customization of configuration tools I can also confirm that most people are asking for powerful customization features but then nobody bothers to read the docs to really customize a admin UI. Ciao, Michael.

Ralf Haferkamp wrote: I already imagined what your aim is. ;-) It's always difficult to draw the line. At least the approach with back-config makes it easier for a tool like yast to stay away from configuration changes made by a sophisticated admin compared to parsing full text files. Ciao, Michael.

Ralf Haferkamp wrote: we routinely feel similar needs. My main concern is that from an api to a management tool there is a big difference. It might be difficult to draw the line, if any line can be drawn at all. In terms of usefulness and demand, I'd concur with you. In terms of viable solution, perhaps you (we) should be more specific, try to propose something that looks like a plan, and see how everyone's needs fit in it. My 2c for now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

Ralf Haferkamp wrote: Yes, this was not meant as offense. I consider the LDAP C API to be inspired by what is sent/received over the wire. I'd expect such a higher-level management API to be inspired by certain management use-cases. So which use-cases do you have in mind? Ciao, Michael.

Howard Chu writes: Indeed. For most of my tasks, my editor is the best API I've got. Or it would be if the task allowed it. One main difference is tasks I don't know very well, when a specialized API can know it better than I do. Assuming it's correct, of course:-) Similarly, a good config API would be useful when one first sets up OpenLDAP. ITS#5312 - ldapmodify defaults:-) Seriously, some suggestions to simplify that: We can include a program which dumps out a subset of cn=config, lets you edit it, generates a diff from the original, shows the changes, and applies it. That at least gets rid the add:/delete:/replace: LDIF verbosity. It'd be nice if if it prettified the ldif a bit first, e.g. chose good places for line breaks in access statements. But I guess that needs a way for the server to tell the client how to format attributes, so it's a lot more work. (I'd like even more if something could generate slapd.conf-format and convert back to ldif, but that would have to be a slap tool or some magic LDAP request which gets a lot of help from slapd. I can't think of a reasonably simple way to do the latter.) As I think I've mentioned before, it'd help make things less verbose if back-config did not create attributes with defaulted values, or marked such defaults with an attribute option. Assertion controls in the generated LDIF, to check that the config entry being updated indeed matches the entry we read from cn=config and edited. This requires support for assertion controls in back-ldif/back-config, and some attribute for the assertion to test. Maybe an automatically maintained md5sum(contents of entry) attribute. From an implicitly included overlay, I guess. (Lacking that, it could at least check modifyTimeStamp.) For similar reasons it'd help to have EQUALITY matching rules on all cn=config attributes. When we write by hand an LDIF to feed ldapmodify, we can then write delete: <old value> / add: <new value>. That adds a extra check for what we are changing. I suggested once to give config entries more informative names than things like olcDatabase={0}<backend> too, more like oldDatabaseName=(something derived from suffix, if possible). That'd also make it easier to see what one is doing, and ensure it is done to the right entry. assert(olcSuffix=...) helps when editing the database entry, but can't be used on its subordinates. -- Regards, Hallvard

On Tue, 15 Jan 2008, Gavin Henry wrote: I didn't think I could start such a long thread... Wish we'd known about that a couple of years back; thanks! -- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

[Ralf Haferkamp] Thanks, will look. [Hallvard B Furuseth] Or rather dynamically generated, since people might edit LDIFs in cn=config by hand if slapd won't start. -- Regards, Hallvard

Hallvard B Furuseth wrote: BTW: web2ldap implements delta-modification. The entry is re-read right before the delta of the current entry and the user's input is generated. This works quite well since years with several LDAP servers. If there was a modification in between the delta modification still applies correctly. The delta modification list generated by web2ldap does not contain a del <old value> to avoid problems with missing EQUALITY matching rules. Instead the whole attribute is deleted and all attribute values are re-added. And before anyone complains: Managing large group entries with lots of values in the member attribute (being member, memberUID or whatever) is done in a separate UI with another modification approach which requires a EQUALITY matching rule for the member attribute. A configuration UI can display more information when listing backend entries read from e.g. 'description'. Guess what, web2ldap is already doing this - not only for cn=config... ;-) Ok, why I'm writing this? Sometimes I'm getting sick about people asking for a software with features which I've already implemented since years. The same feeling Howard has when people are citing old OpenLDAP benchmarks. :-/ Ciao, Michael.

Hallvard B Furuseth wrote: web2ldap trys to get close to a viable solution. The really correct solution would involve entry locking like available in RDBMS, maybe via an LDAP extended operation. Ciao, Michael.

Michael Ströder wrote: Hmm, I'm currently rethinking this approach: Since web2ldap and the delta-modification generator has full schema knowledge today I could look up whether there's an EQUALITY matching rule defined for a given attribute type and then explicitly delete certain attribute values like Hallvard suggested. But it only works if there's schema information available. That's why I'm nagging all the time to add each and every attribute type used in back-config and other operational attributes to the schema. I'd really like to make working this as robust as possible together with back-config. Ciao, Michael.

Howard Chu wrote: Let's be fair. The admin server of the Netscape/SunONE/Fedora DS was meant to manage a whole family of servers (LDAP, WWW, Mail, Calendar) organized in administration domains. So it's a more complex concept. If you're solely using the directory server it might be overkill. I used web2ldap most of the times to configure their server directly because it's much faster than the fat Java stuff. But I have to admit that it's easier to tweak things in cn=config of Netscape/SunONE DS with stock web2ldap than to manage back-config with it. The reason is that their config schema was designed from scratch utilizing separate object classes and attributes without preserving backward compability with old text-based config. This makes it possible for a DUA to almost do the right thing by just looking at the schema. Ciao, Michael.