|
|
Log in / Subscribe / Register

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 19, 2014 6:39 UTC (Thu) by Chousuke (subscriber, #54562)
In reply to: Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems by joib
Parent article: Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

I don't quite understand your point. You would simply put all information needed to get the base system running outside /etc; mounts, services (like database servers, if it even makes sense to run those in a stateless environment) etc. would be configured via unit files under /usr.

Networking would have to be done via DHCP or some other means, but that or dynamically populating /etc is out of the scope here.

The issue before has been that /var and /etc contained important information that couldn't just be thrown away on each boot without hosing the system, making it next to impossible to implement a reliable "factory reset". Given the way systemd works, a factory reset would just rm /etc and /var and on the next boot all the default settings under /usr would be in effect until overriding configuration is put in place under /etc.


to post comments

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 19, 2014 11:41 UTC (Thu) by joib (subscriber, #8541) [Link] (2 responses)

My point is that in many cases some amount of state is necessary, and if one can solve how to "import" this necessary state into an otherwise "stateless system", one could then take advantage of the benefits of stateless systems without having to let go of the concept entirely.

I'm not saying systemd developers are responsible for solving this problem; they're doing what they can and "factory reset" capability is certainly useful for many usecases.

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 19, 2014 11:59 UTC (Thu) by Chousuke (subscriber, #54562) [Link]

I imagine this to be out of scope for what systemd needs to do; there are too many ways to solve the problem for it to make sense for systemd to provide the one true way.

I imagine with a stateless system a computer would start up, get an IP via DHCP or IPv6 autoconfiguration, then connect to a fleet cluster eg. via anycast or DNS, and start providing some service. No need for a persistent /etc at all.

Another approach could be a systemd generator included in the base image that does much the same, but dynamically generates systemd units under /run depending on its environment.

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 19, 2014 13:21 UTC (Thu) by drag (guest, #31333) [Link]

You could choose to provide the configuration with file system labels.

Like LABEL=/var or whatever. Then configure they OS to check for those at boot up. That way you don't have to care about the underling hardware.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds