RE: Signaled to Death by 11 - Again - bdb issues?
Ken: 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? /usr/local/BerkeleyDB is a symbolic link to /usr/local/BerkeleyDB.4.0; i.e. # ls -al /usr/local/BerkeleyDB lrwxrwxrwx 1 root root 14 Jan 18 13:45 /usr/local/BerkeleyDB - BerkeleyDB.4.0 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. H 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. # ls -al /etc/sasldb2 -rw-r- 1 cyrus mail 12288 Mar 22 12:26 /etc/sasldb2 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. Interesting. Have any ideas of what SASL V2 library the module sasl_client_plug_init resides? I look via nm and ar and found nothing. RB
RE: Signaled to Death by 11 - Again - bdb issues?
On Sun, 24 Mar 2002, OCNS Consulting wrote: Interesting. Have any ideas of what SASL V2 library the module sasl_client_plug_init resides? I look via nm and ar and found nothing. Every plugin that supports a client-side SASL negotiation should export this (which is basically all of the included ones, except for libsasldb). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Signaled to Death by 11 - Again - bdb issues?
Also, have any idea what is causing the following error? 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 RB Every plugin that supports a client-side SASL negotiation should export this (which is basically all of the included ones, except for libsasldb). -Rob
RE: Signaled to Death by 11 - Again - bdb issues?
Okay. Then what plugin is expected to perform LDAP authentication? RB Every plugin that supports a client-side SASL negotiation should export this (which is basically all of the included ones, except for libsasldb). -Rob
RE: Signaled to Death by 11 - Again - bdb issues?
On Sun, 24 Mar 2002, OCNS Consulting wrote: Okay. Then what plugin is expected to perform LDAP authentication? No plugins supplied by the Cyrus SASL Distribution currently perform LDAP authentication. There is one third-party auxprop plugin that we're looking at including in the distribution if a few changes were made (which escape me at the moment). Also, have any idea what is causing the following error? 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 The typical answer I give is Stop logging at the LOG_DEBUG level, the messages are harmless, and this feature has been removed from CVS (if not 2.1.1) 3. Undue steps in 1 and authentication works as expected. Next, imtest successfully authenticates accounts known to sasldb2, however imtest fails if an LDAP account is specified - imapd[1063]: badlogin: localhost[127.0.0.1] DIGEST-MD5 [SASL(-13): user not found: no secret in database] DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it needs the plaintext password (or DIGEST secret). (i.e. it won't work with saslauthd). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Signaled to Death by 11 - Again - bdb issues?
On Sun, 24 Mar 2002, OCNS Consulting wrote: DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it needs the plaintext password (or DIGEST secret). (i.e. it won't work with saslauthd). This is making since - Thanks. I'm assuming that the auxprop plugin method doesn't use PAM and thus the LDAP authentication method via pam_ldap.so used with SASL V1 is not applicable with SASL V2. Almost. You can still do pam_ldap authentication via saslauthd. Is all this documented somewhere? The dicumentation in the doc/ directory could probably stand some improvment. Suggestions are welcome, patches are encouraged ;) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Signaled to Death by 11 - Again - bdb issues?
Rob: DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it needs the plaintext password (or DIGEST secret). (i.e. it won't work with saslauthd). This is making since - Thanks. I'm assuming that the auxprop plugin method doesn't use PAM and thus the LDAP authentication method via pam_ldap.so used with SASL V1 is not applicable with SASL V2. Is all this documented somewhere? RB
RE: Signaled to Death by 11 - Again - bdb issues?
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. 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 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=DBuse 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? If not, is there a prescribed method for compiling the Cyrus Projects against bdb4.0? 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 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 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? I look forward to your's and the list responses to this one - Thanks! RB
Re: Signaled to Death by 11 - Again - bdb issues?
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=DBuse 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.
