1 |
On 1/18/20 7:21 PM, Rich Freeman wrote: |
2 |
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@g.o> wrote: |
3 |
>> |
4 |
>> But now users have to follow one more step (create /home/amavis) when |
5 |
>> setting up amavisd-new. Is the QA check really assuring a quality user |
6 |
>> experience here? |
7 |
>> |
8 |
> |
9 |
> Lots of daemons need a home directory for their users, and usually |
10 |
> they manage to get by in /var/lib. It really seems like a bad |
11 |
> practice to start having packages creating stuff in /home. Certainly |
12 |
> I don't want random daemons sticking stuff in /home, which I manage |
13 |
> |
14 |
|
15 |
Let's restart: |
16 |
|
17 |
* The daemon DOES NOT need a home directory for its user. |
18 |
* I DO NOT want to install anything to anyone's home directory. |
19 |
* With respect to user.eclass, I'm proposing that /home be treated |
20 |
EXACTLY THE SAME as it always has been. |
21 |
|
22 |
All I want to do is *set* a user's home directory to /home/foo. |
23 |
|
24 |
Some people want to configure amavis to launch a program like pyzor, |
25 |
which uses per-user configuration files. If you want to do that, you |
26 |
first log in as amavis, and run some command like |
27 |
|
28 |
$ pyzor discover |
29 |
|
30 |
which then finds some servers and creates configuration files for you in |
31 |
$HOME/.pyzor. |
32 |
|
33 |
This is user configuration, not daemon configuration. It doesn't belong |
34 |
in the daemon's working directory. In particular, you should not be |
35 |
dicking around in the daemon's working directory when you run "su |
36 |
amavis..." because what you're doing is irrelevant to the daemon. |
37 |
|
38 |
Spamassassin itself is a better example than amavis. We already set the |
39 |
spamd user's home directory to /home/spamd with user.eclass. We don't |
40 |
install anything there, and this works fine. If a human logs into that |
41 |
account and generates some configuration in ~/.spamassassin, then it's |
42 |
within the spirit of the FHS to have that data stored in /home. |
43 |
|
44 |
Now, with GLEP 81, we get a QA warning for that, because the eclass |
45 |
installs a keepdir file there. I would like things to remain exactly as |
46 |
they are, with no QA warning. Otherwise, we have to tell users to move |
47 |
/home/spamd to /var/lib/spamd-home or something stupid like that. I can |
48 |
think of no good reason to do so. |
49 |
|
50 |
|
51 |
> It seems like the straightforward solution is to stick everything in |
52 |
> /var/lib/amavis, and fix things so that everything has the right |
53 |
> permissions regardless of install order. |
54 |
|
55 |
Please stop telling people to do this. Calling chown on the live |
56 |
filesystem is rarely safe, and I already fixed one root exploit (bug |
57 |
630836) in the amavisd-new ebuild from the last guy who tried to adjust |
58 |
wrong permissions after the fact. |
59 |
|
60 |
|
61 |
> Another option is to have /var/lib/amavis/home and /var/lib/amavis/work. |
62 |
|
63 |
This is better-looking than /var/lib/amavis-home, but it's still |
64 |
violating the spirit of the FHS to avoid triggering a warning on a dummy |
65 |
file. |