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

[Jim Jagielski]

No.

> On Feb 7, 2018, at 2:08 PM, William A Rowe Jr  wrote:
> 
> On Wed, Feb 7, 2018 at 1:01 PM, Jim Jagielski  wrote:
>> 
>> On Feb 7, 2018, at 1:41 PM, Graham Leggett  wrote:
>> 
>> On 07 Feb 2018, at 8:34 PM, William A Rowe Jr  wrote:
>> 
>> So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no
>> - it is doesn't seem we established an ABI contract. The pairing of
>> httpd-2.4.30
>> and the 2.4.30 mod_proxy_balancer are obviously in-sync.
>> 
>> 
>> Digging through the code, the struct proxy_worker_shared is used by the
>> ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in
>> proxy_util.c and therefore mod_proxy.so.
>> 
>> The only user of these two functions is mod_proxy_balancer - so this looks
>> safe as per your definition above.
>> 
>> We need to document whether the name, scheme and hostname fields in
>> proxy_worker_shared are intended for debugging purposes only (ie logging,
>> status, errors) and are therefore safe to truncate or whether they can be
>> used programmatically. I don’t see anything in mod_proxy_balancer that
>> references these fields.
>> 
>> IIRC, it's just for mod_status output. Nothing programmatic.
> 
> As an external representation - if mod_status is compiled against 2.4.29,
> will it crash with this backport?

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

[William A Rowe Jr]

On Wed, Feb 7, 2018 at 1:01 PM, Jim Jagielski  wrote:
>
> On Feb 7, 2018, at 1:41 PM, Graham Leggett  wrote:
>
> On 07 Feb 2018, at 8:34 PM, William A Rowe Jr  wrote:
>
> So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no
> - it is doesn't seem we established an ABI contract. The pairing of
> httpd-2.4.30
> and the 2.4.30 mod_proxy_balancer are obviously in-sync.
>
>
> Digging through the code, the struct proxy_worker_shared is used by the
> ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in
> proxy_util.c and therefore mod_proxy.so.
>
> The only user of these two functions is mod_proxy_balancer - so this looks
> safe as per your definition above.
>
> We need to document whether the name, scheme and hostname fields in
> proxy_worker_shared are intended for debugging purposes only (ie logging,
> status, errors) and are therefore safe to truncate or whether they can be
> used programmatically. I don’t see anything in mod_proxy_balancer that
> references these fields.
>
> IIRC, it's just for mod_status output. Nothing programmatic.

As an external representation - if mod_status is compiled against 2.4.29,
will it crash with this backport?

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

[Jim Jagielski]

> On Feb 7, 2018, at 1:41 PM, Graham Leggett  wrote:
> 
> On 07 Feb 2018, at 8:34 PM, William A Rowe Jr  > wrote:
> 
>> So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no
>> - it is doesn't seem we established an ABI contract. The pairing of
>> httpd-2.4.30
>> and the 2.4.30 mod_proxy_balancer are obviously in-sync.
> 
> Digging through the code, the struct proxy_worker_shared is used by the 
> ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in 
> proxy_util.c and therefore mod_proxy.so.
> 
> The only user of these two functions is mod_proxy_balancer - so this looks 
> safe as per your definition above.
> 
> We need to document whether the name, scheme and hostname fields in 
> proxy_worker_shared are intended for debugging purposes only (ie logging, 
> status, errors) and are therefore safe to truncate or whether they can be 
> used programmatically. I don’t see anything in mod_proxy_balancer that 
> references these fields.
> 

IIRC, it's just for mod_status output. Nothing programmatic.

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

[William A Rowe Jr]

On Wed, Feb 7, 2018 at 12:45 PM, Graham Leggett  wrote:
> On 07 Feb 2018, at 8:36 PM, William A Rowe Jr  wrote:
>
> But there is no argument for a name identifier >255 characters ... the cited
> RFC
> and the filesystem and so many others use this as the conventional
> constraint
> on an identifier.
>
> Why double that?
>
>
> Because the part of the URL that matters to the admin might be at the end,
> as in Dirk’s example. If we’ve consumed the whole length on the hostname, we
> leave nothing for the URL itself.
>
> Eg: https://very-very-long-hostname/foo/bar/baz/veryimportant1 and
> https://very-very-long-hostname/foo/bar/baz/veryimportant2
>
> The burning question is - are these fields only used for debugging, and
> therefore an approximation is fine, or are they used for something else
> where precision is required?

