Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
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-*/ 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.
Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
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-*/ 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-*/ 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
On 12/26/19 9:41 AM, Thomas Deutschmann wrote: > > which would remove nginx from myapp group to match ACCT_USER_GROUPS set > in acct-*/nginx ebuild which would break my application server. Does > that really happen? Yes; if we want to be able to add/remove groups in acct-user ebuilds, then that's the only possible thing it could do. > 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-*/ > 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. > > 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. > Which will become funny if you are maintaining multiple systems: On one > system you have said "myapp", but on another system you would have a > second application named "myapp2". So you cannot even share repositories > between your systems anymore or would have to ensure somehow that system > A which acts as application server for "myapp" will only get > acct-*/- and system B which will > act as application server for "myapp2" will get > acct-*/- instead?! Not > to mention what will happen if you get a third system which will be able > to run multiple nginx instances, one for myapp and one for myapp2... ;] 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?
Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
On 2019-12-26 14:42, Michael Orlitzky wrote:
> So before you push this, I would figure out what you want the Jenkins
> user to look like on your machine, and add an -r1 of acct-user/jenkins
> in a local overlay that configures it how you want. At that point, you
> can drop the usermod calls from your configuration management tools.
>
> For the benefit of those other users, it would be extra nice if you
> could document how to do all that. I recently had to do the same thing
> for OpenDKIM, because the old instructions that were gave were being
> wiped out on upgrades and reinstalls:
>
> https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way
>
> Then if the home directory is only needed by people who are going to be
> overriding the acct-user ebuild anyway, you might as well leave
> ACCT_USER_HOME at the default and let people set it in their overlays.
Now, after reading the wiki for OpenDKIM I am more concerned than
before: We are also changing groups?!
Let me show you an example:
System has www-servers/nginx installed which created nginx user+group
via user eclass.
Now let's say I have a custom application for which I created user+group
"myapp".
I add nginx user to myapp group to allow nginx to access files from
myapp to serve application.
My current understanding is that during www-servers/nginx migration to
GLEP-81, i.e. when www-servers/nginx ebuild will pull in acct-user/nginx
and acct-group/nginx for the first time, the acct-* thing will do
local groups=${ACCT_USER_GROUPS[*]}
esetgroups "${ACCT_USER_NAME}" "${groups// /,}"
which would remove nginx from myapp group to match ACCT_USER_GROUPS set
in acct-*/nginx ebuild which would break my application server. Does
that really happen?
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-*/
package and adjust for your needs?
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?!
Which will become funny if you are maintaining multiple systems: On one
system you have said "myapp", but on another system you would have a
second application named "myapp2". So you cannot even share repositories
between your systems anymore or would have to ensure somehow that system
A which acts as application server for "myapp" will only get
acct-*/- and system B which will
act as application server for "myapp2" will get
acct-*/- instead?! Not
to mention what will happen if you get a third system which will be able
to run multiple nginx instances, one for myapp and one for myapp2... ;]
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
On 12/26/19 8:28 AM, Thomas Deutschmann wrote:
> On 2019-12-26 12:04, Michael Orlitzky wrote:
>> On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
>>> +ACCT_USER_HOME=/var/lib/jenkins
>> Needed?
>
> I cannot answer that for sure. In *my* setups I need a valid home for
> standard SSH setup (~/.ssh/authorized_keys). But there are dozen ways
> how you can run and use Jenkins...
>
> For myself I am probably not going to use Gentoo's acct-* stuff. While
> *I* need valid HOME for jenkins' user to get working SSH setup without
> any additional configuration I also store services in
> /srv/ instead of /var/lib. I am still scared to death
> that when I change HOME (usermod) which is part of my Salt state
> (configuration management) that acct-* stuff will revert at some point
> and break dozen of clusters ;]
>
Unless you override acct-{user,group}/jenkins, you won't really be safe.
Every time the package is installed -- particularly, the first time --
it's going to clobber the existing user's settings. This is true for
everyone using Jenkins in those dozens of different ways.
So before you push this, I would figure out what you want the Jenkins
user to look like on your machine, and add an -r1 of acct-user/jenkins
in a local overlay that configures it how you want. At that point, you
can drop the usermod calls from your configuration management tools.
For the benefit of those other users, it would be extra nice if you
could document how to do all that. I recently had to do the same thing
for OpenDKIM, because the old instructions that were gave were being
wiped out on upgrades and reinstalls:
https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way
Then if the home directory is only needed by people who are going to be
overriding the acct-user ebuild anyway, you might as well leave
ACCT_USER_HOME at the default and let people set it in their overlays.
Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
On 2019-12-26 12:04, Michael Orlitzky wrote: > On 12/25/19 10:11 AM, Thomas Deutschmann wrote: >> +ACCT_USER_HOME=/var/lib/jenkins > Needed? I cannot answer that for sure. In *my* setups I need a valid home for standard SSH setup (~/.ssh/authorized_keys). But there are dozen ways how you can run and use Jenkins... For myself I am probably not going to use Gentoo's acct-* stuff. While *I* need valid HOME for jenkins' user to get working SSH setup without any additional configuration I also store services in /srv/ instead of /var/lib. I am still scared to death that when I change HOME (usermod) which is part of my Salt state (configuration management) that acct-* stuff will revert at some point and break dozen of clusters ;] -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
On 12/25/19 10:11 AM, Thomas Deutschmann wrote: > +ACCT_USER_HOME=/var/lib/jenkins Needed?
[gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473
Package-Manager: Portage-2.3.82, Repoman-2.3.20 Signed-off-by: Thomas Deutschmann --- acct-user/jenkins/jenkins-0.ebuild | 13 + acct-user/jenkins/metadata.xml | 12 2 files changed, 25 insertions(+) create mode 100644 acct-user/jenkins/jenkins-0.ebuild create mode 100644 acct-user/jenkins/metadata.xml diff --git a/acct-user/jenkins/jenkins-0.ebuild b/acct-user/jenkins/jenkins-0.ebuild new file mode 100644 index 000..b3f9a003cd6 --- /dev/null +++ b/acct-user/jenkins/jenkins-0.ebuild @@ -0,0 +1,13 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="Jenkins program user" +ACCT_USER_ID=473 +ACCT_USER_HOME=/var/lib/jenkins +ACCT_USER_HOME_PERMS=0750 +ACCT_USER_GROUPS=( jenkins ) +acct-user_add_deps diff --git a/acct-user/jenkins/metadata.xml b/acct-user/jenkins/metadata.xml new file mode 100644 index 000..de8ce22b371 --- /dev/null +++ b/acct-user/jenkins/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + patr...@gentoo.org + Patrick Lauer + + + gra...@gentoo.org + Hans de Graaff + + -- 2.24.1
