Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

6 Answers 6

up vote 6 down vote accepted

Make sure you check your installed ports for vulnerable packages every so often : portaudit -Fda

share|improve this answer
1  
This is a must-have for *BSD. I highly recommend throwing this in a nightly crontab to email you every morning with ports with security fixes. –  Andrew M. Dec 5 '10 at 17:59
    
But then it's a matter of acting on the advice of Portaudit. From reading the answers here, most people advise leaving things alone unless absolutely necessary. I've heard some admins claiming that everything should be up to date constantly ...this strikes me as a good way to break things. –  Bubnoff Dec 7 '10 at 19:59
    
I will take this advice for FreeBSD. Thank you. Which leaves OpenBSD –  Bubnoff Dec 7 '10 at 20:01

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.

share|improve this answer
    
I like the idea of 'staging' verses 'production'. With virtualization there is almost no excuse not to these days. Thanks for the response. –  Bubnoff Dec 7 '10 at 20:52
    
Yeah, plus it fits in nicely with 'devops' type stuff (from what I understand of it) if you have to deal with that. –  D.F. Dec 8 '10 at 15:37

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.)

share|improve this answer
    
Thanks! Thats the direction I'm headed. Follow lists, use redundant hosts. –  Bubnoff Dec 15 '10 at 3:47

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.

share|improve this answer
3  
3 - 6 months? What about Apache/lighttp or whatever frontfacing web apps CMS etc? Don't you worry about those? Otherwise ...I see your point. –  Bubnoff Dec 4 '10 at 3:04
    
@Bubnoff OpenBSD comes with a custom httpd, derivated from Apache 1.x. Most of the update provided by Apache don't even apply. –  Benoit Dec 6 '10 at 15:39
    
I understand that. But OpenBSD does provide updates to current which later travel to stable. And that still leaves the packages themselves ...Apps that use Apache would possibly require updates. Or do you just upgrade the whole thing every six months? –  Bubnoff Dec 7 '10 at 20:06
    
This is my approach. I rarely install anything out of ports on my production systems so all I really need to tend to is the base installation and the packages. I follow the errata (openbsd.org/errata.html) and the relevant mailing list for any packages I have installed. If I have installed something else on top, such as a CMS system, I track and maintain that separately. If I do need to patch something critical, I build my patch on a test system and then copy it over. –  kce Jan 9 '11 at 22:17

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

share|improve this answer
    
Yes, it seems that the devs/maintainers for OpenBSD encourage the use of packages over ports as the ports produce the package before installing anyway. But the ports tree has an auditing script ( ./out_of_date ) ...what is the analogue for packages? A portaudit for OpenBSD ...or do you just follow the mailing list and upgrade the package(s) manually? –  Bubnoff Dec 7 '10 at 20:13
    
Personally, with -current it's "pkg_add -u -Dupdate,updatedepends" ~monthly for me. I admit I've never thoroughly used the ports like that;it's usually just cvs up;make update clean for me if I ever needed to do that. I was under the impression those other scripts are for porters, but again, I've rarely used the ports system. As for auditing, that's all done by the ports team and of course anyone else who contributes. –  lonerman Dec 9 '10 at 3:36
    
@Bubnoff If you update to the latest versions on -stable, you'll have all the released security patches for that release. (Unlike -current that also includes non-security updates). –  Hugo Jun 21 '13 at 12:01
    
@Hugo - thanks! That's a good point. I'll have to write that into my server build documentation. –  Bubnoff Jun 22 '13 at 16:27

I prefer to use portupgrade for 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.

share|improve this answer
1  
Many seem to prefer portupgrade to portmanager. Is portupgrade the more mature of the two? Looks like portmanager has yet to reach 1.0. –  Bubnoff Dec 7 '10 at 20:14
1  
Yeah, portupgrade's been around for an awfully long time and seems to have the most active development and support. I know there are other port management tools, but portupgrade is the one that's mentioned the most consistently on the lists. There's a discussion between the two from back in '04 -- lists.freebsd.org/pipermail/freebsd-questions/2004-December/… -- that I found, but I'm not sure how current it is. –  D.F. Dec 8 '10 at 15:36
    
I use this same approach and it's mostly due to having used FreeBSD since the 4.x days when buildworld and portupgrade were the best/only options. They still work great today if you have the time to run them and the time to learn the process. Plus I always build with -Os optimizations, smaller/faster system. –  Chris S Dec 9 '10 at 14:17
    
Thanks! I'm switching to portupgrade. –  Bubnoff Dec 15 '10 at 3:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.