1 |
On Sat, Jan 18, 2020 at 9:52 AM Michael Orlitzky <mjo@g.o> wrote: |
2 |
|
3 |
> We forbid packages from installing to /home for good reason: for most of |
4 |
> history, users (and their home directories) were outside the purview of |
5 |
> the package manager. But with GLEP81, that's changed: the package |
6 |
> manager is now in charge of creating each system user's home directory |
7 |
> and of giving it the correct permissions and ownership. |
8 |
> |
9 |
> Is the policy against installing to /home still consistent? |
10 |
> |
11 |
> For example: the mail-filter/amavisd-new daemon needs a user, typically |
12 |
> called "amavis". The daemon also needs a working directory that it can |
13 |
> write to. The obvious choice for a working directory is /var/lib/amavis, |
14 |
> but there's a catch: spamassassin, razor, pyzor, et cetera (which are |
15 |
> all used by amavis) store their configuration in the current user's home |
16 |
> directory, and not in some daemon-specific location. So "amavis" needs a |
17 |
> home directory, because that's where much of the configuration for |
18 |
> amavisd goes. |
19 |
> |
20 |
> Where do we put amavis's home directory? |
21 |
> |
22 |
> 1 /var/lib/amavis is a bad idea, because it conflicts with the working |
23 |
> directory (we don't want the two packages to get out of sync, nor do |
24 |
> we want to keep them in-sync manually). |
25 |
> |
26 |
> 2 /var/lib/amavis/home was my next choice, because logically it puts |
27 |
> the amavisd configuration in a subdirectory of the place where all |
28 |
> of the other amavis stuff goes, and because it doesn't have the |
29 |
> same issue that (1) does. |
30 |
> |
31 |
> But there's a problem: if we create /var/lib/amavis/home before |
32 |
> amavisd-new is installed (as happens when you emerge amavisd-new), |
33 |
> then /var/lib/amavis winds up root:root and the installation of |
34 |
> amavisd-new doesn't change that. So now amavisd-new doesn't work, |
35 |
> because it can't write to its working directory. |
36 |
> |
37 |
> This is a combination of an implementation detail and the fact that |
38 |
> the PMS doesn't cover directories; but ultimately, it just doesn't |
39 |
> work reliably. |
40 |
> |
41 |
> 3 /home/amavis also seems fine to me, except for the fact that it's a |
42 |
> QA violation to install there. |
43 |
> |
44 |
> Note that we could always set system users' home directories to |
45 |
> /home/whatever. It has only become a QA violation with GLEP81 because |
46 |
> the eclass calls keepdir on the user's home directory. |
47 |
> |
48 |
> Should option (3) be viable, or do I go back to the drawing board? |
49 |
> |
50 |
|
51 |
I tend to agree that in theory keeping the working directory and home |
52 |
directory the same is not ideal. However I'm not really aware of any |
53 |
practical problems. Haven't we basically run in this configuration for |
54 |
years? What kind of issues does it pose (outside of "well it sounds like |
55 |
not the best idea?") |
56 |
|
57 |
Agreeing with ulm here. I think the potential struggle for (3) is that |
58 |
conceptually /home is not always system specific. If /home is shared, you |
59 |
could end up with a bad time (e.g. I *don't* want /home/amavis shared |
60 |
across all my hosts, how would I manage multiple versions? Multiple |
61 |
configs?) Often all of /home is mounted and it becomes tricky to build |
62 |
workarounds. You could do things like "symlink /home/amavisd to some local |
63 |
path". At work we use /usr/local/google/home/$USER for this purpose; but it |
64 |
is basically a vestigial artifact from an earlier time than something we |
65 |
explicitly designed. |
66 |
|
67 |
Even the symlink solution is not ideal. NFS can present some exciting |
68 |
reliability issues and so having to touch NFS just to read the symlink |
69 |
(pointing locally) is probably not something I'd advise at scale; it would |
70 |
be simpler to change the users homedir to be elsewhere. Note that I'd |
71 |
expect large scale installs to do this anyway (I wouldn't rely on GLEP81 to |
72 |
manage users in an enterprise environment) but i'm not sure if the entire |
73 |
community shares that belief ;) |
74 |
|
75 |
-A |