9:49 a.m.
Hi Torsten,
Thanks for your help!
On 07/03/11 17:37, Torsten Schlabach (Tascel eG) wrote:
Take a look at the olcAccess attribute values of your cn=config
database.
This should tell you who's allowed to read it or not.
I did add a value to try and make this work (see below), but perhaps I
haven't done all that's necessary.
It depends where your cn=config data comes from, but in many examples
you
will find an olcAccess attribute granting write access to a DN called
cn=admin,cn=config. You need to have that object in your cn=config database
then and it should have the password attribute set.
Post the olcAccess sections of your LDIF here, I think this may help.
Here is my olcDatabase={0}config.ldif, with some comments:
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
# This one added by me recently:
olcAccess: {0}to * by dn.exact=cn=admin,cn=config manage by * break
structuralObjectClass: olcDatabaseConfig
entryUUID: 9dfea13e-dd1c-102f-8cc4-2fe95e0d0dbe
creatorsName: cn=config
createTimestamp: 20110307153755Z
entryCSN: 20110307153755.993390Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20110307153755Z
# These two added by me recently:
oldRootDN: cn=admin,cn=config
olcRootPW: config
So it looks like I just need to make sure I have the cn=admin,cn=config
object in my database. And I think I can probably add it using the magic
-Y EXTERNAL method and ldapadd. However, I don't know how to construct
it - what objectClass should it have?
Gerv
1:33 p.m.
New subject: LDAP browsers and cn=config
Gervase Markham wrote:
On 07/03/11 17:49, Gervase Markham wrote:
> oldRootDN: cn=admin,cn=config
----^
And that would be the problem :-|
Thank you for your help.<shuffles feet in an embarrassed fashion>
cn=config is an LDAP database, it is not a collection of files for you to edit
by hand. You are supposed to use ldapmodify on it, for reasons of this very
nature. I.e., ldapmodify gets syntax-checked and stupid typos of this sort get
caught.
If you had used "ldapmodify -H ldapi:/// -Y EXTERNAL" to add the desired
attributes you wouldn't have these silly problems.
If your LDAP browsers don't support ldapi:/// that's their deficiency...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:51 a.m.
New subject: LDAP browsers and cn=config
On 07/03/11 21:33, Howard Chu wrote:
Gervase Markham wrote:
> On 07/03/11 17:49, Gervase Markham wrote:
>> oldRootDN: cn=admin,cn=config
> ----^
>
> And that would be the problem :-|
>
> Thank you for your help.<shuffles feet in an embarrassed fashion>
cn=config is an LDAP database, it is not a collection of files for you
to edit by hand.
Although presumably if you manage to mess up your configuration enough,
that's what you have to do. I've seen "you can edit the files by hand if
it all goes wrong" used as an argument for using the LDIF backend for
cn=config in the archives of this very mailing list, if I'm not mistaken.
You are supposed to use ldapmodify on it, for reasons
of this very nature. I.e., ldapmodify gets syntax-checked and stupid
typos of this sort get caught.
But being able to edit the database is precisely the problem I had! It's
rather chicken and egg.
If you had used "ldapmodify -H ldapi:/// -Y EXTERNAL" to
add the desired
attributes you wouldn't have these silly problems.
Yes, of course - because Real Men use commands with a minimum of 4
command-line flags to do any operation, and if I'm not up to that, I
can't possibly be worthy to use OpenLDAP.
If your LDAP browsers don't support ldapi:/// that's their
deficiency...
I don't even know what the "i" in ldapi is, or how it's different from
ldap://. And this search of the OpenLDAP documentation is sadly
unenlightening:
http://www.google.co.uk/search?hl=en&q=ldapi%20site%3Aopenldap.org/doc
Can you tell me which LDAP browsers do support this scheme? After all,
the other part of my message was asking for advice on which was best.
There are two ways you, the development team, can think about OpenLDAP:
A) "You have to prove your worthiness to use this software by having a
wide knowledge of Unix history, unwritten conventions, cryptic man-pages
and a perfect recall of command-line options. Searchable documentation
on the web - pah!"
http://farm1.static.flickr.com/87/240803829_9212773615_o.png
B) "We want to lower barriers to entry and make it easier to use."
If the answer is B), then instead of telling me that I'm an idiot, you
might wish to reflect on what lessons can be learnt from my experience
to help other people in the future.
I must say that my experience with the OpenLDAP community thusfar has
not thrilled me with joy at the prospect of using the software for my
project. I speak as someone whose day job is nurturing, growing and
encouraging open source communities.
Gerv
2:34 a.m.
New subject: LDAP browsers and cn=config
Gervase Markham wrote:
On 07/03/11 21:33, Howard Chu wrote:
> Gervase Markham wrote:
>> On 07/03/11 17:49, Gervase Markham wrote:
>>> oldRootDN: cn=admin,cn=config
>> ----^
>>
>> And that would be the problem :-|
>>
>> Thank you for your help.<shuffles feet in an embarrassed fashion>
>
> cn=config is an LDAP database, it is not a collection of files for you
> to edit by hand.
Although presumably if you manage to mess up your configuration enough,
that's what you have to do. I've seen "you can edit the files by hand if
it all goes wrong" used as an argument for using the LDIF backend for
cn=config in the archives of this very mailing list, if I'm not mistaken.
As a last resort, not a first measure. You should also have seen in the
archives "cn=config is a slapd database and like any other slapd database, the
format is subject to change without notice." We may well shift it to a purely
binary format down the road.
> You are supposed to use ldapmodify on it, for reasons
> of this very nature. I.e., ldapmodify gets syntax-checked and stupid
> typos of this sort get caught.
But being able to edit the database is precisely the problem I had! It's
rather chicken and egg.
You're apparently working with a slapd that had a pre-canned config. If the
means of accessing the config wasn't obvious to you, then you should be taking
this up with your distro or whoever provided the canned config to you.
> If you had used "ldapmodify -H ldapi:/// -Y EXTERNAL"
to add the desired
> attributes you wouldn't have these silly problems.
Yes, of course - because Real Men use commands with a minimum of 4
command-line flags to do any operation, and if I'm not up to that, I
can't possibly be worthy to use OpenLDAP.
You can always set these as defaults in /etc/openldap/ldap.conf. Again, if
whoever provided your configs to you didn't set this up or document it
clearly, your beef is with them, not the OpenLDAP community. We don't control
what distros do.
> If your LDAP browsers don't support ldapi:/// that's
their deficiency...
I don't even know what the "i" in ldapi is, or how it's different from
ldap://. And this search of the OpenLDAP documentation is sadly
unenlightening:
http://www.google.co.uk/search?hl=en&q=ldapi%20site%3Aopenldap.org/doc
http://www.openldap.org/devel/cvsweb.cgi/doc/drafts/draft-chu-ldap-ldapi-...
Can you tell me which LDAP browsers do support this scheme? After
all,
the other part of my message was asking for advice on which was best.
Anyone built on top of libldap would support it implicitly. I don't keep tabs
of browsers, so I can't recommend one to you.
There are two ways you, the development team, can think about
OpenLDAP:
A) "You have to prove your worthiness to use this software by having a
wide knowledge of Unix history, unwritten conventions, cryptic man-pages
and a perfect recall of command-line options. Searchable documentation
on the web - pah!"
http://farm1.static.flickr.com/87/240803829_9212773615_o.png
Nonsense. 90% of the OpenLDAP installs in the world are on POSIX-based
systems. If you're using one of these systems and you haven't learned how to
use the most common Unix commands you're doing yourself a disservice. It's not
our job to teach you the basics of getting proficiency with your OS.
You don't have to prove anything to me or anyone else; you simply have to have
the skills that any Unix sysadmin must already possess to have any hope of
doing the job of a sysadmin. The most basic of these is the ability to
actually read documentation and pay attention to the details. You miss the
details and you wind up typing "rm -rf *" in the wrong directory.
B) "We want to lower barriers to entry and make it easier to
use."
We want to make it easier to use, of course, for *system administrators*. This
is not a browser or an email client that Joe Sixpack will use every day. It's
core infrastructure that the majority of the world will never see and never
needs to know about. For that minority of people who need to know, you have
your work cut out for you already. You better already understand IP and TCP
intimately, and you better know how to tune your OS because you're going to
need that kind of knowledge to do your job, whether OpenLDAP is a part of it
or not.
System administration is not for children. Don't ask to be coddled like a
child; that's not what we're here for.
If the answer is B), then instead of telling me that I'm an
idiot, you
might wish to reflect on what lessons can be learnt from my experience
to help other people in the future.
I must say that my experience with the OpenLDAP community thusfar
has
not thrilled me with joy at the prospect of using the software for my
project. I speak as someone whose day job is nurturing, growing and
encouraging open source communities.
Don't blame the community for your own unpreparedness. If your distro didn't
document their chosen configuration well enough to prepare you, then your
complaint is with them, not us. The community is the folks who have stepped in
to bail you out when you were going the wrong direction, we didn't send you in
the wrong direction in the first place.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:35 a.m.
New subject: LDAP browsers and cn=config
Am Tue, 08 Mar 2011 09:51:01 +0000
schrieb Gervase Markham <gerv(a)mozilla.org>:
On 07/03/11 21:33, Howard Chu wrote:
> Gervase Markham wrote:
>> On 07/03/11 17:49, Gervase Markham wrote:
>>> oldRootDN: cn=admin,cn=config
>> ----^
>>
> If you had used "ldapmodify -H ldapi:/// -Y EXTERNAL" to add the
> desired attributes you wouldn't have these silly problems.
[...]
Yes, of course - because Real Men use commands with a minimum of 4
command-line flags to do any operation, and if I'm not up to that, I
can't possibly be worthy to use OpenLDAP.
> If your LDAP browsers don't support ldapi:/// that's their
> deficiency...
I don't even know what the "i" in ldapi is, or how it's different
from ldap://. And this search of the OpenLDAP documentation is sadly
unenlightening:
search the IETF for draft-chu-ldap-ldapi, Using LDAP Over IPC Mechanisms
http://www.google.co.uk/search?hl=en&q=ldapi%20site%3Aopenldap.org/doc
Can you tell me which LDAP browsers do support this scheme? After
all, the other part of my message was asking for advice on which was
best.
http://web2ldap.de
[...]
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
3:12 a.m.
New subject: LDAP browsers and cn=config
Gervase Markham wrote:
Can you tell me which LDAP browsers do support this scheme? After
all,
the other part of my message was asking for advice on which was best.
Ironically, I used to use the Netscape browser as my preferred LDAP browser,
many years ago. Don't recall when they axed that feature, it was quite handy,
and getting the results pretty-printed in HTML was really nice.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:26 a.m.
New subject: LDAP browsers and cn=config
Howard Chu wrote:
Gervase Markham wrote:
> Can you tell me which LDAP browsers do support this scheme? After all,
> the other part of my message was asking for advice on which was best.
Ironically, I used to use the Netscape browser as my preferred LDAP
browser, many years ago.
Yes, that's the historic reason my web2ldap still displays some LDAP URLs
in <a href="">. Today I use these links mainly for constructing
bookmarks.
web2ldap simply processes LDAP URLs given as QUERY_STRING:
http://web2ldap.de/usability.html#persistent_bookmarks
Don't recall when they axed that feature,
It was part of Netscape Communicator 4.5+.
It was never ported to Mozilla browser.
it was quite handy,
I thought about integrating web2ldap as a custom handler URL handler based on
the Protzilla extension. But I never got the thing working.
and getting the results pretty-printed in HTML was
really nice.
Well, it did not do any HTML escaping of attribute values at all. I remember
that the public Bigfoot LDAP server contained HTML in some attributes which
was directly displayed. So today with all the XSS stuff it would be a security
nightmare in this naive form.
Ciao, Michael.
3:28 a.m.
New subject: LDAP browsers and cn=config
Michael Ströder wrote:
I thought about integrating web2ldap as a custom handler URL handler
based on
the Protzilla extension. But I never got the thing working.
Sorry, slightly wrong name.
It was called Protozilla:
http://protozilla.mozdev.org/
Ciao, Michael.
3:10 a.m.
New subject: LDAP browsers and cn=config
----- "Gervase Markham" <gerv(a)mozilla.org> wrote:
On 07/03/11 21:33, Howard Chu wrote:
> Gervase Markham wrote:
>> On 07/03/11 17:49, Gervase Markham wrote:
>>> oldRootDN: cn=admin,cn=config
>> ----^
>>
>> And that would be the problem :-|
>>
>> Thank you for your help.<shuffles feet in an embarrassed fashion>
>
> cn=config is an LDAP database, it is not a collection of files for
you
> to edit by hand.
Although presumably if you manage to mess up your configuration
enough,
that's what you have to do.
But, how did you mess it up so bad in the first place?
I've seen "you can edit the files by hand
if
it all goes wrong" used as an argument for using the LDIF backend for
cn=config in the archives of this very mailing list, if I'm not
mistaken.
> You are supposed to use ldapmodify on it, for reasons
> of this very nature. I.e., ldapmodify gets syntax-checked and
stupid
> typos of this sort get caught.
But being able to edit the database is precisely the problem I had!
It's
rather chicken and egg.
> If you had used "ldapmodify -H ldapi:/// -Y EXTERNAL" to add the
desired
> attributes you wouldn't have these silly problems.
Yes, of course - because Real Men use commands with a minimum of 4
command-line flags to do any operation, and if I'm not up to that, I
can't possibly be worthy to use OpenLDAP.
echo -e "URI ldapi:///\nSASL_MECH EXTERNAL" >> ~/.ldaprc
Then you won't have to use 4 commandline flags in future.
> If your LDAP browsers don't support ldapi:/// that's
their
deficiency...
I don't even know what the "i" in ldapi is, or how it's different from
ldap://. And this search of the OpenLDAP documentation is sadly
unenlightening:
http://www.google.co.uk/search?hl=en&q=ldapi%20site%3Aopenldap.org/doc
Can you tell me which LDAP browsers do support this scheme? After all,
the other part of my message was asking for advice on which was best.
There are two ways you, the development team, can think about
OpenLDAP:
Which development team shipped your config, and set you up with config editing using
ldapi, but didn't think it was a good idea to populate root's .ldaprc ?
Probably not the OpenLDAP team.
Regards,
Buchan
4657
days inactive
4661
days old
openldap-technical@openldap.org
9 comments
5 participants
participants (5)
-
Buchan Milne -
Dieter Kluenter -
Gervase Markham -
Howard Chu -
Michael Ströder