/etc/migration.d

[Patrick Williams]

On Wed, Oct 14, 2020 at 08:47:57PM +0200, Anton Kachalov wrote:
> With moving from root-only environment to unprivileged users' space, we
> need to ensure a smooth transition. To achieve that we need a mechanism for
> one-shot per-package scripts that would take care of migration. That's not
> only about groups & owners, but a general approach. It's similar to
> firstboot, but has a different purpose.
> 
> I'm going to prototype a robust / naive solution to start a service before
> everything else in the system with a condition (non-empty /etc/migration.d)
> and iterate through all files. Each script has to run at list with "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 failure
> and proceed with others and then boot the system? Or proceed other scripts
> 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?  Or
  are you trying to create a general framework for "upgrade scripts"?

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

* How long would a "migration" be kept around for?  Are we expecting
  that packages provide them forever?

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

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

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

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

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201016/14c1c1af/attachment.sig>