Teaser nethserver-php-scl

I’m working on a new module about php software collection, probably from remi.

  • PHP54,PHP55,PHP56 available
  • each ibay can have its php version
  • you can choose with php-mod another version of php for the whole server.

is there known interactions with works in the neth core ?

Hi @stephdl, what’s the low-level architecture that differentiates the PHP version on each shared folder?

AFAIK Apache prefork has only one choice for mod_php. Once configured for one specific version, it is the only available (?).

hi davidep

this is how I did for SME Server 9 : https://github.com/stephdl/smeserver-php-scl/tree/sme9-remi

In order to use a php version for each Ibay I use a CGI script which call the php scl version :

One of cgi scripts
#!/bin/bash
source /opt/remi/php54/enable
exec php-cgi

for the whole server, I agree that just one version can be used with php-mod, except if we use php-fpm and apache2.4

I hope that can be done for NethServer :slight_smile:

The CGI script looks a very simple approach, however did you measure the performance hit of fork+exec? I know it requires some time for the PHP interpreter to be loaded at each request.

I’d like to keep the upstream mod_php by default. And it will be 5.4 (and apache 2.4) soon, if we start development on CentOS 7!

I agree, that when you play too much, quite all the time, you lose
Therefore I understand to be as close as possible than centos is a good thing
All new software versions should come from a centos update but sometime in the real life it is not possible to wait and thus the interest of software collections.

FYI I have just tried nethgui with php56, no errors but ok it was a quick test.

honestly I have done no measures and no benchmarks, I simply stated if you want Joomla on a centos6, it is no more possible, joomla blocks all updates, due to your outdated php version.

Joomla is just one example, sure we can find others and thus this is my ‘solution’ to this issue. Of course if you have another ideas, I’m opened :slight_smile:

I think your idea is good and I like the simple and pragmatic approach. Performances may not be the a big issue on many deployments.

Therefore I would not push a more complex setup now, as we’ll have Apache 2.4 and PHP 5.4 on CentOS 7 that should be a good platform for many apps out there (@giacomo) .

About SCLs: they are good if remain an option, but I’m a bit concerned of the upgrade path to 7


These are good news :slight_smile: ! Thank you!

I’d like merging this new tab with “PHP settings” from the nethserver-phpsettings. Do you think it is possible? Of course, I’d help you with Nethgui :wink:

The SCL + CGI approach seems self-contained, I see no problems at this point.

A little state of development GitHub - stephdl/nethserver-php-scl at ns6

I can

  • load one of PHP_default/PHP54/PHP55/PHP56 per ibay
    I set a tab for for each Ibay a bit like I did with nethserver-phpsettings

  • load either PHP_default/PHP54/PHP55/PHP56 for the whole server
    For now you need to use a db property in ‘httpd’ (can be ‘default/php54/php55/php56’)

    config show httpd
    httpd=service
    PhpVersion=php56
    SSLCipherSuite=ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
    TCPPorts=80,443
    access=public
    status=enabled

Do you think that I should do a specific panel or the choice will be offer manually ? I know that you love to hide some specific and potentially dangerous options to non experimented sysadmin ==> thoughts !

I love modularity, and I wonder if we can have two modules, one for phpsettings, one for php version. Anyway they are not complementary because I can’t trigger php settings by nethserver-phpsettings when I use a php version as a CGI script, I can do it only when apache is the handler by php-mod.

But I accept your help for nethgui, I’m growing my skill in this new framework however I have still stuffs I don’t know how to do.

as all options are db properties based, once templates will be removed, I don’t think we will have problems. In the %postun section, I rewrite alike all php*.conf files

I have one interrogation concerning the remi repository, do we will use it or does we import from him all phpxx rpm. The problem of using directly remi is all rpm with a version more recent than in epel or centos, for sme I excluded mysql*,php-* but at least there are more other rpm
I think about roundcube in version 1.1.1 which could be a really nice update, I use it for sme

You said it! :wink:

In the past, I tested php54 from CentOS SCL. Only a symlink was needed to enable the PHP 5.4 module on the main Apache instance:

ln -s php54-php.conf  /etc/httpd/conf.d/aaa_php54-php.conf 
service httpd restart 

If this is the same for php54 from remi, I’d evaluate these commands for the experienced admin as alternative to the traditional template/setprop/signal-event way.

Thanks for pointing that out: I didn’t consider it! So we need separate php.ini files for SCLs, as I see in your code?

In an hypotetical single panel, the templates logic for PHP settings should depend on PhpVersion prop:

  • if PhpVersion is default, PHP settings are expanded into the ibay template, for mod_php
  • if PhpVersion is php* (SCL), PHP settings are expanded into the specific php.ini file

This is just an idea, of course we can keep them separate in a first stage.

[quote=“stephdl, post:8, topic:637”]
I have one interrogation concerning the remi repository, do we will use it or does we import from him all phpxx rpm.[/quote]

Good question
 AFAIK the SCL philosophy is installing a recent version of a software, without conflicting and upgrading existing packages. For instance php54 RPM is different from php: both are installed at the same time, on different directories.

As a first step, I’d say to use remi directly, and disabled by default. My proposal is: when the admin installs a PHP version from SCL, it becomes listed in the “PHP Software Collection” panel.

In fact all php5*-php.conf are in /etc/httpd/conf.d, therefore, no links needed. The first is taken as the php configuration (it is alphabetically sorted). Actually I rewrite them when I launch an event (either with the good configuration, or with some comments)

yes I provide php.ini for each php version like redhat does. For each scl php I use specific db properties (same like the default php). My php.ini are more commented and more complex than the default php, they need to be review, notably in term of security.

Well sometime I don’t know who I’m, either a developer, or a coder, or simply a man who doesn’t like to watch TV, but for nethserver-phpsettings I lacked some skills to achieve the rpm. Therefore I have not forgotten it, I simply put it in standby, the time to learn more in Nethgui.

If really you think that a bundle of phpsetting and phpversion could bring better values, then we can do that but at least, validators need to be done for nethserver-phpsettings

Interesting point of view, but what could be strange is the fact to trigger php settings of a php.ini when you are in an Ibay panel, it is (IMHO) a non sense. Anyway if apache is not the handler of php-mod, the modifications of php settings have no effects

Keep Kiss :smile:
In fact I provide as rpm required a lot of rpm for all php version available, the sysadmin is lazzy, and he can’t understand why he won’t find his rpm in the standard repository, and thus we should give his life easier and provide those are commonly used. Occasionally I thought to install all available rpm in remi, but I never dared to do it :wink:

Sorry for being OT!
This (your) habit is a awesome (for us)
Please keep doing it! :smile: