2

I have a handful of production servers running Centos. My application requires a fairly recent version of PHP (> 5.2, IIRC). The options currently available to Centos Users are:

  1. The official, mainstream centos5/redhat packages.
    • Pros: Most stable, most secure, easy to install -- redhat regularly releases security updates and advisories.
    • Cons: packages are old (5.1.6?)
  2. Third party repositories (like Remi Collet's repo)
    • Pros: Bleeding-edge, easy to install
    • Con: Unreliable -- we used to use the utterramblings repository... but the guy has been totally MIA for over a year now. I don't want to get left high and dry like that again.
    • Con: Not as secure or stable
  3. Use the CentOS testing repository
    • Pros: Pretty recent version, easy to install
    • Cons: Unstable. They don't call it "testing" for nothing. Not ideal for a production server
  4. Build from source (php.net)
    • Pros: Bleeding edge
    • Cons: Labor intensive, insecure, unstable

Other options:

  1. Redhat offers the Redhat application stack which includes recent builds, but no centos equivalent exists.
    • Is there any reason CentOS versions of these packages don't exist? The source must be available, right?
    • The source has to be available, right? How hard would it be to build centos packages myself?
  2. Other linux distros
    1. Debian is comparable in stability to redhat, but offers old packages
    2. Ubuntu offers fresher, but less stable/secure packages
    3. Others?

So, in the end, my question is this: Is there a good source of stable, secure, regularly updated PHP packages or source out there (for ANY linux distro)? Where do you get your source/binaries from?

5 Answers 5

4

Just to highlight the Debian side:

The previous Debian release - Etch (8th April 2007) - came with PHP 5.2.0.

The current Debian release - Lenny (14th February 2009) - came with PHP 5.2.6.

If there should be any major updates to packages during a release cycle, those versions are usually available at backports.org if they've got a noticeable user base. A complete list of backported packages available for Lenny can be found here. This list is relatively short as of now, since the last release is only a few months old.

To see the specific versions for PHP and other packages in Debian you can use packages.debian.org.

1
  • It's also worth adding that in most cases Ubuntu packages are identical to the Debian packages. Debian/Ubuntu also ship the hardened PHP by default. Jun 4, 2009 at 8:02
3

I build my own RPMs because I don't trust third part maintainers to stay on the face of the earth.

It's a bit of a pain (though I only build a few packages), but I know what I'm getting when I'm done. I use the spec files from the upstream (RHEL / CentOS) but I modify them to suit my needs when necessary, and subsititute in whatever version of the source I'm looking for (modifying the upstream's patches, when necessary).

This also helps my workflow of not installing compilers on production systems, since I can ship my custom-built binaries out to them. I also do this to provide backports for newer packages to older OS's when I'm "stuck" running an older OS (no budget to upgrade, etc).

If you can get your hands on SRPMS, building a package isn't too hard. (It's mainly getting the build environment together for a given package that can be a pain.) Building an RPM from nothing (i.e. writing the spec yourself) is a good exercise, though you should read some "professionally" done specfiles first to get a feel for it.

1

I can't really answer to your question, but what I use to do, is to use the official source code release, then compile it on a developpement environment.

Then I just do a package from it using the dpkg tool (I'm using debian), but there should be similar way to do a package with RedHat like OS.

Then, you just have to spread it on your servers.

0

We keep a VM running to build packages that aren't available from the distribution's repositories. This is a constant problem when you're using a distro; the solution usually is to build them yourself and keep up to date on the security advisories and leaks for those packages. Security patches that vendors distribute are usually provided first via the security lists, then are tested and integrated by vendors and released.

Frankly, as long as you gpg-key check your code (and then sign your packages with your own key), you're going to be as secure as the distro's code. You just have to keep up to date, which isn't insecure, it's just labor. If you need the functionality, then that's up to you to do the labor. Otherwise, go with a distro that doesn't have the trailing-edge problems that centOS has or that has an official build service (cough OpenSuSE) or buy a license from a vendor that updates more frequently. You can work, or you can pay. Your choice, but there's only so much 'free' in 'beer'...

And go hang out with some crufty old gray-hairs that will enjoy telling you how labor-intensive it was to keep up a box when EVERYTHING got compiled from source. ;)

1
  • Uphill, both ways, in the snow, and we LIKED IT. Whippersnappers these days... May 17, 2014 at 10:52
0

Other options worth considering

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .