1 |
On 1/18/20 2:03 PM, Alec Warner wrote: |
2 |
> |
3 |
> I tend to agree that in theory keeping the working directory and home |
4 |
> directory the same is not ideal. However I'm not really aware of any |
5 |
> practical problems. Haven't we basically run in this configuration for |
6 |
> years? What kind of issues does it pose (outside of "well it sounds like |
7 |
> not the best idea?") |
8 |
|
9 |
There have been numerous bugs and mailing list discussions about the |
10 |
problems it causes, but it's kind of a moot point here. The best reason |
11 |
to avoid re-using /var/lib/amavis as the daemon's home directory is |
12 |
because it really is treated like a home directory by all of these |
13 |
packages, and we shouldn't dump a user's dotfiles into a daemon's |
14 |
working directory without a good reason. |
15 |
|
16 |
(We haven't been running this configuration for years, because we |
17 |
haven't had the GLEP81 eclasses that clobber your permissions for years.) |
18 |
|
19 |
|
20 |
> Agreeing with ulm here. I think the potential struggle for (3) is that |
21 |
> conceptually /home is not always system specific. If /home is shared, |
22 |
> you could end up with a bad time (e.g. I *don't* want /home/amavis |
23 |
> shared across all my hosts, how would I manage multiple versions? |
24 |
|
25 |
All of the upstream packages treat $HOME as user configuration. If you |
26 |
want to run two different daemons with two different configurations and |
27 |
if those configurations are sourced from $HOME, then you make two |
28 |
different users. There is no problem here. |
29 |
|
30 |
I'm willing to pick something like /var/lib/amavis-home, but that's |
31 |
clearly just second-guessing the administrator and putting a home |
32 |
directory somewhere it doesn't belong to avoid a QA warning. |
33 |
|
34 |
We have a similar situation with spamd in spamassassin itself, and I'd |
35 |
rather not maintain my own fake /home hierarchy as /var/lib/$user-home. |