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:
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
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
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
projects / openldap / commitdiff