Personal Salt Setup Documentation Release 0 Kyle Isom Apr 10, 2017 Contents 1 Background and Motivation 3 2 Introduction 5 2.1 Current machines.............................................5 3 The states 7 3.1 Custom modules.............................................8 4 State: devel 9 4.1 State: devel.go..............................................9 4.2 State: devel.rust.............................................9 4.3 State: devel.haskell............................................ 10 4.4 State: devel.python............................................ 10 4.5 State: devel.hashicorp.......................................... 10 4.6 State: devel.apt.............................................. 10 4.7 State: devel.quicklisp........................................... 10 5 State: docker 11 6 State: iptables 13 7 State: keys 15 8 State: laptop 17 8.1 State: laptop.logind............................................ 17 8.2 State: laptop.keyboard.......................................... 18 8.3 State: laptop.mail............................................. 18 8.4 State: laptop.network........................................... 18 8.5 State: laptop.redshift........................................... 18 8.6 State: laptop.xorg............................................ 18 9 State: packages 19 9.1 State: packages.apparmor........................................ 19 9.2 State: packages.audio.......................................... 19 9.3 State: packages.chrome......................................... 19 9.4 State: packages.common......................................... 19 9.5 State: packages.devel........................................... 19 9.6 State: packages.dropbox......................................... 20 i 9.7 State: packages.embedded........................................ 20 9.8 State: packages.laptop.......................................... 20 9.9 State: packages.repo........................................... 20 9.10 State: packages.spotify.......................................... 20 9.11 State: packages.stumpwm........................................ 20 9.12 State: packages.xorg........................................... 20 10 State: ssh 21 11 State: sync 23 11.1 State: sync.dropbox........................................... 23 11.2 State: sync.syncthing........................................... 23 12 State: systemd 25 13 State: usbarmoury 27 14 State: users 29 14.1 State: users.kyle............................................. 29 14.2 State: users.ubuntu............................................ 29 15 Packages 31 15.1 Package list................................................ 31 15.2 Directly downloaded........................................... 37 16 Documentation Overview 39 17 Indices and tables 41 ii Personal Salt Setup Documentation, Release 0 Contents: Contents 1 Personal Salt Setup Documentation, Release 0 2 Contents CHAPTER 1 Background and Motivation This project was motivated by getting a new T460s at work to replace the previous T440s. I’ve had to set up this machine from scratch a few times: 1. When I first got it (May 2014ish) 2. When a work tool hosed my system (July 2014ish) 3. When I switched from Ubuntu 14.04 to Debian Jessie (after seeing xscreensaver segfault and having a lot of problems with Ubuntu) The first install wasn’t so bad, because I didn’t have much to deal with. The other two were multi-day ordeals, mostly because I kept forgetting what needed to be done to set up the laptop; several times I had to deep dive into browser history, or dig through pinboard links, or otherwise try to recreate search history to figure a few things out. Also, the bump from Debian Jessie to Debian Testing (to get a grsec kernel) took a day of handholding. When I got the T460s, I’d wanted to find a way to have a fairly specific, light core system (c.f. this README). This effort took entirely too long and didn’t pan out, so I caved in and went with an Ubuntu Xenial install. However, to prevent losing several days worth of time to setting up a new laptop, I started working on a bootstrap project. The bootstrap process is this: 1. Install a new copy of Ubuntu server and reboot into the new installation. • This will set up the user and disk encryption, and is a fairly easy to acquire install media, unlike the case where I have a custom distribution. 2. Insert the bootstrap media (currently a LUKS-encrypted SD card). 3. Unpack a bare-minimum backup tarball to $HOME. • This backup is the absolute minimum needed by Salt and to start being productive before the full backup is done. For example, on the work machine, this is my work SSH key, VPN key, and the repos I work on actively or need for work (such as a Vagrant setup). 4. Go to the salt directory (which is a copy of this repo) and run the bootstrap script. A highstate can take 30-90 minutes, depending on network speeds. 5. Restore the full backup. 3 Personal Salt Setup Documentation, Release 0 While using Salt is a time saver (it’s automated work that I don’t have to do), the biggest benefit for me is that it gets my laptop into a known state. When I make changes, I effect them with Salt: I’ll edit/write the relevant state, apply the state, then run a high state. There’s a git history too, which provides some background on how my laptop setup has changed. I’d also argue it’s more useful the less often you set up a new machine, as you don’t have to dig deep into your memory or notes to get it right. The idea is that if I make a change to my laptop, and then end up doing a reinstall, that change should live on. 4 Chapter 1. Background and Motivation CHAPTER 2 Introduction The state selection is decided entirely on the roles list grain in the minion config. For example, ~ [2016-08-10T09:30:05 PDT] (0) <straka:kyle> $ sudo salt-call --local grains.get roles [sudo] password for kyle: [INFO ] Determining pillar cache local: - laptop - container - cloudflare - devel The roles that are used right now are: • container: machines that should have Docker installed. • devel: machines that are used for software development. • cloudflare: machines that are used at work. • headless: machine is a VM. This also assumes that this is occurring on a laptop or other single-user machine, as it sets up certain services to run as me. For a list of all the specific places this is done, ag kyle (or grep -HRn kyle *). Current machines • straka: work ThinkPad T460s • madison: home ThinkPad X220 • snotra: development and systems management VM 5 Personal Salt Setup Documentation, Release 0 6 Chapter 2. Introduction CHAPTER 3 The states At a glance, the states are currently organised under the following top-level states: • devel • docker • iptables • keys • laptop • packages • ssh • sync • systemd • usbarmoury • users For a work laptop, the states generally work something like: • set up my user (and make sure there’s no default ubuntu user, e.g. for VMs / Vagrant images) • install common packages • set up the firewall • configure some laptop-specific things • set up the SSH server • set up development environment • set up docker • install whatever tools I need for work that aren’t covered above 7 Personal Salt Setup Documentation, Release 0 My home laptop follows up through the last step; and a headless install is generally the same as either of those (depending on whether it’s being used in a work or home role) minus some things. Custom modules debremote debremote is a custom Salt state module that I wrote. It allows for remotely fetching a .deb file and comparing it against a SHA-256 digest (the pkg.installed source-install will let you install from a .deb, but it won’t let you check it against a digest). It will install the package only if it isn’t present or the remote version is greater than the installed version. Hashicorp doesn’t have an apt repo, but Vagrant is provided as a deb file: vagrant: debremote.installed: - name: vagrant - version: {{ salt['pillar.get']('devel:hashicorp:vagrant:version') }} - digest: {{ salt['pillar.get']('devel:hashicorp:vagrant:hash') }} - source: {{ salt['pillar.get']('devel:hashicorp:vagrant:source') }} 8 Chapter 3. The states CHAPTER 4 State: devel The devel state is broken down into a number of sub-states: • packages.devel will install a set of packages that are useful in my development environment. This state is documented in the packages state docs. • devel.go sets up a Go environment. • devel.rust sets up a Rust toolchain. • devel.haskell sets up a Go environment. • devel.python sets up a Go environment. • packages.embedded installs embedded development tools; this is deselected for machines with the cloudflare role, unfortunately. • devel.hashicorp installs some Hashicorp tools. • devel.apt installs • devel.quicklisp sets up a Go environment. State: devel.go This is a fairly simple state; it just ensures the go package is installed. However, it will pull this package from my personal package repo, because the upstream repos are usually out of date. To do this, I use godeb to create a package. Commented out, but retained in the state file in the event that the godeb route becomes untenable in the future, is an alternate method that downloads directly from Google. State: devel.rust If $HOME/.multirust doesn’t exist, this will call the rustup shell script. The entirety of the security from this relies on the TLS cert, but c’est la vie. I’d like to find a better way to do this, but I don’t have one yet. 9 Personal Salt Setup Documentation, Release 0 The state will also make sure that I (e.g. not root) own the multirust directory. State: devel.haskell The FPComplete