I've used FreeBSD for about 5 years - server/Desktop - and I've tended to take my apt-get/yum upgrade everything habits along with me ( I admin Debian/RHEL/Cent boxes as well -- I know, I know ...should be more discerning regardless of platform ). So it's usually a:
portsnap fetch
portsnap update
portmanager -u
For the ports
Sometimes followed by a:
freebsd-update fetch
freebsd-update install
For the system ...etc. Then just clean up any messes afterwards ...if they occur.
This, I realize, is a fairly excessive un-BSD way to do things. What is your philosophy for your BSD boxes? Do you run a portaudit/portversion -- check output then update (make deinstall ...etc) after careful consideration?
I'm fairly new to OpenBSD, I confess. I see myself cvsupping the ports tree, running the "out of date" script, then just upgrading critical ports --- but leaving the kernel/binaries alone and just upgrading every six months. Do you patch/recompile/rebuild kernel, binaries --- why?
What's a conservative approach for critical services ( reasonably critical -- this ain't no bank or hospital ) on BSD boxes? Are you using a similar approach on your Linux boxes? I generally don't touch the kernel on any servers unless a security alert has stricken terror into my soul.
Yeah, there's docs and books galore -- what do you people actually do? Assuming we know the basics -- what's the wisdom? Use cases/environments and scenarios vary, as do the stakes/stakeholders/users. Books and man pages cover tools and uses, but lack practical application. Recommend a book if you know of one that covers it!
Thanks for reading!
Bubnoff
Conclusions ~ Thanks to everyone who took the time to answer this post. My strategy overall is now to follow the mailing lists for both BSDs and be more selective/discerning with updating than I have been in the past.
FreeBSD ~ Portaudit is a good answer. With the mailing lists and diligent audits, I think this will serve well here. It's interesting the different emphasis on ports between OpenBSD verses FreeBSD.
OpenBSD ~ Will follow the mailing list and use the package tools ( pkg_info and pkg_add -u ) where deemed critical. Upgrades: Looks like you need to upgrade at least once a year. They support the newest release plus one back - so right now it's 4.8 and 4.7.
Thanks again.
Make sure you check your installed ports for vulnerable packages every so often : portaudit -Fda
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 :
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.
OpenBSD Update Philosophy
This is my approach for updating OpenBSD
Stay Up to Date on security releases/patches for:
Update Procedures:
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.)
For OpenBSD, at least:
Faq 15, all about ports and packages
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.
I prefer to use
portupgradefor upgrading ports, and do this only when absolutely necessary, e.g. when a vulnerability is found in the port or new functionality is required.As for upgrading the system, I usually rebuild from sources with
make buildworld. I never had any problems with this approach.