| View previous topic :: View next topic |
| Author |
Message |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
 Posted: Thu Jun 08, 2023 2:55 am Post subject: |
 |
|
| figueroa wrote: | | Thanks. I have 77 of those as *.conf files in /usr/lib/sysusers.d since October 2020, but I don't know how they work or how it was done before. |
Those files don't do anything unless systemd-sysusers is installed and something runs it. Gentoo systems with OpenRC and sys-apps/systemd with the sysusers USE flag unset don't have it.
| mv wrote: | | If you modify your /etc/{passwd,group,shadow,gshadow} directly or indirectly you are probably obliged to modify these files analogously or can otherwise expect troubles after the next emerges. |
I'm not sure about that. On Gentoo, the acct-user and acct-group eclasses create them with the same information that they use for the useradd and groupadd commands, i. e. they are kept in sync and ultimately the one source of truth are the ebuilds and their user overrides. And systemd's documentation claims that "systemd-sysusers will do nothing if the specified users or groups already exist or the users are members of specified groups".
I don't know why they are created in the first place, though, it's systemd-sysusers (on Gentoo systems that have it) who would seem to be duplicating the ebuilds' and eclasses' work.
| pjp wrote: | | The ebuilds contain information about each user/group. uid/gid, shell, etc. If Portage is the hammer, the ebuild solution is at least a functioning nail. Personally, I don't think it is a good solution to a "problem" that exists across all Unix-like systems. A generic solution would have been nice. |
The "problem" was keeping track of which packages need which users and groups, so it looks to me like any solution would necessarily be package manager-specific.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Thu Jun 08, 2023 3:11 am Post subject: |
|
|
| GDH-gentoo wrote: | | The "problem" was keeping track of which packages need which users and groups, so it looks to me like any solution would necessarily be package manager-specific. |
I don't agree with that conclusion. That would be similar enough to an application managing their own network addressing and ports. Package management could certainly query a tool to verify ti was configured sufficiently, and perhaps even request that user management set it up. But there is no inherent need for package management to absorb that functionality. To me, the two seem orthogonal to one another.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 08, 2023 6:41 am Post subject: |
|
|
| GDH-gentoo wrote: | | figueroa wrote: | | Thanks. I have 77 of those as *.conf files in /usr/lib/sysusers.d since October 2020, but I don't know how they work or how it was done before. |
Those files don't do anything unless systemd-sysusers is installed and something runs it. Gentoo systems with OpenRC and sys-apps/systemd with the sysusers USE flag unset don't have it. |
Oh, I did not know this. I thought portage is eventually using these files, e.g. when an ebuild wants to know under which id-number a certain user is actually installed.
So I was blaming gentoo falsely, and it is (again one more time) actually systemd which is responsible for an approach broken by concept.
| Quote: | | mv wrote: | | If you modify your /etc/{passwd,group,shadow,gshadow} directly or indirectly you are probably obliged to modify these files analogously or can otherwise expect troubles after the next emerges. |
I'm not sure about that. On Gentoo, the acct-user and acct-group eclasses create them with the same information that they use for the useradd and groupadd commands, i. e. they are kept in sync and ultimately the one source of truth are the ebuilds and their user overrides. |
I agree with the first part for that sentence, but not with anything after the "i.e.":
The files are initially correct, but there is nothing which keeps them in sync if the user modifies (directly or indirectly) the /etc/{passwd,shadow,group,gshadow} files - something which should be normal on any unix system. And BTW, the numbers given in the acct-* ebuilds are not necessary the ones used by the system (e.g. if this number is already used). Moreover, these numbers are sometimes colliding and sometimes changed without a version/revision bump: I know this very well, because whenever a new ebuild of these categories arrives, I install it (and then usually uninstall it again) to have a "full" passwd/group file: I had so many collisions and needs to re-install due to changed numbers - although Gentoo required announcements of these in the dev-list, it seems that nobody really checked them.
| Quote: | | pjp wrote: | | The ebuilds contain information about each user/group. uid/gid, shell, etc. If Portage is the hammer, the ebuild solution is at least a functioning nail. Personally, I don't think it is a good solution to a "problem" that exists across all Unix-like systems. A generic solution would have been nice. |
The "problem" was keeping track of which packages need which users and groups, so it looks to me like any solution would necessarily be package manager-specific. |
I was originally not speaking about the acct-* ebuilds. I think the same about them as apparently most people: They are not an ideal, but one can live with them.
My complaint was about the /usr/lib/sysusers.d which is simply a misconception. But now that I know that it is yet another systemd insanity, I am not surprised and (unfortunately) have to agree that gentoo has no other choice but to follow systemd here: If these files are really only used by systemd (and not by ebuilds as I was falsely afraid of), I also see no problem with it - only systemd users have to care about keeping these files in sync, but these are poor guy anyway... |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Jun 08, 2023 10:31 am Post subject: |
|
|
| mv wrote: |
I was originally not speaking about the acct-* ebuilds. I think the same about them as apparently most people: They are not an ideal, but one can live with them.
My complaint was about the /usr/lib/sysusers.d which is simply a misconception. But now that I know that it is yet another systemd insanity, I am not surprised and (unfortunately) have to agree that gentoo has no other choice but to follow systemd here: If these files are really only used by systemd (and not by ebuilds as I was falsely afraid of), I also see no problem with it - only systemd users have to care about keeping these files in sync, but these are poor guy anyway... |
The easy fix if you don't use systemd is:
| Code: | | INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd" |
Or what the wiki says:
| Code: | | INSTALL_MASK="/lib/systemd/*/*.service /usr/lib/systemd/*/*.service" |
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Thu Jun 08, 2023 2:44 pm Post subject: |
|
|
| stefan11111 wrote: | The easy fix if you don't use systemd is:
| Code: | | INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd" |
|
I think this is incomplete. I think you need to write if you don't use systemd or udev, because systemd-utils[udev] installs /lib/systemd/systemd-udevd as a symlink to /bin/udevadm, and /etc/init.d/udev expects to use /lib/systemd/systemd-udevd to start udev. (The init script also tries some other paths, which do not exist for me here, so the only reason openrc+udev+systemd-utils[udev] works for me here is because of a file that you are advocating be masked out.) This is likely why the Wiki recommends a more limited mask. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 08, 2023 5:34 pm Post subject: |
|
|
| stefan11111 wrote: | | mv wrote: | | [...] If these files are really only used by systemd (and not by ebuilds as I was falsely afraid of), I also see no problem with it[...] |
The easy fix if you don't use systemd is [...] |
As mentioned, there is nothing to fix. If it is used only by systemd, I am fine with having these files and do not care whether they match reality. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Jun 08, 2023 8:21 pm Post subject: |
|
|
| Hu wrote: | | stefan11111 wrote: | The easy fix if you don't use systemd is:
| Code: | | INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd" |
|
I think this is incomplete. I think you need to write if you don't use systemd or udev, because systemd-utils[udev] installs /lib/systemd/systemd-udevd as a symlink to /bin/udevadm, and /etc/init.d/udev expects to use /lib/systemd/systemd-udevd to start udev. (The init script also tries some other paths, which do not exist for me here, so the only reason openrc+udev+systemd-utils[udev] works for me here is because of a file that you are advocating be masked out.) This is likely why the Wiki recommends a more limited mask. |
That may be true. I don't use systemd, or anything related, including udev and tmpfiles.
What the wiki recomends should work for most setups.
Here is my full INSTALL_MASK, for anyone interested:
| Code: | INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev /usr/share/icons /usr/share/applications"
|
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