In order to find the slot, we need to strcmp. 512 is arbitrary, does this
become an 8192 byte identifier? Or do we insist people distill names to
fit into a schema, much like DNS or file names, as the *identifier*?

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

[Graham Leggett]

On 07 Feb 2018, at 8:36 PM, William A Rowe Jr  wrote:

> But there is no argument for a name identifier >255 characters ... the cited 
> RFC
> and the filesystem and so many others use this as the conventional constraint
> on an identifier.
> 
> Why double that?

Because the part of the URL that matters to the admin might be at the end, as 
in Dirk’s example. If we’ve consumed the whole length on the hostname, we leave 
nothing for the URL itself.

Eg: https://very-very-long-hostname/foo/bar/baz/veryimportant1 and 
https://very-very-long-hostname/foo/bar/baz/veryimportant2

The burning question is - are these fields only used for debugging, and 
therefore an approximation is fine, or are they used for something else where 
precision is required?

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

[Graham Leggett]

On 07 Feb 2018, at 8:34 PM, William A Rowe Jr  wrote:

> So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no
> - it is doesn't seem we established an ABI contract. The pairing of
> httpd-2.4.30
> and the 2.4.30 mod_proxy_balancer are obviously in-sync.

Digging through the code, the struct proxy_worker_shared is used by the 
ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in 
proxy_util.c and therefore mod_proxy.so.

The only user of these two functions is mod_proxy_balancer - so this looks safe 
as per your definition above.

We need to document whether the name, scheme and hostname fields in 
proxy_worker_shared are intended for debugging purposes only (ie logging, 
status, errors) and are therefore safe to truncate or whether they can be used 
programmatically. I don’t see anything in mod_proxy_balancer that references 
these fields.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)

[William A Rowe Jr]

Is the sapi compiled against libtool etc. from httpd? Or is it using the
configure logic shipped with the php package?

In any case, asking httpd/apr to conform to the autoconf/libtool
packaging of php, which was built using its own flavor of the toolchain
seems inconsistent.

It seems foolish to ask httpd-apxs to be the install tool of the libphp5
binary. These are two different packages with two different sets of
tooling. If you simply fix the make install to point to the build/install.sh
tool of php, does it all work?



