DirectAdmin with RPM PHP from Remi Repository

sparek

Verified User
Joined
Jun 27, 2019
Messages
465
I was going to post this in the LET thread, but it doesn't appear to like my code.

Switching the DirectAdmin php system to use the Remi repository of PHP seems to be fairly easy. I thought I'd take a shot at providing a loose guide on how it might be accomplished. I didn't really follow all of this, I'm kind of creating this guide backwards. Initially I created my own php-fpm service linking to it through DirectAdmin hooks, but this way might be more straightforward for normal users and might provide some insight to DirectAdmin on how they might integrate this into their own system. I'm sure there are some tweaks that could be made to this.

I'm using CentOS 7 as my base.

Before you start, you need to be sure that Custombuild has already compiled a PHP 7.1 version. This could probably be avoided if DirectAdmin had a way to integrate the Remi repository and packaged PHP binaries into CustomBuild, but for the purpose of this guide, we have to have this already

Make sure your /usr/local/directadmin/custombuild/options.conf file has

php1_release=7.1
php1_mode=php-fpm


Then rebuild php if necessary

/usr/local/directadmin/custombuild/build php

Now you need to install the Remi repository - see https://blog.remirepo.net/pages/Config-en for more details

yum install https://rpms.remirepo.net/enterprise/remi-release-7.rpm

All of the repositories are disabled by default, except for remi-safe, but I'm going to go ahead and disable that as well

yum-config-manager --disable remi-safe

Before you can begin you have to install some requirements for PHP:

yum install environment-modules jbigkit-libs libedit-devel libmcrypt libtidy libtiff libtool-ltdl libxml2-devel libxslt ncurses-devel scl-utils tcl xz-devel libargon2-devel libargon2

I'm doing this here, because in the next step when I install PHP 7.1, I'm not going to have access to any other repositories.

To install PHP 7.1 from Remi:

yum --disablerepo=* --enablerepo=remi-safe --disableexcludes=all --exclude="$(cat /etc/yum.conf | grep ^exclude | cut -d = -f 2 | sed "s/php\* //g")" install php71-php-json php71-php-xml php71 php71-php-soap php71-php-opcache php71-php-bcmath php71-runtime-2.0 php71-php-pdo php71-php-devel php71-php-ioncube php71-php-mbstring php71-php-tidy php71-php-cli php71-php-mysqlnd php71-php-gd php71-php-intl php71-php-gmp php71-php-process php71-php-common php71-php-xmlrpc php71-php-mcrypt php71-php-pecl php71-php-imap php71-php-fpm

Once this is complete you need to change the DirectAdmin compiled PHP 7.1 to this new Remi controlled PHP 7.1

systemctl stop php-fpm71.service
mv /usr/local/php71 /usr/local/php71-da ## Move the DirectAdmin compiled PHP 7.1 out of the way
ln -s /opt/remi/php71/root /usr/local/php71 ## Replace the DirectAdmin compiled PHP 7.1 directory with the Remi PHP 7.1 root directory
ln -s /usr/local/php71/bin/php /usr/local/php71/bin/php71 ## The DirectAdmin compiled PHP 7.1 names the binaries php71 instead of php - so symlink them
ln -s /usr/local/php71/sbin/php-fpm /usr/local/php71/sbin/php-fpm71
mkdir -p /usr/local/php71/etc
cp /usr/local/php71-da/etc/php-fpm.conf /usr/local/php71/etc/php-fpm.conf ## This file could be created separately, but for the purpose of this exercise we'll just move the php-fpm.conf from the (moved) DirectAdmin PHP 7.1 compiled version into this new Remi controlled directory
mkdir -p /usr/local/php71/sockets
chown apache:apache /usr/local/php71/sockets ## This directory needs to be created and ownership changed to house the individual php-fpm sockets
systemctl start php-fpm71.service


That's it.

The main reason you need CustomBuild to initially compile PHP 7.1 is for the file - /usr/local/php71/etc/php-fpm.conf - which can easily be duplicated without compile. And for the creation of the php-fpm71.service file - /etc/systemd/system/php-fpm71.service - which again could be easily duplicated

Now as a reminder, you can't use CustomBuild to recompile PHP 7.1 because that's going to mess up this changed directory structure.

/usr/local/directadmin/custombuild/build versions

Will show you if PHP 7.1 is out of date, but to update it you would need to do something like:

