> 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

Reply via email to