Ajcody-LDAP-Topics

LDAP Topics

   KB 2704        Last updated on 2016-06-20  




0.00
(0 votes)
24px ‎  - This is Zeta Alliance Certified Documentation. The content has been tested by the Community.


Actual LDAP Topics Homepage

Please see Ajcody-LDAP-Topics

LDAP Error Codes

A nice reference on ldap errors codes:

Working With ldap Commands - The Easy Way

Tired of working with long ldap strings on the CLI with ldapmodify, ldapsearch, ldapdelete.

zimbra$ source ~/bin/zmshutil 
zimbra$ zmsetvars 

You can now use this string syntax to make things a little easier.

ldapCOMMAND -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password ACTION

Anonymous Binds

For new installations of ZCS 6.0, anonymous searches of the directory are disabled. (Bug 15378) When you upgrade to 6.0, anonymous searches of the directory are enabled, matching previous release behavior.

  • To disable anonymous search after upgrading, on each LDAP server, as zimbra run
    • /opt/zimbra/libexec/zmldapanon -d
  • To enable anonymous access at any point after it is disabled, on each LDAP server run
    • /opt/zimbra/libexec/zmldapanon -e

Important: Enabling anonymous binds is not recommended as it may expose data not intended for anonymous access

Ref:

Searching For Account In LDAP

To do ldapsearch for the account, and see if there are any related entries in ldap.

su - zimbra
source ~/bin/zmshutil
zmsetvars
ldapsearch -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password "mail=USER@DOMAIN.com"

To just dump the whole thing [to grep and so forth]:

su - zimbra
source ~/bin/zmshutil
zmsetvars
ldapsearch -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password


Searching For Accounts On A Particular Mailstore

To do ldapsearch for the account, and see if there are any related entries in ldap.

su - zimbra
source ~/bin/zmshutil
zmsetvars
ldapsearch -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password "zimbraMailHost=YOURMAILSTORE.COM"


Other LDAP Search Example

See http://wiki.zimbra.com/wiki/ShanxT-LDAP-CheatSheet

ldapsearch over 636 from non-ZCS linux client

From your ZCS ldap server, you'll want to get the following information:

zmhostname
zmlocalconfig -s | egrep 'ldap_master_url|ldap_url|ldap_starttls_supported|ldap_port|zimbra_ldap_password'

Replace the details below as followed: ZMHOSTNAME with zmhostname's output above, PASSWORD with zimbra_ldap_password from above. Also adjust the -b 'ou=people,dc=DOMAIN,dc=com' to reflect your domain string. The other variables should state port 636 if your setup for ldaps [ref: How_to_enable_ldaps Now try the following now on the ldap server below to confirm ldapsearch works :

ldapsearch -x -H ldaps://ZMHOSTNAME:636 -D uid=zimbra,cn=admins,cn=zimbra -w PASSWORD -LLL -b 'ou=people,dc=DOMAIN,dc=com' -Z

Now, example uses a centos/rhe machine and therefor I use yum vs apt-get, let's setup the non-ZCS linux machine to test the query:

yum install openldap-clients 
vi /etc/openldap/ldap.conf  
  * add 
    TLS_REQCERT allow 

And now the search test from the non-zcs linux host [I provide a couple lines of the output in the example below]. Remember to replace the ZMHOSTNAME and PASSWORD values below with your variables and the -b 'ou=people,dc=DOMAIN,dc=com' to reflect your domain string. :

 ldapsearch -x -H ldaps://ZMHOSTNAME:636 -D uid=zimbra,cn=admins,cn=zimbra -w PASSWORD -LLL -b 'ou=people,dc=DOMAIN,dc=com' -Z
 
   ldap_start_tls: Operations error (1) 
   additional info: TLS already started 
   dn: ou=people,dc=DOMAIN,dc=com    
   objectClass: organizationalRole 
   ou: people 
   cn: people 

Deleting An Account In LDAP

Via zmprov

Caution - this should normally only be done under guidance or request by support.

This will delete the account from ldap and not from the db (mysql). It also retains the mail store and index data:

zmprov -l da <USER@DOMAIN.com>

Via ldapdelete

Caution - this should normally only be done under guidance or request by support.

One way:

su - zimbra
source ~/bin/zmshutil
zmsetvars
ldapsearch -LLL -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password "mail=ajcody@zimbra.DOMAIN.com" dn
    dn: uid=ajcody,ou=people,dc=zimbra,dc=DOMAIN,dc=com