yum --disablerepo=* --enablerepo=remi-safe --disableexcludes=all --exclude="$(cat /etc/yum.conf | grep ^exclude | cut -d = -f 2 | sed "s/php\* //g")" update php71

Like I said, there's probably a more eloquent way of doing all of this. I know this is a bit rough around the edges. It's just kind of meant as a Proof of Concept.

This should be duplicatable with PHP 7.2 and PHP 7.3 (Not sure about EOL versions of PHP).

My proposition would be for DirectAdmin's CustomBuild to add another option to the options.conf file, something like:

php1_source="remi"

or

php1_source="compiled"

And if this is set to "remi" then something like the above is done instead of compiling php.
 
There are a lot of reasons why compilation is used instead of RPM packages, however, I agree that both have their own 'bright' and 'dark' sides :) So, I wouldn't really mind providing some way to specify binary locations for the PHP binaries natively, which CustomBuild would just 'symlink' to correct location. This would be considered 'advanced', but might allow easier integration with 3rd party scripts/packages.
 
Not a complaint... but just wanted to point out for those that might argue that compiling PHP will result in faster releases.

As of right now, August 30th. CustomBuild is still showing PHP 7.1 as being 7.1.31. The Remi repository is already installing PHP 7.1.32

CustomBuild:
Latest version of PHP 7.1: 7.1.31
Installed version of PHP 7.1: 7.1.31


Remi:
* remi-safe: mirror.sjc02.svwh.net
Available Packages
Name : php71-php
Arch : x86_64
Version : 7.1.32
Release : 1.el7.remi
Size : 1.5 M


Again, this is not a complaint regarding CustomBuild. Just merely pointing out that Remi would appear to release PHP updates fairly quickly.
 
Please don't use that argument when it is only a matter of HOURS. PHP 7.3.9 and 7.2.22 is already in custombuild, and has been in custombuild for MANY hours already. However PHP 7.1.32 was not released at the same time as 7.3.9 and 7.2.22, but much later, to me it looks like it was in the middle of night in Canada timezone when 7.1.32 was released. Will you please allow DirectAdmin developers to sleep at night? I am not at all interested in RPMs. A big minus from me regarding to that feature.
 
Last edited:
I only mentioned it because there is a crowd that believe compiling from source is the best way to get 0-minute updates.

In fact... even though PHP 7.1.32 isn't in CustomBuild right now... there's nothing stopping you from grabbing the PHP 7.1.32 source from the php.net website and compiling it yourself right now.

Please understand... I did not make this reply to start an argument. I'm just stating, like I said in my first line of the reply, that if you are of the thought that RPMs take days to get released for updates... the Remi repository for PHP is not one of them. I am in no way, shape, or form suggesting that removing the option to compile everything should ever be taken away.

If I upset anyone... I apologize. I thought my words were kept civil. If there is something I have said in any of this that is combative... please let me know so I can learn from it.
 
Yeah REMI PHP yum repo is one exception in that it's fairly quickly updated. But source compiles can be too for DA if they track php version releases via https://github.com/php/php-src/releases rather than wait on mailing list or php.net notifications. That's what I do for my own source compiled PHP version tracking as https://github.com/php/php-src/releases releases are a few days before php.net announced releases.

In the past php.net had a delay to populate various mirrors but php.net switched to CDN based download system so really when https://github.com/php/php-src/releases announces a php version release, it's fairly sure to be available via php.net even if they do not yet announce it. This gives PHP source compilation folks like myself and/or DA a few days early advance notification of PHP pending new release :)

FYI, I was source compile updating PHP 7.3.9, 7.2.22 and 7.1.32 at least 48hrs before php.net announcement and backporting security fixes to PHP 7.0.33/5.6.40 :D
 
Last edited:
Again... I'm not trying to stir up controversy... civil discourse is the term I'm thinking of with this discussion. It was asked on the LET thread about feedback on how to improvement DirectAdmin. I'm simply answering that call. Disagreeing is part of having a discussion. I think sometimes it's important to elicit feedback from sources you don't normally get feedback from, otherwise you get stuck listening to the same people over and over again and depending on your market or landscape that may not accurately reflect your entire user base.

