(Apart from my direct comments in my previous reply in the ServerUID 
I offer a little essay about my motivation in this topic for the interested, as 
is related to the mod_md design I did. It is long. Please feel free to ignore 

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 
is when I ended up copy&pasting configuration directives between different

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

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.

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



Reply via email to