I think we need to look into improving the Virtual Hosts configuration page, based (at least partially) on the threads linked at the end of this post. I see four issues that could stand to be addressed:
A number of modules, both “official” and community, allow creation of a dedicated virtual host (e.g., Nextcloud, WebTop, DokuWiki, etc.). Some others (like CODE) create a “hidden” virtual host that the user (ordinarily) never directly interacts with, but it’s still there. None of these appear on the Virtual Hosts page, entries on the Virtual Hosts page can conflict with them, and there’s no deconficting going on.
There’s some confusion (as evidenced in the first two links below) about the work flow, with some users thinking they need to create a virtual host in the server manager before assigning it to a given web app.
There’s no proper way (either through the GUI or at the shell) to configure those virtual hosts, particularly (in my view) with respect to TLS certs (which is an issue raised in both the first and third link below).
With the exception of Nextcloud in Cockpit, any configuration of the virtual hosts needs to happen at the shell rather than the server manager.
Here’s how I think it should look instead:
If a module supports being accessed via its own virtual host, that should be configurable via the server manager–you shouldn’t need to be running config setprop and signal-event commands for normal, documented, supported configurations.
The Virtual Hosts page should list all virtual hosts. At a minimum, the app-specific hosts can be listed but grayed out. Better if there’s a button to take you to that app’s settings. Better yet would be to let you configure it directly within the Virtual Hosts environment.
Wherever you’re configuring those virtual hosts, you should be able to adjust their settings. The TLS certificate is an obvious setting that should be available on any vhost. Other relevant settings might vary with the app in question, but PHP memory limits, execution timeouts, and the like are good candidates to have adjustable.
Edit: Two more things:
Be able to configure virtual hosts to redirect to a preferred domain name. It’s common to have domain.tld and www.domain.tld–you’ll ordinarily want both on the same virtual host, because some people will add www. even if they aren’t told to, while others will drop it even if it’s part of the URL they’re given. It would be good to have the ability to redirect to whichever hostname the admin chooses as canonical.
It would be good to be able to create a vhost from the Virtual Host page, and still in that page, assign it to an installed web application. There’s no reason to limit one app → one vhost, either–you may well have a web app you want to be available on more than one domain name.
I’m against this since every applications has its own needs, while the virtual host page is part of the core.
We shouldn’t add app-specific code inside the core.
It’s not simple, but it could be done. Even if I prefer the current approach: let the virtual host use the default certificate.
Again this is too application specific, and often the applications override the server configuration.
This is a really nice idea, I like it
To be honest, currently, we have no plans to reserve some development resources for such options.
But I will gladly review any new PR and try to involve someone for the testing.
It’s simpler to implement to be sure, but certificate management is quite a bit simpler when you don’t have 20+ names on a single cert. Sure, Let’s Encrypt will handle it (up to 100 names per cert), but you then need to re-enter all the names (without missing any) any time you need to change the cert (a different feature request would be to have the certs page parse all the virtual hosts and add them automatically to the cert…). It’s configurable for any other virtual host, and there’s no apparent reason that it would cause any conflict for it to be configurable for app-specific virtual hosts.
i totally agree with this case. We have multiple applications which have configured vhosts, but are not visible on the vhost panel.
It makes alot of sense. to also have most if not all modules make use of the vhost defined on the vhost panel, and have the integration made. Than way, its easier to follow along.
there are some instances someone has to scramble getting some config location due to every app having its own way of configuring vhost.
