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

["Colin Walters" <walters verbum org>]

On Thu, Feb 20, 2020, at 5:36 PM, Dan Nicholson wrote:
> 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. 

Why would you want post-boot-hooks versus having systemd units which already exist and are already a rich, 
flexible, well-documented way to execute code during boot (and as you are already using today)?  

One I think probably what systemd could gain sugar for is something like ConditionExecuteAtMostOnce=yes which 
boils down to the "write a stamp file in /var/lib/systemd/atmostonce/$unitname.stamp after unit succeeds" and 
ConditionFileExists=!/var/lib/systemd/atmostonce/$unitname.stamp or so?

One crucial thing is systemd units have flexible ordering/dependencies which anything like a simplistic "run 
these executables in a hooks.d directory" will quickly need.

> For the
> pre-boot case, it would run the hooks at finalize time with bwrap or
> similar. 

The thing is that introducing this ruins the currently IMO very clean model ostree has that it manages the 
filesystem and kernel/bootloader config and that's it.  There's no hard tie to a container runtime - one can 
use bwrap or runc etc.

Another thing that might seem philosophical but has technological implications is - does one think of these 
"post processing hooks" as creating a local commit (hence a potentially derived OS version) or is it just 
"configuration".

These have different implications because for example `ostree admin config-diff` will show you local 
configuration changes, but if you put local stuff in a derived commit, then you'd need to `ostree diff` the 
base vs layered commits instead.  Though I guess we could add `ostree admin config-diff --from-parent` or so?

> In a similar vein, I think it would be nice to be able to hook into
> the /etc merge.

Agree, though this can be implemented with derived commits per above too.