Two Methods for troubleshooting LDAP host server faults

Lightweight Directory Access Protocol (LDAP) allows you to have a master server + slave server, and has the fault tolerance function or scattered workload function in the event of a fault. This has obvious advantages. However, it also hides some problems of the master server.

If your master server is shut down and the slave server is working normally, it is good to perform ldapsearch search and other queries. However, if you try to modify the database (using the ldapadd command), you will get the following error message: ldap_add: Referral (10)

Referrals:

Ldaps: // masterldap.example.com/uid=test,ouyunpeople,

Dc = example, dc = com

The slave server cannot modify this database. Therefore, it tries to point to the master server again and get the result of failure. If you use the ldapsearch SEARCH Command to query the new content, you cannot find the content.

You can use the following method to confirm the diagnosis: Use ldapsearch-H ldaps: // masterldap.example.com to forcibly bind the master server.

The next step is to find the cause of the fault. Set the record level in the/etc/ldap/slapd. conf configuration file to 1, restart slapd, and view the record.

Two common problems are:

An old slapd thread is not properly closed. Use ps to check and close this thread if necessary.

A alock problem. This problem looks like this in the record:

Slapd [27069]: bdb_db_open: alock package is unstable

Slapd [27069]: backend_startup_one: bi_db_open failed! (-1)

To solve this problem, you can delete the/var/lib/ldap/alock file (or check the slapd. conf configuration file in your local data directory ). Run the db_recover command to restore the database, or restart slapd. It should be able to recover it on its own. You need to give it some time or restart it.

Remember to restore the record level to normal after completing the above operations. Otherwise, the server will run slowly. Also, consider using monitoring software to capture these hidden issues.