[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
From:       Michael Orlitzky <mjo () gentoo ! org>
Date:       2019-12-26 17:44:20
Message-ID: f6c12e01-6eb2-5c9a-9fc6-bf59f428167e () gentoo ! org
[Download RAW message or body]

On 12/26/19 11:56 AM, Thomas Deutschmann wrote:
> 
> Why can't I use rm, mv, cp or text editor to change things?

If you change a file belonging to a system package, then the next time
you upgrade or reinstall that package, your changes get overwritten.


> System configuration management is abstraction. You don't care about 
> details like if you are using Debian, RHEL or Gentoo... You will
> probably manage a mapping of package names on your own so that you
> can always say "Install Z" but on Debian your configuration
> management tool will install openssh-server and on Gentoo it will
> just be a package named net-misc/openssh.

I get that (I've used these tools), but the abstraction is always leaky.
At some point, you wind up managing the differences between the target
systems yourself, just like with your package-name example. Is the
difference between "emerge acct-user/foo" and "useradd foo" really that
much greater than "emerge openssh" versus "apt-get install openssh-server"?

Presumably your company overlay (mentioned later) is automatically
installed on your Gentoo machines, after which everything is already
abstracted for you and your CM tool doesn't need to do anything special.
If it knows how to install acct-user/nginx in the first place (to
satisfy the "user must exist" requirement), then it knows how to install
your overlay copy of it. Or if it knows to install nginx, then the
package manager will pull in your overlay user as a dependency.


> Ever deployed a custom Tomcat application for example? Sure, you have
> dozen ways to do that. Like dev-util/jenkins-bin, you could create your
> own package. But if you have to maintain various operating systems you
> will write a role/state, see above. Or if this is your own in-house
> application it could be easier that your CI pipline will just copy to
> /srv/myapp/$buildid on each application server and to flip
> /srv/myapp/current symlink so you can update/rollback in seconds and to
> support staggered deployment.
> 
> My point is, it's pointless to say there are better ways. Making Gentoo
> special because you can't use well established things which are working
> on every other distribution and would require that everyone would
> rewrite their states/roles and/or implement something new just to keep
> Gentoo supported is not going to happen.

The old way still works fine, so long as you don't want to modify a user
in ::gentoo. We do run Tomcat applications (against my... everything),
and I still use useradd to create the www.example.com users they run as.
In the future, I'll create acct-user ebuilds for them in our overlay --
I already wrote ebuilds to pull in their java dependencies; might as
well pull in the user accounts, too. That WORKSFORME because we only
have Gentoo servers; but if we didn't, the old way would continue to
work just fine.

You only need to change something when you want to modify a system user.
In the past, you could usermod them and the changes would stick. Now,
you have to override the ebuild in an overlay. But once you override the
acct-user package, you're back where you started and whatever you were
going to do in the first place should work.


> In you example user would have to fork acct-*/<user/group> package in
> his/her overlay to adjust for his/her needs. At the moment, all larger
> Gentoo setups I am aware of are maintaining a company repository in
> addition to the official Gentoo repository. So they would put
> acct-user/nginx-0-r1 and acct-group/nginx-0-r1 in that repository with
> their changes. But this doesn't work if you have multiple different
> nginx instances for example. Sure, the forked acct-* packages would work
> for all the application servers running this specific role/state. But
> these adjusted packages would be wrong for the servers running grafana
> role/state, i.e. running www-apps/grafana-bin behind www-servers/nginx
> proxy. So you would end up with multiple acct-*/nginx ebuilds for each
> configuration which can't be right. Whereas at the moment you will use
> your configuration management tool to get things into describe state.


Ok, I understand now. This is a little more clumsy than I'd like, but is
still doable using standard ebuild tools. In your company overlay,
create a copy of acct-group/nginx, but then add a few USE flags that
control the extra roles. You can then use your configuration management
tool to push out the corresponding setting to /etc/portage/package.use.

It's clumsy because you can't put USE dependencies in ACCT_USER_GROUPS,
but these are just ebuilds after all. You can edit (R)DEPEND yourself to
make it do exactly what you want.

[prev in list] [next in list] [prev in thread] [next in thread]