> Am 03.02.2018 um 02:05 schrieb Yann Ylavic <ylavic....@gmail.com>:
>
> On Fri, Feb 2, 2018 at 5:52 PM, Jim Jagielski <j...@jagunet.com> wrote:
>> But we already have a unique ID in the form of
>> the actual server struct itself, which contains
>> all the data required to make a vhost "unique"
>
> Sure, my patch or any other way to compute an automatic UID for a
> vhost don't need anything else than the server_rec.
> More exactly the proposed patch needs all the servers because it
> doesn't take the line number into account, and nothing prevents
> multiple exact same vhosts to be configured (totally useless, so an
> implementation detail and not the point here).
>
>>
>> The only "issue" is what makes a host "unique"... IMO,
>> in an environ where the definition line of the vhost changes
>> between restarts is a "new" vhost and that was the assumption
>> that the implementation was based on.
>
> I don't deny it can be a valid assumption for some cases, but I
> observe that it breaks others like "automatic vhost UID should remain
> the same when some totally unrelated line is added before it".
Code exists that wants to persist (and be it shared mem) across
reloads or even restarts for the same (set of) virtual hosts.
Code that wants to re-init on every reload has the generation
and/or timestamps to work with, I assume.
>> *But that assumption can more easily be changed by providing
>> a work-around for that specific use case*
>
> I'm not proposing this directive to address the mod_proxy_lb case, and
> just gave it as an example for an in-tree case where it would be
> useful (at least a new automatic UID is needed I think).
> That case just reminded me that I had a patch somewhere for the
> ServerUID, which is actually part of a larger one for a per-vhost
> scoreboard/logio stuff which I already talked about some times ago
> (with no apparent feedback/interest).
On my ever growing list of needful things is status information about
managed domains. It would be interesting to also show how much traffic
and redirects are being observed on individual server_rec* belonging
to a domain.
> This larger patch really needs a vhost UID for stats to be relevent
> days/month/years later, regardless of minor configuration changes,
> even for things like vhost IP or port (which does not matter too much
> in a local network, not to talk about line numbers...) or
> ServerName/Alias (nothing mandates them for a vhost to work, e.g. IPs
> only and ProxyPreserveHost).
I always think of ServerName as identifier, although the server itself
does not make that assertion. What would be the use of identifying vhosts
*not* based on their ServerName? (Curious)
> Anyway, if you already have an UID in an User Interface to identify a
> vhost, put it in ServerUID for httpd to use it where needed internally
> and/or to "print" that UID anywhere you configured it to (e.g.
> %{SERVER_UID} in access_log, headers, expr, ...).
> At the end of the day, the webmaster really talks about the ServerName
> or this "UID" to refer to a vhost (they can be and even usually are
> the same modulo ports 80/443), but never about the IP or line number
> it once had.
+1
> Sooo :) instead of proposing the change on how we can uniquely
> identify a vhost for mod_proxy_lb only (in an automatic way or not), I
> thought ServerUID could start its upstream life.
+1.
>> instead of creating a
>> whole new Directive for a "generic" server UID which:
>>
>> 1. Implies that the webmaster must know when and how that UID
>> is used internally
I think key is to define a concept of a server identifier that
has clear semantics without knowing the internals.
> How is it different than now, or than anything we could do
> automatically/unconditionaly based on the server_rec?
> This argument sounds to me like we really need the ServerUID, if the
> webmaster really wants httpd to use an ID which does not depend on
> whatever future change to the configuration, (s)he has to provide that
> ID or know the internals.
> The only requirement on the httpd side is that an given ServerUID is
> unique (that should be documented, though the directive name not
> really ambiguous). It shouldn't be too hard for the user, UUID or
> alike.
>
>> 2. Add more Directive cruft to an already bloated collection
>> of directives.
>
> That's a very valid concern! But I think my proposal is quite
> orthogonal to the mod_proxy_lb issue, and it doesn't avoid us to find
> one (or Stefan's multiple) good way to uniquely identify a vhost when
> no ServerUID is specified.
There are directives which introduce "things" in the server, e.g.
"VirtualHost" and there are directives which peek/poke at highly
specific aspects of something, tweaking the defaults. There are
few of the first and a myriad of the latter ones.
Initially, ServerUID sounded like a tweak, but now we are talking
about the identity of a server_rec across reloads and how that
can be useful.
I would like to come to a design where this ServerUID emerges
from the server config as is and only needs a user tweak for
exceptional cases.
>> Instead, as I said, we should have a specific balancer directive
>> or option, complementing the Persist-related ones, that either
>> have the config line number included or not in the hash, ala
>> "IgnoreConfigFileChange" (or whatever)
>
> 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...
>
> It really matters for (graceful) restarts only, because otherwise we
> don't need to reuse names or slotmems (besides Mark's unusual issue,
> see [1] below).
> Why would one restart httpd if not to apply some configuration change?
> Whether this change relates to balancers or not is something the
> webmaster shouldn't care about (and figure out if
> IgnoreConfigFileChange should be on/off, depending on the kind of
> change, before the next restart).
>
>
> Regards,
> Yann.
>
> [1] AIUI, the issue Mark encounters with balancers is that the main
> process crashes because of third party modules, leaking IPC-SysV SHMs
> to the system (many balancers thus many leaks).
> Since his configuration file changes often, the SHMs are not cleaned
> up on the next startup either (their names changed with line numbers).
> So I proposed, as a *workaround* before the root cause if fixed in
> third party modules and to unblock his production, a temporary patch
> to remove line numbers from the computation of the SHMs names.
> But the ServerUID proposal is not meant to address Mark's unusual
> case, I mean the unusual case where the parent process crashes,
> because (frequent) restarts are not that unusual and should be fixed
> IMO.
