FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 02-22-2012, 07:36 PM
Steve Campbell
 
Default Pam problems

I'm having problems with what I think is PAM. Seems that ever since
Centos 5, proftpd has had problems using pam, and with Centos 6.2 64
bit, I had to quit using it altogether with proftpd.

Now I'm trying to set up SMTP AUTH using PAM as the pwcheck parm to
saslauthd, and I can't setup new email accounts on my port submission
(587) to work at all. We use this port of sendmail so outside users can
send through our own email server. The crazy thing is that users that
were setup previously before my migration from an older Centos 3 box to
the new box can still use the port fine on the new server. But I can't
get a new account to work. I'm not seeing any errors anywhere, but when
trying to configure an account manually in Thunderbird, it fails
whenever I use port 587. I've got a similar host on using old Centos 3
that still works fine and I'm using it as a model along with the
settings on the original Centos 3 host that was replaced for most of my
parameters.

Anyone had any experience with sendmail and this sort of thing on Centos
6.2? I've stared at this thing for days and tried about everything I can
think of. The yum says pam is up to date.

I have at the least the same pam packages, if not more, on the new
server as the old ones.

Any help would be appreciated.

steve campbell

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-22-2012, 08:31 PM
Les Mikesell
 
Default Pam problems

On Wed, Feb 22, 2012 at 2:36 PM, Steve Campbell <campbell@cnpapers.com> wrote:
> I'm having problems with what I think is PAM. Seems that ever since
> Centos 5, proftpd has had problems using pam, and with Centos 6.2 64
> bit, I had to quit using it altogether with proftpd.

Do you mean some specific pam step listed in /etc/pam.d/proftpd fails,
or what? And are you doing anything exotic there or just trying to
read the shadow file? And when reading the shadow file, is SElinux
enabled and logging errors?

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 11:36 AM
Steve Campbell
 
Default Pam problems

On 2/22/2012 4:31 PM, Les Mikesell wrote:
> On Wed, Feb 22, 2012 at 2:36 PM, Steve Campbell<campbell@cnpapers.com> wrote:
>> I'm having problems with what I think is PAM. Seems that ever since
>> Centos 5, proftpd has had problems using pam, and with Centos 6.2 64
>> bit, I had to quit using it altogether with proftpd.
> Do you mean some specific pam step listed in /etc/pam.d/proftpd fails,
> or what? And are you doing anything exotic there or just trying to
> read the shadow file? And when reading the shadow file, is SElinux
> enabled and logging errors?

No, nothing exotic, just a generic install of Proftpd.

On the Centos 5 boxes, I started getting the following, but it would work:

Deprecated pam_stack module called from service "proftpd"
pam_succeed_if(proftpd:session): error retrieving information about user 0
pam_unix(proftpd:session): session closed for user XXXX

I'd found tons of fixes for it, but most would mean just editing the /etc/pam.d/proftpd file or making /etc/pam.d/ftp file the same as proftpd file. Nothing was a clean fix. But logins would still work.

On the Centos 6.2 box, logins wouldn't work at all unless I removed the line requiring pam_shells.so.

Now on to the big problem. In the file /etc/sasl2/Sendmail.conf I've got the line:

pwcheck_methodam

I've got the certificates all fine in the sendmail.mc/cf file just fine, I've got the port 587 defined and it's showing in netstat, but when I try and create an account to access port 587 to send email through, no matter what method I use (ssh, tls, plain ) I can't get an email to go through this. I'm guessing that since I've got these ever-increasing problems with PAM, maybe there's something I'm overlooking in the Pam config, but I'm not aware of any problems. I just can't seem to get authenticated.

I'm aware that going from Centos 3 to Centos 6.2 is a big jump. Fighting Dovecot for Imap has been the biggest hurdle, and it's just recently that people have started notifying me of some of the problems of being able to relay through our server.

My access file on both old and new are duplicates, so the problem isn't there. The other sendmail files are the same as well (local domains, etc).

There's not a wall hard enough for me to keep banging my head against, it seems, and I'm really not getting any benefit from banging it.

