Radovan Semancik wrote:
Hi,
The "cn=config" configuration method is clearly superior. However, there are serious practical issues. Firstly, the documentation leaves a lot to be desired. Until recently almost all examples shown the slapd.conf way, cn=config equivalent was simply missing. Unless I have missed something most manual pages still assume the slapd.conf configuration method. And so on.
These perennial arguments keep coming up. If you want things to improve, contribute. Anyone can write a manpage. Hardly anyone ever does. Everyone sits back and moans while waiting for someone else to fix things for them. That's not what open source projects and communities are about.
Secondly, there are operations that simply cannot be done using ldpamodify in cn=config (e.g. removal of a suffix database). And thirdly and most importantly: it is a real pain to remember the configuration schema and write a multi-line ldapmodify command-line even for simple operations.
In most cases you don't need to write multi-line ldapmodify commands. That's what ordering prefixes are for.
Especially given that you have to translate suffix names (dc=example,dc=com) to configuration DNs (olcDatabase={1}mdb,cn=config), set up non-trivial configuration (e.g. replication) and so on. The cn=config method may be superior. But it is not user friendly. Not even close.
But, OpenLDAP is an open source project. If there is something that a user does not like then there is always something that can be done about it. For example, I like cn=config, but I hate the lack of tooling. Therefore I have created the missing tools:
Again, if you want the project to improve - contribute. 3rd party tooling dilutes the knowledge pool. If you think you've improved some aspect of the code, contribute it back to the Project.
Hi,
On 09/18/2017 02:44 PM, Howard Chu wrote:
These perennial arguments keep coming up. If you want things to improve, contribute. Anyone can write a manpage. Hardly anyone ever does. Everyone sits back and moans while waiting for someone else to fix things for them. That's not what open source projects and communities are about.
I would ... if this was a wiki, or github-like pull request and if there was an example of how a good result should look like. But it does not make sense for me to spend few hours just figuring out how to contribute documentation fix. Especially if I have already figured out how to fix my own problem. Well, in fact, I'm quite tempted to try to go down this thorny path anyway. Because I like OpenLDAP and I want to help. Just every time I see your "how to contribute" page I decide that I will leave that for the next time. But I'm quite sure that 99% of users will not even look for "how to contribute" page. They need a simple "contribute", "edit" or "pull request" button. But, we have discussed this before, haven't we?
In most cases you don't need to write multi-line ldapmodify commands. That's what ordering prefixes are for.
Well, every ldapmodify is either multi-line or one-ugly-and-insanely-long-line-that-is-not-really-user-friendly. There is a huge difference between "slapdconf add-overlay dc=example,dc=com memberof" and equivalent command that is using just ldapmodify.
Again, if you want the project to improve - contribute. 3rd party tooling dilutes the knowledge pool. If you think you've improved some aspect of the code, contribute it back to the Project.
Again, it would be probably already contributed to the project if the process was more user friendly. But what do I really need to do to contribute? First, I have to decide whether I'm OK to contribute under OpenLDAP license. The license is not really standard and I have to check whether there are some obligations or limitations for my future work. Then I need to find the right place in source code, check and update coding style (does it apply to perl?), headers, make it part of the build and distribution, format the patch (easy part) and submit. Then I will probably get criticized for some details in my contribution (yes, speculation, but given the overall tone used in this mailing list I think it is quite likely). It may easily take few weeks of work for my contribution to get accepted. And then I will need to submit every other update to the tools as patch. You will probably place the tools in "contrib" anyway and you will not spend any significant effort to maintain it (again, speculation, but I am right, am I not?). I will need to adapt to OpenLDAP release schedule, which, after all these years, is still a bit of mystery to me. If I remain the only contributor to the tools (which again, is quite likely) then what I will get from this move is the same thing as before. But with a lot of extra effort to get there. But what is perhaps the worst thing: If I contribute then it is not "fire and forget". I need to maintain the code in the long run. And if that means more pain to get the same result, you can probably understand that I'm not really motivated to contribute.
But, despite all of this, if you like the tools please take them and use them in OpenLDAP project. I will gladly change the license and and cooperate on inclusion to OpenLDAP project. But we need to find more efficient way to cooperate than the way you already have. Until that time I'm pretty much OK with a separate github project. Works for me.
openldap-technical@openldap.org
-
Howard Chu -
Radovan Semancik