I am a bit ignorant about mod_bmx so I'd need to ask some follow up questions: how is it going to solve Stefan's points? As a far as I can see it is a very nice architecture to query metrics and process them via plugins, so I'd be super glad to see it integrated to power up our status page but I don't see how it could help in abstracting properties across vhosts for example. Can anybody give me more info?
Thanks! Luca 2018-02-04 15:57 GMT+01:00 Jim Jagielski <j...@jagunet.com>: > +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/ > > 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 > > > >
