4 ms·

That sounds really useful. I'm interested in doing something similar with my own machines. Do you have any source code you can share?

sowbug 5y ago
I've thought about making the git repo public, but there are stumbling blocks. First, I started out checking secrets into the repo. Stuff like encrypted ssh private keys. Bad practice, obviously, but at the time I was just learning and didn't think it would grow into something I'd keep so long. I've since removed all the secrets, but they linger in the history. So if I published something, it would have to be a new repo or a shallow clone. That's not such a bad thing because others probably don't care much about my repo's history. Second, I doubt I'm following Ansible best practices, so I'd be doing you a disservice if I held out my repo as a model for organizing your stuff. This matters if you want to import third-party modules (I'm not even sure what they're called), because they seem to expect a certain directory layout. As a result, if I see a cool third-party Ansible feature out there, I can't take it; I pretty much have to rewrite it to fit into my system. Third, there isn't actually much that is both useful and general. Most of my setup copies files into ~, alters /etc files, checks that apt packages are how I want them, and occasionally kicks a service to reload. These functions aren't particularly hard to learn in Ansible, so using my code as an example isn't very useful -- you'd be better off just reading the Ansible docs. All that said, I do have some advice. 1. Start simple. Try specifying your favorite .deb packages in an Ansible playbook. Make that playbook the start of your own repo. Then, like I said in my earlier post, get in the habit of adding new .deb packages into the playbook and installing them by running the playbook, rather than using apt install to modify your package configuration. 2. Re-run your playbook frequently. This will keep you from forgetting how to use Ansible. It will also start acting like a mini BOFH by overwriting the local changes you've made to your system instead of adding them to Ansible like you should have been doing. 3. Once you have the basics down, divide up functionality into "roles" and then compose individual machines ("hosts") out of roles. For example, I have roles named common, desktops, workstations, laptops, me, minecraft_servers, and ssh_servers. Common is stuff every machine should have, like curl, emacs (sorry), git, python3-pip, unzip, and a user named sowbug with certain sudo privileges. Desktops use Cinnamon. Workstations (which could be headless servers) have various developer packages. "me" is all my authorized_keys and other things I like in ~. minecraft_servers was useful because my kids go through MC phases and want a server for a week until they get out of the phase. This way I can set up a server quickly and then delete it a week later, without worrying about paying for an idle disk on AWS for months. 4. Don't use Ansible for copying giant files. Maybe this has improved recently, but it wasn't a good experience. For the few big files I did have for a Quake server I used to run, I ended up keeping the small files in Ansible, and then used get_url to grab the big ones off the web. I do hope you give this a try. Maybe Ansible isn't right for you (I believe Puppet and Chef are still out there; maybe there are others now). Whichever you pick, configuration management for a hobbyist's computers is useful.

sowbug 5y ago

I've thought about making the git repo public, but there are stumbling blocks. First, I started out checking secrets into the repo. Stuff like encrypted ssh private keys. Bad practice, obviously, but at the time I was just learning and didn't think it would grow into something I'd keep so long. I've since removed all the secrets, but they linger in the history. So if I published something, it would have to be a new repo or a shallow clone. That's not such a bad thing because others probably don't care much about my repo's history. Second, I doubt I'm following Ansible best practices, so I'd be doing you a disservice if I held out my repo as a model for organizing your stuff. This matters if you want to import third-party modules (I'm not even sure what they're called), because they seem to expect a certain directory layout. As a result, if I see a cool third-party Ansible feature out there, I can't take it; I pretty much have to rewrite it to fit into my system. Third, there isn't actually much that is both useful and general. Most of my setup copies files into ~, alters /etc files, checks that apt packages are how I want them, and occasionally kicks a service to reload. These functions aren't particularly hard to learn in Ansible, so using my code as an example isn't very useful -- you'd be better off just reading the Ansible docs. All that said, I do have some advice. 1. Start simple. Try specifying your favorite .deb packages in an Ansible playbook. Make that playbook the start of your own repo. Then, like I said in my earlier post, get in the habit of adding new .deb packages into the playbook and installing them by running the playbook, rather than using apt install to modify your package configuration. 2. Re-run your playbook frequently. This will keep you from forgetting how to use Ansible. It will also start acting like a mini BOFH by overwriting the local changes you've made to your system instead of adding them to Ansible like you should have been doing. 3. Once you have the basics down, divide up functionality into "roles" and then compose individual machines ("hosts") out of roles. For example, I have roles named common, desktops, workstations, laptops, me, minecraft_servers, and ssh_servers. Common is stuff every machine should have, like curl, emacs (sorry), git, python3-pip, unzip, and a user named sowbug with certain sudo privileges. Desktops use Cinnamon. Workstations (which could be headless servers) have various developer packages. "me" is all my authorized_keys and other things I like in ~. minecraft_servers was useful because my kids go through MC phases and want a server for a week until they get out of the phase. This way I can set up a server quickly and then delete it a week later, without worrying about paying for an idle disk on AWS for months. 4. Don't use Ansible for copying giant files. Maybe this has improved recently, but it wasn't a good experience. For the few big files I did have for a Quake server I used to run, I ended up keeping the small files in Ansible, and then used get_url to grab the big ones off the web. I do hope you give this a try. Maybe Ansible isn't right for you (I believe Puppet and Chef are still out there; maybe there are others now). Whichever you pick, configuration management for a hobbyist's computers is useful.