1

Is there any kind of "official" repo for upgrading PHP beyond the stock PHP 5.3.3 found in CentOS 6.7?

I'm trying to utilize the SCL repo's, but finding all sorts of peculiarities that seem to point back to this dual PHP install method.

When using the SCL repo's, you have multiple versions of PHP installed. The base package, PHP 5.3.3 in this case, sits in all of the usual RH locations such as /usr/bin/php. The SCL version, let's pick on 5.4 for now, get installed as php54-php and sits in /opt/rh/php54/. Then you tell Apache which one to run via what php config is active in /etc/http/config.d/. However, when running php-cli, you have to declare the php54 version with either a source command for a shell, or a scl enable command for things like cron or sudo jobs. If you don't, it defaults to the the 5.3.3 install.

Peculiarities are things like trying to get the cron job to fire correctly. Using WP-CLI, because cURL/wget/PHP calls are returning invalid username/password error, looks like it runs the jobs but doesn't seem to be doing things like smartgroup rebuilds. Running the cron jobs manually from the Settings page works fine.

  • I feel that this was an erroneous migration. This is specific to CiviCRM on WordPress, not a general Unix/Linux question. CentOS repos are listed at: wiki.centos.org/AdditionalResources/Repositories – G H Feb 11 '16 at 16:34
  • civicrm.stackexchange.com/q/9596/149 - related over on CiviCRM.SE. Can you expand this answer to describe the issues/peculiarities you're having, and what you're referring to with "dual PHP install method"? – Chris Burgess Feb 11 '16 at 17:24
  • When using the SCL repo's, you have multiple versions of PHP installed. The base package, PHP 5.3.3 in this case, sits in all of the usual RH locations such as /usr/bin/php. The SCL version, let's pick on 5.4 for now, get installed as php54-php and sits in /opt/rh/php54/. Then you tell Apache which one to run via what php config is active in /etc/http/config.d/. However, when running php-cli, you have to declare the php54 version with either a source command for a shell, or a scl enable command for things like cron or sudo jobs. If you don't, it defaults to the the 5.3.3 install. – G H Feb 11 '16 at 17:33
  • Peculiarities are things like trying to get the cron job to fire correctly. Using WP-CLI, because cURL/wget/PHP calls are returning invalid username/password error, looks like it runs the jobs but doesn't seem to be doing things like smartgroup rebuilds. Running the cron jobs manually from the Settings page works fine. – G H Feb 11 '16 at 18:12
  • If curl is giving "invalid user/pass" errors, then check the user/pass on the CLI are correct to permit you to access the CiviCRM interface. That is a question suited for civicrm.stackexchange.com (sorry to bounce you around!) – Chris Burgess Feb 11 '16 at 18:30
0

N.B: I don't use CentOS or RHEL distros myself, but have in the (distant) past.

According to https://www.softwarecollections.org/en/scls/rhscl/rh-php56/, it looks like the scl enable command is what you need.

When PHP5.4 is installed in /opt/rh/php54 and PHP5.3 in /usr/bin/php, you need to configure your system environment to select the more recent PHP. This is configured using environment variables like $PATH.

Since CiviCRM has scheduled tasks which need to be run as the webserver user, you will need to ensure that this change is made for the account the tasks run as. If this is a machine dedicated to hosting CiviCRM then updating the preferred PHP for all users seems the sensible route. If other users might be affected negatively by the change, you would make your changes more specific.

Running scl enable php54 will do this, so that command can be added to /etc/bashrc (systemwide) or ~/.bashrc (per-user).

You also can configure your system path in /etc/profile and /etc/profile.d or ~/.bash_profile. If it exists on CentOS, system paths may be determined by adding entries to /etc/paths.d also. (I'm not sure if running scl enable php54 will only change your $PATH - if not then this may not be a complete solution.)

If you have commandline PHP scripts which specify the full path to the old PHP by starting with #!/usr/bin/php, those will need to be modified to use the path of your preferred PHP installation (or replace with #!/usr/bin/env php as seen in CiviCRM's codebase. The same will apply if there are cron entries which specify the full path to PHP5.3.

  • I'm doing the scl enable commands on cron and sudo commands, and I've got the /etc/profile.d stuff in place. I haven't figured out how to correctly do the $path thing yet, but have spent significant time trying to do so. After all, not having /usr/bin in the path seems, um, counter-productive?, and I haven't found an "export PHP_PATH" kind of line yet. – G H Feb 11 '16 at 18:49
  • export PATH=/opt/foo/bin:$PATH – Chris Burgess Feb 11 '16 at 18:57
  • Which is to say: prepend, don't replace – Chris Burgess Feb 11 '16 at 18:57
  • GRRR. Copy and paste ate my path! Fixed it. So yeah, done, but isn't that a per user command? 'sudo -u apache which php' still shows /usr/bin/php, not /opt/rh/blah/blah/blah – G H Feb 11 '16 at 19:19
  • Per-user or system wide is determined by whether you applied the changes in the user's homedir (eg /home/gh) or a system dir (eg /etc). If you want user apache to pick it up, you probably want to apply it system-wide. I recommend testing that the scl command in your cron is working as you expect; try adding a second task which prints the output of php -v to confirm this. Once you confirm the right PHP version is output, you can move on to the next part. – Chris Burgess Feb 11 '16 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.