Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add reset command #320

Open
taukakao opened this issue Jul 18, 2024 · 10 comments
Open

add reset command #320

taukakao opened this issue Jul 18, 2024 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@taukakao
Copy link
Member

taukakao commented Jul 18, 2024

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.

@taukakao taukakao added the enhancement New feature or request label Jul 18, 2024
@taukakao taukakao added this to the 2-after-stable milestone Jul 18, 2024
@taukakao taukakao moved this to To discuss in 2 - Orchid Jul 18, 2024
@leyloe
Copy link

leyloe commented Jan 21, 2025

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

@taukakao
Copy link
Member Author

taukakao commented Jan 21, 2025

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
Copy link

leyloe commented Jan 22, 2025

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
Copy link
Member Author

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

@leyloe
Copy link

leyloe commented Jan 26, 2025

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
Copy link
Member Author

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
Copy link

leyloe commented Jan 26, 2025

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
Copy link
Member Author

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

@leyloe
Copy link

leyloe commented Jan 26, 2025

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
Copy link
Member Author

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.

@taukakao taukakao self-assigned this Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: To discuss
Development

No branches or pull requests

2 participants