[nzlug] CentOS and the "joys" of rpm based systems

[Steve Holdoway]

On Sun, 20 Jan 2008 21:05:07 +1300
Daniel Lawson <daniel at meta.net.nz> wrote:

> 
> > TBH, I wouldn't be using either in that environment, but doing all my package selection manually. Well, I actually go further than that and build from source for my production servers... of which only one is redhat.
> >   
> 
> 
> That's a bit gentoo-esque, isn't it? The idea that a package maintainer 
> will add all the bells and whistles and make it impossible for you to 
> not use them is a bit outdated.
> 
> Debian Woody (released 2002) used to have a bug where if you installed 
> slapd, the openldap daemon package, it ended up pulling in X, due to a 
> dependancy on an ODBC manager which had a GUI interface.  A bug, but 
> I'll concede that it was caused by adding one of those "bells and 
> whistles" which may have been better left unchecked, as I doubt many 
> people use LDAP with an ODBC backend. However, I haven't hit any other 
> troublesome unneeded or unwanted dependencies in Debian since then, and 
> the same for Ubuntu. Or Redhat, for that matter. I'm sure it happens 
> occasionally still, but it's not something I've hit in a problematic way 
> for a long time.
> 
> Debian packagers go out of their way to modularise their packages in 
> fact. You don't install "PHP" for example and get all the bells and 
> whistles. Instead you install the base PHP package (cgi, modapache, cli, 
> or any combination of the above), and then whichever modules you want as 
> separate packages.  It's definitely false to claim that package managers 
> will put extra stuff in there deliberately. Gentoo manages this with USE 
> flags, FreeBSD via ports, and RedHat has a similar method to Debian.

But I've got one system where I cannot install anything newer than php 4.3.7, or loads of code fails. If I relied on apt-get upgrade then I'd be stuffed. If it works, and is secure ( ok php is generally a bad example here ), then why bother to upgrade at all? [another good reason against outsourcing if anyone needs one (:]
> 
> > In a production environment, I don't trust anyone but myself to decide what software to load on my servers - especially not third party packagers who tend to add all possible bells and whistles. 
> >   
> 
> 
> In a production environment, I definitely don't trust whoever is doing 
> the maintenance of a machine to keep up to date with not only upstream 
> bug/security releases, but also to actively backport security fixes to a 
> stable version that it turns out you can't move from.  I'm doing the 
> maintenance today, but I might not be tommorrow, and I have some level 
> of duty to make sure the systems I implement will work without needing 
> my constant care and attention. I'm not saying I ignore these aspects, 
> just that it's a far more efficient use of my time to not reinvent the 
> wheel.
> 
This is where we'll have to agree to disagree. IMO administering servers requires exactly this much effort: to keep abreast of the current security breaches, and to be able to respond to them immediately. The package releases for security alerts are typically weeks behind the source code available at the original maintainer. Even with the effort of building and testing, you're still patched weeks ahead of the (debiam/redhat/suse/...) official release.

With hundreds of servers to maintain, the extra cost of a dedicated employee is pretty trivial compared to the cost of cleaning up from a major attack.

Sorry, but this is a real sore point with me. I see, time after time, production servers installed and configured as if they are development servers, and no real resource allocated to looking after their configuration. You're not reinventing the wheel, because packaged releases are generalistic, whereas your servers are dedicated to a specific task. For example, why wouldn't you reconfigure the kernel of a database server to reflect its needs, rather than installing one that runs X pretty well?
> 
> It's also worth noting that merely using apt, or yum, or whatever, 
> doesn't mean you don't get a say in what's installed. I'm not as 
> familiar with yum, but there are plenty of ways to circumvent unwanted 
> and unneeded bad "dependancies" with apt. The simplest way is to create 
> a dummy package which provides the dependancy, and will therefore keep 
> your package management system happy. Debian even provides 
> infrastructure for this with the equivs package
> 
> 
> When it gets down to it, I don't have time to hand fetch packages from 
> repositories, tracking through their dependancy tree. I did that with 
> older versions of redhat, and I now manage far too many servers to make 
> it palatable. I also don't have time to second guess the guys who do 
> package management and bug tracking/patching/backporting *all the time*.
You'd hand fetch them from the original maintainers... so that, for example I can run openssh version 4.7p1, which includes bugfixes and new functionality above the 4.6p1 available with gutsy gibbon, even though it's been out for over 4 months now.

I still maintain that you don't have time *not* to do this.
> 
> I'd much rather spend my workday doing new work, trying to clear out my 
> blogroll, or hell, even replying to NZLUG emails... :)
> 
Wouldn't we all? 
> 
> 
> 
> _______________________________________________
> NZLUG mailing list NZLUG at linux.net.nz
> http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

I reckon that in most cases the services you need to be paranoid about are the internet facing ones: web, mail, ftp, ssh, and so on. There aren't usually that many of them. And these are the ones that I take this amount of care about ( well, historically Mysql as well as the packaged versions have been so far behind, and the features not available - like views - drove developers used to a more mature rdbms mad ). In reality, few packages out there require keeping right up to date: if your database is only available through server-side web code, and the command line then as long as they are well protected, it could be mysql 4.0, or postgresql 8.2.5, and neither will be less secure than the other.

Steve

-- 
Steve Holdoway <steve at greengecko.co.nz>