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