public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"Kowalsky, Clara" <clara.kowalsky@siemens.com>
Cc: "Schmidt, Adriaan" <adriaan.schmidt@siemens.com>
Subject: Re: [RFC PATCH v2] fix: rebuild rootfs on change of USERS
Date: Fri, 11 Apr 2025 11:04:58 +0000	[thread overview]
Message-ID: <730a8e283bca5ce2fced7f7fdfbe76507a28371f.camel@siemens.com> (raw)
In-Reply-To: <76c8caa7-57d1-44ef-ba89-1dd4b57e9b11@siemens.com>

On Fri, 2025-04-11 at 12:18 +0200, Clara Kowalsky wrote:
> 
> 
> On 11.04.25 12:16, Clara Kowalsky wrote:
> > In case a change to the Isar created users is done, this currently
> > only re-triggers the do_rootfs_postprocess task. This task changes
> > the
> > rootfs (e.g. home dirs are moved) and by that needs to operate on a
> > clean one. Otherwise old homedirs might still remain in the final
> > rootfs
> > or move operations are not possible.
> > 
> > We fix this by ensuring that the do_rootfs_install task is executed
> > whenever a change to USERS is done. By that, we enter the
> > do_rootfs_postinstall with a clean rootfs.
> > 
> > Signed-off-by: Clara Kowalsky <clara.kowalsky@siemens.com>
> > ---
> >   meta/classes/image-account-extension.bbclass | 14 +++++++++-----
> >   1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/meta/classes/image-account-extension.bbclass
> > b/meta/classes/image-account-extension.bbclass
> > index ea956cd5..1c664be0 100644
> > --- a/meta/classes/image-account-extension.bbclass
> > +++ b/meta/classes/image-account-extension.bbclass
> > @@ -11,11 +11,11 @@ GROUPS ??= ""
> >   python() {
> >       for entry in (d.getVar("GROUPS") or "").split():
> >           group_entry = "GROUP_{}".format(entry)
> > -        d.appendVarFlag("image_postprocess_accounts", "vardeps", "
> > {}".format(group_entry))
> > +        d.appendVarFlag("image_postprocess_groups", "vardeps", "
> > {}".format(group_entry))
> >   
> >       for entry in (d.getVar("USERS") or "").split():
> >           user_entry = "USER_{}".format(entry)
> > -        d.appendVarFlag("image_postprocess_accounts", "vardeps", "
> > {}".format(user_entry))
> > +        d.appendVarFlag("image_postprocess_users", "vardeps", "
> > {}".format(user_entry))
> >   }
> >   
> >   def image_create_groups(d: "DataSmart") -> None:
> > @@ -137,10 +137,14 @@ def image_create_users(d: "DataSmart") ->
> > None:
> >           if "force-passwd-change" in flags:
> >               bb.process.run([*chroot, "/usr/bin/passwd", "--
> > expire", entry])
> >   
> > +ROOTFS_POSTPROCESS_COMMAND += "image_postprocess_groups"
> > +ROOTFS_INSTALL_COMMAND += "image_postprocess_users"
> > +image_postprocess_groups[vardeps] += "GROUPS"
> > +image_postprocess_users[vardeps] += "USERS"

This moves the whole user creation to the rootfs_install task, which
also means that the result of the user creation is reflected in the
sstate cache (which might be ok, though). But I'm wondering if that is
logically correct, as IIRC the groups have to be created before the
users are created.

A more subtle change (based on my patch "fix: rebuild rootfs on change
of USERS") would be to just add USERS as well as all USERS_<x>
variables to the vardeps of do_rootfs_install. This should also solve
your case from below, as a removed user always means a change to the
USERS variable.

I'll try to come up with this in a v2 of my patch.

Felix

> >   
> > -ROOTFS_POSTPROCESS_COMMAND += "image_postprocess_accounts"
> > -image_postprocess_accounts[vardeps] += "USERS GROUPS"
> > -python image_postprocess_accounts() {
> > +python image_postprocess_groups() {
> >       image_create_groups(d)
> > +}
> > +python image_postprocess_users() {
> >       image_create_users(d)
> >   }
> 
> This is still not ideal, as old home directories are not removed when
> removing the create-home flag or setting another directory via 
> USER_foo[home] = <x>.
> BR,
> Clara

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/730a8e283bca5ce2fced7f7fdfbe76507a28371f.camel%40siemens.com.

      reply	other threads:[~2025-04-11 11:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 10:16 'Clara Kowalsky' via isar-users
2025-04-11 10:18 ` 'Clara Kowalsky' via isar-users
2025-04-11 11:04   ` 'MOESSBAUER, Felix' via isar-users [this message]

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=730a8e283bca5ce2fced7f7fdfbe76507a28371f.camel@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=adriaan.schmidt@siemens.com \
    --cc=clara.kowalsky@siemens.com \
    --cc=felix.moessbauer@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