Ask HN: Configuration Management for Personal Computer?

I don't do any orchestration either; I just have metapackages that do roughly the same thing, as well as a few packages that install system-wide configuration.

Ansible is worth the extra few minutes, IMHO.

+ (minimal) Bootstrap System playbook

+ Complete System playbook (that references group_vars and host_vars)

+ Per-machine playbooks stored alongside the ansible inventory, group_vars, and host_vars in a separate repo (for machine-specific kernel modules and e.g. touchpad config)

+ User playbook that calls my bootstrap dotfiles shell script

+ Bootstrap dotfiles shell script, which creates symlinks and optionally installs virtualenv+virtualenvwrapper, gitflow and hubflow, and some things with pipsi. https://github.com/westurner/dotfiles/blob/develop/scripts/b...

+ setup_miniconda.sh that creates a CONDA_ROOT and CONDA_ENVS_PATH for each version of CPython (currently py27-py37)

Over the years, I've worked with Bash, Fabric, Puppet, SaltStack, and now Ansible + Bash

I log shell commands with a script called usrlog.sh that creates a $USER and per-virtualenv tab-delimited logfiles with unique per-terminal-session identifiers and ISO8601 timestamps; so it's really easy to just grep for the apt/yum/dnf commands that I ran ad-hoc when I should've just taken a second to create an Ansible role with `ansible-galaxy init ansible-role-name ` and referenced that in a consolidated system playbook with a `when` clause. https://westurner.github.io/dotfiles/usrlog.html#usrlog

A couple weeks ago I added an old i386 netbook to my master Ansible inventory and system playbook and VScode wouldn't install because VScode Linux is x86-64 only and the machine doesn't have enough RAM; so I created when clauses to exclude VScode and extensions on that box (with host_vars). Gvim with my dotvim works great there too though. Someday I'll merge my dotvim with SpaceVim and give SpaceMacs a try; `git clone; make install` works great, but vim-enhanced/vim-full needs to be installed with the system package manager first so that the vimscript plugin installer works and so that the vim binary gets updated when I update all.

I've tested plenty of Ansible server configs with molecule (in docker containers), but haven't yet taken the time to do a full workstation build with e.g. KVM or VirtualBox or write tests with testinfra. It should be easy enough to just run Ansible as a provisioner in a Vagrantfile or a Packer JSON config. VirtualBox supports multi-monitor VMs and makes USB passthrough easy, but lately Docker is enough for everything but Windows (with a PowerShell script that installs NuGet packages with chocolatey) and MacOS (with a few setup scripts that download and install .dmg's and brew) VMs. Someday I'll write or adapt Ansible roles for Windows and Mac, too.

I still configure browser profiles by hand; but it's pretty easy because I just saved all the links in my tools doc: https://westurner.github.io/tools/#browser-extensions

Someday, I'll do bookmarks sync correctly with e.g. Chromium and Firefox; which'll require extending westurner/pbm to support Firefox SQLite or a rewrite in JS with the WebExtension bookmarks API.

A few times, I've decided to write docs for my dotfiles and configuration management policies like someone else is actually going to use them; it seemed like a good exercise at the time, but invariably I have to figure out what the ultimate command sequence was and put that in a shell script (or a Makefile, which adds a dependency on GNU make that's often worth it)

Clonezilla is great and free, but things get out of date fast in a golden master image. It's actually possible to PXE boot clonezilla with Cobbler, but, AFAICT, there's no good way to secure e.g. per-machine disk or other config with PXE. Apt-cacher-ng can proxy-cache-mirror yum repos, too. Pulp requires a bit of RAM but looks like a solid package caching system. I haven't yet tested how well Squid works as a package cache when all of the machines are simultaneously downloading the exact same packages before a canary system (e.g. in a VM) has populated the package cache.

I'm still learning to do as much as possible with Docker containers and Dockerfiles or REES (Reproducible Execution Environment Specifications) -compatible dependency configs that work with e.g. repo2docker and https://mybinder.org/ (BinderHub)

During my master's we had assigned desks and mandatory presence 4.9 days a week. Desks would switch about four times a year using a verifiably random scheme, and in addition, there would be projects that we would work on with random people, so we switched desks a lot. Each desk comes with a proper 2-screen desktop setup, so pulling out your laptop was inferior. Via PXE boot, people would regularly reinstall their system for various reasons, so it would regularly be a fresh Ubuntu install. An additional requirement was that others must still be able to work on my system without (m)any quirks.

