[TriLUG] debian in production

[Michael Alan Dorman]

Scott Lundgren <trilug at capitalfellow.com> writes:

> Searching through the debian, packages list I see apache2 and
> mysql4.1 are there.

Though, with the frequency of updates of apache2 at least, that's
probably already an out-of-date version.

> I'll see I'll need to spend some more time comparing the versions of
> other components I'll need to compile PHP5 with what versions of
> those components debian stable provides, could you give me an
> overview how you blend syncs with the "testing" package tree? Do you
> run say 90% of the server from stable packages and only selectively
> update certain software to testing packages? On a scale from mostly
> harmless to nutball crazy what's the opinion of this package tree
> mixing?

In my experience, trying to mix trees will work for a short while, and
then rapidly becomes untenable.

What will happen is that, say, libc will be updated---an upstream
update, not just a packaging update---and as a result, packages
compiled against that libc require that version of libc as a minimum
because symbols may have changed; another scenario is where the C++
compiler (especially pertinent since you're using MySQL) gets updated
in such a way that it requires that all libraries get recompiled and
that all binaries get recompiled against those libraries.

In fact, both of those things have, I believe, already happened since
sarge was released.  It is the nature of such large transitions that
the are often done early in the development cycle to give the maximum
amount of times for loose ends to be tied off---but that means they
also break compatibility very early on.

So, anyway, I long ago quit trying to do mixing on any serious basis.

That leaves two options---rebuilding for the version you're running
(for which there is something of a subculture---google for "sarge
backport" and/or check out apt-get.org), and tracking testing.

Now I will occasionally rebuild a package from unstable that's pending
something bigger like libc or perl or whatnot to make it into testing
if it's really important to me---something like a clamav update or a
perl module I need---or if it's for my laptop and I'm just too
impatient. :)

For most production work, though, I've elected to track testing, and
the way I do it is using apt-move.

apt-move makes it easy for me to maintain a local mirror of just the
packages I use.  I update that mirror periodically. All my machines
feed from this mirror, so I know for sure what version I'm pulling,
and I can control exactly when updates go in.

Also, apt-move only removes older versions of packages when I tell it
to, so if something goes wrong, I've still got the prior version
hanging around.

Part of the reason I've adopted this strategy is because it gives me
reproducability---I manage a bank of machines running a spam-filtering
service, and if one of them dies, I can swap a new machine in place,
use FAI to do a standard install, which uses cfengine to configure the
software, and, because all this stuff is coming off of my mirror, I
can be sure that the new machine will end up with the same versions of
everything as the existing boxes.  Guaranteed clone.

I admit, It's overkill for a lot of situations, but it's an outgrowth
of strageties I developed when I was the only clueful guy responsible
for a 50-odd machine datacenter for a company in the banking industry;
I had to do all that centralizing because otherwise I wouldn't have
been able to manage the load.  Now it's just habit.

Hope this helps,

Mike
-- 
No marigolds in the promised land -- Steely Dan