Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

[Thomas Deutschmann]

Hi,

On 2019-12-26 16:28, Michael Orlitzky wrote:
>> And would I really have to create my own acct-*/nginx user+group
>> ebuild to mirror my myapp use case? In other words: Thanks to GLEP
>> 81, in Gentoo, you can no longer use known default Linux utilities
>> like usermod to maintain your system and make changes to
>> users/groups created by packages, instead you will always have to
>> 'fork' involved acct-*/<user> package and adjust for your needs?
>
> That's right, but you're making it sound worse than it is. You also
> cannot use known default tools like rm, mv, cp, and your text editor
> to change things installed by system packages, because those changes
> will get overwritten the next time that the package is upgraded or
> reinstalled. Now user/group management works the same way.
>
> If you want to change something that belongs to the system, you
> override and tweak the package that installs it. It's consistent, and
> you don't have to tell people to install puppet/salt/etc. as a
> special case just to make users work like everything else. Those were
> always band-aids for the lack of a better way to do it.

Why can't I use rm, mv, cp or text editor to change things?

System configuration management is abstraction. You don't care about
details like if you are using Debian, RHEL or Gentoo. This is
implemented in used tool. You only define "states":

- Make sure user X is present and member of group Y.

- Make sure directory /var/foo exists and is owned by x:y.

- Make sure service Z is installed.

- Make sure your configuration for service Z is installed.

- Make sure service Z is enabled and running.

*You* don't need to know if you have to use apt, yum or emerge to get Z
installed. This is something the tool (puppet, ansible, salt, chef...)
will know and take care of. 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.

You can deploy your own configuration (=replace /etc/ssh/sshd_config) or
you can say "Make sure /etc/ssh/sshd_config contains 'PermitRootLogin
without-password'" or that "/etc/php/fpm-php7.4/ext-active/foo.ini" is
absent on Gentoo which will translate to "[[ ! -f
/var/lib/php/modules/7.4/fpm/disabled_by_admin/foo]] && phpdismod -v 7.4
-s fpm foo ]]"
on Debian.


>> Things like
>>
>> https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html
>>
>>
https://docs.ansible.com/ansible/latest/modules/user_module.html
>>
>> which are commonly used to apply configurations can't be used
>> anymore?!
>
> You don't need them any more, there's a better way to do it.

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.


> I don't completely understand your example, but it doesn't sound
> like something that should be particularly hard. Can you elaborate
> before I stick my foot in my mouth?

Heh :)

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.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5