Craig White wrote: >On Sun, 2006-11-12 at 21:06 -0700, Philip Prindeville wrote: > > >>Craig White wrote: >> >> >> >>>On Sun, 2006-11-12 at 15:53 -0700, Philip Prindeville wrote: >>> >>> >>> >>> >>>>Sam Varshavchik wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Philip Prindeville writes: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Since we reimaged our mail server (using Sendmail, Cyrus-imap, Mimedefang, >>>>>>and SpamAssassin) to FC5, we've been seeing: >>>>>> >>>>>>Nov 10 11:13:21 mail saslauthd[2912]: Deprecated pam_stack module called from service "imap" >>>>>>Nov 10 11:13:21 mail saslauthd[2912]: Deprecated pam_stack module called from service "imap" >>>>>>Nov 10 11:56:03 mail saslauthd[2912]: Deprecated pam_stack module called from service "imap" >>>>>>Nov 10 11:56:03 mail saslauthd[2912]: Deprecated pam_stack module called from service "imap" >>>>>>Nov 10 11:56:03 mail saslauthd[2909]: Deprecated pam_stack module called from service "imap" >>>>>> >>>>>>in our /var/log/secure logfile. sigh... did I forget to do >>>>>>something else when setting up the mail server following the >>>>>>FC5 reimage? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>As the message says: pam_stack is deprecated. >>>>> >>>>>After some further poking: pam_stack has been replaced by the include >>>>>directive. See /etc/pam.d >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Ok, well, I'm looking at it: >>>> >>>>#%PAM-1.0 >>>>auth required pam_stack.so service=system-auth >>>>account required pam_stack.so service=system-auth >>>> >>>>I'm also seeing the contents of the /usr/share/docs/cyrus-imap-*/ >>>>directory that references the link: >>>> >>>>http://www.kernel.org/pub/linux/libs/pam/FAQ >>>> >>>>and looking at that link, they talk about RedHat lagging behind >>>>on the PAM release. >>>> >>>>Well, this is more than a bit confusing. It looks like Cyrus >>>>is the one lagging behind... or at least, whoever set the options >>>>that the Redhat RPM's get packaged with did. >>>> >>>>What *should* Cyrus be using to authenticate? >>>> >>>>This is assuming that I don't want all users having mailboxes to >>>>have entries (accounts) in /etc/passwd... I can seed their passwords >>>>manually using saslpasswd -f /etc/sasldb2 ... >>>> >>>> >>>> >>>> >>>---- >>>It depends upon setting in /etc/imapd.conf >>> >>># grep sasl /etc/imapd.conf >>>sasl_pwcheck_method: saslauthd >>>sasl_mech_list: PLAIN >>> >>>when cyrus uses saslauthd for authentication... >>> >>># cat /etc/sysconfig/saslauthd >>># Directory in which to place saslauthd's listening socket, pid file, >>>and so >>># on. This directory must already exist. >>>SOCKETDIR=/var/run/saslauthd >>> >>># Mechanism to use when checking passwords. Run "saslauthd -v" to get a >>>list >>># of which mechanism your installation was compiled with the ablity to >>>use. >>>MECH=pam >>> >>># Additional flags to pass to saslauthd on the command line. See >>>saslauthd(8) >>># for the list of accepted flags. >>>FLAGS= >>> >>>make sure that saslauthd service is started... >>> >>>/sbin/service saslauthd status >>>saslauthd (pid 3233 3232 3231 3230 3219) is running... >>> >>>this should pretty much work. >>> >>>Craig >>> >>> >>> >>> >>Yeah, saslauthd is running... the config is unchanged, as above... >>I've created a username with: >> >> saslpasswd2 -f /etc/sasldb2 -a imap -c username >> >>Oh, did the "chown cyrus.mail /etc/sasldb2" also... >> >>So I can't figure out what else needs to be done... Still seeing >>those messages. >> >> >---- >I don't use sasldb but a check of the man page for saslauthd shows... > >sasldb (All platforms) > Authenticate against the SASL authentication database. Note that this >is probabally > not what you want to be using, and is even disabled at compile-time by >default. > If you want to use sasldb with the SASL library, you probably want to >use the > pwcheck_method of "auxprop" along with the sasldb auxprop plugin >instead. > >Craig > > That doesn't seem right. Why would Cyrus-imapd be released in a successive version that removed very popular functionality it previously had? A lot of people use IMAP-over-SSL with a SASL database to authenticate from. Usually RPM's are released in binary form with the maximum amount of functionality. BTW: saslauthd -v returns: saslauthd 2.1.21 authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap -Philip
