1

(originally posted on stackoverflow -- someone suggested I drop the question over here)

Does anyone have any experience in upgrading individual chunks of the XAMPP LAMP stack without installing an upgrade from XAMPP?

We have several production servers which require an update to the openssl lib but the upgrade from XAMPP would take us into newer versions of MySQL and PHP which we haven't tested against yet.

Otherwise, I would look for some sage wisdom from anyone who might have decided to forego XAMPP and build/maintain their own LAMP stack.

Thanks

user7944
  • 135
  • 4
  • I've not used XAMPP but I'm pretty sure I tanked Apache once on a FreeBSD box by upgrading OpenSSL *without* also rebuilding Apache. It was a while ago and the details are vague but all of the Apache processes went crazy on resource usage and I had to rebuild Apache to fix the problem. – Ben Dunlap Jun 18 '09 at 17:16

3 Answers3

0

We just use Debian/Ubuntu for our servers. No security update will cause you to upgrade a software version; everything is backported into the current stable release.

If you need to upgrade a particular component, it's fairly easy to rebuild a particular package for an older release and there are normally very few complications from doing that.

David Pashley
  • 23,497
  • 2
  • 46
  • 73
  • The problem comes from the fact that XAMPP's LAMP stack comes pre-built in a nice little package. Upgrading the server's openssl will have no bearing, so we'd be forced to build the newer openssl library and then figure out how XAMPP has it shoe-horned into their structure. – user7944 Jun 03 '09 at 21:40
0

Modern distributions 'backport' security patches to the 'current' release of their packages, without bumping the primary version numbers in the package (ie, 0.9.6), so version changes don't break other components or packages.

If you want the latest and greatest versions of everything, you should consider rolling your own packages for your application stack, and hosting them on an internal mirror / repository.

jtimberman
  • 7,587
  • 2
  • 34
  • 42
0

This is the trade off of going with "vendor" stack versus rolling your own. I've done it both ways. And I am no longer in the business of maintaining my own stacks. It's good experience, you really learn the software, how it's put together etc. But it takes work and time. When you are using a "vendor" provided stack, it's best to use their stack "as is", and apply any one-off fixes that they may provide. Afterall, that is one of their key benefits is: Install one pkg and not have to maintain libraries and dependencies.

The tradeoff is:

"vendor" stack means you sort of have to wait for updates, patches, fixes at their rate for their stack release.

rolling your own stack means you maintain all those updates, patches, fixes and can apply these at any rate you choose. You just have to do the work.

Yes, you can slide in libraries, but in a way you are voiding the supportability of the stack. If you encounter a problem, is it b/c of that library you just added to the stack and how will the "vendor" or community be able to best support it?

netlinxman
  • 477
  • 1
  • 5
  • 10