On Wed, Feb 7, 2018 at 8:50 AM, Michael  wrote:
> a) It has been a hard climb to get httpd-2.4.29 to build using the latest
> apr and apr-util. Still researching what that is (might be expat related -
> embedded versus external, still searching). Anyway, working with apr-1.5.2 I
> was at least able to get httpd-2.4.29 to build so I could proceed to my
> other "forever" hassle.
>
> b) the forever "hassle": over the years (the first time I posted "a bug may
> be as far back as 2010", not bothering to post before then (or it was
> working??) - was getting "make install" to work for PHP.
>
> c) PHP stated correctly - not them - would be instdso.sh. Also posted, but
> not conclusive. I hacked at instdso - as it knew what to remove (rm -f) but
> did not install. I just hard-wired it to copy the file, if, at the end, it
> was not there. With that, the chmod command that follows instdso.sh works.
>
> Quick History, better review:
>
> Currently:
>
> root@x065:[/data/prj/php/php-5.3.29]make install-sapi
> Installing PHP SAPI module:   apache2handler
> /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin
> if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then  for i
> in 0.0.0 0.0 0; do  if test -r /data/prj/php/php-5.3.29/libs/libphp5.so.$i;
> then  ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i
> /data/prj/php/php-5.3.29/libs/libphp5.so;  break;  fi;  done; fi
> /data/prj/php/src/php-5.3.29/build/shtool mkdir -p
> '/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir -p
> '/var/httpd/etc' && /opt/httpd/bin/apxs -S LIBEXECDIR='/opt/httpd/libexec'
> -S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la
> Use of uninitialized value in concatenation (.) or string at
> /opt/httpd/bin/apxs line 222.
> /var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la
> /opt/httpd/libexec
> rm -f /opt/httpd/libexec/libphp5.so
> /opt/build-1/libtool --mode=install install libphp5.la /opt/httpd/libexec/
> libtool: install: install .libs/libphp5.a /opt/httpd/libexec/libphp5.a
> libtool: install: install .libs/libphp5.lai /opt/httpd/libexec/libphp5.la
> libtool: install: warning: remember to run `libtool --finish
> /data/prj/php/php-5.3.29/libs'
> chmod 755 /opt/httpd/libexec/libphp5.so
> chmod: /opt/httpd/libexec/libphp5.so: A file or directory in the path name
> does not exist.
> apxs:Error: Command failed with rc=65536
> .
> make: 1254-004 The error code from the last command is 1.
>
>  I think I have it!! 
> With one small change: (/opt/build-1/libtool apr-1.5.2)
>  +3403  # See the names of the shared library.
>  +3404  set dummy $dlname $library_names; shift
>
> root@x065:[/data/prj/php/php-5.3.29]make install-sapi
> Installing PHP SAPI module:   apache2handler
> /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin
> if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then  for i
> in 0.0.0 0.0 0; do  if test -r /data/prj/php/php-5.3.29/libs/libphp5.so.$i;
> then  ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i
> /data/prj/php/php-5.3.29/libs/libphp5.so;  break;  fi;  done; fi
> /data/prj/php/src/php-5.3.29/build/shtool mkdir -p
> '/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir -p
> '/var/httpd/etc' && /opt/httpd/bin/apxs -S LIBEXECDIR='/opt/httpd/libexec'
> -S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la
> Use of uninitialized value in concatenation (.) or string at
> /opt/httpd/bin/apxs line 222.
> /var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la
> /opt/httpd/libexec
> rm -f /opt/httpd/libexec/libphp5.so
> /opt/build-1/libtool --mode=install install libphp5.la /opt/httpd/libexec/
> libtool: install: install .libs/libphp5.so /opt/httpd/libexec/libphp5.so
> libtool: install: (cd /opt/httpd/libexec && { ln -s -f libphp5.so libphp5.a
> || { rm -f libphp5.a && ln -s libphp5.so libphp5.a; }; })
> libtool: install: (cd /opt/httpd/libexec && { ln -s -f libphp5.so libphp5.a
> || { rm -f libphp5.a && ln -s libphp5.so libphp5.a; }; })
> libtool: install: install .libs/libphp5.lai /opt/httpd/libexec/libphp5.la
> libtool: install: warning: remember to run `libtool --finish
> /data/prj/php/php-5.3.29/libs'
> chmod 755 /opt/httpd/libexec/libphp5.so
> [activating module `php5' in /var/httpd/etc/httpd.conf]
>
>  So, I suspect the actual 'bug' is in libtool (this embedded version was
> 2.4.2). FYI, the base statement (where I can fix

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

[William A Rowe Jr]

On Wed, Feb 7, 2018 at 11:39 AM, Graham Leggett  wrote:
> On 07 Feb 2018, at 7:04 PM, William A Rowe Jr  wrote:
>
> These are fixed shm strings, IIRC? How is a balancer name >256
> characters usable in anything but automated strings, and the example
> given by Dirk uses nowhere near 256 chars.
>
>
> We’re using automated strings.
>
> The balancer name is a URL, the URL contains a hostname, the hostname length
> is governed by RFC1035. The hostname needs to be at least 256 (255 plus
> null), and therefore the URL needs to be at least 255 plus extra to cover
> the rest of the URL, which given we allow 8192 as an URL length elsewhere in
> the server, we should actually allow 8196 byte URLs, therefore 8192 byte
> names.
>
> From a diagnostics/debugging perspective, nothing is conveyed in a
> balancer name > 256 (realistically, >80, because it is a single token,
> but lets be consistent...) that the human can benefit from.
>
> In the automated configuration case, at some point, you devolve too
> much extra data down to a UUID that will be distinct, and be done with
> it, much as Dirk's example illustrates.
>
>
> In our automated configuration case we have a system with a name, and we
> want an Apache load balancer to expose an URL on that system with that name.
> The name of that system is not under our control.

But there is no argument for a name identifier >255 characters ... the cited RFC
and the filesystem and so many others use this as the conventional constraint
on an identifier.

Why double that?

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

[William A Rowe Jr]

On Wed, Feb 7, 2018 at 11:33 AM, Jim Jagielski  wrote:
> So can I assume that a backport req to bump-up the field sizes to, at least,
> what is in trunk, would not be vetoed?

So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no
 - it is doesn't seem we established an ABI contract. The pairing of
httpd-2.4.30
and the 2.4.30 mod_proxy_balancer are obviously in-sync.

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

[Yann Ylavic]

On Wed, Feb 7, 2018 at 6:33 PM, Jim Jagielski  wrote:
> So can I assume that a backport req to bump-up the field sizes to, at least,
> what is in trunk, would not be vetoed?

Not by me, +1.

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

[Graham Leggett]

On 07 Feb 2018, at 7:04 PM, William A Rowe Jr  wrote:

> These are fixed shm strings, IIRC? How is a balancer name >256
> characters usable in anything but automated strings, and the example
> given by Dirk uses nowhere near 256 chars.

We’re using automated strings.

The balancer name is a URL, the URL contains a hostname, the hostname length is 
governed by RFC1035. The hostname needs to be at least 256 (255 plus null), and 
therefore the URL needs to be at least 255 plus extra to cover the rest of the 
URL, which given we allow 8192 as an URL length elsewhere in the server, we 
should actually allow 8196 byte URLs, therefore 8192 byte names.

> From a diagnostics/debugging perspective, nothing is conveyed in a
> balancer name > 256 (realistically, >80, because it is a single token,
> but lets be consistent...) that the human can benefit from.
> 
> In the automated configuration case, at some point, you devolve too
> much extra data down to a UUID that will be distinct, and be done with
> it, much as Dirk's example illustrates.

In our automated configuration case we have a system with a name, and we want 
an Apache load balancer to expose an URL on that system with that name. The 
name of that system is not under our control.

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]

So can I assume that a backport req to bump-up the field sizes to, at least,
what is in trunk, would not be vetoed?

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

[Jim Jagielski]

> On Feb 7, 2018, at 12:04 PM, William A Rowe Jr  wrote:
> 
> On Wed, Feb 7, 2018 at 9:07 AM, Jim Jagielski  > wrote:
>> Personally, I still think that updating these fields for 2.4.x
>> makes sense and can be justified... but am in no mood
>> for a battle *grin*
> 
> As long as the change allows you to compile the backport and rebuild
> mod_proxy_balancer *alone*... without needing to rebuild all of the
> consumers, then your change is likely similarly safe for third party
> modules consuming our API.

Just mod_proxy_balancer and proxy_util...

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

[William A Rowe Jr]

On Wed, Feb 7, 2018 at 10:46 AM, Graham Leggett  wrote:
> On 07 Feb 2018, at 5:34 PM, Dirk-Willem van Gulik 
> wrote:
>
> Not sure how this broke on your end - but the cases where I had it break on
> me in production where all cases where things were generated and dynamically
> registered with some sort of ``service-zone-status-etc- address>’’ thing:
>
> casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002
>
> so chopping of the end is a bit painful.
>
>
> Ideally the hostname should be 256 to match RFC1035, and the balancer name
> be larger still to accommodate (512? larger?), but recognise the pain of
> being able to backport it.

These are fixed shm strings, IIRC? How is a balancer name >256
characters usable in anything but automated strings, and the example
given by Dirk uses nowhere near 256 chars.

>From a diagnostics/debugging perspective, nothing is conveyed in a
balancer name > 256 (realistically, >80, because it is a single token,
but lets be consistent...) that the human can benefit from.

In the automated configuration case, at some point, you devolve too
much extra data down to a UUID that will be distinct, and be done with
it, much as Dirk's example illustrates.

On Wed, Feb 7, 2018 at 9:07 AM, Jim Jagielski  wrote:
> Personally, I still think that updating these fields for 2.4.x
> makes sense and can be justified... but am in no mood
> for a battle *grin*

As long as the change allows you to compile the backport and rebuild
mod_proxy_balancer *alone*... without needing to rebuild all of the
consumers, then your change is likely similarly safe for third party
modules consuming our API.

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

[Graham Leggett]

On 07 Feb 2018, at 5:33 PM, Jim Jagielski  wrote:

> +1 on removing that as fatal as well... I'll fix trunk and propose
> for backport

Something like this?

Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c  (revision 1823472)
+++ modules/proxy/proxy_util.c  (working copy)
@@ -1727,7 +1727,8 @@
 return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
 }
 if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
-return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO()
+"Alert! worker hostname (%s) too long; truncated to: %s", 
uri.hostname, wshared->hostname);
 }
 wshared->flush_packets = flush_off;
 wshared->flush_wait = PROXY_FLUSH_WAIT;

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

[Graham Leggett]

On 07 Feb 2018, at 5:34 PM, Dirk-Willem van Gulik  wrote:

> Not sure how this broke on your end - but the cases where I had it break on 
> me in production where all cases where things were generated and dynamically 
> registered with some sort of ``service-zone-status-etc- address>’’ thing:
> 
>   
> casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002
> 
> so chopping of the end is a bit painful.

Ideally the hostname should be 256 to match RFC1035, and the balancer name be 
larger still to accommodate (512? larger?), but recognise the pain of being 
able to backport it.

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

[Dirk-Willem van Gulik]

> On 7 Feb 2018, at 16:24, Graham Leggett  wrote:
> 
> On 07 Feb 2018, at 5:18 PM, Graham Leggett  wrote:
> 
>> Looking back through the archives, looks like that backport was already 
>> accepted:
>> 
>> http://svn.apache.org/viewvc?view=revision&revision=1634520
> 
> Hmmm… it’s actually only solved the URL too long problem, the hostname too 
> long problem is still a fatal error:
> 
> ptr = apr_uri_unparse(p, &uri, APR_URI_UNP_REVEALPASSWORD);
> if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
> "Alert! worker name (%s) too long; truncated to: %s", ptr, 
> wshared->name
> );
> }
> if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
> return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
> }
> if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
> return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
> }
> 
> Would this break if we did the same warning on hostname that’s done on the 
> full URL?

Not sure how this broke on your end - but the cases where I had it break on me 
in production where all cases where things were generated and dynamically 
registered with some sort of ``service-zone-status-etc-’’ thing:


casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002

so chopping of the end is a bit painful.

Dw.


signature.asc
Description: Message signed with OpenPGP

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

[Jim Jagielski]

> On Feb 7, 2018, at 10:24 AM, Graham Leggett  wrote:
> 
> On 07 Feb 2018, at 5:18 PM, Graham Leggett  > wrote:
> 
>> Looking back through the archives, looks like that backport was already 
>> accepted:
>> 
>> http://svn.apache.org/viewvc?view=revision&revision=1634520 
>> 
> 
> Hmmm… it’s actually only solved the URL too long problem, the hostname too 
> long problem is still a fatal error:
> 
> ptr = apr_uri_unparse(p, &uri, APR_URI_UNP_REVEALPASSWORD);
> if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
> "Alert! worker name (%s) too long; truncated to: %s", ptr, 
> wshared->name
> );
> }
> if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
> return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
> }
> if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
> return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
> }
> 
> Would this break if we did the same warning on hostname that’s done on the 
> full URL?
> 

+1 on removing that as fatal as well... I'll fix trunk and propose
for backport

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

[Graham Leggett]

On 07 Feb 2018, at 5:18 PM, Graham Leggett  wrote:

> Looking back through the archives, looks like that backport was already 
> accepted:
> 
> http://svn.apache.org/viewvc?view=revision&revision=1634520

Hmmm… it’s actually only solved the URL too long problem, the hostname too long 
problem is still a fatal error:

ptr = apr_uri_unparse(p, &uri, APR_URI_UNP_REVEALPASSWORD);
if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
"Alert! worker name (%s) too long; truncated to: %s", ptr, wshared->name
);
}
if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
}
if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
}

Would this break if we did the same warning on hostname that’s done on the full 
URL?

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]

PS: Want to propose it for back port, or should I? ;)

> On Feb 7, 2018, at 10:16 AM, Jim Jagielski  wrote:
> 
> 
> 
>> On Feb 7, 2018, at 10:07 AM, Graham Leggett  wrote:
>> 
>> 
>> In theory, the “accept a truncated value” will work around the problem and 
>> be backport-able, is that true?
> 
> +1 (assuming the truncated value is unique)

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

[Graham Leggett]

On 07 Feb 2018, at 5:16 PM, Jim Jagielski  wrote:

>> In theory, the “accept a truncated value” will work around the problem and 
>> be backport-able, is that true?
> 
> +1 (assuming the truncated value is unique)

Looking back through the archives, looks like that backport was already 
accepted:

http://svn.apache.org/viewvc?view=revision&revision=1634520

I suspect my problem is that upstream (Ubuntu in this case) hasn’t picked up 
the changes.

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]

> On Feb 7, 2018, at 10:07 AM, Graham Leggett  wrote:
> 
> 
> In theory, the “accept a truncated value” will work around the problem and be 
> backport-able, is that true?

+1 (assuming the truncated value is unique)

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

[Graham Leggett]

On 07 Feb 2018, at 5:04 PM, Jim Jagielski  wrote:

> I believe the issue are the various defines in
> mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These
> have been bumped up in trunk but have not been
> backported to 2.4 due to perceived API/ABI issues.

Looking at https://svn.apache.org/viewvc?view=revision&revision=1621367 it 
seems two changes are being made, one is to increase the sizes, the second is 
to accept a truncated value.

In theory, the “accept a truncated value” will work around the problem and be 
backport-able, is that true?

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]

Personally, I still think that updating these fields for 2.4.x
makes sense and can be justified... but am in no mood
for a battle *grin*

> On Feb 7, 2018, at 10:04 AM, Jim Jagielski  wrote:
> 
> I believe the issue are the various defines in
> mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These
> have been bumped up in trunk but have not been
> backported to 2.4 due to perceived API/ABI issues.
> 
>> On Feb 7, 2018, at 9:52 AM, Graham Leggett  wrote:
>> 
>> Hi all,
>> 
>> Just hit this error while trying to configure a load balancer:
>> 
>> Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname 
>> (xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long
>> 
>> According to RFC1035, DNS names are allowed to be 255 characters long.
>> 
>> This is really embarrassing - just sold the idea of an httpd based load 
>> balancer and it breaks direct out the box. What changes do I need to make to 
>> fix this? Any blockers?
>> 
>> Regards,
>> Graham
>> —
>> 
> 

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

[Jim Jagielski]

I believe the issue are the various defines in
mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These
have been bumped up in trunk but have not been
backported to 2.4 due to perceived API/ABI issues.

> On Feb 7, 2018, at 9:52 AM, Graham Leggett  wrote:
> 
> Hi all,
> 
> Just hit this error while trying to configure a load balancer:
> 
> Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname 
> (xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long
> 
> According to RFC1035, DNS names are allowed to be 255 characters long.
> 
> This is really embarrassing - just sold the idea of an httpd based load 
> balancer and it breaks direct out the box. What changes do I need to make to 
> fix this? Any blockers?
> 
> Regards,
> Graham
> —
> 

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

[Michal Karm]

On 02/07/2018 03:52 PM, Graham Leggett wrote:
> Hi all,
>
> Just hit this error while trying to configure a load balancer:
>
> Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname 
> (xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long
>
> According to RFC1035, DNS names are allowed to be 255 characters long.
>
> This is really embarrassing - just sold the idea of an httpd based load 
> balancer and it breaks direct out the box. What changes do I need to make to 
> fix this? Any blockers?
>
> Regards,
> Graham
> —
>

Hello Graham,

See https://bz.apache.org/bugzilla/show_bug.cgi?id=53218

I believe it is related to what you are talking about.

Cheers

Michal Karm Babacek

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7




signature.asc
Description: OpenPGP digital signature

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

[Graham Leggett]

Hi all,

Just hit this error while trying to configure a load balancer:

Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname 
(xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long

According to RFC1035, DNS names are allowed to be 255 characters long.

This is really embarrassing - just sold the idea of an httpd based load 
balancer and it breaks direct out the box. What changes do I need to make to 
fix this? Any blockers?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)

[Michael]

a) It has been a hard climb to get httpd-2.4.29 to build using the 
latest apr and apr-util. Still researching what that is (might be expat 
related - embedded versus external, still searching). Anyway, working 
with apr-1.5.2 I was at least able to get httpd-2.4.29 to build so I 
could proceed to my other "forever" hassle.


b) the forever "hassle": over the years (the first time I posted "a bug 
may be as far back as 2010", not bothering to post before then (or it 
was working??) - was getting "make install" to work for PHP.


c) PHP stated correctly - not them - would be instdso.sh. Also posted, 
but not conclusive. I hacked at instdso - as it knew what to remove (rm 
-f) but did not install. I just hard-wired it to copy the file, if, at 
the end, it was not there. With that, the chmod command that follows 
instdso.sh works.


Quick History, better review:

Currently:

root@x065:[/data/prj/php/php-5.3.29]make install-sapi
Installing PHP SAPI module:   apache2handler
    /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin
    if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then  
for i in 0.0.0 0.0 0; do  if test -r 
/data/prj/php/php-5.3.29/libs/libphp5.so.$i; then  ln -s 
/data/prj/php/php-5.3.29/libs/libphp5.so.$i 
/data/prj/php/php-5.3.29/libs/libphp5.so;  break;  fi;  done; fi
    /data/prj/php/src/php-5.3.29/build/shtool mkdir -p 
'/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir 
-p '/var/httpd/etc' && /opt/httpd/bin/apxs -S 
LIBEXECDIR='/opt/httpd/libexec' -S SYSCONFDIR='/var/httpd/etc' -i -a -n 
php5 libphp5.la
Use of uninitialized value in concatenation (.) or string at 
/opt/httpd/bin/apxs line 222.
/var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la 
/opt/httpd/libexec

rm -f /opt/httpd/libexec/libphp5.so
/opt/build-1/libtool --mode=install install libphp5.la /opt/httpd/libexec/
libtool: install: install .libs/libphp5.a /opt/httpd/libexec/libphp5.a
libtool: install: install .libs/libphp5.lai /opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish 
/data/prj/php/php-5.3.29/libs'

chmod 755 /opt/httpd/libexec/libphp5.so
chmod: /opt/httpd/libexec/libphp5.so: A file or directory in the path 
name does not exist.

apxs:Error: Command failed with rc=65536
.
make: 1254-004 The error code from the last command is 1.

 I think I have it!! 
With one small change: (/opt/build-1/libtool apr-1.5.2)
 +3403  # See the names of the shared library.
 +3404  set dummy $dlname $library_names; shift

root@x065:[/data/prj/php/php-5.3.29]make install-sapi
Installing PHP SAPI module:   apache2handler
    /data/prj/php/src/php-5.3.29/build/shtool mkdir -p /opt/bin
    if test ! -r /data/prj/php/php-5.3.29/libs/libphp5.so; then  
for i in 0.0.0 0.0 0; do  if test -r 
/data/prj/php/php-5.3.29/libs/libphp5.so.$i; then  ln -s 
/data/prj/php/php-5.3.29/libs/libphp5.so.$i 
/data/prj/php/php-5.3.29/libs/libphp5.so;  break;  fi;  done; fi
    /data/prj/php/src/php-5.3.29/build/shtool mkdir -p 
'/opt/httpd/libexec' && /data/prj/php/src/php-5.3.29/build/shtool mkdir 
-p '/var/httpd/etc' && /opt/httpd/bin/apxs -S 
LIBEXECDIR='/opt/httpd/libexec' -S SYSCONFDIR='/var/httpd/etc' -i -a -n 
php5 libphp5.la
Use of uninitialized value in concatenation (.) or string at 
/opt/httpd/bin/apxs line 222.
/var/httpd/build/instdso.sh SH_LIBTOOL='/opt/build-1/libtool' libphp5.la 
/opt/httpd/libexec

rm -f /opt/httpd/libexec/libphp5.so
/opt/build-1/libtool --mode=install install libphp5.la /opt/httpd/libexec/
libtool: install: install .libs/libphp5.so /opt/httpd/libexec/libphp5.so
libtool: install: (cd /opt/httpd/libexec && { ln -s -f libphp5.so 
libphp5.a || { rm -f libphp5.a && ln -s libphp5.so libphp5.a; }; })
libtool: install: (cd /opt/httpd/libexec && { ln -s -f libphp5.so 
libphp5.a || { rm -f libphp5.a && ln -s libphp5.so libphp5.a; }; })

libtool: install: install .libs/libphp5.lai /opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish 
/data/prj/php/php-5.3.29/libs'

chmod 755 /opt/httpd/libexec/libphp5.so
[activating module `php5' in /var/httpd/etc/httpd.conf]

 So, I suspect the actual 'bug' is in libtool (this embedded version 
was 2.4.2). FYI, the base statement (where I can fix it) is, in 
apr-1.6.2, based on libtool-2.4.6


/opt/build-1/libtool

 +4800  # See the names of the shared library.
 +4801  set dummy $library_names; shift

I have no clue whether prefixing $dlname is the right approach, or that 
library_names (in the .la file) is wrong.


FYI: libphp5.la contents:

root@x065:[/data/prj/php/php-5.3.29]cat .libs/libphp5.la
# libphp5.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.492 2008/01/30 
06:40:56)

