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