> @mjasay: Putting together a post on the not-so-flawless execution of Red Hat's past. (Weird M&A, etc.) Pls send yr ideas to my twitter name @mac.com
Here's one I'm still a little raw about.
I figured out the hard way one of the ways that Red Hat earns money. Strong arming, as far as I'm concerned...
I work for a broadband ISP and over the last couple of years we've been moving away from Sun gear and the Solaris o/s to HP blades running Linux. In preparation for moving my BIND dns servers from Solaris to Linux, I set up up a pair of servers running the stock bind packages for 5.2. I started by just pointing my 10 anti-spam servers to these two boxes.
The named process crashed in two days. "socket.c:1649: INSIST(!sock->pending_recv)" Come to find out, this is a bug that had been fixed a year and a half prior by the ISC BIND developers. Red Hat will not implement the fix unless you have one of their ridiculously expensive support contracts and open up a case with them.
They keep the model broken because the way the bind rpm packages are created, the start with a VERY OLD version of bind as the base to compile from, then simply apply whatever patches they pick and choose to apply before building the rpm.
I'm usually a proponent of sticking with rpm's for anything like that because it makes things very maintainable. But since Red Hat holds bug fixes hostage like in this example, I'm compiling from source. Less maintainable, but the named process hasn't crashed for me and it's been about 5 months now.
As an aside, I ran dnsperf tests against the stock bind and a fresh compile of my own and mine handled 3 to 5 times as many queries per second. But this only because Red Hat uses shitty ./configure options when they compile, something anyone can tune with a src rpm.
--
Andy Harrison
public key: 0x67518262
