Which server id for mod_proxy_lb? (was: New ServerUID directive)
On Mon, Feb 5, 2018 at 8:09 PM, Jim Jagielski wrote: > > On Feb 5, 2018, at 7:38 AM, Stefan Eissing > wrote: > > 2. Does httpd core expose a VirtualHost Identifier in its API and > what would the semantic properties of such an identifier be? > > Yes, it does. It's the server_rec. That contains all the info required > to determine any and all fashion of "unique" Vhost IDs. So, for balancers (slotmems) needs, how about: - All IP:port from server_addr_rec list + - ServerName + - ServerAlias(es) (i.e. hash/MD5 thereof). ? The rationale is that this is solely what determines the "election" of a server_rec for each request. All duplicates, since nothing is enforced on this in httpd (should it?), would never be elected at runtime (i.e. ignored). We may want to detect the case though, or do we blindly reuse slotmems for them (w/o any consistency checks)? Regards, Yann.
Re: The Case for Managed Domains
Forgive the top-post, Gmail app sucks. Thanks for taking the time for tl;dr - it sums up the current situation really well. I pointed out some months ago that the matching foo in vhosts is weak, since we have a 1:1 ip:port relationship. We determined that can change in the next iteration to compare a list we already keep. It seems also evident that a vhost could have more than one ServerName as long as we track the canonical name that the request presented. Considering your cases, I'm wondering if the simplest thing is to promote to a preprocessed, but fully nestable context on trunk? One, two, three deep VirtualHost server scopes would provide sharing of config choices between hosts. Because some of these would be Management Scopes, as you suggest, using TAKE_01 would allow an umbrella scope to not actually be attached to an interface at all, but just serve, as the global context does, for inheritance only hosts. Simplest example would be a well scoped http:// interface with a nested https:// interface, adding some protected ssl-only content mapping and tls config. That would not diminish the outer http:// vhost mapping. Similar examples would be a wild card SSL cert config with a number of specific content hosts nested within that, sharing the same tls config. What this doesn't solve is a many:many mapping. I haven't come up with a good answer to that puzzle without resorting to includes and macros, etc. On Feb 4, 2018 05:51, "Stefan Eissing" wrote: 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.
Re: New ServerUID directive
> On Feb 5, 2018, at 7:38 AM, Stefan Eissing > wrote: > > > 2. Does httpd core expose a VirtualHost Identifier in its API and > what would the semantic properties of such an identifier be? > Yes, it does. It's the server_rec. That contains all the info required to determine any and all fashion of "unique" Vhost IDs.
Re: The Case for Managed Domains
On Sun, Feb 4, 2018 at 7:47 PM, Eric Covener wrote: > On Sun, Feb 4, 2018 at 8:43 PM, Luca Toscano wrote: >> 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? > > FWIW I don't see the relationship either. I don't see bmx serving the managed domain structure proposed in top post. But the proposal could certainly alter the structure of bmx itself. The feature I think Steffen refers to is mod_bmx_vhost, which collects traffic and activity counts on a per-vhost basis. In looking at the proposed model, if several vhosts reflected the same basic unit of web services, I can see it evolving to count and sum the activity across this management unit, as opposed to each individual vhost.
Re: svn commit: r1822879 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
You can't retrieve in the register fn hook, without creating load order dependencies. On Feb 2, 2018 02:44, "Joe Orton" wrote: > On Thu, Feb 01, 2018 at 03:01:41PM -, yla...@apache.org wrote: > > Author: ylavic > > Date: Thu Feb 1 15:01:40 2018 > > New Revision: 1822879 > > > > URL: http://svn.apache.org/viewvc?rev=1822879&view=rev > > Log: > > mod_proxy: follow up to r1822849 and r1822878. > > > > Does r1822878's "static" APR_RETRIEVE_OPTIONAL_FN work if, say, > mod_proxy is > > builtin but mod_http2 isn't? > > I'd guess not! > > > Not worth taking the risk here since it's not a fast path... > > > > Note: if this is an issue, I'm afraid it applies elsewhere too. > > The only places I found with optional fn declared static within a > function were both pointlessly static and safe, fixed in r1822931. It's > funny since we have a specific hook for retrieving optional functions at > the right time, but it's almost never used. Most modules do it in > post_config which is safe. > > Regards, Joe >
Re: New ServerUID directive
> Am 04.02.2018 um 15:32 schrieb Jim Jagielski : > > > >> On Feb 2, 2018, at 8:05 PM, Yann Ylavic wrote: >> >> That's a new directive too, very specialized (though it's your point). >> Wouldn't it end up being declined to other modules one day or the other? >> But mainly, rather than ignoring config changes, I think mod_proxy_lb >> should ignore non-changes. >> And it already knows how to do that provided the vhost's balancer id >> does not change unnecessarily... > > The main point is that modules are free to determine what they > consider a unique Vhost; they are free to make whatever assumptions > are required. Inevitably, it depends on the module and WHY it needs > to know if a Vhost is "unique" and that will vary. Some will be more > stringent, others more free. Creating a user land directive which is > basically for internal module use doesn't help at all. No one wants to restrict any module's freedom to choose meaningful identifier for the data it manages. I think we are all in agreement to that. There seem to be two things worth discussion: 1. How can the default behaviour of mod_proxy_lb be changed, so that site owner with frequent reloads no longer suffer the current problems. I think we can get a solution without introducing a new directive. That would be good for our users. 2. Does httpd core expose a VirtualHost Identifier in its API and what would the semantic properties of such an identifier be? The second part is what I and Yann have both argued for. I do not know if we are in 100% agreement to what it should be, but we both seem to see use cases where an identifier (for me, an id always is unique) for a virtual host is useful. Again, I think that such a server id can be handed out by httpd without using a directive. That id does not have to satisfy all uses cases, since modules - as stated above - remain free to use it or come up with their own. Cheers, Stefan > > The only issue is that *in this particular case* there is a > weird use case where the assumption on what makes a > Vhost unique doesn't match with what they want. One > option, of course, is to say "Well, you need to figure out > a way such that when you adjust the config file, the line > number doesn't change". For such an extremely rare edge > case, this seems a valid suggestion, rather than directly > jumping into code and adding fluff and cruft that 99.% > of httpd users will never want and see. > > But sometimes, such edge cases are not-so-rare enough that > we provide code workaround for the normal case, ala the > singular workaround directive suggested. It's specific, targeted > and low touch for the vast majority of httpd users and admins. > > For example, consider the above. You say "I think mod_proxy_lb > should ignore non-changes.". What do we do for the admin > who doesn't feel that way? Or that we want ServerUID to be > one thing for module foo and another for module bar? Isn't > it up to the *module* itself to determine what makes sense? > The module itself is (hopefully!! :) ) designed and architected > and "logic" with its own specific assumption and requirement > on what a unique UID needs to be. I would guess that 99.999% > of the time, any change to that would cause really weird behavior. > > This just seems like a heavy-weight "fix" for an extremely > weird on one-off edge case which is more suitably handled > by, if an actual code change is really *required*, a small > targeted patch.
