On Sun, Oct 13, 2019 at 10:25:04PM -0500, Bruce Dubbs via blfs-dev wrote:
> On 10/13/19 7:17 PM, Ken Moffat via blfs-dev wrote:
> > For a long time, fetchmail has warned about running as root.
> >
> > I'm sure that the organization made sense, but not convinced that
> > most of these are now other than random choices. So, is there any
> > logic which escapes me, or else any preference for where fetchmail
> > would best fit ?
>
> Yes. The mail related groups are in the 30s. I'd say 38 would be OK. The
> kdm user/group (37) is a bit out of place, but it is obsolete and should be
> removed.
>
Thanks. Although in my comments below I'm forming the view that
running the daemon is not the way many people will want to go,
changing the ownership still sounds like a good idea.
> However, I am not very familiar with fetchmail. I thought it ran on a
> per-user basis. Looking at the man page, it does discuss running in daemon
> mode.
>
I see that the BLFS pages shows how individual users can run it.
Arguably, for a real multiuser system a bootscript or systemd
service is not appropriate (the password per account is in plain
text in /etc/fetchmailrc, although I'm sure that an admin could
probably read users' fetchmailrc files unless their security
measures prevent that).
Looking at what gurgle finds, the general use-case for running a
daemon is to retrieve mail from multiple accounts at different sites
and forward it to a singel local user who hapens to own the box.
>
> I suppose that a boot script would be appropriate. It should start after
> networking is set up and after dns if that is local. Anything after S22 and
> before K49 seems appropriate to me.
>
> The daemon time in the man page specifies 900 seconds as a default. That's
> probably OK. It also says that specifying fetchmail will wake up the daemon
> but it is unclear to me how the daemon interacts with multiple users.
>
Me neither. Whilst changing the ownership adds a further level of
security, I'm starting to think that a bootscript is not the correct
method.
But it will be some time before I progress further - apart from
needing to get new hardware for my local server upgrade, I now see
that the SSD on this machine seems to be becoming problematic,
various stalls in the past few days like:
[63831.473366] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[63831.473371] ata1.00: failed command: FLUSH CACHE EXT
[63831.473375] ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 30
res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4
(timeout)
[63831.473376] ata1.00: status: { DRDY }
[63831.473379] ata1: hard resetting link
[63831.944370] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[63831.950103] ata1.00: configured for UDMA/133
[63831.950105] ata1.00: retrying FLUSH 0xea Emask 0x4
[63831.960336] ata1: EH complete
But I only notice these if I'm sat at the machine trying to do
something, and the only apparent problem in smartctl is a series of
# 1 Extended offline Interrupted (host reset) 00% 2079 -
(short test was ok, but last completed extended test was over 300
hours ago). So, for the moment I'm concentrating on backups and
then I'll be looking for a drive.
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
