Official support of PHP-FPM inside Web server app

We are working to make available rh-php71 and rh-php72 inside the vhost panel of cockpit (later rh-php73 will come)

this is the main PR

We want to install directly the PHP version inside the vhost if it is not installed and set by the sysadmin, so we need a yum group

this is the PR

I would like to know @mark_nl if we could set the same for ARM, make a yum group to install a bunch of ARM php rpm, probably the nethserver-httpd-virtualhost should be adapted because I saw that you maintain a fork of nethserver-arm-php72-php-fpm:

I could help you to adapt it, ping me


This is a screenshot of Steph’s work, just the tip of the iceberg :wink:

Alternative PHP versions can be selected and installed from this magic form


Sorry for the late reply…

Unfortunately there are no Software Collections available for armhfp (32bit) and close too none for aarch64.
For armhfp there is a community build for php-72 based on remi-safe (SCL) repositories, which as you know differs a bit from rh-php72.


that is not good, but the contrary would have surprised me :slight_smile:

As a fallback, we could imagine to switch to remi for ARM, do you think it worth it, else we will have a broken feature inside the cockpit vhost panel. Obviously you will have my help to do it

(re)builing php is quite a difficult job therefor (at least for me) not worth the effort.

We could remove nethserver-virtualhost from the comps list for arm or check if it really breaks thinks.If it it a matter of an errror of the like “package not found” we could decide to live with it.

grt Mark


no problem, we will go in testing in few days, so no hurry…we still have time to decide the best approach

1 Like

The package is available from testing!

yum --enablerepo=nethserver-testing install nethserver-httpd\*

We tried to handle the missing package scenario gracefully (Test case 2).

Everybody: please give it a try!



1 Like

I completed all test cases. I think it’s OK to release it :heart:


How easy to use. Nicely done!
There are a few rough edges to polish:

  1. Create a virtual host with a custom php version
  2. Edit the vhost, renaming the virtual host name (FQDN)

Result: new host alias not created and not accessible; old unassinged vhost alias present, accessible and falling back to default vhost/php version.
Some questions come to mind, what should happen:

  • with preexisting alias
  • when creating a vhost named the same as a preexisting alias
  • when deleting or disabling a vhost (what shall happen with the related alias)

Validations (I shall do more tests):

  • vhost name can create an alias considered invalid by the server alias validator (example: office as vhost results in office.domain.tld or alike, but adding other aliases from system dashboard results in a validation error).
1 Like

The host alias behavior didn’t change since the initial release of the Web server app: New Apache integration in cockpit (Web server)

[We could move this discussion there…]

I recall many past discussions since the times of nethgui about dns records and virtual hosts.

The cockpit app now tries to do as little as possible of dns alias records. Maybe it should stop even creating them because it seem there’s no possibility of implementing a consistent behavior.

Other random considerations

  • we don’t add aliases also in Kerberos keytab and in X509 certs
  • if the DNS server is another host there’s no (easy) way to add dns records to it

As alternative to all the above we can change approach and start from the list of host name aliases. Vhost, keytab, x509 cert: they all become locked with that list.

In other words imagine in vhosts panel (and proxypass) we remove the input box for the vhost name completely replacing it with a multiple selector. Can you figure it out? Only host aliases are already listed as available vhost names.