Linux System Administration Recipes A Problem-Solution Approach

CHAPTER 2 ■ CENTRALIZING YOUR NETWORK: KERBEROS, LDAP, AND NFSSlave servers can’t modify the database, so it tries to redirect to the master and fails. If you now useldapsearch to look for your new entry, you will not find it.You can confirm this diagnosis by trying ldapsearch -H ldaps://masterldap.example.com to force abind to the master server.The next stage is to find out what’s causing the problem. Set the log level in /etc/ldap/slapd.conf to1, and then restart slapd and check the logs.These are two common problems:• An old slapd process that hasn’t been killed off properly. Check with ps and kill it ifnecessary.• An alock problem, which looks like this in the log:slapd[27069]: bdb_db_open: alock package is unstableslapd[27069]: backend_startup_one: bi_db_open failed! (-1)To resolve this, stop the server, delete the old alock file, and restart the server:/etc/init.d/slapd stoprm /var/lib/ldap/alock/etc/init.d/slapd startslapd may take a little while to recover the database after this and may also needto be restarted again. It’s probably wise to run a database dump before doing this.Again, this is something that you should be doing regularly anyway.Remember to return the log level to normal afterward, or the server will be very slow.If slurpd isn’t working properly, stop slapd, check the output of ps -A for old slapd processes andkill them if necessary, and then restart slapd. Check ps -A again to confirm that slapd is running.If the slave server is missing some entries (for example, if entries were added to the main databasethat relied on new schemas that weren’t available on the slave, which means that the slave will ignorethe changes):1. Stop slapd on the slave.2. On the master server, run the following:/usr/sbin/slapcat -l backupdb.ldif3. Copy backupdb.ldif onto the slave server.4. slapcat -c -l backupdb.ldif on the slave. Ignore any errors regardingduplicate entries.5. Restart slapd on the slave server.When you are troubleshooting, bear in mind that the replog file is expected to be empty, becauseslurpd truncates it immediately on read. In other words, if you see an empty replog, this is not on its ownan indication of or a source of any problems! However, the truncation happens whether a full successfulreplication has been completed, because the file is truncated immediately on read. If you have aproblem with replication, you’ll usually lose the replication data from the replog file, though the correctdata will still be in the master database. This means that when you do get replication working again, thenew data will never be transferred. To resolve this problem, use the method mentioned previously.46Download at WoweBook.Com