There is already Basic Management eXtensions for Apache : mod_bmx is handling
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>
> het volgende geschreven:
> (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 it
> 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
> 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
> 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
> 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
> 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...