There is already Basic Management eXtensions for Apache : mod_bmx is handling vhosts.
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> > 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 > >
