Multiple PHP Versions in Plesk 12.0 Out of the Box!

[tkalfaoglu]

It seems if you select FastCGI + another version of PHP in a PLAN, this specification is not used when you apply that plan to a domain.
That is, the domain ends up with Apache Module + regular PHP version instead.

..Confirmed just now.. Indeed the php version and module to use is IGNORED in plans.

 

[tkalfaoglu]

How do we edit the php.ini that is copied to the /var/www/vhosts/system/domain.com/etc folder?
I mean, where does its source come from?

I made changes to /opt/plesk/php/5.3/etc/php.ini, but when I issued an
# php_management_tool move --to=plesk-php53-fastcgi --domains=domain.com
the php.ini that is placed at the /var/www/vhosts/system/domain.com/etc was the default php.ini for 5.3, NOT the one I customized.

 

[iainh]

Hi again UFHH01

So ran bootstrapper.sh as per your suggestion. I then lost my net connection and so didn't get to see all the output. Reconnecting I attempted to re-run and was warned about not running two bootstrapper processes simultaniously so left for a while. Then checked via ps that bootstrapper was finished. Presuming this is a check and update, there seems no issue in re-running and so I ran bootstrapper again intending to capture the output. I noted I was not given the warning about a running process indicating the first process had completed okay and released its lock, however, I then realised I should have piped the output as the scrpt generates *a lot* of output and so I ran a third time, this time piping the output. Execution third time around was a lot quicker than previously if that is an indication of anything?

I was also checking in Home > Service Plans > Hosting parameters and still only had one option, 5.3.3, and then I thought I'd see if the php versions were offered to me differently if I switched from running php as an Apache module to a Fast CGI ap, and voila:



Note how this differs to:



So the only issue now is the increased memory footprint of running php as a Fast CGI although there are other benefits of configuring things this way.

So I presume this 'sorts' the issue? Is it not possible to run 'added-on' php versions as Apache modules in the same way the default CentOS bundled copy?

 

[iainh]

It seems if you select FastCGI + another version of PHP in a PLAN, this specification is not used when you apply that plan to a domain.
That is, the domain ends up with Apache Module + regular PHP version instead.

..Confirmed just now.. Indeed the php version and module to use is IGNORED in plans.

Oh...so looks like I'm not out of the woods yet. Haven't got as far as building a new Service plan using one of the newer php versions :-(

 

[UFHH01]

Hi iainh,

please be aware that there is a normal rights/permission/setting structure and each child in the structure inherits the settings and configurations - a quite "normal" way.

 

[iainh]

@tkalfaoglu, you are quite right. What I have tried is:

1. Cloned a plan and via 'Hosting Parameters' set php as FastCGI, version php 5.4 and named as 'php 5.4'
   
2. Cloned the php 5.4 plan and changed php to FastCGI (unchanged) and selected php 5.5 and named as 'php 5.5'
   
3. And cloned again, set to php 5.6 and named as 'php 5.6'
4. Selected a domain, sadly discovering you can't set Plans by sub-domain as I'd planned to create php54.example.com, php55.example.com and php56.example.com and set names in my hosts file (rather than create in DNS)
   
5. Loaded a small script that echoed phpVersion() to the domain docroot
6. Altered the domain plan to 'php54' and restarted Apache
7. Ctrl+F5 on the phpVersion and still sat as 5.3.3
8. Altered the domain to 'php55' and restarted Apache
9. Guess what Ctrl+F5 showed? - 5.3.3
10. Altered the domain to the 'php56' plan and restarted Apache
11. You don't need me to tell you what Ctrl+F5 gave...5.3.3
12. Restarted complete server at the OS
13. Ctrl+F5 continues to show php 5.3.3 so exactly as you say, the php version defined in the Service Plan is entitely ignored and you just start on the default CentOS 5.3.3 build

@UFHH01, any suggestions now? php 5.4, 5.5 and 5.6 are all showing as installed, I have plans defining the use of each, but assigning any of these Service Plans to a domain/subscription has no effect, just as @tkalfaoglu reports

 

[iainh]

The plot thinckens. Going to take a look at the contents of the php.ini @tkalfaoglu mentioned to see what was being written to it (or not!), I thought I'd check yum while I was there. yum check-updates suggested a few pieces including a kernal update and so my thinking was it would be worth doing a yum update while on the box.

yum update however, created a very different picture with a *HUGE* dependency list (output attached) before finally deciding it wasn't going to go further due to:

--> Finished Dependency Resolution
Error: Package: plesk-php55-imagick-3.1.2-centos6.15061117.x86_64 (@PHP_5_5_26-dist)
Requires: libMagickCore.so.2()(64bit)
Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@updates/6.5)
libMagickCore.so.2()(64bit)
Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base)
Not found
Error: Package: plesk-php54-imagick-3.1.2-centos6.15061118.x86_64 (@PHP_5_4_42-dist)
Requires: libMagickWand.so.2()(64bit)
Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@updates/6.5)
libMagickWand.so.2()(64bit)
Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base)
Not found
Error: Package: plesk-php55-imagick-3.1.2-centos6.15061117.x86_64 (@PHP_5_5_26-dist)
Requires: libMagickWand.so.2()(64bit)
Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@updates/6.5)
libMagickWand.so.2()(64bit)
Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base)
Not found
Error: Package: plesk-php56-imagick-3.1.2-centos6.15061116.x86_64 (@PHP_5_6_10-dist)
Requires: libMagickCore.so.2()(64bit)
Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@updates/6.5)
libMagickCore.so.2()(64bit)
Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base)
Not found
Error: Package: plesk-php54-imagick-3.1.2-centos6.15061118.x86_64 (@PHP_5_4_42-dist)
Requires: lagickCore.so.2()(64bit)
Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@updates/6.5)
libMagickCore.so.2()(64bit)
Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base)
Not found
Error: Package: plesk-php56-imagick-3.1.2-centos6.15061116.x86_64 (@PHP_5_6_10-dist)
Requires: libMagickWand.so.2()(64bit)
Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@updates/6.5)
libMagickWand.so.2()(64bit)
Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base)
Not found
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

