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