Skip to content

Ansible based automation scripts for my Arch Linux machines

License

Notifications You must be signed in to change notification settings

raphiz/my-arch-setup

Repository files navigation

My Arch Setup

This Repository contains Ansible based automation scripts for my Arch Linux machines.

To be able to run the Ansible playbook, an Arch Linux installation is required. Some parts of the playbook also assume a particular BTRFS partition layout that enables roll back to a previous system snapshot.

Attribution

The base system installation is mostly derived from articles of the ArchWiki.

The BTRFS subvolume concept is inspired by John Ramsden's blog post.

Many Ansible roles are derived from pigmonkey's spark playbook.

License

The code in this repository is MIT licensed

How to use

The installation is described in a separate document. Before you start though you should create a custom hosts directory.

Hosts Directory

An entire system setup as this requires secret information, such as SSH-keys and passwords. Also, this setup is not limited to just one specific machine but can be used for multiple similar installations, for example, for work and private purposes. To achieve these properties a dedicated hosts directory exists, that can be managed separately and privately (to keep secrets private). It's recommended to keep the hosts directory under version control as well. The hosts directory is placed directly in the root of this repository and might look like this (containing two hosts):

hosts/
    files/
        host1/
            ssh_keys/
                id_rsa
                id_rsa.pub
                known_hosts
        host2/
            ssh_keys/
                id_rsa
                id_rsa.pub
    inventory/
        host_vars/
            host1.yaml
            host2.yaml
        hosts

The files id_rsa, id_rsa.pub and known_hosts are for illustration purposes only and can be replaced with any kind of key and configuration filed as placed in .ssh. I strongly recommended encrypting the SSH private keys. You might want to encrypt other files such as known_hosts as well using ansible vault.

The inventory directory contains the host-specific configurations. The hosts file might look as follows:

[local]
host1 ansible_connection=local
host2 ansible_connection=local

The files host1.yaml and host2.yaml contain the host-specific configuration. They should be encrypted using ansible vault, as they contain the user password. Here is an example host configuration:

hostname: host1

hardware:
  disk_name: /dev/sda

user:
  name: userX
  uid: 1000
  group: userX
  password: top-secret
  password_salt: XYZ123
  mail: user@example.com

features:
  - virtualbox

apps:
  - youtube-dl

The parameters of this configuration file are used in the roles defined in this repository, and you can find out more about them by browsing through this repo (I know, just a bad excuse because I'm too lazy to document it).

BTRFS Subvolume Concept

The primary motivation for this subvolume concept was to be able to roll back the system to a minimal base state, on which the main ansible setup can be executed without affecting user data. This saves time (no fresh arch installation required) and is good hygiene.

The concept used in the installation script assumes three versions of the file system root, all of which are just BTRFS subvolumes/snapshots. The EDGE subvolume is used on a daily basis as one uses any other operating system. It is upgraded frequently and changes continuously.

Before pacman changes anything, a hook makes a copy of the EDGE subvolume. If something breaks after a package upgrade and things "just have to work", one can quickly roll-back to this snapshot. These subvolumes are prefixed with pacman-, or example pacman-2021-02-09.

After the base installation, the MINIMAL subvolume is created. One can always roll back to this state to cleanly rerun this Ansible setup from scratch.

Some subdirectories, such as /home, are separate BTRFS-subvolumes and not affected by these rollback actions, as they are not part of the system configuration.

Note that all subvolumes are NOT read-only (it's not possible to boot them otherwise) and are, therefore, not real snapshots. If you have an idea how to fix this, please open an issue or contact me!

Regular Ansible Restore

The system can be rolled back to the MINIMAL-Snapshot to get a fresh and clean setup as described in this playbook without having to do the whole Arch Linux base system installation.

  1. Boot into MINIMAL snapshot
  2. Update the snapshot by calling pacman -Syu
  3. Backup the current EDGE snapshot as STABLE /config/scripts/backup_edge_as_stable.bash
  4. Roll back the EDGE snapshot to MINIMAL /config/scripts/reset_edge_to_minimal.bash
    • This might fail with an error "Directory not empty". This might be due to existing docker images/volumes. docker system prune -a && docker volume prune can be used to delete all containers, images and volumes.
  5. Reboot into EDGE
  6. Run Ansible /config/run.bash

In case a package update broke the system, you can roll back to the latest STABLE snapshot. The STABLE should still work as it is updated before every Pacman transaction.

  1. Boot into STABLE
  2. Run /config/scripts/reset_edge_to_stable.bash
  3. Boot into EDGE

About

Ansible based automation scripts for my Arch Linux machines

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published