(Apart from my direct comments in my previous reply in the ServerUID discussion, I offer a little essay about my motivation in this topic for the interested, as it is related to the mod_md design I did. It is long. Please feel free to ignore it.)
When thinking about adding ACME support to Apache, I felt that the server lacked the concept of something "above" VirtualHosts. Something that keeps common properties that some VirtualHosts have in common. The Occasional Admin -------------------- My example was the Apache instance I myself had kept on running over the years, that has a very limited set of DNS domains it manages. What I had always disliked is when I ended up copy&pasting configuration directives between different VirtualHosts. I say "ended up", because there are other options like macros or includes, but for an occasional site admin like myself, those do not work that well. If I go in to fix something, it will work best with some local changes to the VirtualHost that I'd like to change/fix. Editing includes/macros is dangerous as I have no good feeling if this will break other VirtualHosts that also include/use this, but I have forgotten about that dependency. I only edit the server every few months or so. Then I use Ubuntu, which already comes with several includes. But editing those is worse, since I am never certain if edits get replaced on update or if updates get ignored due to my edits. I could find this all out, but the time I am willing to spend on this is limited. I consider myself a very average httpd admin. The Arrival of SSL ------------------ This all started when SSL was not really a topic for small sites like mine. There was 1 VirtualHost for every DNS name served (plus some aliases). Changes almost always affected only once vhost at a time. When https: became relevant (and certificates affordable) things got more complicated. It doubled the number of VirtualHosts as most of the sites needed be be available via http: and https: for the same resources (some resources only to be available on https:). Since it took some effort to get a certificate, I got few certs with several alt-names. This meant the same SSL configurations copy&paste between vhosts. Again, yes, Includes to the rescue. Did some of them, never was happy. Now, a VirtualHost in my server no longer was the DNS domain. Instead a DNS domain was made of several vhosts and, if I did it correctly, the common parts were shared and the other parts stayed separated. It worked, but it did not feel very natural. See: as the admin, I do not look at resources for VirtualHosts. I *have* different sets of resources and need them to be served in the right way. A vhost is just a vessel to do that. And the vessel no longer could contain a complete set of resources. I needed to split it over several vessels. Managed Domains --------------- This was the motivation to design something that aggregates the common things for several VirtualHosts into something new. The name I came up with for that is a "Managed Domain". "Domain" as it is mainly identified by a DNS name. "Managed" because the server should offer some nice defaults on how to serve it and take care about things. aspects like Obviously it was made to care about the domain's certificate. Another thing is that you can specify that resources in this domain require being served via https: only. There are other things that would fit well into this concept. For example, settings and locations for access logging would be nice to have. IO Stats as well. Locations would be really useful. Alternative ----------- Instead of enhancing Managed Domains, one could also go about extending VirtualHosts to allow better management of common resource sets. My patch to allow address lists in SSLEngine goes in that direction. The drawback is that when one overloads existing directives with "special sauce", it has limits and can be easily confusing. Conclusion ---------- I hope to have made the case for a concept "above" vhosts. If that is an extension of what mod_md currently offers or needs to be reshaped is not that important. I merely argue that we need such a thing and current config concepts and helpers are not enough. Now, go and enjoy your definitely-not-soccer event... Cheers, Stefan
