Migrating from RedHat ES

[Synchro]

I have a RH ES box hosted with SB. Generally I'm not very impressed with RH. I can't believe how easy it is to screw up the system with rpm - my up2date is currently broken due to an OpenSSL version conflict! Many of their packages are way out of date - PHP 4.3.2 and Apache 2.0.46 are considered current by up2date, despite them containing known security holes! On top of that, I'm finding that the very simple task of setting up virtual servers in Apache is just not working, despite having done it in many other places successfully. The upshot is that I'm wondering if it's a good idea to switch to Debian to restore my sanity.

I'm used to fink on OS X, which I understand is based on Debian's package manager (and also apt-get). Aside from that, I'm also familiar with OpenBSD, so tend to prefer doing updates from source. do Debian's packages tend to be more up to date than RH? Is there better integration in Debian between packages installed from source (e.g. MySQL) and those installed through the package manager?

I'm also assuming that this would cost me an OS install from SB, but also that I could drop the additional cost of RHES.

[bow-wow]

PHP 4.3.2 and Apache 2.0.46
The version numbers are not always interesting because the security fixes are backported. If up2date says they're good then I'll bet you have RedHat-patched versions of both.

Debian has much better package management, but as far as the packages being more "up to date" that is another story. Naturally, security fixes are backported very quickly, but the patches are applied to the current version of the packages where possible.
For example, my current Debian stable box has:

linux kernel 2.4.18
Apache 1.3.26
php 4.1.2

All known vulnerabilities have been patched but as you can see these are older releases. This can be a problem if you require specific versions of some packages for certain features.

If you have no such requirements, then you can use Debian with peace of mind that you have a very stable and secure system, with sane package management to boot.

[Synchro]

I appreciate the backporting issue - it's very common in OpenBSD - however, I'm a PHP developer and tend to need current releases. Apache's not such a problem, but I can see that MySQL will be as I need to run 4.1 for unicode support.
This split between RHN and manual packages is the source of the problems with up2date. I just need to know if Debian's package management can cope with packages from multiple sources without getting all confused like RPM.
I might just give it a whirl here on an old PC before trying to switch at SB.

[Tino Didriksen]

I'd say that exactly Apache and PHP are worth compiling yourself. Then you get exactly what you want, and the package managers are out of the loop.

[ferret]

If you really need more up to date features in Debian, try backports.org

Its a site that provides binary packages in .deb format (The package manager for Debian) with the latest updates from Unstable.

You can get 2.6.4 (And .5) there, as well as MySQL and Apache, etc.

I've used multiple packages there, and have had no conflicts with the normal Stable package list.

[Synchro]

Sure, I'd always compile PHP myself - the problem is when dependencies screw up the rest of the system, for example RHN uses OpenSSL 0.9.6, but latest PHP depends upon 0.9.7, and if I update to that to support PHP, other packages will break.

This is partly why I'm keen on installing from source as it gets around most of these issues, however, it's not an easy option in RHN.

[ferret]

Debian's package manager also lets you download the source and build it yourself, btw. It would be the source for their package, not the latest, but the option is there.

[knightfoo]

If you find yourself needing custom built packages that don't quite work with the packages provided by the OS vendor, there are safe ways to build them without mucking up the system.

On Red Hat systems it is fairly easy to create your own binary and source RPMs. There is a really good tutorial at RPM.org (http://www.rpm.org) that is worth reading. If you want a template you can always take the spec files from existing source RPMs and change the name of the source files. The configure options don't change much between versions so the only thing you need to worry about is which patches to apply (or not apply). If you build the latest version they you may not need to apply any patches because most of the patches involve security fixes that are already rolled into the latest version. You can even tell up2date to ignore packages that you created so they don't get blown away by Red Hat updates.

Debian has its own package building system too. In the simplest case, you build your application, install it to an alternate root, then tar it up. There is more information about building Debian packages than you could possibly need on Google (http://www.google.com/search?q=debian+package+howto). You could go so far as building source packages and make an "official" Debian package for distribution. You could even put up your own Debian package repository and add it to the sources.list on all your machines so you only need to build it once. We have had to build a few custom PostgreSQL packages for ServerBeach systems (darn PHP developers and their long table names ;)) and it really is not painful.

If you want to get really hardcore you can go and build all of your packages from source. There are some things to look out for though when doing this. Make sure you install libraries out of the way so they don't overwrite or interfere with packaged system libraries. Keep your custom built libraries and applications in /usr/local or even /opt. I'm a fan of using /opt/<application> because it makes it easier to keep track of things and you can even install multiple versions with minimal hassle. You may need to adjust /etc/ld.so.conf or set your LD_LIBRARY_PATH to use any custom libraries.

-knightfoo