]> git.sur5r.net Git - openldap/commitdiff
Sync with HEAD
authorQuanah Gibson-Mount <quanah@openldap.org>
Tue, 23 Oct 2007 21:06:09 +0000 (21:06 +0000)
committerQuanah Gibson-Mount <quanah@openldap.org>
Tue, 23 Oct 2007 21:06:09 +0000 (21:06 +0000)
20 files changed:
doc/guide/admin/Makefile
doc/guide/admin/appendix-changes.sdf
doc/guide/admin/appendix-common-errors.sdf [new file with mode: 0644]
doc/guide/admin/appendix-contrib.sdf [new file with mode: 0644]
doc/guide/admin/appendix-deployments.sdf [new file with mode: 0644]
doc/guide/admin/appendix-ldap-result-codes.sdf [new file with mode: 0644]
doc/guide/admin/appendix-recommended-versions.sdf [new file with mode: 0644]
doc/guide/admin/aspell.en.pws
doc/guide/admin/dbtools.sdf
doc/guide/admin/intro.sdf
doc/guide/admin/maintenance.sdf
doc/guide/admin/master.sdf
doc/guide/admin/monitoringslapd.sdf
doc/guide/admin/overlays.sdf
doc/guide/admin/preface.sdf
doc/guide/admin/replication.sdf
doc/guide/admin/runningslapd.sdf
doc/guide/admin/slapdconf2.sdf
doc/guide/admin/troubleshooting.sdf
doc/guide/admin/tuning.sdf

index f4ba869bc8ef3cd135b0863d5f119241d9945925..5b673a9201408f5935bb64fd18c3fa27b797eb14 100644 (file)
@@ -19,7 +19,12 @@ sdf-src: \
        ../preamble.sdf \
        abstract.sdf \
        appendix-changes.sdf \
+       appendix-common-errors.sdf \
        appendix-configs.sdf \
+       appendix-contrib.sdf \
+       appendix-deployments.sdf \
+       appendix-ldap-result-codes.sdf \
+       appendix-recommended-versions.sdf \
        appendix-upgrading.sdf \
        backends.sdf \
        config.sdf \
index 4ee1dce24867c04ee748955c25bdd739f950df6c..05dc7f418a9924ecccd48200a8626e20c7669fb5 100644 (file)
@@ -23,7 +23,13 @@ asked on the OpenLDAP mailing lists and scenarios discussed there, we have added
 * {{SECT:Tuning}}
 * {{SECT:Troubleshooting}}
 * {{SECT:Changes Since Previous Release}}
+* {{SECT:Upgrading from 2.3.x}}
+* {{SECT:Common errors encountered when using OpenLDAP Software}}
+* {{SECT:Recommended OpenLDAP Software Dependency Versions}}
+* {{SECT:Real World OpenLDAP Deployments and Examples}}
+* {{SECT:OpenLDAP Software Contributions}}
 * {{SECT:Configuration File Examples}}
+* {{SECT:LDAP Result Codes}}
 * {{SECT:Glossary}}
 
 Also, the table of contents is now 3 levels deep to ease navigation.
