Dangers of Tracking FreeBSD STABLE
Most of my FreeBSD systems track the SECURITY branch of FreeBSD. Wherever possible I try to apply binary updates for the kernel and userland with Colin Percival's freebsd-update tool. Most of my hardware is really old and I prefer not to spend a lot of time recompiling from source.
One of my systems does track the STABLE branch of FreeBSD, specifically RELENG_6. This is more or less a lab system. I like to see what might appear in the next version of FreeBSD, since 6.1 will be a version of STABLE.
Although STABLE is definitely more likely to be operational than CURRENT (which is the bleeding edge and will become FreeBSD 7.0), running STABLE is not without its hazards. Recently a commit appeared that changed part of the PCI code, shown with diffs here.
I happened to try updating to the version of FreeBSD STABLE that had src/sys/dev/pci/pci.c version 1.292.2.6, dated Mon Jan 30 18:42:10 2006 UTC. While compiling, I got this error:
I can see the line in pci.c the compiler doesn't like:
Shorly after version 1.292.2.6, dated Mon Jan 30 18:42:10 2006 UTC, appeared in STABLE, it was updated to 1.292.2.7, dated Tue Jan 31 14:42:43 2006 UTC. However, the diffs to the previous version don't appear to affect the PCI_IVAR_LATTIMER code. I'm not sure what happened, but I was able to update to STABLE after the new code was committed and therefore get the system compiled and running.
As you can see, the system is now running STABLE as of late 31 Jan 06.
One of my systems does track the STABLE branch of FreeBSD, specifically RELENG_6. This is more or less a lab system. I like to see what might appear in the next version of FreeBSD, since 6.1 will be a version of STABLE.
Although STABLE is definitely more likely to be operational than CURRENT (which is the bleeding edge and will become FreeBSD 7.0), running STABLE is not without its hazards. Recently a commit appeared that changed part of the PCI code, shown with diffs here.
I happened to try updating to the version of FreeBSD STABLE that had src/sys/dev/pci/pci.c version 1.292.2.6, dated Mon Jan 30 18:42:10 2006 UTC. While compiling, I got this error:
/usr/src/sys/dev/pci/pci.c:1611: error: `PCI_IVAR_LATTIMER' undeclared
(first use in this function)
*** Error code 1
Stop in /usr/obj/usr/src/sys/JANNEY.
Error code 1
Stop in /usr/src.
*** Error code 1
I can see the line in pci.c the compiler doesn't like:
1611 case PCI_IVAR_LATTIMER:
1612 *result = cfg->lattimer;
1613 break;
Shorly after version 1.292.2.6, dated Mon Jan 30 18:42:10 2006 UTC, appeared in STABLE, it was updated to 1.292.2.7, dated Tue Jan 31 14:42:43 2006 UTC. However, the diffs to the previous version don't appear to affect the PCI_IVAR_LATTIMER code. I'm not sure what happened, but I was able to update to STABLE after the new code was committed and therefore get the system compiled and running.
janney:/home/richard$ uname -a
FreeBSD janney.taosecurity.com 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Jan 31 22:17:14 EST 2006
root@janney.taosecurity.com:/usr/obj/usr/src/sys/JANNEY i386
janney:/home/richard$ grep FBSDID /usr/src/sys/dev/pci/pci.c
__FBSDID("$FreeBSD: src/sys/dev/pci/pci.c,v 1.292.2.7 2006/01/31 14:42:43 imp Exp $");
As you can see, the system is now running STABLE as of late 31 Jan 06.
Comments
It depends on your needs. As a general-purpose server with a huge array of applications in the ports tree (14,000+), I like FreeBSD. For a single-purpose system with a high level of Internet exposure or responsibility (like a firewall), I like OpenBSD. The good news is that trying both costs zero money.
FBSD and the ports system make it a lot easier to maintain than OBSD.
I've deployed into production use both on custom systems for clients and as part of self contained solutions using PFSense.
Regardless of platform, PF is a joy to work on and maintain compared to iptables.
greg
For a generic server/router I would choose FreeBSD over OpenBSD or in Chris case where you'll find FreeBSD a more welcoming enviroment for first time users.
I agree with greg, pf is way more friendly than iptables.
One thing I miss from iptables: a p2p module where you can discard or tag packets. Imagine ALTQ on it ;)
Apparently you don't know the benefits of compiling from source: http://funroll-loops.org/
Pat
I resent the use of the Type-R logo to make fun of someone. What's wrong with my CTR? ;)
http://www.civictype-r.co.uk/gallery.htm
I use both FreeBSD and OpenBSD, similar to the way Richard does. For an all round server, FreeBSD and the various ports tools are great.
I leave firewalling and VPN'ing to my OpenBSD boxes. You can also run snort on them, but you have to do a manual install of snort and any tools you want. However, setting up a bonded interface when using taps is a piece of cake on OpenBSD. FreeBSD is a little more work.
PF rocks btw. So does having a transparent squid proxy and a chrooted bind (caching dns for internal users).
I am curious as to why you'd need an external module to packet shape p2p ?
I havent had much difficulty tagging and massaging p2p traffic using ALTQ here.
Joe,
I can recommend adding
Ad blocking with Bind
to your internal dns. Speeds up surfing a lot
greg
Yes it's doable but not dynamic and when you have such dynamic traffic like P2P you're not shaping/blocking everything.
Take for example ICQ: block the default ICQ ports,start a network capture and you'll see it try to go out through 21, 23, 80, 8080, 3128, etc. Identify it by packet pattern and you'll get it always (depending on protocol).
Of course as like snort a realtime packet parser is a cpu hog and depending on the scenario, mostly pps or bandwith this can be very dificult to apply.
Sure, it's Loonix not FreeBSD, but it's an easy build, install & config on 2.6.12 or higher kernels..
(ipp2p is a kernel & iptables module that allows you to mark most P2P connections/sessions. It works "a trick" to allow you to mark, classify & ratelimit most modern P2P protocols!
I've also read of the ng_p2p netgraph module for FreeBSD, but I don't think it's anywhere near as good as ipp2p currently is..
ipp2p is (much) less cpu load than you'd think, even with its need for the CONNTRACK modules etal..