NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD, sendmail with AUTH and TLS

On Thu, 13 Dec 2012, Peter Bex wrote:
On Thu, Dec 13, 2012 at 12:22:17PM -0600, Michael Parson wrote:
I followed the wiki entry for this on my NetBSD/i386 5.0.2 system:

And it worked beautifully.  However, that system died, and now:

Trying the same thing on my amd64 6.0 system, and it's not working.

Is this a clean 6.0 system, or an upgraded one?  If you built inside
a chroot, did you remember to upgrade the chroot to 6.0 userland as
well?  If you're using binary packages, did you remember to update
the PKG_PATH variable or pkgin's repositories.conf to look at a 6.0

Clean binary install of 6.0, in fact, I couldn't get anything before 6.0
to install on this setup ('s Xen infrastructure), building
all the pkgsrc stuff from source, my mk.conf has my LOCALBASE set to
/usr/local instead of /usr/pkg, just a personal preference I've been
dragging along with me for years.

# uname -a
NetBSD testhost 6.0 NetBSD 6.0 (XEN3_DOMU) amd64

This doesn't seem to be working either.  In my /var/log/authlog, I see the
probable problem, but I don't know how to solve it:

Dec 13 12:15:46 testhost sm-mta[26159]: unable to dlopen
/usr/local/lib/sasl2/ Cannot dlopen non-loadable

I've seen something similar before just after upgrading and installing
my first newly built binaries.  This probably means that some component
(either the end-point binary or one of the libraries it loads),
was linked to (the 5.x libpthread) and one or more
of the other libraries (or the binary itself) was linked against

NetBSD 6.0 has a newer libpthread and needed to bump the ABI version,
and libpthread can only be active once when the program is started,
and all binaries using .so-files that use it need the library linked
into it.  libpthread is a bit odd that way ;)

That maks sense.

From what I can tell from searching google and reading the dlopen
manpage, something is trying to load, but that something
isn't also linked against

This can be debugged by using ldd(1) on the binary and working through
all its .so-files, recursively running ldd on them.  One of those
should eventually show up being linked against; that
needs to be rebuilt and reinstalled.

The bits that I can think of to check are:

/usr/local/libexec/sendmail/sendmail (not linked against libpthread at all)
/usr/local/lib/sasl2/ (not linked against libpthread at all)
/usr/local/sbin/saslauthd (not linked against libpthread at all)

Starting with

# ldd
        -ldb4-4.8.8 => /usr/local/lib/
        -lpthread.1 => /usr/lib/
        -lgcc_s.1 => /usr/lib/
        -lc.12 => /usr/lib/
        -lresolv.2 => /usr/lib/

# ldd /usr/local/lib/
        -lpthread.1 => /usr/lib/
        -lgcc_s.1 => /usr/lib/
        -lc.12 => /usr/lib/

For giggles, I ran through all of /usr/local/lib and /usr/local/bin,
can't find anything linked against pthread.0, all the pthreads requests
are for .1

It might help if I can find who is loading  Reading a
ktrace of sendmail it looks like sendmail is loading it, but it's not
directly linked to it:

# grep pthread ktrace.txt
 17364      1 sendmail NAMI  "/usr/local/lib/"
 17364      1 sendmail NAMI  "/usr/X11R7/lib/"
 17364      1 sendmail NAMI  "/usr/lib/"
       "<35>1 2012-12-13T08:45:56.560822-06:00 testhost sm-mta 17364 - - unable to 
dlopen /usr/local/lib/sasl2/ Cannot dlopen non-loadable 

# ldd /usr/local/libexec/sendmail/sendmail
        -lwrap.7 => /usr/local/lib/
        -lc.12 => /usr/lib/
        -lssl.0.9.8 => /usr/local/lib/
        -lcrypto.0.9.8 => /usr/local/lib/
        -lsasl2.2 => /usr/local/lib/
        -lresolv.2 => /usr/lib/
        -lgcc_s.1 => /usr/lib/
        -lutil.7 => /usr/lib/

Michael Parson
Austin, TX

Home | Main Index | Thread Index | Old Index