ServerSpark

ServerSpark is an Ansible playbook meant to provision a personal machine running Arch Linux. It is intended to run locally on a fresh Arch install (ie, taking the place of any post-installation), but due to Ansible's idempotent nature it may also be run on top of an already configured machine.

ServerSpark assumes it will be run on a headless server and performs some configuration based on this assumption.

Running

First, sync mirrors and install Ansible:

$ pacman -Syy python2-passlib ansible

Second, install and update the submodules:

$ git submodule init && git submodule update

Run the playbook as root.

# ansible-playbook -i localhost playbook.yml

When run, Ansible will prompt for the user password. This only needs to be provided on the first run when the user is being created. On later runs, providing any password -- whether the current user password or a new one -- will have no effect.

SSH

By default, Ansible will attempt to install the private SSH key for the user. The key should be available at the path specified in the ssh.user_key variable. Removing this variable will cause the key installation task to be skipped.

SSHD

If ssh.enable_sshd is set to True the systemd socket service will be enabled. By default, sshd is configured but not enabled.

Dotfiles

Ansible expects that the user wishes to clone dotfiles via the git repository specified via the dotfiles.url variable and install them with rcm. If this is not the case, removing the dotfiles variable will cause the relevant tasks to be skipped.

Tagging

All tasks are tagged with their role, allowing them to be skipped by tag in addition to modifying playbook.yml.

AUR

All tasks involving the AUR are tagged aur. To provision an AUR-free system, pass this tag to ansible's --skip-tag.

AUR packages are installed via the ansible-aur module. Note that while aura, an AUR helper, is installed by default, it will not be used during any of the provisioning.

Tarsnap

Tarsnap is installed with its default configuration file. However, setting up Tarsnap is left as an exercise for the user. New Tarsnap users should register their machine and generate a key. Existing users should recover their key(s) and cache directory from their backups (or, alternatively, recover their key(s) and rebuild the cache directory with tarsnap --fsck).

Tarsnapper is installed to manage backups. A basic configuration file to backup /etc is included. Tarsnapper is configured to look in /usr/local/etc/tarsnapper.d for additional jobs. As with with the Tarsnap key and cache directory, users should recover their jobs files from backups after the Tarsnapper install is complete. See the Tarsnapper documentation for more details.

Scheduling Tarsnap

A systemd unit file and timer are included for Tarsnapper. The timer is set to execute Tarsnapper hourly (configurable through the tarsnapper.timer.schedule variable).

Adding custom pacman repositories

Take a look in the haskell roles for examples on adding custom repositories that need signed keys