to the DN of the root of the subtree you are trying to create.
For example
-E: suffix "o=University of Michigan, c=US"
+E: suffix "dc=OpenLDAP, dc=org"
You should be sure to specify a directory where the index
files should be created:
See Section 4 on the configuration file for more details on
this option. Once you have configured things to your liking,
start up slapd, connect with your LDAP client, and start
-adding entries. For example, to add a the U of M entry
+adding entries. For example, to add a the organizational entry
followed by a Postmaster entry using the {{I:ldapadd}} tool, you
could create a file called {{EX:/tmp/newentry}} with the contents:
-E: o=University of Michigan, c=US
+E: dc=OpenLDAP, dc=org
+E: objectClass=dcObject
E: objectClass=organization
-E: o=University of Michigan
-E: description=University of Michigan at Ann Arbor
-E: cn=Postmaster, o=University of Michigan, c=US
+E: dc=OpenLDAP
+E: o=OpenLDAP
+E: o=OpenLDAP Project
+E: o=OpenLDAP Foundation
+E: description=The OpenLDAP Foundation
+E: description=The OpenLDAP Project
+E:
+E: cn=Postmaster, dc=OpenLDAP, dc=org
E: objectClass=organizationalRole
E: cn=Postmaster
-E: description=U of M postmaster - postmaster@umich.edu
+E: description=OpenLDAP Postmaster <Postmaster@OpenLDAP.org>
and then use a command like this to actually create the
entry:
-E: ldapadd -f /tmp/newentry -D "cn=Manager, o=University of
-E: Michigan, c=US" -w secret
+E: ldapadd -f /tmp/newentry -D \
+ "cn=Manager, dc=OpenLDAP, dc=org" -w secret
The above command assumes that you have set {{EX: rootdn}} to
-"cn=Manager, o=University of Michigan, c=US" and {{EX: rootpw}}
+"cn=Manager, dc=OpenLDAP, dc=org" and {{EX: rootpw}}
to "secret".
H2: Creating a database off-line
to the DN of the root of the subtree you are trying to create.
For example
-E: suffix "o=University of Michigan, c=US"
+E: suffix "dc=OpenLDAP, dc=org"
You should be sure to specify a directory where the index
files should be created:
For example:
-E: directory /usr/local/openldap-slapd
+E: directory /usr/local/var/openldap
Next, you probably want to increase the size of the in-core
cache used by each open index file. For best performance
A line may be continued by starting the next line with a
single space or tab character. e.g.,
-E: dn: cn=Barbara J Jensen, o=University of Michigan, c=US
+E: dn: cn=Barbara J Jensen, dc=OpenLDAP, dc=org
Multiple attribute values are specified on separate lines. e.g.,
blank lines. Here's an example of an LDIF file containing
three entries.
-E: dn: cn=Barbara J Jensen, o=University of Michigan, c=US
+E: dn: cn=Barbara J Jensen, dc=OpenLDAP, dc=org
E: cn: Barbara J Jensen
E: cn: Babs Jensen
E: objectclass: person
E: sn: Jensen
E:
E:
-E: dn: cn=Bjorn J Jensen, o=University of Michigan, c=US
+E: dn: cn=Bjorn J Jensen, dc=OpenLDAP, dc=org
E: cn: Bjorn J Jensen
E: cn: Bjorn Jensen
E: objectclass: person
E: sn: Jensen
E:
-E: dn: cn=Jennifer J Jensen, o=University of Michigan, c=US
+E: dn: cn=Jennifer J Jensen, dc=OpenLDAP, dc=org
E: cn: Jennifer J Jensen
E: cn: Jennifer Jensen
E: objectclass: person
.{{EX: MASTER}}
.{{EX: 000001}}
.{{EX: }}
-.{{EX: o=University of Michigan}}
+.{{EX: o=OpenLDAP}}
.{{EX: objectClass= top & organization & domainRelatedObject &\}}
.{{EX: quipuObject & quipuNonLeafObject}}
-.{{EX: l= Ann Arbor, Michigan}}
-.{{EX: st= Michigan}}
-.{{EX: o= University of Michigan & UMICH & UM & U-M & U of M}}
-.{{EX: description= The University of Michigan at Ann Arbor}}
-.{{EX: associatedDomain= umich.edu}}
+.{{EX: l= Redwood City, California}}
+.{{EX: st= California}}
+.{{EX: o=OpenLDAP Project & OpenLDAP Foundation & OpenLDAP}}
+.{{EX: description=The OpenLDAP Project}}
+.{{EX: associatedDomain= openldap.org}}
.{{EX: masterDSA= c=US@cn=Woolly Monkey}}
.{{EX: }}
The types are typically mnemonic strings, like "{{EX:cn}}" for common
name, or "{{EX:mail}}" for email address. The values depend on what type of
attribute it is. For example, a {{EX:mail}} attribute might contain the value
-"{{EX:babs@umich.edu}}". A {{EX:jpegPhoto}} attribute would contain
+"{{EX:babs@openldap.org}}". A {{EX:jpegPhoto}} attribute would contain
a photograph in binary JPEG/JFIF format.
{{I:How is the information arranged?}} In LDAP, directory entries are arranged in
itself (called the relative distinguished name, or RDN) and concatenating the
names of its ancestor entries. For example, the entry for Barbara Jensen in
the example above has an RDN of "{{EX:cn=Barbara J Jensen}}" and a DN of
-"{{EX:cn=Barbara J Jensen, o=U of M, c=US}}". The full DN format is described in
-RFC 1779, "A String Representation of Distinguished Names."
+"{{EX:cn=Barbara J Jensen, o=OpenLDAP Project, c=US}}". The full DN format is
+described in RFC 1779, "A String Representation of Distinguished Names."
{{I:How is the information accessed?}} LDAP defines operations for interrogating
and updating the directory. Operations are provided for adding and deleting
the criteria.
For example, you might want to search the entire directory subtree below the
-University of Michigan for people with the name Barbara Jensen, retrieving
+OpenLDAP Project for people with the name Barbara Jensen, retrieving
the email address of each entry found. LDAP lets you do this easily. Or you
might want to search the entries directly below the c=US entry for
organizations with the string "Acme" in their name, and that have a fax
.enter the following lines into it. See Section 5 for more details on this
.file.
.
-.{{EX:referral ldap://ldap.itd.umich.edu}}
+.{{EX:referral ldap://ldap.openldap.org}}
.{{EX:database ldbm}}
.{{EX:suffix "o=<YOUR ORGANIZATION>, c=US"}}
.{{EX:rootdn "cn=<YOUR NAME>, o=<YOUR ORGANIZATION>, c=US"}}
+{{B:See if it works}}.You can use any LDAP client to do this, but our
.example uses the ldapsearch tool.
.
-.{{EX:ldapsearch -h 127.0.0.1 'objectclass=*'}}
+.{{EX:ldapsearch -h 127.0.0.1 -b 'o=<YOUR ORGANIZATION>, c=US' 'objectclass=*'}}
.
.This command will search for and retrieve every entry in the database.
.Note the use of single quotes around the filter, which prevents the "*"
In certain configurations, a single slapd instance may be
insufficient to handle the number of clients requiring
directory service via LDAP. It may become necessary to
-run more than one slapd instance. At the University of
-Michigan, for instance, there are four slapd servers, one
-master and three slaves. A DNS lookup of the name
-ldap.itd.umich.edu returns the IP addresses of those four
-servers, distributing the load among them. This
+run more than one slapd instance. Many sites,
+for instance, there are multiple slapd servers, one
+master and one or slaves. DNS can be setup such that
+a lookup of ldap.openldap.org returns the IP addresses
+of these servers, distributing the load among them. This
master/slave arrangement provides a simple and effective
way to increase capacity, availability and reliability.
of lines which specify the changes to make. In the
example below, "Barbara Jensen" has replaced a line of
her multiLineDescription. The change is to be propagated
-to the slapd instance running on truelies.rs.itd.umich.edu.
+to the slapd instance running on slave.openldap.org
The lastModifiedBy and lastModified Time attributes are
also propagated to the slave slapd.
-E: replica: truelies.rs.itd.umich.edu:389
+E: replica: slave.openldap.org:389
E: time: 809618633
-E: dn: cn=Barbara Jensen, ou=People, o=University of Michigan,c=US
+E: dn: cn=Barbara Jensen, ou=People, o=OpenLDAP Project,c=US
E: changetype: modify
E: delete: multiLineDescription
E: multiLineDescription: I enjoy sailing in my spare time
E: delete: lastModifiedBy
E: -
E: add: lastModifiedBy
-E: lastModifiedBy: cn=Barbara Jensen, ou=People, o=University of Michigan, c=US
+E: lastModifiedBy: cn=Barbara Jensen, ou=People, o=OpenLDAP Project, c=US
E: -
E: delete: lastModifiedTime
E: -
add a "{{EX: replica}}" configuration option to the master slapd's
config file. For example, if we wish to propagate changes
to the slapd instance running on host
-truelies.rs.itd.umich.edu:
+slave.openldap.org:
-E: replica host=truelies.rs.itd.umich.edu:389
-E: binddn="cn=Replicator, o=U of M, c=US"
+E: replica host=slave.openldap.org:389
+E: binddn="cn=Replicator, o=OpenLDAP Project, c=US"
E: bindmethod=simple credentials=secret
In this example, changes will be sent to port 389 (the
standard LDAP port) on host truelies. The slurpd process
will bind to the slave slapd as
-"cn=Replicator, o=U of M, c=US"
+"cn=Replicator, o=OpenLDAP Project, c=US"
using simple authentication with password "secret".
Note that the entry given by the binddn= directive must
exist in the slave slapd's database (or be the rootdn
file is located in the same directory with the per-replica
replication logfile, and has the same name, but with the
string ".rej" appended. For example, for a replica running
-on host truelies.rs.itd.umich.edu, port 389, the reject file, if it
+on host slave.openldap.org, port 389, the reject file, if it
exists, will be named
-E: /usr/tmp/truelies.rs.itd.umich.edu:389.
+E: /usr/tmp/replog.slave.openldap.org:389.
A sample rejection log entry follows:
E: ERROR: No such attribute
-E: replica: truelies.rs.itd.umich.edu:389
+E: replica: slave.openldap.org:389
E: time: 809618633
-E: dn: cn=Barbara Jensen, ou=People, o=University of Michigan, c=US
+E: dn: cn=Barbara Jensen, ou=People, o=OpenLDAP Project, c=US
E: changetype: modify
E: delete: multiLineDescription
E: multiLineDescription: I enjoy sailing in my spare time
E: delete: lastModifiedBy
E: -
E: add: lastModifiedBy
-E: lastModifiedBy: cn=Barbara Jensen, ou=People, o=University of Michigan, c=US
+E: lastModifiedBy: cn=Barbara Jensen, ou=People, o=OpenLDAP Project, c=US
E: -
E: delete: lastModifiedTime
E: -
log on the command line as the argument to the -r flag,
and specify one-shot mode with the -o flag. For example,
to process the rejection log file
-/usr/tmp/replog.truelies.rs.itd.umich.edu:389 and exit, use the
+/usr/tmp/replog.slave.openldap.org:389 and exit, use the
command
-E: slurpd -r /usr/tmp/truelies.rs.itd.umich.edu:389 -o
+E: slurpd -r /usr/tmp/replog.slave.openldap.org:389 -o
H2: Replication from a slapd directory server to an X.500 DSA
\Example:
-E: referral ldap://ldap.itd.umich.edu
+E: referral ldap://ldap.openldap.org
This will refer non-local queries to the LDAP server at the
-University of Michigan. Smart LDAP clients can re-ask their
+OpenLDAP Project. Smart LDAP clients can re-ask their
query at that server, but note that most of these clients are
only going to know how to handle simple LDAP URLs that
contain a host part and optionally a distinguished name part.
\Example:
-E: rootdn "cn=Manager, o=U of M, c=US"
+E: rootdn "cn=Manager, o=OpenLDAP Project, c=US"
H4: rootkrbname <kerberosname>
\Example:
-E: rootkrbname admin@umich.edu
+E: rootkrbname admin@openldap.org
H4: rootpw <password>
\Example:
-E: suffix "o=University of Michigan, c=US"
+E: suffix "o=OpenLDAP Project, c=US"
-Queries with a DN ending in "o=University of Michigan, c=US"
+Queries with a DN ending in "o=OpenLDAP Project, c=US"
will be passed to this backend.
Note: when the backend to pass a query to is selected, slapd
Note: The DN pattern specified should be "normalized",
meaning that there should be no extra spaces, and commas
should be used to separate components. An example
-normalized DN is "cn=Babs Jensen,o=University of
-Michigan,c=US". An example of a non-normalized DN is
-"cn=Babs Jensen; o=University of Michigan, c=US".
+normalized DN is "cn=Babs Jensen,o=OpenLDAP Project,c=US".
+An example of a non-normalized DN is
+"cn=Babs Jensen; o=OpenLDAP Project, c=US".
Or, entries may be selected by a filter matching some
attribute(s) in the entry:
to select the entries by DN in two access directives where
ordering is significant.
-E: access to dn=".*, o=U of M, c=US"
+E: access to dn=".*, o=OpenLDAP Project, c=US"
E: by * search
E: access to dn=".*, c=US"
E: by * read
Read access is granted to entries under the c=US subtree,
-except for those entries under the "o=University of Michigan,
+except for those entries under the "o=OpenLDAP Project,
c=US" subtree, to which search access is granted. If the
order of these access directives was reversed, the
-U-M-specific directive would never be matched, since all
-U-M entries are also c=US entries.
+OpenLDAP-specific directive would never be matched, since all
+OpenLDAP entries are also c=US entries.
The next example again shows the importance of ordering,
both of the access directives and the "by" clauses. It also
shows the use of an attribute selector to grant access to a
specific attribute and various <who> selectors.
-E:access to dn=".*, o=U of M, c=US" attr=homePhone
+E:access to dn=".*, o=OpenLDAP Project, c=US" attr=homePhone
E: by self write
-E: by dn=".*, o=U of M, c=US" search
-E: by domain=.*\.umich\.edu read
+E: by dn=".*, o=OpenLDAP Project, c=US" search
+E: by domain=.*\.openldap\.org read
E: by * compare
-E:access to dn=".*, o=U of M, c=US"
+E:access to dn=".*, o=OpenLDAP Project, c=US"
E: by self write
-E: by dn=".*, o=U of M, c=US" search
+E: by dn=".*, o=OpenLDAP Project, c=US" search
E: by * none
-This example applies to entries in the "o=U of M, c=US"
+This example applies to entries in the "o=OpenLDAP Project, c=US"
subtree. To all attributes except homePhone, the entry itself
-can write them, other U-M entries can search by them,
+can write them, other OpenLDAP entries can search by them,
anybody else has no access. The homePhone attribute is
-writable by the entry, searchable by other U-M entries,
+writable by the entry, searchable by other OpenLDAP entries,
readable by clients connecting from somewhere in the
-umich.edu domain, and comparable by everybody else.
+OpenLDAP.org domain, and comparable by everybody else.
Sometimes it is useful to permit a particular DN to add or
remove itself from an attribute. For example, if you would like to
E: 2. include /usr/local/etc/slapd.at.conf
E: 3. include /usr/local/etc/slapd.oc.conf
E: 4. schemacheck on
-E: 5. referral ldap://ldap.itd.umich.edu
+E: 5. referral ldap://ldap.openldap.org
Line 1 is a comment. Lines 2 and 3 include other config files
containing attribute and object class definitions, respectively.
Line 4 turns on schema checking. The {{EX: referral}} option on line 5
means that queries not local to one of the databases defined
below will be referred to the LDAP server running on the
-standard port (389) at the host {{EX: ldap.itd.umich.edu}}.
+standard port (389) at the host {{EX: ldap.openldap.org}}.
The next section of the configuration file defines an LDBM
backend that will handle queries for things in the
-"o=University of Michigan, c=US" portion of the tree. The
+"o=OpenLDAP Project, c=US" portion of the tree. The
database is to be replicated to two slave slapds, one on
truelies, the other on judgmentday. Indexes are to be
maintained for several attributes, and the {{EX: userPassword}}
E: 1. # ldbm definition for the U-M database
E: 2. database ldbm
-E: 3. suffix "o=University of Michigan, c=US"
-E: 4. directory /usr/local/ldbm-umich
-E: 6. rootdn "cn=Manager, o=University of Michigan, c=US"
+E: 3. suffix "o=OpenLDAP Project, c=US"
+E: 4. directory /usr/local/var/openldap
+E: 6. rootdn "cn=Manager, o=OpenLDAP Project, c=US"
E: 7. rootpw secret
-E: 8. replogfile /usr/local/ldbm-umich/slapd.replog
-E: 9. replica host=truelies.rs.itd.umich.edu:389
-E: 10. binddn="cn=Replicator, o=U of M, c=US"
+E: 8. replogfile /usr/local/var/openldap/slapd.replog
+E: 9. replica host=slave1.openldap.org:389
+E: 10. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
E: 11. bindmethod=simple credentials=secret
-E: 12.replica host=judgmentday.rs.itd.umich.edu
-E: 13. binddn="cn=Replicator, o=U of M, c=US"
+E: 12.replica host=slave2.openldap.org
+E: 13. binddn="cn=Replicator, o=OpenLDAP Project, c=US"
E: 14. bindmethod=kerberos
-E: 15. srvtab=/etc/srvtab.judgmentday
+E: 15. srvtab=/etc/srvtab.slave2
E: 16.# ldbm indexed attribute definitions
E: 17.index cn,sn,uid pres,eq,approx,sub
E: 18.index objectclass pres,eq
E: 21.defaultaccess read
E: 22.access to attr=userpassword
E: 23. by self write
-E: 24. by dn="cn=Admin, o=University of Michigan, c=US" write
+E: 24. by dn="cn=Admin, o=OpenLDAP Project, c=US" write
E: 25. by * compare
Line 1 is a comment. The start of the database definition is
projects / openldap / commitdiff