use 'modern' logging style

minimal note on overlay stacking

doc/guide/admin/overlays.sdf

@@ -261,7 +261,7 @@ 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.
+{{loglevel stats}} (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:
@@ -855,6 +855,14 @@ 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 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)
+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).
+
 
 H3: Example Scenarios
 

doc/guide/admin/troubleshooting.sdf

@@ -90,7 +90,7 @@ H2: Debugging {{slapd}}(8)
 After reading through the above sections and before e-mailing the OpenLDAP lists, you
 might want to try out some of the following to track down the cause of your problems:
 
-* Loglevel 256 is generally a good first loglevel to try for getting 
+* Loglevel stats (256) is generally a good first loglevel to try for getting 
   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

doc/guide/admin/tuning.sdf

@@ -111,7 +111,7 @@ H2: Logging
 
 H3: What log level to use
 
-The default of {{loglevel 256}} is really the best bet. There's a corollary to 
+The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to 
 this when problems *do* arise, don't try to trace them using syslog. 
 Use the debug flag instead, and capture slapd's stderr output. syslog is too 
 slow for debug tracing, and it's inherently lossy - it will throw away messages when it
@@ -131,7 +131,7 @@ and attribute {{foo}} does not have an equality index. If you see a lot of these
 messages, you should add the index. If you see one every month or so, it may
 be acceptable to ignore it.
 
-The default syslog level is 256 which logs the basic parameters of each
+The default syslog level is stats (256) which logs the basic parameters of each
 request; it usually produces 1-3 lines of output. On Solaris and systems that
 only provide synchronous syslog, you may want to turn it off completely, but
 usually you want to leave it enabled so that you'll be able to see index