SeLinux is off as well as iptables and ip6tables. The firewalling is done for all servers on the network, not the individual server, and the IP of the new server took over the IP of the old server, so the firewall should still be good for all ports and services.

Proftpd is not the real problem here, but the sendmail problem is causing a few calls.

Thanks for any help and replies
steve



>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 02:54 PM
Steve Campbell
 
Default Pam problems

On 2/23/2012 7:36 AM, Steve Campbell wrote:
>
> On 2/22/2012 4:31 PM, Les Mikesell wrote:
>> On Wed, Feb 22, 2012 at 2:36 PM, Steve Campbell<campbell@cnpapers.com> wrote:
>>> I'm having problems with what I think is PAM. Seems that ever since
>>> Centos 5, proftpd has had problems using pam, and with Centos 6.2 64
>>> bit, I had to quit using it altogether with proftpd.
>> Do you mean some specific pam step listed in /etc/pam.d/proftpd fails,
>> or what? And are you doing anything exotic there or just trying to
>> read the shadow file? And when reading the shadow file, is SElinux
>> enabled and logging errors?
> No, nothing exotic, just a generic install of Proftpd.
>
> On the Centos 5 boxes, I started getting the following, but it would work:
>
> Deprecated pam_stack module called from service "proftpd"
> pam_succeed_if(proftpd:session): error retrieving information about user 0
> pam_unix(proftpd:session): session closed for user XXXX
>
> I'd found tons of fixes for it, but most would mean just editing the /etc/pam.d/proftpd file or making /etc/pam.d/ftp file the same as proftpd file. Nothing was a clean fix. But logins would still work.
>
> On the Centos 6.2 box, logins wouldn't work at all unless I removed the line requiring pam_shells.so.
>
> Now on to the big problem. In the file /etc/sasl2/Sendmail.conf I've got the line:
>
> pwcheck_methodam
>
> I've got the certificates all fine in the sendmail.mc/cf file just fine, I've got the port 587 defined and it's showing in netstat, but when I try and create an account to access port 587 to send email through, no matter what method I use (ssh, tls, plain ) I can't get an email to go through this. I'm guessing that since I've got these ever-increasing problems with PAM, maybe there's something I'm overlooking in the Pam config, but I'm not aware of any problems. I just can't seem to get authenticated.
>
> I'm aware that going from Centos 3 to Centos 6.2 is a big jump. Fighting Dovecot for Imap has been the biggest hurdle, and it's just recently that people have started notifying me of some of the problems of being able to relay through our server.
>
> My access file on both old and new are duplicates, so the problem isn't there. The other sendmail files are the same as well (local domains, etc).
>
> There's not a wall hard enough for me to keep banging my head against, it seems, and I'm really not getting any benefit from banging it.
>
> SeLinux is off as well as iptables and ip6tables. The firewalling is done for all servers on the network, not the individual server, and the IP of the new server took over the IP of the old server, so the firewall should still be good for all ports and services.
>
> Proftpd is not the real problem here, but the sendmail problem is causing a few calls.
>
> Thanks for any help and replies
> steve
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
Seems I've found that dovecot is handling the auth for smtp, and it
doesn't like sendmail very much since their documentation avoids
sendmail like the plague.

I sure wish Centos/RH had left something for us so that I wouldn't have
to learn dovecot, postfix and all the other stuff. The original tests I
ran seemed to handle most of the stuff normally but now users are
calling and complaining and there's not a lot I can do but forge ahead.

Not happy but it's my own fault

Thanks for the help

steve
>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 03:04 PM
Les Mikesell
 
Default Pam problems

On Thu, Feb 23, 2012 at 9:54 AM, Steve Campbell <campbell@cnpapers.com> wrote:
>
> Seems I've found that dovecot is handling the auth for smtp, and it
> doesn't like sendmail very much since their documentation avoids
> sendmail like the plague.

None of that makes any sense. Dovecot should have nothing to do with
smtp, so of course it doesn't have anything about sendmail in its
documentation other than adding its local delivery agent which should
be their only interaction and you probably don't even need to use
that.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 03:39 PM
 
Default Pam problems

On Thu, 23 Feb 2012, Les Mikesell wrote:

