From: Henning Schild <henning.schild@siemens.com>
To: Gylstorff Quirin <quirin.gylstorff@siemens.com>
Cc: "T. Schaffner" <tobias.schaffner@siemens.com>,
isar-users@googlegroups.com, michael.adler@siemens.com
Subject: Re: [PATCH 0/5] allow creation of users/groups before rootfs creation
Date: Wed, 25 Jan 2023 17:29:16 +0100 [thread overview]
Message-ID: <20230125172916.0d49528f@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <b026d2e3-98eb-f20b-606d-22d38b259852@siemens.com>
Am Wed, 25 Jan 2023 14:44:40 +0100
schrieb Gylstorff Quirin <quirin.gylstorff@siemens.com>:
> On 1/25/23 14:29, Henning Schild wrote:
> > Am Wed, 25 Jan 2023 10:01:51 +0100
> > schrieb "T. Schaffner" <tobias.schaffner@siemens.com>:
> >
> >> From: Tobias Schaffner <tobias.schaffner@siemens.com>
> >>
> >> This patch series will allow to specify a `pre` flag for the USER_
> >> and GROUP_ bitbake variables. If this flag is set to `true` the
> >> given user or group will be created in the rootfs configuration
> >> step instead of on rootfs postprocessing. This is helpful when a
> >> specific id should be used which would otherwise be picked by a
> >> user or group created by one of the installed packages.
> >
> > While i do understand the reason i am not sure how relevant that is.
> > Why would anything only function with a fixed ID? Whoever provided
> > that thing should maybe fix it.
>
> Specific IDs are necessary for Updating an A/B rootfs system with a
> persistent partition. In this case you do not want to change any IDs
> as this can lead to wrong file permissions.
I see, that is much more understandable. It also goes into the
reproducible build direction.
But if that is the case the solution does not seem to be good enough
because it only considers users/groups created by isar. Not the ones
created by installing debian packages. Where the order could be
potentially random. Say you DEBIAN_DEPENDS or IMAGE_PREINSTALL "ftpd
wwwd" which will craete users "ftp www" where the two deamons do not
have any dep on each other and apt-get could install them in any order.
That order might in reality not change too often but it could i.e. when
you move from debian11 to debian12 or when you bring the third (or
10th) user-adding package into your new firmware.
So what you maybe really want is giving isar an /etc/passwd /etc/group
pair. Every new firmware is build with the given layer code and that
file-pair from the first release. Where you inject those files between
bootstrap and install ... hoping that bootstrap will always be the same.
Maybe one can inject before bootstrap ... or write a postproc function
that will find all different ids and all files and fix up. Or at least
start with an assertion in postproc that looks at the old database.
Is the problem of uid/gid depend on install order known in the debian
community and how do others solve it? Gentoo has moved from such
dynamic allocation to static some years ago, probably for similar
reasons.
Henning
> >
> > So i am willing to say that this is super-niche! And it deserves a
> > niche-solution in its layer, not a feature in Isar.
> >
> > You could hook in a task between bootstrap and image_install. Or you
> > could rebuild a bootstrap package to have reserved ids. You could
> > run "the thing" in namespaces ...
> >
> > So is that really relevant? Please go into detail.
> >
> > Whatever happens i think the python rewrite is cool. But the code
> > may have been coming/inspired from OE ... in which case it would
> > not be cool, because it would fork away further.
>
>
> OE uses a complete different implementation than to original:
> https://git.openembedded.org/openembedded-core/tree/meta/classes/useradd.bbclass
>
> see also:
>
> https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
>
>
>
> Quirin
> >
> > Henning
> >
> >> A rewrite of the image-account-extension in python was done on the
> >> way. This allows us to drop a lot of encoding and parsing code that
> >> was used to transition to shell and therefore made it easier to
> >> read and maintain.
> >>
> >> Using python functions for more complex tasks allows us the usage
> >> of unittests. A very basic infrastructure for unittesting using
> >> the build in python unittest and the bb.parse module was added.
> >> This was used to test the re-implementation of the
> >> image-account-extension as a first showcase.
> >>
> >> Tobias Schaffner (5):
> >> simplify image-account-extension
> >> allow creation of users/groups before rootfs creation
> >> create a minimal python unittest infrastructure
> >> add unittests for the image-account-extension
> >> set minimal python version in user_manual to 3.5
> >>
> >> doc/user_manual.md | 4 +-
> >> meta/classes/image-account-extension.bbclass | 391
> >> +++++++----------- testsuite/unittests/README.md |
> >> 28 ++ testsuite/unittests/bitbake.py | 37 ++
> >> testsuite/unittests/rootfs.py | 45 ++
> >> .../unittests/test_image_account_extension.py | 175 ++++++++
> >> 6 files changed, 434 insertions(+), 246 deletions(-)
> >> create mode 100644 testsuite/unittests/README.md
> >> create mode 100644 testsuite/unittests/bitbake.py
> >> create mode 100644 testsuite/unittests/rootfs.py
> >> create mode 100644
> >> testsuite/unittests/test_image_account_extension.py
> >>
> >
>
>
>
>
next prev parent reply other threads:[~2023-01-25 16:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 9:01 T. Schaffner
2023-01-25 9:01 ` [PATCH 1/5] simplify image-account-extension T. Schaffner
2023-01-25 9:01 ` [PATCH 2/5] allow creation of users/groups before rootfs creation T. Schaffner
2023-01-25 9:01 ` [PATCH 3/5] create a minimal python unittest infrastructure T. Schaffner
2023-01-25 9:01 ` [PATCH 4/5] add unittests for the image-account-extension T. Schaffner
2023-01-25 9:01 ` [PATCH 5/5] set minimal python version in user_manual to 3.5 T. Schaffner
2023-01-25 13:29 ` [PATCH 0/5] allow creation of users/groups before rootfs creation Henning Schild
2023-01-25 13:44 ` Gylstorff Quirin
2023-01-25 16:29 ` Henning Schild [this message]
2023-01-25 20:55 ` Schaffner, Tobias
2023-01-25 21:38 ` Henning Schild
2023-01-26 8:21 ` Schaffner, Tobias
2023-01-26 8:48 ` Florian Bezdeka
2023-01-26 10:27 ` Henning Schild
2023-01-26 9:59 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230125172916.0d49528f@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=michael.adler@siemens.com \
--cc=quirin.gylstorff@siemens.com \
--cc=tobias.schaffner@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox