Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
Date: Thu, 26 Dec 2019 17:44:28
In Reply to: Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473 by Thomas Deutschmann
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?
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.
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.
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"?
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.
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.
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 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.
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.
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.
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.
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.