Restic backup creates a snapper snapshot of the root system which it
then chroots into and starts a restic backup to a (wasabi) S3 bucket to.
Intended to roughly follow this
<https://codeberg.org/silmaril/my-restic-solution> solution to achieve
restic backup of the _newest_ snapshot of my live root system.
Sets up a login screen using tuigreet. From there the user is thrown
into a shell. Other units/services (usually, the user service `river`)
take care to start an actual wayland session for the user.
Creates separate snapper services for root and home directories. Does
_not_ yet set up any btrfs mounts or ensure that they are mounted at the
locations.
Instead of changing a line in the sudoers file we just copy a new
drop-in file into the sudoers.d/ dir. Easier, less error-prone and
allows everyone to see 'who' the sudo enabled users are (since it is
world readable).
User services under control of runit under turnstiled now default to the
`~/.local/state/service/` directory (and `~/.local/state/service-env/`
for the env vars). This mimics the system-wide runit setup, with service
templates kept in `/etc/sv` (in my case `~/.config/sv` for user
services) and active ones in `/var/service`
For now, putting the associated files simply within the books/ directory
as well is the simplest solution. It also removes some clutter from the
root directory. If we refactor later, this will be changed overall
anyway.
Can be used to have the ansible playbook run on the currently running
(host) machine, using a local connection instead of a chroot.
TODO: This _will_ change your host machine so be careful running this.
Additionally, we need to find a way to deduplicate the inventory
variables since we have them doubled for chroot/local now.
Allows setting the current target to any of the groups sorted by target
type (i.e. 'what' type of machine it is). For example, we currently
target our system to a 'workstation' type machine. But we could switch
it to a headless machine which would not install any of the DE/GUI
grouped packages.
If assigning a list of 'host's to a group those become actual hosts and
have their own host variables. What we want to use groups with
child/parent relationships to group things is to not directly use hosts.
This should allow just having a general 'target' system for ansible
which will take all the modifications - but not care whether we connect
to it locally (i.e. running from void) or through chroot.
We can set the connection method for the specific system(s) in whatever
we group as part of the target group then. For local installation we
simply add locally connected hosts and for chroot set up chrooted hosts.
It does not work like I want it to - presumably since it counts for
tasks _within_ the play while it is the connection for the play itself
which requires root?
