OpenBSD, FreeBSD: your update philosophy?
Solution 1:
Make sure you check your installed ports for vulnerable packages every so often : portaudit -Fda
Solution 2:
I'm not sure there's a specific "BSD way" to do this type of stuff. It all comes down to knowing what's being updated and testing -- generic sysadmin stuff. Fortunately, freebsd-update and portsnap make the "knowing what" fairly trivial.
But, since you asked for specifics, back when I herded a large number of FreeBSD machines, they were all nodes in a cluster. Standalone machines would not be all that different from this, but I guess you could make this vaguely 'devops' like for your production services. In the end, its always a good idea to have separate testing and production environments.
In the cluster situation :
- Each machine mounted /usr/src, /usr/obj, and /usr/ports via NFS.
- Depending on your budget, you can either have a staging/build machine or designate a cluster node as the staging/build node.
- The staging node had a different copy of /usr/ports
- The staging node would update src-all and ports-all via cvsup every night
- In the event of a necessary update, the staging node would be taken out of rotation and buildworld, installworld, and portupgrade would be run.
- The staging node would be tested thoroughly.
- /usr/ports would be swapped on the NFS host
- Each cluster node would be rotated out run installworld and portupgrade, tested and then rotated back in.
Obviously, this was in the case of both a system and a ports update, but the procedure was similar enough updating just packages or system.
If this is done with two machines you could have each taking turns as being production or staging, or just update production from staging.
You can track changes from the cvs logs and check if you've gotten specific updates in /usr/src/UPDATING and /usr/ports/UPDATING, both of which are automatically updated from cvsup.
If you don't use cvsup (and these days there's less of a reason to) you'll just need to find some other way to track what updates you want. You could mail a list of changes that freebsd-update wants to make to yourself and keep an eye on the security errata page.
Solution 3:
OpenBSD Update Philosophy
This is my approach for updating OpenBSD
Stay Up to Date on security releases/patches for:
- BASE (i.e. the stuff the OpenBSD dev team maintains in their source tree)
- Packages/Ports (i.e. software applications installed on top of BASE)
Update Procedures:
- Same OS Version
- New OS Version
BASE
a. Follow the relevant mailing lists - I watch the squish.net daily digests, as well as the general direction shown on the Tech and Misc mailing lists.
b. Follow Unix related security announcement websites/mailing lists.
c. Maintain a local CVS copy of using cvsync
d. Build STABLE releases from the above
When security updates are published, we evaluate the actual security issue with the profile of machines with that version of the OS/vulnerability. If the vulnerability is relevant that we go through the "same version upgrade procedure."
Packages/Ports
It's more difficult to keep track of security updates for ports/packages, but if it's critical enough to be on our infrastructure then it's important enough to keep track off in a similar manner to BASE.
Get on the mailing list for the specific application (it's our responsibility to keep tabs of upstream changes, independent of the OpenBSD project.)
Get on the distribution lists of security sits like CERT that publishes findings of vulnerabilities on apps etc.
The Upgrade Procedures
Obviously build and test your install procedure on separate hardware (or VM) before doing it on your production machines. Fortunately for us, we have redundant hosts for many things and can therefore roll out with minimal downtime of services. Because OpenBSD supports a broad range of hardware, we can rollout server grade equipment for our primary machines, and lower-end desktops as our redundant hosts (or we just build a temporary box to fill in for the main machine during the update cycle.)
Our update procedures are heavily dependent on using the ports/packages system for non-BASE software. The two hosts where we install software from source are a pain to update between version updates of the OS.
Same OS Update
For the BASE OS, we continue to have success with just installing the new binaries over the old ones. Preferably, we backup all the OS and Application configuration/data files, format and reinstall the patched OS and reinstall packages (retaining the original data)
In our deployed OpenBSD hosts (30+), and experience, backing up the configuration and data is not difficult. For our firewalls, all the data is in the configuration and log files.
For Ports/Packages - where the changes are simple, we modify our own port and build the package from that. Having an updated port simplifies the process above.
New OS Update
Between OS releases, we install everything from sketch.
I'm sure there's enough documentation out there for the process, but essentially we build a reference machine with the same configuration as the system to be "replaced." Go through the same tests required before deploying the host.
We backup the configuration from the reference host and install OpenBSD on the production host, restoring the "verified" configuration ontop of it (again running the same validation tests afterwards.)
Solution 4:
For OpenBSD, at least:
- packages are the end product of the ports system; there should be little, if any need to run around with ports.
- -release and -stable is (mostly) frozen in time, with some updates from time to time.
- -current is regularly updated. If you really need up-to-date packages, this is the way to go.
- remain consistent: -release/-stable systems stick with -release/-stable packages...-current systems run -current packages
Faq 15, all about ports and packages
Solution 5:
If there's no security issue, or functionality-obstructing bug, then leave it alone. Check for updates maybe every 3-6 months so you don't get too far behind, but otherwise leave things alone.
If it ain't broke, don't fix it.