#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libphp5.so'

# Names of this library.
library_names='libphp5.a libphp5

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

[Jim Jagielski]

At this point, I no longer have a horse in this race... From a philosophical
point of view, adding 10kgs of fluff to fix 1kg of error seems over-engineering
to me, but that is just me.

+1 for whatever you think is best... and thx for your
work on this.

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

[Yann Ylavic]

On Wed, Feb 7, 2018 at 1:47 PM, Jim Jagielski  wrote:
>
> Just curious if our current policy is to use a sledgehammer now
> to fix what can be handled with a pair of tweezers.

Btw, I also think this is a sledgehammer for the mod_proxy_lb case,
while it wouldn't for s->server_id (IMHO).

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

[Yann Ylavic]

On Wed, Feb 7, 2018 at 1:47 PM, Jim Jagielski  wrote:
> Just for fun, what is the functional difference, if any, between this
> very large patch, that adds lots of code, and this extremely simple
> diff which, from what I can tell, handles the exact defined
> "problem" with the original code???

This oneliner is what I proposed to Mark in the PR to unblock his
situation (IPC-SysV leaks on main process crash)...
But unless one configures a different ServerName (or ServerAdmin??)
for each vhost, multiple servers may have the same ID.
AFAICT, this is neither a requirement nor an enforcement in httpd, and
there may even be multiple vhost configured on different ports with
the same ServerName (legitimately).
If this happens, mod_proxy_lb will possibly reuse slotmems with
incompatible sizes (two vhosts with the same ID but for example a
different number of balancer members), which is controlled by
mod_slotmem but leads to the previous SHM to be overwritten (i.e. all
bets are off).

