3 ms·

I think overall its a mistake to try to over automate this process. It's brittle and the requirements are simply not the same as a server environment that needs

I think overall its a mistake to try to over automate this process. It's brittle and the requirements are simply not the same as a server environment that needs to be simple to replicate X versions quickly, repeatedly and frequently. Automation needs fairly constant attention in the order of little tweaks week over week to fight the inevitable mismatch between the automation and the software networks that it interfaces with. Do you reinstall your workstation once a week? Unlikely and probably would be an unproductive use of your time. The way I approach it instead - The first thing I do is list everything I need for a workstation in an orgmode text file. For why orgmode really works well for this - http://howardism.org/Technical/Emacs/literate-devops.html http://howardism.org/Technical/Emacs/literate-devops.html I aim to make a "computational document" that I can execute a bit at a time as I review/check each piece on installs and upgrades of the system. To me it's really critical that there are links to the webpages and text notes about these configurations alongside the code I'm using. I check this and the needed config files into a single git repository. As the workstations (I use the same document for workstation,laptop, studiopc, homeserver, android) age I'm inevitably adding and upgrading bits of the git repository. I make sure that I work from the orgmode document whenever I touch any configuration. I use Linux and Emacs (which means a big part of my software environment is in a git controlled .emacs.d) so the entire environment supports this workflow.

JoshTriplett 7y ago
> I think overall its a mistake to try to over automate this process. It's brittle and the requirements are simply not the same as a server environment that needs to be simple to replicate X versions quickly, repeatedly and frequently. > Do you reinstall your workstation once a week? Unlikely and probably would be an unproductive use of your time. It's not about how often I reinstall. It's about how many machines I work on. I have a personal laptop, a work laptop, a work build server, a personal cloud server, and accounts on various systems. I want all of those to have mostly the same packages, with some variations (such as no GUI on the servers, and SSH on the servers). (In my case, I ended up with a simple set of Debian metapackages that between them depend on 99% of what I need, in addition to the usual git homedir.)
- lucb1e 7y ago
  If you regularly pull up new systems (also VMs), it indeed becomes worth it to do some form of automation. For me, instead of having a whole orchestration setpu, I just have a simple .bashrc that I copy everywhere and it has a few package lists in the form of functions: - Running `defaultinstall` will install vim, git, iotop, progress, curl, and other essentials, and it runs apt-file update. - Running `defaultinstalloptional` will pull more packages like sipcalc, cloc, woof, and other packages that I like but are not something I use on every system or do not use regularly. - Running `defaultinstallwifi` pulls wavemon, iw, and wireless-tools; `defaultinstallprogramming` gets me interpreters and compilers that I regularly use; `defaultinstallgui` gets me GUIs that I use (audacity, gimp, wireshark, xdotool, xclip, etc.); etc. On a new system I run whichever ones are applicable (e.g. a desktop may be GUI but not WiFi). Together with copying .bashrc, .vim/, and .vimrc, that's 90% of the setup I need for a non-GUI system. On a GUI system, I will want to set some task bar preferences. Only replacing my main system is an exception: I'll simply copy my filesystem from the old system (or, more often, physically move over the SSD), since I'll want to have the files, firefox profile, thunderbird config, etc. anyway. Takes nearly zero time to maintain and is not dependent on anything that I don't already consider essential (Debian won't ship without bash-compatible shell or a package manager for a long time) so there is only one manual pre-setup step: copying a text file.
  - JoshTriplett 7y ago
    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.
StavrosK 7y ago
I entirely disagree with it, because I do do this and it works beautifully. I even wrote an article on how: https://www.stavros.io/posts/provisioning-your-computer-one-command-awesome/ https://www.stavros.io/posts/provisioning-your-computer-one-... Just write whatever change you want to make into your Ansible file, and run the provisioning command, instead of making the change directly. Done.
wwwigham 7y ago
I had a period where I _did_ reimage my machine every week. Keeping it running productively wasn't that bad - data was kept on a separate drive from the OS, and a script was used (as a post-reimage step) to reinstall all the apps I used and link all the data folders (and config files and profiles) into place. For me for Windows, that meant having a powershell script that used a combination of chocolatey (to install what was available via package manager in that way) and saved installers run from the command line in quiet mode (plus a bunch of link commands). The only real drain is that you need to remember when you install a new app that you need to add it to your script. Beyond that, simply keeping most non-application data on a drive that didn't get reimaged with the OS (and could store things that could be linked into the system drive) handled a lot.

JoshTriplett 7y ago

> I think overall its a mistake to try to over automate this process. It's brittle and the requirements are simply not the same as a server environment that needs to be simple to replicate X versions quickly, repeatedly and frequently. > Do you reinstall your workstation once a week? Unlikely and probably would be an unproductive use of your time. It's not about how often I reinstall. It's about how many machines I work on. I have a personal laptop, a work laptop, a work build server, a personal cloud server, and accounts on various systems. I want all of those to have mostly the same packages, with some variations (such as no GUI on the servers, and SSH on the servers). (In my case, I ended up with a simple set of Debian metapackages that between them depend on 99% of what I need, in addition to the usual git homedir.)

lucb1e 7y ago
If you regularly pull up new systems (also VMs), it indeed becomes worth it to do some form of automation. For me, instead of having a whole orchestration setpu, I just have a simple .bashrc that I copy everywhere and it has a few package lists in the form of functions: - Running `defaultinstall` will install vim, git, iotop, progress, curl, and other essentials, and it runs apt-file update. - Running `defaultinstalloptional` will pull more packages like sipcalc, cloc, woof, and other packages that I like but are not something I use on every system or do not use regularly. - Running `defaultinstallwifi` pulls wavemon, iw, and wireless-tools; `defaultinstallprogramming` gets me interpreters and compilers that I regularly use; `defaultinstallgui` gets me GUIs that I use (audacity, gimp, wireshark, xdotool, xclip, etc.); etc. On a new system I run whichever ones are applicable (e.g. a desktop may be GUI but not WiFi). Together with copying .bashrc, .vim/, and .vimrc, that's 90% of the setup I need for a non-GUI system. On a GUI system, I will want to set some task bar preferences. Only replacing my main system is an exception: I'll simply copy my filesystem from the old system (or, more often, physically move over the SSD), since I'll want to have the files, firefox profile, thunderbird config, etc. anyway. Takes nearly zero time to maintain and is not dependent on anything that I don't already consider essential (Debian won't ship without bash-compatible shell or a package manager for a long time) so there is only one manual pre-setup step: copying a text file.
- JoshTriplett 7y ago
  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.

StavrosK 7y ago

I entirely disagree with it, because I do do this and it works beautifully. I even wrote an article on how: https://www.stavros.io/posts/provisioning-your-computer-one-command-awesome/ https://www.stavros.io/posts/provisioning-your-computer-one-... Just write whatever change you want to make into your Ansible file, and run the provisioning command, instead of making the change directly. Done.

wwwigham 7y ago

I had a period where I _did_ reimage my machine every week. Keeping it running productively wasn't that bad - data was kept on a separate drive from the OS, and a script was used (as a post-reimage step) to reinstall all the apps I used and link all the data folders (and config files and profiles) into place. For me for Windows, that meant having a powershell script that used a combination of chocolatey (to install what was available via package manager in that way) and saved installers run from the command line in quiet mode (plus a bunch of link commands). The only real drain is that you need to remember when you install a new app that you need to add it to your script. Beyond that, simply keeping most non-application data on a drive that didn't get reimaged with the OS (and could store things that could be linked into the system drive) handled a lot.