A lot of parts borrowed from GitHub - TechDufus/dotfiles: Fully automated development environment for Tech…

This ansible playbook only supports OS’s on a per-role basis. This gives a high level of flexibility to each role.

This means that you can run a role, and it will only run if your current OS is configured for that role.

This is accomplished with this template main.yml task in each role:

---
- name: "{{ role_name }} | Checking for Distribution Config: {{ ansible_distribution }}"
  ansible.builtin.stat:
    path: "{{ role_path }}/tasks/{{ ansible_distribution }}.yml"
  register: distribution_config

- name: "{{ role_name }} | Run Tasks: {{ ansible_distribution }}"
  ansible.builtin.include_tasks: "{{ ansible_distribution }}.yml"
  when: distribution_config.stat.exists

The first task checks for the existence of a roles/<target role>/tasks/<current_distro>.yml file. If that file exists (example current_distro:Archlinux and a Archlinux.yml file exists) it will be run automatically. This keeps roles from breaking if you run a role that isn’t yet supported or configured for the system you are running dotfiles on.

Currently configured ‘bootstrap-able’ OS’s:

• Archlinux

bootstrap-able means the pre-dotfiles setup is configured and performed automatically by this project. For example, before we can run this ansible project, we must first install ansible on each OS type.

To see details, see the __task "Loading Setup for detected OS: $ID" section of the bin/dotfiles script to see how each OS type is being handled.

Verify your supported OS installation has all latest packages installed before running the playbook.

# Arch
sudo pacman -Syu

NOTE: This may take some time…

The all.yml file allows you to personalize your setup to your needs. This file will be created in the file located at ~~/.dotfiles/group_vars/all.yml~ after you install this dotfiles and include your desired settings.

Below is a list of all available values. Not all are required but incorrect values will break the playbook if not properly set.

This project depends on pass https://www.passwordstore.org. This means you must have a pass store already setup.

https://michael.mulqueen.me.uk/2018/02/using-ansible-with-pass-for-secrets/

First you need to install pass. bin/dotfiles will this make for you.

Before you can make a password vault with Pass, you’ll need a GPG key. If you don’t already have one, you can generate one with gpg --generate-key. Bear in mind that if you don’t set a passphrase, you’re not really gaining any protection.

Then you can run pass init "Juan Carlos Coruña" , changing my name to match whatever name you’re using for your GPG key. If you’re not sure, you can run gpg -k to see what name you’ve used.

You can store passwords in pass by running pass insert servers/example.com/postgresql. You can use whatever convention you like for structuring your passwords in pass.

To store a key that is already in a file you can use:

pass insert -m personal/ssh/id_rsa/private_key < ~/.ssh/id_rsa

Passwords can be edited by running pass edit servers/example.com/postgresql

Retrieving a password is as simple as pass show servers/example.com/postgresql

Passwords stored in Pass can be accessed using Ansible’s pipe module.

For example like this from an inventory file:

example.com ansible_become=True ansible_become_pass="{{ lookup('pipe', 'pass show servers/example.com/ssh') }}" ansible_user=ansible

Or like this as a task:

- postgresql_user:
    name: postgres
    password: "{{ lookup('pipe', 'pass show servers/example.com/postgresql') }}"

Pass will need to be unlocked before running the Ansible playbook because otherwise it may try (and fail) to interactively prompt for a password. This is as simple as showing one of the passwords before running Ansible - you could create a dummy password for this purpose if you like and then run pass show dummy. This shouldn’t be a problem if you’re using a GPG implementation that usually prompts with a graphical popup to ask for a passphrase (or PIN for a hardware key).

This playbook includes a custom shell script located at bin/dotfiles. This script is added to your $PATH after installation and can be run multiple times while making sure any Ansible dependencies are installed and updated.

This shell script is also used to initialize your environment after bootstrapping your supported-OS and performing a full system upgrade as mentioned above.

NOTE: You must follow required steps before running this command or things may become unusable until fixed.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/oggers/dotfiles/main/bin/dotfiles)"

If you want to run only a specific role, you can specify the following bash command:

curl -fsSL https://raw.githubusercontent.com/oggers/dotfiles/main/bin/dotfiles | bash -s -- --tags comma,separated,tags

This repository is continuously updated with new features and settings which become available to you when updating.

To update your environment run the dotfiles command in your shell:

dotfiles

This will handle the following tasks:

• Verify Ansible is up-to-date.
• Clone this repository locally to ~~/.dotfiles~
• Verify any ansible-galaxy plugins are updated
• Run this playbook with the values in ~~/.config/dotfiles/group_vars/all.yaml~

This dotfiles command is available to you after the first use of this repo, as it adds this repo’s bin directory to your path, allowing you to call dotfiles from anywhere.

Any flags or arguments you pass to the dotfiles command are passed as-is to the ansible-playbook command.

For example: running the emacs tag with verbosity:

dotfiles -t emacs -vvv

As an added bonus, the tags have tab completion!

dotfiles -t <tab><tab>
dotfiles -t t<tab>
dotfiles -t ne<tab>