OCNS Consulting wrote:
>
> Ken:
>
> I finally determined the issue with BerkeleyDB. The SASL configure script
> looks for "/usr/include/db3" which is found and contains (as expected) bdb3
> headers. Of course I compile SASL against bdb4 which is specified by
> including
> the options ->
>
> --with-bdb-libdir=/usr/local/BerkeleyDB.4.0/lib
> --with-bdb-incdir=/usr/local/BerkeleyDB.4.0/include
>
> However, the above "configure" script option "--with-bdb-incdir" is
> apparently
> overridden when header files in "/usr/include/db3" are present. My temporary
> solution was to rename/mv the "/usr/include/db3" directory to
> "/usr/include/db3.SAV"
> and create a sym link from "/usr/local/BerkeleyDB.4.0/include" to
> "/usr/include/db3".
> This did the trick. Now SASL V2 libraries are created without a bdb conflict
> and
> "dbconverter-2" as well as "saslpasswd2" work as expected.
Hmm. The configure script should definitely use the options that you
specify and not bother to look for BDB on its own. Something to look
at.
> Now the issue is with "Cyrus IMAP 2.1.3". The service protocol processes
> complain that
> "libsasl.so" is looking for "libdb-3.3.so". Just to insure that Cyrus IMAP
> was not
> experiencing the same bdb issue as SASL V2, I recompiled IMAP 2.1.3 - here
> are the
> "configure script" options selected ->
>
> ./configure \
> --enable-fulldirhash \
> --with-sasl=/usr/lib/sasl2 \
> --with-openssl=/usr/local/ssl \
> --with-tcl=/usr/local/ActiveTcl \
> --with-auth=unix \
> --without-krb \
> --with-dbdir=/usr/local/BerkeleyDB \
> --enable-listext
Why is the BDB directory different from the one you used for SASL?
> Additional bdb "configure script" options are ->
>
> --with-duplicate-db=DB use DB (db3, skiplist) as a backend
> for the duplicate delivery db (Default:
> db3_nosync)
> --with-mboxlist-db=DB use DB (flat, db3, skiplist) as a backend
> for the mailbox list (Default: db3)
> --with-seen-db=DB use DB (flat, db3, skiplist) as a backend
> for the seen state (Default: flat)
> --with-subs-db=DB use DB (flat, db3, skiplist) as a backend
> for the subscriptions list (Default: flat)
> --with-tls-db=DB use DB (db3, skiplist) as a backend
> for the TLS cache (Default: db3_nosync)
>
> The above IMAP "configure script" db option descriptions would lead me to
> believe that
> bdb4.0 is not supported by "Cyrus IMAP" and potentially "SASL V2 libraries".
> Is this
> the case?
No. The name of the backend just happens to be db3, but db4 is
supported. We should probably change the name to bdb so it is version
agnostic.
> If not, is there a prescribed method for compiling the Cyrus
> Projects against
> bdb4.0?
--with-dbdir
>
> Moving along, I then restart "master" and the following entries are still
> showing-up in
> "imapd.log":
>
> imapd[12558]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open
> shared object file: No such file or directory
>
> pop3d[12561]: unable to dlopen libsasl.so: libdb-3.3.so: cannot open
> shared object file: No such file or directory
Your services should not be linked against SASL v1. I'm not sure how
this is happening.
> So, I created a sym link from "/usr/local/BerkeleyDB.3.3/lib/libdb-3.3.so"
> to
> "/lib/libdb-3.3.so" and the above log file messages no longer appear. I then
> ran
> "imtest" and authentication was successful using "sasldb2" accounts.
>
> Yet all is not working, now the following entries are made to the
> "imapd.log" file
> when attempting to login via my mail client:
>
> badlogin: mailclient [X.X.X.X] plaintext theman SASL(-4): no mechanism
> available: checkpass failed
Make sure that /etc/sasldb2 is readable by the 'cyrus' user. This might
also be a problem with the wrong libsasl and/or libdb being linked.
> The "/etc/imapd.conf" file contains ->
>
> configdirectory: /var/imap
> partition-default: /var/spool/imap
> admins: cyrusadmin
> sasl_pwcheck_method: auxprop
> partition-news: /var/spool/imap-news
> newsspool: /var/spool/news
> sendmail: /usr/sbin/sendmail
> tls_cert_file: /var/imap/server.pem
> tls_key_file: /var/imap/server.pem
>
> Further, when I attempt to "su", it "Segmentation Faults" and the following
> entries are
> showing-up in the "messages" file
>
> su(pam_unix)[12943]: authentication failure; logname=username uid=500
> euid=0 tty= ruser= rhost= user=root
>
> su[12943]: unable to get entry point sasl_client_plug_init in
> /usr/lib/sasl/libsasldb.so:
> /usr/local/lib/libsasl.so.7: undefined symbol: sasl_client_plug_init
>
> Why would PAM looking for "SASL V1" libraries? Does PAM need to be relinked
> against "SASL V2"
> libraries?
AFAIK, PAM doesn't know anything about SASL. SASL can use PAM, not the
other way around.
>
> I look forward to your's and the list responses to this one - Thanks!
>
> RB
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
