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: https://github.com/markVnl/nethserver-arm-php72-php-fpm
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
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.
How easy to use. Nicely done!
There are a few rough edges to polish:
Create a virtual host with a custom php version
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).
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.
