3 ms·

> The point is to only maintain the list of packages via this list. Except you'll find that if you have more than one person looking after the machine, someone

> The point is to only maintain the list of packages via this list. Except you'll find that if you have more than one person looking after the machine, someone will install a package directly and it'll get removed by the next person to run the script. If your using something like Ansible, Chef or Puppet then you can do things to make it harder for people to make changes to your machines outside of your configuration management. > What exactly is the difference between a list of packages expressed like this and a list of packages expressed in puppet's syntax? The big important differences aren't the list of packages, it's the additional tools around the list of packages that you get. Simply installing a package is trivial, setting up your configuration for those packages you've installed is the real issue that you need to solve - which Ansible, Chef, Puppet, etc solves very well. The script is probably fine if you're the only one using the machine, keep your list of packages up to date and don't change any of your configurations from the defaults (or have a separate process for managing them).

rkangel 4y ago
> Except you'll find that if you have more than one person looking after the machine, someone will install a package directly and it'll get removed by the next person to run the script. This is explicitly the purpose of what is being done here. The state of the machine (or at least "which packages are installed") is described completely by the list. Here is a common problem that you get with Ansible: I go and build a new machine using an Ansible Playbook that has worked perfectly for 6 months. The production code doesn't run. It turns out that's because there is a package missing that is needed. That package was manually installed on the other server by someone to do a debug task, and then somewhere along the line an implicit dependency on it happened. With this approach that isn't possible - you've specified the entire (package) state of the system so it isn't possible for the config of the machine to drift from your code that specifies it. No need to worry your playbook is wrong, no need to do a nightly test of your playbook on a fresh VM.
- scrapheap 4y ago
  Your Ansible problem is hit when you're setting up a new machine and your live production code is still running on your old production machine. You fix your Ansible script to include the missing dependency, run it against the new server again and it's now working. The risk I described, where a package is removed from your current running production machine and stops your code from working, results in an outage. Personally, I'd rather have the Ansible problem than the outage :)
  - anthk 4y ago
    OpenBSD is not Linux. You can purge all the packages and everything will be fine.

rkangel 4y ago

> Except you'll find that if you have more than one person looking after the machine, someone will install a package directly and it'll get removed by the next person to run the script. This is explicitly the purpose of what is being done here. The state of the machine (or at least "which packages are installed") is described completely by the list. Here is a common problem that you get with Ansible: I go and build a new machine using an Ansible Playbook that has worked perfectly for 6 months. The production code doesn't run. It turns out that's because there is a package missing that is needed. That package was manually installed on the other server by someone to do a debug task, and then somewhere along the line an implicit dependency on it happened. With this approach that isn't possible - you've specified the entire (package) state of the system so it isn't possible for the config of the machine to drift from your code that specifies it. No need to worry your playbook is wrong, no need to do a nightly test of your playbook on a fresh VM.

scrapheap 4y ago
Your Ansible problem is hit when you're setting up a new machine and your live production code is still running on your old production machine. You fix your Ansible script to include the missing dependency, run it against the new server again and it's now working. The risk I described, where a package is removed from your current running production machine and stops your code from working, results in an outage. Personally, I'd rather have the Ansible problem than the outage :)
- anthk 4y ago
  OpenBSD is not Linux. You can purge all the packages and everything will be fine.