Human readable automation instructions designed to predictably manage the configuration of macOS and Linux systems
Although the vast majority of the tasks normally associated with setting up a new system have been automated, there are still a few steps that require manual procedures after the Ansible run.
First, make sure you have all those things installed:
- git: to clone the repo
- curl: to download files
Then, run these steps:
$ git clone https://github.com/frankhinek/automaton ~/.automaton
$ cd ~/.automaton
$ git submodule update --init --recursive
$ ./run
To update, you just need to git pull
and run the bootstrap script again:
$ cd ~/.automaton
$ git pull origin master
$ ./run
Automaton includes support for using PGP keys to sign git commits. If you wish to sign your commits, then follow the steps below.
Start by ensuring that enable_git_signing
is set to true
in the all
group variables.
Next, generate new git_signing_key
variable values for the personal
and
work
group variables. Use the following command to create a new encrypted string with Ansible vault:
$ ./gen-secret git_signing_key
When prompted, enter and confirm a vault password:
New vault password (default):
Confirm new vault password (default):
Type the value you wish to encrypt followed by pressing Ctrl+D twice:
Reading plaintext input from stdin. (ctrl-d to end input, twice if your content does not already have a newline)
Save the value after Encryption successful
to the appropriate group_vars
YAML file.
For daily use, especially on a mobile device such as a MacBook or Linux laptop, a strong security measure is to remove the master secret key from the keyring. You will often hear people refer to this as a laptop keyring. You can then use the signing subkey to sign git commits, etc. There are multiple ways to accomplish this. Two options are detailed below.
- Import your public and private key pair to the new machine:
$ gpg --import my_gpg_private_key.asc
$ gpg --import my_gpg_public_key.asc
- Ensure that the Key ID printed is the correct one, and if so, then go ahead and add ultimate trust for it:
$ gpg --edit-key <KEY_ID>
...
Command>
- At the
Command>
prompt, type intrust
. - You will be prompted to decide how far to trust this key. Since, presumably, this is your key that you have verified you would enter
5
and answery
to confirm. - Export the secret subkeys to file:
$ gpg --export-secret-subkeys --armor --output secret-subkeys.asc <KEY_ID>
- Delete all the secret keys of your key from the keyring. This includes the master key and all subkeys.
$ gpg --delete-secret-keys <KEY_ID>
- Version 2 of GnuPG will prompt you to confirm the deletion of the secret key
of the master key and each subkey. You should respond
y
when prompted to delete the secret key and then confirm by enteringy
again. - When prompted to delete the first subkey, enter
n
. This will result in an error message which indicates that the secret master key was deleted, but the subkeys were not deleted.
- From a trusted machine that already contains your key in its keyring, export only the subkeys:
$ gpg --export-secret-subkeys --armor --output secret-subkeys.asc <KEY_ID>
- Export the public keys:
$ gpg --export --armor --output public-keys.asc <KEY_ID>
- Import the public keys into the keyring:
$ gpg --import public-keys.asc
- Import the secret subkeys, without the master secret key, into the daily use keyring:
$ gpg --import secret-subkeys.asc
Regardless of which approach you took, the output from the gpg -K
command
should display the master key with a hash character (e.g., sec#
) indicating
that the secret master key is missing as we intended.
- Create a custom Homebrew formula to install the Automounter Helper.
Rather than forking an existing Ansible macOS or Linux setup repository I started from a blank canvas and added only what I needed. However, nearly every bit of this was copied directly from or heavily based on work by the individuals listed below. Thanks to all that shared their code!