mail/postfix: Use more FHS compliant /srv for data

[danielfdickinson]

Maintainer: Shulyaka@gmail.com (mail being sent with PR link once submitted)
Compile tested: x86_64, ar71xx
Run tested: likewise, ar71xx NETGEAR WND3800, basic local mail checked

Description:

/usr/var is very non-FHS compliant, /srv is a better choice for
working data, so move to more FHS-compliant /srv/var.

Signed-off-by: Daniel Dickinson lede@cshore.thecshore.com

[mhei]

Hi,

could you please elaborate, why do you think that /srv is a more FHS-compliant choice? I agree, that /usr is really the wrong place to put data there, but according to my understanding of the FHS, /srv is not even better, because its usage is to store data which is served from the system. On a usual Debian system, you will find the affected directories as /var/spool/postfix, /var/lib/postfix and /var/mail - and I really think would be the right locations.

So please share your minds in the commit message. I guess your concern is that /var is none-permanent on a OpenWrt/LEDE system, right?

Thanks, mhei

[Shulyaka]

Well, I have searched through other packages in the repo and it seems that only lxc and radicale packages use /srv at all. My test LEDE system also doesn't have /srv at all, so I can conclude that /srv is not widely used in OpenWRT/LEDE.

Yes, I have originally put data dir, queue dir and spool dir into /usr/var instead of /var because the latter is not persistant.

The values can be changed by configuration after the installation. Personally I don't find /srv to be a better default place. So what is the official OpenWRT/LEDE developers' position on this topic?

Best regards,
Denis Shulyaka

[mhei]

I think the reason for not widely-used /srv on OpenWrt/LEDE is that routers -in the original sense- does not provide services like e.g. FTP/Samba... with much user-changeable data. Thus there was simply no strong need for /srv hierarchy. Creating full-fledged systems leads to such "infrastructure requirements"...

I've the same feeling that /srv would not improve the current situation. However, I do not use this specific package on my systems, so I can only guess what the usual OpenWrt/LEDE user is expecting by the default installation. At least the following points should be considered:

• Is the user aware that /var is not persistent?
• When using /var -and this is usually RAM fs-, do we suffer from any memory limit?
• When using /srv and/or /usr, then the underlying fs is located often in flash. What about the erase cycle topic. Does the user care?

So my proposal would be to change the default to /var - thus making it not persistent. The idea is to not destroy the system e.g. with too much stress for the flash. However, we should put a "big red warning" into the config explaining the situation and thus force the user to change this to a persistent location, e.g. SD card/USB memory...

[danielfdickinson]

On Sun, 2016-08-14 at 11:39 -0700, Michael Heimpold wrote:

Hi,
could you please elaborate, why do you think that /srv is a more FHS-
compliant choice? I agree, that /usr is really the wrong place to put
data there, but according to my understanding of the FHS, /srv is not
even better, because its usage is to store data which is served from
the system. On a usual Debian system, you will find the affected
directories as /var/spool/postfix, /var/lib/postfix and /var/mail -
and I really think would be the right locations.
So please share your minds in the commit message. I guess your
concern is that /var is none-permanent on a OpenWrt/LEDE system,
right?

That's right.  On OpenWrt/LEDE /var is symlinked to /tmp so isn't
really available for things like mail spools.  Other packages like LXC
have already done this, but in response to you request to elaborate I'm
thinking those packages and this one should use symlinks to some other
location (e.g. /data/) from /var/xxxx rather than totally alter
the layout. 

OTOH I'm not sure that's in keeping with the reason for the FHS, and
whether it would be better to push OpenWrt / LEDE to do something
better with /var (I'm thinking that things like /var/lock, /var/run,
/var/state, etc would better be individually symlinked to tmpfs
(because of flash wear concerns) rather than a blanket /var symlink
that breaks FHS.

Regards,

Daniel

[danielfdickinson]

Doesn't seem to be of much interest