Hello, Patrick.

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, 16 Oct 2020 at 22:25, Patrick = Williams <patrick@stwcx.xyz>= wrote:

On Wed, = Oct 14, 2020 at 08:47:57PM +0200, Anton Kachalov wrote:
> With moving from root-only environment to unprivileged users' spac= e, we
> need to ensure a smooth transition. To achieve that we need a mechanis= m for
> one-shot per-package scripts that would take care of migration. That&#= 39;s not
> only about groups & owners, but a general approach. It's simil= ar to
> firstboot, but has a different purpose.
>
> I'm going to prototype a robust / naive solution to start a servic= e before
> everything else in the system with a condition (non-empty /etc/migrati= on.d)
> and iterate through all files. Each script has to run at list with &qu= ot;set -e"
> to bail out on failures. If the script succeeded -- it will be removed= .
>
> The tricky part is: what if the script fails? Keep it, ignore the fail= ure
> and proceed with others and then boot the system? Or proceed other scr= ipts
> as well and then enter some "failure state"?

Hi Anton,

I have some high-level questions / ideas about this.

* Would these migrations be restricted to just useradd/groupadd operations?= =C2=A0 Or
=C2=A0 are you trying to create a general framework for "upgrade scrip= ts"?

This might be a general frame= work.

=C2=A0

* Have you looked at any existing support by Yocto or systemd to provide =C2=A0 what you need?=C2=A0 Yocto has USERADD_PACKAGES, postinst_intercept.=
=C2=A0 Systemd has firstboot.=C2=A0 There might be other mechanisms I'm= not
=C2=A0 remembering as well.=C2=A0 (I guess you mentioned firstboot).=C2=A0 = There is
=C2=A0 hacky override to install a "@reboot" directive in the cro= ntab.

afaik, systemd's firstboot is= only about to run special units right after installation. Once the system = is configured, the firstboot units wouldn't be executed anymore.

<= div>This thread I've started to find possible solutions.

=C2=A0

* How do we handle downgrades?=C2=A0 Some systems are set up with a "g= olden
=C2=A0 image" which is locked at manufacturing.=C2=A0 Maybe simple
=C2=A0 useradd/groupadd calls are innately backwards compatible but I worry=
=C2=A0 about a general framework falling apart.

In general, that's an issue. Golden-image downgrades should be= allowed within a compatible release branch (without wiping data). As above= , golden-images might be incompatible and wouldn't allow downgrades.

The particular migration from root-only users to unp= rivileged users should be one way without wiping data. If the downgrade is = requested, then it will be required to wipe the data.

=C2=A0

* Is there some mechanism we should do to run the migrations as part of
=C2=A0 the upgrade process instead of waiting to the next boot?=C2=A0 The =C2=A0 migrations could be included in the image tarball and thus be signed= .
=C2=A0 That would save time on reboots for checking if the migrations are =C2=A0 done.

Yes, it could be done as a= set of scripts during the update process. That is one of the possible appr= oaches. This also could be an approach for downgrades. I'm only worryin= g about the effort to support downgrades from random version to random vers= ion. The least effort with incompatible upgrades / downgrades is to keep sp= ecial transition firmware allowing downgrade from current Golden version to= the previous Golden version from incompatible branch. For upgrades the lat= est version of transition firmware might not be golden. This will require a= separate repo with an auto-generated set of scripts to be used to build tr= ansition fws.

=C2=A0

* Rather than have a single migration script that runs before everything =C2=A0 else (and is thus serial), you might create a template service
=C2=A0 (phosphor-migration-@.service) that can be depended on by the servic= es
=C2=A0 needing the migration results.=C2=A0 (ie. service foo depends on
=C2=A0 migration-foo).

While migration = is one-off, it might be safer to run serial one by one.

=C2=A0

* In a follow up email you mentioned something about hashing.=C2=A0 I was =C2=A0 going to ask how you know when a particular migration has been
=C2=A0 executed.=C2=A0 Maybe there are some tricks of recording hash values= in
=C2=A0 the RWFS could prevent multiple executions.

We can track the succeeded scripts by touching some file in a d= irectory like /var/lib/migration (e.g. create a file named as sha-sum of th= e runned script).

=C2=A0

--
Patrick Williams

--000000000000d4a4b705b1d0138b--