Systemd 215 Works On Factory Reset, DHCPv4 Server Support

[newwen]

Stateless systems... Factory reset... Rootkits... DRMs... I bet RedHat and Canonical are loving the lyrics...

I love the sound of systemd trolling in the morning

[Vash63]

Stateless systems... Factory reset... Rootkits... DRMs... I bet RedHat and Canonical are loving the lyrics...

So... two things that actually are part of systemd and aren't bad at all, followed by two completely random things that have nothing to do with systemd. My, that escalated quickly.

[stevenc]

Does it retain MY installation modifications (like fs layout) ?

You're not allowed to make such modifications. A user has no business doing this. systemd knows best.

[erendorn]

You're not allowed to make such modifications. A user has no business doing this. systemd knows best.

Aahh.. If anything, systemd threads are great ignore list feeders.

[doom_Oo7]

You're not allowed to make such modifications. A user has no business doing this. systemd knows best.

• sd auto-detects your basic layout
• if you have custom settings you want to keep, why would you do a factory reset ? I only factory reset my phone when it is not working or stuff like this... I could also see the use in my school where every student computer is a VM...

[interested]

Does it retain MY installation modifications (like fs layout) ? I mean this sounds like a useless feature. Why not just snapshot /etc after install and make user changes into the snapshot so you can revert back ? Restore points before upgrades/changes are more usefull since they are granular ... not all or nothing ....

The problem with using a snapshot to restore a system to a pristine state is, that you thereby also looses all security updates and all packages added or removed since.( you also need extra disk space, a problem on embedded devices). A Factory Reset may keep all the binaries in /usr (and can verify them cryptographically to be in a pristine state), so the system remains secure at all times.

Factory Resets (FR) as feature in it self isn't so important for individual people running a traditional desktop system, though a handy feature nonetheless. But the changes needed to get a stateless system are beneficial to all. It will make Linux a more robust system, especially when it comes to system upgrades and installations.

There are +100.000.000 devices running Linux (not counting Android and pc's), from routers, NAS', SmartTVs, Navigation and entertainment systems etc. Such systems can really benefit from a standard, easy way to do a Factory Reset.

Factory Resets, Reproducible Systems, Stateless Systems, Verifiable Systems, are now potentially possible because of Systemd. There are however still a long way to go to actually implement these features in distros, but when that work is done, Linux will be even better that it is now.

Poettering has a good overview here:

http://0pointer.de/blog/projects/

[SpyroRyder]

This factory reset SOUNDS like a good idea but I am just wondering how they'd handle rengenerating all this stuff. I can only speak as an arch user so I'd be doing it all manually i'm guessing but what about Fedora or the 'buntus. Would they have to develop distro specific additions to this just to regen everything correctly especially seeing how a lot of that "first time config" (like locale, timezone, system mountpoints) is handled on install and not after. The other concern I have is that as it leaves /usr untouched all the packages you installed will still be there but the records of them won't be, your system will think it's vanilla. So i'm either missing something or it doesn't seem well thought out

[You-]

This factory reset SOUNDS like a good idea but I am just wondering how they'd handle rengenerating all this stuff. I can only speak as an arch user so I'd be doing it all manually i'm guessing but what about Fedora or the 'buntus. Would they have to develop distro specific additions to this just to regen everything correctly especially seeing how a lot of that "first time config" (like locale, timezone, system mountpoints) is handled on install and not after. The other concern I have is that as it leaves /usr untouched all the packages you installed will still be there but the records of them won't be, your system will think it's vanilla. So i'm either missing something or it doesn't seem well thought out

There are still a few missing pieces of the puzzle.

To get to the final version of this, it requires changes to more than systemd.

The idea is that

1. all packages are installed to /usr (eg Fedora's UsrMove a few years back) - This is either mostly done or in the process for many distributions
2. the packagemanager stores the package database in /usr (as it is not configuration) - AFAIK This still needs to be done in most cases.
3. Packages put pristine unmodified packagemanager-managed config files in another location inside /usr (usr/etc?)

Then the installed packages in /usr will be known per /usr and if /etc is missing/deleted, it can be repopulated by the pristine package manager managed versions from the alternate location.

[ghexsel]

The use-case for these features, if I understand it correctly, is "kiosk mode", where the system is shipped ready for production and just needs to process information that is either fixed (like a real info kiosk) or that is accessed from other means, e.g. a node on a map-reduce large deployment. You feed it data and the task, it processes it and returns/forwards it somewhere else (maybe even to a Network-Attached Storage).

If you think about it, most server installations could run somewhat like this, if you consider NAS as "external state".

[interested]

This factory reset SOUNDS like a good idea but I am just wondering how they'd handle rengenerating all this stuff. I can only speak as an arch user so I'd be doing it all manually i'm guessing but what about Fedora or the 'buntus. Would they have to develop distro specific additions to this just to regen everything correctly especially seeing how a lot of that "first time config" (like locale, timezone, system mountpoints) is handled on install and not after. The other concern I have is that as it leaves /usr untouched all the packages you installed will still be there but the records of them won't be, your system will think it's vanilla. So i'm either missing something or it doesn't seem well thought out

There is still quite a bit of work to do before all those features can be implemented, including changes in the file layout and where certain files/packages are installed. For example, the package database could be moved to /usr or similar, since it contains description of the packages in /usr, so the system will be fully functional after a Factory Reset.

Most systems will probably run a "configuration wizard" after a Factory Reset to enable the user to enter new config information, just like after or during an install.

For those users that running a Linux distro directly on metal in a non-office environment, a Factory Reset probably isn't a very important feature. It is the features (like the /usr merge) that makes a FR possible that are of general interest, since the new design and layout makes upgrades, installs and maintenance much more robust and secure. It will also make life easier for distro and package maintainers.
It also enables multi user systems, where thousands of users all share the same /usr, but each have their own /etc and /var, so it is perfect for "kiosk/thin/fat" clients that are booted and configured from network.

To me the most important new feature is that /usr can be strictly read-only and fully cryptographically verified as one unit. Systems needs to be as secure as possible by design and with as little user interaction as possible and still provide general use systems that aren't locked down so they are very secure but nothing of interest can be done.