I have been running a LDAP with 2.3.x series for awhile now without the cn=config stuff and I have been looking to add this functionality into our running setup. So i have read the http://www.openldap.org/ doc/admin23/slapdconf2.html stuff and I am still a bit confused.
I obviously have to have some basic slapd.conf file, what does it have to contain? And after i write basically the ldif for my config for cn=config, you would just use slapadd to add it? Maybe i am missing something could some shed some light?
----- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies derek@umiacs.umd.edu
Derek Yarnell wrote:
I have been running a LDAP with 2.3.x series for awhile now without the cn=config stuff and I have been looking to add this functionality into our running setup. So i have read the http://www.openldap.org/ doc/admin23/slapdconf2.html stuff and I am still a bit confused.
I obviously have to have some basic slapd.conf file, what does it have to contain? And after i write basically the ldif for my config for cn=config, you would just use slapadd to add it? Maybe i am missing something could some shed some light?
If you have an existing slapd.conf you can simply let slapd convert it to a cn=config database for you.
If you're writing a config LDIF from scratch, then yes, you slapadd it. There is no need for a slapd.conf file at all in this case. Just create the filesystem directory where the config database will live. E.g.: mkdir /usr/local/etc/openldap/slapd.d slapadd -F /usr/local/etc/openldap/slapd.d -n0 -l my_config.ldif
Howard Chu hyc@symas.com wrote:
If you have an existing slapd.conf you can simply let slapd convert it to a cn=config database for you.
That's the -F flag, but how does it works? I made little attemps, without much success.
As I understand, schema replication won't work with syncrepl on 2.3.x, right?
On Thursday 20 September 2007 05:35:14 Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
If you have an existing slapd.conf you can simply let slapd convert it to a cn=config database for you.
That's the -F flag, but how does it works? I made little attemps, without much success.
# mkdir /etc/openldap/slapd.d # slapd -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
(if slapd is already running, you need to stop it ... or if you just want to test conversion, you need to start the new one doing the conversion listening on a different port)
Regards, Buchan
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
If you have an existing slapd.conf you can simply let slapd convert it to a cn=config database for you.
That's the -F flag, but how does it works? I made little attemps, without much success.
As I understand, schema replication won't work with syncrepl on 2.3.x, right?
There's a new man page in 2.4 (slapd-config), but basically:
"Alternatively, an existing slapd.conf file can be converted to the new format using slapd or any of the slap tools: slaptest -f /usr/local/etc/openldap/slapd.conf -F ETCDIR/slapd."
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
If you have an existing slapd.conf you can simply let slapd convert it to a cn=config database for you.
That's the -F flag, but how does it works? I made little attemps, without much success.
As I understand, schema replication won't work with syncrepl on 2.3.x, right?
There's a new man page in 2.4 (slapd-config), but basically:
"Alternatively, an existing slapd.conf file can be converted to the new format using slapd or any of the slap tools: slaptest -f /usr/local/etc/openldap/slapd.conf -F ETCDIR/slapd."
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
Howard Chu wrote:
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
If you have an existing slapd.conf you can simply let slapd convert it to a cn=config database for you.
That's the -F flag, but how does it works? I made little attemps, without much success.
As I understand, schema replication won't work with syncrepl on 2.3.x, right?
There's a new man page in 2.4 (slapd-config), but basically:
"Alternatively, an existing slapd.conf file can be converted to the new format using slapd or any of the slap tools: slaptest -f /usr/local/etc/openldap/slapd.conf -F ETCDIR/slapd."
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
We should just write mindless howtos like the everyone else out there. Then all we need is some whytos ;-)
On Thursday 20 September 2007 16:37:58 Gavin Henry wrote:
Howard Chu wrote:
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
We should just write mindless howtos like the everyone else out there. Then all we need is some whytos ;-)
Maybe first a whynotto ... follow howtos without reading the documentation supplied with the version of the software you are using.
Regards, Buchan
Howard Chu hyc@symas.com wrote:
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
And it's a sad that project leaders immediatly assume users are just unwilling to read the docs, rather than wondering if the docs need improvement.
I just discovered why my slapd -f slapd.conf -F slapd.d attempt failed: permissions on the slapd.d directory were wrong, so slapd just start and quits without a message, leaving an empty directory.
I suspect I did not had the idea to check the logs because I was just expecting it to do the conversion in the foreground and exit. Obviously a wrong expectation.
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
And it's a sad that project leaders immediatly assume users are just unwilling to read the docs, rather than wondering if the docs need improvement.
We know they do, and we are. There's no wondering involved ;-)
I just discovered why my slapd -f slapd.conf -F slapd.d attempt failed: permissions on the slapd.d directory were wrong, so slapd just start and quits without a message, leaving an empty directory.
I suspect I did not had the idea to check the logs because I was just expecting it to do the conversion in the foreground and exit. Obviously a wrong expectation.
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
And it's a sad that project leaders immediatly assume users are just unwilling to read the docs, rather than wondering if the docs need improvement.
We know they do, and we are. There's no wondering involved ;-)
This bears some repeating. We are continuously investing time and energy into updating the docs. But if you don't provide feedback like "this part helped" or "this part is unclear" then we can only assume you're not reading any of it. If you don't tell us the commands you used, and you don't tell us what diagnostic output was produced, we can only assume that you don't know how to ask for help, and that you don't know how to use the software, and that you've ignored all of the documentation that tells you how to do all these things.
Just saying "this didn't work for me" doesn't tell anybody anything useful.
When you communicate effectively with us, you'll get better information back.
People...
I have a idea about OpenLDAP documentation. There´s a good documentation at OpenLDAP website. Why not create more efforts to create a Howto series? I´m writing constantlty a howto week´s about basic OpenLDAP features, like some integrations and hints. We can create something like a wiki, using the OpenLDAP documentation and "translate" this things to Howto´s.
Horward, we can help your efforts? Thanks for your good work.
Cheers.
On 9/20/07, Howard Chu hyc@symas.com wrote:
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the
trouble of
writing these docs that nobody actually reads.
And it's a sad that project leaders immediatly assume users are just unwilling to read the docs, rather than wondering if the docs need improvement.
We know they do, and we are. There's no wondering involved ;-)
This bears some repeating. We are continuously investing time and energy into updating the docs. But if you don't provide feedback like "this part helped" or "this part is unclear" then we can only assume you're not reading any of it. If you don't tell us the commands you used, and you don't tell us what diagnostic output was produced, we can only assume that you don't know how to ask for help, and that you don't know how to use the software, and that you've ignored all of the documentation that tells you how to do all these things.
Just saying "this didn't work for me" doesn't tell anybody anything useful.
When you communicate effectively with us, you'll get better information back. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Gabriel Stein wrote:
People...
I have a idea about OpenLDAP documentation. There´s a good documentation at OpenLDAP website. Why not create more efforts to create a Howto series? I´m writing constantlty a howto week´s about basic OpenLDAP features, like some integrations and hints. We can create something like a wiki, using the OpenLDAP documentation and "translate" this things to Howto´s.
Horward, we can help your efforts? Thanks for your good work.
Cheers.
Hi Gabriel.
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
Here are the issues with your appreciated suggestions:
1. The OpenLDAP project do not support 3rd Party software 2. We have to find the time to mentor and verify the howto/wiki contributors. 3. We have to find the time to fight the wiki spam 4. We have to find the time to keep the howtos updated 5. Resources, lack of resources, need more resources. 6. etc.....
*My* first and foremost priority is to finish the Admin Guide, keep it accurate and up to date.
I think, as we have done all along, we leave the 3rd party integration to the 3rd party projects (like the wiki mentioned above). What we don't want is a wiki where people come along and start posting How tos that we don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we have.
However, what is *vital* is that we provide a means to put the Admin Guide sections into working configuration examples (which some sections have/will have). This could mean real world deployment examples etc.
It's all very good having in depth guides, but sometimes it's better to get something running and come back to the main docs. The vessel in which we present these complete examples is irrelevant and can be decided at any point.
So, coming back to your wonderful offer of help. If you would like to look at the latest docs in our source repo and pick up a section/subsection that appeals to you, we can move towards a complete and detailed OpenLDAP 2.4 Admin Guide and then do the wiki/howto stuff.
Does that sound like a plan?
Thanks,
Gavin.
Hello I have a recommendation for the idap recommendation, specifically for a howto. I think a great howto would be one that expands on this: http://mattfleming.com/node/190 except going into much more detail outlining every step necessary for it to work. That is a good setup that will give ldap users a good feel for how ldap works as it'll walk users through a real world setup thus making it easy for people to pickup the essential skills necessary to get ldap up and running.
On Fri Sep 21 2007 at 00:00:08 CEST, Hex Star wrote:
howto. I think a great howto would be one that expands on this: http:// mattfleming.com/node/190 except going into much more detail outlining every step necessary for it to work.
Documents such as the one you mention are, apart from quite good-looking, rather useless to the world at whole; papers that start off with `apt-get ...', are useless as they supply information to only a small portion of users, and what is worse, information that quickly is outdated, or incorrect to start with. Furthermore, most people simply "write-and-forget", meaning they never come back to update their "howtos" for a next version of the respective software.
I tell people, "If you want howtos, buy Windows".
Gavin's suggestion to augment the Admin Guide with real-world configuration examples can only be applauded. Examples of ACL, grouping, etc. with descriptions would greatly enhance the value of the OpenLDAP documentation.
-JP
P.S.: where is the book ? ;-)
Jan-Piet Mens wrote:
On Fri Sep 21 2007 at 00:00:08 CEST, Hex Star wrote:
howto. I think a great howto would be one that expands on this: http:// mattfleming.com/node/190 except going into much more detail outlining every step necessary for it to work.
Documents such as the one you mention are, apart from quite good-looking, rather useless to the world at whole; papers that start off with `apt-get ...', are useless as they supply information to only a small portion of users, and what is worse, information that quickly is outdated, or incorrect to start with. Furthermore, most people simply "write-and-forget", meaning they never come back to update their "howtos" for a next version of the respective software.
I tell people, "If you want howtos, buy Windows".
++ To all of above.
Gavin's suggestion to augment the Admin Guide with real-world configuration examples can only be applauded. Examples of ACL, grouping, etc. with descriptions would greatly enhance the value of the OpenLDAP documentation.
I think our Appendices will be the biggest part ;-)
Gavin.
Jan-Piet Mens skrev, on 21-09-2007 08:19:
howto. I think a great howto would be one that expands on this: http:// mattfleming.com/node/190 except going into much more detail outlining every step necessary for it to work.
Documents such as the one you mention are, apart from quite good-looking, rather useless to the world at whole; papers that start off with `apt-get ...', are useless as they supply information to only a small portion of users, and what is worse, information that quickly is outdated, or incorrect to start with. Furthermore, most people simply "write-and-forget", meaning they never come back to update their "howtos" for a next version of the respective software.
I tell people, "If you want howtos, buy Windows".
Generally, all "HOWTO"s are to be despised and regarded as dog food (but there's quite tasty dog food out there).
I used to write my few own guides, but always stressed that these were not HOWTOs, simply "what works for me". I stressed that I hated the word "HOWTO".
Gavin's suggestion to augment the Admin Guide with real-world configuration examples can only be applauded. Examples of ACL, grouping, etc. with descriptions would greatly enhance the value of the OpenLDAP documentation.
I still have to get around to "what works for me" for writing up for Gavin delta-syncrepl chaining and ppolicy (for our site, the latter greatest thing since sliced gnats ;) )
Best,
--Tonni
Thanks Gavin for your answer. I appreciate this.
Yes, sounds like a good plan. The Admin Guide is a excelent start to the wiki. On next months, if a have a good howto´s to the wiki, where I can install wiki and leave the howto´s? There´s a possibility to have private wiki with contributors at openldap.org? Something like http://wiki.openldap.org?
I´m in the end of howto about schema anatomy.
And finally, how I can help you Gavin with Admin Guide?
Cheers.
On 9/20/07, Gavin Henry ghenry@openldap.org wrote:
Gabriel Stein wrote:
People...
I have a idea about OpenLDAP documentation. There´s a good documentation at OpenLDAP website. Why not create more efforts to create a Howto series? I´m writing constantlty a howto week´s about basic OpenLDAP features, like some integrations and hints. We can create something like a wiki, using the OpenLDAP documentation and "translate" this things to Howto´s.
Horward, we can help your efforts? Thanks for your good work.
Cheers.
Hi Gabriel.
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
Here are the issues with your appreciated suggestions:
- The OpenLDAP project do not support 3rd Party software
- We have to find the time to mentor and verify the howto/wiki
contributors. 3. We have to find the time to fight the wiki spam 4. We have to find the time to keep the howtos updated 5. Resources, lack of resources, need more resources. 6. etc.....
*My* first and foremost priority is to finish the Admin Guide, keep it accurate and up to date.
I think, as we have done all along, we leave the 3rd party integration to the 3rd party projects (like the wiki mentioned above). What we don't want is a wiki where people come along and start posting How tos that we don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we have.
However, what is *vital* is that we provide a means to put the Admin Guide sections into working configuration examples (which some sections have/will have). This could mean real world deployment examples etc.
It's all very good having in depth guides, but sometimes it's better to get something running and come back to the main docs. The vessel in which we present these complete examples is irrelevant and can be decided at any point.
So, coming back to your wonderful offer of help. If you would like to look at the latest docs in our source repo and pick up a section/subsection that appeals to you, we can move towards a complete and detailed OpenLDAP 2.4 Admin Guide and then do the wiki/howto stuff.
Does that sound like a plan?
Thanks,
Gavin.
-- Kind Regards,
Gavin Henry. OpenLDAP Engineering Team.
E ghenry@OpenLDAP.org
Community developed LDAP software.
Gabriel Stein wrote:
Thanks Gavin for your answer. I appreciate this.
Not at all.
Yes, sounds like a good plan. The Admin Guide is a excelent start to the wiki. On next months, if a have a good howto´s to the wiki, where I can install wiki and leave the howto´s? There´s a possibility to have private wiki with contributors at openldap.org http://openldap.org? Something like http://wiki.openldap.org?
Like I said, none of the wiki (if ever, as we use our FAQ-O-MATIC (http://www.openldap.org/faq/) will be created until the Admin Guide is finished. So if you have something, please feel free to add it to the FAQ section or our site.
I´m in the end of howto about schema anatomy.
Nice.
And finally, how I can help you Gavin with Admin Guide?
After checkign out CVS HEAD, pick a section you're interested in and submit patches via our ITS. That would be great!
Gavin.
On Thursday 20 September 2007 23:45:53 Gavin Henry wrote:
Gabriel Stein wrote:
People...
I have a idea about OpenLDAP documentation. There´s a good documentation at OpenLDAP website. Why not create more efforts to create a Howto series? I´m writing constantlty a howto week´s about basic OpenLDAP features, like some integrations and hints. We can create something like a wiki, using the OpenLDAP documentation and "translate" this things to Howto´s.
Horward, we can help your efforts? Thanks for your good work.
Cheers.
Hi Gabriel.
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
But, then if we look at a page relevant to *this* project, you get something like: http://wiki.samba.org/index.php/Samba_%26_LDAP#Setting_up_PAM_and_NSS_to_use...
Which is incomplete, misleading, and wrong on all distributions but SUSE.
Or, you follow links on some of the other resources that have been posted in this thread, and you get something like this: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP... or this part: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
And, they missed the usual advice of editing migrate_common.ph (instead of the easier method of setting the LDAP_BASEDN environment variable), by only using the dc=example,dc=com example, thus ensuring all other users will be confused later: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
Here are the issues with your appreciated suggestions:
- The OpenLDAP project do not support 3rd Party software
While I don't have a problem with this, the question is why should this prevent OpenLDAP project documentation (with suitable disclaimers) from covering how to allow OpenLDAP to support other LDAP client software. For example, the only documentation available for configuring Solaris for using LDAP for user/group accounts assumes you use JES LDAP. Sun certainly isn't going to write any, and I would like to put the details somewhere before I forget them.
Is our only option something like http://scratchpad.wikia.com/wiki/Ldap
- We have to find the time to mentor and verify the howto/wiki
contributors.
Are you saying I need mentorship and verification?
- We have to find the time to fight the wiki spam
Not if you limit contributions to authenticated users. And there is the LDAP authentication plugin for mediawiki ...
- We have to find the time to keep the howtos updated
As the scratchpad wiki proves, I don't have *much* time ... but if a few people can spare a small amount of time, it may be viable.
- Resources, lack of resources, need more resources.
- etc.....
*My* first and foremost priority is to finish the Admin Guide, keep it accurate and up to date.
I think, as we have done all along, we leave the 3rd party integration to the 3rd party projects (like the wiki mentioned above).
Which obviously isn't doing such a great job. And, why should we leave it to Samba to document how to set up nss_ldap and OpenLDAP optimally? Or, is this an area nss_ldap should cover (including the indexes, ACLs etc. that should be configured on the server side)?
What we don't want is a wiki where people come along and start posting How tos that we don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we have.
It may be better than having hundreds of howtos out there in random places of much worse quality, leaving the impression that the OpenLDAP project prefers this to one authoritative place, where at least contributors or experts can correct mistakes (which we can't do for all the broken howtos).
However, what is *vital* is that we provide a means to put the Admin Guide sections into working configuration examples (which some sections have/will have). This could mean real world deployment examples etc.
But, if we can't cover nss_ldap, Solaris ldapclient, sudo, proftpd,bind, dhcpd, autofs, samba,apache-mod_vhost_ldap, freeradius, kmail, evolution, thunderbird (all of which I have used with OpenLDAP), what do we cover (that isn't covered in man pages)?
It's all very good having in depth guides, but sometimes it's better to get something running and come back to the main docs. The vessel in which we present these complete examples is irrelevant and can be decided at any point.
So, coming back to your wonderful offer of help. If you would like to look at the latest docs in our source repo and pick up a section/subsection that appeals to you, we can move towards a complete and detailed OpenLDAP 2.4 Admin Guide and then do the wiki/howto stuff.
Does that sound like a plan?
IMHO, it is more important to have concise, clear, documentation on getting the basics most people need to get started with (before they can justify spending more time to learn the ins and outs of all the features) with the most gain for the least effort, than documenting all the overlays, or the backends that are not used frequently.
For example, we have nothing to offer to compete with: http://directory.fedoraproject.org/ http://directory.fedoraproject.org/wiki/Howto:MigrateToLDAP http://directory.fedoraproject.org/wiki/Howto:OpenLDAPMigration http://directory.fedoraproject.org/wiki/Howto:Posix http://directory.fedoraproject.org/wiki/Howto:PAM http://directory.fedoraproject.org/wiki/Howto:Netgroups http://directory.fedoraproject.org/wiki/Howto:SolarisClient http://directory.fedoraproject.org/wiki/Howto:Automount http://directory.fedoraproject.org/wiki/Howto:Samba
So, from a "what can I do with this software before I decide which one" perspective, OpenLDAP will be at a disadvantage while we are prevented from mentioning anything besides OpenLDAP.
Regards, Buchan
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
But, then if we look at a page relevant to *this* project, you get something like: http://wiki.samba.org/index.php/Samba_%26_LDAP#Setting_up_PAM_and_NSS_to_use...
Which is incomplete, misleading, and wrong on all distributions but SUSE.
Or, you follow links on some of the other resources that have been posted in this thread, and you get something like this: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP... or this part: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
And, they missed the usual advice of editing migrate_common.ph (instead of the easier method of setting the LDAP_BASEDN environment variable), by only using the dc=example,dc=com example, thus ensuring all other users will be confused later: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
Appreciated comments, but these projects *never* come to us and ask us to review anything. Are we expected to spend all our time reviewing and editing others work?
Here are the issues with your appreciated suggestions:
- The OpenLDAP project do not support 3rd Party software
While I don't have a problem with this, the question is why should this prevent OpenLDAP project documentation (with suitable disclaimers) from covering how to allow OpenLDAP to support other LDAP client software.
But how many times do we need to cover it? No matter what client or software using a Directory, it's always the same; custom schema (give or take), relevant indexes and ACLs etc. Another client, another day.
For example, the only documentation available for configuring Solaris for using LDAP for user/group accounts assumes you use JES LDAP. Sun certainly isn't going to write any, and I would like to put the details somewhere before I forget them.
But isn't that the duty of the authors of said software that provide this functionality.
Is our only option something like http://scratchpad.wikia.com/wiki/Ldap
No, we have a perfectly good FAQ. You could add a new item in client integration.
- We have to find the time to mentor and verify the howto/wiki
contributors.
Are you saying I need mentorship and verification?
Yes, everyone does. Mentoring could mean instructing you how to author using the SDF tools, or wiki syntax etc. If someone thinks they never need help or clarification sometimes, then they must be very arrogant.
- We have to find the time to fight the wiki spam
Not if you limit contributions to authenticated users. And there is the LDAP authentication plugin for mediawiki ...
Yes, we could do invite only or get a new contributor to justify their addition. But again, we have a great FAQ system for this.
- We have to find the time to keep the howtos updated
As the scratchpad wiki proves, I don't have *much* time ... but if a few people can spare a small amount of time, it may be viable.
We all seem to think we don't have a system in place for this, namely the FAQ. I've only mentioned a wiki, as people are talking about it. We've had the FAQ for years and years now, but people are still shy.
- Resources, lack of resources, need more resources.
- etc.....
*My* first and foremost priority is to finish the Admin Guide, keep it accurate and up to date.
I think, as we have done all along, we leave the 3rd party integration to the 3rd party projects (like the wiki mentioned above).
Which obviously isn't doing such a great job. And, why should we leave it to Samba to document how to set up nss_ldap and OpenLDAP optimally? Or, is this an area nss_ldap should cover (including the indexes, ACLs etc. that should be configured on the server side)?
I'm confused here. We should step back and think about the community. Does the normal Open Source community author a piece of software, then document every possible integration scenario? Should the Linux Kernel team provide me with a guide how to install my graphics card that sits on top of it? No, they provide docs for the author of the card drivers, who then give me the install guide. Just like Samba, because LDAP is an integral part of it.
What we don't want is a wiki where people come along and start posting How tos that we don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we have.
It may be better than having hundreds of howtos out there in random places of much worse quality, leaving the impression that the OpenLDAP project prefers this to one authoritative place, where at least contributors or experts can correct mistakes (which we can't do for all the broken howtos).
Possibly.
However, what is *vital* is that we provide a means to put the Admin Guide sections into working configuration examples (which some sections have/will have). This could mean real world deployment examples etc.
But, if we can't cover nss_ldap, Solaris ldapclient, sudo, proftpd,bind, dhcpd, autofs, samba,apache-mod_vhost_ldap, freeradius, kmail, evolution, thunderbird (all of which I have used with OpenLDAP), what do we cover (that isn't covered in man pages)?
Sigh...Administration of OpenLDAP perhaps?
It's all very good having in depth guides, but sometimes it's better to get something running and come back to the main docs. The vessel in which we present these complete examples is irrelevant and can be decided at any point.
So, coming back to your wonderful offer of help. If you would like to look at the latest docs in our source repo and pick up a section/subsection that appeals to you, we can move towards a complete and detailed OpenLDAP 2.4 Admin Guide and then do the wiki/howto stuff.
Does that sound like a plan?
IMHO, it is more important to have concise, clear, documentation on getting the basics most people need to get started with (before they can justify spending more time to learn the ins and outs of all the features) with the most gain for the least effort, than documenting all the overlays, or the backends that are not used frequently.
Which the quick start does. We aren't an LDAP training centre.
For example, we have nothing to offer to compete with: http://directory.fedoraproject.org/ http://directory.fedoraproject.org/wiki/Howto:MigrateToLDAP http://directory.fedoraproject.org/wiki/Howto:OpenLDAPMigration http://directory.fedoraproject.org/wiki/Howto:Posix http://directory.fedoraproject.org/wiki/Howto:PAM http://directory.fedoraproject.org/wiki/Howto:Netgroups http://directory.fedoraproject.org/wiki/Howto:SolarisClient http://directory.fedoraproject.org/wiki/Howto:Automount http://directory.fedoraproject.org/wiki/Howto:Samba
So, from a "what can I do with this software before I decide which one" perspective, OpenLDAP will be at a disadvantage while we are prevented from mentioning anything besides OpenLDAP.
I leave the last part above for others to discuss.
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
But, then if we look at a page relevant to *this* project, you get something like: http://wiki.samba.org/index.php/Samba_%26_LDAP#Setting_up_PAM_and_NSS_to_use... Which is incomplete, misleading, and wrong on all distributions but SUSE. Or, you follow links on some of the other resources that have been posted in this thread, and you get something like this: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP... or this part: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP... And, they missed the usual advice of editing migrate_common.ph (instead of the easier method of setting the LDAP_BASEDN environment variable), by only using the dc=example,dc=com example, thus ensuring all other users will be confused later: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
The date on the aforementioned page is also "2005-10-25", so it is pretty darn old. I've got no problem with people publishing anything they want, but it is also reasonable to expect people [users, certainly administrators] to pay attention to things like published date. I have an owner's manual for my 1919 Model-T Ford, but I don't expect it to be helpful in fixing my 2007 Ford Mustang. If a reader ignores the fact that a document is stale it is no ones fault but the readers, and if they complain about it they should be dope slapped.
Appreciated comments, but these projects *never* come to us and ask us to review anything. Are we expected to spend all our time reviewing and editing others work?
Nope.
Here are the issues with your appreciated suggestions:
- The OpenLDAP project do not support 3rd Party software
While I don't have a problem with this, the question is why should this prevent OpenLDAP project documentation (with suitable disclaimers) from covering how to allow OpenLDAP to support other LDAP client software.
But how many times do we need to cover it? No matter what client or software using a Directory, it's always the same; custom schema (give or take), relevant indexes and ACLs etc. Another client, another day.
Exactly. If you understand LDAP *AND* the service you are configuring (Samba, NSS, PAM, RADIUS, etc...) then *MOST* stuff is pretty obvious and even drearily redundant after awhile. What I see is that allot of people want to skip one or both sides of the equation - if they want to do that they should hire a consultant.
For example, the only documentation available for configuring Solaris for using LDAP for user/group accounts assumes you use JES LDAP. Sun certainly isn't going to write any, and I would like to put the details somewhere before I forget them.
But isn't that the duty of the authors of said software that provide this functionality.
Yes.
- We have to find the time to fight the wiki spam
Not if you limit contributions to authenticated users. And there is the LDAP authentication plugin for mediawiki ...
Yes, we could do invite only or get a new contributor to justify their addition. But again, we have a great FAQ system for this.
Ditto, there is a FAQ.
- We have to find the time to keep the howtos updated
As the scratchpad wiki proves, I don't have *much* time ... but if a few people can spare a small amount of time, it may be viable.
We all seem to think we don't have a system in place for this, namely the FAQ. I've only mentioned a wiki, as people are talking about it. We've had the FAQ for years and years now, but people are still shy.
Maybe if we just rename the FAQ and call it a Wiki then people will be happy? :)
- Resources, lack of resources, need more resources.
- etc.....
*My* first and foremost priority is to finish the Admin Guide, keep it accurate and up to date. I think, as we have done all along, we leave the 3rd party integration to the 3rd party projects (like the wiki mentioned above).
Which obviously isn't doing such a great job.
It has worked for me any many others. I've migrated almost all our services to use OpenLDAP.
Or, is this an area nss_ldap should cover (including the indexes, ACLs etc. that should be configured on the server side)?
Yes, it is.
What we don't want is a wiki where people come along and start posting How tos that we don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we have.
It may be better than having hundreds of howtos out there in random places of much worse quality, leaving the impression that the OpenLDAP project prefers this to one authoritative place, where at least contributors or experts can correct mistakes (which we can't do for all the broken howtos).
What i don't understand is that (a) there is an official place for Samba documentation (b) there is an official place for PAM documentation (c) there is an official place for NSS documentation (d) there is an official place for ISC Bind documentation (e) there is an official place for ISC DHCPd documentation (f) there is an official place for Cyrus IMAPd documentation........... so what is the problem? Either (1) the user chose not to look in the official place or (2) the project chose not to provide documentation related to LDAP. #1 is the user's problem and for #2 the user should contact that project, not complain to their DSA "vendor".
If the user chose to look in "random places" they must expect documentation of "random" quality.
It's all very good having in depth guides, but sometimes it's better to get something running and come back to the main docs.
Disagree; that is just a sloppy approach to system administration.
People,
I´m really sorry about this discussion. Well, we have a lot of answers about wiki and 3rd party. I'm agree with OpenLDAP Team about "keep the focus" on your documentation. Why? Because we have a lot of people when start some project say "Ok, I participate, I do something", but times after you see some guy with all things of project, and people who said that things gonna away.
I´m really apreciatte the answers of OpenLDAP Team, and my focus now is contribute to Admin Guide with Gavin. But, I have some comments about this question: why not put links about ISC DHCP Integration, Samba Integration... etc.? Just put something on final of FAQ and Admin Guide, like "If you need integrate OpenLDAP with this services, just follow this links".
Focus... a better way to organize things and organize all efforts to do something.
Cheers.
On 9/21/07, Adam Tauno Williams adamtaunowilliams@gmail.com wrote:
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS
projects.
But, then if we look at a page relevant to *this* project, you get
something
like:
http://wiki.samba.org/index.php/Samba_%26_LDAP#Setting_up_PAM_and_NSS_to_use...
Which is incomplete, misleading, and wrong on all distributions but
SUSE.
Or, you follow links on some of the other resources that have been
posted in
this thread, and you get something like this:
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
or this part:
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
And, they missed the usual advice of editing migrate_common.ph
(instead of the
easier method of setting the LDAP_BASEDN environment variable), by
only using
the dc=example,dc=com example, thus ensuring all other users will be
confused
later:
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
The date on the aforementioned page is also "2005-10-25", so it is pretty darn old. I've got no problem with people publishing anything they want, but it is also reasonable to expect people [users, certainly administrators] to pay attention to things like published date. I have an owner's manual for my 1919 Model-T Ford, but I don't expect it to be helpful in fixing my 2007 Ford Mustang. If a reader ignores the fact that a document is stale it is no ones fault but the readers, and if they complain about it they should be dope slapped.
Appreciated comments, but these projects *never* come to us and ask us to review anything. Are we expected to spend all our time reviewing and editing others work?
Nope.
Here are the issues with your appreciated suggestions:
- The OpenLDAP project do not support 3rd Party software
While I don't have a problem with this, the question is why should
this
prevent OpenLDAP project documentation (with suitable disclaimers)
from
covering how to allow OpenLDAP to support other LDAP client software.
But how many times do we need to cover it? No matter what client or software using a Directory, it's always the same; custom schema (give or take), relevant indexes and ACLs etc. Another client, another day.
Exactly. If you understand LDAP *AND* the service you are configuring (Samba, NSS, PAM, RADIUS, etc...) then *MOST* stuff is pretty obvious and even drearily redundant after awhile. What I see is that allot of people want to skip one or both sides of the equation - if they want to do that they should hire a consultant.
For example, the only documentation available for configuring Solaris for
using
LDAP for user/group accounts assumes you use JES LDAP. Sun certainly
isn't
going to write any, and I would like to put the details somewhere
before I
forget them.
But isn't that the duty of the authors of said software that provide this functionality.
Yes.
- We have to find the time to fight the wiki spam
Not if you limit contributions to authenticated users. And there is
the LDAP
authentication plugin for mediawiki ...
Yes, we could do invite only or get a new contributor to justify their addition. But again, we have a great FAQ system for this.
Ditto, there is a FAQ.
- We have to find the time to keep the howtos updated
As the scratchpad wiki proves, I don't have *much* time ... but if a
few
people can spare a small amount of time, it may be viable.
We all seem to think we don't have a system in place for this, namely the FAQ. I've only mentioned a wiki, as people are talking about it. We've had the FAQ for years and years now, but people are still shy.
Maybe if we just rename the FAQ and call it a Wiki then people will be happy? :)
- Resources, lack of resources, need more resources.
- etc.....
*My* first and foremost priority is to finish the Admin Guide, keep
it
accurate and up to date. I think, as we have done all along, we leave the 3rd party
integration
to the 3rd party projects (like the wiki mentioned above).
Which obviously isn't doing such a great job.
It has worked for me any many others. I've migrated almost all our services to use OpenLDAP.
Or, is this an area nss_ldap should cover (including the indexes, ACLs etc. that
should
be configured on the server side)?
Yes, it is.
What we don't want is a wiki where people come along and start posting How tos that
we
don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we
have.
It may be better than having hundreds of howtos out there in random
places of
much worse quality, leaving the impression that the OpenLDAP project
prefers
this to one authoritative place, where at least contributors or
experts can
correct mistakes (which we can't do for all the broken howtos).
What i don't understand is that (a) there is an official place for Samba documentation (b) there is an official place for PAM documentation (c) there is an official place for NSS documentation (d) there is an official place for ISC Bind documentation (e) there is an official place for ISC DHCPd documentation (f) there is an official place for Cyrus IMAPd documentation........... so what is the problem? Either (1) the user chose not to look in the official place or (2) the project chose not to provide documentation related to LDAP. #1 is the user's problem and for #2 the user should contact that project, not complain to their DSA "vendor".
If the user chose to look in "random places" they must expect documentation of "random" quality.
It's all very good having in depth guides, but sometimes it's better
to
get something running and come back to the main docs.
Disagree; that is just a sloppy approach to system administration.
-- Adam Tauno Williams, Network & Systems Administrator Consultant - http://www.whitemiceconsulting.com Developer - http://www.opengroupware.org
--On Friday, September 21, 2007 1:27 PM -0300 Gabriel Stein gabrielstein@gmail.com wrote:
I´m really apreciatte the answers of OpenLDAP Team, and my focus now is contribute to Admin Guide with Gavin. But, I have some comments about this question: why not put links about ISC DHCP Integration, Samba Integration... etc.? Just put something on final of FAQ and Admin Guide, like "If you need integrate OpenLDAP with this services, just follow this links".
As long as they were only toplevel links, i.e. http://www.samba.org/
Since deeper links can (and often do) change.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Friday, September 21, 2007 1:27 PM -0300 Gabriel Stein gabrielstein@gmail.com wrote:
I´m really apreciatte the answers of OpenLDAP Team, and my focus now is contribute to Admin Guide with Gavin. But, I have some comments about this question: why not put links about ISC DHCP Integration, Samba Integration... etc.? Just put something on final of FAQ and Admin Guide, like "If you need integrate OpenLDAP with this services, just follow this links".
Nobody is preventing you from adding pages of links to the FAQ. Don't just talk about it, do it.
As long as they were only toplevel links, i.e. http://www.samba.org/
Since deeper links can (and often do) change.
Ah, if only HTTP had referential integrity. Obviously off-topic, but someone should write a standard spec for publishing website changelogs via RSS or somesuch. Announcing new material isn't so important, people already browse for that purpose. But a standard format for announcing changes/renames/moves of existing content would really help.
Gabriel Stein wrote:
People,
I´m really sorry about this discussion. Well, we have a lot of answers about wiki and 3rd party. I'm agree with OpenLDAP Team about "keep the focus" on your documentation. Why? Because we have a lot of people when start some project say "Ok, I participate, I do something", but times after you see some guy with all things of project, and people who said that things gonna away.
I´m really apreciatte the answers of OpenLDAP Team, and my focus now is contribute to Admin Guide with Gavin. But, I have some comments about this question: why not put links about ISC DHCP Integration, Samba Integration... etc.? Just put something on final of FAQ and Admin Guide, like "If you need integrate OpenLDAP with this services, just follow this links".
We do link to the FAQ in the guide, so it's best to create a new or find an existing FAQ section and link to that.
Focus... a better way to organize things and organize all efforts to do something.
I'm going to carry on focusing on what I'm focusing on, trying not to lose focus and focus on something that I can put my efforts into ;-)
Adam Tauno Williams wrote:
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
But, then if we look at a page relevant to *this* project, you get something like: http://wiki.samba.org/index.php/Samba_%26_LDAP#Setting_up_PAM_and_NSS_to_use... Which is incomplete, misleading, and wrong on all distributions but SUSE. Or, you follow links on some of the other resources that have been posted in this thread, and you get something like this: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP... or this part: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP... And, they missed the usual advice of editing migrate_common.ph (instead of the easier method of setting the LDAP_BASEDN environment variable), by only using the dc=example,dc=com example, thus ensuring all other users will be confused later: http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP...
The date on the aforementioned page is also "2005-10-25", so it is pretty darn old. I've got no problem with people publishing anything they want, but it is also reasonable to expect people [users, certainly administrators] to pay attention to things like published date. I have an owner's manual for my 1919 Model-T Ford, but I don't expect it to be helpful in fixing my 2007 Ford Mustang. If a reader ignores the fact that a document is stale it is no ones fault but the readers, and if they complain about it they should be dope slapped.
Appreciated comments, but these projects *never* come to us and ask us to review anything. Are we expected to spend all our time reviewing and editing others work?
Nope.
Here are the issues with your appreciated suggestions:
- The OpenLDAP project do not support 3rd Party software
While I don't have a problem with this, the question is why should this prevent OpenLDAP project documentation (with suitable disclaimers) from covering how to allow OpenLDAP to support other LDAP client software.
But how many times do we need to cover it? No matter what client or software using a Directory, it's always the same; custom schema (give or take), relevant indexes and ACLs etc. Another client, another day.
Exactly. If you understand LDAP *AND* the service you are configuring (Samba, NSS, PAM, RADIUS, etc...) then *MOST* stuff is pretty obvious and even drearily redundant after awhile. What I see is that allot of people want to skip one or both sides of the equation - if they want to do that they should hire a consultant.
For example, the only documentation available for configuring Solaris for using LDAP for user/group accounts assumes you use JES LDAP. Sun certainly isn't going to write any, and I would like to put the details somewhere before I forget them.
But isn't that the duty of the authors of said software that provide this functionality.
Yes.
- We have to find the time to fight the wiki spam
Not if you limit contributions to authenticated users. And there is the LDAP authentication plugin for mediawiki ...
Yes, we could do invite only or get a new contributor to justify their addition. But again, we have a great FAQ system for this.
Ditto, there is a FAQ.
- We have to find the time to keep the howtos updated
As the scratchpad wiki proves, I don't have *much* time ... but if a few people can spare a small amount of time, it may be viable.
We all seem to think we don't have a system in place for this, namely the FAQ. I've only mentioned a wiki, as people are talking about it. We've had the FAQ for years and years now, but people are still shy.
Maybe if we just rename the FAQ and call it a Wiki then people will be happy? :)
- Resources, lack of resources, need more resources.
- etc.....
*My* first and foremost priority is to finish the Admin Guide, keep it accurate and up to date. I think, as we have done all along, we leave the 3rd party integration to the 3rd party projects (like the wiki mentioned above).
Which obviously isn't doing such a great job.
It has worked for me any many others. I've migrated almost all our services to use OpenLDAP.
Or, is this an area nss_ldap should cover (including the indexes, ACLs etc. that should be configured on the server side)?
Yes, it is.
What we don't want is a wiki where people come along and start posting How tos that we don't have time to vet, which in turn starts to dilute the OpenLDAP quality brand and take our time away with the little resources we have.
It may be better than having hundreds of howtos out there in random places of much worse quality, leaving the impression that the OpenLDAP project prefers this to one authoritative place, where at least contributors or experts can correct mistakes (which we can't do for all the broken howtos).
What i don't understand is that (a) there is an official place for Samba documentation (b) there is an official place for PAM documentation (c) there is an official place for NSS documentation (d) there is an official place for ISC Bind documentation (e) there is an official place for ISC DHCPd documentation (f) there is an official place for Cyrus IMAPd documentation........... so what is the problem? Either (1) the user chose not to look in the official place or (2) the project chose not to provide documentation related to LDAP. #1 is the user's problem and for #2 the user should contact that project, not complain to their DSA "vendor".
If the user chose to look in "random places" they must expect documentation of "random" quality.
It's all very good having in depth guides, but sometimes it's better to get something running and come back to the main docs.
Disagree; that is just a sloppy approach to system administration.
Disagree; My reasoning was an admin that needed to demonstrate proof of concept, then come back and get to the finer details.
Buchan Milne wrote:
So, from a "what can I do with this software before I decide which one" perspective, OpenLDAP will be at a disadvantage while we are prevented from mentioning anything besides OpenLDAP.
Nobody is preventing you from contributing docs about integrating with other systems to the FAQ-o-Matic. It would probably have taken you less time to write a useful page there than it took to compose that email.
On Friday 21 September 2007 10:32:04 Howard Chu wrote:
Buchan Milne wrote:
So, from a "what can I do with this software before I decide which one" perspective, OpenLDAP will be at a disadvantage while we are prevented from mentioning anything besides OpenLDAP.
Nobody is preventing you from contributing docs about integrating with other systems to the FAQ-o-Matic. It would probably have taken you less time to write a useful page there than it took to compose that email.
Actually, no, it took more time to find *one* place I could add something useful. I'll try and update some of the very sparse pages, some of the vastly out-of-date pages as and when I can.
Gavin Henry wrote:
Gabriel Stein wrote:
We can create something like a wiki, using the OpenLDAP documentation and "translate" this things to Howto´s.
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
Here are the issues with your appreciated suggestions:
I'm also tired of this yet-another-wiki-will-improve-documentation approach. Why? Because Wikis have to be filled with content by skilled people who have some spare time left. If they are able and willing to do the work (like fortunately Gavin does) they sure are able to give input without the need for a particular media. There are so many Wikis out there without any real content...
BTW: "Customers" want to have "official" looking docs => IMO the Admin Guide is the most suitable media to work with.
Ciao, Michael.
Michael Ströder wrote:
Gavin Henry wrote:
Gabriel Stein wrote:
We can create something like a wiki, using the OpenLDAP documentation and "translate" this things to Howto´s.
I've often thought about this, as Samba do similar at: http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
Here are the issues with your appreciated suggestions:
I'm also tired of this yet-another-wiki-will-improve-documentation approach. Why? Because Wikis have to be filled with content by skilled people who have some spare time left. If they are able and willing to do the work (like fortunately Gavin does) they sure are able to give input without the need for a particular media. There are so many Wikis out there without any real content...
I agree. And to provide different media formats for export is hard. We would also need a website, database, upgrades, maintenance etc. etc.
BTW: "Customers" want to have "official" looking docs => IMO the Admin Guide is the most suitable media to work with.
Again, agreed. From SDF we can provide multi-html, single-html and PDF.
Ciao, Michael.
Howard Chu wrote:
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Note that this feature was already documented in the existing slapd/slapadd/slap* manpages in 2.3. It's a shame that we go to the trouble of writing these docs that nobody actually reads.
And it's a sad that project leaders immediatly assume users are just unwilling to read the docs, rather than wondering if the docs need improvement.
We know they do, and we are. There's no wondering involved ;-)
This bears some repeating. We are continuously investing time and energy into updating the docs. But if you don't provide feedback like "this part helped" or "this part is unclear" then we can only assume you're not reading any of it. If you don't tell us the commands you used, and you don't tell us what diagnostic output was produced, we can only assume that you don't know how to ask for help, and that you don't know how to use the software, and that you've ignored all of the documentation that tells you how to do all these things.
Just saying "this didn't work for me" doesn't tell anybody anything useful.
When you communicate effectively with us, you'll get better information back.
I'd love to also see, "It would be really helpful if x, y and x was covered".
Much like our test suite, complete coverage is the aim.
Gavin Henry ghenry@OpenLDAP.org writes:
I'd love to also see, "It would be really helpful if x, y and x was covered".
Ask and you shall receive. It would be really helpful if the slapd.access man page said something more useful than:
The statement set=<pattern> is undocumented yet.
Russ Allbery wrote:
Gavin Henry ghenry@OpenLDAP.org writes:
I'd love to also see, "It would be really helpful if x, y and x was covered".
Ask and you shall receive. It would be really helpful if the slapd.access man page said something more useful than:
The statement set=<pattern> is undocumented yet.
Anything but that. ;)
Sets are still experimental. The only existing doc is in the FAQ. http://www.openldap.org/faq/index.cgi?file=1133
The syntax was recently (just a couple days ago) extended as noted in that FAQ article.
They will likely continue to be experimental for some time yet.
In this particular case, it would help to get out of the experimental phase if someone would write a spec of what sets *should* be able to do. I.e., we've talked about "it would be cool if sets could be combined with regexes" but no one has ever taken the time to define what that would mean.
So, for those of you using sets - why are they useful to you, and in what ways are they still too limited? I personally am concerned that they are too expensive to evaluate; if we could provide similar features using a less general model that would be worth exploring too.
Howard Chu hyc@symas.com writes:
So, for those of you using sets - why are they useful to you, and in what ways are they still too limited? I personally am concerned that they are too expensive to evaluate; if we could provide similar features using a less general model that would be worth exploring too.
I inherited this setup, so I don't know how useful it is or if there are better ways of expressing the same thing, but we use it for:
access to dn.children="cn=people,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read
access to dn.children="cn=nis,dc=stanford,dc=edu" by set.exact="this/host & user" sasl_ssf=56 read
access to dn.children="cn=accounts,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read by * break
--On Thursday, September 20, 2007 6:37 PM -0700 Russ Allbery rra@stanford.edu wrote:
Howard Chu hyc@symas.com writes:
So, for those of you using sets - why are they useful to you, and in what ways are they still too limited? I personally am concerned that they are too expensive to evaluate; if we could provide similar features using a less general model that would be worth exploring too.
I inherited this setup, so I don't know how useful it is or if there are better ways of expressing the same thing, but we use it for:
access to dn.children="cn=people,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read
This allows users who bind to the server to read their person entry when their binding user id matches the user id in the people tree.
access to dn.children="cn=nis,dc=stanford,dc=edu" by set.exact="this/host & user" sasl_ssf=56 read
This was an experimental ACL for doing host based restrictions of user logins. It currently will never be used since this was never deployed. Still a cool idea though, I think. ;)
access to dn.children="cn=accounts,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read by * break
This allows users who bind to the server to read their account entry when their binding user id matches the user id in the entry in the account tree.
Basically, the first and third acls allow Stanford users to have full read on their own data, but keeps the restrictions in place on all other peoples data in both trees.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, September 20, 2007 6:37 PM -0700 Russ Allbery rra@stanford.edu wrote:
Howard Chu hyc@symas.com writes:
So, for those of you using sets - why are they useful to you, and in what ways are they still too limited? I personally am concerned that they are too expensive to evaluate; if we could provide similar features using a less general model that would be worth exploring too.
I inherited this setup, so I don't know how useful it is or if there are better ways of expressing the same thing, but we use it for:
access to dn.children="cn=people,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read
This allows users who bind to the server to read their person entry when their binding user id matches the user id in the people tree.
I guess that makes sense. What is an example "user" in this case, does that reside under the people tree, or the accounts tree?
access to dn.children="cn=nis,dc=stanford,dc=edu" by set.exact="this/host & user" sasl_ssf=56 read
This was an experimental ACL for doing host based restrictions of user logins. It currently will never be used since this was never deployed. Still a cool idea though, I think. ;)
That would require your "host" attribute to use DN syntax. So presumably the user in this case is an nss_ldap proxy account...?
access to dn.children="cn=accounts,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read by * break
This allows users who bind to the server to read their account entry when their binding user id matches the user id in the entry in the account tree.
Don't users just bind using account entries anyway? Isn't this the same as "by self read" ? Or you're saying that there can be multiple accounts with the same uid?
Basically, the first and third acls allow Stanford users to have full read on their own data, but keeps the restrictions in place on all other peoples data in both trees.
Howard Chu hyc@symas.com writes:
Quanah Gibson-Mount wrote:
This allows users who bind to the server to read their person entry when their binding user id matches the user id in the people tree.
I guess that makes sense. What is an example "user" in this case, does that reside under the people tree, or the accounts tree?
Accounts (in the sense that that's where krb5principalname is, which I think is what you mean).
This was an experimental ACL for doing host based restrictions of user logins. It currently will never be used since this was never deployed. Still a cool idea though, I think. ;)
That would require your "host" attribute to use DN syntax. So presumably the user in this case is an nss_ldap proxy account...?
Yeah, we were planning on setting host attributes to DN syntax, although we never finished really specifying how that was all going to work.
Don't users just bind using account entries anyway? Isn't this the same as "by self read" ? Or you're saying that there can be multiple accounts with the same uid?
There aren't, so I think you're right.
--On Thursday, September 20, 2007 8:43 PM -0700 Russ Allbery rra@stanford.edu wrote:
Don't users just bind using account entries anyway? Isn't this the same as "by self read" ? Or you're saying that there can be multiple accounts with the same uid?
There aren't, so I think you're right.
Correct, but which tree the person binds to has changed before, so I put it that way purposely in case the definition changed yet again.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
And it's a sad that project leaders immediatly assume users are just unwilling to read the docs, rather than wondering if the docs need improvement.
I just discovered why my slapd -f slapd.conf -F slapd.d attempt failed: permissions on the slapd.d directory were wrong, so slapd just start and quits without a message, leaving an empty directory.
This is a concrete case of improvement: "slapd should not be silent on EACCES (or others)." I'd imagine that such a proposal would be met favorably in the ITS. Vague, overreaching statements about the perceived incomprehensibility of OpenLDAP documentation are what deserve questioning. There's a lot of doc work being done right now -- what would make it more usable?
Aaron Richton richton@nbcs.rutgers.edu wrote:
This is a concrete case of improvement: "slapd should not be silent on EACCES (or others)."
Well, it's not silent: it sends an error to the logs.
The oddity here is that there are two functionalities blent into the same program: the LDAP server and the slapd.conf to slapd.d converter. Moreover, it seems the latter cannot be used without launching the former.
The choice for that is obvious: the config parser is in slapd, so slapd is used for conversion. But it has drawbacks, since when one want to perform the conversion, slapd will usually be already running. So you have to use -h so that you don't fail because the address is already in use, you have to use -u to run as the usual slapd UID so that you don't fail on reading the certificates, and so on. I'm not sure how this could be quickly explained in slapd(8)
Emmanuel Dreyfus wrote:
Aaron Richton richton@nbcs.rutgers.edu wrote:
This is a concrete case of improvement: "slapd should not be silent on EACCES (or others)."
Well, it's not silent: it sends an error to the logs.
The oddity here is that there are two functionalities blent into the same program: the LDAP server and the slapd.conf to slapd.d converter. Moreover, it seems the latter cannot be used without launching the former.
Use slaptest instead.
The choice for that is obvious: the config parser is in slapd, so slapd is used for conversion. But it has drawbacks, since when one want to perform the conversion, slapd will usually be already running. So you have to use -h so that you don't fail because the address is already in use, you have to use -u to run as the usual slapd UID so that you don't fail on reading the certificates, and so on. I'm not sure how this could be quickly explained in slapd(8)
Howard Chu hyc@symas.com wrote:
Use slaptest instead.
Oh, right, I missed that one. Perhaps this is the missing piece in the docs? It's not obvious how to explain it, though. I'm not sure the sentence below is satisfying.
-F slapd-config-directory Specifies the slapd configuration directory. The default is /usr/pkg/share/examples/openldap/slapd.d. If both -f and -F are specified, the config file will be read and converted to config directory format and written to the specified directory before slapd starts regular operations. slaptest(8) can also be used to just perform the conversion.
Alternatively, perhaps it's the admin guide that should suggest running slaptest -f -F in order to build the cn=config tree from slapd.conf? It does not seem to contain the upgrade procedure at all.
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Use slaptest instead.
Oh, right, I missed that one. Perhaps this is the missing piece in the docs? It's not obvious how to explain it, though. I'm not sure the sentence below is satisfying.
-F slapd-config-directory Specifies the slapd configuration directory. The default is /usr/pkg/share/examples/openldap/slapd.d. If both -f and -F are specified, the config file will be read and converted to config directory format and written to the specified directory before slapd starts regular operations. slaptest(8) can also be used to just perform the conversion.
in slapd(8) in HEAD, the last sentence does say:
"All of the slap tools that use the config options observe this same behavior."
So that would imply slaptest. But maybe something clearer should be said?
If you'd like to file an ITS, that would be best to track this.
Alternatively, perhaps it's the admin guide that should suggest running slaptest -f -F in order to build the cn=config tree from slapd.conf? It does not seem to contain the upgrade procedure at all.
I've added a placeholder to the cn=config section in the Guide, for me to fill out later:
"Converting from slapd.conf(8) to a cn=config directory format"
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Use slaptest instead.
Oh, right, I missed that one. Perhaps this is the missing piece in the docs? It's not obvious how to explain it, though. I'm not sure the sentence below is satisfying.
-F slapd-config-directory Specifies the slapd configuration directory. The default is /usr/pkg/share/examples/openldap/slapd.d. If both -f and -F are specified, the config file will be read and converted to config directory format and written to the specified directory before slapd starts regular operations. slaptest(8) can also be used to just perform the conversion.in slapd(8) in HEAD, the last sentence does say:
"All of the slap tools that use the config options observe this same behavior."
Not just in HEAD. That text has been there since May/June 2005, 2.3 onward.
So that would imply slaptest. But maybe something clearer should be said?
If you'd like to file an ITS, that would be best to track this.
Alternatively, perhaps it's the admin guide that should suggest running slaptest -f -F in order to build the cn=config tree from slapd.conf? It does not seem to contain the upgrade procedure at all.
I've added a placeholder to the cn=config section in the Guide, for me to fill out later:
"Converting from slapd.conf(8) to a cn=config directory format"
Howard Chu wrote:
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Use slaptest instead.
Oh, right, I missed that one. Perhaps this is the missing piece in the docs? It's not obvious how to explain it, though. I'm not sure the sentence below is satisfying.
-F slapd-config-directory Specifies the slapd configuration directory. The default is /usr/pkg/share/examples/openldap/slapd.d. If both -f and -F are specified, the config file will be read and converted to config directory format and written to the specified directory before slapd starts regular operations. slaptest(8) can also be used to just perform the conversion.in slapd(8) in HEAD, the last sentence does say:
"All of the slap tools that use the config options observe this same behavior."
Not just in HEAD. That text has been there since May/June 2005, 2.3 onward.
OK. Well, there's no excuse for people missing it then. A bit of thought would lead them to slaptest. Or do we have to actually say slaptest.
Gavin, A key to good documentation is "don't assume anything". If you have to ask the question, then it is best to include it in the docos.
Howard Chu wrote: Gavin Henry wrote:
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Use slaptest instead.
Oh, right, I missed that one. Perhaps this is the missing piece in the docs? It's not obvious how to explain it, though. I'm not sure the sentence below is satisfying.
-F slapd-config-directory Specifies the slapd configuration directory. The default is /usr/pkg/share/examples/openldap/slapd.d. If both -f and -F are specified, the config file will be
read
and converted to config directory format and written to the specified directory before slapd starts regular operations. slaptest(8) can also be used to just perform the conversion.in slapd(8) in HEAD, the last sentence does say:
"All of the slap tools that use the config options observe this same behavior."
Not just in HEAD. That text has been there since May/June 2005, 2.3
onward.
OK. Well, there's no excuse for people missing it then. A bit of thought would lead them to slaptest. Or do we have to actually say slaptest.
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretecsystems.com
Open Source. Open Solutions(tm).
Regards,
David Damon Senior Systems Integration Analyst Office: (714) 442-7562 FAX: (714) 442-2845
David Damon wrote:
Gavin, A key to good documentation is "don't assume anything". If you have to ask the question, then it is best to include it in the docos.
Thanks for that, but we have to assume some background knowledge ;-) We're definitely not doing a "Dummies guide to OpenLDAP"
Gavin Henry ghenry@suretecsystems.com wrote:
Thanks for that, but we have to assume some background knowledge ;-)
Then the amount of
Emmanuel Dreyfus manu@netbsd.org wrote:
Thanks for that, but we have to assume some background knowledge ;-)
Then the amount of
Hem, that one was sent too early :-)
What is the amount of assumed knowledge? It would be fair to tell what are the requirement for reading the doc and where they can be acquired...
Emmanuel Dreyfus wrote:
Emmanuel Dreyfus manu@netbsd.org wrote:
Thanks for that, but we have to assume some background knowledge ;-)
Then the amount of
Hem, that one was sent too early :-)
What is the amount of assumed knowledge? It would be fair to tell what are the requirement for reading the doc and where they can be acquired...
From the Project's perspective, I think the basic requirements include: basic sysadmin skills on your target platform - you need to be proficient enough to operate as a superuser/Administrator without obliterating your machine. basic netadmin skills - if you have to deal with IP filters, firewalls, strange routing configurations, it's your obligation to be cognizant of those things. security requirements - if you're trying to implement security, you have to have a clear policy spec that tells you what you're trying to secure, from whom. basic LDAP/X.500 knowledge - you should already know what "DIT" and "DN" stand for, you should know what a schema looks like and what it does. You should know the syntax and semantics of a search filter, and what all of the standard LDAP Request types are. You should know how an LDAP URL is structured, etc. Essentially, at least enough familiarity with everything in the LDAP RFCs to recognize the terminology.
Since the Project releases source code only, you should have basic proficiency with software development tools and procedures - how to use the basic tools of the trade - configure, make, cc, etc. For people using a prebuilt distro, this is probably not a requirement.
Howard Chu skrev, on 21-09-2007 21:58:
What is the amount of assumed knowledge? It would be fair to tell what are the requirement for reading the doc and where they can be acquired...
From the Project's perspective, I think the basic requirements include: basic sysadmin skills on your target platform - you need to be proficient enough to operate as a superuser/Administrator without obliterating your machine.
Certainly without pretty comprehensive shell and a bit of Perl knowledge combined with OL tools such as ldapsearch and ldapmodify, coping with my 1150+ user site would be a nightmare. The basic ideas I stole from others in the beginning ...
basic netadmin skills - if you have to deal with IP filters,firewalls, strange routing configurations, it's your obligation to be cognizant of those things. security requirements - if you're trying to implement security, you have to have a clear policy spec that tells you what you're trying to secure, from whom. basic LDAP/X.500 knowledge - you should already know what "DIT" and "DN" stand for, you should know what a schema looks like and what it does. You should know the syntax and semantics of a search filter, and what all of the standard LDAP Request types are. You should know how an LDAP URL is structured, etc. Essentially, at least enough familiarity with everything in the LDAP RFCs to recognize the terminology.
Since the Project releases source code only, you should have basic proficiency with software development tools and procedures - how to use the basic tools of the trade - configure, make, cc, etc. For people using a prebuilt distro, this is probably not a requirement.
--Tonni
Ok People.
Just organize this question:
- Gavin finishing the Admin Guide; - I'm free to put links(3rd party) at FAQ and update it when have some change(its a good idea about RSS); - Gavin, you are accepting contributions to finish Admin Guide; - And finally... the main concept is RTFM and not make a Dummies Guide;
Anything wrong? These points are correct?
Sorry about this email, I´m just trying to organize this discussion to make more easy focus and our production.
On 9/21/07, Emmanuel Dreyfus manu@netbsd.org wrote:
Emmanuel Dreyfus manu@netbsd.org wrote:
Thanks for that, but we have to assume some background knowledge ;-)
Then the amount of
Hem, that one was sent too early :-)
What is the amount of assumed knowledge? It would be fair to tell what are the requirement for reading the doc and where they can be acquired...
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
<quote who="Gabriel Stein">
Ok People.
Just organize this question:
- Gavin finishing the Admin Guide;
Correct. As well as anyone via ITS and OpenLDAP team.
- I'm free to put links(3rd party) at FAQ and update it when have some
change(its a good idea about RSS);
OK, sounds good.
- Gavin, you are accepting contributions to finish Admin Guide;
Yes.
- And finally... the main concept is RTFM and not make a Dummies Guide;
Yes.
Anything wrong? These points are correct?
All ok,
Sorry about this email, I´m just trying to organize this discussion to make more easy focus and our production.
Not at all. Just a note regarding the admin guide. All the sections are there (except a couple of appendices I'm still going to add), so just the content needs to be completed/pulled in from FAQ etc.
On 9/21/07, Emmanuel Dreyfus manu@netbsd.org wrote:
Emmanuel Dreyfus manu@netbsd.org wrote:
Thanks for that, but we have to assume some background knowledge ;-)
Then the amount of
Hem, that one was sent too early :-)
What is the amount of assumed knowledge? It would be fair to tell what are the requirement for reading the doc and where they can be acquired...
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
-- /\ Gabriel Stein gabrielstein@gmail.com MSN: gabrielstein@hotmail.com Administrador de Redes - Network Administrador Linux User #223750 51-92796310 Porto Alegre - RS - Brasil
On Friday 21 September 2007 06:07:47 Howard Chu wrote:
Emmanuel Dreyfus wrote:
Aaron Richton richton@nbcs.rutgers.edu wrote:
This is a concrete case of improvement: "slapd should not be silent on EACCES (or others)."
Well, it's not silent: it sends an error to the logs.
Not if you run it in the foreground, e.g. -d config, or -d none.
The oddity here is that there are two functionalities blent into the same program: the LDAP server and the slapd.conf to slapd.d converter. Moreover, it seems the latter cannot be used without launching the former.
Use slaptest instead.
except that slaptest doesn't have a "run as another user" flag, and -u is already taken :-(.
At present, it seems that if you want to do the conversion while slapd is running, and for a slapd that runs as non-root, something like this is the best option:
# slapd -u ldap -g ldap -d none -h ldap://localhost:391/ -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
As then -The configuration will be converted -slapd won't start up -you will see any relevant errors -all the files will be owned by the ldap user/group -if it succeeds, a restart of slapd is all that is necessary to continue
Regards, Buchan
Buchan Milne wrote:
On Friday 21 September 2007 06:07:47 Howard Chu wrote:
Use slaptest instead.
except that slaptest doesn't have a "run as another user" flag, and -u is already taken :-(.
Nor do the tools need such an option; you can just use su. The reason slapd can't be started with just "su ldap" is because it may need root privs to open the listener sockets. That's the only reason it has -u/-g options.
At present, it seems that if you want to do the conversion while slapd is running, and for a slapd that runs as non-root, something like this is the best option:
# slapd -u ldap -g ldap -d none -h ldap://localhost:391/ -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
As then -The configuration will be converted -slapd won't start up
What makes you say that?
-you will see any relevant errors -all the files will be owned by the ldap user/group -if it succeeds, a restart of slapd is all that is necessary to continue
That seems like far more trouble than just using su...
On Friday 21 September 2007 09:52:03 Howard Chu wrote:
Buchan Milne wrote:
On Friday 21 September 2007 06:07:47 Howard Chu wrote:
Use slaptest instead.
except that slaptest doesn't have a "run as another user" flag, and -u is already taken :-(.
Nor do the tools need such an option; you can just use su. The reason slapd can't be started with just "su ldap" is because it may need root privs to open the listener sockets. That's the only reason it has -u/-g options.
Sure, and I use su in our init script when testing the configuration. But, some other distros don't, and don't use -u, and end up creating transaction log files as root, preventing startup later. I am not aware of any recommendation of using su for slaptest (though it is quite obvious to many, it may be worth mentioning explicitly). And, it should certainly be mentioned in any documentation covering converting to back-config.
At present, it seems that if you want to do the conversion while slapd is running, and for a slapd that runs as non-root, something like this is the best option:
# slapd -u ldap -g ldap -d none -h ldap://localhost:391/ -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
As then -The configuration will be converted -slapd won't start up
What makes you say that?
It will fail to open the database already opened by the running slapd.
-you will see any relevant errors -all the files will be owned by the ldap user/group -if it succeeds, a restart of slapd is all that is necessary to continue
That seems like far more trouble than just using su...
It's aobut the same amount of typing:
# su - ldap -s /bin/bash -c 'slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d'
So, maybe I'll use this ...
Regards, Buchan
Buchan Milne wrote:
On Friday 21 September 2007 09:52:03 Howard Chu wrote:
At present, it seems that if you want to do the conversion while slapd is running, and for a slapd that runs as non-root, something like this is the best option:
# slapd -u ldap -g ldap -d none -h ldap://localhost:391/ -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
As then -The configuration will be converted -slapd won't start up
What makes you say that?
It will fail to open the database already opened by the running slapd.
You're assuming a back-bdb/hdb database. Not everyone uses them. There are quite a large number of installations using just back-ldap/meta etc... The slaptest invocation will always work.
Howard Chu hyc@symas.com wrote:
You're assuming a back-bdb/hdb database. Not everyone uses them. There are quite a large number of installations using just back-ldap/meta etc... The slaptest invocation will always work.
Ok, so slaptest is the way to do the conversion. That should be explained somewhere, IMO.
On Friday 21 September 2007 06:07:47 Howard Chu wrote:
Use slaptest instead.
except that slaptest doesn't have a "run as another user" flag, and -u is already taken :-(.
I was just working with converting a conf file to a config backend and swear I saw a specific note somewhere to use slaptest (and I knew to use slaptest). Now poking around a bit I can't find it.
Nor do the tools need such an option; you can just use su. The reason slapd can't be started with just "su ldap" is because it may need root privs to open the listener sockets. That's the only reason it has -u/-g options.
Sure, and I use su in our init script when testing the configuration. But, some other distros don't, and don't use -u, and end up creating transaction log files as root, preventing startup later.
I don't perceive this as an OpenLDAP problem; it is more of a "bad distribution! bad!" kind of issue.
I am not aware of any recommendation of using su for slaptest (though it is quite obvious to many, it may be worth mentioning explicitly). And, it should certainly be mentioned in any documentation covering converting to back-config.
Nah, it is simply obvious/standard practice. Configuring services as a user or root and then setting permissions as the last step is just how things are done.
At present, it seems that if you want to do the conversion while slapd is running, and for a slapd that runs as non-root, something like this is the best option: # slapd -u ldap -g ldap -d none -h ldap://localhost:391/ -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d As then -The configuration will be converted -slapd won't start up
What makes you say that?
It will fail to open the database already opened by the running slapd.
I'm confused by all of this; who is going to be converting their configuration (which one assumes would also include testing the resulting configuration) while slapd is hot?
-you will see any relevant errors -all the files will be owned by the ldap user/group -if it succeeds, a restart of slapd is all that is necessary to continue
That seems like far more trouble than just using su...
It's aobut the same amount of typing:
slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d chown -R ldap.ldap /etc/openldap/slapd.d
openldap-software@openldap.org
-
Aaron Richton -
Adam Tauno Williams -
Buchan Milne -
David Damon -
Derek Yarnell -
Gabriel Stein -
Gavin Henry -
Gavin Henry -
Hex Star -
Howard Chu -
Jan-Piet Mens -
manu＠netbsd.org -
Michael Ströder -
Quanah Gibson-Mount -
Russ Allbery -
Tony Earnshaw