minor cleanup

doc/guide/admin/appendix-changes.sdf

@@ -179,6 +179,10 @@ H3: New features in slapd
 * monitoring of back-{b,h}db: cache fill-in, non-indexed searches,
 * session tracking control (draft-wahl-ldap-session)
 * subtree delete in back-sql (draft-armijo-ldap-treedelete)
+* sorted values in multivalued attributes for faster matching 
+* lightweight dispatcher for greater throughput under heavy load and on
+multiprocessor machines. (33% faster than 2.3 on AMD quad-socket dual-core server.)
+
 
 H3: New features in libldap
 

doc/guide/admin/overlays.sdf

@@ -10,10 +10,15 @@ and as callbacks on top of backend responses to alter their behavior.
 
 Overlays may be compiled statically into {{slapd}}, or when module support
 is enabled, they may be dynamically loaded. Most of the overlays
-are only allowed to be configured on individual databases, but some
-may also be configured globally.
+are only allowed to be configured on individual databases.
 
-Essentially, they represent a means to:
+Some can be stacked on the {{EX:frontend}} as well, for global use. This means that
+they can be executed after a request is parsed and validated, but right before the 
+appropriate database is selected. The main purpose is to affect operations 
+regardless of the database they will be handled by, and, in some cases, 
+to influence the selection of the database by massaging the request DN. 
+
+Essentially, overlays represent a means to:
 
     * customize the behavior of existing backends without changing the backend 
       code and without requiring one to write a new custom backend with 
@@ -21,6 +26,14 @@ Essentially, they represent a means to:
     * write functionality of general usefulness that can be applied to 
       different backend types
 
+When using {{slapd.conf}}(5), overlays that are configured before any other
+databases are considered global, as mentioned above. In fact they are implicitly
+stacked on top of the {{EX:frontend}} database. They can also be explicitly
+configured as such:
+
+>        database frontend
+>        overlay <overlay name>
+
 Overlays are usually documented by separate specific man pages in section 5; 
 the naming convention is
 
@@ -35,7 +48,7 @@ Official overlays are located in
 >        servers/slapd/overlays/
 
 That directory also contains the file slapover.txt, which describes the 
-rationale of the overlay implementation, and may serve as guideline for the 
+rationale of the overlay implementation, and may serve as a guideline for the 
 development of custom overlays.
 
 Contribware overlays are located in
@@ -45,13 +58,7 @@ Contribware overlays are located in
 along with other types of run-time loadable components; they are officially 
 distributed, but not maintained by the project.
 
-They can be stacked on the frontend as well; this means that they can be 
-executed after a request is parsed and validated, but right before the 
-appropriate database is selected. The main purpose is to affect operations 
-regardless of the database they will be handled by, and, in some cases, 
-to influence the selection of the database by massaging the request DN. 
-
-All the current overlays in 2.4 are listed and described in detail in the 
+All the current overlays in OpenLDAP are listed and described in detail in the 
 following sections.
 
 
@@ -239,8 +246,8 @@ 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:
+On each replica, add this near the top of the {{slapd.conf}}(5) file
+(global), before any database definitions:
 
 >        overlay                    chain
 >        chain-uri                  "ldap://ldapmaster.example.com"
@@ -260,8 +267,10 @@ 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 stats}} (256), you can monitor an {{ldapmodify}} on the slave and the master.
+You will need to restart the slave after these {{slapd.conf}} changes.
+Then, if you are using {{loglevel stats}} (256), you can monitor an
+{{ldapmodify}} on the slave and the master. (If you're using {{cn=config}}
+no restart is required.)
 
 Now start an {{ldapmodify}} on the slave and watch the logs. You should expect 
 something like:
@@ -914,10 +923,10 @@ H2: Overlay Stacking
 H3: Overview
 
 Overlays can be stacked, which means that more than one overlay
-can be instantiated for each database, or for the frontend.
-As a consequence, each overlays function is called, if defined,
+can be instantiated for each database, or for the {{EX:frontend}}.
+As a consequence, each overlay's function is called, if defined,
 when overlay execution is invoked.
-Multiple overlays are executed in reverse order (it's a stack, all in all)
+Multiple overlays are executed in reverse order (as a stack)
 with respect to their definition in slapd.conf (5), or with respect
 to their ordering in the config database, as documented in slapd-config (5).
 

doc/guide/admin/replication.sdf

@@ -702,7 +702,7 @@ 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 accepted 
+* As long as one Master is operational, writes can safely be accepted
 * 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