With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI).
In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :)
Ralf Haferkamp wrote:
With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI).
In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :)
One thing I find to be extremely awkward about other directory server products is the fact that they corral you into using their custom tools to do administration. If they even have a generic admin interface it's poorly documented and hidden in a corner somewhere.
My point in implementing back-config is not only that it allows dynamic changes, but that it can be operated using standard LDAP requests, manipulated using generic tools, and requires no auxiliary programs to support it. As such, I don't see much benefit in designing custom APIs for configuration. Specialized, task-oriented UIs sometimes make sense, but I think if they use specialized APIs then something is wrong with the design.
Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
In a lot of ways I think homegrown solutions are the only way to go. People seem to believe that there are a ton of common operations that every site needs to do, but in reality, every site has different deployment styles and policies. They look the same from 10,000 feet, but at the detail level they're nothing alike.
That means you wind up needing a tool that is extensively configurable, to present just the set of menus or tasks that you want to deploy. If this tool is general-purpose enough, and can be customized enough to be focused on the tasks of interest, it will inevitably be even more complicated to configure than slapd itself.
For the moment I think it would make most sense to take something like Apache Directory Studio, which already has comprehensive capabilities and configurability, and just provide some sample modules for it.
On the command line, the only thing I ever wish for is a more compact input format than LDIF.
That's just my personal reaction, based on my experiences with numerous deployments; other folks' experience will probably differ.
On Dienstag, 15. Januar 2008, Howard Chu wrote:
Ralf Haferkamp wrote:
With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI).
In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :)
One thing I find to be extremely awkward about other directory server products is the fact that they corral you into using their custom tools to do administration. If they even have a generic admin interface it's poorly documented and hidden in a corner somewhere.
My point in implementing back-config is not only that it allows dynamic changes, but that it can be operated using standard LDAP requests, manipulated using generic tools, and requires no auxiliary programs to support it.
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.
As such, I don't see much benefit in designing custom APIs for configuration. Specialized, task-oriented UIs sometimes make sense, but I think if they use specialized APIs then something is wrong with the design.
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.
Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
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.
In a lot of ways I think homegrown solutions are the only way to go. People seem to believe that there are a ton of common operations that every site needs to do, but in reality, every site has different deployment styles and policies. They look the same from 10,000 feet, but at the detail level they're nothing alike.
That means you wind up needing a tool that is extensively configurable, to present just the set of menus or tasks that you want to deploy. If this tool is general-purpose enough, and can be customized enough to be focused on the tasks of interest, it will inevitably be even more complicated to configure than slapd itself.
Yes, that's a good point. And something that we should of course avoid.
For the moment I think it would make most sense to take something like Apache Directory Studio, which already has comprehensive capabilities and configurability, and just provide some sample modules for it.
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 ;)
On the command line, the only thing I ever wish for is a more compact input format than LDIF.
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?
That's just my personal reaction, based on my experiences with numerous deployments; other folks' experience will probably differ.
Ralf Haferkamp wrote:
On Dienstag, 15. Januar 2008, Howard Chu wrote:
Ralf Haferkamp wrote:
With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI).
In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :)
One thing I find to be extremely awkward about other directory server products is the fact that they corral you into using their custom tools to do administration. If they even have a generic admin interface it's poorly documented and hidden in a corner somewhere.
My point in implementing back-config is not only that it allows dynamic changes, but that it can be operated using standard LDAP requests, manipulated using generic tools, and requires no auxiliary programs to support it.
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.
Agreed.
As such, I don't see much benefit in designing custom APIs for configuration. Specialized, task-oriented UIs sometimes make sense, but I think if they use specialized APIs then something is wrong with the design.
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.
Just some kind of wrapper lib. I guess it's up to whatever language you use and write something for your own use. I thinking like the CPAN etc.
Depends what UI you want to write.
Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
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.
This question always gets asked by customers ;-) The answer is they are free to chose.
Whenever anything gets mentioned, like Howard says, each rolls their own...
In a lot of ways I think homegrown solutions are the only way to go. People seem to believe that there are a ton of common operations that every site needs to do, but in reality, every site has different deployment styles and policies. They look the same from 10,000 feet, but at the detail level they're nothing alike.
That means you wind up needing a tool that is extensively configurable, to present just the set of menus or tasks that you want to deploy. If this tool is general-purpose enough, and can be customized enough to be focused on the tasks of interest, it will inevitably be even more complicated to configure than slapd itself.
Yes, that's a good point. And something that we should of course avoid.
For the moment I think it would make most sense to take something like Apache Directory Studio, which already has comprehensive capabilities and configurability, and just provide some sample modules for it.
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 ;)
On the command line, the only thing I ever wish for is a more compact input format than LDIF.
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?
That's just my personal reaction, based on my experiences with numerous deployments; other folks' experience will probably differ.
Ralf Haferkamp wrote:
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.
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.
On Mittwoch, 16. Januar 2008, Michael Ströder wrote:
Ralf Haferkamp wrote:
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.
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:
- Configuration (network config, backends, indexing, ACLs, etc.)
This is what I was talking about. I thought that was clear, when I mentioned back-config in my original posting ;)
- Directory user and group management related to access control
- 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.
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product, that is also used by people that are not too familiar with OpenLDAP. Ok, one might argue now, that people not really familiar with OpenLDAP should not use it, but I tend to disagree a bit here ;).
I pretty much agree with the rest of your mail.
Ralf Haferkamp wrote:
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. :-)
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
that is also used by people that are not too familiar with OpenLDAP. Ok, one might argue now, that people not really familiar with OpenLDAP should not use it, but I tend to disagree a bit here ;).
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.
On Mittwoch, 16. Januar 2008, Michael Ströder wrote:
Ralf Haferkamp wrote:
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. :-)
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
Of course my aim is somewhat focused on what I am getting paid for, whose isn't? :) But additionally to that I was trying to find out if there is a general interest among the OpenLDAP Developers to have some kind of management tools/api. If there were, we could have started something that would serve both interests. I am trying to avoid a solution just specific to our products.
that is also used by people that are not too familiar with OpenLDAP. Ok, one might argue now, that people not really familiar with OpenLDAP should not use it, but I tend to disagree a bit here ;).
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.
Ralf Haferkamp wrote:
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
Of course my aim is somewhat focused on what I am getting paid for, whose isn't? :)
we routinely feel similar needs.
But additionally to that I was trying to find out if there is a general interest among the OpenLDAP Developers to have some kind of management tools/api. If there were, we could have started something that would serve both interests. I am trying to avoid a solution just specific to our products.
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@sys-net.it ---------------------------------------
On Donnerstag, 17. Januar 2008, Pierangelo Masarati wrote:
Ralf Haferkamp wrote:
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
Of course my aim is somewhat focused on what I am getting paid for, whose isn't? :)
we routinely feel similar needs.
But additionally to that I was trying to find out if there is a general interest among the OpenLDAP Developers to have some kind of management tools/api. If there were, we could have started something that would serve both interests. I am trying to avoid a solution just specific to our products.
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.
The API that I had in mind would have some knowledge how back-config is structured and have functions to read specific parts of the configuration (e.g. a single database or overlay) into datastructures. Additionally it would provide functions to access those structures. A simple example: In order to create a new index on a database you'd call something like this:
db = olcConfig.getDatabase("<suffix>"); db.addIndex("<attribute>", SLAP_INDEX_EQ); db.commit();
Providing this kind of detailed API for every possible slapd parameter would probably be an overkill and too much to implement, even if one would chose as similar table based approach as inside slapd. It should probably only done for the most important settings (which are of course hard to define). The rest of the attributes should probably be handled by more generic getter/setter-functions.
As for usecases, that Michael asked for in his last mail, I have the e.g. following in mind:
- add a simple database - manage ACLs and indexes on that database - configure some overlays on that database (e.g. ppolicy, refint, memberof) - setup replication - manage the schema (not a complete schema editor to define new objectclasses and attribute types, but the possibility to add existing definitions to the server) - or as something completely different, but also requested some times: setup a caching proxy server.
Ralf Haferkamp wrote:
On Mittwoch, 16. Januar 2008, Michael Ströder wrote:
Ralf Haferkamp wrote:
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. :-)
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
Of course my aim is somewhat focused on what I am getting paid for, whose isn't? :)
Yes, this was not meant as offense.
But additionally to that I was trying to find out if there is a general interest among the OpenLDAP Developers to have some kind of management tools/api.
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.
On Donnerstag, 17. Januar 2008, Michael Ströder wrote:
Ralf Haferkamp wrote:
On Mittwoch, 16. Januar 2008, Michael Ströder wrote:
Ralf Haferkamp wrote:
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. :-)
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
Of course my aim is somewhat focused on what I am getting paid for, whose isn't? :)
Yes, this was not meant as offense.
I didn't take it as an offense. But thanks for clarifying ;-)
But additionally to that I was trying to find out if there is a general interest among the OpenLDAP Developers to have some kind of management tools/api.
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?
I listed some in my last reply to Ando.
Howard Chu writes:
One thing I find to be extremely awkward about other directory server products is the fact that they corral you into using their custom tools to do administration. If they even have a generic admin interface it's poorly documented and hidden in a corner somewhere. (...) Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
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.
(...) On the command line, the only thing I ever wish for is a more compact input format than LDIF.
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.
<quote who="Hallvard B Furuseth">
Howard Chu writes:
One thing I find to be extremely awkward about other directory server products is the fact that they corral you into using their custom tools to do administration. If they even have a generic admin interface it's poorly documented and hidden in a corner somewhere. (...) Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
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.
(...) On the command line, the only thing I ever wish for is a more compact input format than LDIF.
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.
ldapvi is very good for all this.
http://www.lichteblau.com/ldapvi/
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:
(...) On the command line, the only thing I ever wish for is a more compact input format than LDIF.
ITS#5312 - ldapmodify defaults:-)
I didn't think I could start such a long thread...
ldapvi is very good for all this. http://www.lichteblau.com/ldapvi/
Wish we'd known about that a couple of years back; thanks!
On Dienstag, 15. Januar 2008, Hallvard B Furuseth wrote:
Howard Chu writes:
One thing I find to be extremely awkward about other directory server products is the fact that they corral you into using their custom tools to do administration. If they even have a generic admin interface it's poorly documented and hidden in a corner somewhere. (...) Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
Indeed. For most of my tasks, my editor is the best API I've got. Or it would be if the task allowed it.
Yes. But on the other hand you are a very experienced OpenLDAP user :)
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.
(...) On the command line, the only thing I ever wish for is a more compact input format than LDIF.
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.
Hm, have you heard of ldapvi? I think that does exactly what you are describing above:
http://www.lichteblau.com/ldapvi/
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.
[Ralf Haferkamp]
Hm, have you heard of ldapvi? I think that does exactly what you are describing above:
Thanks, will look.
[Hallvard B Furuseth]
Assertion controls in the generated LDIF (...) 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.
Or rather dynamically generated, since people might edit LDIFs in cn=config by hand if slapd won't start.
From an implicitly included overlay, I guess. (Lacking that, it could at least check modifyTimeStamp.)
Hallvard B Furuseth wrote:
Indeed. For most of my tasks, my editor is the best API I've got. Or it would be if the task allowed it.
In recent version of web2ldap you can switch the input form when adding/modifying entries from HTML template to raw table to LDIF multi-line text field without loosing the changes you made in another form before.
Howard Chu writes:
(...) On the command line, the only thing I ever wish for is a more compact input format than LDIF.
ITS#5312 - ldapmodify defaults:-)
web2ldap has the capability to let you configure LDIF templates in a quick-list for adding new entries quickly. It ships with example LDIF templates for BDB backend configurations for OpenLDAP's back-config and HTML input form templates.
Maybe read page 19 and 20 of this: http://www.openldap.org/conf/odd-tuebingen-2006/Michael.pdf
From my understanding ITS#5312 is not about attribute value defaults though.
Ciao, Michael.
Hallvard B Furuseth wrote:
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.
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.
For similar reasons it'd help to have EQUALITY matching rules on all cn=config attributes.
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.
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).
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.
Michael Ströder writes:
[rearranging a little]
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. :-/
Oh, I'm unsurprised that some of this exists already. I've written my own bits and pieces long ago, after all. (Not for back-config though.) And we could collect some suggestions to software to use in the doc, just as well as including some code.
The FAQ lists various clients, but it just lists them - doesn't give much clue about which one would want to look at for what.
Hallvard B Furuseth wrote:
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.
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.
Not sure if I should be writing this since I've hardly looked at web2ldap yet, but anyway... I don't quite get that. I'd think a correct delta would be generated by comparing with the entries as they looked when the user started editing. Minus any changes that have happened already. With back-config I would _not_ my changes to be applied without asking me if there had been changes since I started editing, hence my suggestion of assertions. A delta agains the current directory would be useful to see if my own changes conflict in intent with the changes that have already happened (regardless of whether my changes would apply cleanly.)
For similar reasons it'd help to have EQUALITY matching rules on all cn=config attributes.
The delta modification list generated by web2ldap does not contain a del <old value> to avoid problems with missing EQUALITY matching rules.o
As I said in the next sentence this would be useful when writing a change LDIF by hand (instead of a tool which generates the diffs).
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).
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... ;-)
But it can't when you are not using it, just writing a change by hand. Also it might not catch if someone has renamed the entries - like adding a new database definition which gets the name of the one you are editing. You may end up adding a new overlay to thewrong database, or something. (Assuming back-config supports adding a new db in the middle yet, I haven't checked.) Don't know if web2ldap does this, but it's in any case an unnecessary problem.
Hallvard B Furuseth wrote:
Michael Ströder writes:
Hallvard B Furuseth wrote:
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.
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.
Not sure if I should be writing this since I've hardly looked at web2ldap yet, but anyway... I don't quite get that. I'd think a correct delta would be generated by comparing with the entries as they looked when the user started editing. Minus any changes that have happened already.
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.
Hallvard B Furuseth wrote:
Michael Ströder writes:
Hallvard B Furuseth wrote:
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.
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.
Not sure if I should be writing this since I've hardly looked at web2ldap yet, but anyway... I don't quite get that. I'd think a correct delta would be generated by comparing with the entries as they looked when the user started editing. Minus any changes that have happened already. With back-config I would _not_ my changes to be applied without asking me if there had been changes since I started editing, hence my suggestion of assertions. A delta agains the current directory would be useful to see if my own changes conflict in intent with the changes that have already happened (regardless of whether my changes would apply cleanly.)
web2ldap 0.16.26 now passes around a assertion filter for cross-checking whether an entry was modified/removed in between. At the moment this is only applied as a search filter when re-reading the entry to determine the delta modification list.
I will also pass this assertion filter along with the modify request once python-ldap supports the assertion control...
Ciao, Michael.
Michael Ströder wrote:
Hallvard B Furuseth wrote:
For similar reasons it'd help to have EQUALITY matching rules on all cn=config attributes.
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.
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.
Michael Ströder writes:
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.
Actually I wasn't suggesting that for web2ldap, though it sounds nice. At the time I was talking about how EQUALITY rules would make it easier to write config LDIFs by hand.
Howard Chu wrote:
Tools that make certain commonplace tasks easier are certainly a good thing. But when the tools get in the way, (e.g., FedoraDS where there are even more bug reports about getting their admin server running than for their actual directory server), the whole effort is just pointless.
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.
-
Dave Horsfall -
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder -
Pierangelo Masarati -
Ralf Haferkamp