Re: Updating the OS data that ostree doesn't manage

[Dan Nicholson <nicholson endlessm com>]

On Thu, Feb 20, 2020 at 1:16 PM Colin Walters <walters verbum org> wrote:
> On Tue, Feb 18, 2020, at 12:25 PM, Will Manley wrote:
> > Regarding managing /sysroot/ostree: We have a systemd unit called
> > post-upgrade-cleanup.service which is run at boot after a deploy.  This
> > allows us to perform housekeeping including running `ostree admin
> > cleanup`.
>
> Yep, this is a sensible approach.
>
> That all said at some point we may need to add a generic "before reboot" hook in ostree for
> https://github.com/ostreedev/ostree/issues/1026

At Endless we have a pile of early systemd units that attempt to fixup
things we've gotten wrong or some setting we'd like to change. This is
currently our primary means of achieving the things Daniel is
referring to. Those all run post-boot, but I can definitely see things
that would prefer to run pre-boot on the deployment. I suppose we
could hook into the finalize service and do some things there, but
I've often wondered if ostree could provide a more first-class way to
run these kinds of operations.

While ostree allows us to avoid many of the horrors of packaging
hooks, I also think there are legit cases for that. As you note above,
the SELinux case already requires management of the deployment before
it's booted and ostree has a non-trivial amount of code to do that. I
think it would be nice if you could ship hooks in the OS that ostree
runs at the appropriate time. For instance,
/usr/lib/ostree/{pre,post}-boot-hooks/ or something like that. For the
pre-boot case, it would run the hooks at finalize time with bwrap or
similar. For the post-boot case, it would run the hooks after remount
but before multi-user.target or similar.

In a similar vein, I think it would be nice to be able to hook into
the /etc merge. What's in ostree now is nice but naive - if the
contents have changed from the current deployment, keep them. If not,
use the contents from the new deployment. However, there are many
pieces of local configuration in /etc that you could do a reliable job
of merging like /etc/nsswitch.conf. Currently we just hope that no one
touches those files besides the few that are handled specially like
/etc/passwd since otherwise they won't get the updated configuration
we'd like to provide.