(ITS#7341) Ordered list error in overlays.sdf and attr in access-control.sdf

diff --git a/doc/guide/admin/access-control.sdf b/doc/guide/admin/access-control.sdf
index 16ad9d18652077c46f0ff0d16c310dad99018c24..4cfba9444b08760aea3b91e242c1e7758d22909a 100644 (file)
--- a/doc/guide/admin/access-control.sdf
+++ b/doc/guide/admin/access-control.sdf
@@ -1,5 +1,5 @@
-# $OpenLDAP$
-# Copyright 1999-2012 The OpenLDAP Foundation, All Rights Reserved.
+# $OpenLDAP: pkg/openldap-guide/admin/access-control.sdf,v 1.9 2009-06-19 19:12:12 ghenry Exp $
+# Copyright 1999-2009 The OpenLDAP Foundation, All Rights Reserved.
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 
 H1: Access Control
@@ -25,9 +25,8 @@ rights (i.e. auth, search, compare, read and write) on everything and anything.
 As a consequence, it's useless (and results in a performance penalty) to explicitly 
 list the {{rootdn}} among the {{<by>}} clauses.
 
-The following sections will describe Access Control Lists in greater depth and 
-follow with some examples and recommendations. See {{slapd.access}}(5) for
-complete details.
+The following sections will describe Access Control Lists in more details and 
+follow with some examples and recommendations. 
 
 H2: Access Control via Static Configuration
 
@@ -327,7 +326,7 @@ attribute and various {{EX:<who>}} selectors.
 >    access to dn.subtree="dc=example,dc=com" attrs=homePhone
 >        by self write
 >        by dn.children="dc=example,dc=com" search
->        by peername.regex=IP=10\..+ read
+>        by peername.regex=IP:10\..+ read
 >    access to dn.subtree="dc=example,dc=com"
 >        by self write
 >        by dn.children="dc=example,dc=com" search
@@ -665,7 +664,7 @@ attribute and various {{EX:<who>}} selectors.
 >    olcAccess: to dn.subtree="dc=example,dc=com" attrs=homePhone
 >        by self write
 >        by dn.children=dc=example,dc=com" search
->        by peername.regex=IP=10\..+ read
+>        by peername.regex=IP:10\..+ read
 >    olcAccess: to dn.subtree="dc=example,dc=com"
 >        by self write
 >        by dn.children="dc=example,dc=com" search
@@ -781,7 +780,7 @@ H3: Basic ACLs
 
 Generally one should start with some basic ACLs such as:
 
->    access to attr=userPassword
+>    access to attrs=userPassword
 >        by self =xw
 >        by anonymous auth
 >        by * none
@@ -827,7 +826,7 @@ This ACL grants read permissions to authenticated users while denying others
 
 H3: Controlling rootdn access
 
-You could specify the {{rootdn}} in {{slapd.conf}}(5) or {{slapd.d}} without 
+You could specify the {{rootdn}} in {{slapd.conf}}(5) or {[slapd.d}} without 
 specifying a {{rootpw}}. Then you have to add an actual directory entry with 
 the same dn, e.g.:
 
@@ -877,7 +876,7 @@ One can then grant access to the members of this this group by adding appropriat
 >        by group.exact="cn=Administrators,dc=example,dc=com" write  
 >        by * auth
 
-Like by {{dn}} clauses, one can also use {{expand}} to expand the group name 
+Like by {[dn}} clauses, one can also use {{expand}} to expand the group name 
 based upon the regular expression matching of the target, that is, the to {{dn.regex}}). 
 For instance,
 
@@ -1154,7 +1153,7 @@ To get what we wanted the file has to read:
 
 The general rule is: "special access rules first, generic access rules last"
 
-See also {{slapd.access}}(5), loglevel 128 and {{slapacl}}(8) for debugging
+See also {{slapd.access}}(8), loglevel 128 and {{slapacl}}(8) for debugging
 information.
 
 
@@ -1323,7 +1322,7 @@ The end result is that when Jane accesses John's entry, she will be granted
 write access to the specified attributes. Better yet, this will happen to any
 entry she accesses which has Mary as the manager.
 
-This is all cool and nice, but perhaps gives too much power to secretaries. Maybe we need to further
+This is all cool and nice, but perhaps gives to much power to secretaries. Maybe we need to further
 restrict it. For example, let's only allow executive secretaries to have this power:
 
 > access to dn.exact="uid=john,ou=people,dc=example,dc=com"

diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf
index 89835558c23437ede0ad40804cf81028bebcf186..0cb28c26f8f6ad3f2662301e714dfb3af3182d13 100644 (file)
--- a/doc/guide/admin/overlays.sdf
+++ b/doc/guide/admin/overlays.sdf
@@ -1,5 +1,5 @@
-# $OpenLDAP$
-# Copyright 2007-2012 The OpenLDAP Foundation, All Rights Reserved.
+# $OpenLDAP: pkg/openldap-guide/admin/overlays.sdf,v 1.47 2009-12-15 12:09:35 ghenry Exp $
+# Copyright 2007-2009 The OpenLDAP Foundation, All Rights Reserved.
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 
 H1: Overlays
@@ -326,7 +326,7 @@ H3: Read-Back of Chained Modifications
 
 Occasionally, applications want to read back the data that they just wrote.
 If a modification requested to a shadow server was silently chained to its 
-provider, an immediate read could result in receiving data not yet synchronized.  
+producer, an immediate read could result in receiving data not yet synchronized.  
 In those cases, clients should use the {{B:dontusecopy}} control to ensure 
 they are directed to the authoritative source for that piece of data.
 
@@ -555,7 +555,7 @@ In {{F:slapd.conf}}(5):
 >       ...
 >       overlay dynlist
 >       dynlist-attrset groupOfURLs labeledURI member
-+
+
 +Note: We must include the {{F:dyngroup.schema}} file that defines the
 +{{F:groupOfURLs}} objectClass used in this example.
 
@@ -613,7 +613,8 @@ 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
@@ -724,13 +725,13 @@ design and implementation details.
 H3: Proxy Cache Configuration
 
 The cache configuration specific directives described below must
-appear after a {{EX:overlay pcache}} directive within a
-{{EX:"database meta"}} or {{EX:"database ldap"}} section of
+appear after a {{EX:overlay proxycache}} directive within a
+{{EX:"database meta"}} or {{EX:database ldap}} section of
 the server's {{slapd.conf}}(5) file.
 
 H4: Setting cache parameters
 
-> pcache <DB> <maxentries> <nattrsets> <entrylimit> <period>
+> proxyCache <DB> <maxentries> <nattrsets> <entrylimit> <period>
 
 This directive enables proxy caching and sets general cache
 parameters.  The <DB> parameter specifies which underlying database
@@ -738,7 +739,7 @@ is to be used to hold cached entries.  It should be set to
 {{EX:bdb}} or {{EX:hdb}}.  The <maxentries> parameter specifies the
 total number of entries which may be held in the cache.  The
 <nattrsets> parameter specifies the total number of attribute sets
-(as specified by the {{EX:pcacheAttrset}} directive) that may be
+(as specified by the {{EX:proxyAttrSet}} directive) that may be
 defined.  The <entrylimit> parameter specifies the maximum number of
 entries in a cacheable query.  The <period> specifies the consistency
 check period (in seconds).  In each period, queries with expired
@@ -746,16 +747,16 @@ TTLs are removed.
 
 H4: Defining attribute sets
 
-> pcacheAttrset <index> <attrs...>
+> proxyAttrset <index> <attrs...>
 
 Used to associate a set of attributes to an index. Each attribute
 set is associated with an index number from 0 to <numattrsets>-1.
-These indices are used by the pcacheTemplate directive to define
+These indices are used by the proxyTemplate directive to define
 cacheable templates.
 
 H4: Specifying cacheable templates 
 
-> pcacheTemplate <prototype_string> <attrset_index> <TTL>
+> proxyTemplate <prototype_string> <attrset_index> <TTL>
 
 Specifies a cacheable template and the "time to live" (in sec) <TTL>
 for queries belonging to the template. A template is described by
@@ -763,7 +764,7 @@ its prototype filter string and set of required attributes identified
 by <attrset_index>.
 
 
-H4: Example for slapd.conf
+H4: Example
 
 An example {{slapd.conf}}(5) database section for a caching server
 which proxies for the {{EX:"dc=example,dc=com"}} subtree held
@@ -773,60 +774,27 @@ at server {{EX:ldap.example.com}}.
 >      suffix          "dc=example,dc=com" 
 >      rootdn          "dc=example,dc=com" 
 >      uri             ldap://ldap.example.com/
