1 |
On 12/26/19 11:56 AM, Thomas Deutschmann wrote: |
2 |
> |
3 |
> Why can't I use rm, mv, cp or text editor to change things? |
4 |
|
5 |
If you change a file belonging to a system package, then the next time |
6 |
you upgrade or reinstall that package, your changes get overwritten. |
7 |
|
8 |
|
9 |
> System configuration management is abstraction. You don't care about |
10 |
> details like if you are using Debian, RHEL or Gentoo... You will |
11 |
> probably manage a mapping of package names on your own so that you |
12 |
> can always say "Install Z" but on Debian your configuration |
13 |
> management tool will install openssh-server and on Gentoo it will |
14 |
> just be a package named net-misc/openssh. |
15 |
|
16 |
I get that (I've used these tools), but the abstraction is always leaky. |
17 |
At some point, you wind up managing the differences between the target |
18 |
systems yourself, just like with your package-name example. Is the |
19 |
difference between "emerge acct-user/foo" and "useradd foo" really that |
20 |
much greater than "emerge openssh" versus "apt-get install openssh-server"? |
21 |
|
22 |
Presumably your company overlay (mentioned later) is automatically |
23 |
installed on your Gentoo machines, after which everything is already |
24 |
abstracted for you and your CM tool doesn't need to do anything special. |
25 |
If it knows how to install acct-user/nginx in the first place (to |
26 |
satisfy the "user must exist" requirement), then it knows how to install |
27 |
your overlay copy of it. Or if it knows to install nginx, then the |
28 |
package manager will pull in your overlay user as a dependency. |
29 |
|
30 |
|
31 |
> Ever deployed a custom Tomcat application for example? Sure, you have |
32 |
> dozen ways to do that. Like dev-util/jenkins-bin, you could create your |
33 |
> own package. But if you have to maintain various operating systems you |
34 |
> will write a role/state, see above. Or if this is your own in-house |
35 |
> application it could be easier that your CI pipline will just copy to |
36 |
> /srv/myapp/$buildid on each application server and to flip |
37 |
> /srv/myapp/current symlink so you can update/rollback in seconds and to |
38 |
> support staggered deployment. |
39 |
> |
40 |
> My point is, it's pointless to say there are better ways. Making Gentoo |
41 |
> special because you can't use well established things which are working |
42 |
> on every other distribution and would require that everyone would |
43 |
> rewrite their states/roles and/or implement something new just to keep |
44 |
> Gentoo supported is not going to happen. |
45 |
|
46 |
The old way still works fine, so long as you don't want to modify a user |
47 |
in ::gentoo. We do run Tomcat applications (against my... everything), |
48 |
and I still use useradd to create the www.example.com users they run as. |
49 |
In the future, I'll create acct-user ebuilds for them in our overlay -- |
50 |
I already wrote ebuilds to pull in their java dependencies; might as |
51 |
well pull in the user accounts, too. That WORKSFORME because we only |
52 |
have Gentoo servers; but if we didn't, the old way would continue to |
53 |
work just fine. |
54 |
|
55 |
You only need to change something when you want to modify a system user. |
56 |
In the past, you could usermod them and the changes would stick. Now, |
57 |
you have to override the ebuild in an overlay. But once you override the |
58 |
acct-user package, you're back where you started and whatever you were |
59 |
going to do in the first place should work. |
60 |
|
61 |
|
62 |
> In you example user would have to fork acct-*/<user/group> package in |
63 |
> his/her overlay to adjust for his/her needs. At the moment, all larger |
64 |
> Gentoo setups I am aware of are maintaining a company repository in |
65 |
> addition to the official Gentoo repository. So they would put |
66 |
> acct-user/nginx-0-r1 and acct-group/nginx-0-r1 in that repository with |
67 |
> their changes. But this doesn't work if you have multiple different |
68 |
> nginx instances for example. Sure, the forked acct-* packages would work |
69 |
> for all the application servers running this specific role/state. But |
70 |
> these adjusted packages would be wrong for the servers running grafana |
71 |
> role/state, i.e. running www-apps/grafana-bin behind www-servers/nginx |
72 |
> proxy. So you would end up with multiple acct-*/nginx ebuilds for each |
73 |
> configuration which can't be right. Whereas at the moment you will use |
74 |
> your configuration management tool to get things into describe state. |
75 |
|
76 |
|
77 |
Ok, I understand now. This is a little more clumsy than I'd like, but is |
78 |
still doable using standard ebuild tools. In your company overlay, |
79 |
create a copy of acct-group/nginx, but then add a few USE flags that |
80 |
control the extra roles. You can then use your configuration management |
81 |
tool to push out the corresponding setting to /etc/portage/package.use. |
82 |
|
83 |
It's clumsy because you can't put USE dependencies in ACCT_USER_GROUPS, |
84 |
but these are just ebuilds after all. You can edit (R)DEPEND yourself to |
85 |
make it do exactly what you want. |