diff --git a/doc/guide/admin/appendix-common-errors.sdf b/doc/guide/admin/appendix-common-errors.sdf
new file mode 100644 (file)
index 0000000..f24f509
--- /dev/null
@@ -0,0 +1,482 @@
+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Common errors encountered when using OpenLDAP Software
+
+The following sections attempt to summarize the most common causes of LDAP errors 
+when using OpenLDAP
+
+H2: Common causes of LDAP errors
+
+H3: ldap_*: Can't contact LDAP server
+
+The {[B:Can't contact LDAP server}} error is usually returned when the LDAP 
+server cannot be contacted. This may occur for many reasons:
+
+* the LDAP server is not running; this can be checked by running, for example,
+
+>      telnet <host> <port>
+
+replacing {{<host>}} and {{<port>}} with the hostname and the port the server 
+is supposed to listen on.
+* the client has not been instructed to contact a running server; with OpenLDAP 
+command-line tools this is accomplished by providing the -H switch, whose 
+argument is a valid LDAP url corresponding to the interface the server is supposed to be listening on.
+
+H3: ldap_*: No such object
+
+The {{B:no such object}} error is generally returned when the target DN of the 
+operation cannot be located. This section details reasons common to all 
+operations. You should also look for answers specific to the operation 
+(as indicated in the error message).
+
+The most common reason for this error is non-existence of the named object. First, 
+check for typos.
+
+Also note that, by default, a new directory server holds no objects 
+(except for a few system entries). So, if you are setting up a new directory 
+server and get this message, it may simply be that you have yet to add the 
+object you are trying to locate.
+
+The error commonly occurs because a DN was not specified and a default was not properly configured.
+
+If you have a suffix specified in slapd.conf eg.
+
+>      suffix "dc=example,dc=com"
+
+You should use
+
+>      ldapsearch -b 'dc=example,dc=com' '(cn=jane*)'
+
+to tell it where to start the search.
+
+The -b should be specified for all LDAP commands unless you have an ldap.conf(5) default configured.
+
+See Also: ldapsearch(1), ldapmodify(1), and (Xref) How do I specify default base DN for clients?
+Also, slapadd(8) and its ancillary programs are very strict about the syntax of the LDIF file. Some liberties in the LDIF file may result in an apparently successful creation of the database, but accessing some parts of it may be difficult.
+
+One known common error in database creation is putting a blank line before the first entry in the LDIF file. There must be no leading blank lines in the LDIF file.
+
+It is generally recommended that ldapadd(1) be used instead of slapadd(8) when adding new entries your directory. slapadd(8) should be used to bulk load entries known to be valid.
+Another cause of this message is a referral entry to an unpopulated directory. Either remove the referral, or add a single record with the referral base DN to the empty directory.
+This error may also occur when slapd is unable to access the contents of its database because of file permission problems. For instance, on a Red Hat Linux system, slapd runs as user 'ldap'. When slapadd is run as root to create a database from scratch, the contents of /var/lib/ldap are created with user and group root and with permission 600, making the contents inaccessible to the slapd server.
+
+H3: ldap_*: Can't chase referral
+
+This is caused by the line
+
+>      referral        ldap://root.openldap.org
+
+in slapd.conf, It was provided as an example for how to use referrals in the original file. however if your machine is not permanently connected to the Internet, it will fail to find the server, and hence produce an error message.
+
+To resolve, just place a # in front of line and restart slapd or point it to an available ldap server.
+See also: ldapadd(1) ldapmodify(1) slapd.conf(5)
+
+H3: ldap_*: server is unwilling to perform
+
+The OpenLDAP server will return an unwilling to perform error if the backend holding the target entry does not support the given operation.
+The password backend is only willing to perform searches. It will return an unwilling to perform error for all other operations.
+The shell backend is configurable and may support a limited subset of operations.
+Check for other errors indicating a shortage of resources required by the directory server. i.e. you may have a full disk etc
+
+H3: ldap_*: Insufficient access
+
+This error occurs when server denies the operation due to insufficient access. This is usually caused by binding to a DN with insufficient privileges (or binding anonymously) to perform the operation. You can bind as the rootdn/rootpw specified in slapd.conf(5) to gain full access. Otherwise, you must bind to an entry which has been granted the appropriate rights through access controls.
+See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5)
+(Xref) ldap_bind: Insufficient access (Xref) Access Control
+
+H3: ldap_*: Invalid DN syntax
+
+The target (or other) DN of the operation is invalid. This implies that either the string representation of the DN is not in the required form, one of the types in the attribute value assertions is not defined, or one of the values in the attribute value assertions does not conform to the appropriate syntax.
+
+H3: ldap_*: Referral hop limit exceeded
+
+This error generally occurs when the client chases a referral which refers itself back to a server it already contacted. The server responds as it did before and the client loops. This loop is detected when the hop limit is exceeded.
+
+This is most often caused through misconfiguration of the server's default referral. The default referral should not be itself:
+
+That is, on ldap://myldap/ the default referral should not be ldap://myldap/ (or any hostname/ip which is equivalent to myldap).
+
+H3: ldap_*: operations error
+
+In some versions of slapd(8), operationsError was returned instead of other. See also: (Xref) ldap_*: other error.
+
+H3: ldap_*: other error
+
+The other result code indicates an internal error has occurred. While the additional information provided with the result code might provide some hint as to the problem, often one will need to consult the server's log files.
+
+H3: ldap_add/modify: Invalid syntax
+
+This error is reported when a value of an attribute does not conform to syntax restrictions. Additional information is commonly provided stating which value of which attribute was found to be invalid. Double check this value and other values (the server will only report the first error it finds).
+
+Common causes include:
+
+* extraneous white space (especially trailing white space)
+* improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
+* empty values (few syntaxes allow empty values)
+
+
+For certain syntax, like OBJECT IDENTIFIER (OID), this error can indicate that the OID descriptor (a "short name") provided is unrecognized. For instance, this error is returned if the objectClass value provided is unrecognized.
+
+H3: ldap_add/modify: Object class violation
+
+This error is returned with the entry to be added or the entry as modified violates the object class schema rules. Normally additional information is returned the error detailing the violation. Some of these are detailed below.
+
+Violations related to the entry's attributes:
+
+>      Attribute not allowed
+        A provided attribute is not allowed by the entry's object class(es). 
+>      Missing required attribute
+        An attribute required by the entry's object class(es) was not provided. 
+
+Violations related to the entry's class(es):
+
+>      Entry has no objectClass attribute
+        The entry did not state which object classes it belonged to. 
+>      Unrecognized objectClass
+        One (or more) of the listed objectClass values is not recognized. 
+>      No structural object class provided
+        None of the listed objectClass values is structural. 
+>      Invalid structural object class chain
+        Two or more structural objectClass values are not in same structural object class chain. See also (Xref) ldap add: invalid structural object class chain. 
+>      Structural object class modification
+        Modify operation attempts to change the structural class of the entry. See also (Xref) ldap_modify: cannot modify object class. 
+>      Instanstantiation of abstract objectClass.
+        An abstract class is not subordinate to any listed structural or auxiliary class. 
+>      Invalid structural object class
+        Other structural object class problem. 
+>      No structuralObjectClass operational attribute
+        This is commonly returned when a shadow server is provided an entry which does not contain the structuralObjectClass operational attribute. 
+
+
+Note that the above error messages as well as the above answer assumes basic knowledge of LDAP/X.500 schema.
+
+H3: ldap_add: No such object
+
+The "ldap_add: No such object" error is commonly returned if parent of the entry being added does not exist. Add the parent entry first...
+
+For example, if you are adding "cn=bob,dc=domain,dc=com" and you get:
+
+>      ldap_add: No such object
+
+The entry "dc=domain,dc=com" likely doesn't exist. You can use ldapsearch to see if does exist:
+
+>      ldapsearch -b 'dc=domain,dc=com' -s base '(objectclass=*)'
+
+If it doesn't, add it. See the Quick Start Guide (http://www.openldap.org/doc/admin/quickstart.html) for assistance.
+
+Note: if the entry being added is the same as database suffix, it's parent isn't required. i.e.: if your suffix is "dc=domain,dc=com", "dc=com" doesn't need to exist to add "dc=domain,dc=com".
+This error will also occur if you try to add any entry that the server is not configured to hold.
+
+For example, if your database suffix is "dc=domain,dc=com" and you attempt to add "dc=domain2,dc=com", "dc=com", "dc=domain,dc=org", "o=domain,c=us", or an other DN in the "dc=domain,dc=com" subtree, the server will return a "No such object" (or referral) error.
+
+slapd(8) will generally return "no global superior knowledge" as additional information indicating its return noSuchObject instead of a referral as the server is not configured with knowledge of a global superior server.
+See also: ldapadd(1) ldapmodify(1) (Xref) ldap_add/delete/modify/rename: no global superior knowledge
+
+H3: ldap add: invalid structural object class chain
+
+This particular error refers to the rule about STRUCTURAL objectclasses, which states that an object is of one STRUCTURAL class, the structural class of the object. The object is said to belong to this class, zero or more auxiliaries classes, and their super classes. While all of these classes are commonly listed in the objectClass attribute of the entry, one of these classes is the structural object class of the entry. Thus, it is OK for an objectClass attribute to contain inetOrgPerson, organizationalPerson, and person because they inherit one from another to form a single super class chain. That is, inetOrgPerson SUPs organizationPerson SUPs person. On the other hand, it is invalid for both inetOrgPerson and account to be listed in objectClass as inetOrgPerson and account are not part of the same super class chain (unless some other class is also listed with is a subclass of both).
+
+To resolve this problem, one must determine which class will better serve structural object class for the entry, adding this class to the objectClass attribute (if not already present), and remove any other structural class from the entry's objectClass attribute which is not a super class of the structural object class.
+
+Which object class is better depends on the particulars of the situation. One generally should consult the documentation for the applications one is using for help in making the determination.
+
+H3: ldap_add: no structuralObjectClass operational attribute
+
+ldapadd(1) may error:
+
+>      adding new entry "uid=XXX,ou=People,o=campus,c=ru"
+>        ldap_add: Internal (implementation specific) error (80)
+>           additional info: no structuralObjectClass operational attribute
+
+when slapd(8) cannot determine, based upon the contents of the objectClass attribute, what the structural class of the object should be.
+
+While this normally should produce an object class violation error, some versions of slapd(8) contain a minor bug which cause the object class error not to be properly detected. In these versions, slapd(8) instead catches its failure to populate the structuralObjectClass operational attribute (hence the internal error).
+Kurt@OpenLDAP.org
+See also: (Xref) ldap add: invalid structural object class chain
+Kurt@OpenLDAP.org
+
+H3: ldap_add/modify/rename: Naming violation
+
+OpenLDAP's slapd checks for naming attributes and distinguished values consistency, according to RFC 4512.
+
+Naming attributes are those attributeTypes that appear in an entry's RDN; distinguished values are the values of the naming attributes that appear in an entry's RDN, e.g, in
+
+>      cn=Someone+mail=someone@example.com,dc=example,dc=com
+
+the naming attributes are cn and mail, and the distinguished values are Someone and someone@example.com.
+
+OpenLDAP's slapd checks for consistency when:
+
+    * adding an entry
+    * modifying an entry, if the values of the naming attributes are changed
+    * renaming an entry, if the RDN of the entry changes
+
+Possible causes of error are:
+
+    * the naming attributes are not present in the entry; for example:
+
+>                dn: dc=example,dc=com
+>                objectClass: organization
+>                o: Example
+>                # note: "dc: example" is missing
+
+    * the naming attributes are present in the entry, but in the attributeType definition they are marked as:
+          o collective
+          o operational
+          o obsolete
+    * the naming attributes are present in the entry, but the distinguished values are not; for example:
+
+>                dn: dc=example,dc=com
+>                objectClass: domain
+>                dc: foobar
+>                # note: "dc" is present, but the value is not "example"
+
+    * the naming attributes are present in the entry, with the distinguished values, but the naming attributes:
+          o do not have an equality field, so equality cannot be asserted
+          o the matching rule is not supported (yet)
+          o the matching rule is not appropriate
+    * the given distinguished values do not comply with their syntax
+    * other errors occurred during the validation/normalization/match process; this is a catchall: look at previous logs for details in case none of the above apply to your case.
+
+In any case, make sure that the attributeType definition for the naming attributes contains an appropriate EQUALITY field; or that of the superior, if they are defined based on a superior attributeType (look at the SUP field). See RFC 4512 for details.
+ando@sys-net.it, Kurt@OpenLDAP.org
+
+H3: ldap_add/delete/modify/rename: no global superior knowledge
+
+If the target entry name places is not within any of the databases the server is configured to hold and the server has no knowledge of a global superior, the server will indicate it is unwilling to perform the operation and provide the text "no global superior knowledge" as additional text.
+
+Likely the entry name is incorrect, or the server is not properly configured to hold the named entry, or, in distributed directory environments, a default referral was not configured.
+Kurt@OpenLDAP.org
+
+H3: ldap_bind: Insufficient access
+
+Current versions of slapd(8) requires that clients have authentication permission to attribute types used for authentication purposes before accessing them to perform the bind operation. As all bind operations are done anonymously (regardless of previous bind success), the auth access must be granted to anonymous.
+
+In the example ACL below grants the following access:
+
+    * to anonymous users:
+          o permission to authenticate using values of userPassword
+    * to authenticated users:
+          o permission to update (but not read) their userPassword
+          o permission to read any object excepting values of userPassword 
+
+All other access is denied.
+
+>        access to attr=userPassword
+>          by self =w
+>          by anonymous auth
+
+>        access *
+>          by self write
+>          by users read
+
+
+Note that latest versions of slapd(8) will report invalid credentials in cases where the client has insufficient access to complete the operation. This is avoid inappropriate disclosure of the validity of the user's name.
+See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5) (Xref) Access Control
+
+H3: ldap_bind: Invalid credentials
+
+The error usually occurs when the credentials (password) provided does not match the userPassword held in entry you are binding to.
+
+The error can also occur when the bind DN specified is not known to the server.
+
+Check both!
+In addition to the cases mentioned above you should check if the server denied access to userPassword on selected parts of the directory. In fact, slapd always returns "Invalid credentials" in case of failed bind, regardless of the failure reason, since other return codes could reveal the validity of the user's name.
+
+To debug access rules defined in slapd.conf, add "ACL" to log level.
+See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5) (Xref) ldap_bind: No such object
+
+H3: ldap_bind: No such object
+
+This answer is specific to OpenLDAP 1.2 and earlier releases. In later releases, ldap_bind returns (Xref) ldap_bind: Invalid credentials instead.
+'No such object' is only returned by ldap_bind operation in a few special cases. Normally, the server returns (Xref) ldap_bind: Invalid credentials when the entry associated with the bind DN cannot be located.
+This error occurs when binding using the rootdn and the asserted value doesn't match configured password value. Rootpw values must be conform to RFC 2307 format defined for userPassword.
+See also: ldapadd(1) ldapdelete(1) ldapmodify(1) ldapmodrdn(1) ldapsearch(1) slapd.conf(5) (Xref) ldap_bind: Invalid credentials
+
+H3: ldap_bind: Protocol error
+
+There error is generally occurs when the LDAP version requested by the client is not supported by the server.
+
+The OpenLDAP Software 1.x server only accepts version 2 LDAP Bind requests. Note that 1.x server expects U-Mich LDAP, an LDAPv2 variant, to be used. This variant is sometimes referred to as LDAPv2+.
+
+The OpenLDAP Software 2.x server, by default, only accepts version 3 LDAP Bind requests but can be configured to accept a version 2 LDAP Bind request. Note that the 2.x server expects LDAPv3 [RFC4510] to be used when the client requests version 3 and expects a limited LDAPv3 variant (basically, LDAPv3 syntax and semantics in an LDAPv2 PDUs) to be used when version 2 is expected. This variant is also sometimes referred to as LDAPv2+, but differs from the U-Mich LDAP variant in a number of ways.
+
+Use of LDAPv3!
+See also: (Xref) How to configure slapd(8) with LDAPv2 support (for legacy clients)?.
+
+H3: ldap_modify: cannot modify object class
+
+This message is commonly returned when attempting to modify the objectClass attribute in a manner inconsistent with the LDAP/X.500 information model. In particular, it commonly occurs when one tries to change the structure of the object from one class to another, for instance, trying to change an 'apple' into a 'pear' or a 'fruit' into a 'pear'. Such changes are disallowed by the slapd(8) in accordance with LDAP and X.500 restrictions.
+
+To overcome this restriction in 2.3 (and prior releases), one must re-create the object with the desired new structural object class (e.g., delete old object then add new object). In 2.4, support for a new control will (hopefully) be introduced to allow the (authorized) user to request this (and various other model restrictions) be temporarily relaxed.
+
+H3: ldap_sasl_interactive_bind_s: ...
+
+If you intended to bind using a DN and password and get an error from ldap_sasl_interactive_bind_s, you likely forgot to provide a '-x' option to the command. By default, SASL authentication is used. '-x' is necessary to select "simple" authentication.
+Kurt@OpenLDAP.org
+
+H3: ldap_sasl_interactive_bind_s: No such Object
+
+This indicates that LDAP SASL authentication function could not read the Root DSE.
+The error will occur when the server doesn't provide a root DSE. This may be due to access controls.
+
+Note, also, that LDAPv2 servers, such as those OpenLDAP 1.x's slapd(8), do not provide a root DSE. Use -P 2 when LDAPv2 is desired. LDAPv2 servers also do not support SASL binds, so you will need to use a "simple" bind instead.
+Note: SASL bind is the default for all OpenLDAP tools. To force use of "simple" bind, use the "-x" option. Use of "simple" bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
+
+H3: ldap_sasl_interactive_bind_s: No such attribute
+
+This indicates that LDAP SASL authentication function could read the Root DSE but it contained no supportedSASLMechanism attribute.
+The supportedSASLmechanism attribute lists mechanisms currently available. The list may be empty because none of the supported mechanisms are currently available. For example, EXTERNAL is listed only if the client has established its identity by authenticating at a lower level (e.g. TLS).
+Note: the attribute may not be visible due to access controls
+Note: SASL bind is the default for all OpenLDAP tools, e.g. ldapsearch(1), ldapmodify(1). To force use of "simple" bind, use the "-x" option. Use of "simple" bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
+
+H3: ldap_sasl_interactive_bind_s: Unknown authentication method
+
+This indicates that none of the SASL authentication supported by the server are supported by the client, or that they are too weak or otherwise inappropriate for use by the client. Note that the default security options disallows the use of certain mechanisms such as ANONYMOUS and PLAIN (without TLS).
+Note: SASL bind is the default for all OpenLDAP tools. To force use of "simple" bind, use the "-x" option. Use of "simple" bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
+
+H3: ldap_sasl_interactive_bind_s: Local error (82)
+
+Apparently not having forward and reverse DNS entries for the LDAP server can result in this error.
+
+
+H3: ldap_search: Partial results and referral received
+
+This error is returned with the server responses to an LDAPv2 search query with both results (zero or more matched entries) and references (referrals to other servers).
+See also: ldapsearch(1).
+If the updatedn on the replica does not exist, a referral will be returned. It may do this as well if the ACL needs tweaking.
+
+H3: ldap_start_tls: Operations error
+
+ldapsearch(1) and other tools will return
+
+>        ldap_start_tls: Operations error (1)
+>              additional info: TLS already started
+
+when the user (though command line options and/or ldap.conf(5)) has requested TLS (SSL) be started twice. For instance, when specifying both "-H ldaps://server.do.main" and "-ZZ".
+
+H2: Other Errors
+
+H3: ber_get_next on fd X failed errno=34 (Numerical result out of range)
+
+This slapd error generally indicates that the client sent a message that exceeded an administrative limit. See sockbuf_max_incoming and sockbuf_max_incoming_auth configuration directives in slapd.conf(5).
+
+H3: ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)
+
+This message is not indicative of abnormal behavior or error. It simply means that expected data is not yet available from the resource, in this context, a network socket. slapd(8) will process the data once it does becomes available.
+
+H3: daemon: socket() failed errno=97 (Address family not supported)
+
+This message indicates that the operating system does not support one of the (protocol) address families which slapd(8) was configured to support. Most commonly, this occurs when slapd(8) was configured to support IPv6 yet the operating system kernel wasn't. In such cases, the message can be ignored.
+
+H3: GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;
+
+This message means that slapd is not running as root and, thus, it cannot get its Kerberos 5 key from the keytab, usually file /etc/krb5.keytab.
+
+A keytab file is used to store keys that are to be used by services or daemons that are started at boot time. It is very important that these secrets are kept beyond reach of intruders.
+
+That's why the default keytab file is owned by root and protected from being read by others. Do not mess with these permissions, build a different keytab file for slapd instead.
+
+To do this, start kadmin, and enter the following commands:
+
+    * addprinc -randkey ldap/ldap.example.com@EXAMPLE.COM
+    * ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM 
+
+Then, on the shell, do:
+
+    * chown ldap.ldap /etc/openldap/ldap.keytab
+    * chmod 600 /etc/openldap/ldap.keytab 
+
+Now you have to tell slapd (well, actually tell the gssapi library in Kerberos 5 that is invoked by Cyrus SASL) where to find the new keytab. You do this by setting the environment variable KRB5_KTNAME like this:
+
+export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
+
+Set that environment variable on the slapd start script (Red Hat users might find /etc/sysconfig/ldap a perfect place).
+jsanchez@openldap.org, hyc@openldap.org
+This only works if you are using MIT kerberos. It doesn't work with Heimdal, for instance.
+andreas@conectiva.com.br
+In Heimdal there is a function gsskrb5_register_acceptor_identity() that sets the path of the keytab file you want to use. In Cyrus SASL 2 you can add
+
+    keytab: /path/to/file
+
+to your application's SASL config file to use this feature. This only works with Heimdal.
+hyc@openldap.org
+
+H3: access from unknown denied
+
+This related to TCP wrappers. See hosts_access(5) for more information.
+in the log file: "access from unknown denied" This related to TCP wrappers. See hosts_access(5) for more information.
+for example: add the line "slapd: .hosts.you.want.to.allow" in /etc/hosts.allow to get rid of the error.
+
+H3: ldap_read: want=# error=Resource temporarily unavailable
+
+This message occurs normally. It means that pending data is not yet available from the resource, a network socket. slapd(8) will process the data once it becomes available.
+
+H3: `make test' fails
+
+Some times, `make test' fails at the very first test with an obscure message like
+
+    make test
+    make[1]: Entering directory `/ldap_files/openldap-2.2.13/tests'
+    make[2]: Entering directory `/ldap_files/openldap-2.2.13/tests'
+    Initiating LDAP tests for BDB...
+    Cleaning up test run directory leftover from previous run.
+    Running ./scripts/all...
+    >>>>> Executing all LDAP tests for bdb
+    >>>>> Starting test000-rootdse ...
+    running defines.sh
+    Starting slapd on TCP/IP port 9011...
+    Using ldapsearch to retrieve the root DSE...
+    Waiting 5 seconds for slapd to start...
+    ./scripts/test000-rootdse: line 40: 10607 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1
+    Waiting 5 seconds for slapd to start...
+    Waiting 5 seconds for slapd to start...
+    Waiting 5 seconds for slapd to start...
+    Waiting 5 seconds for slapd to start...
+    Waiting 5 seconds for slapd to start...
+    ./scripts/test000-rootdse: kill: (10607) - No such pid
+    ldap_bind: Can't contact LDAP server (-1)
+    >>>>> Test failed
+    >>>>> ./scripts/test000-rootdse failed (exit 1)
+    make[2]: *** [bdb-yes] Error 1
+    make[2]: Leaving directory `/ldap_files/openldap-2.2.13/tests'
+    make[1]: *** [test] Error 2
+    make[1]: Leaving directory `/ldap_files/openldap-2.2.13/tests'
+    make: *** [test] Error 2
+
+or so. Usually, the five lines
+
+    Waiting 5 seconds for slapd to start...
+
+indicate that slapd didn't start at all.
+
+For OpenLDAP 2.2 and later, in tests/testrun/slapd.1.log there is a full log of what slapd wrote while trying to start. The log level can be increased by setting the environment variable SLAPD_DEBUG to the corresponding value; see loglevel in slapd.conf(5) for the meaning of log levels.
+
+A typical reason for this behavior is a runtime link problem, i.e. slapd cannot find some dynamic libraries it was linked against. Try running ldd(1) on slapd (for those architectures that support runtime linking).
+
+There might well be other reasons; the contents of the log file should help clarifying them.
+
+Tests that fire up multiple instances of slapd typically log to tests/testrun/slapd.<n>.log, with a distinct <n> for each instance of slapd; list tests/testrun/ for possible values of <n>.
+ando@sys-net.it
+
+H3: ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed
+
+This seems to be related with wrong ownership of the BDB's dir (/var/lib/ldap) and files.
+chmod -r openldap:openldap /var/lib/ldap fixes it in Debian Etch.
+I don't really know how the wrong permission went into place, but I suspect it has something to do with slapd's starting, no database existing (I had deleted it to get a new, fresh one), and slapd creating one before chroot.
+After a bug report, some insightful feedback, and some amount of testing, i found out that the 'wrong ownership of new files' problem is not with slapd but with slapadd. This happens when one initially populates the Directory.
+Oh, and the right switch of chown is '-R', not '-r'.
+My God! What a mess! The right command to correct this problem is: chown -R /var/lib/ldap
+
+pedrorandrade@gmail.com
+H3: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
+
+Using SASL, when a client contacts LDAP server, the slapd service dies immediately and client gets an error :
+SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
+Then check the slapd service, it stopped.
+This may come from incompatible of using different versions of BerkeleyDB for installing of SASL and installing of OpenLDAP. The problem arises in case of using multiple version of BerkeleyDB. Solution: - Check which version of BerkeleyDB when install Cyrus SASL. - Reinstall OpenLDAP with the version of BerkeleyDB above.
+It was my case and that was the solution I did and it worked :) Hope this gives you some information.
+-- Le Trung Kien 
+
diff --git a/doc/guide/admin/appendix-contrib.sdf b/doc/guide/admin/appendix-contrib.sdf
new file mode 100644 (file)
index 0000000..263537b
--- /dev/null
@@ -0,0 +1,53 @@
+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: OpenLDAP Software Contributions
+
+The following sections attempt to summarize the various contributions in OpenLDAP
+software, as found in {{F:openldap_src/contrib}}
+
+H2: Client APIs
+
+Intro and discuss
+
+H3: ldapc++
+
+Intro and discuss
+
+H3: ldaptcl
+
+Intro and discuss
+
+H2: Overlays
+
+Intro and complete/expand correct names for below:
+
+H3: acl
+H3: addpartial
+H3: allop
+H3: comp_match
+H3: denyop
+H3: dsaschema
+H3: lastmod
+H3: passwd
+H3: proxyOld
+H3: smbk5pwd
+H3: trace
+
+
+H2: Tools
+
+Intro and discuss
+
+H3: Statistic Logging
+
+statslog
+
+H2: SLAPI Plugins
+
+Intro and discuss
+
+H3: addrdnvalues
+
+More
diff --git a/doc/guide/admin/appendix-deployments.sdf b/doc/guide/admin/appendix-deployments.sdf
new file mode 100644 (file)
index 0000000..98eda61
--- /dev/null
@@ -0,0 +1,7 @@
+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Real World OpenLDAP Deployments and Examples
+
+Examples and discussions
diff --git a/doc/guide/admin/appendix-ldap-result-codes.sdf b/doc/guide/admin/appendix-ldap-result-codes.sdf
new file mode 100644 (file)
index 0000000..6276441
--- /dev/null
@@ -0,0 +1,9 @@
+# $OpenLDAP$
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1:  LDAP Result Codes
+
+Port "Appendix A.  LDAP Result Codes" from rfc4511 and add a small explanation
+in addition to current one for ldap*/slap* tools, with the aim of fending off simple, recurring 
+questions on the lists.
diff --git a/doc/guide/admin/appendix-recommended-versions.sdf b/doc/guide/admin/appendix-recommended-versions.sdf
new file mode 100644 (file)
index 0000000..fc5982f
--- /dev/null
@@ -0,0 +1,35 @@
+# $OpenLDAP$
+# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Recommended OpenLDAP Software Dependency Versions
+
+This appendix details the recommended versions of the software 
+that OpenLDAP depends on. 
+
+Please read the {{SECT:Prerequisite software}} section for more 
+information on the following software dependencies.
+
+H2: Dependency Versions
+
+!block table; align=Center; coltags="N,EX,EX"; title="Table 8.5: OpenLDAP Software Dependency Versions"
+Feature|Software|Version
+{{TERM[expand]TLS}}:
+|{{PRD:OpenSSL}}|0.9.7+
+|{{PRD:GnuTLS}}|2.0.1
+{{TERM[expand]SASL}}|{{PRD:Cyrus SASL}}|2.1.21+
+{{TERM[expand]Kerberos}}:
+|{{PRD:Heimdal}}|Version
+|{{PRD:MIT Kerberos}}|Version
+Database Software|{{PRD:Berkeley DB}}:|
+||4.2
+||4.4
+||4.5
+||4.6
+||Note: It is highly recommended to apply the patches from for a given release.
+Threads:
+|POSIX {{pthreads}}|Version
+|Mach {{CThreads}}|Version
+TCP Wrappers|Name|Version
+!endblock
+
index ef1e8fb3bd9d0e55794a3d71ef5dbb70bf15a318..f2fedf6b6258b879a7d2834f6df1b8d85b54c502 100644 (file)
@@ -1,4 +1,4 @@
-personal_ws-1.1 en 1406 
+personal_ws-1.1 en 1451 
 nattrsets
 inappropriateAuthentication
 api
