[FrontPage] [TitleIndex] [WordIndex

This is a read-only archived version of wiki.centos.org

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.

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 

. /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
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.

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.

2023-09-11 07:22