> On Thu, Feb 23, 2012 at 9:54 AM, Steve Campbell <campbell@cnpapers.com> wrote:
>>
>> Seems I've found that dovecot is handling the auth for smtp, and it
>> doesn't like sendmail very much since their documentation avoids
>> sendmail like the plague.

The Dovecot developer is a smart dude. :-)

> None of that makes any sense. Dovecot should have nothing to do with
> smtp, so of course it doesn't have anything about sendmail in its
> documentation other than adding its local delivery agent which should
> be their only interaction and you probably don't even need to use
> that.

Actually it might. Dovecot can do the sasl auth part. I have not touched
sendmail in at least 10 years, so I do not know anything about the current
default sendmail config but I know dovecot sasl auth is easier to config
for postfix (5 lines in the postfix main.cf IIRC).

I suppose it is possible that RH switched sendmail to user dovecot sasl
in their default config.

HTH,

Regards,

--
Tom me@tdiehl.org Spamtrap address me123@tdiehl.org
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 03:55 PM
Les Mikesell
 
Default Pam problems

On Thu, Feb 23, 2012 at 10:39 AM, <me@tdiehl.org> wrote:
>>>
>>> Seems I've found that dovecot is handling the auth for smtp, and it
>>> doesn't like sendmail very much since their documentation avoids
>>> sendmail like the plague.
>
> The Dovecot developer is a smart dude. :-)
>
>> None of that makes any sense. *Dovecot should have nothing to do with
>> smtp, so of course it doesn't have anything about sendmail in its
>> documentation other than adding its local delivery agent which should
>> be their only interaction and you probably don't even need to use
>> that.
>
> Actually it might. Dovecot can do the sasl auth part. I have not touched
> sendmail in at least 10 years, so I do not know anything about the current
> default sendmail config but I know dovecot sasl auth is easier to config
> for postfix (5 lines in the postfix main.cf IIRC).
>
> I suppose it is possible that RH switched sendmail to user dovecot sasl
> in their default config.

Sendmail is infinitely configurable, but I don't see any uncommented
Auth schemes in the stock sendmail.mc and the smtp-sendmail file in
pam.d just invokes 'system-auth' on 5.x and 'password-auth' on 6.x,
like most of the other things. Something else must be going on here.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 04:18 PM
Steve Campbell
 
Default Pam problems

On 2/23/2012 11:55 AM, Les Mikesell wrote:
> On Thu, Feb 23, 2012 at 10:39 AM,<me@tdiehl.org> wrote:
>>>> Seems I've found that dovecot is handling the auth for smtp, and it
>>>> doesn't like sendmail very much since their documentation avoids
>>>> sendmail like the plague.
>> The Dovecot developer is a smart dude. :-)
>>
>>> None of that makes any sense. Dovecot should have nothing to do with
>>> smtp, so of course it doesn't have anything about sendmail in its
>>> documentation other than adding its local delivery agent which should
>>> be their only interaction and you probably don't even need to use
>>> that.
>> Actually it might. Dovecot can do the sasl auth part. I have not touched
>> sendmail in at least 10 years, so I do not know anything about the current
>> default sendmail config but I know dovecot sasl auth is easier to config
>> for postfix (5 lines in the postfix main.cf IIRC).
>>
>> I suppose it is possible that RH switched sendmail to user dovecot sasl
>> in their default config.
> Sendmail is infinitely configurable, but I don't see any uncommented
> Auth schemes in the stock sendmail.mc and the smtp-sendmail file in
> pam.d just invokes 'system-auth' on 5.x and 'password-auth' on 6.x,
> like most of the other things. Something else must be going on here.

Seems that I've gotten myself into a war over on the dovecot forums. Not
what I intended to do, but when using sendmail with dovecot, it appears
that dovecot auth takes over what sasl auth used to do.

Pretty much over there uses postfix and postfix supports dovecot auth.
sendmail doesn't. I don't know how to separate the auth stuff.

I agree with you concerning the pam files being pretty simple. If I turn
off dovecot and try and connect to port 587, I get nothing including no
return. If I turn on dovecot, I get dovecot auth failures in my secure
logs. Sort of tells me that dovecot is taking over the auth processes
from sasl. I could be wrong.

