Jump to content

Good practices on maintaining PHP up-to-date


Recommended Posts

Hy everyone! Two questions:

 

1) If I compile PHP with zlib, I get the version 1.2.3.4 which is much older than current stable (1.2.6). So, is it a good practice to build and update php modules myself? I mean, both performance and security-wise, is it OK to build their newest versions as shared extensions and use it on production?

 

2) Whenever I do that, I get two versions from phpinfo() output: "Linked Version = 1.2.6" and "Compiled Version = 1.2.3.4". Given that I specified its path while building PHP, which one is actually being used?

 

These questions are not specifically related to ZLIB, I'm only using it as an example. I am considering maintaining every module in use fresh and up-to-date if that not a problem.

 

Thank you!

Link to comment
Share on other sites

Unless you have a specific reason for compiling php yourself your generally better off leaving it to be maintained by your distros developers IMO. It's just much easier to keep things in sync.

 

Thanks for sharing your experience, thorpe!

 

The point is that official PHP releases on Debian are quite outdated, while using non-official maintainers like dotdeb in a privacy-sensitive mission critical setup might not be suitable for some clients, I suppose...  :-\

Link to comment
Share on other sites

Are there particular features you are looking to use that aren't available in the current Debian versions? Servers aren't like desktop computers, you generally don't try and run the very latest versions of software. That is the entire reason Debian is a bit behind, because it is well tested and stable.

Link to comment
Share on other sites

Are there particular features you are looking to use that aren't available in the current Debian versions? Servers aren't like desktop computers, you generally don't try and run the very latest versions of software. That is the entire reason Debian is a bit behind, because it is well tested and stable.

 

Sure! Let's take OpenSSL library as an example. The latest version available on Debian Squeeze right now (including testing and backport repos) is "0.9.8o-4squeeze7". In order to take advantage of AES-NI hardware-based instruction set, it would take you to use OpenSSL 1.0.0e or newer as far as I know. That would be a huge performance leap from the stable build...

Link to comment
Share on other sites

Sounds like you should be using a faster moving distro then if these types of things concern you. Either that, or maintain your own packages, it's not really something I'd like to be responsible for though.

 

We maintain a lot of servers at work, and besides security related updates and installing new software that we need, we only really update the systems and there software once every 12 months or so.

Link to comment
Share on other sites

Sounds like you should be using a faster moving distro then if these types of things concern you. Either that, or maintain your own packages, it's not really something I'd like to be responsible for though.

 

We maintain a lot of servers at work, and besides security related updates and installing new software that we need, we only really update the systems and there software once every 12 months or so.

 

Yeah, that's something I get a lot but I never figured it out. Why is it that people say it's so hard to maintain your own packages? I mean, building and replacing old binaries and config files doesn't look any tricky when I do it in a testing environment, so what is it that makes it so much harder to achieve in production?

Link to comment
Share on other sites

Eventually you will run into issues with dependencies because certain versions of software and libraries might only work with other specific versions of software and libraries.

 

Of course, if your testing before pushing to production you can test these thing first.

Link to comment
Share on other sites

Eventually you will run into issues with dependencies because certain versions of software and libraries might only work with other specific versions of software and libraries.

 

Of course, if your testing before pushing to production you can test these thing first.

 

Sure, they would run through extensive scripted stress testing in order to test every possible interaction before going to production, but mmm... it's one heck of an management overhead...  8)

 

TBH, I'm really confused right now. I need as much reliability as possible given that I need to assure a 99.995% SLA uptime on the Apache+PHP-FPM SaaS enviroment (it's a datacenter redundant mission-critical infrastructure), but it's hard to comply with Debian's stability when I go to PHP.net and read "Fixed arbitrary remote code execution vulnerability" and "All users are strongly encouraged to upgrade to [latest stable]". That's in the changelog for the latest stable, let alone all the security vulnerabilities found since 5.3.3 (latest Debian Stable)...

 

For the first time in 7 years I'm considering switching away from Debian...

Link to comment
Share on other sites

For the first time in 7 years I'm considering switching away from Debian...

 

But where are you going to go? Seriously, Debian offers a lot of stability.

 

The only distros I know of that are bleeding edge are also far more work to maintain than Debian. It comes with the territory.

Link to comment
Share on other sites

For the first time in 7 years I'm considering switching away from Debian...

 

But where are you going to go? Seriously, Debian offers a lot of stability.

 

The only distros I know of that are bleeding edge are also far more work to maintain than Debian. It comes with the territory.

 

Well, I've been evaluating CentOS 6.2 with Remi and RPMForge repos over the past couple of days, but it didn't quite match up to my expectations...  :( So, I think I'm sticking with Debian anyway. I might as well use DotDeb packages for some lower grade setups, but after all Squeeze how it is seems to be the way to go when downtime is not on the table.  ;)

 

Thanks a lot for the advises, thorpe!

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.