We *really* need an unique ID for mod_proxy_lb to work correctly.

>
> Just curious if our current policy is to use a sledgehammer now
> to fix what can be handled with a pair of tweezers.

You just ignored anything related the ID (hence the issue) so far, at
least there is a proposal this time.
Please go ahead with a simpler fix if the sledgehammer hurts you.

> On Feb 6, 2018, at 12:59 PM, Yann Ylavic  wrote:
>> 

This patch was bogus, I have fixed it but I'd better wait for yours now.


Regards,
Yann.

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

[Jim Jagielski]

Just for fun, what is the functional difference, if any, between this
very large patch, that adds lots of code, and this extremely simple
diff which, from what I can tell, handles the exact defined
"problem" with the original code???

Just curious if our current policy is to use a sledgehammer now
to fix what can be handled with a pair of tweezers.

diff --git a/modules/proxy/mod_proxy_balancer.c 
b/modules/proxy/mod_proxy_balancer.c
index bdefc8f54..21a65910d 100644
--- a/modules/proxy/mod_proxy_balancer.c
+++ b/modules/proxy/mod_proxy_balancer.c
@@ -784,13 +784,12 @@ static int balancer_post_config(apr_pool_t *pconf, 
apr_pool_t *plog,
  * During create_proxy_config() we created a dummy id. Now that
  * we have identifying info, we can create the real id
  */
-id = apr_psprintf(pconf, "%s.%s.%d.%s.%s.%u.%s",
+id = apr_psprintf(pconf, "%s.%s.%d.%s.%s.%s",
   (s->server_scheme ? s->server_scheme : ""),
   (s->server_hostname ? s->server_hostname : "???"),
   (int)s->port,
   (s->server_admin ? s->server_admin : "??"),
   (s->defn_name ? s->defn_name : "?"),
-  s->defn_line_number,
   (s->error_fname ? s->error_fname : 
DEFAULT_ERRORLOG));
 conf->id = apr_psprintf(pconf, "p%x",
 ap_proxy_hashfunc(id, PROXY_HASHFUNC_DEFAULT));



> On Feb 6, 2018, at 12:59 PM, Yann Ylavic  wrote:
> 
> 

mod_ssl: support for forced renegotiation on timeout or bytes?

[Pavel Janík]

Hi,

are there any plans to support openssl’s BIO_set_ssl_renegotiate_timeout and 
BIO_set_ssl_renegotiate_bytes in mod_ssl’s config?

Please CC me on reply as I’m not subscribed to this list.

Thank you.
--  
Pavel Janík