Like I mentioned in the LET thread (good luck getting LET to load) I think this boils down to... what market do the owners and upper management of DirectAdmin want to target? Up until July 1, 2019... I would bet that DirectAdmin was more a target of single use servers or at least small time hosts - hosts with 1 maybe 2 servers, perhaps VPSs (that's not to say that large web hosts did not use DirectAdmin, just that it was probably few). After July 1, 2019... an opportunity presented itself with DirectAdmin. A flood of potential new customers started knocking down their door. Now the decision DirectAdmin has to make... do they welcome these new customers or do they continue to operate as they did pre-July 2019? That is an honest question... there is no malicious intent with asking that question and it's totally their question to answer. It's not my place (or anyone coming over after July 1, 2019) to make demands on DirectAdmin to go one way or the other.

Now... having said all of that... IF DirectAdmin wants to embrace this post-July 1, 2019 incident then I think including the option for some pre-packaged binaries would be a good decision. Particularly with PHP. It's one thing when a hosting company has 1 or 2 servers and maybe 200 customers. It's another when a hosting company has a fleet of 50 servers with 10,000 to 20,000 customers. PHP being a de-facto every-month upgrade... knowing that that has to be compiled every month can quickly become cumbersome. I don't know if pre-July 1, 2019 DirectAdmin really ever considered such a scenario or how much weight it was really given.

Utilizing Remi in this situation is different from what other control panels might be doing with pre-packaged binaries. DirectAdmin doesn't have to repackage these binaries or get involved in much of anyway. Ideally custombuild would allow for an option like I suggested, that would define a PHP version's "source" and perhaps make the symlink and necessary changes like I suggested (rudimentary as they may be). This would in no way, shape, or form completely replace compiling PHP through custombuild. It would just provide a different option... an option that (IMHO) a lot of post-July 2019 DirectAdmin customers would embrace.

I make the argument that compiling is always an option. No matter what control panel you are using, no matter what operating system you are using. If an application's source is available, then compiling is always an option for you (getting the library dependencies installed is another thing). In this sense, DirectAdmin's CustomBuild is defaulting to the lowest common denominator... compiling. And just like compiling it is always an option... rolling your own is also always an option - and that's what I've done. When I started looking at DirectAdmin and saw the PHP compiling, I knew of Remi's existence so I started to look into ways to integrate it in with DirectAdmin and for my purposes, I think I've come across with a reasonable way to include it on my servers. If DirectAdmin decides not to go down the path of offering pre-packaged binaries, then I'll likely continue to "roll my own" with this - no harm, no foul.

The purpose of my initial post was just to show how (at least to me) easy it could be to include remi's pre-packaged PHP binaries. And the purpose of my second post was to illustrate that there doesn't appear to be a long wait time after a new PHP release and Remi's repository including it. Is it meant to persuade DirectAdmin to offer this? Sure! Absolutely! But is it demanding that DirectAdmin offer this? No. If my language in any of these posts comes across that way, then please let me know. That was never my intent.

Now regarding the other applications and components that CustomBuild provides... honestly I'm pretty much fine with all of that being compiled. PHP is the only component that is relatively large that gets new releases on a regular basis. Some of the libraries may see quite a few updates, but those are mostly small compiles (and probably utilized mostly by PHP anyway). Maybe MariaDB (which I think is RPM installed anyway) and perhaps Apache might be helped by pre-packaged binaries, but neither is really upgraded on a regular basis (I think MySQL is also RPM installed, at least on Redhat variant OSs, but can't be sure).

But the Exim incident of September 6, 2019 illustrates where this compile everything approach can beneficial. DirectAdmin had this update included in CustomBuild relatively quickly after Exim released the new version. It did not necessiate an upgrade to DirectAdmin... simply rebuild Exim. In contrast to other control panels that had to repackage Exim themselves - which delayed it's release and also required you to "upgrade" the control panel in order to install the new version of Exim. From this perspective, I liked DirectAdmin's and CustomBuild's method of fixing this issue a lot better. But Exim is not regularly updated and is relatively small to compile. PHP is really the only component that we all know will have an update released on or around October 1, 2019 (and November 1, December 1...).
 
What you have done is what I have asked for at least a couple of times! I currently only have one DA server left due to many problems I have had with tailoring some components plus the rigidity of the configuration system. Instead of saving time DA has lately proved to require more working hours than previously (DA user since 2008, I think). After using Nginx & PHP repositories in non-DA servers I noticed how handy they are for general use and how much they save time. I understand that in some rare installations one needs to fine-tune some bits and pieces but I firmly believe that repositories are the best option for most of us and for general use.

As for PHP 7.4 compiling seems to be the only way to get hold of SQLite and Zip functionality. They have been (almost) silently dropped from the PHP bundle and as of writing this Remi does not offer either of those packages in the collection. So it is dull "compile and sit waiting".
 
Back
Top