[Bug 249860] mail/fetchmail: rc.conf overrides set daemon interval

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249860

Matthias Andree <mandree at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #218297|0                           |1
        is obsolete|                            |
                 CC|                            |mandree at FreeBSD.org
           Assignee|ports-bugs at FreeBSD.org      |mandree at FreeBSD.org
 Attachment #218317|                            |maintainer-approval?(chalpi
              Flags|                            |n at cs.wisc.edu)

--- Comment #2 from Matthias Andree <mandree at FreeBSD.org> ---
Created attachment 218317
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=218317&action=edit
revised patch/overhaul of fetchmail.in

I've added some documentation to the comments of files/fetchmail.in and while
writing that, I've figured that we have a similar situation for the logging
facility (--syslog vs. --logfile) where we need to make a similar change.

I've also found that the root/$fetchmail_user split can skew our results
because a fetchmail --configdump run as root from the script may refuse output
with this error message (I am running the script as root and fetchmailrc is
owned by fetchmail):

  File /usr/local/etc/fetchmailrc must be owned by you.

Consequence: we need to add su -m $user -c sh to our fetchmail --configdump
runs.

Then, the script does not change the "name" variable to fetchmail_$user but
isn't written that way, so we manually need to pull up the typical rc.subr
variables, for instance, ${name}_env from ${name}_${user}_env. Added.

I've pondered the fetchmail_home_prefix, too - we can safely query the actual
home directory (rather than second-guess and make something up) with

  getent passwd $fetchmail_user | cut -f6 -d:

Added.

Also, the global run will lose the user name because the user variable is
unset, and I've replaced it with $name, but not tested the output cosmetically.

In case passwords are missing, the rcfile will stall the boot interactively, so
I've added exec </dev/null.  If it is acceptable to you, this may need to be
added to UPDATING, too, so that people know to put the passwords into .netrc or
their config files.

I've found that we clobber existing fetchmail_flags in rc.conf, so we'd negate
effects of a fetchmail_flags=-v, for instance.

Finally, the script isn't exactly logical to read and the two huge outer
if/else blocks are both reversed from the natural reading direction where I'd
like to get the general idea first and then the nitty-gritty details, and I
question that we really need to recurse the script into itself when
fetchmail_users is blank and it does something like $fetchmail_script start
root GLOBALCONFIG. Haven't thought this through...

Essentially I've run out of time for now but would like to propose my current
working state for your review and comments.

-- 
You are receiving this mail because:
You are the assignee for the bug.