Saslauthd troubleshooting

package update: no worky

April 27, 2006

I recently upgraded packages related to sasl. According to the contents of /var/cache/apt/archives, these are the new packages:

-rw-r--r--  1 root root  120368 2006-04-24 05:08 sasl2-bin_2.1.19-1.5ubuntu4.2_amd64.deb
-rw-r--r--  1 root root  265392 2006-04-24 05:08 libsasl2_2.1.19-1.5ubuntu4.2_amd64.deb
-rw-r--r--  1 root root  170336 2006-04-24 05:08 libsasl2-modules_2.1.19-1.5ubuntu4.2_amd64.deb

Sometime after that, I noticed that I could no longer send mail. Soon after that, I noticed that saslauthd is not running and won't restart.

I found that /etc/init.d/saslauthd thinks that it is succeeding, but fails because $PWDIR doesn't have a match in the dpkg-statoverride list:

case "${1}" in
  start)
        echo -n "Starting ${DESC}: "
    dir=`dpkg-statoverride --list $PWDIR`
    test -z "$dir" || createdir $dir
    if start-stop-daemon ${START} >/dev/null 2>&1 ; then
        echo "${NAME}."
    else
        if start-stop-daemon --test ${START} >/dev/null 2>&1; then
            echo "(failed)."
            exit 1
        else
            echo "${DAEMON} already running."
            exit 0
        fi
    fi
        ;;

$PWDIR is set to /var/spool/postfix/var/run/saslauthd

The output of dpkg-statoverride --list is:

root sasl 660 /etc/sasldb2
postfix postdrop 02710 /var/spool/postfix/public
amavis amavis 755 /var/lib/amavis
root postdrop 02555 /usr/sbin/postdrop
amavis amavis 755 /var/lib/amavis/virusmails
amavis amavis 755 /var/run/amavis
root postdrop 02555 /usr/sbin/postqueue
hplip root 755 /var/run/hplip
root sasl 710 /var/run/saslauthd

The output of dpkg-statoverride --list /var/spool/postfix/var/run/saslauthd is nothing.

So dpkg-statoverride doesn't know that saslauthd is running inside the chroot jail of postfix. Do I want to pull saslauthd out of the chroot jail? That would allow other processes to use saslauthd and would probably make future upgrades to sasl less painful. I believe I tried that and found that the effort to circumvent the chroot jail of postfix was too much and too messy. And I don't really want saslauthd for anything but postfix.

So I need to figure out what dpkg-statoverride is and tell it where saslauthd is running.

While tracking down the configuration files for saslauthd, I found a program called testsaslauthd that takes a username and password and does a test transaction against saslauthd. I tried it to watch it fail and it worked. Somehow saslauthd is running now.

A (fairly) complete overview of the config files

June 4, 2006

Same general problem: I update to the latest Ubunutu packages and saslauthd stops working. But the slight difference this time is that saslauthd will stop and start without error.

The current problem is that I am unable to authenticate properly when trying to send mail. The config files are ordered according to the steps in that process.

Postfix gets a request to send mail from me and needs to know how to handle authentication.

/etc/postfix/main.cf

enable_sasl_authentication = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl2_auth_enable = yes

/etc/postfix/master.cf

includes the option to smtpd "-o smtpd_sasl_auth_enable=yes

/etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5
allow_plaintext: true

That much should be sufficient to get the transaction directed to saslauthd, but apparently it is not.

SASL authentication failure: cannot connect to saslauthd server: No such file or directory

Even though, this works:

root@weasel:/etc/pam.d# testsaslauthd -u rday -p password
0: OK "Success."

If the request gets to saslauthd, it must know what to do with it:

/etc/default/saslauthd

# This needs to be uncommented before saslauthd will be run automatically
START=yes

# You must specify the authentication mechanisms you wish to use.
# This defaults to "pam" for PAM support, but may also include
# "shadow" or "sasldb", like this:
# MECHANISMS="pam shadow"

MECHANISMS="pam"
#PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"
PARAMS="-m /var/run/saslauthd"

It hands the request over to pam. That was easy.

/etc/pam.d/smtp

#%PAM-1.0

@include common-auth
@include common-account
@include common-session

Pam does the common Pam things.