@@ -190,7 +190,7 @@ RELEASEDATE
 baseDN
 basedn
 argv
-GSS
+gss
 schemachecking
 whoami
 WhoAmI
@@ -198,6 +198,7 @@ syslogd
 dataflow
 subentries
 attrpair
+balancer
 BerkeleyDB's
 singleLevel
 entryDN
@@ -206,6 +207,7 @@ includedir
 inplace
 LDAPAPIFeatureInfo
 logbase
+ldapmaster
 ing
 moduleload
 IPC
@@ -230,6 +232,7 @@ reqMod
 ldb
 srcdir
 pwdExpireWarning
+ldd
 localstatedir
 sockbuf
 PENs
@@ -249,6 +252,7 @@ whitespaces
 ISP
 ldp
 monitorInfo
+PDUs
 bjensen
 newPasswd
 irresponsive
@@ -305,10 +309,13 @@ desc
 LTCOMPILE
 bindmethod
 olcDbCheckpoint
+addprinc
 modme
 refreshOnly
 PIII
 pwdPolicySubentry
+supportedSASLmechanism
+supportedSASLMechanism
 FIXME
 realanonymous
 caseExactMatch
@@ -345,6 +352,7 @@ strdup
 gsMatch
 adamson
 UniqueName
+LVL
 ppErrStr
 DESTDIR
 oid
