Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[William A Rowe Jr]

For the match of balancer://group/ I don't believe length adds any value.
The one and hopefully final strcmp to validate the hash elt election should
accomplish this. From that point it becomes simple sting concatenation.

The optimization is getting us to that elt.

On Feb 13, 2018 11:32 AM, "Yann Ylavic"  wrote:

> On Tue, Feb 13, 2018 at 3:19 PM, Graham Leggett  wrote:
> >
> > Another option for the name is to store a URL prefix length and a hash of
> > the prefix. If the hash of the prefix matches, we have a match. Would
> this
> > work, would it be too expensive to hash on every hit, would it be safe
> > enough?
>
> It could work for prefix equality (with a keyed hash function like
> siphash to avoid collision forgery), though hashing every URL
> (possibly multiple times, for each different configured length) might
> be more costly than the current strncmp.
>
> But I suppose that the main issue is for regex matchings ("ProxyPass
> ~" and ProxyPassMatch)...
>
>
> Regards,
> Yann.
>

Re: Time for 2.4.30? (Was: Re: 2.4.x STATUS needs you!)

[William A Rowe Jr]

And perhaps sufficient testing of the end result? The number of exceptions
at the moment bode ill for a stable long term release. Feature dumps always
introduce instability.

Maybe a bug fix only freeze for a short period to stabilize that pile of
code?

On Feb 14, 2018 06:41, "Jim Jagielski"  wrote:

> Yes... there are/were a few backports which are/were lacking
> a single vote...
>
> On Feb 13, 2018, at 1:23 PM, Nic Jansma  wrote:
>
> Are there still plans to push for a 2.4.30 soon?  There's a couple bug
> fixes in it that I'd love to have in the official builds!
>
> Thanks,
>
> - Nic
>
> On 2018/01/04 12:43:12, Jim Jagielski 
>  wrote:
> > As we get settled into the new year, it seems a good time>
> > to think about a 2.4.30 release in the coming week or>
> > so. Lots of good stuff currently in 2.4.30-dev and even>
> > more good stuff in STATUS awaiting a single vote!>
> >
> > Let's see if we can clean-up STATUS, get 2.4.30-dev into>
> > fantastic shape, and "commit" to doing a release no later>
> > than mid Jan.>
> >
> > I volunteer to RM and/or help someone else RM.>
> >
>
>
>

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

Not at all.

This is physical host vs named based vhost.

We got clever and eliminated the distinction after 2.0... which is catching
up with us.

Should we reintroduce a physical vhost? I don't have a simple answer, but
we can at least keep repeating that the first vhost is the physical vhost
and only certain directives have any effect there.

On Feb 14, 2018 08:49, "Stefan Eissing" 
wrote:

> I had a patch posted here on Monday that introduces
>
> 
>...
>
>
> 
>
> with a server_rec and configs between base server and a a set of
> vhosts. Would that satisfy your needs for this?
>
> -Stefan
>
> > Am 14.02.2018 um 14:39 schrieb Graham Leggett :
> >
> > On 14 Feb 2018, at 3:05 PM, Yann Ylavic  wrote:
> >
> >> It makes sense, and actually I missed some logic w.r.t.
> >> enabled/disabled being a list of sockaddrs (based on servers'
> >> server_addr_rec, and not a global boolean as I first thought...). This
> >> is later compared to incoming connections local addr.
> >> Let me grok that... but at first glance it looks quite cumbersome, why
> >> not the usual server merging and a simple "enabled" boolean?
> >> If we only care about the config of the base server,
> >> "ap_get_module_config(c->base_server->module_config,
> >> &remoteip_module)" could do it no?
> >> For now it seems that all the vhost selection logic is duplicated, but
> >> indeed it's not global (nor really per vhost, but yes this is thee
> >> scope which comes closest).
> >
> > I think the problem distills down to our config lacking an explicit
> configuration container for the IP address and port, something like this:
> >
> > # global
> > 
> > # per port
> > RemoteIPProxyProtocol on
> > 
> >   # per virtual host
> > 
> > 
> >
> > In the absence of a Bind directive (or equivalent) we’re left with this
> undesirable config:
> >
> > # global, yuck
> > RemoteIPProxyProtocol on
> > 
> > # per virtual host
> > 
> >
> > So we’ve compromised and said we’ll accept this config:
> >
> > 
> >   # per port
> >   RemoteIPProxyProtocol on
> >   # per virtual host
> > 
> >
> > To set RemoteIPProxyProtocol, we have to jump up one level to get
> server_addr_rec, walk the list of matching IP addresses on virtual hosts
> and setting (or not) as appropriate.
> >
> > Regards,
> > Graham
> > —
> >
>
>

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[William A Rowe Jr]

That explanation is noxious.

If enabled in the *default* initial matching physical ip:port host it
applies to all related hosts

If enabled in any secondary-non-default named vhost it is ignored.



On Feb 14, 2018 06:28, "Graham Leggett"  wrote:

> On 14 Feb 2018, at 1:03 PM, Yann Ylavic  wrote:
>
> The docs talk about connection based config, while ap_server_conf is
> really the main server config.
> The code should be improved to be based on c->baser_server config
> (with merging of RemoteIPProxyProtocol*), unless I'm missing something
> it seems (as of now) that the directives overwrite each other when
> used in vhost context (not only for name-based vhosts).
> So now (or post-backport) I think we should at least document the
> scope as being "server config" only, and follow up with
> "c->baser_server config" when possible (not a blocker for the first
> version).
>
>
> The docs explain the above here, which makes sense to me:
>
> While this directive may be specified in any virtual host, it is
> important to understand that because the proxy protocol is connection
> based and protocol agnostic, the enabling and disabling is actually
> based
> on ip-address and port. This means that if you have multiple name-based
> virtual hosts for the same host and port, and you enable it any one of
> them, then it is enabled for all them (with that host and port). It
> also
> means that if you attempt to enable the proxy protocol in one and
> disable
> in the other, that won't work; in such a case the last one wins and a
> notice will be logged indicating which setting was being
> overridden.
>
> Regards,
> Graham
> —
>
>

Re: something amiss in 2.4.x

[Yann Ylavic]

On Wed, Feb 14, 2018 at 6:08 PM, Stefan Eissing
 wrote:
>
> This looks not right, certainly? Seems like the balancer hook is not invoked 
> on the request. But later on connection release, it is?

Different PIDs, the error is in the main server while hcheck
(watchdog) is running.

>
> Not really the expert here. Need to run now, will check this again tomorrow.

