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
signal-eventcommands 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.