4 ms·

IMHO they really need a two-step release process for changes to pf.conf syntax. In the first step you get a warning when running the service about a deprecated

IMHO they really need a two-step release process for changes to pf.conf syntax. In the first step you get a warning when running the service about a deprecated syntax, then drop it. Over the last 20 years I’ve been bitten multiple times by changes to pf.conf which not only breaks your firewall, but invalidates entire published books on pf, countless articles, tutorials, etc. I read some quote from the BDFL once where he said something about breaking changes being good because you’re “in a better place” but I feel the BC breaks are too aggressive to rely on pf directly in anything but small commercial applications. If you want to to tinker and break your home network fine.

petee 3y ago
This is why the upgrade guide says to actually read the changelog; they tell you the changes. I've only been bitten once, and it was because I didn't read first. >> Read through and understand this process before attempting it. For critical or physically remote machines, test it on an identical, local system first. >> Read configuration and syntax changes and the package upgrade instructions. There were several configuration changes and changes in packages that may require planning before starting the upgrade.
- tiffanyh 3y ago
  Typically you don't have breaking changes for a point release.
  - accrual 3y ago
    For OpenBSD at least, every release has equal weight and always increments by 0.1. There isn't a distinction between major and minor releases like other projects have. There are patches/errata, but those don't bump the version.
  - petee 3y ago
    Theres a reason they call it an system upgrade, and not a patch or update. Blindly upgrading anything important without rtfm is just plain irresponsible, yet OP has used openbsd for 20 years and keeps making the same mistake over and over; typically you don't do that.
bombcar 3y ago
The best way I've seen is to have the upgrade itself migrate the config, when at all possible. Sometimes it can't be done, because the changes are entirely orthogonal, but trying your best is quite helpful. Or you just do like Linux apparently seems to do and introduce a new software firewall every few years :D

petee 3y ago

This is why the upgrade guide says to actually read the changelog; they tell you the changes. I've only been bitten once, and it was because I didn't read first. >> Read through and understand this process before attempting it. For critical or physically remote machines, test it on an identical, local system first. >> Read configuration and syntax changes and the package upgrade instructions. There were several configuration changes and changes in packages that may require planning before starting the upgrade.

tiffanyh 3y ago
Typically you don't have breaking changes for a point release.
- accrual 3y ago
  For OpenBSD at least, every release has equal weight and always increments by 0.1. There isn't a distinction between major and minor releases like other projects have. There are patches/errata, but those don't bump the version.
- petee 3y ago
  Theres a reason they call it an system upgrade, and not a patch or update. Blindly upgrading anything important without rtfm is just plain irresponsible, yet OP has used openbsd for 20 years and keeps making the same mistake over and over; typically you don't do that.

bombcar 3y ago

The best way I've seen is to have the upgrade itself migrate the config, when at all possible. Sometimes it can't be done, because the changes are entirely orthogonal, but trying your best is quite helpful. Or you just do like Linux apparently seems to do and introduce a new software firewall every few years :D