Running newer applications on CentOS


Although the standard answer for additional software for CentOS/RHEL is EPEL, the EPEL policies don't permit replacing any base packages and the lack of guidelines for SCL (Software Collections) that have passed the FPC (Fedora Packaging Committee) prevents making use of these in EPEL.

There are three primary places worth visiting to handle this, each with their own pros and cons to take into account.

  • The IUS Community Repo which is sponsored by Rackspace and used by their customers.
  • The CentOS SCL SIG which rebuilds the Red Hat Software Collections and also provides some additional ones of their own. The SIG provides more detailed information on tha Software Collections site. If looking at the Software Collections site pay special attention to who 'owns' a given collection as it's a superset of the SIG collections (including the RHSCL rebuilds) and user contributed ones.
  • Remi Collet's repositories which focus on PHP only and has different methods of use depending on requirements.

We'll explore each of these options and how to use them in order to get an understanding of their different strengths and weaknesses to best fit a given set of requirements.

IUS Community Repo

IUS take the position that they should not be overriding any base packages and that the packages they install should follow the standard filesystem locations. They will generally name their packages differently but use a provides so that they can fulfill any dependency requirements. They describe their position in more detail on their Safe Repo inititiave page and their view of how they compare to SCL as well.

This does mean that it's generally safe to enable on systems without having to worry about adding include/exclude filters in the yum configuration. It also means that for most things updating to a new version is a matter of replacing the existing package (if installed) using yum swap/replace or yum shell techniques or calling the name of the new one, with no changes to where configuration is located etc in the Configuration Management engine of choice. IUS also covers much more than just PHP with python, and MariaDB packages as well.

The downsides to be aware of with IUS are that due to the way they provide the base version it is important to install the main package prior to installing any packages depending on it. For instance, php should be installed before any php modules. An example of this conflict issue can be seen here . In addition since IUS follow the upstream support policy it's important to be aware of when something like PHP5.5 upstream support ends and a migration is required to PHP5.6, with similar situations on the other packages. This may result in more frequent testing than otherwise required on a Red Hat SCL set up. To assist with this there is a GitHub issues 'list' that IUS have put in place to track the EOL notices and should be watched for notifications.

Enabling IUS for CentOS is trivial:

# CentOS6
yum install
# CentOS7
yum install

That's all it takes as the EPEL repo requirement is fulfilled by the CentOS Extras repo which is enabled by default. On RHEL the EPEL repo will need to be specifically enabled as well, though if on really RHEL it's important to include the support situation as Red Hat formally support their SCL repo when evaluating the best choice for the environment.

With the repo in place use yum to check the packages available for the application/language in question and then pick the version (IUS uses a 'u' suffix) that is required, then carry on installing the rest of the stuff needed:

yum --disablerepo="*" --enablerepo="ius" list all
httpd24u-debuginfo.x86_64                               2.4.20-1.ius.centos6                          ius            
httpd24u-tools.x86_64                                   2.4.20-1.ius.centos6                          ius            
libmemcached10.x86_64                                   1.0.16-1.ius.centos6                          ius            
libmemcached10-debuginfo.x86_64                         1.0.16-1.ius.centos6                          ius            
libmemcached10-devel.x86_64                             1.0.16-1.ius.centos6                          ius            
mod24u_ldap.x86_64                                      2.4.20-1.ius.centos6                          ius            
mod24u_ssl.x86_64                                       1:2.4.20-1.ius.centos6                        ius            
mod_php70u.x86_64                                       7.0.6-1.ius.centos6                           ius            
mysql55.x86_64                                          5.5.49-1.ius.centos6                          ius            
mysql55-bench.x86_64                                    5.5.49-1.ius.centos6                          ius            
mysql56u-debuginfo.x86_64                               5.6.30-1.ius.centos6                          ius            
mysql56u-devel.x86_64                                   5.6.30-1.ius.centos6                          ius 

yum search php
php-zetacomponents-console-tools.noarch : Zeta ConsoleTools Component
php55u-pecl-memcache.x86_64 : Extension to work with the Memcached caching daemon
php55u-pecl-memcached.x86_64 : Extension to work with the Memcached caching daemon
php56u-pecl-amqp.x86_64 : Communicate with any AMQP compliant server
php56u-pecl-apcu.x86_64 : APC User Cache
php56u-pecl-apcu-devel.x86_64 : APCu developer files (header)

These install to standard locations and if there is a naming clash with base (eg python 2.6 in base) then the python 2.7 install will have a python27 binary but things like mysql and php will have the standard /var/lib/mysql and /etc/php/php.ini locations.

The SCL Repositories

On CentOS enabling the SCL repositories is carried out by installing the release rpm:

yum install centos-release-scl

This includes both the rebuilds from the Red Hat SCL (rhscl) and the SCL SIG only collections (sclo)

When software is installed from these repositories they get sectioned off in a special area of /opt and are not on the standard path. To make use of the new version at the shell a special scl command is used:

yum install python27 
python --version
Python 2.7.5
scl enable python27 bash
python --version
Python 2.7.8

It's also possible to source an enable script in many of the collections to switch over the application versions within a script without needing to call it with the scl command.


. /opt/rh/python27/enable

python --version

[root@c7-template ~]# sh 
Python 2.7.8

More than one SCL may be enabled at a time:

scl enable python27 ruby200 bash
ruby --version
ruby 2.0.0p645 (2015-04-13) [x86_64-linux]
python --version
Python 2.7.8

It is important to verify where the config files are when using SCL as they will be in their own section of the filesystem and not where usually expected:

rpm -qlc rh-php56-php
rpm -qlc httpd24-httpd

Something that is important to keep in mind if migrating an existing application from the base CentOS php to php56 is that the php55 and php56 mod_php builds are linked against and depend on the SCL httpd24 package. When carrying out this migration then a corresponding migration to the SCL httpd24 package needs to be taken into account.

The packages that have an actual service such as httpd24 or mariadb100 have their own service files that configure things and run things within that environment specifically:

# EL7
systemctl status httpd24-httpd.service
systemctl status rh-mariadb100-mariadb.service
# EL6
service httpd24-httpd status
service rh-mariadb100-mariadb status 

The Red Hat SCL items (from the centos-sclo-rh repo) have a 3 year maintenance lifecycle which does allow for a longer time between major regression testing but this is of course shorter than the base support lifecycle.

The sclo items are purely community supported from the SCL SIG so that should be taken into account when evaluating options on an Enterprise install.

To get a list of what SCL packages have been installed the scl command can be used to query:

scl -l

The RHSCL PHP packages do not include the base system PHP libraries (/usr/share/php) in the include_path so if using an application that requires libraries that have been installed from EPEL it's important to modify the include_path in the application behaviour, or in the mod_php/php-fpm configuration, to include these. Alternatively specifically including via an autoloader shipped by the library would also work, and is considered the preferred solution from the Fedora PHP SIG rather than relying on include_path.

Remi Repo

Remi is the maintainer for PHP and many PHP libraries in Fedora and EPEL. He is also a member of the CentOS SCL SIG. As such a lot of things pending for inclusion in Fedora, EPEL or SCL can initially be found in his repositories.

Depending on the specific needs there are multiple ways to configure the repositories there.

The basic remi-safe repo (the only one enabled by default) does not replace any system packages and uses SCL (pretty similar packages to the SIG SCL ones) to avoid disturbing system packages. The mod_php packages from the remi SCL packages are linked against the base httpd so do not require a migration to the SCL httpd24 as well.

In addition to these Remi has PHP packages that replace base so that yum install php rather than a specific version is required, going by the idea that if only a single PHP version is required (SCL with php-fpm can handle multiple versions installed at once) then it's better for the admin to be able to use the same commands and package names as if just working with base, rather than having to adapt for a particular repo.

If using the single php replacement then the config files are in the usual place, and if using the SCL version then the same scl enable stuff above applies.

yum install
yum install php56
scl enable php56 bash
[root@c7-template ~]# php --version
PHP 5.6.22 (cli) (built: May 26 2016 14:33:44) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

Note that these packages also have a symlink from /usr/bin/php* to the appropriate SCL version which can be used to avoid the need to use the scl enable syntax.

In order to help decide which of his repositories should be enabled for the system there is a wizard where based on the requirements stated the specific commands and repositories required will be detailed.

Where IUS follows the upstream EOL closely, Remi does make an effort to extend support still where there is reason to do so, on a best effort basis of course given this is in personal time.

This repo also focuses only on PHP, not just the language but the PHP ecosystem/stack with a large collection of libraries, extensions and tools. Some of these will be in Fedora/EPEL but others may be waiting for review, or in the case of EPEL not possible due to version dependencies.

The Remi SCL packages do include the system PHP path so no include_path changes are required, but the advice is still to use a specific autoloader by preference rather than rely on include_path.


As can be seen in this article there are plenty of ways to get modern languages and applications on CentOS and the right choice is always going to depend on the specific requirements at hand.

As always when mixing repos do pay attention to the output of yum update to be sure what might be replaced, and try to set priorities (or use include/exclude filters) to ensure the behaviour for the system is exactly as expected.

Add new comment