Welcome! Log In Create A New Profile

Advanced

[PATCH] MINOR: compression: fix -vv output without zlib/slz

Posted by Lukas Tribus 
Lukas Tribus
[PATCH] MINOR: compression: fix -vv output without zlib/slz
January 11, 2017 03:30PM
When haproxy is compiled without zlib or slz, the output of
haproxy -vv shows (null).

Make haproxy -vv output great again by providing the proper
information (which is what we did before).

This is for 1.8 only.
---
src/compression.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/src/compression.c b/src/compression.c
index 27ab7f7..ecd2fa5 100644
--- a/src/compression.c
+++ b/src/compression.c
@@ -696,6 +696,8 @@ static void __comp_fetch_init(void)
memprintf(&ptr, "%s\nRunning on zlib version : %s", ptr, zlibVersion());
#elif defined(USE_SLZ)
memprintf(&ptr, "Built with libslz for stateless compression.");
+#else
+ memprintf(&ptr, "Built without compression support (neither USE_ZLIB nor USE_SLZ are set).");
#endif
memprintf(&ptr, "%s\nCompression algorithms supported :", ptr);

--
2.7.4
On Wed, Jan 11, 2017 at 02:24:35PM +0000, Lukas Tribus wrote:
> When haproxy is compiled without zlib or slz, the output of
> haproxy -vv shows (null).
>
> Make haproxy -vv output great again by providing the proper
> information (which is what we did before).
>
> This is for 1.8 only.

Ah crap, and I was particularly careful about it when I did it :-(

Thanks Lukas!
Willy
> Ah crap, and I was particularly careful about it when I did it :-(

There is more from this conversation:

The prefer-server-ciphers output relies on the macro
SSL_OP_CIPHER_SERVER_PREFERENCE, however it is (now) redefined
before checking its presence in src/ssl_sock.c.

We may just remove this particular output, as its for < 0.9.7 anyways.

What do you think?


Lukas
Aleksandar Lazic
Re: [PATCH] MINOR: compression: fix -vv output without zlib/slz
January 11, 2017 06:50PM
Hi.

Am 11-01-2017 14:24, schrieb Lukas Tribus:
> When haproxy is compiled without zlib or slz, the output of
> haproxy -vv shows (null).

Just for my curiosity, why someone want no compression?

BR Aleks
Hello,


Am 11.01.2017 um 18:40 schrieb Aleksandar Lazic:
> Just for my curiosity, why someone want no compression?
>

There are a number of reasons to compile with a smaller number of
dependencies:

- smaller builds for embedded systems
- faster compilation for development
- lack of trust in the libs
- upgrading haproxy for fixes, not features

If there is no need for compression, there is no need for the library.

I also assume there are sectors with specific policies about such things
(I'm thinking
health care, finance, military, government), etc.

In debian for example nginx has 3 packages, full, extras and light. You
don't need
all the dependencies if you only serve simple HTTP.


Regards,

Lukas
On Wed, Jan 11, 2017 at 04:08:03PM +0000, Lukas Tribus wrote:
> > Ah crap, and I was particularly careful about it when I did it :-(
>
> There is more from this conversation:
>
> The prefer-server-ciphers output relies on the macro
> SSL_OP_CIPHER_SERVER_PREFERENCE, however it is (now) redefined
> before checking its presence in src/ssl_sock.c.

Hmmm probably the result of moving the code from one file to
another without noticing the other file used to define it.

> We may just remove this particular output, as its for < 0.9.7 anyways.

I think it makes sense for 1.7+ to get rid of anything < 0.9.8 since
it's the oldest one we managed to build with and we're not aware of
any still supported distro supporting any older version.

> What do you think?

Yep please proceed as you see fit. If you think other ones are also for
< 0.9.7 (or < 0.9.8), you can kill them as well.

Thanks Lukas!
Willy
Aleksandar Lazic
Re: [PATCH] MINOR: compression: fix -vv output without zlib/slz
January 11, 2017 11:30PM
Hi.

Am 11-01-2017 18:40, schrieb Lukas Tribus:
> Hello,
>
>
> Am 11.01.2017 um 18:40 schrieb Aleksandar Lazic:
>> Just for my curiosity, why someone want no compression?
>>
>
> There are a number of reasons to compile with a smaller number of
> dependencies:
>
> - smaller builds for embedded systems
> - faster compilation for development
> - lack of trust in the libs
> - upgrading haproxy for fixes, not features
>
> If there is no need for compression, there is no need for the library.
>
> I also assume there are sectors with specific policies about such
> things (I'm thinking
> health care, finance, military, government), etc.
>
> In debian for example nginx has 3 packages, full, extras and light.
> You don't need
> all the dependencies if you only serve simple HTTP.

Indeed.

Thank you for the explanation.

> Regards,
>
> Lukas

BR aleks
Lukas Tribus
[PATCH] MINOR: ssl: don't show prefer-server-ciphers output
January 11, 2017 11:50PM
The output of whether prefer-server-ciphers is supported by OpenSSL
actually always show yes in 1.8, because SSL_OP_CIPHER_SERVER_PREFERENCE
is redefined before the actual check in src/ssl_sock.c, since it was
moved from here from src/haproxy.c.

Since this is not really relevant anymore as we don't support OpenSSL
< 0.9.7 anyway, this change just removes this output.
---
> Yep please proceed as you see fit. If you think other ones are also for
> < 0.9.7 (or < 0.9.8), you can kill them as well.

I did not find any other outputs, unless you meant actual #defines for
older openssl compatiblity as well? I would leave them as-is. It may be
useful for OpenSSL forks or forward compatibility if those macros get
removed from upstream OpenSSL.

---
src/ssl_sock.c | 7 -------
1 file changed, 7 deletions(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 62b983a..3705917 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -6794,13 +6794,6 @@ static void __ssl_sock_init(void)
#endif
"", ptr);

- memprintf(&ptr, "%s\nOpenSSL library supports prefer-server-ciphers : "
-#ifdef SSL_OP_CIPHER_SERVER_PREFERENCE
- "yes"
-#else
- "no (0.9.7 or later needed)"
-#endif
- "", ptr);
hap_register_build_opts(ptr, 1);

global.ssl_session_max_cost = SSL_SESSION_MAX_COST;
--
2.7.4
On Wed, Jan 11, 2017 at 10:47:18PM +0000, Lukas Tribus wrote:
> The output of whether prefer-server-ciphers is supported by OpenSSL
> actually always show yes in 1.8, because SSL_OP_CIPHER_SERVER_PREFERENCE
> is redefined before the actual check in src/ssl_sock.c, since it was
> moved from here from src/haproxy.c.
>
> Since this is not really relevant anymore as we don't support OpenSSL
> < 0.9.7 anyway, this change just removes this output.
(...)

Applied, thank you Lukas!

> I did not find any other outputs, unless you meant actual #defines for
> older openssl compatiblity as well? I would leave them as-is. It may be
> useful for OpenSSL forks or forward compatibility if those macros get
> removed from upstream OpenSSL.

I only meant if other macros used in #ifdef for compatibility reasons
induce some dead code that never gets built anymore, then we can remove
them. But don't waste your time on this, it's neither fun nor useful.
At best it will make the code cleaner :-)

Cheers,
Willy
Sorry, only registered users may post in this forum.

Click here to login