You may need http://svn.apache.org/r1667707
Without it, I got strange mergings with your configuration (global
 ProxyPass'ed in ), where each global
balancer is added twice in the vhost config (the second is
empty/incomplete and makes SHMs names collide, so the first one gets
reset because of wrong sizes). Kind of "undefined behaviour" land, I
suppose :/

Re: something amiss in 2.4.x

[Stefan Eissing]

Adding
Index: modules/proxy/mod_proxy_balancer.c
===
--- modules/proxy/mod_proxy_balancer.c  (revision 1824256)
+++ modules/proxy/mod_proxy_balancer.c  (working copy)
@@ -1117,6 +1117,7 @@
 const char *action;
 apr_status_t rv;
 
+ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r, "check, if request for 
balancer");
 /* is this for us? */
 if (strcmp(r->handler, "balancer-manager")) {
 return DECLINED;

and config
LogLevel proxy:trace1
LogLevel proxy_balancer:trace1

I get for a request against https://test.example.org:12346/proxy/002.jpg

[Wed Feb 14 18:04:09.231668 2018] [proxy:trace1] [pid 62513:tid 
123145351254016] mod_proxy.c(749): [client 127.0.0.1:51975] AH03464: URI path 
'/proxy/002.jpg' matches proxy handler 'proxy:balancer://https-local/002.jpg', 
referer: https://test.example.org:12346/
[Wed Feb 14 18:04:09.231800 2018] [proxy_balancer:trace1] [pid 62513:tid 
123145351254016] mod_proxy_balancer.c(85): [client 127.0.0.1:51975] 
canonicalising URL //https-local/002.jpg, referer: 
https://test.example.org:12346/
[Wed Feb 14 18:04:09.231821 2018] [proxy_balancer:debug] [pid 62513:tid 
123145351254016] mod_proxy_balancer.c(632): [client 127.0.0.1:51975] AH01172: 
balancer://https-local: worker () rewritten to /002.jpg, referer: 
https://test.example.org:12346/
[Wed Feb 14 18:04:09.231830 2018] [proxy:debug] [pid 62513:tid 123145351254016] 
proxy_util.c(1772): AH00924: worker  shared already initialized
[Wed Feb 14 18:04:09.231837 2018] [proxy:debug] [pid 62513:tid 123145351254016] 
proxy_util.c(1814): AH00926: worker  local already initialized
[Wed Feb 14 18:04:09.231845 2018] [proxy:debug] [pid 62513:tid 123145351254016] 
mod_proxy.c(1229): [client 127.0.0.1:51975] AH01143: Running scheme balancer 
handler (attempt 0), referer: https://test.example.org:12346/
[Wed Feb 14 18:04:09.231854 2018] [proxy:warn] [pid 62513:tid 123145351254016] 
[client 127.0.0.1:51975] AH01144: No protocol handler was valid for the URL 
/proxy/002.jpg (scheme 'balancer'). If you are using a DSO version of 
mod_proxy, make sure the proxy submodules are included in the configuration 
using LoadModule., referer: https://test.example.org:12346/
[Wed Feb 14 18:04:09.231862 2018] [proxy_balancer:debug] [pid 62513:tid 
123145351254016] mod_proxy_balancer.c(689): [client 127.0.0.1:51975] AH01176: 
proxy_balancer_post_request for (balancer://https-local), referer: 
https://test.example.org:12346/
[Wed Feb 14 18:04:34.139205 2018] [proxy:debug] [pid 62476:tid 123145336594432] 
proxy_util.c(2154): AH00942: HCOH: has acquired connection for (127.0.0.1)
[Wed Feb 14 18:04:34.139506 2018] [proxy:debug] [pid 62476:tid 123145336594432] 
proxy_util.c(2883): AH02824: HCOH: connection established with 127.0.0.1:12345 
(127.0.0.1)
[Wed Feb 14 18:04:34.139546 2018] [proxy:debug] [pid 62476:tid 123145336594432] 
proxy_util.c(3053): AH00962: HCOH: connection complete to 127.0.0.1:12345 
(127.0.0.1)
[Wed Feb 14 18:04:34.139673 2018] [proxy_balancer:trace1] [pid 62513:tid 
123145356083200] mod_proxy_balancer.c(1120): [client 127.0.0.1:51985] check, if 
request for balancer
[Wed Feb 14 18:04:34.139876 2018] [proxy:debug] [pid 62476:tid 123145336594432] 
proxy_util.c(2169): AH00943: HCOH: has released connection for (127.0.0.1)

This looks not right, certainly? Seems like the balancer hook is not invoked on 
the request. But later on connection release, it is?

Not really the expert here. Need to run now, will check this again tomorrow.
Cheers,

-Stefan


> Am 14.02.2018 um 17:36 schrieb Yann Ylavic :
> 
> On Wed, Feb 14, 2018 at 5:16 PM, Stefan Eissing
>  wrote:
>> In my h2 test suite, I get on the 2.4.x branch a no longer working propxy 
>> setup.
>> 
>> error_log shows
>> [Wed Feb 14 17:11:35.996712 2018] [proxy:warn] [pid 69638:tid 
>> 123145425334272] [client 127.0.0.1:50616] AH01144: No protocol handler was 
>> valid for the URL /proxy/index.html (scheme 'balancer'). If you are using a 
>> DSO version of mod_proxy, make sure the proxy submodules are included in the 
>> configuration using LoadModule.
>> 
>> Same setup works flawlessly on trunk.
>> 
>> config basically is
>> 
>>
>>BalancerMember "http://127.0.0.1:12345"; hcmethod=GET hcuri=/
>>
>> 
>>
>> 
>>  ProxyPass "/proxy" "balancer://http-local"
>>  ProxyPassReverse "/proxy" "balancer://http-local"
>>
>> 
>> Compiled clean several times already. Did we miss something on the backport?
> 
> Hmm, this works here.
> Don't you have some builtin mod_proxy_* module (e.g.
> enable-proxy_balancer=static or alike)?

Re: something amiss in 2.4.x

[Yann Ylavic]

On Wed, Feb 14, 2018 at 5:16 PM, Stefan Eissing
 wrote:
> In my h2 test suite, I get on the 2.4.x branch a no longer working propxy 
> setup.
>
> error_log shows
> [Wed Feb 14 17:11:35.996712 2018] [proxy:warn] [pid 69638:tid 
> 123145425334272] [client 127.0.0.1:50616] AH01144: No protocol handler was 
> valid for the URL /proxy/index.html (scheme 'balancer'). If you are using a 
> DSO version of mod_proxy, make sure the proxy submodules are included in the 
> configuration using LoadModule.
>
> Same setup works flawlessly on trunk.
>
> config basically is
>
> 
> BalancerMember "http://127.0.0.1:12345"; hcmethod=GET hcuri=/
> 
>
> 
>
>   ProxyPass "/proxy" "balancer://http-local"
>   ProxyPassReverse "/proxy" "balancer://http-local"
> 
>
> Compiled clean several times already. Did we miss something on the backport?

Hmm, this works here.
Don't you have some builtin mod_proxy_* module (e.g.
enable-proxy_balancer=static or alike)?

Re: something amiss in 2.4.x

[Stefan Eissing]

balancer is loaded and has the same creation times than the others in my 
modules directory. hmm...

> Am 14.02.2018 um 17:19 schrieb Graham Leggett :
> 
> On 14 Feb 2018, at 6:16 PM, Stefan Eissing  
> wrote:
> 
>> In my h2 test suite, I get on the 2.4.x branch a no longer working propxy 
>> setup.
>> 
>> error_log shows
>> [Wed Feb 14 17:11:35.996712 2018] [proxy:warn] [pid 69638:tid 
>> 123145425334272] [client 127.0.0.1:50616] AH01144: No protocol handler was 
>> valid for the URL /proxy/index.html (scheme 'balancer'). If you are using a 
>> DSO version of mod_proxy, make sure the proxy submodules are included in the 
>> configuration using LoadModule.
> 
> Looks like mod_proxy_balancer module is missing from the test - did you 
> include mod_proxy_balancer in your v2.4.x build? I suspect httpd-test isn’t 
> skipping the test if mod_proxy_balancer doesn’t exist.
> 
> Regards,
> Graham
> —
> 

Re: something amiss in 2.4.x

[Graham Leggett]

On 14 Feb 2018, at 6:16 PM, Stefan Eissing  wrote:

> In my h2 test suite, I get on the 2.4.x branch a no longer working propxy 
> setup.
> 
> error_log shows
> [Wed Feb 14 17:11:35.996712 2018] [proxy:warn] [pid 69638:tid 
> 123145425334272] [client 127.0.0.1:50616] AH01144: No protocol handler was 
> valid for the URL /proxy/index.html (scheme 'balancer'). If you are using a 
> DSO version of mod_proxy, make sure the proxy submodules are included in the 
> configuration using LoadModule.

Looks like mod_proxy_balancer module is missing from the test - did you include 
mod_proxy_balancer in your v2.4.x build? I suspect httpd-test isn’t skipping 
the test if mod_proxy_balancer doesn’t exist.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

something amiss in 2.4.x

[Stefan Eissing]

In my h2 test suite, I get on the 2.4.x branch a no longer working propxy setup.

error_log shows
[Wed Feb 14 17:11:35.996712 2018] [proxy:warn] [pid 69638:tid 123145425334272] 
[client 127.0.0.1:50616] AH01144: No protocol handler was valid for the URL 
/proxy/index.html (scheme 'balancer'). If you are using a DSO version of 
mod_proxy, make sure the proxy submodules are included in the configuration 
using LoadModule.

Same setup works flawlessly on trunk.

config basically is


BalancerMember "http://127.0.0.1:12345"; hcmethod=GET hcuri=/




  ProxyPass "/proxy" "balancer://http-local"
  ProxyPassReverse "/proxy" "balancer://http-local"


Compiled clean several times already. Did we miss something on the backport?

-Stefan

Re: svn commit: r1824221 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Yann Ylavic]

On Wed, Feb 14, 2018 at 11:55 AM,   wrote:
> Author: minfrin
> Date: Wed Feb 14 10:55:44 2018
> New Revision: 1824221
>
> URL: http://svn.apache.org/viewvc?rev=1824221&view=rev
> Log:
> mod_remoteip: Add PROXY protocol support
> trunk patch: http://svn.apache.org/r1776575
>  http://svn.apache.org/r1776578 (doc fix)
>  http://svn.apache.org/r1776624
>  http://svn.apache.org/r1776627 (shortened name + doc fix)
>  http://svn.apache.org/r1776674 (attribution moved to CHANGES)
>  http://svn.apache.org/r1776734
>  http://svn.apache.org/r1776740 (attribution updated in 
> mod_remotip.c)
>  http://svn.apache.org/r1778268 (fix compiler warning)
>  http://svn.apache.org/r1780725 (set buckets aside)
>  http://svn.apache.org/r1781030 (fix strict GCC warning)
>  http://svn.apache.org/r1781031 (reference the filter by handle)
>  http://svn.apache.org/r1781701 (rework optional processing case)
>  http://svn.apache.org/r1788674 (final edge cases/ignore slave 
> conns)
>  http://svn.apache.org/r1789800 (remove optional processing)
>  http://svn.apache.org/r1790169 (rename "exception" directive)
>  http://svn.apache.org/r1790457 (Update directive name in err 
> message)
>  http://svn.apache.org/r1790691
>  http://svn.apache.org/r1806985
>  http://svn.apache.org/r1818279
> 2.4 convenience patch (includes CHANGES):
>  
> http://home.apache.org/~ylavic/patches/RemoteIPProxyProtocol.2.4-v3.patch
> +1: druggeri, jim, minfrin
>
> Modified:
> httpd/httpd/branches/2.4.x/   (props changed)
> httpd/httpd/branches/2.4.x/CHANGES
> httpd/httpd/branches/2.4.x/STATUS
> httpd/httpd/branches/2.4.x/docs/manual/mod/mod_remoteip.xml
> httpd/httpd/branches/2.4.x/modules/metadata/mod_remoteip.c

