9:20 a.m.
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(a)umiacs.umd.edu
2:45 p.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:35 p.m.
Howard Chu <hyc(a)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?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
3:17 a.m.
On Thursday 20 September 2007 05:35:14 Emmanuel Dreyfus wrote:
Howard Chu <hyc(a)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
6:03 a.m.
Emmanuel Dreyfus wrote:
Howard Chu <hyc(a)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."
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
6:57 a.m.
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
> Howard Chu <hyc(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:37 a.m.
Howard Chu wrote:
Gavin Henry wrote:
> Emmanuel Dreyfus wrote:
>> Howard Chu <hyc(a)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 ;-)
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
9:34 a.m.
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
1:19 p.m.
Howard Chu <hyc(a)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
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
1:41 p.m.
Emmanuel Dreyfus wrote:
Howard Chu <hyc(a)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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
1:46 p.m.
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
> Howard Chu <hyc(a)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/
1:56 p.m.
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(a)symas.com> wrote:
Gavin Henry wrote:
> Emmanuel Dreyfus wrote:
>> Howard Chu <hyc(a)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
gabrielstein(a)gmail.com
MSN: gabrielstein(a)hotmail.com
Administrador de Redes -
Network Administrador
Linux User #223750
51-92796310
Porto Alegre - RS - Brasil
2:45 p.m.
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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
3 p.m.
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.
11:19 p.m.
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 ? ;-)
4:50 a.m.
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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
11:30 a.m.
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
--
Tony Earnshaw
Email: tonni at hetnet dot nl
7:29 p.m.
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(a)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:
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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
--
/\
Gabriel Stein
gabrielstein(a)gmail.com
MSN: gabrielstein(a)hotmail.com
Administrador de Redes -
Network Administrador
Linux User #223750
51-92796310
Porto Alegre - RS - Brasil
11:59 p.m.
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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
12:48 a.m.
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_...
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_OpenL...
or this part:
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenL...
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_OpenL...
Here are the issues with your appreciated suggestions:
1. 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
2. We have to find the time to mentor and verify the howto/wiki
contributors.
Are you saying I need mentorship and verification?
3. 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 ...
4. 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.
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).
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
1:21 a.m.
> 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_...
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_OpenL...
or this part:
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenL...
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_OpenL...
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:
>
> 1. 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.
> 2. 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.
> 3. 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.
> 4. 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.
> 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).
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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
7:51 a.m.
>> 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_...
> 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_OpenL...
> or this part:
>
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenL...
> 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_OpenL...
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:
>> 1. 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.
>> 3. 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.
>> 4. 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? :)
>> 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).
> 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
9:27 a.m.
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(a)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_...
> > 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_OpenL...
> > or this part:
> >
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenL...
> > 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_OpenL...
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:
> >> 1. 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.
> >> 3. 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.
> >> 4. 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? :)
> >> 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).
> > 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
--
/\
Gabriel Stein
gabrielstein(a)gmail.com
MSN: gabrielstein(a)hotmail.com
Administrador de Redes -
Network Administrador
Linux User #223750
51-92796310
Porto Alegre - RS - Brasil
10:21 a.m.
--On Friday, September 21, 2007 1:27 PM -0300 Gabriel Stein
<gabrielstein(a)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
10:33 a.m.
Quanah Gibson-Mount wrote:
--On Friday, September 21, 2007 1:27 PM -0300 Gabriel Stein
<gabrielstein(a)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.
--
-- 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/
12:07 p.m.
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 ;-)
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
11:59 a.m.
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_...
>> 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_OpenL...
>> or this part:
>>
http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenL...
>> 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_OpenL...
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:
>>> 1. 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.
>>> 3. 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.
>>> 4. 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? :)
>>> 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).
>> 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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
1:32 a.m.
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.
--
-- 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/
6:13 a.m.
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.
4:27 a.m.
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.
5:30 a.m.
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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
2:18 p.m.
Howard Chu wrote:
Gavin Henry wrote:
> Emmanuel Dreyfus wrote:
>> Howard Chu <hyc(a)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.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
5:30 p.m.
New subject: Documentation request (was: Re: cn=config example)
Gavin Henry <ghenry(a)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 (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
6:17 p.m.
New subject: Documentation request
Russ Allbery wrote:
Gavin Henry <ghenry(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:37 p.m.
New subject: Documentation request
Howard Chu <hyc(a)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
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
7:10 p.m.
New subject: Documentation request
--On Thursday, September 20, 2007 6:37 PM -0700 Russ Allbery
<rra(a)stanford.edu> wrote:
Howard Chu <hyc(a)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
8:33 p.m.
New subject: Documentation request
Quanah Gibson-Mount wrote:
--On Thursday, September 20, 2007 6:37 PM -0700 Russ Allbery
<rra(a)stanford.edu> wrote:
> Howard Chu <hyc(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:43 p.m.
New subject: Documentation request
Howard Chu <hyc(a)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.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
10:05 p.m.
New subject: Documentation request
--On Thursday, September 20, 2007 8:43 PM -0700 Russ Allbery
<rra(a)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
2:16 p.m.
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?
8:55 p.m.
Aaron Richton <richton(a)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
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
9:07 p.m.
Emmanuel Dreyfus wrote:
Aaron Richton <richton(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:33 p.m.
Howard Chu <hyc(a)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
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
11:51 p.m.
Emmanuel Dreyfus wrote:
Howard Chu <hyc(a)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"
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
11:58 p.m.
Gavin Henry wrote:
Emmanuel Dreyfus wrote:
> Howard Chu <hyc(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:56 a.m.
Howard Chu wrote:
Gavin Henry wrote:
> Emmanuel Dreyfus wrote:
>> Howard Chu <hyc(a)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(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
10:49 a.m.
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(a)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(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Regards,
David Damon
Senior Systems Integration Analyst
Office: (714) 442-7562
FAX: (714) 442-2845
12:02 p.m.
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"
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
12:41 p.m.
Gavin Henry <ghenry(a)suretecsystems.com> wrote:
Thanks for that, but we have to assume some background knowledge ;-)
Then the amount of
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
12:43 p.m.
Emmanuel Dreyfus <manu(a)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(a)netbsd.org
12:58 p.m.
Emmanuel Dreyfus wrote:
Emmanuel Dreyfus <manu(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:44 a.m.
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
--
Tony Earnshaw
Email: tonni at hetnet dot nl
1:12 p.m.
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(a)netbsd.org> wrote:
Emmanuel Dreyfus <manu(a)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(a)netbsd.org
--
/\
Gabriel Stein
gabrielstein(a)gmail.com
MSN: gabrielstein(a)hotmail.com
Administrador de Redes -
Network Administrador
Linux User #223750
51-92796310
Porto Alegre - RS - Brasil
1:07 p.m.
<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(a)netbsd.org> wrote:
>
> Emmanuel Dreyfus <manu(a)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(a)netbsd.org
>
--
/\
Gabriel Stein
gabrielstein(a)gmail.com
MSN: gabrielstein(a)hotmail.com
Administrador de Redes -
Network Administrador
Linux User #223750
51-92796310
Porto Alegre - RS - Brasil
12:14 a.m.
On Friday 21 September 2007 06:07:47 Howard Chu wrote:
Emmanuel Dreyfus wrote:
> Aaron Richton <richton(a)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
12:52 a.m.
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...
--
-- 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/
1:20 a.m.
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
1:28 a.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:41 a.m.
Howard Chu <hyc(a)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.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
7:19 a.m.
> > 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
--
Consonance: an Open Source .NET OpenGroupware client.
http://code.google.com/p/consonance/ - Searching for a bored Cairo# hacker.
Contact:awilliam@whitemiceconsulting.com http://www.opengroupware.org
5913
days inactive
5916
days old
openldap-software@openldap.org
59 comments
16 participants
participants (16)
-
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