FS#2727 - fetchmail rc.d script

Attached to Project: Arch Linux
Opened by Hugo (Citral) - Thursday, 12 May 2005, 16:15 GMT
Last edited by Kevin Piche (kpiche) - Monday, 04 June 2007, 23:06 GMT
Task Type Feature Request
Category Packages: Current
Status Closed
Assigned To Kevin Piche (kpiche)
Architecture All
Severity Very Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

fetchmail doesn't have an rc.d script, even though it has a daemon capability. I always start fetchmail at boot to regularly download my mail.

This is just what I use (/etc/rc.d/fetchmail):
(Note: interval doesn't really matter because it reads a new interval from the config file)

#!/bin/bash

INTERVAL=60

. /etc/rc.conf
. /etc/rc.d/functions

PID=`pidof -o %PPID /usr/bin/fetchmail`
case "$1" in
start)
stat_busy "Starting fetchmail"
[ -z "$PID" ] && /usr/bin/fetchmail -d $INTERVAL -f /etc/fetchmailrc
if [ $? -gt 0 ]; then
stat_fail
else
#fetchmail does this for us:
#echo $PID > /var/run/fetchmail.pid
add_daemon fetchmail
stat_done
fi
;;
stop)
stat_busy "Stopping fetchmail"
[ ! -z "$PID" ] && kill $PID &> /dev/null
if [ $? -gt 0 ]; then
stat_fail
else
rm -f /var/run/fetchmail.pid
rm_daemon fetchmail
stat_done
fi
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "usage: $0 {start|stop|restart}"
esac
exit 0
This task depends upon

Closed by  Kevin Piche (kpiche)
Monday, 04 June 2007, 23:06 GMT
Reason for closing:  Implemented
Additional comments about closing:  Done in fetchmail 6.3.8-3
Comment by David Rosenstrauch (darose) - Friday, 15 September 2006, 03:02 GMT
I have this same issue, and am also using a home-grown rc.d script to run fetchmail as a daemon.

However, as of a recent upgrade, I'm now experiencing an additional, related problem.

When the fetchmail daemon starts, it outputs a message, something like:

Warning: running fetchmail as root is discouraged

The reason is obvious, but the solution is not. How might I modify the fetchmail start-up script to run as a user other than root?
Comment by Roman Kyrylych (Romashka) - Monday, 09 April 2007, 17:07 GMT
A request to re-open the task has been made. Reason for request: What about the issue I pointed out where fetchmail warns: WARNING: Running as root is discouraged. The start-up script really should not be run as root, but rather as user "nobody" or "fetchmail" or some such. Is there any way to do that in Arch?
Comment by Kevin Piche (kpiche) - Wednesday, 18 April 2007, 03:22 GMT
Added a config file /etc/conf.d/fetchmail. Added a new user "fetchmail" and modified the /etc/rc.d/fetchmail to su to fetchmail when starting the daemon.

Try it out. If I don't hear anything I'll close in a few days.
Comment by David Rosenstrauch (darose) - Wednesday, 18 April 2007, 12:30 GMT
OK, thanks for tackling this, Kevin. I'll try out the fix when I get a chance. But ...

Isn't this not the best approach for a fix like this? I thought I remember that su is not really something that you should use to run a daemon process, which could be running for days/weeks/months/years. I don't think that most other daemons which run as another user use su to do it. So I'd imagine that there's a better approach than this.

Is that actually the case? If so, how do most other daemons do it?


If we can't find a "correct" way to run the daemon under a different username, then we might want to consider another approach:

Instead of running fetchmail as a daemon, perhaps we should rip the daemon script out, and just modify the .install file to instruct the user how to set up fetchmail to run as a cron job.

What are your thoughts on all this, Kevin?
Comment by David Rosenstrauch (darose) - Friday, 20 April 2007, 03:03 GMT
Hmmm .... I guess you didn't have any thoughts on this, since you just went live with the solution you proposed. Not a great solution, IMO, frankly. I think just instructing users to run fetchmail as a cron job is better than using su.


Also, there's a bug in the 6.3.8-2 package: the daemon won't start. It reports an error:

File /etc/fetchmailrc must be owned by you.

Which I assume means it must be owned by the fetchmail user. It's currently owned by root.


Please take another look at this. I don't think the current solution is very good.
Comment by Kevin Piche (kpiche) - Friday, 20 April 2007, 14:52 GMT
No, I went live for people to try it out. People not using the start/stop script would not be affected.

The thing is there is no way to run fetchmail as non-root without using su. Other daemons like apache, squid, etc do this by starting as root but switching to an unpriviledged user themselves after binding to ports and opening key files. Fetchmail does not have the ability to switch users itself once started. I don't feel that using su is the best since an account with a valid shell is required but there is no other way except for using cron. Users should use whatever they feel comfortable with. As a note Debian uses su to start fetchmail as non-root in their script.

The file /etc/fetchmailrc is not provided by the script so users that want to run the rc.d script would have to change the ownership for it to work.
Comment by Roman Kyrylych (Romashka) - Friday, 20 April 2007, 14:57 GMT
> The file /etc/fetchmailrc is not provided by the script so users that want to run the rc.d script would have to change the ownership for it to work.
Then I think it would be nice to have this message in post_install.
Comment by David Rosenstrauch (darose) - Tuesday, 24 April 2007, 23:21 GMT
Thanks for the explanation, Kevin. I'm surprised to hear that Debian uses su for this as well, since I thought they generally use start-stop-daemon (which IIRC can change users) for this sort of thing. But I guess it makes sense to just use whatever works for now. The more important issues is that fetchmail not run as root.

So anyway, I installed the new version and started running it, and it seems to be working fine.

One other thing, though: I realize you said that /etc/fetchmailrc is not part of the package and so we shouldn't change the file ownership. But I think we can do better than either a) making the user change ownership manually, or b) outputting a message telling them to change it manually. Just check if the file exists, and if so, then this is obviously an upgrade from a previous version of fetchmail, so then change ownership on fetchmailrc. i.e.:

if [ -f /etc/fetchmailrc ] ; then chown fetchmail /etc/fetchmailrc; fi

or perhaps:

. /etc/conf.d/fetchmail
if [ -f $CONFIG ] ; then chown fetchmail $CONFIG; fi

(That would go after the "useradd fetchmail" command, of course.)

What do you think?
Comment by Kevin Piche (kpiche) - Tuesday, 15 May 2007, 23:58 GMT
Sorry for the late reply. I think I'll just put a message in the install script about the file ownership. I'm guessing users would not accept arbitrary file ownership changes especially if they're using the crontab method. Any objections?
Comment by David Rosenstrauch (darose) - Wednesday, 16 May 2007, 06:38 GMT
No. I don't feel too strongly either way.
Comment by Kevin Piche (kpiche) - Monday, 04 June 2007, 23:03 GMT
Added an install message about changing the ownership of /etc/fetchmailrc.

Loading...