ldapdelete -r -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password uid=ajcody,ou=people,dc=zimbra,dc=DOMAIN,dc=com

Once done, you should be able to add or remove the account using 'zmprov ca' command.

db_recover For OpenLdap DB In /opt/zimbra/openldap-data

Caution - this should normally only be done under guidance or request by support.

For ZCS 5.x

This will cause an impact to your user base, since we'll be stopping the ldap service.

su - zimbra
cd /opt/zimbra/openldap-data
ls -la
  **Notice the __db.00# files**
ldap stop
/opt/zimbra/sleepycat/bin/db_recover
ls -la
  **Notice the __db.00# files are gone**
ldap start

Attempt To Cover Versions Higher Than ZCS5 - I've yet to confirm the below

ZCS 6.X.X
# su - zimbra
$ ldap stop
$ cd /opt/zimbra/openldap-data
$ /opt/zimbra/sleepycat/bin/db_recover

and also, if this is a ldap master:

$ cd /opt/zimbra/openldap-data/accesslog/db
$ /opt/zimbra/sleepycat/bin/db_recover
ZCS 7.0.x

unconfirmed

7.1.x
# su - zimbra
$ ldap stop
$ cd /opt/zimbra/data/ldap/hdb/db
$ /opt/zimbra/bdb/bin/db_recover
7.1.x Ldap Replica & Mailstore - Case Notes

Error customer had in /var/log/zimbra.log after /opt/zimbra partition hit 100% usage.

Aug 25 15:51:12 SERVER postfix/smtpd[20470]: NOQUEUE: reject: MAIL from 
localhost.localdomain[127.0.0.1]: 452 4.3.1 Insufficient system storage; 
proto=ESMTP helo=<localhost>
Aug 25 15:51:12 SERVER amavis[16494]: (16494-03) smtp resp to MAIL (pip): 
452 4.3.1 Insufficient system storage

and later....

