Linux System Administration Recipes A Problem-Solution Approach

CHAPTER 2 ■ CENTRALIZING YOUR NETWORK: KERBEROS, LDAP, AND NFSYou shouldn’t need to restart the master server (the provider). Just start the slave server up, and itshould automatically pick up the master server database.For this setup to work, you need to be able to have a Kerberos ticket for both ldapadm and rep_admalive at the same time (see the alternative configuration later in this recipe if you’re not using Kerberos).Otherwise, you’d set up your authentication as rep_adm on the master machine, and that would workgreat until you authenticated as ldapadm to make a change to the DB, at which point it would fail. This isparticularly not great given that it’s precisely when you’re making changes that you want replicationto work!■ Note If you do have this problem, you’ll see this in the .rej file in /var/lib/ldap/:ERROR: ReferralIf you increase the logging of the slave, you’ll also see slurpd changing users.What you need is to set up k5start to manage more than one ticket. Set up your slapd init script(which also starts slurpd and k5start) to include this:KRB5CCNAME="FILE:/tmp/ldap_replicator.tkt"export KRB5CCNAME.....start_slurpd() {if [ "$SLURPD_START" != yes ]; thenreturn 0fiecho -n " slurpd"reason="`start-stop-daemon --start --quiet --oknodo \--exec /usr/sbin/slurpd -- $SLURPD_OPTIONS 2>&1`"echo -n " k5start"# Start kstart in order to manage replicationreason_kstart="`start-stop-daemon --start --pidfile \/var/run/k5start.pid \--exec /usr/bin/k5start -- -b -K 10 \-k /tmp/ldap_replicator.tkt \-p /var/run/k5start.pid \-f /etc/ldap/slurpd.keytab rep_adm`"}reason and reason_kstart are caught separately elsewhere in the script so that a failure ofkstart won’t cause the total failure of the LDAP server. To do this, add this section to the start ofreport_failure:44Download at WoweBook.Com