+1
> On Feb 4, 2018, at 7:35 AM, Steffen <i...@apachelounge.com> wrote:
>
> There is already Basic Management eXtensions for Apache : mod_bmx is handling
> vhosts.
>
> https://github.com/hyperic/mod_bmx/ <https://github.com/hyperic/mod_bmx/>
>
> Using it on windows with mrtg and mod_watch to create nice graphs per vhost.
>
> An issue is that it is not collecting incoming traffic, Bill(William Rowe) is
> looking for a fix.
>
> I am +1 to adopt mod_bmx and use it as a framework and maybe some of Stefan
> proposals we can fit in.
>
> When I recall Bill did already propose to adopt some time ago.
>
>
> Op 4 feb. 2018 om 12:51 heeft Stefan Eissing <stefan.eiss...@greenbytes.de
> <mailto:stefan.eiss...@greenbytes.de>> het volgende geschreven:
>
>> (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
>>
>>
