Re: [gentoo-dev] GLEP81 and /home

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3784 bytes --]

On Sat, Jan 18, 2020 at 9:52 AM Michael Orlitzky <mjo@gentoo.org> wrote:

> We forbid packages from installing to /home for good reason: for most of
> history, users (and their home directories) were outside the purview of
> the package manager. But with GLEP81, that's changed: the package
> manager is now in charge of creating each system user's home directory
> and of giving it the correct permissions and ownership.
>
> Is the policy against installing to /home still consistent?
>
> For example: the mail-filter/amavisd-new daemon needs a user, typically
> called "amavis". The daemon also needs a working directory that it can
> write to. The obvious choice for a working directory is /var/lib/amavis,
> but there's a catch: spamassassin, razor, pyzor, et cetera (which are
> all used by amavis) store their configuration in the current user's home
> directory, and not in some daemon-specific location. So "amavis" needs a
> home directory, because that's where much of the configuration for
> amavisd goes.
>
> Where do we put amavis's home directory?
>
>   1 /var/lib/amavis is a bad idea, because it conflicts with the working
>     directory (we don't want the two packages to get out of sync, nor do
>     we want to keep them in-sync manually).
>
>   2 /var/lib/amavis/home was my next choice, because logically it puts
>     the amavisd configuration in a subdirectory of the place where all
>     of the other amavis stuff goes, and because it doesn't have the
>     same issue that (1) does.
>
>     But there's a problem: if we create /var/lib/amavis/home before
>     amavisd-new is installed (as happens when you emerge amavisd-new),
>     then /var/lib/amavis winds up root:root and the installation of
>     amavisd-new doesn't change that. So now amavisd-new doesn't work,
>     because it can't write to its working directory.
>
>     This is a combination of an implementation detail and the fact that
>     the PMS doesn't cover directories; but ultimately, it just doesn't
>     work reliably.
>
>   3 /home/amavis also seems fine to me, except for the fact that it's a
>     QA violation to install there.
>
> Note that we could always set system users' home directories to
> /home/whatever. It has only become a QA violation with GLEP81 because
> the eclass calls keepdir on the user's home directory.
>
> Should option (3) be viable, or do I go back to the drawing board?
>

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?")

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? Multiple
configs?) Often all of /home is mounted and it becomes tricky to build
workarounds. You could do things like "symlink /home/amavisd to some local
path". At work we use /usr/local/google/home/$USER for this purpose; but it
is basically a vestigial artifact from an earlier time than something we
explicitly designed.

Even the symlink solution is not ideal. NFS can present some exciting
reliability issues and so having to touch NFS just to read the symlink
(pointing locally) is probably not something I'd advise at scale; it would
be simpler to change the users homedir to be elsewhere. Note that I'd
expect large scale installs to do this anyway (I wouldn't rely on GLEP81 to
manage users in an enterprise environment) but i'm not sure if the entire
community shares that belief ;)

-A

[-- Attachment #2: Type: text/html, Size: 4518 bytes --]