Plesk 8.3.0 and PHP 5.2.5 (and auto update)
Plesk 8.3.0 and PHP 5.2.5 (and auto update)
Yesterday I used the atomic installer which added the ART repositories to my server (which was running Plesk 8.2.1 and PHP 5.2.1). Also I answered "yes" to the question "install Plesk repository".
I didn't realize that Plesk had a cron job to run yum update every morning so today I got a million updates of everything.
My first question is, "is this a good thing, is this the way most people have their servers set?" I'm generally one who doesn't like updates happening without my say so, and I figure most server admins are probably the same. So should I delete this cron job?
I also notice that Plesk updated to 8.3.0 and PHP updated to 5.2.5.
My PCI compliance was failing because of PHP vulnerabilities in 5.2.X < 5 so I have been reading here about the upgrade issues with 5.2.5 and "php_admin_value". But Scott has said on a couple of occasions that Plesk 8.3.0 was fixing that, but then there were issues with 8.3.0.
So my second question is, "is this upgrade ok now? Are there still issues needing to be resolved? Do I need to go change all php_admin_values?"
I didn't realize that Plesk had a cron job to run yum update every morning so today I got a million updates of everything.
My first question is, "is this a good thing, is this the way most people have their servers set?" I'm generally one who doesn't like updates happening without my say so, and I figure most server admins are probably the same. So should I delete this cron job?
I also notice that Plesk updated to 8.3.0 and PHP updated to 5.2.5.
My PCI compliance was failing because of PHP vulnerabilities in 5.2.X < 5 so I have been reading here about the upgrade issues with 5.2.5 and "php_admin_value". But Scott has said on a couple of occasions that Plesk 8.3.0 was fixing that, but then there were issues with 8.3.0.
So my second question is, "is this upgrade ok now? Are there still issues needing to be resolved? Do I need to go change all php_admin_values?"
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
Lots of questions here, so in no particular order:
1) Your PCI compliance tests were probably wrong anyway. Theyre looking at the banners from your server which is the least accurate way of measuring a vulnerability on the server. The scanner they are using (probably nessus) even tells them that. This has to do with redhats backport policy, they will correct a vulnerability in older versions of software.
2) I autoupdate via cron, and Im OK with that
3) the php_admin_value changes are something you should be concerned with if you have made changes in either vhost.conf, an htaccess file, or your PHP code uses it. If you dont then you probably wont even notice it.Also, dont forget to update any extentions you installed from source (ioncube, eaccellerator, zend, etc).
1) Your PCI compliance tests were probably wrong anyway. Theyre looking at the banners from your server which is the least accurate way of measuring a vulnerability on the server. The scanner they are using (probably nessus) even tells them that. This has to do with redhats backport policy, they will correct a vulnerability in older versions of software.
2) I autoupdate via cron, and Im OK with that
3) the php_admin_value changes are something you should be concerned with if you have made changes in either vhost.conf, an htaccess file, or your PHP code uses it. If you dont then you probably wont even notice it.Also, dont forget to update any extentions you installed from source (ioncube, eaccellerator, zend, etc).
Thanks Scott. You're a real help here. An Amazing one actually. I don't know how you ever get any work done! ;)
I know what you mean about PCI scanners. They often give FAIL errors with messages like "this MAY mean..."! Yeah, well, it MAY NOT, too! If you can't tell for sure how can you FAIL?!
Anyway, that being said, on to the real issue, I HAVE made extensive changes to the vhost.conf file, in particular, open_basedir and setup for running AWSTATS dynamically. After a couple days of running though I have seen no problems, so does that mean the php_admin_value is resolved in the 8.3.0<->5.2.5 scenario?
I did NOT do any compiling of my own so I have added no extensions manually. HOWEVER, since the update I am now getting regular messages in the error log:
Failed loading /usr/lib/php/modules//php_ioncube_loader_lin_5.1.so: /usr/lib/php/modules//php_ioncube_loader_lin_5.1.so: undefined symbol: zend_unmangle_property_name_ex
Do you know what caused this and how I can repair?
Thanks again!
I know what you mean about PCI scanners. They often give FAIL errors with messages like "this MAY mean..."! Yeah, well, it MAY NOT, too! If you can't tell for sure how can you FAIL?!
Anyway, that being said, on to the real issue, I HAVE made extensive changes to the vhost.conf file, in particular, open_basedir and setup for running AWSTATS dynamically. After a couple days of running though I have seen no problems, so does that mean the php_admin_value is resolved in the 8.3.0<->5.2.5 scenario?
I did NOT do any compiling of my own so I have added no extensions manually. HOWEVER, since the update I am now getting regular messages in the error log:
Failed loading /usr/lib/php/modules//php_ioncube_loader_lin_5.1.so: /usr/lib/php/modules//php_ioncube_loader_lin_5.1.so: undefined symbol: zend_unmangle_property_name_ex
Do you know what caused this and how I can repair?
Thanks again!
This was just base installation of my Plesk 8.2.1 RHEL5 server. I installed no RPMs before the auto upgrade to 8.3.0 and PHP 5.2.5.
Here's what yum says:
php-xml.i386 5.2.5-4.el5.art installed
php5-ioncube-loader.i386 3.1-07051711 installed
php5-ioncube-php52.i386 4.0-rhas5.07042717 installed
So you can see some ART php stuff was installed, but its not clear where the ioncube stuff came from.
Here's what yum says:
php-xml.i386 5.2.5-4.el5.art installed
php5-ioncube-loader.i386 3.1-07051711 installed
php5-ioncube-php52.i386 4.0-rhas5.07042717 installed
So you can see some ART php stuff was installed, but its not clear where the ioncube stuff came from.
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
php-xml is mine, the others are not. You can use rpm -qi <packagename> to get info on the source of package. You'd have to look at what comprises those packages (rpm -ql <packagename>) to see if they have the right libraries. My guess is that they don't, but you never know.
Assuming they dont, try removing them and installing the ones from the atomic archive.
Assuming they dont, try removing them and installing the ones from the atomic archive.
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
The other two look like they're installed as part of Plesk's SiteBuilder. Those are not used by regular PHP sites AFAIK.
Edit: gee, this was my 1Kth post.
Edit: gee, this was my 1Kth post.
Lemonbit Internet Dedicated Server Management
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
Re: Plesk 8.3.0 and PHP 5.2.5 (and auto update)
AFAIK Plesk does not setup a cron job to run yum update for you.rwhirn wrote:I didn't realize that Plesk had a cron job to run yum update every morning so today I got a million updates of everything.
I like to run yum manually, but I guess that's entirely a matter of taste. I you like it, keep it and if you don't, get rid of it. Keeping your systems up to date is important, how you accomplish that is up to you I guess.My first question is, "is this a good thing, is this the way most people have their servers set?" I'm generally one who doesn't like updates happening without my say so, and I figure most server admins are probably the same. So should I delete this cron job?
Lemonbit Internet Dedicated Server Management