From: Kurt Zeilenga Date: Sat, 24 Apr 1999 23:11:27 +0000 (+0000) Subject: Change examples: s/U-Mich/OpenLDAP/ X-Git-Tag: OPENLDAP_SLAPD_BACK_LDAP~137 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=e7e807f2933d0590269a737ca01b13311fc7eef6;p=openldap Change examples: s/U-Mich/OpenLDAP/ --- diff --git a/doc/guide/dbtools.sdf b/doc/guide/dbtools.sdf index 7ca6b9f36d..d296f30a89 100644 --- a/doc/guide/dbtools.sdf +++ b/doc/guide/dbtools.sdf @@ -36,7 +36,7 @@ entries are to be held by this database. You should set this 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: @@ -78,28 +78,34 @@ E: index default none 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 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 @@ -122,7 +128,7 @@ entries are to be held by this database. You should set this 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: @@ -131,7 +137,7 @@ E: directory 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 @@ -348,7 +354,7 @@ program, however, produces an LDIF format that includes 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., @@ -367,20 +373,20 @@ Multiple entries within the same LDIF file are separated by 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 @@ -502,14 +508,14 @@ data to an LDIF file are: .{{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: }} diff --git a/doc/guide/intro.sdf b/doc/guide/intro.sdf index 3c5cd89743..27da553be1 100644 --- a/doc/guide/intro.sdf +++ b/doc/guide/intro.sdf @@ -56,7 +56,7 @@ more {{I:values}}. 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 @@ -85,8 +85,8 @@ distinguished name, which is constructed by taking the name of the entry 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 @@ -98,7 +98,7 @@ by a search filter. Information can be requested from each entry that matches 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 diff --git a/doc/guide/quickstart.sdf b/doc/guide/quickstart.sdf index 495836661f..aef7397047 100644 --- a/doc/guide/quickstart.sdf +++ b/doc/guide/quickstart.sdf @@ -55,7 +55,7 @@ type: .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=, c=US"}} .{{EX:rootdn "cn=, o=, c=US"}} @@ -101,7 +101,7 @@ type: +{{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=, 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 "*" diff --git a/doc/guide/replication.sdf b/doc/guide/replication.sdf index df55d7bd7e..a915227c7f 100644 --- a/doc/guide/replication.sdf +++ b/doc/guide/replication.sdf @@ -5,11 +5,11 @@ H1: Replication with slurpd 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. @@ -70,13 +70,13 @@ timestamp, the DN of the entry being modified, and a series 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 @@ -87,7 +87,7 @@ E: - 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: - @@ -264,16 +264,16 @@ To configure slapd to generate a replication logfile, you 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 @@ -312,17 +312,17 @@ error and the replication record to a reject file. The reject 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 @@ -333,7 +333,7 @@ E: - 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: - @@ -362,10 +362,10 @@ To use one-shot mode, specify the name of the rejection 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 diff --git a/doc/guide/slapdconfig.sdf b/doc/guide/slapdconfig.sdf index da657b104f..34e37c2067 100644 --- a/doc/guide/slapdconfig.sdf +++ b/doc/guide/slapdconfig.sdf @@ -164,10 +164,10 @@ cannot find a local database to handle a request. \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. @@ -317,7 +317,7 @@ operations on this database. \Example: -E: rootdn "cn=Manager, o=U of M, c=US" +E: rootdn "cn=Manager, o=OpenLDAP Project, c=US" H4: rootkrbname @@ -329,7 +329,7 @@ to provide replication service (see Section 10). \Example: -E: rootkrbname admin@umich.edu +E: rootkrbname admin@openldap.org H4: rootpw @@ -352,9 +352,9 @@ definition. \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 @@ -576,9 +576,9 @@ E: dn= 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: @@ -705,40 +705,40 @@ The following example shows the use of a regular expression 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 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 @@ -820,18 +820,18 @@ E: 1. # example config file - global configuration section 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}} @@ -839,18 +839,18 @@ attribute is to be protected from unauthorized access. 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 @@ -859,7 +859,7 @@ E: 20.# ldbm access control definitions 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