[gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them
After a cursory scan of the Gentoo repository, I've noticed an
overabundance of start_stop_daemon_args being declared in scripts committed.
I would like to draw attention and see if we can clean these up together.
The reason why these are important is the modular nature of the
declarative syntax. For example, supervise-daemon should be available to
any user for a declarative script by simply adding
supervisor="supervise-daemon" to the corresponding conf.d file.
There are many necessary options like --wait or --env which don't have a
declarative replacement.
These comments are for scripts without a start/stop function defined
thereby relying on the default scripts in /lib/rc/sh/. There are other
advanced cases for sure. I just want to discuss easy to forget options.
Common mistakes included with start_stop_daemon_args:
"--background --make-pidfile" ("-b -m") should be replaced by
command_background="yes" (these are implied together)
"--user" and/or "--group" should be command_user="user:group" (use root
for user when only group is needed, the :group can be omitted)
"--chdir /path/to/foo" (-d) should be directory="/path/to/foo"
"--chroot /var/chroot/foo" (-r) should be chroot="/var/chroot/foo"
"--stdout /var/log/foo" (-1) should be output_log="/var/log/foo"
"--stderr /var/log/foo.err" (-2) should be error_log="/var/log/foo.err"
"--pidifle /run/foo.pid" (-p) should be pidfile="/run/foo.pid"
"--name foo" (-n) should be procname="foo"
"--exec" (-x) should be deleted as it is included by default when
command="" is declared (required to exist)
In addition, command_args may need to be reevaluated for each script to
split certain pieces out into command_args_foreground and
command_args_background.
command_args_foreground should include any options to force the
daemon/script into the foreground instead of forking.
command_args_background should include any option to fork a daemon and,
optionally, to have it write a pidfile to monitor. (Cannot be used
together with command_background option).
command_args should not include the conditions of the other two in most
cases.
If anyone would want me to do work in obvious cleanups, I am open to
bugs, patches or just committing.
Comments welcome.
Brian
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: x11-terms/lilyterm
Dear all the following packages are up for grabs after dropping desktop-misc: x11-terms/lilyterm https://packages.gentoo.org/packages/x11-terms/lilyterm Open bugs: x11-terms/lilyterm-0.9.9.4-r2 installs files into unexpected paths https://bugs.gentoo.org/811540 -- Best, Jonas
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
On 11/30/21 17:32, William Hubbs wrote: > On Tue, Nov 30, 2021 at 12:59:18PM +0100, Ulrich Mueller wrote: >>> On Tue, 30 Nov 2021, James Cloos wrote: >>> "UM" == Ulrich Mueller writes: >> UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine, >> UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999. >> >>> why do you thing gentoo is everyone's first or only dist on their >>> network? >>> or even on any given box? >> I was specifically asking about Gentoo infra there. >> >>> forcing existing boxen to change just because a new dist is added >>> is also unacceptable. >>> for me though, it would be enough if there is something i can add to >>> make.conf to ensure that the acct-user and acct-group builds avoid the >>> ranges i already use. >>> that may also work for others. >> UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always >> used for dynamic allocation of system accounts. GLEP 81 hasn't really >> changed anything there, except that the ebuild will now suggest an ID to >> try first. > This is the part of this that I don't understand. If we aren't enforcing > an ID, why do we care which ID to try first? It seems to be an > unnecessary step since users can pick the IDs they want by putting > settings in make.conf. At risk of sounding pithy, it could maybe be summed up as: 'because "Gentoo is about choice" (but a sensible default doesn't hurt).' As you say "users _can_ pick the IDs they want," but if they don't happen to want to, we've tried to pick defaults (which are even shared by other distributions where possible) so that there's a greater than zero chance that things will "just work" when the time comes for them to interoperate. As a user, despite having initially installed way before this was a thing, it seems nice. The new SBC (rockpro64) we installed last year or so has a much more consistent user setup now than the laptop which is just random. > > William -A OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] app-containers: new category
Discussed in https://archives.gentoo.org/gentoo-dev/message/67ecdd21af5eaddffd87e6707d54de61 Signed-off-by: Georgy Yakovlev --- app-containers/metadata.xml | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 app-containers/metadata.xml diff --git a/app-containers/metadata.xml b/app-containers/metadata.xml new file mode 100644 index ..c1a2b4e9a74a --- /dev/null +++ b/app-containers/metadata.xml @@ -0,0 +1,7 @@ + +https://www.gentoo.org/dtd/metadata.dtd;> + + + The app-containers category contains container related software. + + -- 2.34.1
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
On Tue, 2021-11-30 at 22:45 -0800, Alec Warner wrote: > > So questions from my side are: > Does your cluster not have human users? > Do the userids for the human users also not have to match between > hosts in the cluster? > > You can easily create ebuilds for the human users who access the system, and sets like @admins or @developers, so that all important user information is ultimately recorded by the package manager.