@@ -376,6 +384,7 @@ sharedstatedir
 OLP
 LDFLAGS
 dereferencing
+allop
 errcodep
 xeXBkeFxlZ
 accessor's
@@ -409,6 +418,7 @@ OSI
 subschemaSubentry
 cond
 conf
+rfc
 bvec
 rdn
 ECHOPROMPT
@@ -435,6 +445,7 @@ olcReadonly
 olcReadOnly
 pwdChangedTime
 mySQL
+DITs
 sdf
 suffixmassage
 referralDN
@@ -451,6 +462,7 @@ telephonenumber
 telephoneNumber
 DLDAP
 peernamestyle
+Sep
 SHA
 filename
 rpath
@@ -471,6 +483,7 @@ subdir
 searchAttrDN
 cctrls
 tcp
+kadmin
 strlen
 spellcheck
 ludpp
@@ -482,6 +495,7 @@ SMD
 UCD
 cancelled
 crit
+organizationalUnit
 lucyB
 slp
 rdns
@@ -594,6 +608,7 @@ initgroups
 auditCompare
 GDBM
 DSA's
+dsaschema
 compareFalse
 resultCode
 resultcode
@@ -620,6 +635,7 @@ extparam
 auditWriteObject
 colaligns
 Diffie
+offsite
 attributevalue
 AttributeValue
 SIGTERM
