Managing OpenBSD installed packages declaratively
dataswamp.org
dataswamp.org
OP just re-invented that wheel.
One gotcha of Ansible is that removing a package from a playbook does not remove it from Ansible managed systems. You need to either manually remove the package or add another play that removes the package. The OP's tool does not have this limitation.
What I mean is that It's not an impossible goal with Ansible. Not even a tough one.
Not trying to discourage innovation and enthusiasm. I just want my router setup.
It feels very inconsistent to me. You can always start from a minimalist system image and then add a few packages you need using Ansible. Is that really that different?
If you're going to the effort to define the list of packages you want installed on a machine then go with something like Ansible, Chef or Puppet that gives you the tools to do it correctly.
The point is to only maintain the list of packages via this list.
If you're going to the effort to define the list of packages you want installed on a machine then go with something like Ansible, Chef or Puppet that gives you the tools to do it correctly.
What exactly is the difference between a list of packages expressed like this and a list of packages expressed in puppet's syntax?
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).
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.
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 :)
This doesn’t require a puppet install to work, and is ~100 lines of perl which would easily fit into the pkg infrastructure on OpenBSD if it gets adoption?
In that case, all it takes is a moment of distraction.