Running newer applications on CentOS
Submitted by james on Wed, 05/25/2016 - 16:13
(Contents of this page stolen from https://www.hogarthuk.com/?q=node/15 as it looks like JHogarth, the original maintainer, is no longer around and the content is currently useful.)
1. Introduction
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 Repo https://ius.io/ which is sponsored by Rackspace and used by their customers.
The CentOS SCL SIG https://wiki.centos.org/SpecialInterestGroup/SCLo which rebuilds the Red Hat Software Collections https://access.redhat.com/solutions/472793 and also provides some additional ones of their own. The SIG provides more detailed information on tha Software Collections http://www.softwarecollections.org/ 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 http://rpms.remirepo.net/ 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.
1.1. IUS 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 about https://ius.io/about#safe-replacement page and their view of how they compare to SCL https://ius.io/faq#how-is-ius-different-from-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 packages for Apache HTTPD, MariaDB, Redis, HAProxy, and more.
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. In addition since IUS follow the upstream support policy it's important to be aware of when something like PHP 7.2 upstream support ends and a migration is required to PHP 7.3, with similar situations on the other packages. When IUS packages reaches EOL it is announced with an issue on GitHub in the https://github.com/iusrepo/announce repository. Users of IUS should "watch" that repository to be aware when packages they are using are no longer maintained.
Enabling IUS for CentOS is trivial:
# CentOS6 yum install https://repo.ius.io/ius-release-el6.rpm # CentOS7 yum install https://repo.ius.io/ius-release-el7.rpm
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 that is required, then carry on installing the rest of the stuff needed. Most packages install to the same locations as stock packages. If a package cannot completely replace the stock package, it will provide slightly different paths to be parallel installable.
1.2. 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.
cat test.sh #!/bin/bash . /opt/rh/python27/enable python --version [root@c7-template ~]# sh test.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 /opt/rh/httpd24/root/etc/httpd/conf.d/rh-php56-php.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/10-rh-php56-php.conf rpm -qlc httpd24-httpd /etc/logrotate.d/httpd24-httpd /opt/rh/httpd24/root/etc/httpd/conf.d/autoindex.conf /opt/rh/httpd24/root/etc/httpd/conf.d/userdir.conf /opt/rh/httpd24/root/etc/httpd/conf.d/welcome.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-base.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-dav.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-lua.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-mpm.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-optional.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-proxy.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/00-systemd.conf /opt/rh/httpd24/root/etc/httpd/conf.modules.d/01-cgi.conf /opt/rh/httpd24/root/etc/httpd/conf/httpd.conf /opt/rh/httpd24/root/etc/httpd/conf/magic /opt/rh/httpd24/root/etc/sysconfig/htcacheclean /opt/rh/httpd24/root/etc/sysconfig/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 httpd24 python27 rh-mariadb100 rh-php56 ruby200
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.
1.3. 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.
There are additional repositories such as remi-php73 that contain normal packages (not SCL) that obsolete packages of the same name from base. This avoids the complexity of SCL if only a single PHP version is needed. However, be aware these packages also obsolete package names from other third party repos such as IUS, so it is not recommended to mix remirepo with other repos.
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 http://rpms.remirepo.net/enterprise/remi-release-7.rpm 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.
2. Conclusion
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.