@@ -650,6 +666,7 @@ fd
 LDAPSync
 olcReplicationInterval
 fG
+gidNumber
 fi
 eq
 FIPS
@@ -755,6 +772,8 @@ errSleepTime
 INSTALLFLAGS
 pthread
 pwdHistory
+x's
+Debian
 slen
 errUnsolicitedOID
 dyngroup
@@ -782,6 +801,7 @@ sbindir
 apache's
 noidlen
 monitorContext
+testrun
 resync
 fqdn
 authPassword
@@ -822,7 +842,9 @@ pwdSafeModify
 contrib
 FQDNs
 bjorn
+myldap
 myLDAP
+peercred
 SNMP
 myObjectClass
 thru
@@ -841,9 +863,11 @@ ldapmodrdn
 ldapbis
 attributeoptions
 serverID
+memberOf
 memberof
 pseudorootpw
 CFLAGS
+operationsError
 substr
 pwdAllowUserChange
 rewriteRule
@@ -880,6 +904,7 @@ SSHA
 func
 filterlist
 modifyDN
+jane
 syncuser
 Masarati
 LDAPSyntax
@@ -901,6 +926,8 @@ slapacl
 multiclassing
 monitoredInfo
 LTLINK
+addrdnvalues
+KTNAME
 ETCDIR
 reqId
 setspec
@@ -919,6 +946,7 @@ subr
 cachesize
 olcRootPW
 SSLv
+proxyOld
 domainScope
 LDAPMessage
 LTVERSION
@@ -951,13 +979,16 @@ libtool
 servercredp
 AttributeTypeDescription
 LTFLAGS
+simplebinddn
 authcDN
 TLSCipherSuite
 supportedSASLMechanisms
+rootdse
 rootDSE
 dsaparam
 cachefree
 UMich's
+uidNumber
 schemadir
 attribute's
 extern
@@ -980,10 +1011,12 @@ Supr
 olcDatabaseConfig
 rwxrwxrwx
 aeeiib
+SUPs
 reqStart
 sasldb
 somevalue
 LIBRELEASE
+randkey
 starttls
 StartTLS
 LDAPSchemaExtensionItem
@@ -995,6 +1028,7 @@ backend
 portnumber
 subjectAltName
 errObject
+gsskrb
 valsort
 bervals
 berval's
@@ -1008,6 +1042,7 @@ dbnum
 olcLdapConfig
 sessionlog
 attrset
+organizationPerson
 entryCSN
 strcast
 kbyte
@@ -1027,6 +1062,7 @@ memvfree
 tuple
 superset
 directoryString
+ktadd
 proxyTemplate
 proxytemplate
 wildcards
@@ -1059,6 +1095,7 @@ Subbarao
 setstyle
 subdirectories
 errlist
+addpartial
 slapdn
 uncached
 ldapapiinfo
@@ -1096,6 +1133,7 @@ noprompt
 databasenumber
 hasSubordintes
 URIs
+denyop
 lang
 auditSearch
 ldapdelete
@@ -1120,6 +1158,7 @@ ldbm
 ursula
 LDAPModifying
 slapdconfig
+sysconfig
 dnSubtreeMatch
 olcSaslSecProps
 olcSaslSecprops
@@ -1154,6 +1193,7 @@ sleeptime
 pwdCheckQuality
 msgidp
 pwdAttribute
+chown
 PRNGD
 LDAPRDN
 entryUUIDs
@@ -1182,6 +1222,7 @@ dryrun
 noplain
 exattrs
 Jong
+ldaptcl
 proxied
 firstName
 accesslevel
@@ -1219,11 +1260,13 @@ woid
 numericStringOrderingMatch
 clientctrls
 RetCodes
+ldapc
 pwdAccountLockedTime
 attrtype
 LIBVERSION
 proto
 endif
+logfiles
 reqNewRDN
 ldapi
 notoc
@@ -1333,6 +1376,7 @@ DHAVE
 caseIgnoreSubstringsMatch
 monitorIsShadow
 syncdata
+BDB's
 olcPidFile
 hostport
 backload
@@ -1384,6 +1428,7 @@ objectIdentifierMatch
 Blowfish
 mkln
 numericStringSubstringsMatch
+testgroup
 openssl
 OpenSSL
 ModName
index 61b2aec692241cf127327899ed1f6376f85aab9d..32bbefc5c928f05d609c0e05ed66cc4a5a58f784 100644 (file)
@@ -187,6 +187,15 @@ format}} section).
 Specifies the slapd configuration file that tells where to create
 the indices, what indices to create, etc.
 