Somehow this commit does not correspond to v3 patch above (nor with trunk code).
For instance there are some reminiscence from
RemoteIPProxyProtocolEnable optional (old name and option).
Needs to be reverted, will do...


Regards,
Yann.

Apache EU Roadshow CFP Closing Soon (23 February)

[Sharan F]

Hello Everyone

This is an initial reminder to let you all know that we are holding an 
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and 
14^th June 2018. https://s.apache.org/tCHx


The Call for Proposals (CFP) for the Apache EU Roadshow is currently 
open and will close at the end of next week, so if you have been 
delaying making a submission because the closing date seemed a long way 
off, then it's time to start getting your proposals submitted.


So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so 
are looking for projects including incubating ones, to submit 
presentations, panel discussions, BoFs, or workshop proposals. The main 
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your 
project is involved in or around any of these technologies at Apache 
then we are very interested in hearing from you.


Community and collaboration is important at Apache so if your project is 
interested in organising a project sprint, meetup or hackathon during 
the Roadshow, then please submit it inthe CFP as we do have some space 
available to allocate for these.


If you are wanting to submit a talk on open source community related 
topics such as the Apache Way, governance or legal aspects then please 
submit these to the CFP for FOSS Backstage.


Tickets for the Apache EU Roadshow are included as part of the 
registration for FOSS Backstage, so to attend the Roadshow you will need 
to register for FOSS Backstage. Early Bird tickets are still available 
until the 21^st February 2018.


Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow 
:http://apachecon.com/euroadshow18/ 


-  To submit a CFP for FOSS Backstage : 
https://foss-backstage.de/call-papers


-  To register to attend the Apache EU Roadshow and/or FOSS Backstage : 
https://foss-backstage.de/tickets


For further updates and information about the Apache EU Roadshowplease 
check http://apachecon.com/euroadshow18/


Thanks
Sharan Foga, VP Apache Community Development

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[Stefan Eissing]

I had a patch posted here on Monday that introduces


   ...
   
   


with a server_rec and configs between base server and a a set of 
vhosts. Would that satisfy your needs for this?

-Stefan

> Am 14.02.2018 um 14:39 schrieb Graham Leggett :
> 
> On 14 Feb 2018, at 3:05 PM, Yann Ylavic  wrote:
> 
>> It makes sense, and actually I missed some logic w.r.t.
>> enabled/disabled being a list of sockaddrs (based on servers'
>> server_addr_rec, and not a global boolean as I first thought...). This
>> is later compared to incoming connections local addr.
>> Let me grok that... but at first glance it looks quite cumbersome, why
>> not the usual server merging and a simple "enabled" boolean?
>> If we only care about the config of the base server,
>> "ap_get_module_config(c->base_server->module_config,
>> &remoteip_module)" could do it no?
>> For now it seems that all the vhost selection logic is duplicated, but
>> indeed it's not global (nor really per vhost, but yes this is thee
>> scope which comes closest).
> 
> I think the problem distills down to our config lacking an explicit 
> configuration container for the IP address and port, something like this:
> 
> # global
> 
> # per port
> RemoteIPProxyProtocol on
> 
>   # per virtual host
> 
> 
> 
> In the absence of a Bind directive (or equivalent) we’re left with this 
> undesirable config:
> 
> # global, yuck
> RemoteIPProxyProtocol on
> 
> # per virtual host
> 
> 
> So we’ve compromised and said we’ll accept this config:
> 
> 
>   # per port
>   RemoteIPProxyProtocol on
>   # per virtual host
> 
> 
> To set RemoteIPProxyProtocol, we have to jump up one level to get 
> server_addr_rec, walk the list of matching IP addresses on virtual hosts and 
> setting (or not) as appropriate.
> 
> Regards,
> Graham
> —
> 

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[Graham Leggett]

On 14 Feb 2018, at 3:05 PM, Yann Ylavic  wrote:

> It makes sense, and actually I missed some logic w.r.t.
> enabled/disabled being a list of sockaddrs (based on servers'
> server_addr_rec, and not a global boolean as I first thought...). This
> is later compared to incoming connections local addr.
> Let me grok that... but at first glance it looks quite cumbersome, why
> not the usual server merging and a simple "enabled" boolean?
> If we only care about the config of the base server,
> "ap_get_module_config(c->base_server->module_config,
> &remoteip_module)" could do it no?
> For now it seems that all the vhost selection logic is duplicated, but
> indeed it's not global (nor really per vhost, but yes this is thee
> scope which comes closest).

I think the problem distills down to our config lacking an explicit 
configuration container for the IP address and port, something like this:

# global

# per port
RemoteIPProxyProtocol on

  # per virtual host



In the absence of a Bind directive (or equivalent) we’re left with this 
undesirable config:

# global, yuck
RemoteIPProxyProtocol on

# per virtual host


So we’ve compromised and said we’ll accept this config:


  # per port
  RemoteIPProxyProtocol on
  # per virtual host