Only a few of us used any sort of automation. Most that did chose Ansible, and all I ever heard from them was cursing on new systems and, between homework, constantly tweaking the deployment script. I'm sure the comments will say Ansible works reliably and painlessly for them, but from what I've seen, it seems to take some time to get into it if you want to setup GUI systems in detail.

What worked extremely well for me was a shell script that I grabbed from my server (wget example.com/setup.sh), ran, switched user account, ran step 2 (since it mounts the user's homedir, you don't want to do that while logged in), and then logged back into my real account. After less than 5 minutes of manual work, I had my desired software, the right desktop environment, task bar / alt tab / system tray / clock / etc. settings, and I mounted my homedir on a local server, which was fast enough to painlessly run virtual machines with GUI OSes off of it. I would be as productive and comfortable as on my private laptop after a few minutes of work in the worst case. The script took a few hours to create at first, and with a new Ubuntu release maybe another hour to make it work on the mix of old and new systems. The advantage over other people's setups was that anyone could wipe my system without a second thought (usually you'd have to ask the desk's owner, they'd want to copy files...) and others couldn't snoop through my files (at least, not opportunistically: they'd have to purposefully install a keylogger rather than just "sudo; ls /home/lucb1e") so I can jot down thoughts or save passwords in Thunderbird without worrying.

In a more common scenario (not shared systems that are regularly wiped), you'd leave out the mounting of the homedir and copy essential files instead, such as your bashrc/vimrc. Using a simple shell script is something I still recommend to manage setting up personal systems. It's what you would do anyway, except stored in a file instead of typing the commands manually. So that's what I still use today, though I don't switch systems often enough to warrant maintaining commands for GUI configuration preferences (which can be a pain to figure out how to set from the command line). My current setup script is included in my bashrc (which I copy together with a .vimrc) and mainly pulls packages. I specify which categories I want, e.g. if the system has WiFi it'll install wavemon, or if the system has a GUI it'll install wireshark and xdotool.

Probably overkill, but I'm pretty happy with how my dotfiles are managed now. I commit everything to my dotfiles repository and use chef to install things and manage dependencies. It's easy to support another OS by adding a cookbook and recipes.

https://github.com/callahanrts/dotfiles

Definitely - I've been doing this for about five years with all my machines. A rough overview of the setup:

- A public repository with a Nix configuration file: https://gitlab.com/victor-engmark/root. This does the global setup, installing applications, configuring global services, enabling hardware, etc, and gets me 90% of the way to identical machines with a single `nixos-rebuild switch`.

- A public repository with dotfiles and main application configuration: https://gitlab.com/victor-engmark/tilde. Allows me to configure user applications once for all my machines.

- A private repository with secrets such as SSH keys and host-specific configuration like video drivers, screen layout etc.

This makes it possible to get from a fresh OS install to a developer workstation with everything from keyboard layout to my favourite window manager configured as I like it within minutes.

I consider learning configuration management a nice bonus of this setup, but of course that is not for everyone.

The biggest problem with this is how many programs seem to go out of their way to make their configuration hard to version control. Firefox moved to SQLite for everything years ago, but at least there's the Sync service. Some applications reorder configuration items every time they save (I've built scripts to order them properly). And others include things which IMO don't belong in "user" configuration files such as window size, recently opened files and which configuration tab was last open.

PS: I recently moved to Nix on NixOS from Puppet (similar features to Ansible and Chef) on Arch Linux for the system configuration. Nix has several massive advantages over at least Puppet and Ansible, both of which I've used a fair bit:

- Much shorter configuration. For example, `services.fail2ban.enable = true;` is enough to install, enable and start a fail2ban service when building the configuration, and `time.timeZone = "Pacific/Auckland";` means I don't have to even think about where that piece of configuration is stored, or in which of the infinite formats used for Linux configuration.

- Trivial rollback to earlier configurations, during runtime or at the boot menu. This saved my backside when I screwed up a GRUB-related setting - just reboot and select the previous configuration.

- You can install applications as a non-root user to try them out.

- I've been using Nix for less than a month, but it's far easier to just get stuff done with it than with Puppet or Ansible, and the end results so far are just generally nicer.

So if you want a simple system configuration you can copy around to configure everything the same way I would thoroughly recommend NixOS.