Re: Converting from slapd.d back to slapd.conf
On 03/27/2014 04:38 PM, Aaron Richton wrote: Would you mind documenting your concerns/experiences for the benefit of the list? (And, for that matter, if there are outright flaws they should be tracked in OpenLDAP's ITS...) I can give my reason: - it's more readable than the ldif slapcat is producing - I can put comments on it - I can go back to a previous configuration just by a cp o editing back the contents Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Converting from slapd.d back to slapd.conf
Hi, On Fri, 28 Mar 2014, Simone Piccardi wrote: On 03/27/2014 04:38 PM, Aaron Richton wrote: Would you mind documenting your concerns/experiences for the benefit of the list? (And, for that matter, if there are outright flaws they should be tracked in OpenLDAP's ITS...) I can give my reason: - it's more readable than the ldif slapcat is producing - I can put comments on it - I can go back to a previous configuration just by a cp o editing back the contents yes it is a very different concept. But after setting up several projects with cn=config I quite enjoy the new style of doing things: 1. I have ldiff snippets with nicely edited and commented acl configs and scheme deinitions that I apply with ldapmodify 2. I use ldapvi for quick changes 3. I replicate cn=config between members of a cluster and only apply changes to one of them 4. I have a bootstrapping config with :include: directives for pulling in standard schema. I do not use slaptest for bootstrapping anymore. 5. I have setup personal admin accounts that have permission to edit both the main dit and cn=config 6. I archive daily, weekly and monthly dumps of the configuration that I can easily diff if needed 7. I very much enjoy chaning the loglevel runtime in case I need detailed output 8. I also greatly enjoy the mostly consistent ordering of the config 9. When I goof up I delete slapd.d and reimport a known good config with slapadd -n0 -F slapd.d -l config.ldif cn=config does take some time getting used to and I myself also resisted for some time. It has a steeper learning curve and we need to document best practices and provide improved documentation for getting started. slapd.conf is not going away in the very near future at least not until the rough edges and bugs in cn=config have been sorted out. I consider cn=config superior once you get your head wrapped around it. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/
Re: Converting from slapd.d back to slapd.conf
On 28/3/2014 1:25 μμ, Christian Kratzer wrote: I consider cn=config superior once you get your head wrapped around it. On 28/3/2014 12:53 μμ, Simone Piccardi wrote: - I can put comments on it Christian, Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt. Here is a long discussion done in 2012 about this (this link points to my own message, but it is a long thread with valuable info): http://www.openldap.org/lists/openldap-technical/201203/msg00214.html I take the opportunity to repeat here that, IMHO it is vital to have (at least) correct ordering of ACLs and the ability to add comments anywhere in the config. Also see other usability issues mentioned in the above thread and elsewhere. I hope that now, when 2.5 branch has started, such issues may be addressed! All the best, Nick
Re: Syncrepl Multi-Master with multiple BDB backends
Michael, Michael schrieb (27.03.2014 21:58 Uhr): I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a replicate user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement? The replication user has to have enough rights to access (read) all the to replicate data on the provider. An ACL defined outside a database definition is valid for all of the databases on the server. So yes, you can have one replications user for all your databases (on the provider). Marc
Re: Converting from slapd.d back to slapd.conf
Hi, On Fri, 28 Mar 2014, Nick Milas wrote: On 28/3/2014 1:25 ??, Christian Kratzer wrote: I consider cn=config superior once you get your head wrapped around it. On 28/3/2014 12:53 ??, Simone Piccardi wrote: - I can put comments on it Christian, Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt. Here is a long discussion done in 2012 about this (this link points to my own message, but it is a long thread with valuable info): http://www.openldap.org/lists/openldap-technical/201203/msg00214.html yes cn=config needs some work and polishing. As we already have ordering in acl and such comments should not bee too hard to add. We still have the problem of formatting of individual attributes like olcAccess and olcSyncrepl which have tons of information. That's why I currently maintain my acl externally and version them using svn which allows me to keep my indentation, comments and formtting. I consider this quite similar to the way I maintain cisco router and asa firewall configs and specific acl on a tftp server and use copy tftp running-config to apply them. Ideally I would like to fire up ldapvi and see my comments and my formatting of large attributes such as olcSyncrepl and olcAccess perhaps split up over multiple lines. This of course poses challenges as the attributes are plain ascii strings. The best approach needs thiniking. I take the opportunity to repeat here that, IMHO it is vital to have (at least) correct ordering of ACLs and the ability to add comments anywhere in the config. Also see other usability issues mentioned in the above thread and elsewhere. Ordering is already implemented. +1 for the rest. I hope that now, when 2.5 branch has started, such issues may be addressed! I would suppose that patches and discussion is welcome. As a cn=config user I am equally interested in getting full usablity. Kind of like havin feature parity between ipv4 and ipv6 is so important in other areas. Greetings Christian All the best, Nick -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/
Re: cn=config replication mistake
Ferenc Wagner wrote:
Hi,
First, please let me tell you the story of my adventure yesterday. I'll
summarize my questions at the end.
I've set up a simple master-slave replicated system some time ago (stock
Debian wheezy OpenLDAP, version 2.4.31-1+nmu2):
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=1 provider=ldap://elm.niif.hu [...]
dn: olcDatabase={1}mdb,cn=config
olcSyncrepl: {0}rid=2 provider=ldap://elm.niif.hu [...]
The slave opened two connections to the master, and everything worked
fine. Then I enabled TLS and put in a CNAME record, so that the master
became accessible as ldaps://ldap-master.niif.hu. I decided to also
switch over the replication traffic to the SSL channel, so ldapmodified
the above attributes to contain provider=ldaps://ldap-master.niif.hu.
This pretty much broke the system, because the master server suddenly
started to replicate from itself, thus became read-only.
Finding no other option, I stopped the master slapd and edited back
the providers to their previous values (above) in the
olcDatabase={0}config.ldif and olcDatabase={1}mdb.ldif files under the
cn=config directory of my server configuration. I know these files
should not be edited, but I found no other way.
This move made the master recognized itself again in the provider URI,
so it did not start replicating and became writeable. My edits,
however, did not propagate to the slave, probably because I did not
change the internal attributes (entryCSN?) so this was expected. Also,
slapcat started to report CRC warnings in some LDIF files while dumping
the databases, which was also understandable for the edited ones, but
not so much for cn=config.ldif (if I remember correctly).
I tried to fix these by doing some dummy changes by ldapmodify to the
database entries. For both, I added an extra olcAccess attribute, then
deleted it. These operations made the slave switch back its syncrepl
connections to the ldap port from ldaps, but also instantly broke the
slave server, which stopped returning results and instead logged lots of
slapd[27944]: = mdb_idl_fetch_key: cursor failed: Invalid argument (22)
lines. Having no better idea, I restarted the slave server, which
fortunately returned it to normal working condition.
So, my questions:
1. How does the self-recognition (by which the master does not start
replicating from itself) work, why did it fail when I changed the
provider URI to ldaps?
As noted here
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
Did using a CNAME (instead of some FQDN of
the server) confuse it? Could this be fixed by adding an appropriate
subjectAltName to the server TLS certificate? Or by adding some
olcServerID attributes?
2. How could I have handled the read-only situation, instead of editing
forbidden LDIF files? Would setting olcMirrorMode have been
possible (without olcServerIDs around)?
At the moment, manually editing was probably your only course of action. In
OpenLDAP 2.5 the slapmodify tool should be used to make changes while slapd is
shutdown.
3. Is my setup in a reliable and consistent state now, or should I
expect sudden future failures? I mean, were the cursor failed
errors fixed for good by the slave server restart?
Don't know. You're using 2.4.31, current is 2.4.39, possibly you saw a bug
that has been fixed. Doesn't sound familiar though.
Please also feel free to educate me on any other points, as needed. :)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Converting from slapd.d back to slapd.conf
On 28/3/2014 3:59 μμ, Christian Kratzer wrote:
Ordering is already implemented.
Thanks Christian for your feeback, but, as of v2.4.39 (which I am
running), I can't confirm correct ACL ordering.
As explained in the thread I provided, ordering (of ACL rule numbers) is
string-based and not number-based, so LDAP clients cannot display ACL
rules in correct order.
The current order of my 34 rules (as displayed by clients) is:
{0},{10},...{19},{1},{20},{21},...{29},{2},{30},...{34},{3},{4},{5},{6},{7},{8},{9}
which makes ACL listing very unfriendly.
If I remember right (I can't find the thread right now), I had proposed
in the past (as a simple solution) to switch numbering from {0}, {1},...
to e.g. {000}, {001},... or even {}, {0001},...so that clients can
list them correctly.
N
Re: cn=config replication mistake
Howard Chu h...@symas.com writes: Ferenc Wagner wrote: 1. How does the self-recognition (by which the master does not start replicating from itself) work, why did it fail when I changed the provider URI to ldaps? As noted here http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master Thanks for pointing out that note, I missed it. So bare ldaps:/// is not usable in this case, I'll have to specify the CNAME here as well. As I don't depend on using INADDR_ANY (no dynamic interfaces), this should work fine. -- Thanks, Feri.
Re: memberof in openldap
Michael Ströder wrote: Brad Hartlove wrote: The core problem is why can I not add the operational attribute to my custom objectclass. Operational attributes are simply not normal user attributes. If your LDAP client is supposed to alter an attribute via LDAP it has to be a user attribute. Period. That's only a partial answer. Brad, the answer is go read the LDAP spec - operational attributes are never part of any objectclass definition, and the server is free to use them in any entry regardless of objectclass. The OpenLDAP manpages are not here to teach you the basics of LDAP. You're expected to read the specs and know the basics of LDAP. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
RE: Syncrepl Multi-Master with multiple BDB backends
Thanks Marc, that's essentially the information I was looking for. -Mike Date: Fri, 28 Mar 2014 13:18:00 +0100 From: hans.mo...@ofd-z.niedersachsen.de To: mlstarlin...@hotmail.com Subject: Re: Syncrepl Multi-Master with multiple BDB backends CC: openldap-technical@openldap.org Michael, Michael schrieb (27.03.2014 21:58 Uhr): I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a replicate user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement? The replication user has to have enough rights to access (read) all the to replicate data on the provider. An ACL defined outside a database definition is valid for all of the databases on the server. So yes, you can have one replications user for all your databases (on the provider). Marc
Re: Converting from slapd.d back to slapd.conf
Hi,
On Fri, 28 Mar 2014, Nick Milas wrote:
On 28/3/2014 3:59 ??, Christian Kratzer wrote:
Ordering is already implemented.
Thanks Christian for your feeback, but, as of v2.4.39 (which I am running), I
can't confirm correct ACL ordering.
As explained in the thread I provided, ordering (of ACL rule numbers) is
string-based and not number-based, so LDAP clients cannot display ACL rules
in correct order.
The current order of my 34 rules (as displayed by clients) is:
{0},{10},...{19},{1},{20},{21},...{29},{2},{30},...{34},{3},{4},{5},{6},{7},{8},{9}
which makes ACL listing very unfriendly.
strange I can see correct ordering of my acl and also of schema definitions in
both ldapvi and ldapsearch.
This is also on 2.4.39.
--snipp--
[ck@ldaptest1]$ ldapsearch -x -W -b cn={0}core,cn=schema,cn=config -o ldif-wrap=no '(objectClass=olcSchemaConfig)' olcAttributeTypes
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base cn={0}core,cn=schema,cn=config with scope subtree
# filter: (objectClass=olcSchemaConfig)
# requesting: olcAttributeTypes
#
# {0}core, schema, config
dn: cn={0}core,cn=schema,cn=config
olcAttributeTypes: {0}( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256:
knowledge information' EQUALITY caseIgnoreMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{32768} )
olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last
(family) name(s) for which the entity is known by' SUP name )
olcAttributeTypes: {2}( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial
number of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
olcAttributeTypes: {3}( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519:
two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )
olcAttributeTypes: {4}( 2.5.4.7 NAME ( 'l' 'localityName' ) DESC 'RFC2256:
locality which this object resides in' SUP name )
olcAttributeTypes: {5}( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC
'RFC2256: state or province which this object resides in' SUP name )
olcAttributeTypes: {6}( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC
'RFC2256: street address of this object' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {7}( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256:
organization this object belongs to' SUP name )
olcAttributeTypes: {8}( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated
with the entity' SUP name )
olcAttributeTypes: {9}( 2.5.4.14 NAME 'searchGuide' DESC 'RFC2256: search
guide, deprecated by enhancedSearchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
olcAttributeTypes: {10}( 2.5.4.15 NAME 'businessCategory' DESC 'RFC2256:
business category' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {11}( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal
address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
olcAttributeTypes: {12}( 2.5.4.17 NAME 'postalCode' DESC 'RFC2256: postal code'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{40} )
olcAttributeTypes: {13}( 2.5.4.18 NAME 'postOfficeBox' DESC 'RFC2256: Post
Office Box' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{40} )
olcAttributeTypes: {14}( 2.5.4.19 NAME 'physicalDeliveryOfficeName' DESC
'RFC2256: Physical Delivery Office Name' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
olcAttributeTypes: {15}( 2.5.4.20 NAME 'telephoneNumber' DESC 'RFC2256:
Telephone Number' EQUALITY telephoneNumberMatch SUBSTR
telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
--snipp--
Of course if your client tries to string sort the results after reading it will
mix things up.
If the clients leaves the order as it is, everything should be in correct order.
If the client desires to sort it would be trivial to focus on the braces and
numerically evaluate the value as sort order.
The problem with padding is how much to add. Do you want {000} or {} or
whatever.
Both of my favourite clients ldapsearch and ldapvi leave the order untouched.
Greetings
Christian
If I remember right (I can't find the thread right now), I had proposed in
the past (as a simple solution) to switch numbering from {0}, {1},... to e.g.
{000}, {001},... or even {}, {0001},...so that clients can list them
correctly.
N
--
Christian Kratzer CK Software GmbH
Email: c...@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
Re: memberof in openldap
Brad Hartlove wrote: I get everything you said. I also understand that this may be a valid permissions issue. If the answer is it isn't supposed to be done and the server will prevent that, that is what I will go with. This is not my first dance, but if I already knew every detail of LDAP's code, I wouldn't be on this mailing list. There is no such thing as LDAP's code - LDAP is a protocol definition built on a data model. There is OpenLDAP code and SunDS code etc., various other implementations of the protocol and data model. It is well documented that Sun/Netscape/RedHat/Microsoft implemented the specs incorrectly. As I have said, I am seeing this defined in another LDAP's objectClass, so someone figured it out right, wrong, or indifferent. I am not here to argue, so if that is what I go with, so be it. Brad Hartlove -Original Message- From: Howard Chu [mailto:h...@symas.com] Sent: Friday, March 28, 2014 11:08 AM To: Michael Ströder; brad.hartl...@g2-inc.com; openldap-technical@openldap.org Subject: Re: memberof in openldap Michael Ströder wrote: Brad Hartlove wrote: The core problem is why can I not add the operational attribute to my custom objectclass. Operational attributes are simply not normal user attributes. If your LDAP client is supposed to alter an attribute via LDAP it has to be a user attribute. Period. That's only a partial answer. Brad, the answer is go read the LDAP spec - operational attributes are never part of any objectclass definition, and the server is free to use them in any entry regardless of objectclass. The OpenLDAP manpages are not here to teach you the basics of LDAP. You're expected to read the specs and know the basics of LDAP. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Converting from slapd.d back to slapd.conf
On 03/28/2014 01:16 PM, Nick Milas wrote: On 28/3/2014 1:25 μμ, Christian Kratzer wrote: I consider cn=config superior once you get your head wrapped around it. On 28/3/2014 12:53 μμ, Simone Piccardi wrote: - I can put comments on it Christian, Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt. It's not only about comments, it's also about readability. The ACL order is a problem, but also having what were directives prefixed by olc make the output far less readable, brain is not fast as sed to remove unuseful (for human understanding) prefixes. Just think what an apache or bind configuration file will look if you prepend olc to almost all keywords. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Converting from slapd.d back to slapd.conf
Christian Kratzer wrote: Hi, On Fri, 28 Mar 2014, Nick Milas wrote: On 28/3/2014 1:25 ??, Christian Kratzer wrote: I consider cn=config superior once you get your head wrapped around it. On 28/3/2014 12:53 ??, Simone Piccardi wrote: - I can put comments on it Christian, Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt. Here is a long discussion done in 2012 about this (this link points to my own message, but it is a long thread with valuable info): http://www.openldap.org/lists/openldap-technical/201203/msg00214.html yes cn=config needs some work and polishing. As we already have ordering in acl and such comments should not bee too hard to add. We still have the problem of formatting of individual attributes like olcAccess and olcSyncrepl which have tons of information. The syncrepl consumer needs to be moved into an overlay (as was already done for the provider, years ago). At that point the config will simply be split into its own set of attributes, instead of a single large value. That's why I currently maintain my acl externally and version them using svn which allows me to keep my indentation, comments and formtting. I consider this quite similar to the way I maintain cisco router and asa firewall configs and specific acl on a tftp server and use copy tftp running-config to apply them. Ideally I would like to fire up ldapvi and see my comments and my formatting of large attributes such as olcSyncrepl and olcAccess perhaps split up over multiple lines. This of course poses challenges as the attributes are plain ascii strings. The best approach needs thiniking. I take the opportunity to repeat here that, IMHO it is vital to have (at least) correct ordering of ACLs and the ability to add comments anywhere in the config. Also see other usability issues mentioned in the above thread and elsewhere. Ordering is already implemented. +1 for the rest. I hope that now, when 2.5 branch has started, such issues may be addressed! I would suppose that patches and discussion is welcome. As a cn=config user I am equally interested in getting full usablity. Certainly, patches welcome. Kind of like havin feature parity between ipv4 and ipv6 is so important in other areas. Greetings Christian All the best, Nick -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: What is the default of `-b`?
How to search for everything in the ldap database (such config)?
On Fri, Mar 28, 2014 at 8:31 AM, Brad Hartlove
bradley.hartl...@g2-inc.com wrote:
Peng
The default of -b should be whatever you have specified in your
ldap.conf configuration file. In a fresh install, without any
configuration, I do not believe it will look for any base. The -b flag
is used to specify the base of the tree from where you wish to begin your
search. If you also pass the -v flag, it will spit out the base you are
using ex: # base dc=somedomain,dc=com with scope subtree. In the
ldap.conf (typically located in your /etc/opendlap directory in linux),
the directive you want to set is BASE. It natively comes with something
that is commented out ex: #BASE dc=example,dc=com. You need to
uncomment and add the appropriate base location from where you wish to
operate. Bear in mind that this affects the behavior of all your OpenLDAP
client calls if the -b is not specified in the command string.
Regards,
Brad Hartlove
-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Peng Yu
Sent: Thursday, March 27, 2014 4:17 PM
To: openldap-technical@openldap.org
Subject: What is the default of `-b`?
Hi,
The man page says the following.
`-b` *searchbase*
: Use *searchbase* as the starting point for the search instead of
the default.
I'm wondering what is the default. If I don't specify -b, I will get an
error. Does anyone know how show all the contents from the database?
Thanks.
$ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config
$ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// dn No such object (32)
--
Regards,
Peng
--
Regards,
Peng
Why ldapadd -x -D cn=admin, cn=config -W -f ~/sudoWork/cn\=sudo.ldif does not work?
Hi, I followed the following instructions. http://ubuntuforums.org/showthread.php?t=1421998 I get the following error. pengy@openldapserver:~$ ldapadd -x -D cn=admin,cn=config -W -f ~/sudoWork/cn\=sudo.ldif Enter LDAP Password: ldap_bind: Invalid credentials (49) Here is the log. Does anybody know what the log means and how to fix the problem? Thanks. pengy@openldapserver:~$ tail -n 5 /var/log/syslog Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 fd=21 ACCEPT from IP=127.0.0.1:47481 (IP=0.0.0.0:389) Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=0 BIND dn=cn=admin,cn=config method=128 Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=0 RESULT tag=97 err=49 text= Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=1 UNBIND Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 fd=21 closed -- Regards, Peng