+>      -F <slapdconfdirectory>
+
+Specifies a config directory.  If both {{EX:-f}} and {{EX:-F}} are specified, 
+the config file will be read and converted to config  directory format and 
+written to the specified directory.  If neither option is specified, an attempt 
+to read the default config directory will be made before trying to use the 
+default config file. If a valid config directory exists then the default 
+config file is ignored. If dryrun mode is also specified, no conversion will occur.
+
 >      -d <debuglevel>
 
 Turn on debugging, as specified by {{EX:<debuglevel>}}. The debug
index fe8f23bb09693a3407ba1b79c97466c5b972cf76..6c41397b657c8de2ca14830140773923fcc868d8 100644 (file)
@@ -156,9 +156,44 @@ services.
 
 H2: When should I use LDAP?
 
+This is a very good question. In general, you should use a Directory
+server when you require data to be centrally managed, stored and accessible via
+standards based methods. 
+
+Some common examples found throughout the industry are, but not limited to:
+
+* Machine Authentication
+* User Authentication
+* User/System Groups
+* Address book
+* Organization Representation
+* Asset Tracking
+* Telephony Information Store
+* User resource management
+* E-mail address lookups
+* Application Configuration store
+* PBX Configuration store
+* etc.....
+
+There are various {{SECT:Distributed Schema Files}} that are standards based, but
+you can always create your own {{SECT:Schema Specification}}.
+
+There are always new ways to use a Directory and apply LDAP principles to address
+certain problems, therefore there is no simple answer to this question.
+
+If in doubt, join the general LDAP forum for non-commercial discussions and 
+information relating to LDAP at: 
+{{URL:http://www.umich.edu/~dirsvcs/ldap/mailinglist.html}} and ask
 
 H2: When should I not use LDAP?
 
+When you start finding yourself bending the directory to do what you require,
+maybe a redesign is needed. Or if you only require one application to use and 
+manipulate your data (for discussion of LDAP vs RDBMS, please read the 
+{{SECT:LDAP vs RDBMS}} section).
+
+It will become obvious when LDAP is the right tool for the job.
+
 
 H2: How does LDAP work?
 
@@ -238,8 +273,7 @@ sharing of data with other applications.
 
 The short answer is that use of an embedded database and custom indexing system 
 allows OpenLDAP to provide greater performance and scalability without loss of 
-reliability. OpenLDAP, since release 2.1, in its main storage-oriented backends 
-(back-bdb and, since 2.2, back-hdb) uses Berkeley DB concurrent / transactional 
+reliability. OpenLDAP uses Berkeley DB concurrent / transactional 
 database software. This is the same software used by leading commercial 
 directory software.
 
index 5bba1a5f5ab5addf59a87714df44740da11ef4ff..fae8c5a43b122a50996b24436e273c48c8ecf1de 100644 (file)
@@ -10,7 +10,40 @@ discuss how to correctly maintain an OpenLDAP deployment.
 
 H2: Directory Backups
 
-MORE
+Backup strategies largely depend on the amount of change in the database
+and how much of that change an administrator might be willing to lose in a 
+catastrophic failure. There are two basic methods that can be used:
+
+1. Backup the Berkeley database itself and periodically back up the transaction 
+log files:
+
+Berkeley DB produces transaction logs that can be used to reconstruct
+changes from a given point in time. For example, if an administrator were willing to only
+lose one hour's worth of changes, they could take down the server in
+the middle of the night, copy the Berkeley database files offsite, and bring
+the server back online. Then, on an hourly basis, they could force a
+database checkpoint, capture the log files that have been generated in the
+past hour, and copy them offsite. The accumulated log files, in combination
+with the previous database backup, could be used with db_recover to
+reconstruct the database up to the time the last collection of log files was
+copied offsite. This method affords good protection, with minimal space
+overhead.
+
+
+2. Periodically run slapcat and back up the LDIF file:
+
+Slapcat can be run while slapd is active. However, one runs the risk of an
+inconsistent database- not from the point of slapd, but from the point of
+the applications using LDAP. For example, if a provisioning application
+performed tasks that consisted of several LDAP operations, and the slapcat
+took place concurrently with those operations, then there might be
+inconsistencies in the LDAP database from the point of view of that
+provisioning application and applications that depended on it. One must,
+therefore, be convinced something like that won't happen. One way to do that
+would be to put the database in read-only mode while performing the
+slapcat. The other disadvantage of this approach is that the generated LDIF
+files can be rather large and the accumulation of the day's backups could
+add up to a substantial amount of space.
 
 You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8) 
 back-bdb or back-hdb databases.
@@ -19,8 +52,7 @@ back-bdb or back-hdb databases.
 
 For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
 
-MORE
-
+MORE on actual Berkeley DB backups later covering db_recover etc.
 
 H2: Berkeley DB Logs
 
index ec495af9091509d47c3e395cac8649fb1e3d3be7..95f3672606cc497df04017cdd3e86197568d97bb 100644 (file)
@@ -92,10 +92,31 @@ PB:
 !include "appendix-upgrading.sdf"; appendix
 PB:
 
+# Common Errors
+!include "appendix-common-errors.sdf"; appendix
+PB:
+
+# What versions we recommend 
+!include "appendix-recommended-versions.sdf"; appendix
+PB:
+
+# Real Deployments
+!include "appendix-deployments.sdf"; appendix
+PB:
+
+# Contributions
+!include "appendix-contrib.sdf"; appendix
+PB:
+
 # Config file examples
 !include "appendix-configs.sdf"; appendix
 PB:
 
+# LDAP Result Codes
+!include "appendix-ldap-result-codes.sdf"; appendix
+PB:
+
+
 # Terms
 !include "glossary.sdf"; appendix
 PB:
index a21ebcaf5bbafe3e05ed3fb273e4ee934c8c987a..559775b3d16ef9925778b747ff2adafe02bbef68 100644 (file)
@@ -354,17 +354,17 @@ be in the list of admittable log switches:
 >   Conns
 >   BER
 >   Filter
->   Config             (useless)
+>   Config
 >   ACL
 >   Stats
 >   Stats2
 >   Shell
 >   Parse
->   Cache              (deprecated)
->   Index
+>   Sync
 
 These values can be added, replaced or deleted; they affect what 
 messages are sent to the syslog device.
+Custom values could be added by custom modules.
 
 H3: Operations
 
index b153978ece423ff903baf9cd553b8f509795942e..4474501a8e7730f9d3375b70d2a18fb89d703301 100644 (file)
@@ -98,6 +98,71 @@ default when --enable-ldap.
 
 H3: Chaining Configuration
 
+In order to demonstrate how this overlay works, we shall discuss a typical 
+scenario which might be one master server and three Syncrepl slaves. 
+
+On each replica, add this near the top of the file (global), before any database 
+definitions:
+
+>        overlay                    chain
+>        chain-uri                  "ldap://ldapmaster.example.com"
+>        chain-idassert-bind        bindmethod="simple"
+>                                   binddn="cn=Manager,dc=example,dc=com"
+>                                   credentials="<secret>" 
+>                                   mode="self"
+>        chain-tls                  start
+>        chain-return-error         TRUE 
+>        updateref                  "ldap://ldapmaster.example.com/"
+
+The {{B:chain-tls}} statement enables TLS from the slave to the ldap master. 
+The DITs are exactly the same between these machines, therefore whatever user 
+bound to the slave will also exist on the master. If that DN does not have 
+update privileges on the master, nothing will happen.
+
+You will need to restart the slave after these changes. Then, if you are using 
+{{loglevel 256}}, you can monitor an {{ldapmodify}} on the slave and the master.
+
+Now start an {{ldapmodify}} on the slave and watch the logs. You should expect 
+something like:
+
+>        Sep  6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 ACCEPT from IP=143.199.102.216:45181 (IP=143.199.102.216:389)
+>        Sep  6 09:27:25 slave1 slapd[29274]: conn=11 op=0 STARTTLS
+>        Sep  6 09:27:25 slave1 slapd[29274]: conn=11 op=0 RESULT oid= err=0 text=
+>        Sep  6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 TLS established tls_ssf=256 ssf=256
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=people,dc=example,dc=com" method=128
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=1 RESULT tag=97 err=0 text=
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD dn="uid=user1,ou=People,dc=example,dc=com"
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD attr=mail
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=2 RESULT tag=103 err=0 text=
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 op=3 UNBIND
+>        Sep  6 09:27:28 slave1 slapd[29274]: conn=11 fd=31 closed
+>        Sep  6 09:27:28 slave1 slapd[29274]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
+>        Sep  6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_search (0)
+>        Sep  6 09:27:28 slave1 slapd[29274]: syncrepl_entry: uid=user1,ou=People,dc=example,dc=com
+>        Sep  6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_modify (0)
+
+And on the master you will see this:
+
+>        Sep  6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 PROXYAUTHZ dn="uid=user1,ou=people,dc=example,dc=com"
+>        Sep  6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD dn="uid=user1,ou=People,dc=example,dc=com"
+>        Sep  6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD attr=mail
+>        Sep  6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 RESULT tag=103 err=0 text=
+
+Note: You can clearly see the PROXYAUTHZ line on the master, indicating the 
+proper identity assertion for the update on the master. Also note the slave 
+immediately receiving the Syncrepl update from the master.
+
+H3: Handling Chaining Errors
+
+By default, if chaining fails, the original referral is returned to the client
+under the assumption that the client might want to try and follow the referral.
+
+With the following directive however, if the chaining fails at the provider 
+side, the actual error is returned to the client.
+
+>        chain-return-error TRUE
+
 
 H2: Constraints
 
@@ -151,9 +216,81 @@ H3: Dynamic List Configuration
 
 H2: Reverse Group Membership Maintenance
 
+H3: Overview
+
+In some scenarios, it may be desirable for a client to be able to determine
+which groups an entry is a member of, without performing an additional search.
+Examples of this are applications using the {{TERM:DIT}} for access control
+based on group authorization.
+
+The {{B:memberof}} overlay updates an attribute (by default {{B:memberOf}}) whenever
+changes occur to the membership attribute (by default {{B:member}}) of entries of the
+objectclass (by default {{B:groupOfNames}}) configured to trigger updates.
+
+Thus, it provides maintenance of the list of groups an entry is a member of,
+when usual maintenance of groups is done by modifying the members on the group
+entry.
 
 H3: Member Of Configuration
 
+The typical use of this overlay requires just enabling the overlay for a
+specific database. For example, with the following minimal slapd.conf:
+
+>        include /usr/share/openldap/schema/core.schema
+>        include /usr/share/openldap/schema/cosine.schema
+>        modulepath      /usr/lib/openldap
+>        moduleload      memberof.la
+>        authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
+>                "cn=Manager,dc=example,dc=com"
+>        database        bdb
+>        suffix          "dc=example,dc=com"
+>        rootdn          "cn=Manager,dc=example,dc=com"
+>        rootpw          secret
+>        directory       /var/lib/ldap2.4
+>        checkpoint 256 5
+>        index   objectClass   eq
+>        index   uid           eq,sub
+>        
+>        overlay memberof
+
+adding the following ldif:
+
+>        cat memberof.ldif
+>        dn: dc=example,dc=com
+>        objectclass: domain
+>        dc: example
+>        
+>        dn: ou=Group,dc=example,dc=com
+>        objectclass: organizationalUnit
+>        ou: Group
+>        
+>        dn: ou=People,dc=example,dc=com
+>        objectclass: organizationalUnit
+>        ou: People
+>        
+>        dn: uid=test1,ou=People,dc=example,dc=com
+>        objectclass: account
+>        uid: test1
+>        
+>        dn: cn=testgroup,ou=Group,dc=example,dc=com
+>        objectclass: groupOfNames
+>        cn: testgroup
+>        member: uid=test1,ou=People,dc=example,dc=com
+
+Results in the following output from a search on the test1 user:
+
+> # ldapsearch -LL -Y EXTERNAL -H ldapi:/// "(uid=test1)" -b dc=example,dc=com memberOf
+> SASL/EXTERNAL authentication started
+> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
+> SASL SSF: 0
+> version: 1
+> 
+> dn: uid=test1,ou=People,dc=example,dc=com
+> memberOf: cn=testgroup,ou=Group,dc=example,dc=com
+
+Note that the {{B:memberOf}} attribute is an operational attribute, so it must be
+requested explicitly.
+
 
 H2: The Proxy Cache Engine
 
index 83db7c7c138f8e2527f1c294dd47c8fb7017bf8d..920057a592fd3b2f79f420cfc45609392918ff8f 100644 (file)
@@ -17,7 +17,7 @@ This document is considered a part of OpenLDAP Software.  This
 document is subject to terms of conditions set forth in {{SECT:OpenLDAP
 Software Copyright Notices}} and the {{SECT:OpenLDAP Public License}}.
 Complete copies of the notices and associated license can be found
-in Appendix C and D, respectively.
+in Appendix K and L, respectively.
 
 
 P2[notoc] Scope of this Document
index 0df0beab287137560b4c70087bbb8bdbabd8f47c..f37d36367b83bb29fe91c9e00b876fe71b3bac08 100644 (file)
@@ -7,7 +7,7 @@ H1: Replication
 Replicated directories are a fundamental requirement for delivering a 
 resilient enterprise deployment.
 
-OpenLDAP has various configuration options for creating a replicated 
+{{PRD:OpenLDAP}} has various configuration options for creating a replicated 
 directory. The following sections will discuss these.
 
 H2: Replication Strategies
@@ -18,12 +18,12 @@ H3: Push Based
 
 H5: Replacing Slurpd
 
-Slurpd replication has been deprecated in favor of Syncrepl replication and 
-has been completely removed from 2.4.
+{{Slurpd}} replication has been deprecated in favor of Syncrepl replication and 
+has been completely removed from OpenLDAP 2.4.
 
 {{Why was it replaced?}}
 
-The slurpd daemon was the original replication mechanism inherited from 
+The {{slurpd}} daemon was the original replication mechanism inherited from 
 UMich's LDAP and operates in push mode: the master pushes changes to the 
 slaves. It has been replaced for many reasons, in brief:
 
@@ -37,7 +37,7 @@ slaves. It has been replaced for many reasons, in brief:
 
 {{What was it replaced with?}}
 
-Syncrepl.
+Syncrepl
 
 {{Why is Syncrepl better?}}
 
@@ -159,7 +159,7 @@ http://www.openldap.org/lists/openldap-software/200602/msg00064.html
 H3: MirrorMode
 
 MirrorMode is a hybrid configuration that provides all of the consistency
-guarantees of single-master replication while also providing the high
+guarantees of single-master replication, while also providing the high
 availability of multi-master. In MirrorMode two masters are set up to
 replicate from each other (as a multi-master configuration) but an
 external frontend is employed to direct all writes to only one of
@@ -169,6 +169,8 @@ directing all writes to the second master. When a crashed master is
 repaired and restarted it will automatically catch up to any changes
 on the running master and resync.
 
+This is discussed in full in the {{SECT:MirrorMode}} section below
+
 H2: LDAP Sync Replication
 
 The {{TERM:LDAP Sync}} Replication engine, {{TERM:syncrepl}} for
@@ -576,4 +578,104 @@ H2: N-Way Multi-Master
 
 H2: MirrorMode
 
+H3: Arguments for MirrorMode
+
+* Provides a high-availability (HA) solution for directory writes (replicas handle reads)
+* As long as one Master is operational, writes can safely be excepted
+* Master nodes replicate from each other, so they are always up to date and
+can be ready to take over (hot standby)
+* Syncrepl also allows the master nodes to re-synchronize after any downtime
+* Delta-Syncrepl can be used
+
+
+H3: Arguments against MirrorMode
+
+* MirrorMode is not what is termed as a Multi-Master solution. This is because 
+writes have to go to one of the mirror nodes at a time
+* MirrorMode can be termed as Active-Active Hot-Standby, therefor an external 
+server (slapd in proxy mode) or device (hardware load balancer) to manage which 
+master is currently active
+* While syncrepl can recover from a completely empty database, slapadd is much 
+faster
+* Does not provide faster or more scalable write performance (neither could 
+  any Multi-Master solution)
+* Backups are managed slightly differently
+- If backing up the Berkeley database itself and periodically backing up the 
+transaction log files, then the same member of the mirror pair needs to be 
+used to collect logfiles until the next database backup is taken 
+- To ensure that both databases are consistent, each database might have to be 
+put in read-only mode while performing a slapcat. 
+- When using slapcat, the generated LDIF files can be rather large. This can 
+happen with a non-MirrorMode deployment also.
+
+H3: MirrorMode Configuration
+
+MirrorMode configuration is actually very easy. If you have ever setup a normal
+slapd syncrepl provider, then the only change is the directive:
+
+>       mirrormode  on
+
+You also need to make you the {{rid}} of each mirror node pair is different and
+that the {{provider}} syncrepl directive points to the other mirror pair.
+
+H4: Mirror Node Configuration
+
+This is the same as the {{SECT:Set up the provider slapd}} section, referencing
+{{SECT:delta-syncrepl replication}} if using {{delta-syncrepl}}.
+
+Here's a specific cut down example:
+
+MirrorMode node 1:
+
+>       # syncrepl directives\r
+>       syncrepl      rid=1\r
+>                     provider=ldap://ldap-rid2.example.com\r
+>                     bindmethod=simple\r
+>                     binddn="cn=mirrormode,dc=example,dc=com"\r
+>                     credentials=mirrormode\r
+>                     searchbase="dc=example,dc=com"\r
+>                     schemachecking=on\r
+>                     type=refreshAndPersist\r
+>                     retry="60 +"\r
+>       \r
+>       mirrormode on
+
+MirrorMode node 2:
+
+>       # syncrepl directives\r
+>       syncrepl      rid=2\r
+>                     provider=ldap://ldap-rid1.example.com\r
+>                     bindmethod=simple\r
+>                     binddn="cn=mirrormode,dc=example,dc=com"\r
+>                     credentials=mirrormode\r
+>                     searchbase="dc=example,dc=com"\r
+>                     schemachecking=on\r
+>                     type=refreshAndPersist\r
+>                     retry="60 +"\r
+>       \r
+>       mirrormode on
+
+It's simple really; each MirrorMode node is setup {{B:exactly}} the same, except
+that the {{B:provider}} directive is set to point to the other MirrorMode node.
+
+H4: Failover Configuration
+
+There are generally 2 choices for this; 1.  Hardware proxies/load-balancing or 
+dedicated proxy software, 2. using a Back-LDAP proxy as a syncrepl provider
+
+MORE HERE and a nice PICTURE
+
+
+H4: Normal Consumer Configuration
+
+This is exactly the same as the {{SECT:Set up the consumer slapd}} section. It
+can either setup in normal {{SECT:syncrepl replication}} mode, or in 
+{{SECT:delta-syncrepl replication}} mode.
+
+H3: MirrorMode Summary
+
+Hopefully you will now have a directory architecture that provides all of the 
+consistency guarantees of single-master replication, whilst also providing the 
+high availability of multi-master replication.
+
 
index 54a4145c80201bfb5afde33108baeea745e54bea..fda57ae21cf02a3b2df6db3a01e4757e6f472e90 100644 (file)
@@ -19,6 +19,17 @@ in the manual page.  This section details a few commonly used options.
 This option specifies an alternate configuration file for slapd.
 The default is normally {{F:/usr/local/etc/openldap/slapd.conf}}.
 
+>      -F <slapd-config-directory>
+
+Specifies the slapd configuration directory. The default is {{F:/usr/local/etc/openldap/slapd.d}}
+
+If both {{EX:-f}} and {{EX:-F}} are specified, the config file will be read and converted 
+to config directory format and written to the specified directory.  
+If neither option is specified, slapd will attempt to read the default config 
+directory before trying to use the default config file. If a valid config 
+directory exists then the default config file is ignored. All of the slap tools 
+that use the config options observe this same behavior.
+
 >      -h <URLs>
 
 This option specifies alternative listener configurations.  The
@@ -37,7 +48,7 @@ numeric.
 >      -n <service-name>
 
 This option specifies the service name used for logging and
-other purposes.  The default service name is {{EX:slapd}}.
+other purposes. The default service name is {{EX:slapd}}.
 
 >      -l <syslog-local-user>
 
index 8b80c0014ed659de120c6c0d104f5ed7e5722284..ed482fd4619995fc1a8fd9fd15a66124b17ae78b 100644 (file)
@@ -1472,3 +1472,8 @@ E: 49.    olcDbDirectory: /usr/local/var/openldap-data-net
 E: 50. olcRootDN: "cn=Manager,dc=example,dc=com"
 E: 51. olcDbIndex: objectClass eq
 E: 52. olcAccess: to * by users read
+
+
+H2: Converting from slapd.conf(8) to a {{B:cn=config}} directory format
+
+Discuss slap* -f slapd.conf -F slapd.d/  (man slapd-config)
index 18544c7fa4079e48b01d33d88e96937c358575d4..43d77c3d89e14249a5d573ae3db69a7673032a4f 100644 (file)
@@ -5,9 +5,11 @@
 H1: Troubleshooting
 
 If you're having trouble using OpenLDAP, get onto the
-OpenLDAP-Software mailing list
+OpenLDAP-Software mailing list, or:
 
-Browse the list archives at {{URL:http://www.openldap.org/lists/}} 
+* Browse the list archives at {{URL:http://www.openldap.org/lists/#archives}} 
+* Search the FAQ at {{URL:http://www.openldap.org/faq/}}
+* Search the Issue Tracking System at {{URL:http://www.openldap.org/its/}}
 
 Chances are the problem has been solved and explained in detail many times before.
 
@@ -16,14 +18,7 @@ H2: User or Software errors?
 More often than not, an error is caused by a configuration problem or a misunderstanding
 of what you are trying to implement and/or achieve. 
 
-Sometimes you may encounter an actual OpenLDAP bug, in which case please visit 
-our Issue Tracking system {{URL:http://www.openldap.org/its/}} and report it there, 
-providing as much information as possible.
-
-Note: Our Issue Tracking system is {{B:NOT}} for OpenLDAP {{B:Support}}, please join our
-mailing Lists: {{URL:http://www.openldap.org/lists/}} for that
-
-We will now attempt to discuss common user errors
+We will now attempt to discuss common user errors.
 
 H2: Checklist
 
@@ -51,6 +46,25 @@ posting to the list, or in the rare circumstances of reporting a bug.
 .{{S: }}
 +{{B: Have your certificates expired?}}
 
+H2: OpenLDAP Bugs
+
+Sometimes you may encounter an actual OpenLDAP bug, in which case please visit 
+our Issue Tracking system {{URL:http://www.openldap.org/its/}} and report it.
+However, make sure it's not already a known bug or a common user problem.
+
+* bugs in historic versions of OpenLDAP will not be considered;
+* bugs in released versions that are no longer present in HEAD code, 
+either because they have been fixed or because they no longer apply, 
+will not be considered as well;
+* bugs in distributions of OpenLDAP software that are not related to the 
+software as provided by OpenLDAP will not be considered; in those cases please 
+refer to the distributor.
+
+Note: Our Issue Tracking system is {{B:NOT}} for OpenLDAP {{B:Support}}, please join our
+mailing Lists: {{URL:http://www.openldap.org/lists/}} for that.
+
+The information you should provide in your bug report is discussed in our FAQ-O-MATIC at
+{{URL:http://www.openldap.org/faq/data/cache/59.html}}
 
 H2: 3rd party software error
 
@@ -80,6 +94,7 @@ might want to try out some of the following to track down the cause of your prob
   information useful to list members on issues
 * Running {{slapd -d -1}} can often track down fairly simple issues, such as 
   missing schemas and incorrect file permissions for the {{slapd}} user to things like certs
+* Check your logs for errors, as discussed at {{URL:http://www.openldap.org/faq/data/cache/358.html}}
 
 H2: Commercial Support
 
index 54dd7e695182e52ce1e8742e70a1f36014759ecb..28baa9624f60405ce18476607b585a7828970f22 100644 (file)
@@ -146,7 +146,7 @@ if you are using the default LOCAL4 logging you could try:
 
 For syslog-ng, add or modify the following line in {{syslog-ng.conf}}:
 
-   options { sync(n); };
+>   options { sync(n); };
 
 where n is the number of lines which will be buffered before a write.