[Openembedded-architecture] "stateless" support

[Patrick Ohly]

Hello!

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

Feel free to comment on or ask specific questions about the code there.

To get started, let me quote parts of the (updated today) Wiki page:
https://wiki.yoctoproject.org/wiki/Stateless

        Definition

        A "stateless" distro is one where /etc and /var are entirely
        empty when booting. According to this definition,
        populating /etc to factory defaults during the boot process is
        allowed. However, also allowing persistent modifications of the
        copied files then leads to problems when updating the defaults.
        See http://0pointer.net/blog/projects/stateless.html for more
        information.
        
        So a stricter definition of "stateless" as used by the Clear
        Linux project (called "fully stateless" in this page) is that
        the system must work also when /etc remains empty at runtime,
        while (optionally) allowing an admin to configure the system by
        creating files there. See
        https://clearlinux.org/features/stateless

        Purpose
        
        In a stateless image, factory reset can be achieved by wiping
        out the content of /etc, without exceptions.
        
        A fully stateless image, updates can be done without touching
        local configuration files.

        Limitations 
        
        Ideally, no configuration files are needed by the OS in /etc at
        all, while using them when they exist. Only the local admin or
        configuration tools create files there. In such a setup,
        configuration files in /etc may become incompatible with an
        updated OS. That is a problem that needs to be solved by the
        person or tool which created these incompatible local
        configuration files. It can be mitigated a bit by keeping the
        configuration API of OS components stable across updates.
        
        In practice, a lot of files are still expected in /etc. They can
        be placed there from factory defaults via the systemd tmpfiles.d
        service. After a system update, either a factory reset must be
        done or these copied files must be overwritten with more recent
        ones from the updated factory defaults.

        Status and goals for "stateless" in Yocto

        Stateless support does not exit in current Yocto. Work is under
        way to improve that. Related Bugzilla entries are
        https://bugzilla.yoctoproject.org/show_bug.cgi?id=9527,
        https://bugzilla.yoctoproject.org/show_bug.cgi?id=1593
        
        It is not realistic to make all components in Yocto stateless.
        This will only work for some selected components and thus only
        those images using those components. The initial goal is to make
        the "refkit-image-common" from the IoT OS Reference Kit
        stateless, with user handling fully stateless. In that image, at
        least the following local configuration changes are meant to
        work in combination with system update:
        
              * adding users and groups with user/groupadd
              * replacing the default motd


What I'd like to achieve for now is that we agree on the general
direction, like introduction of a "stateless" distro feature. When
turned on, packages should avoid putting files into /etc when not needed
(for example, when the file merely documents the builtin defaults) or
enable support for "fully stateless" configuration file handling. Note
that this could even be done unconditionally, if it is considered
acceptable that files that traditionally were in /etc no longer end up
there.

Can we agree on "/usr/share/doc/etc" as the location where
"informational" configuration files get installed instead? If we do,
then we could even change the default packaging rules (like splitting
out those files into their own packages, with magic a la dev-pkgs to
install them automatically if desired).

Does the approach taken in stateless.bbclass make sense for now? Should
the class perhaps be added to OE-core directly instead of IoT Refkit? I
don't see a need to have it in OE-core myself, because meta-refkit-core
is safe to add to other distros as it doesn't change a build and has no
dependencies other than openembedded-core.

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. Therefore while
the pull request has stateless-*.inc files which enable patches, those
include files and thus the patches are not actually used at the moment.
Include them in local.conf to try out what they do.

Of the goals mentioned above for refkit-image-common, only
overriding /etc/motd currently works in combination with OSTree. This
doesn't even need any changes, the default OSTree /etc handling (keep
using locally modified files in /etc) is already enough.

The more complex user and group handling can be enabled via
stateless-nss-altfiles.inc when using glib, but because it needs
additional patches, that file is not used at the moment.

stateless.bbclass has support for turning /etc into factory defaults
that get restored by systemd. That isn't useful for an image where
OSTree or swupd manage /etc, but I can imagine that it might be useful
for people who want to implement factory reset without those. Is anyone
interested in this aspect or can it be dropped (and thus simplifying the
code)?

-- 
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.