Upgrading to PHP 5.2.1 on RHEL and CentOS
February 10, 2007 by Jason · 36 Comments
Well, PHP 5.2.1 was released on Thursday so here we go again. PHP 5.2.1 contains more than 180 bug fixes, as well as some performance improvements (official release statement). For those of you that like to stay on the bleeding edge, here's my how-to on upgrading to PHP 5.2.1 for RHEL & CentOS 4.
As I have done with the last few upgrade tutorials, I'm including the modified src.rpm at the bottom of this post. Compiled RPM packages are NOT going to be included as PHP RPMs are dependent on the version of httpd that you're running. If you didn't follow my Upgrading to httpd 2.2.4 how-to, my compiled binaries won't do you a bit of good. In any case, if you've followed any of my other tutorials, you're probably pretty familiar with the process. If not, read my how-to's on Upgrading to PHP 5.1.6 & Upgrading to PHP 5.2.0 BEFORE proceeding as they both contain helpful information about the process.
As with all src.rpm compiles, make sure that you have a complete development environment installed on your system. If you don't have packages such as gcc, gcc-c++, make, autoconf, etc. installed then checkout the PHP 5.2.0 how-to to see what you'll need. Make sure that you have the 'mysql-devel' package installed as well. This should be the same version that is on your web server (assuming that you are compiling on a different box).
Once that's out of the way, make sure that you have a non-root user available for the compilation and that that user has full access to the /usr/src/redhat folder (and everything below it). If you don't have that folder (meaning that you've never built a src.rpm before), create it first. The permissions can be set with the 'chmod -R 777 /usr/src/redhat' command or with 'chown -R username:usergroup /usr/src/redhat' which is actually the better method (make sure you substitute the actual user name and user group).
At this point you're ready for the unmodified php & php-pear src.rpm files. You can find them here & here respectively. It's worth mentioning that this is a newer version of php-pear than was used in my prior how-to's, so make sure that you update your system. Once they've been downloaded to your server, install them as a non-root user using 'rpm -ivh filename' for each one.
Next, you're ready to build the RPMs. PHP must be built and installed BEFORE php-pear can be built so we'll start there. First things first, the src.rpm you installed was for PHP 5.2.0, not 5.2.1, so we'll need to get the newest source and make a couple changes to the php.spec file.
In order to get the newest source into your build environment you'll want to use 'wget' to download this file to your '/usr/src/redhat/SOURCES/' folder. It should be just under 9MB so if you don't get that much, the file I linked to may have been moved. In that case, just go to the PHP downloads page and elect to get the tar.gz package.
Next up, change to the '/usr/src/redhat/SPECS/' folder and begin editing the php.spec file (I use 'nano -w php.spec' but if you want to use 'vi' or something else, go right ahead). You'll want to make the following changes:
- Line #8 - Change "5.2.0" to "5.2.1".
- Line #9 - Change "9" to something else (I use "jason.1" but "1" would work just as well).
- Delete lines 24 & 25 (the ones that say "patch6" & "patch7")
- Delete lines 298 & 299 (the ones that say "patch6" & "patch7")
- Search for "CFLAGS" and remove "-Wno-pointer-sign" from the line you find.
Once you've done that, save your changes and return to the command prompt. You are now ready to compile and package PHP. You can do that by running the command 'rpmbuild -bb php.spec' (this assumes that you are in the '/usr/src/redhat/SPECS/' folder). Once that finishes compiling, and it will take a while, you'll need to install a few of the new packages from the '/usr/src/redhat/RPMS/i386/' folder (assuming that you are on a 32-bit Linux install) before we can move on to php-pear.
The packages that you'll need are as follows (switch back to 'root' and install them with 'rpm -Uvh package1.rpm package2.rpm ...'):
- php
- php-common
- php-cli
- php-devel
- php-gd (if you use image verification)
- php-mysql (if you use mysql)
- php-pdo (if you use mysql)
Now that you've got PHP 5.2.1, you can move forward with building php-pear. This one is actually very easy and no changes need to be made to the spec file. All you'll need to do is run 'rpmbuild -bb php-pear.spec' as a non-root user from the '/usr/src/redhat/SPECS/' folder and it'll be done about 15 seconds later. The RPM for this one can be found in '/usr/src/redhat/RPMS/noarch/'. Switch back to 'root' and install that RPM as well.
At this point, you're basically done. If you were already running PHP 5.2.0 then you won't need to update or rebuild any 3rd-party modules (such as the Ioncube loaders, XCache, etc.). If you were running an older version of PHP then you should go back and reinstall those extensions. That said, just restart 'httpd' and you should be good to go with PHP 5.2.1.
Update (9/24/2009): Package deleted, use the yum repository instead.
Great tutorial, see you at vb.com 🙂
Glad to hear you like it.
I am new to Linux and have found your information and instructions very useful! Everyone I have tried has worked great. Wanted to say Thanks! Have you writen anything on Qmail or creating src.rpm's? I have searched but haven't found any if you have.
Thanks again
Todd
Sorry, I don't use QMail. I've had some bad experiences with it on some Plesk servers. My mail server of choice is postfix courier-imap.
As to creating your own SRPMS, my suggestion would be to read some of the documentation and then start with something simple. Find (or create) a simple program that only requires a "make" & "make install" to build and install. Once you've created a spec file to accomplish that you can move on to more interesting things like breaking apart a program into multiple packages. You can also learn a lot from examining the spec files for programs with install methods similar to what you want to accomplish.
Jason,
You rock. I had installed everything on a box and had it all working, but needed to do it on two more boxes. The Apache RPM's I had already made when I was looking for a spec file for php and came across your site. I scraped everything and moved over to your code. Thanks so much for taking the time to do this.
Stac...
Thanks for another guide Jason!
Jason, thanks for the great guide.
I have some problem, because I need to enable two additional modules: mcrypt and tidy
So, I added --with-tidy and --with-mcrypt=shared to the configuration lines, but after a while, I get the errors:
Requires(rpmlib): rpmlib(CompressedFileNames)
...continued:
error: Installed (but unpackaged) file(s) found:
/usr/lib/php/modules/mcrypt.so
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/php/modules/mcrypt.so
Thanks Jason, great guide!
Maybe you can help me. Everything works very good for me. I'm also using Apache with Trac and Subversion (with mod_python) and a Mongrel cluster through the proxy_balancer module.
It all functions, but memory keeps leaking. The httpd processes keep multiplying (start at 7 and rise constantly) and worse - the system memory just keeps climbing. It starts at 240Mb (with everything running) and just goes up indefinitely. Summing up the memory by the processes I see doesn't get close to the reported memory usage. Then, the system crashes.
Where might I start looking for the cause of all this?
Much appreciated,
Amir
It could be the way you have it configured and it could be the amount of traffic you're receiving. The prefork MPM needs one process per client so it does tend to be high on the memory usage.
Have you tried enabling the extended status module to see what each process is doing?
Hi Jason,
From mod_status, it looks OK. It's probably not coming at all from the Apache server, but something else I've done. Is it possible that Linux (via 'top' command) is just reporting a lot of used memory, when it's not really used?
Just as a sanity check, this is what I'm getting from mod_status:
Server Version: Apache/2.2.4 (Unix) DAV/2 mod_python/3.3.1 Python/2.3.4 SVN/1.4.3 PHP/5.2.1 mod_perl/2.0.3 Perl/v5.8.5
Thanks again,
Amir
Linux uses spare memory as a disk cache. You can expect to see all of the RAM in your system eventually show as "used" if you are looking in 'top'.
If you want to know how much memory your programs are really using then use the command "free -m". The numbers next to the line starting with "-/ buffers/cache" are what you want. The first is memory in use and the second is free memory (both in MB).
I have a problem using mod_suphp for this php release. Do you have an rpm for the 0.6.2 version?
Sorry, I don't use that package (and therefore will probably not be building it). Have you tried simply rebuilding the suPHP package from source?
That said, it looks like that particular module requires you to run the CGI version of PHP. As a whole, is not a terribly great idea, particularly if your site receives a decent amount of traffic. I would strongly suggest that you find a different way to run your site.
ok no problem, it's working now with the rebuilded package.
Hi. I've been following your blog for a little while although I only just stumbled across your most recent posts regarding your Yum repository. So, firstly thanks for both this blog and the new repository.
Now, my question, do your PHP RPMs support FastCGI? I'll be using your Apache install but mainly for mod_svn (I assume you support this?) and I want to use another web server which requires PHP to be compiled for Fast CGI use.
Any guidance will be apprecaited.
Thanks,
Alex.
Yes, FastCGI should be supported through the 'php-cgi' binary. As to mod_svn, I'm not real familiar with Subversion, but if it uses an httpd module, a binary package created for RHEL4 will NOT work. That said, if you rebuild the src.rpm after installing a newer version of httpd then you should be fine.
Thanks. Subversion (when used with Apache) requires mod_dav. I'll get your apache packages installed and take it from there. If I getit all setup I'll document it somewherefor others to find.
Thanks again,
Alex.
Hi,
I've not actually followed your tutorial yet, but I'd like to point out something that jumped out at me as being "sub optimal". I build a lot of RPMs on Mandriva and generally faff about with RPM all the time so when I saw this:
Once that’s out of the way, make sure that you have a non-root user available for the compilation and that that user has full access to the /usr/src/redhat folder (and everything below it). If you don’t have that folder (meaning that you’ve never built a src.rpm before), create it first. The permissions can be set with the ‘chmod -R 777 /usr/src/redhat’ command or with ‘chown -R username:usergroup /usr/src/redhat’ which is actually the better method (make sure you substitute the actual user name and user group).
i kinda balked!!
This is not needed. This is the space for the root user to build RPMs but users shouldn't really build in here. Users can build where ever they like, it's just a matter of telling rpm about it!
e.g.
[[email protected] ~]$ mkdir rpms
[[email protected] ~]$ cd rpms
[[email protected] rpms]$ mkdir BUILD RPMS SOURCES SPECS SRPMS tmp
[[email protected] rpms]$ cat >~/.rpmmacros
Hmm last reply was cut off:
[[email protected] ~]$ mkdir rpms
[[email protected] ~]$ cd rpms
[[email protected] rpms]$ mkdir BUILD RPMS SOURCES SPECS SRPMS tmp
[[email protected] rpms]$ cat >~/.rpmmacros
%_topdir /home/user/rpms
%_tmppath /home/user/rpms/tmp
CTRL D
[[email protected] rpms]$ rpm -i /path/to/my.src.rpm
[[email protected] rpms]$ cd SPECS
[[email protected] rpms]$ rpm -bb my.spec
etc.
Hope that helps for future tutorials 🙂
Thanks for the input. I build my RPMs in /usr/src/redhat (as I recommended in the tutorial) because I NEVER build RPMs as root. In my opinion, if you can't build a package as a non-root user, you shouldn't be building it at all.
That said, I don't believe that there is really anything wrong with either approach as long as you are comfortable with what you are doing. Knowing that many people aren't comfortable with compiling their own software is one of the reasons I made my yum repository public.
The only difference is that "rpm -qV rpm-build" will report that files belonging to a package have been altered etc. in automated tests which may just clog up automated error/warning reports that may be run.... I prefer to keep files/directories owned by packages in their original form unless they are marked as config files in the SPEC. Just my preference tho'.
That's a good point, I'll give it a try your way and see if that affects my build process. If not, I'll write it up differently from now on. Thanks again for your input.
Thanks for the detailed steps here. FYI : I was concerned about the issues raised by the Month of PHP Bugs project and found some patches in the OpenSuSE bleeding edge packages, as well as the suhosin patch. I put together an article on how to get them installed in CentOS at my weblog above. I am running them on a test server right now with eGroupware and it seems to be working so far.
I'll take a look at your site, thanks.
hi,
thanks for giving the options to install php upgradation documents here. as i am following your steps mentioned here. But am encountering the following error.Please help me to solve this problem. when i issue as a non -root privilleges am getting this error. Am not able to find any php rpm inside the "/usr/src/redhat" folder.
rpmbuild -bb php.spec
cat: /usr/include/httpd/.mmn: No such file or directory
error: Failed build dependencies:
aspell-devel >= 0.50.0 is needed by php-5.2.1-1.i386
httpd-devel >= 2.0.46-1 is needed by php-5.2.1-1.i386
libjpeg-devel is needed by php-5.2.1-1.i386
libpng-devel is needed by php-5.2.1-1.i386
sqlite-devel >= 3.0.0 is needed by php-5.2.1-1.i386
pcre-devel >= 4.5 is needed by php-5.2.1-1.i386
libc-client-devel is needed by php-5.2.1-1.i386
postgresql-devel is needed by php-5.2.1-1.i386
unixODBC-devel is needed by php-5.2.1-1.i386
net-snmp-devel is needed by php-5.2.1-1.i386
libxslt-devel >= 1.0.18-1 is needed by php-5.2.1-1.i386
gd-devel is needed by php-5.2.1-1.i386
freetype-devel is needed by php-5.2.1-1.i386
i had to remove php and php-common before this would allow me to install:
$ yum remove php
$ yum remove php-common
$ rpm -Uvh php-5.2.1-[ ... ]
Thirupathy,
You can't build a program until you've filled all of the dependencies. You'll need to install all of those "-devel" packages before you can build from source. Alternatively, you can simply use teh binary packages out of my Yum repo.
Matt Dennewitz,
What error were you given when you tried to upgrade without removing those packages?
Hi Jason,
Great guide, I am very close to getting it working but it's crapping out on the SNMP part of the SRPM build.
Did you have to use a different version of net-snmp when you built your rpm?
I am running CentOS 4.4 I considered your yum repository, but I have to use the stock version of httpd that came with centos.
checking for SNMP support... yes, shared
checking OpenSSL dir for SNMP... no
checking for snmp_parse_oid in -lnetsnmp... no
checking for init_snmp in -lnetsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for more information.
error: Bad exit status from /var/tmp/rpm-tmp.83959 (%build)
In the config log it lists this as the problem:
configure:107611: checking for SNMP support
configure:107650: result: yes, shared
configure:107658: checking OpenSSL dir for SNMP
configure:107676: result: no
configure:109207: checking for snmp_parse_oid in -lnetsnmp
configure:109237: gcc -o conftest -L/usr/lib -L/usr/lib -L/usr/kerberos/lib -lnetsnmp -lcrypto -lelf -lm conftest.c -lnetsnmp -lhistory -lreadline -lncurses -laspell -lpspell -lgmp -ldb-4.2 -lcurl -lbz2 -lz -lpcre -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -ldl -lz -lcurl -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -ldl -lz -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -lidn -lssl -lcrypto -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -ldl -lz -lz -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -ldl -lz -lxml2 -lz -lm >&5
/usr/bin/ld: cannot find -lnetsnmp
I've got 5.1.2-11.EL4.7 installed of net-snmp, net-snmp-devel, and net-snmp-libs.
hmm, that's weird I have a different verion of the devel package:
net-snmp-5.2.1.2-2.el4
net-snmp-devel-5.1.2-11.EL4.7
That's probably what the problem is.
Thanks,
Tony
AM Software Design
http://www.amsoftwaredesign.com
Home of Lightning Admin for PostgreSQL and MySQL
Hi Jason,
I got it compiled and working perfectly.
Thank you so much for this guide. You should contact the Centos people and see if you can get your work in the CentOSPlus repository.
In case anyone else is having issues with SNMP, make sure you have lm_sensors and net-snmp-libs, they were not showing on my system as dependencies and I only found out I was missing them when I tried to downgrade my net-snmp to the same version as net-snmp-devel.
For whatever reason I had a different version of the devel package and that was causing issues with the dependencies.
On another note:
Jason, do you use PostgreSQL at all? If so would you be interested in doing a review of Lighting Admin?
Tony
AM Software Design
http://www.amsoftwaredesign.com
Home of Lightning Admin for PostgreSQL and MySQL
Sorry, no, I don't generally use PostgreSQL. About 90% of the DB-driven applications I work with run from MySQL and the other 10% on Microsoft SQL Server.
Hi Jason,
I have another question for you...
5.2 is supposed to have a built in extension for upload progress bar hooks, but after I built the source RPM the uploadprogress.so is not in the modules directory.
Any idea?
Thanks,
Tony
P.S.
I also have a MySQL version of Lightning Admin, would you be interested in doing a review of that on your site? Reviewers of course get a commercial copy for no charge.
In order to get progress data for file uploads you need to install the pecl extension "uploadprogress". You can do that by running the command "pecl install uploadprogress". Once you've done that, you'll need to edit your php.ini to load the extension. Finally, you'll need to create a hidden form element called "UPLOAD_IDENTIFIER" so that your progress calls know which upload to track.
As to reviewing a copy of your software, If you'd like, email me at jasonlitka AT verizon.net and we can talk some more.