5 ms·

Managing OpenBSD installed packages declaratively

61 points by zdw 5y ago

scrapheap 5y ago
This looks to me like a script that will shoot you in the foot at some point by removing a package that you've forgotten to put in the configuration 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.
- thwarted 5y ago
  shoot you in the foot at some point by removing a package that you've forgotten to put in the configuration list. 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?
  - scrapheap 5y ago
    > 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 5y 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 5y 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 5y ago
        OpenBSD is not Linux. You can purge all the packages and everything will be fine.
  - apgwoz 5y ago
    > What exactly is the difference between a list of packages expressed like this and a list of packages expressed in puppet's syntax? 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?
- jchw 5y ago
  If you are going to manage packages declaratively, you should do so always. It should only flow one way. That having been said… this can be solved just by showing what changes will be made before making them.
  - danuker 5y ago
    > solved just by showing what changes will be made In that case, all it takes is a moment of distraction.
    - jchw 5y ago
      Well, no kidding, but at that point we’re just getting damn silly. I can also make an Ansible playbook that hoses my machine, too. That’s just how doing things that can potentially hose your machine (certainly reconciling system configurations) works…
INTPenis 5y ago
It's funny but I was just going to setup my new OpenBSD router and obviously I'm using Ansible where I can declaratively define what packages to install, what configuration files to setup and so forth. OP just re-invented that wheel.
- kiwijamo 5y ago
  The difference is that Ansible just installs the package you ask for in addition to other packages which may have been installed by a previous play or by other means, whereas the OP has developed a tool that ensures only the specific packages you ask for (and its dependencies) are installed. 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.
  - scrapheap 5y ago
    You can create an Ansible play that will make sure that only a fixed set of packages are installed. You can even make it pull that list of packages and their versions from another machine (actually very useful for making sure that your production servers aren't running newer packages than your dev/test environments).
  - szszrk 5y ago
    Well, you just change state to absent and it will be uninstalled. You don't need two tasks for that. It's one task that describes state of a package. That state can be a number of things. You don't even need to create a task for each package, you can easily make a loop over a predefined key:value list with statuses of packages you want/don't want. What I mean is that It's not an impossible goal with Ansible. Not even a tough one.
    - oddlama 5y ago
      Neither impossible nor tough, but also not a clean way of managing state. You need to keep track of all past things you once did but no longer need.

61 points by zdw 5y ago

This looks to me like a script that will shoot you in the foot at some point by removing a package that you've forgotten to put in the configuration 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.

thwarted 5y ago
shoot you in the foot at some point by removing a package that you've forgotten to put in the configuration list. 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?
- scrapheap 5y ago
  > 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 5y 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 5y 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 5y ago
        OpenBSD is not Linux. You can purge all the packages and everything will be fine.
- apgwoz 5y ago
  > What exactly is the difference between a list of packages expressed like this and a list of packages expressed in puppet's syntax? 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?
jchw 5y ago
If you are going to manage packages declaratively, you should do so always. It should only flow one way. That having been said… this can be solved just by showing what changes will be made before making them.
- danuker 5y ago
  > solved just by showing what changes will be made In that case, all it takes is a moment of distraction.
  - jchw 5y ago
    Well, no kidding, but at that point we’re just getting damn silly. I can also make an Ansible playbook that hoses my machine, too. That’s just how doing things that can potentially hose your machine (certainly reconciling system configurations) works…

INTPenis 5y ago

It's funny but I was just going to setup my new OpenBSD router and obviously I'm using Ansible where I can declaratively define what packages to install, what configuration files to setup and so forth. OP just re-invented that wheel.

kiwijamo 5y ago
The difference is that Ansible just installs the package you ask for in addition to other packages which may have been installed by a previous play or by other means, whereas the OP has developed a tool that ensures only the specific packages you ask for (and its dependencies) are installed. 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.
- scrapheap 5y ago
  You can create an Ansible play that will make sure that only a fixed set of packages are installed. You can even make it pull that list of packages and their versions from another machine (actually very useful for making sure that your production servers aren't running newer packages than your dev/test environments).
- szszrk 5y ago
  Well, you just change state to absent and it will be uninstalled. You don't need two tasks for that. It's one task that describes state of a package. That state can be a number of things. You don't even need to create a task for each package, you can easily make a loop over a predefined key:value list with statuses of packages you want/don't want. What I mean is that It's not an impossible goal with Ansible. Not even a tough one.
  - oddlama 5y ago
    Neither impossible nor tough, but also not a clean way of managing state. You need to keep track of all past things you once did but no longer need.