steve
>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 04:44 PM
Les Mikesell
 
Default Pam problems

On Thu, Feb 23, 2012 at 11:18 AM, Steve Campbell <campbell@cnpapers.com> wrote:
>
> Seems that I've gotten myself into a war over on the dovecot forums. Not
> what I intended to do, but when using sendmail with dovecot, it *appears
> that dovecot auth takes over what sasl auth used to do.

You are still not making any sense. Dovecot doesn't do anything
directly to sendmail. If anything like this is happening at all, it
is in the configurations as shipped by whatever packages you have
installed, or some local change you have. Or maybe by the
slightly-weird 'alternatives' system. Have you followed all of the
symlinks that might be involved?

> Pretty much over there uses postfix and postfix supports dovecot auth.
> sendmail doesn't. I don't know how to separate the auth stuff.

What does that mean. And what do you want to happen?

> I agree with you concerning the pam files being pretty simple. If I turn
> off dovecot and try and connect to port 587, I get nothing including no
> return.

What does 'turn off dovecot' mean? And did you note the comment in sendmail.mc:
' Please remember that saslauthd needs to be running for AUTH'

> If I turn on dovecot, I get dovecot auth failures in my secure
> logs. Sort of tells me that dovecot is taking over the auth processes
> from sasl. I could be wrong.

That would probably be a good thing, since you generally want the same
people to authenticate the same way for imap and authenticated
sending. Why not leave that part alone and focus on fixing it?

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-23-2012, 05:20 PM
Steve Campbell
 
Default Pam problems

On 2/23/2012 12:44 PM, Les Mikesell wrote:
> On Thu, Feb 23, 2012 at 11:18 AM, Steve Campbell<campbell@cnpapers.com> wrote:
>> Seems that I've gotten myself into a war over on the dovecot forums. Not
>> what I intended to do, but when using sendmail with dovecot, it appears
>> that dovecot auth takes over what sasl auth used to do.
> You are still not making any sense. Dovecot doesn't do anything
> directly to sendmail. If anything like this is happening at all, it
> is in the configurations as shipped by whatever packages you have
> installed, or some local change you have. Or maybe by the
> slightly-weird 'alternatives' system. Have you followed all of the
> symlinks that might be involved?

Symlinks? I haven't found any of those yet. All files are real files
>
>> Pretty much over there uses postfix and postfix supports dovecot auth.
>> sendmail doesn't. I don't know how to separate the auth stuff.
> What does that mean. And what do you want to happen?
Meant to say pretty much everyone over on the dovecot list must be using
postfix, which has support for dovecot auth. I'd like to make sendmail
use cyrus sasl, and I don't really care what auth dovecot uses, but I'm
guessing it's inflexible so that it probably will use dovecot auth. The
suggestion to make them the same has been brought up, but all's I want
to use is the PAM mechanism.
>
>> I agree with you concerning the pam files being pretty simple. If I turn
>> off dovecot and try and connect to port 587, I get nothing including no
>> return.
> What does 'turn off dovecot' mean? And did you note the comment in sendmail.mc:
> ' Please remember that saslauthd needs to be running for AUTH'

turn off dovecot means "service dovecot stop" or
"/etc/rc.d/init.d/dovecot stop". saslauthd is still running and so is
sendmail. saslauthd is started at boot and I've made sure it really is
running using ps.
>
>> If I turn on dovecot, I get dovecot auth failures in my secure
>> logs. Sort of tells me that dovecot is taking over the auth processes
>> from sasl. I could be wrong.
> That would probably be a good thing, since you generally want the same
> people to authenticate the same way for imap and authenticated
> sending. Why not leave that part alone and focus on fixing it?

Believe me, if I knew where to start looking, I would. As far as
everything I've looked out, both should be using pam, but the auth file
for dovecot is a little cryptic to me. My fault, I know, but still I'm
not finding out a lot about it.

This is a great suggestion, and for the time being, I'll concentrate on
the auth config file for dovecot.

Sorry to all for sounding so buttish. Don't mean to be that way.

Thanks for all the help so far

steve
>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:43 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org