[Openembedded-architecture] "stateless" support

[Patrick Ohly]

On Fri, 2017-07-07 at 12:45 -0400, Rich Persaud wrote:
> On Jul 7, 2017, at 10:11, Patrick Ohly <patrick.ohly at intel.com> wrote:
> > 
> > I've finished the prototyping work for "stateless" support in IoT Refkit
> > and now would like to take the opportunity to get feedback from the
> > wider community on how much of that should also be in OE-core itself
> > and/or how to move forward.
> > 
> > The changes proposed for IoT Refkit are currently pending review here:
> > https://github.com/intel/intel-iot-refkit/pull/233
> > 
> > ...
> > 
> > What I'd like to achieve for now is that we agree on the general
> > direction, like introduction of a "stateless" distro feature. 
> > 
> > ...
> > 
> > I'd also like to hear what others think about taking some of the
> > currently non-upstream patches for "fully stateless" into OE-core. We
> > cannot maintain them in IoT Refkit, because the risk that package
> > updates in OE-core then break IoT Refkit is too high. 
> 
> OpenXT uses OE Jethro in "stateless" production systems, with dom0
> (Xen control domain) and network VM read-only OE images measured on
> each boot.  There is early support for forward seal (pre-computed TPM
> PCR measurements) of new images for OTA upgrade of stateless VMs.

This is "stateless" according to the original definition from systemd,
right? I.e. the entire image is read-only, with local state stored
elsewhere and completely overriding the corresponding read-only system
files?

There are plenty of ways of doing that. The Wiki page lists some ideas
at the bottom. I believe nothing new is needed in OE-core to support
such setups, it can already be done.

The more interesting goal is "fully stateless", because that depends on
different packaging (no useless files in /etc) and sometimes on
non-upstream patches (like reading config files both from /etc and /usr,
instead of just one config file). That's were changes in OE-core are
needed.

> For this proposed implementation of "stateless" support, is systemd
> mandatory?

The "factory" support in stateless.bbclass relies on systemd's
tmpfiles.d. But that's completely optional, and I have my doubts whether
that kind of factory reset mechanism is really useful. It would be much
easier to use a read-only image with overlay, or store a full copy
of /etc (like OSTree does it) and restore defaults from that.

For "fully stateless", systemd has some advantages over sysvinit because
it already supports reading its own configuration from both from /usr
and /etc. stateless.bbclass takes advantage of that by moving systemd
configuration from /etc (where the current OE image building puts
per-image customization) to /usr. Someone who wants "fully stateless"
with sysvinit would have to find some way of achieving that for that
init system.

Other components (like glibc or shadow) can be made "fully stateless"
with or without systemd.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.