Always default to 'root' as a user_name if no variable has been set.
This can easily happen as not every role sets the variable and instead
we only set it once in the user role.
Another way to possibly go about it in the future would be to inject the
'user_name' into each role that needs it as one of that role's default
variables. If it is specified by the user somewhere it _should_
override those defaults, though I have to read up on the exact variable
precedence.
Since void defaults to building an 'initramfs-<kernelversion>.img' file
when running the update hook, I think it is just correct if we follow
their example.
This will make it harder to distinguish between kernels if you have many
others in the boot dir (e.g. Arch, or LTS) but that seems only an edge
case.
We disable the default ACPI handler script logic for LID events.
We _only_ disable that in the script - the default handler script will
still fire for LID events, just not do anything in its routine. That is
so that in the future it is easy to rectify with any upstream changes.
If, over time we add more custom event and action chain to our ACPI
settings, we can think about spinning out all event types into our own
rules and completely disabling the deafult handler script.
Our custom LID action only fires for LID open close events, and only
logs that the lid has been opened for open events. For close events, it
adds one extra step before suspending: Checking if any DP screens are
connected - and inhibiting suspend then. That way we still automatically
suspend when closing the screen lid if we are in portable mode (no
external screens connected) but do nothing if they are.
By setting the `desired_package_state` variable we can change if ansible
should only ensure that the packages exist on the system (`present`) or
that they are also updated to their latest version (`latest`).
One inventory targets a local machine (`inv-local.yaml`, chosen by default)
while the other targets a chrooted installation accessible from another
system, usually in the `/mnt/void` directory (`inv-chroot.yaml`, has to
be called like `ansible-playbook -i inv-chroot.yaml`).
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.
