https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Patrick+OhlyYocto Project - User contributions [en]2026-04-11T13:14:16ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=28561Stateless2017-07-07T13:31:28Z<p>Patrick Ohly: /* Status and goals for "stateless" in Yocto */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty<br />
when booting. According to this definition, populating /etc to factory<br />
defaults during the boot process is allowed. However, also allowing<br />
persistent modifications of the copied files then leads to problems<br />
when updating the defaults. See<br />
http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
So a stricter definition of "stateless" as used by the Clear Linux<br />
project (called "fully stateless" in this page) is that the system must work also when /etc remains empty at<br />
runtime, while (optionally) allowing an admin to configure the system<br />
by creating files there. See https://clearlinux.org/features/stateless<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A fully stateless image, updates can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless-pr. It does not yet achieve all of the goals, but the general approach is ready for review in https://github.com/intel/intel-iot-refkit/pull/233. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless-pr/meta-refkit-core/classes/stateless.bbclass. It operates almost entirely during rootfs construction, with some patches integrated into various recipes as an interim solution until it gets decided whether those patches can be upstreamed and/or included in OE-core.<br />
<br />
The actual configuration is in various stateless*.inc files in https://github.com/pohly/intel-iot-refkit/blob/stateless-pr/meta-refkit-core/conf/distro/include.<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=28560Stateless2017-07-07T13:30:49Z<p>Patrick Ohly: /* Status and goals for "stateless" in Yocto */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty<br />
when booting. According to this definition, populating /etc to factory<br />
defaults during the boot process is allowed. However, also allowing<br />
persistent modifications of the copied files then leads to problems<br />
when updating the defaults. See<br />
http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
So a stricter definition of "stateless" as used by the Clear Linux<br />
project (called "fully stateless" in this page) is that the system must work also when /etc remains empty at<br />
runtime, while (optionally) allowing an admin to configure the system<br />
by creating files there. See https://clearlinux.org/features/stateless<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A fully stateless image, updates can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless-pr. It does not yet achieve all of the goals, but the general approach is ready for review in https://github.com/intel/intel-iot-refkit/pull/233. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless-pr/meta-refkit/classes/stateless.bbclass. It operates almost entirely during rootfs construction, with some patches integrated into various recipes as an interim solution until it gets decided whether those patches can be upstreamed and/or included in OE-core.<br />
<br />
The actual configuration is in various stateless*.inc files in https://github.com/pohly/intel-iot-refkit/blob/stateless-pr/meta-refkit/conf/distro/include.<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=28559Stateless2017-07-07T13:24:02Z<p>Patrick Ohly: /* Purpose */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty<br />
when booting. According to this definition, populating /etc to factory<br />
defaults during the boot process is allowed. However, also allowing<br />
persistent modifications of the copied files then leads to problems<br />
when updating the defaults. See<br />
http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
So a stricter definition of "stateless" as used by the Clear Linux<br />
project (called "fully stateless" in this page) is that the system must work also when /etc remains empty at<br />
runtime, while (optionally) allowing an admin to configure the system<br />
by creating files there. See https://clearlinux.org/features/stateless<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A fully stateless image, updates can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It operates entirely during rootfs construction. STATELESS_MV_ROOTFS is for cases where configuration files were put into /etc in do_install that can also be elsewhere. It also supports moving files into the factory defaults. STATELESS_RM_ROOTFS is for items that can be removed.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. refkit-image-common is built with an empty /etc, and accidentally putting something into /etc triggers a build error.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=28558Stateless2017-07-07T13:23:32Z<p>Patrick Ohly: /* Definition */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty<br />
when booting. According to this definition, populating /etc to factory<br />
defaults during the boot process is allowed. However, also allowing<br />
persistent modifications of the copied files then leads to problems<br />
when updating the defaults. See<br />
http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
So a stricter definition of "stateless" as used by the Clear Linux<br />
project (called "fully stateless" in this page) is that the system must work also when /etc remains empty at<br />
runtime, while (optionally) allowing an admin to configure the system<br />
by creating files there. See https://clearlinux.org/features/stateless<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It operates entirely during rootfs construction. STATELESS_MV_ROOTFS is for cases where configuration files were put into /etc in do_install that can also be elsewhere. It also supports moving files into the factory defaults. STATELESS_RM_ROOTFS is for items that can be removed.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. refkit-image-common is built with an empty /etc, and accidentally putting something into /etc triggers a build error.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=28557Stateless2017-07-07T13:22:37Z<p>Patrick Ohly: /* Definition */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty<br />
when booting. According to this definition, populating /etc to factory<br />
defaults during the boot process is allowed. However, also allowing<br />
persistent modifications of the copied files then leads to problems<br />
when updating the defaults. See<br />
http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
So a stricter definition of "stateless" as used by the Clear Linux<br />
project is that the system must work also when /etc remains empty at<br />
runtime, while (optionally) allowing an admin to configure the system<br />
by creating files there. See https://clearlinux.org/features/stateless<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It operates entirely during rootfs construction. STATELESS_MV_ROOTFS is for cases where configuration files were put into /etc in do_install that can also be elsewhere. It also supports moving files into the factory defaults. STATELESS_RM_ROOTFS is for items that can be removed.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. refkit-image-common is built with an empty /etc, and accidentally putting something into /etc triggers a build error.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=26452System Update2017-04-28T06:54:54Z<p>Patrick Ohly: /* Introduction */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
* "Surviving in the Wilderness: Integrity Protection and System Update" by Patrick Ohly: [https://openiotelcna2017.sched.com/event/9J5i/surviving-in-the-wilderness-integrity-protection-and-system-update-patrick-ohly-intel-gmbh abstract and slides], [https://www.youtube.com/watch?v=N8V0W0p3YBU video recording of talk]<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based / file based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| [https://docs.mender.io/1.0/Devices/Partition-layout flexible (minimum four partitions)], U-Boot as boot loader<br />
| conceptually read-only<br />
| remote ([https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation managed mode]) or local ([https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation standalone mode])<br />
| Complete rootfs, including kernel.<br />
| relatively stable, fully supported and tested upgrade path<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| compressed rootfs per build<br />
| download and write compressed rootfs<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS enforced, [https://tracker.mender.io/projects/MEN/issues/MEN-1020 signing being developed]<br />
|-<br />
! [https://github.com/ostreedev/ostree OSTree]<br />
| file-based<br />
| flexible, but supports only limited set of bootloaders<br />
| read/write, OS trees bind mounted read-only, /etc and /var writable<br />
| local and remote repositories<br />
| kernel and filesystem<br />
| relatively stable, significant user base, under active development<br />
| meta-ostree (WIP), [https://github.com/advancedtelematic/meta-updater meta-updater] (public)<br />
| generating commits based on new builds, storing them in repository<br />
| updating local repository, hard links for sharing unchanged content between deployments<br />
| rollback to a different deployed OS tree<br />
| some work required<br />
| reboot required<br />
| GPG-signed commits<br />
|-<br />
|-<br />
! [https://github.com/rauc/rauc RAUC]<br />
| block based / file-based (tar)<br />
| flexible (block-device/MTD)<br />
| depends on setup (read-only supported)<br />
| depends on setup<br />
| depends on setup (any storage device)<br />
| relatively stable, under active development<br />
| [https://github.com/rauc/meta-rauc meta-rauc]<br />
| archives full (compressed) image per build<br />
| download and write full (compressed) image<br />
| integrated rollback (requires bootloader support)<br />
| some customization required<br />
| reboot required<br />
| X509-signed update bundles<br />
|}<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly or not at all (examples: [https://github.com/clearlinux/swupd-server/pull/25 assumption about filesystem], [https://github.com/clearlinux/swupd-server/pull/26 error checking], [https://github.com/clearlinux/swupd-client/pull/71 path configuration]).<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: No upper limit on partitions, [https://docs.mender.io/1.0/Devices/Partition-layout minimum four]. Dual rootfs partitions with two extra partitions, a boot and a data partition. Depends on U-Boot as boot loader for the automatic rollback.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions, so persistent data should be stored in the data partition. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender Server over HTTPS ([https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation managed mode])<br />
: manual provisioning : local file system/URL, e.g. USB, SD, HTTP(S) ([https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation standalone mode])<br />
;Code stability<br />
: Stable release. Upgrade path fully supported and tested.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions (update is streamed), space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Artifact signing is [https://tracker.mender.io/projects/MEN/issues/MEN-1020?filter=allopenissues being implemented].<br />
<br />
== OSTree ==<br />
<br />
;Disk layout<br />
:Only limited set of bootloaders supported (those that support [http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec The Boot Loader Specification] and some exceptions). The root file system has to have the /boot directory managed by OSTree. The actual deployed OS trees have certain conventions and requirements. For example, /etc and /var need to be writable, while /usr is mounted read-only.<br />
;Rootfs<br />
:Files provided by OS are expected to be in /usr, which is mounted read-only. /etc and /var are writable.<br />
;Updates from<br />
:Local and remote repostories. OSTree works by replicating a repository to the target device and then "checking out" deployment directories from the repository. Local and HTTP methods for replicating the repository are available.<br />
;Updates what<br />
:OSTree (atomically) updates root file system trees and the kernel. If anything else needs to be updated, it needs to happen by running custom code on the target device.<br />
;Code stability<br />
:OSTree is relatively stable. It's used by many distributions and projects, such as Fedora Atomic and Flatpak. OSTree is under active development and has an open-source community around it.<br />
;OE/Yocto integration<br />
:Meta-ostree layer is work in progress.<br />
;Resource requirements on server<br />
:OSTree generates "commit objects" based on the filesystem changes between builds. These commit objects are stored in a commit chain the same way as git does. The commit objects transmitted over the network as binary diffs when the remote and local repositories are synchronized.<br />
;Resource requirements on client<br />
:Client has the local copy of the repository. The repository contains the objects, which map to the files on the OS trees. The deployments of the OS trees (or "checkouts" in git termininology) are made using hard links to the repository content. This means that the required space is only increased when the data changes: the static data files are shared between deployments.<br />
:OSTree allows deleting of data. This means that the full operating system history doesn't need to be stored in the repository. A typical OSTree-based system might have two deployed OS trees: one that is being currently used and one fallback.<br />
;Failure resilience<br />
:OSTree controls the booting to the different deployed trees using bootloader entries. If booting a deployed OS tree fails, a different bootloader entry can be chosen for booting into a different OS tree.<br />
;Complexity<br />
:Some work is needed to fit the root filesystem into the conventions that OSTree likes. Some documentation of the needed steps [https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ is available here].<br />
;Downtime<br />
:Reboot is required after updates. Changing between deployed OS trees is done by selecting a different boot loader entry.<br />
;Security<br />
:The commits can be signed with GPG-based signatures. OSTree repositories store file extended attributes, which means that the security mechanisms using extended attributes should be functional with OSTree.<br />
<br />
== RAUC ==<br />
<br />
;Type<br />
: RAUC supports filesystems on block devices and MTD (NAND/NOR) as well as raw images (bootloaders, FPGA bitstreams).<br />
;Disk layout<br />
: RAUC does not depend on a fixed disk layout but allows to flexibly [https://rauc.readthedocs.io/en/latest/reference.html#sec-ref-slot-config configure] one. It supports A+B scenarios as well as A+recovery or more complex setups. <br />
;Rootfs<br />
: There are no limitations on the root file system, it can be read-only or read-write. It has to contain the RAUC system configuration file, a keyring for verification and the small RAUC binary itself.<br />
;Updates from<br />
: RAUC is the updating core that is meant to be integrated in a custom environment. Thus it supports installing bundles from local file paths, while another application is responsible fetching the update.<br />
: External storage (USB, SD): direct access, no copying required<br />
: Webserver: Application downloads Bundle to local tmpfs / storage.<br />
: Demo-applications planned.<br />
;Updates what<br />
:<br />
:* everything which is updatable<br />
:* default handler for common storage types and file systems (ext4, NAND, UBI, raw copy)<br />
:* allows [https://rauc.readthedocs.io/en/latest/using.html#customizing-the-update custom handler] for each update target (script or application, information passed as environment variables)<br />
;Resources on client<br />
: At least one production rootfs and a rescue system. Temporary storage for update Bundle (compressed) if provided by a webserver.<br />
;Failure resilience<br />
: Interface to [https://rauc.readthedocs.io/en/latest/integration.html#interfacing-with-the-bootloader Booloader] (Barebox, U-Boot, GRUB) allows atomic updates (correct fallback handling is up to the bootloader). Interface to mark updates good or bad after certain checks in the newly booted rootfs (must be supported by bootloader).<br />
;Complexity<br />
: Integration into the rootfs and generating update Bundles is relatively easy with Yocto ([https://github.com/rauc/meta-rauc meta-rauc]) or [https://www.mail-archive.com/ptxdist@pengutronix.de/msg11471.html PTXdist]. Manual integration described [https://rauc.readthedocs.io/en/latest/integration.html here].<br />
;Downtime<br />
: Normally, downloading and installing will be perforemd as background operation. A reboot is needed to make the new system active (might be scheduled).<br />
;Security<br />
: Signed images: Signing images is mandatory. X.509 cryptography (CMS) is used to sign the bundle and a full PKI with revocations is supported. An example script allows creating key/cert/keychain for test purposes.<br />
: Verified boot: When using image updates, compatible with IMA, SELinux, dm-verity, ... (as it does require write access to the filesystems).</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=25136Stateless2017-03-10T12:32:31Z<p>Patrick Ohly: /* Status and goals for "stateless" in Yocto */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It operates entirely during rootfs construction. STATELESS_MV_ROOTFS is for cases where configuration files were put into /etc in do_install that can also be elsewhere. It also supports moving files into the factory defaults. STATELESS_RM_ROOTFS is for items that can be removed.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. refkit-image-common is built with an empty /etc, and accidentally putting something into /etc triggers a build error.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=25135Stateless2017-03-10T12:28:09Z<p>Patrick Ohly: /* Implementation */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=25134Stateless2017-03-10T12:27:57Z<p>Patrick Ohly: /* Limitations */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=25133Stateless2017-03-10T11:27:18Z<p>Patrick Ohly: /* Limitations */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=25132Stateless2017-03-10T11:21:01Z<p>Patrick Ohly: /* Purpose */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc, without exceptions.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=24537Stateless2017-03-01T16:51:56Z<p>Patrick Ohly: /* Status and goals for "stateless" in Yocto */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless. Previous work in Ostro that led to a considerably reduced /etc is in https://github.com/pohly/ostro-os/tree/stateless-rebased.<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=24533Stateless2017-03-01T16:04:32Z<p>Patrick Ohly: /* Definition */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc and /var are entirely empty when booting. No state persists across reboots, hence the name. A more relaxed version of this preserves config files in /etc, but still allows them to be removed at any time to do a factory reset.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=24532Stateless2017-03-01T16:00:21Z<p>Patrick Ohly: /* Definition */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc is reserved entirely for local, machine specific customizations. Default OS configuration must be stored elsewhere or be compiled into the binaries. In such a distro, the OS must be able to boot with an entirely empty /etc.<br />
<br />
See http://0pointer.net/blog/projects/stateless.html for more information.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=24531Stateless2017-03-01T15:59:41Z<p>Patrick Ohly: /* Status and goals for "stateless" in Yocto */</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc is reserved entirely for local, machine specific customizations. Default OS configuration must be stored elsewhere or be compiled into the binaries. In such a distro, the OS must be able to boot with an entirely empty /etc.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
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<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Stateless&diff=24530Stateless2017-03-01T15:54:51Z<p>Patrick Ohly: Created page with "== Definition == A "stateless" distro is one where /etc is reserved entirely for local, machine specific customizations. Default OS configuration must be stored elsewhere or ..."</p>
<hr />
<div>== Definition ==<br />
<br />
A "stateless" distro is one where /etc is reserved entirely for local, machine specific customizations. Default OS configuration must be stored elsewhere or be compiled into the binaries. In such a distro, the OS must be able to boot with an entirely empty /etc.<br />
<br />
== Purpose ==<br />
<br />
In a stateless image, factory reset can be achieved by wiping out the content of /etc.<br />
<br />
A system update can be done without touching local configuration files.<br />
<br />
== Limitations ==<br />
<br />
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.<br />
<br />
<br />
== Implementation ==<br />
<br />
Ideally, an OS component itself knows how to update the default configuration with small, independent configuration fragments in /etc, i.e. the actual configuration is constructed dynamically at runtime. systemd works like that.<br />
<br />
Less suitable, but still "stateless" is an OS component which reads a configuration file from /etc if it exists and falls back to some read-only default when it doesn't. This is less suitable when a real human creates the configuration in /etc because that person then has to ensure that updated system defaults get copied into the config file in /etc, but it may work when the file is created using some tool that can be re-run after an update.<br />
<br />
Finally, an OS component can be configured to ignore /etc entirely and just read its configuration files from a read-only location. It can then still be configured when building the OS, but not locally. Depending on the use-cases, such local modifications might not be needed.<br />
<br />
Some legacy components use /etc as location for files created at runtime. This is undesirable because it makes it less obvious for an admin which files in /etc may be modified, but if the files get recreated without data loss after a factory reset or system update, then using /etc is acceptable.<br />
<br />
== Status and goals for "stateless" in Yocto ==<br />
<br />
Stateless support does not exit in current Yocto. Work is under way to improve that.<br />
<br />
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. In that image, at least the following local configuration changes are meant to work:<br />
* adding users and groups with user/groupadd<br />
* replacing the default motd<br />
<br />
The current prototype is hosted in https://github.com/pohly/intel-iot-refkit/tree/stateless<br />
<br />
The generic mechanism is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/classes/stateless.bbclass. It supports STATELESS_RELOCATE_pn-<recipe> = "True" for compiling a recipe such that it uses a read-only sysconfig directory. STATELESS_MV is for cases where a recipe puts files into /etc in do_install that can also be elsewhere. STATELESS_RM is for items that can be removed. The same exists as STATELESS_RM/MV_ROOTFS for items created as part of package installation or rootfs functions.<br />
<br />
The actual configuration used for Refkit is https://github.com/pohly/intel-iot-refkit/blob/stateless/meta-refkit/conf/distro/include/stateless.inc. It does not yet enforce an empty /etc. Instead one has to run "bitbake refkit-image-common:do_rootfs" and check the content of /etc manually.<br />
<br />
Some BKMs for gradually moving content out of /etc:<br />
<br />
* use STATELESS_MV_pn-<recipe> to avoid repackaging other recipes<br />
* precede each entry with a detailed technical explanation of why the change is working<br />
* sort entries in the file as follows:<br />
** header<br />
** STATELESS_ETC_WHITELIST<br />
** STATELESS_RM/MV sorted by pn-<reciped> (alphabetically)<br />
** STATELESS_RM_ROOTFS (no particular order, add at the bottom)<br />
** STATELESS_MV_ROOTFS (no particular order, add at the bottom)<br />
** special python functions<br />
<br />
refkit-image-common is stateless once /etc is empty after do_rootfs and the resulting image works without problems. Right now, it still has the following content:<br />
<br />
$ tree tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-common/1.0-r0/rootfs/etc/<br />
├── asound.conf<br />
├── audisp<br />
│  ├── audispd.conf<br />
│  └── plugins.d<br />
│  ├── af_unix.conf<br />
│  └── syslog.conf<br />
├── audit<br />
│  ├── auditd.conf<br />
│  ├── audit.rules<br />
│  └── rules.d<br />
│  └── audit.rules<br />
├── bluetooth<br />
│  ├── input.conf<br />
│  └── network.conf<br />
├── build<br />
├── busybox.links.nosuid<br />
├── busybox.links.suid<br />
├── ca-certificates<br />
│  └── update.d<br />
├── ca-certificates.conf<br />
├── dbus-1<br />
│  ├── session.conf<br />
│  ├── system.conf<br />
│  └── system.d<br />
│  ├── bluetooth.conf<br />
│  ├── connman.conf<br />
│  ├── dbus-wpa_supplicant.conf<br />
│  ├── org.freedesktop.hostname1.conf<br />
│  ├── org.freedesktop.locale1.conf<br />
│  ├── org.freedesktop.login1.conf<br />
│  ├── org.freedesktop.machine1.conf<br />
│  ├── org.freedesktop.systemd1.conf<br />
│  └── org.freedesktop.timedate1.conf<br />
├── default<br />
│  ├── auditd<br />
│  ├── mountall<br />
│  ├── usbd<br />
│  ├── useradd<br />
│  └── volatiles<br />
│  ├── 99_dbus<br />
│  ├── 99_pam<br />
│  ├── 99_sshd<br />
│  └── 99_wpa_supplicant<br />
├── depmod.d<br />
├── environment<br />
├── filesystems<br />
├── fstab<br />
├── group<br />
├── gshadow<br />
├── host.conf<br />
├── hostname<br />
├── hosts<br />
├── init.d<br />
│  └── smack<br />
├── inputrc<br />
├── issue<br />
├── issue.net<br />
├── ld.so.conf<br />
├── libaudit.conf<br />
├── libnl<br />
│  ├── classid<br />
│  └── pktloc<br />
├── login.defs<br />
├── machine-id<br />
├── mke2fs.conf<br />
├── modprobe.d<br />
├── modules-load.d<br />
│  ├── iwlwifi.conf<br />
│  └── uio.conf<br />
├── motd<br />
├── mtab -> /proc/mounts<br />
├── network<br />
│  ├── if-down.d<br />
│  ├── if-post-down.d<br />
│  │  └── wpa-supplicant -> ../if-pre-up.d/wpa-supplicant<br />
│  └── if-pre-up.d<br />
│  └── wpa-supplicant<br />
├── nsswitch.conf<br />
├── os-release<br />
├── pam.d<br />
│  ├── chage<br />
│  ├── chfn<br />
│  ├── chgpasswd<br />
│  ├── chpasswd<br />
│  ├── chsh<br />
│  ├── common-account<br />
│  ├── common-auth<br />
│  ├── common-password<br />
│  ├── common-session<br />
│  ├── common-session-noninteractive<br />
│  ├── groupadd<br />
│  ├── groupdel<br />
│  ├── groupmems<br />
│  ├── groupmod<br />
│  ├── login<br />
│  ├── newusers<br />
│  ├── other<br />
│  ├── passwd<br />
│  ├── runuser<br />
│  ├── runuser-l<br />
│  ├── sshd<br />
│  ├── su<br />
│  ├── systemd-user<br />
│  ├── useradd<br />
│  ├── userdel<br />
│  └── usermod<br />
├── passwd<br />
├── profile<br />
├── protocols<br />
├── request-key.conf<br />
├── request-key.d<br />
├── rpc<br />
├── securetty<br />
├── security<br />
│  ├── access.conf<br />
│  ├── group.conf<br />
│  ├── limits.conf<br />
│  ├── limits.d<br />
│  ├── namespace.conf<br />
│  ├── namespace.d<br />
│  ├── namespace.init<br />
│  ├── pam_env.conf<br />
│  └── time.conf<br />
├── services<br />
├── shadow<br />
├── shells<br />
├── skel<br />
├── smack<br />
│  ├── accesses.d<br />
│  └── cipso.d<br />
├── ssh<br />
│  ├── moduli<br />
│  ├── ssh_config<br />
│  ├── sshd_config<br />
│  └── sshd_config_readonly<br />
├── ssl<br />
│  ├── certs<br />
│  │  ├── 02265526.0 -> /usr/share/ca-certificates/mozilla/Entrust_Root_Certification_Authority_-_G2.crt<br />
│  │  ├── 024dc131.0 -> /usr/share/ca-certificates/mozilla/Microsec_e-Szigno_Root_CA.crt<br />
│  │  ├── 03179a64.0 -> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt<br />
...<br />
│  │  └── XRamp_Global_CA_Root.pem -> /usr/share/ca-certificates/mozilla/XRamp_Global_CA_Root.crt<br />
│  ├── openssl.cnf<br />
│  └── private<br />
├── sysctl.d<br />
├── systemd<br />
│  ├── journald.conf<br />
│  ├── logind.conf<br />
│  ├── network<br />
│  ├── system<br />
│  │  ├── bluetooth.target.wants<br />
│  │  │  └── bluetooth.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── ctrl-alt-del.target -> ../../../lib/systemd/system/reboot.target<br />
│  │  ├── dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service<br />
│  │  ├── default.target -> /lib/systemd/system/multi-user.target<br />
│  │  ├── getty.target.wants<br />
│  │  │  └── getty@tty1.service -> ../../../../lib/systemd/system/getty@.service<br />
│  │  ├── local-fs.target.wants<br />
│  │  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  │  ├── multi-user.target.wants<br />
│  │  │  ├── auditd.service -> /lib/systemd/system/auditd.service<br />
│  │  │  ├── connman.service -> /lib/systemd/system/connman.service<br />
│  │  │  ├── machines.target -> ../../../../lib/systemd/system/machines.target<br />
│  │  │  └── remote-fs.target -> ../../../../lib/systemd/system/remote-fs.target<br />
│  │  ├── network.target.wants<br />
│  │  │  ├── ip6tables.service -> /lib/systemd/system/ip6tables.service<br />
│  │  │  └── iptables.service -> /lib/systemd/system/iptables.service<br />
│  │  ├── sockets.target.wants<br />
│  │  │  └── sshd.socket -> /lib/systemd/system/sshd.socket<br />
│  │  ├── sysinit.target.wants<br />
│  │  │  ├── run-postinsts.service -> /lib/systemd/system/run-postinsts.service<br />
│  │  │  └── systemd-timesyncd.service -> ../../../../lib/systemd/system/systemd-timesyncd.service<br />
│  │  └── systemd-random-seed.service.wants<br />
│  │  └── var-volatile-lib.service -> /lib/systemd/system/var-volatile-lib.service<br />
│  ├── system.conf<br />
│  ├── timesyncd.conf<br />
│  ├── user<br />
│  └── user.conf<br />
├── terminfo<br />
│  ├── a<br />
│  │  └── ansi<br />
│  ├── d<br />
│  │  └── dumb<br />
│  ├── l<br />
│  │  └── linux<br />
│  ├── r<br />
│  │  └── rxvt<br />
│  ├── s<br />
│  │  ├── screen<br />
│  │  ├── screen-256color<br />
│  │  └── sun<br />
│  ├── v<br />
│  │  ├── vt100<br />
│  │  ├── vt102<br />
│  │  ├── vt200<br />
│  │  ├── vt220<br />
│  │  └── vt52<br />
│  └── x<br />
│  ├── xterm -> xterm-color<br />
│  ├── xterm-256color<br />
│  ├── xterm-color<br />
│  └── xterm-xfree86<br />
├── timestamp<br />
├── tmpfiles.d<br />
│  ├── 00-create-volatile.conf<br />
│  ├── audit-volatile.conf<br />
│  └── connman_resolvconf.conf<br />
├── udev<br />
│  ├── hwdb.d<br />
│  ├── rules.d<br />
│  │  ├── touchscreen.rules<br />
│  │  └── udev-smack-default.rules<br />
│  └── udev.conf<br />
├── udhcpc.d<br />
│  └── 50default<br />
├── version<br />
├── wpa_supplicant.conf<br />
└── xdg<br />
└── systemd<br />
└── user -> ../../systemd/user<br />
<br />
62 directories, 500 files<br />
<br />
<br />
== Alternatives ==<br />
<br />
There are other solutions with similar goals. However, stateless has some properties that, when it is applicable, make stateless a better solution.<br />
<br />
=== overlayfs ===<br />
<br />
The OS configuration files are in /etc. At runtime, an overlay is activated. Editing items in /etc then stores a new copy of the modified files in the overlay. A system update is done when the overlay is not active.<br />
<br />
Drawback: files in the overlay continue to shadow an updated system configuration, i.e. new settings from the updated OS configuration files are ignored. Addressing this would require merging potentially complex files during an update.<br />
<br />
=== config generator ===<br />
<br />
Instead of allowing local modifications in the normal /etc configuration files, one or more additional config files are used. A tool takes those files and the default system configuration to produce the actual content of /etc, either by writing to it directly or into an overlay.<br />
<br />
Drawback: custom solution, the normal tools like "useradd" do not work; no such generator exists (?) and thus would have to be written from scratch<br />
Advantage: full control over the format of allowed configuration changes; the generator can be updated together with the OS so that the output always matches what the OS components expect<br />
<br />
Such a config generator can be combined with a stateless distro.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=23728System Update2017-02-08T14:58:02Z<p>Patrick Ohly: add place holder for RAUC</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| fixed, U-Boot as boot loader<br />
| conceptually read-only<br />
| remote<br />
| Complete rootfs, including kernel.<br />
| in development<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| archives full image per build<br />
| download and write full image<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS<br />
|-<br />
! [https://github.com/ostreedev/ostree OSTree]<br />
| file-based<br />
| flexible, but supports only limited set of bootloaders<br />
| read/write, OS trees bind mounted read-only, /etc and /var writable<br />
| local and remote repositories<br />
| kernel and filesystem<br />
| relatively stable, significant user base, under active development<br />
| meta-ostree (WIP), [https://github.com/advancedtelematic/meta-updater meta-updater] (public)<br />
| generating commits based on new builds, storing them in repository<br />
| updating local repository, hard links for sharing unchanged content between deployments<br />
| rollback to a different deployed OS tree<br />
| some work required<br />
| reboot required<br />
| GPG-signed commits<br />
|-<br />
| [https://fosdem.org/2017/schedule/event/secure_safe_embedded_updates/ Robust Auto-Update Controller (RAUC)]<br />
| block based?<br />
|}<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly or not at all (examples: [https://github.com/clearlinux/swupd-server/pull/25 assumption about filesystem], [https://github.com/clearlinux/swupd-server/pull/26 error checking], [https://github.com/clearlinux/swupd-client/pull/71 path configuration]).<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: Dual rootfs partitions with two extra partitions, a boot and a data partition. Depends on U-Boot as boot loader for the automatic rollback.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender server and/or HTTPS server<br />
;Code stability<br />
: Master branch under development. There is a stable branch, but it's lacking many basic features.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions, space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Signing not currently supported, but planned.<br />
<br />
== OSTree ==<br />
<br />
;Disk layout<br />
:Only limited set of bootloaders supported (those that support [http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec The Boot Loader Specification] and some exceptions). The root file system has to have the /boot directory managed by OSTree. The actual deployed OS trees have certain conventions and requirements. For example, /etc and /var need to be writable, while /usr is mounted read-only.<br />
;Rootfs<br />
:Files provided by OS are expected to be in /usr, which is mounted read-only. /etc and /var are writable.<br />
;Updates from<br />
:Local and remote repostories. OSTree works by replicating a repository to the target device and then "checking out" deployment directories from the repository. Local and HTTP methods for replicating the repository are available.<br />
;Updates what<br />
:OSTree (atomically) updates root file system trees and the kernel. If anything else needs to be updated, it needs to happen by running custom code on the target device.<br />
;Code stability<br />
:OSTree is relatively stable. It's used by many distributions and projects, such as Fedora Atomic and Flatpak. OSTree is under active development and has an open-source community around it.<br />
;OE/Yocto integration<br />
:Meta-ostree layer is work in progress.<br />
;Resource requirements on server<br />
:OSTree generates "commit objects" based on the filesystem changes between builds. These commit objects are stored in a commit chain the same way as git does. The commit objects transmitted over the network as binary diffs when the remote and local repositories are synchronized.<br />
;Resource requirements on client<br />
:Client has the local copy of the repository. The repository contains the objects, which map to the files on the OS trees. The deployments of the OS trees (or "checkouts" in git termininology) are made using hard links to the repository content. This means that the required space is only increased when the data changes: the static data files are shared between deployments.<br />
:OSTree allows deleting of data. This means that the full operating system history doesn't need to be stored in the repository. A typical OSTree-based system might have two deployed OS trees: one that is being currently used and one fallback.<br />
;Failure resilience<br />
:OSTree controls the booting to the different deployed trees using bootloader entries. If booting a deployed OS tree fails, a different bootloader entry can be chosen for booting into a different OS tree.<br />
;Complexity<br />
:Some work is needed to fit the root filesystem into the conventions that OSTree likes. Some documentation of the needed steps [https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ is available here].<br />
;Downtime<br />
:Reboot is required after updates. Changing between deployed OS trees is done by selecting a different boot loader entry.<br />
;Security<br />
:The commits can be signed with GPG-based signatures. OSTree repositories store file extended attributes, which means that the security mechanisms using extended attributes should be functional with OSTree.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=22940System Update2017-01-16T15:23:14Z<p>Patrick Ohly: add link to meta-updater</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| fixed, U-Boot as boot loader<br />
| conceptually read-only<br />
| remote<br />
| Complete rootfs, including kernel.<br />
| in development<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| archives full image per build<br />
| download and write full image<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS<br />
|-<br />
! [https://github.com/ostreedev/ostree OSTree]<br />
| file-based<br />
| flexible, but supports only limited set of bootloaders<br />
| read/write, OS trees bind mounted read-only, /etc and /var writable<br />
| local and remote repositories<br />
| kernel and filesystem<br />
| relatively stable, significant user base, under active development<br />
| meta-ostree (WIP), [https://github.com/advancedtelematic/meta-updater meta-updater] (public)<br />
| generating commits based on new builds, storing them in repository<br />
| updating local repository, hard links for sharing unchanged content between deployments<br />
| rollback to a different deployed OS tree<br />
| some work required<br />
| reboot required<br />
| GPG-signed commits<br />
|}<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly or not at all (examples: [https://github.com/clearlinux/swupd-server/pull/25 assumption about filesystem], [https://github.com/clearlinux/swupd-server/pull/26 error checking], [https://github.com/clearlinux/swupd-client/pull/71 path configuration]).<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: Dual rootfs partitions with two extra partitions, a boot and a data partition. Depends on U-Boot as boot loader for the automatic rollback.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender server and/or HTTPS server<br />
;Code stability<br />
: Master branch under development. There is a stable branch, but it's lacking many basic features.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions, space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Signing not currently supported, but planned.<br />
<br />
== OSTree ==<br />
<br />
;Disk layout<br />
:Only limited set of bootloaders supported (those that support [http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec The Boot Loader Specification] and some exceptions). The root file system has to have the /boot directory managed by OSTree. The actual deployed OS trees have certain conventions and requirements. For example, /etc and /var need to be writable, while /usr is mounted read-only.<br />
;Rootfs<br />
:Files provided by OS are expected to be in /usr, which is mounted read-only. /etc and /var are writable.<br />
;Updates from<br />
:Local and remote repostories. OSTree works by replicating a repository to the target device and then "checking out" deployment directories from the repository. Local and HTTP methods for replicating the repository are available.<br />
;Updates what<br />
:OSTree (atomically) updates root file system trees and the kernel. If anything else needs to be updated, it needs to happen by running custom code on the target device.<br />
;Code stability<br />
:OSTree is relatively stable. It's used by many distributions and projects, such as Fedora Atomic and Flatpak. OSTree is under active development and has an open-source community around it.<br />
;OE/Yocto integration<br />
:Meta-ostree layer is work in progress.<br />
;Resource requirements on server<br />
:OSTree generates "commit objects" based on the filesystem changes between builds. These commit objects are stored in a commit chain the same way as git does. The commit objects transmitted over the network as binary diffs when the remote and local repositories are synchronized.<br />
;Resource requirements on client<br />
:Client has the local copy of the repository. The repository contains the objects, which map to the files on the OS trees. The deployments of the OS trees (or "checkouts" in git termininology) are made using hard links to the repository content. This means that the required space is only increased when the data changes: the static data files are shared between deployments.<br />
:OSTree allows deleting of data. This means that the full operating system history doesn't need to be stored in the repository. A typical OSTree-based system might have two deployed OS trees: one that is being currently used and one fallback.<br />
;Failure resilience<br />
:OSTree controls the booting to the different deployed trees using bootloader entries. If booting a deployed OS tree fails, a different bootloader entry can be chosen for booting into a different OS tree.<br />
;Complexity<br />
:Some work is needed to fit the root filesystem into the conventions that OSTree likes. Some documentation of the needed steps [https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ is available here].<br />
;Downtime<br />
:Reboot is required after updates. Changing between deployed OS trees is done by selecting a different boot loader entry.<br />
;Security<br />
:The commits can be signed with GPG-based signatures. OSTree repositories store file extended attributes, which means that the security mechanisms using extended attributes should be functional with OSTree.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21977System Update2016-12-12T08:42:11Z<p>Patrick Ohly: swupd pull request examples</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| fixed, U-Boot as boot loader<br />
| conceptually read-only<br />
| remote<br />
| Complete rootfs, including kernel.<br />
| in development<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| archives full image per build<br />
| download and write full image<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704)<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly or not at all (examples: [https://github.com/clearlinux/swupd-server/pull/25 assumption about filesystem], [https://github.com/clearlinux/swupd-server/pull/26 error checking], [https://github.com/clearlinux/swupd-client/pull/71 path configuration]).<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: Dual rootfs partitions with two extra partitions, a boot and a data partition. Depends on U-Boot as boot loader for the automatic rollback.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender server and/or HTTPS server<br />
;Code stability<br />
: Master branch under development. There is a stable branch, but it's lacking many basic features.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions, space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Signing not currently supported, but planned.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21948System Update2016-12-09T15:12:17Z<p>Patrick Ohly: Mender + U-Boot dependency</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| fixed, U-Boot as boot loader<br />
| conceptually read-only<br />
| remote<br />
| Complete rootfs, including kernel.<br />
| in development<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| archives full image per build<br />
| download and write full image<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704)<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly.<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: Dual rootfs partitions with two extra partitions, a boot and a data partition. Depends on U-Boot as boot loader for the automatic rollback.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender server and/or HTTPS server<br />
;Code stability<br />
: Master branch under development. There is a stable branch, but it's lacking many basic features.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions, space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Signing not currently supported, but planned.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21947System Update2016-12-09T15:04:35Z<p>Patrick Ohly: /* Introduction */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| fixed<br />
| conceptually read-only<br />
| remote<br />
| Complete rootfs, including kernel.<br />
| in development<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| archives full image per build<br />
| download and write full image<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704)<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly.<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: Dual rootfs partitions with two extra partitions, a boot and a data partition.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender server and/or HTTPS server<br />
;Code stability<br />
: Master branch under development. There is a stable branch, but it's lacking many basic features.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions, space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Signing not currently supported, but planned.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21946System Update2016-12-09T14:48:23Z<p>Patrick Ohly: summary in table, details in sections</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
A similar comparison was done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
<br />
Some talks at Embedded Linux Conference presented an overview of the current mechanisms:<br />
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf<br />
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q<br />
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play<br />
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| flexible<br />
| read/write<br />
| HTTP(S) server, local media<br />
| depends on setup<br />
| relatively stable, under active development<br />
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]<br />
| moderate, suitable for frequent updates<br />
| minimal download, needs sufficient free space in rootfs<br />
| favors fast updates over failure resilience<br />
| some planning required<br />
| minimal, reboot optional<br />
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| flexible<br />
| depends on setup<br />
| local and remote (plain HTTP(S) or custom server)<br />
| depends on setup<br />
| Code relatively stable, 3 months release cycle<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate]<br />
| archives full image per build<br />
| download and write full image<br />
| no builtin mechanism, to be added as part of system<br />
| easy to use (but requires customization!?)<br />
| reboot required<br />
| signed and encrypted images, HTTPS<br />
|-<br />
! [https://mender.io/ Mender]<br />
| block-based<br />
| fixed<br />
| conceptually read-only<br />
| remote<br />
| Complete rootfs, including kernel.<br />
| in development<br />
| [https://github.com/mendersoftware/meta-mender meta-mender]<br />
| archives full image per build<br />
| download and write full image<br />
| integrated rollback<br />
| easy when using meta-mender<br />
| reboot required<br />
| HTTPS<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704)<br />
<br />
== swupd ==<br />
<br />
;Disk layout<br />
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.<br />
;Rootfs<br />
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
;Updates from<br />
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.<br />
;Updates what<br />
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.<br />
;Code stability<br />
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly.<br />
;OE/Yocto integration<br />
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).<br />
;Resource requirements on server<br />
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
;Resource requirements on client<br />
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
;Failure resilience<br />
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.<br />
;Complexity<br />
: Upgrade path must be considered as part of release process (deltas, incompatible changes).<br />
;Downtime<br />
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).<br />
;Security<br />
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).<br />
<br />
<br />
== babic's SWUpdate ==<br />
<br />
;Disk layout<br />
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.<br />
;Rootfs<br />
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.<br />
:<br />
: SWUpdate is often used in one of the following setup:<br />
:<br />
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.<br />
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.<br />
;Updates from<br />
:<br />
:* local provisioning : USB, SD, etc.<br />
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.<br />
:* Webserver : SWUpdate integrates a Webserver (moongoose)<br />
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.<br />
;Updates what<br />
:<br />
:* bootloader (risky !)<br />
:* kernel<br />
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
;* disk partitions<br />
;* provide interface to update FPGAs, external microcontrollers, etc.<br />
;* custom handlers: an interface allows to add own installers written in C or in LUA.<br />
;Resources on client<br />
:<br />
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).<br />
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.<br />
;Failure resilience<br />
: There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
; Downtime<br />
:<br />
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image. <br />
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime. <br />
;Security<br />
:<br />
:* Connection with HTTPS to the external the server.<br />
:* Signed images : it is possible to sign the images used for the update in order to check its integrity.<br />
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer. The installer runs often with high privileges because it has to write the hardware.<br />
:* Support for encrypted artifacts<br />
<br />
<br />
== Mender ==<br />
<br />
;Disk layout<br />
: Dual rootfs partitions with two extra partitions, a boot and a data partition.<br />
;Rootfs<br />
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions. Kernel is stored on rootfs.<br />
; Updates from<br />
: Mender server and/or HTTPS server<br />
;Code stability<br />
: Master branch under development. There is a stable branch, but it's lacking many basic features.<br />
;Resources on server<br />
: Needs to store one compressed rootfs image for each update, plus small meta data section.<br />
;Resources on client<br />
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions, space for the Mender binary, and a tiny local database.<br />
;Failure resilience<br />
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.<br />
;Complexity<br />
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].<br />
;Downtime<br />
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.<br />
;Security<br />
: Secure connection to the server (TLS). Signing not currently supported, but planned.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21871System Update2016-12-06T09:43:05Z<p>Patrick Ohly: </p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
A similar comparison was done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Files in the rootfs, boot loader and kernel via plugins<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Upgrade path must be considered as part of release process (deltas, incompatible changes)<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|-<br />
! [https://github.com/sbabic/swupdate sbabic's swupdate]<br />
| block-based<br />
| A complete partition. Arbitrary disk layout, kernel, filesystem and boot mechanism.<br />
| Read only. Partiton must not be mounted. Device must boot from maintenance image (could be in another partition in the same disk).<br />
| Local provisioning of image file or use mongoose HTTP server.<br />
| Complete partition. Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.<br />
| Code relatively stable, but there is only a master branch and no versioning.<br />
| [https://github.com/sbabic/meta-swupdate meta-swupdate] (Not part of the Yocto project).<br />
| Just need to build the update image and package it with a configuration file (sw-description).<br />
| It needs to have at least two partition; production and maintenance. To perform the update it requires to download the image file to the maintenance partition, so it requires the maintenance partition needs to be big enough to hold the image file.<br />
| There are no recovery mechanism built in. If the bootloader has the capability to check if a boot failed, it could boot in maintenance mode again.<br />
| This updater is very easy to use and setup, even if not using the OE layer.<br />
| There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image.<br />
| It is possible to sign the images used for the update in order to check its integrity.<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704) and mender.io (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10703)<br />
TODO: move text from table into the sections of the individual mechanisms to keep the table short. Perhaps just keep a rating ("low/middle/high complexity") above in some of the columns? Rating would be relative to each other.<br />
<br />
== swupd ==<br />
<br />
TODO: when using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs.<br />
<br />
== SWUpdate ==<br />
<br />
TODO: additional explanations?</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21816System Update2016-12-01T07:42:33Z<p>Patrick Ohly: /* Introduction */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
A similar comparison was done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Files in the rootfs, boot loader and kernel via plugins<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Upgrade path must be considered as part of release process (deltas, incompatible changes)<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704) and mender.io (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10703)<br />
TODO: move text from table into the sections of the individual mechanisms to keep the table short. Perhaps just keep a rating ("low/middle/high complexity") above in some of the columns? Rating would be relative to each other.<br />
<br />
== swupd ==<br />
<br />
TODO: when using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21664System Update2016-11-28T12:54:52Z<p>Patrick Ohly: /* Comparison */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Files in the rootfs, boot loader and kernel via plugins<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Upgrade path must be considered as part of release process (deltas, incompatible changes)<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704) and mender.io (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10703)<br />
TODO: move text from table into the sections of the individual mechanisms to keep the table short. Perhaps just keep a rating ("low/middle/high complexity") above in some of the columns? Rating would be relative to each other.<br />
<br />
== swupd ==<br />
<br />
TODO: when using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21663System Update2016-11-28T12:51:53Z<p>Patrick Ohly: /* Comparison */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Files in the rootfs, boot loader and kernel via plugins<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Upgrade path must be considered as part of release process (deltas, incompatible changes)<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704) and mender.io (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10703)<br />
<br />
== swupd ==<br />
<br />
TODO: when using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21636System Update2016-11-25T10:04:27Z<p>Patrick Ohly: /* Comparison */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Files in the rootfs, boot loader and kernel via plugins<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Upgrade path must be considered as part of release process (deltas, incompatible changes)<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}<br />
<br />
TODO: add OSTree (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10704) and mender.io (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10703)<br />
<br />
== swupd ==<br />
<br />
TODO: when using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs.</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21629System Update2016-11-24T20:34:53Z<p>Patrick Ohly: added complexity and "updates what"</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Updates what<br />
: describes which parts of the overall system the mechanism updates.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Complexity<br />
: Some mechanisms are harder to use correctly than others.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Updates what<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Complexity<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Files in the rootfs, boot loader and kernel via plugins<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Upgrade path must be considered as part of release process (deltas, incompatible changes)<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21627System Update2016-11-24T20:16:30Z<p>Patrick Ohly: /* Comparison */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| HTTP(S) server<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21625System Update2016-11-24T20:06:11Z<p>Patrick Ohly: /* Comparison */</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| HTTP(S) server<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21612System Update2016-11-24T16:18:29Z<p>Patrick Ohly: </p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition cannot be changed locally. Devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]<br />
| file-based<br />
| HTTP(S) server<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of downloaded files.<br />
|}</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=System_Update&diff=21611System Update2016-11-24T16:17:17Z<p>Patrick Ohly: Created page with "== Introduction == This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will supp..."</p>
<hr />
<div>== Introduction ==<br />
<br />
This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.<br />
<br />
A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:<br />
* never ends up in an inconsistent state (atomic update),<br />
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),<br />
* requires little additional resources (disk space, RAM),<br />
* minimizes downtime while updating,<br />
* works in combination with security technology (integrity protection),<br />
* is secure (does not install or execute software created by an attacker).<br />
<br />
These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.<br />
<br />
== Comparison ==<br />
<br />
;Type<br />
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition cannot be changed locally. Devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.<br />
;Disk layout<br />
: Boot loader, number and kind of partitions, ...<br />
;Rootfs<br />
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.<br />
;Updates from<br />
: describes from where the update mechanism gets the update.<br />
;Code stability<br />
: Based on how long the code has been in use, personal experience, etc.<br />
;OE/Yocto integration<br />
: Whether the mechanism is already available and who supports it.<br />
;Resource requirements on server<br />
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.<br />
;Resource requirements on client<br />
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.<br />
;Failure resilience<br />
: Summarizes how the mechanism copes with potential problems.<br />
;Downtime<br />
: How long normal operation of the device needs to be interrupted for an update.<br />
;Security<br />
: Compatibility with other technology, protection of the update mechanism itself.<br />
<br />
{| class="wikitable"<br />
! rowspan="2"|Mechanism<br />
! rowspan="2"|Type<br />
! rowspan="2"|Disk layout<br />
! rowspan="2"|Rootfs<br />
! rowspan="2"|Updates from<br />
! rowspan="2"|Code stability<br />
! rowspan="2"|OE/Yocto integration<br />
! colspan="2"|Resource requirements<br />
! rowspan="2"|Failure resilience<br />
! rowspan="2"|Downtime<br />
! rowspan="2"|Security<br />
|-<br />
! on server<br />
! on client<br />
|-<br />
! [swupd https://clearlinux.org/documentation/swupdate_about_sw_update.html]<br />
| file-based<br />
| HTTP(S) server<br />
| All files in a single partition. Arbitrary disk layout, filesystem and boot mechanism.<br />
| Read/write. Files provided by the OS are read-only, everything else is read/write (/etc, /var). OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.<br />
| Used in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype).<br />
| meta-swupd (work in progress, not part of the Yocto project). No support for automatically updating at the moment.<br />
| Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.<br />
| In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.<br />
| No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left.<br />
| Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot (needs to be automated).<br />
| Compatible with Linux IMA, Smack, SELinux. Incompatible with dm-verity. Relies on HTTPS and (optionally) [signing https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture] to protect integrity of downloaded files.<br />
|}</div>Patrick Ohlyhttps://wiki.yoctoproject.org/wiki/index.php?title=Projects&diff=21610Projects2016-11-24T11:51:54Z<p>Patrick Ohly: /* Welcome to the Projects Page */</p>
<hr />
<div>== Welcome to the Projects Page ==<br />
* [[AutoBuilder]]<br />
* [[Poky]]<br />
* [[Eclipse Plug-in]]<br />
* [[Anjuta Plug-in]]<br />
* [[Pseudo]]<br />
* [[Cross-Prelink]]<br />
* [[QA]]<br />
* [[Documentation]]<br />
* [[BSPs]]<br />
* [[Tracing and Profiling]]<br />
* Linux Kernel<br />
** [[Linux_Kernel/Boot_Time|Boot Time]]<br />
** [[Linux_kernel/Image_Size|Image Size]]<br />
* [[Multilib]]<br />
* [[BitBake/GUI|BitBake GUI's]]<br />
* [[x32 abi]]<br />
* [[Build Appliance Design]]<br />
* [[Toaster]]<br />
* [[OpenGL pass-through in QEMU]]<br />
* [[Running an x86 Yocto Linux image under QEMU KVM]]<br />
* [[Web Application for Interactive Kiosk Devices]]<br />
* [[Virtualization with KVM]]<br />
* [[Poky-Tiny]]<br />
* [[System Update]]<br />
* [[Wayland]]<br />
<br />
== Archived Projects ==<br />
* [[SDK Generator]]<br />
* [[Hob2 (Hob v2)]]<br />
* [[DLNA Media Server Virtual Appliance]]<br />
* [[Swabber]]<br />
* [[Baryon]]<br />
* [[ELC2013kiosk_demo]]</div>Patrick Ohly