->      overlay pcache
->      pcache         bdb 100000 1 1000 100
->      pcacheAttrset  0 mail postaladdress telephonenumber 
->      pcacheTemplate (sn=) 0 3600
->      pcacheTemplate (&(sn=)(givenName=)) 0 3600
->      pcacheTemplate (&(departmentNumber=)(secretary=*)) 0 3600
+>      overlay proxycache
+>      proxycache    bdb 100000 1 1000 100
+>      proxyAttrset  0 mail postaladdress telephonenumber 
+>      proxyTemplate (sn=) 0 3600
+>      proxyTemplate (&(sn=)(givenName=)) 0 3600
+>      proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600
 >
 >      cachesize 20
 >      directory ./testrun/db.2.a
 >      index       objectClass eq
 >      index       cn,sn,uid,mail  pres,eq,sub
 
-H4: Example for slapd-config
-
-The same example as a LDIF file for back-config for a caching server
-which proxies for the {{EX:"dc=example,dc=com"}} subtree held
-at server {{EX:ldap.example.com}}.
-
->   dn: olcDatabase={2}ldap
->   objectClass: olcDatabaseConfig
->   objectClass: olcLDAPConfig
->   olcDatabase: {2}ldap
->   olcSuffix: dc=example,dc=com
->   olcRootDN: dc=example,dc=com
->   olcDbURI: "ldap://ldap.example.com"
->   
->   dn: olcOverlay={0}pcache
->   objectClass: olcOverlayConfig
->   objectClass: olcPcacheConfig
->   olcOverlay: {0}pcache
->   olcPcache: bdb 100000 1 1000 100
->   olcPcacheAttrset: 0 mail postalAddress telephoneNumber
->   olcPcacheTemplate: "(sn=)" 0 3600 0 0 0
->   olcPcacheTemplate: "(&(sn=)(givenName=))" 0 3600 0 0 0
->   olcPcacheTemplate: "(&(departmentNumber=)(secretary=))" 0 3600
->   
->   dn: olcDatabase={0}hdb
->   objectClass: olcHdbConfig
->   objectClass: olcPcacheDatabase
->   olcDatabase: {0}hdb
->   olcDbDirectory: ./testrun/db.2.a
->   olcDbCacheSize: 20
->   olcDbIndex: objectClass eq
->   olcDbIndex: cn,sn,uid,mail  pres,eq,sub
-
 
 H5: Cacheable Queries
 
 A LDAP search query is cacheable when its filter matches one of the
-templates as defined in the "pcacheTemplate" statements and when it references
+templates as defined in the "proxyTemplate" statements and when it references
 only the attributes specified in the corresponding attribute set. 
 In the example above the attribute set number 0 defines that only the
 attributes: {{EX:mail postaladdress telephonenumber}} are cached for the following
-pcacheTemplates.
+proxyTemplates.
 
 H5: Examples:
 
@@ -834,7 +802,7 @@ H5: Examples:
 >      Attrs: mail telephoneNumber
 
     is cacheable, because it matches the template {{EX:(&(sn=)(givenName=))}} and its
-    attributes are contained in pcacheAttrset 0.
+    attributes are contained in proxyAttrset 0.
 
 >      Filter: (&(sn=Richard*)(telephoneNumber))
 >      Attrs: givenName 
@@ -1042,8 +1010,6 @@ If we removed all users from the directory who are a member of this group, then
 would be a single member in the group: {{F:cn=admin,dc=example,dc=com}}. This is the
 {{F:refint_nothing}} parameter kicking into action so that the schema is not violated.
 
-The {{rootdn}} must be set for the database as refint runs as the {{rootdn}} to gain access to
-make its updates.  The {{rootpw}} does not need to be set.
 
 H3: Further Information
 
@@ -1209,6 +1175,11 @@ First we configure the overlay in the normal manner:
 >       pidfile     ./slapd.pid
 >       argsfile    ./slapd.args
 >       
+>       modulepath  /usr/local/libexec/openldap
+>       moduleload  back_bdb.la
+>       moduleload  back_ldap.la
+>       moduleload  translucent.la
+>       
 >       database    bdb
 >       suffix      "dc=suretecsystems,dc=com"
 >       rootdn      "cn=trans,dc=suretecsystems,dc=com"