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.
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.