So:

1. Is there a clue here to why the Plesk installed php 5.4, 5.5 and 5.6 are not working
2. yum is in essense broken. Yes I can break dependancies, but that brings issues with it so I'd prefer not to go there

So the Plesk-installed php updates not only don't work when configured via a Service Plan, they also seem to break yum which is a bit of an issue.

@UFHH01, any advice on where-to next?

 

[iainh]

How do we edit the php.ini that is copied to the /var/www/vhosts/system/domain.com/etc folder?
I mean, where does its source come from?

Looking at my own VPS, the only /var/www/vhosts/system/domain.com/etc/ php.ini files I can find belong to Drupal-based sites. Other sites lack this and so I suspect the answer to your question is that these files are being generated by Drupal...at least based on what I can see from my own VPS

 

[UFHH01]

Hi iainh,

for the "ImageMagic" - issue... please just be patient. Odin Team is working on this issue for its packages and has as well a solution at the Odin - Knowledge Base :

Hi all,

We published a KB article with workaround for this issue:

http://kb.odin.com/en/126493

Problem has been reported to Plesk Service Team for deeper investigation and permanent resolution.

... since some vendors decided to use some corrupt / misconfigured ImageMagic packages, with some missiong *.so" 's. You might read the thread "Plesk update fails due to ImageMagick dependencies" for further informations to that.

Looking at my own VPS, the only /var/www/vhosts/system/domain.com/etc/ php.ini files I can find belong to Drupal-based sites. Other sites lack this and so I suspect the answer to your question is that these files are being generated by Drupal...at least based on what I can see from my own VPS

How do we edit the php.ini that is copied to the /var/www/vhosts/system/domain.com/etc folder?
I mean, where does its source come from?

The source is the standard system PHP.ini from "/etc/php5/cli/php.ini" .

 

[PleskWebmaster]

I was trying to load an application and the app said I needed PHP 5.6, So I added it as an available version in Plesk and went on my way... until I saw that it was still not working. I saw the notice said I needed a newer version of ImageMagick for PHP 5.6 to work correctly. Fine, I went to update and this is what I get:

[root@server][~/]# /usr/bin/yum update ImageMagick
Loaded plugins: fastestmirror
Setting up Update Process
Determining fastest mirrors
base | 3.7 kB 00:00
base/primary_db | 4.6 MB 00:00
elrepo-kernel | 2.9 kB 00:00
elrepo-kernel/primary_db | 20 kB 00:00
extras | 3.4 kB 00:00
extras/primary_db | 26 kB 00:00
plesk-php-5.3 | 2.9 kB 00:00
plesk-php-5.3/primary_db | 14 kB 00:00
plesk-php-5.4 | 2.9 kB 00:00
plesk-php-5.4/primary_db | 14 kB 00:00
plesk-php-5.5 | 2.9 kB 00:00
plesk-php-5.5/primary_db | 14 kB 00:00
plesk-php-5.6 | 2.9 kB 00:00
plesk-php-5.6/primary_db | 14 kB 00:00
updates | 3.4 kB 00:00
updates/primary_db | 770 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package ImageMagick.x86_64 0:6.5.4.7-7.el6_5 will be updated
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php55-imagick-3.1.2-centos6.15061117.x86_64
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php54-imagick-3.1.2-centos6.15061118.x86_64
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php53-imagick-3.1.2-centos6.15061118.x86_64
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php56-imagick-3.1.2-centos6.15061116.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php55-imagick-3.1.2-centos6.15061117.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php54-imagick-3.1.2-centos6.15061118.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php53-imagick-3.1.2-centos6.15061118.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php56-imagick-3.1.2-centos6.15061116.x86_64
---> Package ImageMagick.x86_64 0:6.7.2.7-2.el6 will be an update
--> Processing Dependency: libwmf-0.2.so.7()(64bit) for package: ImageMagick-6.7.2.7-2.el6.x86_64
--> Running transaction check
---> Package ImageMagick.x86_64 0:6.5.4.7-7.el6_5 will be updated
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php55-imagick-3.1.2-centos6.15061117.x86_64
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php54-imagick-3.1.2-centos6.15061118.x86_64
--> Processing Dependency: libMagickCore.so.2()(64bit) for package: plesk-php56-imagick-3.1.2-centos6.15061116.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php55-imagick-3.1.2-centos6.15061117.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php54-imagick-3.1.2-centos6.15061118.x86_64
--> Processing Dependency: libMagickWand.so.2()(64bit) for package: plesk-php56-imagick-3.1.2-centos6.15061116.x86_64
---> Package libwmf.x86_64 0:0.2.8.4-23.el6 will be installed
---> Package plesk-php53-imagick.x86_64 0:3.1.2-centos6.15061118 will be updated
---> Package plesk-php53-imagick.x86_64 0:3.1.2-centos6.15081014 will be an update
--> Finished Dependency Resolution
[root@server][~/]#

I am guessing this is related to the "ImageMagic issue" that the Odin Team is working on?

Being patient, but just making sure.

 

[UFHH01]

I am guessing this is related to the "ImageMagic issue" that the Odin Team is working on?

Yes, it is. You could read the other "Imagick" - threads, to see suggestions and work-arounds from the last days, untill Odin finds a way to support all ( strange ) CentOS - systems.


I still recommend for unexperienced server administrators to use Ubuntu - servers..... but this is only MY opinion and has got nothing to do with the thread. ^^

 

[Juuk]

FYI http://autoinstall.plesk.com/PHP_5.6.12/dist-rpm-CentOS-6-x86_64/extra/plesk-php56-devel-5.6.12-centos6.15081013.x86_64.rpm is available too!

 

[iainh]

Well I've just had a yum update run through to completion. But it's a BIG update, but clearly someone has been working on something as I no longer had the Imagick dependancy issues

 

[IgorG]

This article may be useful for you - http://devblog.plesk.com/2015/08/adding-custom-php-modules-in-plesk/

 

[iainh]

Thanks @Igor

 

[iainh]

I'm on Plesk 12.0.18 Update #60 having updated from 11.5 I think, being the ISP standard build. I have Plesk to automatically apply updates, so does this imply 12.5 is considered bleeding edge (early adopter) and will come into the automated update process once considered general release? Thx

 

[Timo002]

When I change the php version from 5.4 to 5.6.12, phpinfo() is showing version 5.6.12. But when I enter 'php -v' from commandline, I get 5.4 returned!

How do I update the cli php version?

Running CentOs 7 and Plesk 12

 

[UFHH01]

Hi Timo002,

to update your PHP version on CentOS 7, you could take a look at for example:

https://www.mojowill.com/geek/howto-install-php-5-4-5-5-or-5-6-on-centos-6-and-centos-7/ ( external link, please inform me, if the link goes dead, so I can replace it with another one )​

You could find several other tutorials, when searching with Google for example. Please be reminded, that using the "webtactic repo" for example is not recommended, because it may conflict with names at "CentOS base" and "CentOS updates" - repos.

 

[vlikhtanskiy]

Hi @Timo002!

You can check which PHP cli is used using:
# which php

And you can find out path to PHP cli of installed php versions:
# plesk bin php_handler --list

 

[Timo002]

@UFHH01, @vlikhtanskiy

I managed it to get it working with the link UFHH01 mentioned. However, now I can't access the MySQL database remotely. To be honest, I did not check it before updating, so I don't know if it didn't work before. But as far as I can see the firewall rules allow incoming connections and the database user settings are also right.