Aug 25 17:34:27 SERVER slapd[5627]: @(#) $OpenLDAP: slapd 2.4.26 (Sep 7 2011 
12:24:16) 
$#012#011build@zre-rhel6-64.eng.vmware.com:/home/build/p4/HELIX/ThirdParty/openldap/openldap-2.4.26.5z/servers/slapd
Aug 25 17:34:27 SERVER slapd[5628]: hdb_db_open: database "": unclean shutdown 
detected; attempting recovery.
Aug 25 17:34:27 SERVER slapd[5628]: bdb(): file unknown has LSN 146/8895192, 
past end of log at 146/7885578
Aug 25 17:34:27 SERVER slapd[5628]: bdb(): Commonly caused by moving a database 
from one database environment
Aug 25 17:34:27 SERVER slapd[5628]: bdb(): to another without clearing the database 
LSNs, or by removing all of
Aug 25 17:34:27 SERVER slapd[5628]: bdb(): the log files from a database environment
Aug 25 17:34:28 SERVER slapd[5628]: bdb(): file id2entry.bdb has LSN 146/8895192, 
past end of log at 146/7887443
Aug 25 17:34:28 SERVER slapd[5628]: bdb(): Commonly caused by moving a database 
from one database environment
Aug 25 17:34:28 SERVER slapd[5628]: bdb(): to another without clearing the database 
LSNs, or by removing all of
Aug 25 17:34:28 SERVER slapd[5628]: bdb(): the log files from a database environment
Aug 25 17:34:28 SERVER slapd[5628]: bdb(): /opt/zimbra/data/ldap/hdb/db/id2entry.bdb: 
unexpected file type or format
Aug 25 17:34:28 SERVER slapd[5628]: hdb_db_open: database "": 
db_open(/opt/zimbra/data/ldap/hdb/db/id2entry.bdb) failed: Invalid argument (22).
Aug 25 17:34:28 SERVER slapd[5628]: backend_startup_one (type=hdb, suffix=""): 
bi_db_open failed! (22)
Aug 25 17:34:28 SERVER slapd[5628]: bdb_db_close: database "": alock_close failed
Aug 25 17:34:28 SERVER slapd[5628]: slapd stopped.
Aug 25 17:34:32 SERVER slapd[5631]: @(#) $OpenLDAP: slapd 2.4.26 (Sep 7 2011 12:24:16) 
$#012#011build@zre-rhel6-64.eng.vmware.com:/home/build/p4/HELIX/ThirdParty/openldap/openldap-2.4.26.5z/servers/slapd
Aug 25 17:34:32 SERVER slapd[5632]: bdb(): file id2entry.bdb has LSN 146/8895192, 
past end of log at 146/7887499
Aug 25 17:34:32 SERVER slapd[5632]: bdb(): Commonly caused by moving a database 
from one database environment
Aug 25 17:34:32 SERVER slapd[5632]: bdb(): to another without clearing the database 
LSNs, or by removing all of
Aug 25 17:34:32 SERVER slapd[5632]: bdb(): the log files from a database environment
Aug 25 17:34:32 SERVER slapd[5632]: bdb(): /opt/zimbra/data/ldap/hdb/db/id2entry.bdb: 
unexpected file type or format
Aug 25 17:34:32 SERVER slapd[5632]: hdb_db_open: database "": 
db_open(/opt/zimbra/data/ldap/hdb/db/id2entry.bdb) failed: Invalid argument (22).
Aug 25 17:34:32 SERVER slapd[5632]: backend_startup_one (type=hdb, suffix=""): 
bi_db_open failed! (22)
Aug 25 17:34:32 SERVER slapd[5632]: bdb_db_close: database "": alock_close failed
Aug 25 17:34:32 SERVER slapd[5632]: slapd stopped.

Error from the command line when attempting zmcontrol start or ldap start:

Starting ldap...Done.
Failed.
Failed to start slapd. Attempting debug start to determine error.
hdb_db_open: database "": db_open(/opt/zimbra/data/ldap/hdb/db/id2entry.bdb) 
failed: Invalid argument (22).
backend_startup_one (type=hdb, suffix=""): bi_db_open failed! (22)
bdb_db_close: database "": alock_close failed 

Attempted ldap db recovery.

su - zimbra
zmcontrol stop
cd /opt/zimbra/data/ldap/hdb/db
/opt/zimbra/bdb/bin/db_recover

That didn't work.

Removal of the alock [/opt/zimbra/data/ldap/hdb/db/alock] file also didn't work, ldap start failed with same error and created a new alock file.

Proceeded with some of the steps taken from this reference: http://wiki.zimbra.com/wiki/LDAP_data_import_export

cd /opt/zimbra/data/ldap/
mv hdb hdb.old

Create the new directory structure :

mkdir -p hdb/db
mkdir -p hdb/logs
mv hdb hdb.old
ldap start

Confirmed ldap started ok and also checked replica status.

/opt/zimbra/libexec/zmreplchk
Code: 0 Status: In Sync

zimbra.log looked good.

zmcontrol start

And the rest of the zimbra services came up cleanly.

Ldap Restore

To find the LDAP session labels type -lbs.

zmrestoreldap -lbs

Restore the complete LDAP directory server [example]

zmrestoreldap -lb full20061130135236

ldapmodify Examples

Removing An Alias That Is Also Primary Account

Bug Reference:

External Reference:

Description of problem:

When I try to remove the alias that matches the primary account with zmprov or to delete the Alias in the web console it fails. And attempt to restore the account to another name [ -ca -pre old_] fails as well [Error occurred: Read timed out].

An attempt to rename the primary account doesn't avoid the issue with the matching alias name.

[zimbra@mail root]$ zmprov ra USER@DOMAIN.com USER_OLD@DOMAIN.com
[zimbra@mail root]$ zmprov raa USER_OLD@DOMAIN.com USER@DOMAIN.com
ERROR: account.NO_SUCH_ALIAS (no such alias: USER@DOMAIN.com)
[zimbra@mail root]$ zmprov ra USER_OLD@DOMAIN.com USER@DOMAIN.com

Also, whenever I rename the account, the alias gets renamed with it. Even when using the zimbraID to rename the account.

The following will confirm the issue as it will show a zimbraMailAlias matching a mail variable.

su - zimbra
source ~/bin/zmshutil
zmsetvars
ldapsearch -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password "mail=USER@DOMAIN.com"
##shows us something like this##
[cut]
# USER, people, DOMAIN.com
dn: uid=USER,ou=people,dc=DOMAIN,dc=com
[cut]
mail: USER@DOMAIN.com
mail: USER_Alias1@DOMAIN.com
mail: USER_Alias2@DOMAIN.com
mail: USER_Alias3@DOMAIN.com
zimbraMailAlias: USER@DOMAIN.com
zimbraMailAlias: USER_Alias1@DOMAIN.com
zimbraMailAlias: USER_Alias2@DOMAIN.com
zimbraMailAlias: USER_Alias3@DOMAIN.com
[cut]

To use ldapmodify to replace the aliases, you would construct a statement like this:

[if you haven't already done this in the current shell]
su - zimbra
source ~/bin/zmshutil
zmsetvars
[end]
ldapmodify -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password
dn: uid=USER,ou=people,dc=DOMAIN,dc=com
changetype: modify
replace: zimbraMailAlias
zimbraMailAlias: USER_Alias1@DOMAIN.com
zimbraMailAlias: USER_Alias2@DOMAIN.com
zimbraMailAlias: USER_Alias3@DOMAIN.com
[ctrl-D executes this change and drops you to prompt]
zmprov flushCache account USER@DOMAIN.com

Notice the absence of the zimbraMailAlias: USER@DOMAIN.com variable.

To use ldapmodify to delete ALL aliases, you would construct a statement like this:

[if you haven't already done this in the current shell]
su - zimbra
source ~/bin/zmshutil
zmsetvars
[end]
ldapmodify -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password
dn: uid=USER,ou=people,dc=DOMAIN,dc=com
changetype: modify
delete: zimbraMailAlias
[ctrl-D executes this change and drops you to prompt]
zmprov flushCache account USER@DOMAIN.com

You can also place the edit's in a text file and run it like:

[if you haven't already done this in the current shell]
su - zimbra
source ~/bin/zmshutil
zmsetvars
[end]
ldapmodify -x -H $ldap_master_url -D $zimbra_ldap_userdn -w $zimbra_ldap_password -f fix-account.ldif


zmprov flushCache account USER@DOMAIN.com

If you were to do multiple operations, you would need to include the - marker. For example:

userprompt> ldapmodify -D bindDN -w password -h server1
 dn: cn=Niels Nelissen,ou=people,dc=example,dc=com
 changetype: modify
 delete: telephonenumber
 -
 add: manager
 manager: cn=Peter Petersen,ou=people,dc=example,dc=com
 ^D
 userprompt>

db_recover For OpenLdap Accesslog DB In /opt/zimbra/openldap-data/accesslog/db

Caution - this should normally only be done under guidance or request by support.

For ZCS 5.x Only

This will cause an impact to your user base, since we'll be stopping the ldap service.

For replication issues.

Steps Removed At This Time.

Re-indexing Openldap

Caution - this should normally only be done under guidance or request by support.

This will cause an impact to your user base, since we'll be stopping the ldap service.

su - zimbra
cd /opt/zimbra/openldap-data
ldap stop
/opt/zimbra/openldap/sbin/slapindex -f /opt/zimbra/conf/slapd.conf

Purging Logs From /opt/zimbra/openldap-data/logs

Caution - this should normally only be done under guidance or request by support.

DB_CONFIG sets the log variable, it should be /opt/zimbra/openldap-data/logs .

ldap stop
db_checkpoint -1 -h /opt/zimbra/openldap-data
db_archive -h /opt/zimbra/openldap-data
rm <logs listed from db_archive>
ldap start

What Does - connection_read : no connection! - In zimbra.log Indicate

Developer responses I've had on this question:

  • One ldap server is seeing it and others aren't, then confirm the logging levels are set the same
  • This informative message indicates that a client disconnected without sending an unbind request first. It is quite common and certainly something to ignore.

Note, customer also gave me feedback that they ended up seeing this as a result of they way their load-balancers were operating.

Change LDAP Port On Zimbra

It is recommend that there is no other LDAP service running on the ZCS besides Zimbra's. But if you find the need to change it, here's the steps.

You can modify the default [389] port ldap uses to port 390 by doing the following [change LDAPHOSTNAME.com to your server name]:

zmlocalconfig -e ldap_port=390
zmlocalconfig -e ldap_master_url=ldap://LDAPHOSTNAME.com:390
zmlocalconfig -e ldap_url=ldap://LDAPHOSTNAME.com:390

Note you need to do all three of these or things will break. Once you've run those commands, you will need to restart ZCS:

zmcontrol stop
zmcontrol start

Once this is completed, Zimbra will run with LDAP on port 390 rather than port 389 (the default). If you'd like to use a port other than 390, substitute that port for 390 and use the same process.

Can't Setup/Install LDAP Replica

Please see bug against documentation:

Checking /tmp/zmsetup.log will expose errors with installation configuration, for example below, others are listed in my notes farther down:

: Thu Aug 21 16:00:12 2008 *** Running as zimbra user: /opt/zimbra/bin/zmlicense -c
Error: exception occurred: system failure: ZimbraLdapContext
 when running 'zmcontrol start':
[zimbra@mail1b ~]$ zmcontrol start
Host mail1b.DOMAINNAME
Unable to determine enabled services from ldap.
Unable to determine enabled services. Cache is out of date or doesn't exist.

Make sure you are using the right passwords. If the ldap replica can't authenticate to the master LDAP server it will not be able to pull down the ldap configurations it needs - one of which is the license data.

My Notes From The Case That I Made For Bug 26117

Verified Fixed for 5.0.10+ in regards to bug 26117
Summary

Action Items:

  • Update doc's to reflect ldap repli password setting during install (all ref docs miss this step)
    • If this is done during install, no other action is needed except logger and sshkeys (zmupdateauthkeys)
  • Update doc's to reflect recovery steps on an improper install for ldap replication server
  • Make comments consistent. See LDAP wiki page
  • Update installer to require ldap repli password rather default to random set

password.

References:

LDAP replication has some comments that aren't in other places

  • Set the master LDAP password to the correct value (run zmlocalconfig -s ldap_root_password on the master to determine this value)
  • Note: In order to install an LDAP replica server with no MBS (Mailbox Server), set zimbra_zmprov_default_to_ldap to true, using the following command:
    • zmlocalconfig -e zimbra_zmprov_default_to_ldap=true.
    • If you later add an MBS to your LDAP replica server, set zimbra_zmprov_default_to_ldap to false.
  • After the installation is complete, run /opt/zimbra/libexec/zmldapenablereplica on the replica server. This will enable replication in the LDAP server and will force an LDAP restart to begin pulling data from the master. zmldapenablereplica must be run on both the master and replica for LDAP replication to work.
The Work

Duplicated on ZCS 5.0.2 - OS Redhat.

Current Servers For Test:

  • Setup LDAP MAIN server - zldap1 (ldap only configured server)
    • setting passwords to "PASSWORD"
  • Mailstore server - zmail2 (mailstore only config)
  • MTA server - zmta1 (mta only config)
  • Post install
    • enable logger
    • enable ssh keys
      • run zmupdateauthkeys on servers
    • created two test accounts and confirmed email delivery between the two.
    • On LDAP MAIN (zldap1)- zmldapenablereplica

Install LDAP repli - zldap3

  • Doc show only to set
    • ldap master host
    • Master ldap server password
    • Create Domain to no
  • It fails to include
    • Replication Password (part of "Ldap configuration")
      • If this is not done, install will finish but you get these errors.
[zimbra@zldap3 ~]$ zmcontrol status
Cannot determine services - exiting
zldap3.DOMAIN.com...ERROR: service.FAILURE (system failure: getDirectContext)
(cause: javax.naming.AuthenticationException [LDAP: error code 49 - Invalid Credentials])
To Correct Without Reinstalling

If this has happened and you want to correct without a reinstall. Do the following, please adjust for HOSTNAMES for LDAP MAIN and LDAP REPLICA.

  • confirm ssh keys are updated
run zmupdateauthkeys on all servers
  • confirm current settings on LDAP MAIN
zmlocalconfig -s | grep replication
grep credentials /opt/zimbra/conf/slapd.conf
  • confirm current settings on LDAP REPLI
grep credentials /opt/zimbra/conf/slapd.conf
zmlocalconfig -s | grep replication
  • Now reconfigure on LDAP REPLI
zmldappasswd -l [passwd from ldap main slapd.conf]
    • This does not dynamically update the slapd.conf variable, it puts it in the zmconfig file /opt/zimbra/libexec/zmldapenablereplica
    • You'll see that it updates the slapd.conf
    • There might be one auth error, until the slapd.conf is reconfigured.
    • zmprov gacf will fail with auth errors
  • Confirm again settings on LDAP REPLI
grep credentials /opt/zimbra/conf/slapd.conf
zmlocalconfig -s | grep replication
zmlocalconfig | grep ldap_url
    • Should have repli first and ldap main second
  • Now to confirm it worked
zmcontrol stop
zmcontrol start
zmcontrol status
    • Create a test account on LDAP MAIN (example uses test3)
    • On LDAP REPLI - replace hostname and test account below
      • ldapsearch -x -H ldap://LDAPREPLICA.DOMAIN.com:389 | grep test3

Disable LDAP Replica

References:

http://wiki.zimbra.com/index.php?title=Promoting_Replica_to_LDAP_Master

http://www.zimbra.com/docs/os/latest/multi_server_install/LDAP%20Replication.6.1.html

Remove LDAP Replica From All Active Servers

On each member server, including the replica itself, verify the ldap_url value.

zmlocalconfig ldap_url

Modify the ldap_url to only include enabled ZCS LDAP servers. The master LDAP server should always be at the end of the ldap_url string value.

zmlocalconfig -e ldap_url="ldap://<replica-server-host> ldap://<master-server-host>"

Disable LDAP On The Replica

Stop Zimbra services.

zmcontrol stop

The - in front of zimbraServiceEnabled is [off], rather than a + for [on].

zmprov -l ms `zmhostname` -zimbraServiceEnabled ldap

To enable the ldap service, prefix the zimbraServiceEnabled attribute with a "+".

zmprov -l ms `zmhostname` +zimbraServiceEnabled ldap

If other services are enabled on this host, start them.

zmcontrol start

Additional Steps for MTA hosts

After updating the ldap_url with zmlocalconfig, rerun /opt/zimbra/libexec/zmmtainit. This rewrites the Postfix configuration with the updated ldap_url.

Disabling Replication On The Master

ZCS 5.x

Use only if disabling replication entirely across all nodes.

Edit /opt/zimbra/conf/slapd.conf.in adding the following comments. Please use the precise number of hash marks (#) shown.

change

include /opt/zimbra/conf/master-accesslog.conf

to

###include /opt/zimbra/conf/master-accesslog.conf

change

overlay syncprov
syncprov-checkpoint 20 10
syncprov-sessionlog 500
include /opt/zimbra/conf/master-accesslog-overlay.conf

to

#overlay syncprov
#syncprov-checkpoint 20 10
#syncprov-sessionlog 500
###include /opt/zimbra/conf/master-accesslog-overlay.conf

Restart the master LDAP server

ldap stop; ldap start

Promoting Replica To LDAP Master

Please see:

Importing LDAP data from master to replica 6.0

Please see:

BDB - Underlying Database Used For LDAP Data

BDB is the underlying high-performance transactional database used to store the LDAP data.

See:

db_stat

The db_stat utility displays statistics for Berkeley DB environments.

Example output:

[zimbra@mail3 openldap-data]$ db_stat -c -h /opt/zimbra/openldap-data
462	Last allocated locker ID.
2147M	Current maximum unused locker ID.
9	Number of lock modes.
3000	Maximum number of locks possible.
1500	Maximum number of lockers possible.
1500	Maximum number of lock objects possible.
19	Number of current locks.
73	Maximum number of locks at any one time.
62	Number of current lockers.
68	Maximum number of lockers at any one time.
19	Number of current lock objects.
50	Maximum number of lock objects at any one time.
1784391	Total number of locks requested.
1784372	Total number of locks released.
0	Total number of lock requests failing because DB_LOCK_NOWAIT was set.
8	Total number of locks not immediately available due to conflicts.
0	Number of deadlocks.
0	Lock timeout value.
0	Number of locks that have timed out.
0	Transaction timeout value.
0	Number of transactions that have timed out.
968KB	The size of the lock region..
6	The number of region locks granted after waiting.
3543865	The number of region locks granted without waiting.
db_archive

The db_archive utility writes the pathnames of log files that are no longer in use (for example, no longer involved in active transactions), to the standard output, one pathname per line. These log files should be written to backup media to provide for recovery in the case of catastrophic failure (which also requires a snapshot of the database files), but they may then be deleted from the system to reclaim disk space.

db_checkpoint

The db_checkpoint utility is a daemon process that monitors the database log, and periodically calls DB_ENV->txn_checkpoint to checkpoint it.

db_deadlock
db_dump
db_load
db_recover

Ldap Replica Styles And Timeframes

Please see this external reference:

LDAP And OverLays

We don't [officially] support running additional overlays with OpenLDAP.

SLAPO-RWM OVERLAY RWM

And slapo-rwm is known to be buggy in OpenLDAP 2.3.43 and continues to be buggy to this day in OpenLDAP 2.4. It certainly won't work with ZCS 5.0.16.

We would advise customers to avoid using it until it stabilizes, though they need to understand it's still going to be unsupported by us.

Where one places "overlay rwm" in the slapd.conf file has been known to cause issues as well. RWM has problems in the order in which it is loaded. There are at least 2 open bugs currently in the OpenLDAP ITS tracker.



Jump to: navigation, search