To set RemoteIPProxyProtocol, we have to jump up one level to get 
server_addr_rec, walk the list of matching IP addresses on virtual hosts and 
setting (or not) as appropriate.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

T&R of 2.4.30 Proposal

[Jim Jagielski]

I propose a T&R of 2.4.30 on Feb 19th. I offer to RM
unless someone else would like to do so.

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

On Wed, Feb 14, 2018 at 1:28 PM, Graham Leggett  wrote:
> On 14 Feb 2018, at 1:03 PM, Yann Ylavic  wrote:
>>
>> The docs talk about connection based config, while ap_server_conf is
>> really the main server config.
>> The code should be improved to be based on c->baser_server config
>> (with merging of RemoteIPProxyProtocol*), unless I'm missing something
>> it seems (as of now) that the directives overwrite each other when
>> used in vhost context (not only for name-based vhosts).
>> So now (or post-backport) I think we should at least document the
>> scope as being "server config" only, and follow up with
>> "c->baser_server config" when possible (not a blocker for the first
>> version).
>
> The docs explain the above here, which makes sense to me:
>
> While this directive may be specified in any virtual host, it is
> important to understand that because the proxy protocol is connection
> based and protocol agnostic, the enabling and disabling is actually
> based
> on ip-address and port. This means that if you have multiple name-based
> virtual hosts for the same host and port, and you enable it any one of
> them, then it is enabled for all them (with that host and port). It also
> means that if you attempt to enable the proxy protocol in one and
> disable
> in the other, that won't work; in such a case the last one wins and a
> notice will be logged indicating which setting was being overridden.

It makes sense, and actually I missed some logic w.r.t.
enabled/disabled being a list of sockaddrs (based on servers'
server_addr_rec, and not a global boolean as I first thought...). This
is later compared to incoming connections local addr.
Let me grok that... but at first glance it looks quite cumbersome, why
not the usual server merging and a simple "enabled" boolean?
If we only care about the config of the base server,
"ap_get_module_config(c->base_server->module_config,
&remoteip_module)" could do it no?
For now it seems that all the vhost selection logic is duplicated, but
indeed it's not global (nor really per vhost, but yes this is thee
scope which comes closest).


Regards,
Yann.

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[Graham Leggett]

On 14 Feb 2018, at 2:43 PM, Jim Jagielski  wrote:

> ++1!
> 
> BTW: I'm fine with removing the hostname field in trunk and just having/using 
> hostname_ex

Agreed. Will do that after the backport is done.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Time for 2.4.30? (Was: Re: 2.4.x STATUS needs you!)

[Graham Leggett]

On 14 Feb 2018, at 2:40 PM, Jim Jagielski  wrote:

> Yes... there are/were a few backports which are/were lacking
> a single vote…

We’re down to these ones left:

 +1: jim, minfrin
 +1: jailletc36, minfrin
 +1: minfrin

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[Jim Jagielski]

++1!

BTW: I'm fine with removing the hostname field in trunk and just having/using 
hostname_ex

> On Feb 13, 2018, at 9:19 AM, Graham Leggett  wrote:
> 
> On 09 Feb 2018, at 7:12 AM, William A Rowe Jr  > wrote:
> 
>> [Why] would you compare 8192 byte strings as identifiers?
> 
> I just checked the code, and as I suspected the “name” field isn’t a name, or 
> an identifier, it’s actually a URL prefix.
> 
> When a balancer is found to match, the “balancer:foo” is removed, and 
> replaced by the name, with the rest of the URL postfixed to it.
> 
> As you can see - we’re currently arbitrarily limiting the length of the URL 
> prefix to 256 characters, because 640k is big enough for everybody.
> 
>> On Feb 8, 2018 2:39 PM, "Jim Jagielski" > > wrote:
>> Another, much more extensive and intrusive fix would be to create
>> each ind field dynamically and tuck away in the  proxy_worker_shared
>> struct the SHM field to be attached to which holds the actual dynamically
>> allocated string. Better on SHM usage (our current usage is sloppy regarding
>> SHM utilization due to the fixed char arrays, most of which aren't
>> full) but more complex in other ways.
>> 
>> Idea would be to use the actual name and generate a hash from
>> that, use the hash as the SHM filename, create the SHM using
>> that filename (hash) to dynamically allocate the host string
>> and then store in proxy_worker_shared the hash (filename) used.
>> Attach to that SHM as needed.
>> 
>> Cleanup would need some thought…
> 
> Another option for the name is to store a URL prefix length and a hash of the 
> prefix. If the hash of the prefix matches, we have a match. Would this work, 
> would it be too expensive to hash on every hit, would it be safe enough?
> 
> For the hostname, the field only has to be 256 characters long (because 
> RFC1035 says it must be) and that’s manageable. I have created a patch to do 
> this and it works for me.
> 
> Regards,
> Graham
> —
> 

