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
Opened by Hugo (Citral) - Thursday, 12 May 2005, 16:15 GMT
Last edited by Kevin Piche (kpiche) - Monday, 04 June 2007, 23:06 GMT
|
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
Monday, 04 June 2007, 23:06 GMT
Reason for closing: Implemented
Additional comments about closing: Done in fetchmail 6.3.8-3
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?
Try it out. If I don't hear anything I'll close in a few days.
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?
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.
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.
Then I think it would be nice to have this message in post_install.
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?