add reset command

[taukakao]

It might be useful to offer a reset command that clears out any added packages and resets the kernel args to default.

It could also have an option to clear out the /etc for everything except necessary files like /etc/shadow.

[leyloe]

• Prompt asking for the configuration of applications/folders/files to preserve. Remember that choice for next time

[taukakao]

This is a command that would be run very rarely. I think keeping the choices would make this a lot more confusing and unsafe.

[leyloe]

Would this also reset all of the Systemctl services to be regenerated? I could imagine someone messing with that, and adding or deleting too many services

[taukakao]

I mean yeah, it's a reset, it will reset the hosts configuration, including systemd stuff.

[leyloe]

I mean yeah, it's a reset, it will reset the hosts configuration, including systemd stuff.

any resources useful for this (like what configuration to keep, or how to reset systemd)? don't rely on it, but ill not likely but maybe draft my own utility, and possibly implement a abroot function for it in go

i think the permissions for these files/directories should be unchangeable, and checked for tampering on bootup like what abroot does for other root directories

[taukakao]

like what configuration to keep, or how to reset systemd

I would go about it in this way:

1. Make a fresh install in a VM, look at the files in /var/lib/abroot/etc/vos-a
2. decide which are crucial for system operation (like /etc/shadow for example)
3. Delete all but these files from /var/lib/abroot... after doing an upgrade

i think the permissions for these files/directories should be unchangeable

Absolutely disagree here. That would make VOS practically unusable since many apps (including Gnome ones) expect to be able to write there to perform system configuration.

[leyloe]

like what configuration to keep, or how to reset systemd

I would go about it in this way:

1. Make a fresh install in a VM, look at the files in /var/lib/abroot/etc/vos-a
2. decide which are crucial for system operation (like /etc/shadow for example)
3. Delete all but these files from /var/lib/abroot... after doing an upgrade

i think the permissions for these files/directories should be unchangeable

Absolutely disagree here. That would make VOS practically unusable since many apps (including Gnome ones) expect to be able to write there to perform system configuration.

no not the files, i mean the actual permissions themselves. everything can still be writable. but the actual permissions should not be able to be modified since it's not needed

[taukakao]

Don't see the big benefit in that either. Why would users randomly change permissions of files in /etc?

[leyloe]

Don't see the big benefit in that either. Why would users randomly change permissions of files in /etc?

why would users randomly change /bin? might as well remove read only functionality

p.s ive seen shell scripts change /etc permissions before, so keep that in mind

it's better to just add safeguards regardless

[taukakao]

Users would not randomly change /bin, they would deliberately change /bin to install software there if it was possible.

Basically, I just don't think it's worth it. It does make the boot process more complicated which can hurt stability instead of improving it if there's a bug, it slows down the boot, it's quite a bit work to properly implement this and I'm not convinced that it solves a problem that anyone actually has.

A proper solution to the problem is a recovery mode boot option where the user can reset their /etc folder.

[justsaft]

I really like this idea of this. Tho may I add that I'd like it to touch /var as little as necessary, so it becomes effectively a freshly-ish set up host without the removal of any user data. I believe OSTree already has this in the form of ostree reset tho I don't know the extent of it. Ideally /etc gets reset to the exact state that a fresh installation of desktop-image or custom image with extra files in /etc would give you.

Some misc. thoughts:

• Doesn't necessarily need to delete the old root
• Maybe this could be used to reset the ABroot package agreement (e.g. user moves from abroot pkg packages to a custom image).

[taukakao]

I'd say it needs to be configurable either way. Not sure if monifying stuff in /var would even be practical though so not sure if it should even be an option, it might break too much.