Hello,
I'm still trying to fix a problem I've had for a long time (started after an update) where mailman won't start from the standard init script. I think I have finally figured out what the problem is, but wanted to ask...
Is the mailman user supposed to be passwordless?
I know I'm running a non vanilla version, but my question is mostly generic I think...
Currently, the init script contains:
su - mailman -c '/bin/mailmanctl -s start' >/dev/null 2>&1
When I do this from a non-root account:
myuser@myhost ~ $ su - mailman -c '/bin/mailmanctl -s start' >/dev/null 2>&1
I see this in the log:
myhost su[6114]: pam_unix(su:auth): authentication failure; logname=myuser uid=1001 euid=0 tty=pts/2 ruser=myuser rhost= user=mailman myhost su[6114]: pam_authenticate: Authentication failure myhost su[6114]: FAILED su for mailman by myuser myhost su[6114]: - pts/2 myuser:mailman
My problem is I don't know how this works/is supposed to work. Is mailmans passwd supposed to be empty/blank? That seems like a bad idea, but if not, how is it supposed to start without giving the password for the mailman account somehow?
It starts fine if I start it from the command line as root, so it has to be something to do with the init script and/or permissions (the password for the mailman account)...
Thanks for any comments/thoughts...
tanstaafl@libertytrek.org writes:
Is the mailman user supposed to be passwordless?
AFAIK there is no need to log in as the mailman user, so that user should have no password (in the sense of "disabled", not in the sense of "zero-length string").
When I do this from a non-root account:
myuser@myhost ~ $ su - mailman -c '/bin/mailmanctl -s start' >/dev/null 2>&1
[it doesn't work as expected]
My problem is I don't know how this works/is supposed to work.
It's not supposed to work. mailman privileges should only be accessible by the system administrator, ie, someone who has the root password.
It starts fine if I start it from the command line as root,
That's how you're supposed to do it, if you need to do it.
so it has to be something to do with the init script and/or permissions (the password for the mailman account)...
It's not a problem with the password for the mailman user. :-)
The init script itself may be broken. AFAIK, the init script should be invoking the set-gid binary called "mailman" or "wrapper". This just cleans up the environment, changes the effective user id to mailman, and execs the command specified. (There's no good reason for *any* mailman program to be on anybody's PATH, so yes, just having /bin/mailmanctl makes your installation nonstandard.)
The best thing to do at this point is to run the check_perms script provided with mailman. It usually resides in $prefix/lib/mailman/bin, but since your installation is non-standard, you may have to search a bit.
On 8/2/2009 5:13 AM, Stephen J. Turnbull wrote:
Ah, ok, that makes sense...
Iirc, with gentoo it is only for the mailman user, so running the command as su - mailman gets the path/prefix...
I thought about doing that, but the 'authentication failure' I got in the logs was leading me to believe it was a mailman user passwd issue, but now, after your explanation and looking more closely at the error, I see it wasn't having trouble with the execution of the mailman start command, it was having trouble with the su - mailman command... man, I hate being so blind for a sighted person... ;)
I'll check this when I get into the office in a few hours...
Thanks Stephen...
tanstaafl@libertytrek.org writes:
First, if you're sure you know why Mark said what he did, consider him authoritative. (For future reference, Barry Warsaw and Brad Knowles should also be considered authoritative unless they disagree. [@Brad: I know you like to deprecate your expertise these days, but you don't spout off unless you do know, or at least provide appropriate caveats.] :-) Me? I'm definitely of the persuasion that it is better to be in error than in doubt. :-)
However, in this case, I was assuming that Mark simply took you at your word that mailmanctl lives in /bin, not in something like /usr/lib/mailman/bin (which is where it is on Debian; it is also visible at /var/lib/mailman/bin). My point was simply that normally Mailman functions are invoked from CGI scripts, the MTA, or an init script, so having the full path is not a burden. None of the Mailman servers I have access to have /bin/mailmanctl, so I believe it's nonstandard (at the very least I would expect it to be in /sbin, more likely /usr/sbin, and most likely, for the reasons mentioned, in none of them :-).
The word "nonstandard" was not meant to be critical of your setup, except as far as it makes our advice less accurate.
Or are you speaking strictly in terms of the fact that I'm on a gentoo system?
No. I do run Gentoo on my workstation, but my mailman server is on Debian, so I don't know about the Gentoo package. (My preference is to run the oldest OS that can run my services, and Debian stable fits that bill quite nicely. :-)
On 8/7/2009 5:44 AM, Stephen J. Turnbull wrote:
Hmmm... Mark didn't seem to agree... he said:
First, if you're sure you know why Mark said what he did, consider him authoritative.
Heh... I know enough to know that I'm not sure of anything...
In Gentoo, it lives in /usr/lib64/mailman/bin
The word "nonstandard" was not meant to be critical of your setup, except as far as it makes our advice less accurate.
I know, and no offense taken... I did say 'on gentoo'... I totally understand different distros do things differently. But I was using the init script that gentoo installed, and no one on the gentoo forums could figure out why it wouldn't start. Something broke during the 2.1.9 > 2.1.10 upgrade, and I've been trying to fix it ever since... well, I took a look at it for 15 or 20 minutes, 2 or 3 times (whenever I had to reboot) over the last 2 years, but since I could start it manually, and hardly ever reboot, it wasn't a priority.
There's an upgrade available for 2.1.12 now, so I'll see what happens when I upgrade this time. At least I'll know what to do if it changes the init script back and still won't start.
(My preference is to run the oldest OS that can run my services,
<shudder> I'm the exact opposite... ain't it grand that there's a distro for every one out there somewhere? ;)
--
Best regards,
Charles
I'm sorry, I missed the OP and can't at the moment check the archives...
On Aug 7, 2009, at 5:44 AM, Stephen J. Turnbull wrote:
I can't check my Gentoo or Ubuntu machines right now, but on my own
servers, I run Mailman from source anyway :).
But in any case, I do think mailmanctl should be in sbin or
equivalent, though most people will probably use an init.d script to
start and stop mailman.
It kind of sucks that there are so many other Mailman command line
scripts, which is one reason why I've always put them in a separate
Mailman specific bin directory. With MM3 though I intend to use a
'subcommand' approach so that there's only one 'mailman' command.
Think things like 'mailman listmembers foo'. I'll probably keep
mailmanctl separate though I haven't decided about that yet.
-Barry
On 8/7/2009, Mark Sapiro (mark@msapiro.net) wrote:
Exactly.
Ok, but... well, I didn't exactly say that, but yes, that was what the command in question showed.
It's been a while since I researched this, but the reasoning was that /usr/lib64/mailman was in the path for user mailman, and the command was executed as mailman user, so had the path, so the command only needed to be /bin/...
Anyway, this isn't a mailman issue anymore, so I won't say any more about it...
--
Best regards,
Charles
tanstaafl@libertytrek.org wrote:
Is the mailman user supposed to be passwordless?
It doesn't matter. It's up to you and your own policy.
This is the real issue. mailmanctl should always be run by root. Your init script should just contain
/bin/mailmanctl -s start >/dev/null 2>&1
without the su - mailman
You're supposed to start it as root. Unprivileged users aren't supposed to be able to start, stop, restart Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 8/2/2009, Mark Sapiro (mark@msapiro.net) wrote:
This is the real issue. mailmanctl should always be run by root.
Hmmm... ok, thanks.
So, on linux, when an init script runs at startup, it runs as root?
Ok, thanks, but I'll have to find out why the gentoo init script is written the way it is, just to make sure I don't break something if I change it.
Thanks Mark, your helpfulness is genuinely appreciated.
--
Best regards,
Charles
On 8/2/2009 10:05 AM, Mark Sapiro wrote:
Ok, I tried this, but it did the same thing... however, I tried something else - adding the full path to the command - and it now works:
su - mailman -c '/usr/lib64/mailman/bin/mailmanctl -s start' >/dev/null 2>&1
I'm assuming this is a gentoo issue, but if anyone here runs gentoo and might know whats up with this I'd appreciate a comment.
Thanks Mark! At least it works now. :)
--
Best regards,
Charles
tanstaafl@libertytrek.org writes:
Is the mailman user supposed to be passwordless?
AFAIK there is no need to log in as the mailman user, so that user should have no password (in the sense of "disabled", not in the sense of "zero-length string").
When I do this from a non-root account:
myuser@myhost ~ $ su - mailman -c '/bin/mailmanctl -s start' >/dev/null 2>&1
[it doesn't work as expected]
My problem is I don't know how this works/is supposed to work.
It's not supposed to work. mailman privileges should only be accessible by the system administrator, ie, someone who has the root password.
It starts fine if I start it from the command line as root,
That's how you're supposed to do it, if you need to do it.
so it has to be something to do with the init script and/or permissions (the password for the mailman account)...
It's not a problem with the password for the mailman user. :-)
The init script itself may be broken. AFAIK, the init script should be invoking the set-gid binary called "mailman" or "wrapper". This just cleans up the environment, changes the effective user id to mailman, and execs the command specified. (There's no good reason for *any* mailman program to be on anybody's PATH, so yes, just having /bin/mailmanctl makes your installation nonstandard.)
The best thing to do at this point is to run the check_perms script provided with mailman. It usually resides in $prefix/lib/mailman/bin, but since your installation is non-standard, you may have to search a bit.
On 8/2/2009 5:13 AM, Stephen J. Turnbull wrote:
Ah, ok, that makes sense...
Iirc, with gentoo it is only for the mailman user, so running the command as su - mailman gets the path/prefix...
I thought about doing that, but the 'authentication failure' I got in the logs was leading me to believe it was a mailman user passwd issue, but now, after your explanation and looking more closely at the error, I see it wasn't having trouble with the execution of the mailman start command, it was having trouble with the su - mailman command... man, I hate being so blind for a sighted person... ;)
I'll check this when I get into the office in a few hours...
Thanks Stephen...
tanstaafl@libertytrek.org writes:
First, if you're sure you know why Mark said what he did, consider him authoritative. (For future reference, Barry Warsaw and Brad Knowles should also be considered authoritative unless they disagree. [@Brad: I know you like to deprecate your expertise these days, but you don't spout off unless you do know, or at least provide appropriate caveats.] :-) Me? I'm definitely of the persuasion that it is better to be in error than in doubt. :-)
However, in this case, I was assuming that Mark simply took you at your word that mailmanctl lives in /bin, not in something like /usr/lib/mailman/bin (which is where it is on Debian; it is also visible at /var/lib/mailman/bin). My point was simply that normally Mailman functions are invoked from CGI scripts, the MTA, or an init script, so having the full path is not a burden. None of the Mailman servers I have access to have /bin/mailmanctl, so I believe it's nonstandard (at the very least I would expect it to be in /sbin, more likely /usr/sbin, and most likely, for the reasons mentioned, in none of them :-).
The word "nonstandard" was not meant to be critical of your setup, except as far as it makes our advice less accurate.
Or are you speaking strictly in terms of the fact that I'm on a gentoo system?
No. I do run Gentoo on my workstation, but my mailman server is on Debian, so I don't know about the Gentoo package. (My preference is to run the oldest OS that can run my services, and Debian stable fits that bill quite nicely. :-)
On 8/7/2009 5:44 AM, Stephen J. Turnbull wrote:
Hmmm... Mark didn't seem to agree... he said:
First, if you're sure you know why Mark said what he did, consider him authoritative.
Heh... I know enough to know that I'm not sure of anything...
In Gentoo, it lives in /usr/lib64/mailman/bin
The word "nonstandard" was not meant to be critical of your setup, except as far as it makes our advice less accurate.
I know, and no offense taken... I did say 'on gentoo'... I totally understand different distros do things differently. But I was using the init script that gentoo installed, and no one on the gentoo forums could figure out why it wouldn't start. Something broke during the 2.1.9 > 2.1.10 upgrade, and I've been trying to fix it ever since... well, I took a look at it for 15 or 20 minutes, 2 or 3 times (whenever I had to reboot) over the last 2 years, but since I could start it manually, and hardly ever reboot, it wasn't a priority.
There's an upgrade available for 2.1.12 now, so I'll see what happens when I upgrade this time. At least I'll know what to do if it changes the init script back and still won't start.
(My preference is to run the oldest OS that can run my services,
<shudder> I'm the exact opposite... ain't it grand that there's a distro for every one out there somewhere? ;)
--
Best regards,
Charles
I'm sorry, I missed the OP and can't at the moment check the archives...
On Aug 7, 2009, at 5:44 AM, Stephen J. Turnbull wrote:
I can't check my Gentoo or Ubuntu machines right now, but on my own
servers, I run Mailman from source anyway :).
But in any case, I do think mailmanctl should be in sbin or
equivalent, though most people will probably use an init.d script to
start and stop mailman.
It kind of sucks that there are so many other Mailman command line
scripts, which is one reason why I've always put them in a separate
Mailman specific bin directory. With MM3 though I intend to use a
'subcommand' approach so that there's only one 'mailman' command.
Think things like 'mailman listmembers foo'. I'll probably keep
mailmanctl separate though I haven't decided about that yet.
-Barry
Stephen J. Turnbull wrote:
However, in this case, I was assuming that Mark simply took you at your word that mailmanctl lives in /bin,
Exactly.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 8/7/2009, Mark Sapiro (mark@msapiro.net) wrote:
Exactly.
Ok, but... well, I didn't exactly say that, but yes, that was what the command in question showed.
It's been a while since I researched this, but the reasoning was that /usr/lib64/mailman was in the path for user mailman, and the command was executed as mailman user, so had the path, so the command only needed to be /bin/...
Anyway, this isn't a mailman issue anymore, so I won't say any more about it...
--
Best regards,
Charles
tanstaafl@libertytrek.org wrote:
Is the mailman user supposed to be passwordless?
It doesn't matter. It's up to you and your own policy.
This is the real issue. mailmanctl should always be run by root. Your init script should just contain
/bin/mailmanctl -s start >/dev/null 2>&1
without the su - mailman
You're supposed to start it as root. Unprivileged users aren't supposed to be able to start, stop, restart Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 8/2/2009, Mark Sapiro (mark@msapiro.net) wrote:
This is the real issue. mailmanctl should always be run by root.
Hmmm... ok, thanks.
So, on linux, when an init script runs at startup, it runs as root?
Ok, thanks, but I'll have to find out why the gentoo init script is written the way it is, just to make sure I don't break something if I change it.
Thanks Mark, your helpfulness is genuinely appreciated.
--
Best regards,
Charles
On 8/2/2009 10:05 AM, Mark Sapiro wrote:
Ok, I tried this, but it did the same thing... however, I tried something else - adding the full path to the command - and it now works:
su - mailman -c '/usr/lib64/mailman/bin/mailmanctl -s start' >/dev/null 2>&1
I'm assuming this is a gentoo issue, but if anyone here runs gentoo and might know whats up with this I'd appreciate a comment.
Thanks Mark! At least it works now. :)
--
Best regards,
Charles
participants (4)
-
Barry Warsaw -
Mark Sapiro -
Stephen J. Turnbull -
tanstaafl＠libertytrek.org