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

[Daniel Lawson]

> 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 (:]
>   

You can hold back upgrading a specific package.


>  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?
>   

Mostly because the kernel developers don't think I should have to have 
different kernels. Which tweaks did you have in mind?


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

During this thread I've assumed you've meant hand-compiling packages and 
distributing through some manual mechanism - either hand-built on every 
machine, or built once, scp'd then installed on every machine.  That's 
what I interpret "hand compiling" to mean.

IMO the better practice is to utilise the tools you have in your 
distribution. To use your example of openssh, I would build an openssh 
4.7p1 package, and put that on my private deb repository, and would get 
pushed out to all my nodes.  I can track per-distro changes in build 
time configurations easily, including taking note of which libraries are 
relevant on each distro. Other than a short amount of work for each 
release, this makes pushing these packages out trivially easy.

I don't think openssh is a great example, because debian *do* track 
security flaws in openssh really quickly, and I can't think of anything 
that is a must-have new feature in the intervening versions. It's just 
not worth the time to me.

What is worth spending the time on is building a reproduceable network, 
through standardised builds and processes, existing distribution backed 
expertise and infrastucture and node management tools like puppet. So 
I'll let debian push a new openssh package for me, and let me focus on 
deploying new tools and infrastructure. If and when the shit hits the 
fan with a serious flaw that doesn't get due attention, I'll do what's 
needed. I never said I won't pay attention to security notices... :)