Re: Time for 2.4.30? (Was: Re: 2.4.x STATUS needs you!)

[Jim Jagielski]

Yes... there are/were a few backports which are/were lacking
a single vote...

> On Feb 13, 2018, at 1:23 PM, Nic Jansma  wrote:
> 
> Are there still plans to push for a 2.4.30 soon?  There's a couple bug fixes 
> in it that I'd love to have in the official builds!
> 
> Thanks,
> 
> - Nic
> 
> On 2018/01/04 12:43:12, Jim Jagielski  
>  wrote: 
> > As we get settled into the new year, it seems a good time> 
> > to think about a 2.4.30 release in the coming week or> 
> > so. Lots of good stuff currently in 2.4.30-dev and even> 
> > more good stuff in STATUS awaiting a single vote!> 
> > 
> > Let's see if we can clean-up STATUS, get 2.4.30-dev into> 
> > fantastic shape, and "commit" to doing a release no later> 
> > than mid Jan.> 
> > 
> > I volunteer to RM and/or help someone else RM.> 
> > 

Re: Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[Graham Leggett]

On 14 Feb 2018, at 1:03 PM, Yann Ylavic  wrote:

> The docs talk about connection based config, while ap_server_conf is
> really the main server config.
> The code should be improved to be based on c->baser_server config
> (with merging of RemoteIPProxyProtocol*), unless I'm missing something
> it seems (as of now) that the directives overwrite each other when
> used in vhost context (not only for name-based vhosts).
> So now (or post-backport) I think we should at least document the
> scope as being "server config" only, and follow up with
> "c->baser_server config" when possible (not a blocker for the first
> version).

The docs explain the above here, which makes sense to me:

While this directive may be specified in any virtual host, it is
important to understand that because the proxy protocol is connection
based and protocol agnostic, the enabling and disabling is actually based
on ip-address and port. This means that if you have multiple name-based
virtual hosts for the same host and port, and you enable it any one of
them, then it is enabled for all them (with that host and port). It also
means that if you attempt to enable the proxy protocol in one and disable
in the other, that won't work; in such a case the last one wins and a
notice will be logged indicating which setting was being overridden.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Scope of RemoteIPProxyProtocol* (was: svn commit: r1824211 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

On Wed, Feb 14, 2018 at 11:21 AM,   wrote:
>
>*) mod_remoteip: Add PROXY protocol support
[]
>   ylavic: RemoteIPProxyProtocol* are documented as scoped to server config
>   and virtual host, though using ap_server_conf makes them global
>   only (thus less useful too...).
>  jim: Can docco patch be post-backport?
>   minfrin: The docs seem correct, and there is a long explanation in the 
> docs of
>why the scoping is as it is.

The docs talk about connection based config, while ap_server_conf is
really the main server config.
The code should be improved to be based on c->baser_server config
(with merging of RemoteIPProxyProtocol*), unless I'm missing something
it seems (as of now) that the directives overwrite each other when
used in vhost context (not only for name-based vhosts).
So now (or post-backport) I think we should at least document the
scope as being "server config" only, and follow up with
"c->baser_server config" when possible (not a blocker for the first
version).


Regards,
Yann.