Changing Command Line Version Of Php For Apache
I have updated php on a CentOS 7 system to use php 7.2 from sclo. Apache running on the system is also using php 7.2 as shown by phpinfo(), however, apache continues to use the default version of php, ie 5.4.16, when that user launches a process from the command line. All other users default to php 7.2 when running from the command line which is correct. For some reason I have missed configuring apache php-cli correctly.
I have googled and found many examples on how to change the configuration settings so that apache uses php 7.2 when serving web pages but in this case it is php-cli that needs to be corrected to use a later version.
What should I check? What have I missed? By the way, I am not planning to remove php 5.4 from the system since it might be needed for something at a later time.
Thanks.
8 thoughts on - Changing Command Line Version Of Php For Apache
Am 13.02.21 um 21:59 schrieb H:
Check SCL docs:
https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/html/packaging_guide/sect-enabling_the_software_collection#sect-Running_an_Application_Directly
CLI:
scl enable rh-php72 yourcmd
Am 13.02.21 um 21:59 schrieb H:
Docs:
https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/html/packaging_guide/sect-enabling_the_software_collection#sect-Running_an_Application_Directly
CLI:
scl enable rh-php72 yourcmd
But apache does not have a shell where I issue that command? And, a change needs to survive a reboot.
Perhaps it might help if you explained how the Apache user is running the commands? Cron job? Systemd service? The “scl” commands are used to run the alternative PHP, so how you run it is important.
—
Jonathan Billings
I have two situations I believe:
The first is apache launching cron jobs and an hour or so I remedied the issue by explicitly specifying the location of the php 7.2 binary in the cronedit file. This now works.
The second is that I am having problems with the webapp not being able to retrieve e-mail from an external e-mail account. I can view sent e-mails in the external e-mail account from the webapp (which I believe uses php SMTP module) but am unable to retrieve inbox/draft/archive e-mails which require imap ssl and thus port 993. I am still trying to figure out why this is and if the webapp might kick off a php script doing this (rather than just running code in the app itself).
But my question is also a more general one: short of ridding the system of the old, default php 5 binary, how should I configure a user without a shell such as apache to default to the newer php binary? As mentioned previously, apache itself runs the new php just fine (except for the imap issue above which could also be some other bug…).
Also, as mentioned before, all users with a shell on this system already default to the new php binary so it is only users without shells that I have to figure out how to configure.
I would appreciate your thoughts.
–CentOS 7 runs apache from systemd. Apache finds programs using the path. So you need to customize the systemd unit file for Apache to run it from within a script that first prefixes the path with the location of your custom PHP binary. Software Collections provides a script for this.
See the systemd documentation for how to customize a unit file. You probably just need a “drop-in” in /etc/systemd/system that replaces the ExecStart value in httpd.service.
Another approach is to run php-fpm for your custom PHP (package rh-php72-php-fpm) and have Apache connect to this via the SetHandler directive. Use SetHandler instead of ProxyPass because the latter doesn’t play well with FilesMatch.
# send PHP requests to PHP 7.2 via php-fpm service
SetHandler “proxy:fcgi://127.0.0.1:9000”
This will sandbox PHP into its own process.
Thank you, I did not know that! I will take a look at this.
Apart from what you described above, is it in general possible to force a non-shell user to use a specific version of software when multiple versions are installed on a machine, be it php, python or something else?
–As I said, use the path. The path environment variable isn’t part of a shell, but shells provide nice ways to manipulate it. The scripts provided with Software Collections modify the path and possibly other variables before invoking a shell or a program. Environment variables are part of a process’ state and are inherited when a process spawns a child. A shell is just a special kind of process that provides interactive support and may provide a programming API.