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
>
>
>
>

Reply via email to