Lukas,
Am 19.06.19 um 01:44 schrieb Lukas Tribus:
> Hello Willy, hello Tim,
>
>
> On Sat, 15 Jun 2019 at 18:57, Willy Tarreau <[email protected]> wrote:
>>> - ssl.cfg : 4 years with the most recent commit adding a
>>> 'verify none' which is questionable.
>>
>> deleted, I agree with not spreading bad options by default.
>
> I disagree that the amount of the commits and its age are *the* metric
> to measure the value of an example configuration. It's a fact that we
I agree here generally, but: The age of the most recent commit to a file
is a good *indicator* whether the file is still relevant and follows
best practices. I have taken a basic look into all the files I listed.
> seldom make breaking changes to our config parser, that's a good thing
> and it's why we don't need to update the example sections for every
> stable release. We need to measure the merits of an example file based
> on it's content. A short example configuration does not need frequent
> updates and it's more useful, the *shorter* it is (as it focuses on
> one aspect, allowing the user to quickly grasp the config-concept).
I believe it should also bring a measurable benefit compared to the
configuration.txt. Examples are just that: Examples. They need to be
adapted to the own environment, requiring a look into configuration.txt
for details. SSL would possibly qualify here, ACL usage is shown well in
configuration.txt ("ACL basics").
> Of course we need to discuss the removal of obsolete ones, which
> brings me to the second point:
>
> Could we allow some more time for such things to be discussed? A few
> working days instead of less than 2 hours? I get it, you wanted it
> done in 2.0, but that's not what I'd call asking for objections.
I agree here.
> In the specific ssl example, yes, the "verify none" directive does not
> belong there, instead, it should have been a ca-file directive. Other
> than that, I don't see neither why this example would be outdated, nor
It's not just the `verify none`. It's also incomplete for a modern TLS
configuration. I've just grabbed a Debian Stretch based Docker container
with HAProxy 2.0.0 and run it through Qualys' SSL tester. Apart from the
fact that I used an untrusted certificate it only gets a 'B'. Among the
reasons is the support for TLS_DHE_RSA_WITH_AES_128_CBC_SHA (or
generally CBC).
> where we could point people asking the extremely specific "howto ssl?"
> question instead.
>
While first party sources generally should be preferred I consider this
a good destination, because it makes sure to also configure sane
ciphers:
https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy-1.8.0&openssl=1.0.1e&hsts=yes&profile=intermediate
>
>> As history has shown the examples tend to be neglected.
>
> History has also shown that documentation is neglected. But we can
> point people to specific examples, just as we can point people to
> documentations.
Neglected meaning: Neglected by the developers / HAProxy team. I've just
grabbed the `acl-content-sw.cfg` which still is in 2.0:
- It still uses the `block` directive (which is deprecated since 1.5)
- It still uses `contimeout` (which is deprecated since 1.5)
- It still uses `rspadd` (which I consider somewhat acceptable)
It does not output warnings for some reason, though (might need to be
investigated).
With HAProxy 2.1 it will look like this:
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:19] : the 'clitimeout'
> directive is not supported anymore since HAProxy 2.1. Use 'timeout client'.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:35] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:40] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:51] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:61] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:84] : the 'contimeout'
> directive is not supported anymore since HAProxy 2.1. Use 'timeout connect'.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:85] : the 'srvtimeout'
> directive is not supported anymore since HAProxy 2.1. Use 'timeout server'.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:87] : keyword 'redispatch'
> directive is not supported anymore since HAProxy 2.1. Use 'option redispatch'.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:97] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:98] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:99] : The 'block' directive
> is not supported anymore since HAProxy 2.1. Use 'http-request deny' which
> uses the exact same syntax.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:113] : the 'contimeout'
> directive is not supported anymore since HAProxy 2.1. Use 'timeout connect'.
> [ALERT] 169/022719 (23353) : parsing [./test.cfg:114] : the 'srvtimeout'
> directive is not supported anymore since HAProxy 2.1. Use 'timeout server'.
> That's why we need examples. To point people to them when they ask.
>
>
>> if you start from the need to implement something, you search
>> it in the architecture manual and you copy-paste a look-alike
>> config that you can then extend.
>
> I was unaware that that's your intention with the architecture manual,
> I always saw it as an explanation of basic load-balancing concepts
> applied to haproxy (principal features like load-balancing and health
> checking), but I realize now what you mean.
>
> However for a 1400 lines document with 4 commits in the last 10 years,
> all 4 of which typo/spelling fixes only, we cannot exactly claim
> success.
>
> If we want to retire the examples/ directory and put everything in one
> file, we probably need to revamp the architecture manual completely
> and create something that Cyril can use for the HTML converter.
> Otherwise and in its current condition, people are probably not gonna
> find it, and we'd also have a hard time referencing single examples in
> there.
>
> I'm really not sure if this is all worth it and quite frankly, don't
> get the problem with single example files in the examples/ directory.
In the previous state the directory was unsalvageable. If it will be
retained then we must make sure to regularly update the examples with
the current best practices. For configuration.txt the updates are
expected to come together with the patch changing something. For the
examples this is harder to determine.
> Explanations can be inline with the configuration, so it's even
> lighter to read than an example in the architecture manual.
>
>
> I'm not sure about the gh-wiki, I don't know how it works technically
> and I'm a bit afraid that we don't have the actual content in *our*
> git repositories. Also unsure about if we really still own the content
> once we put it up there. This is different than feature requests or
> issues, because those are processes that start and end, while
> architecture guides and everything referenced in the "Proposed plan"
> is mostly here to stay and they are also *a lot* of work. When I
> scrolled through the "proposed plan" I felt like this could be the
> content for 2 or 3 books. Of course, simple example configurations are
> not that valuable, but still, I'm unsure about that wiki.
>
No strong opion on the Wiki. Biggest issue with Wikis is that they tend
to attract half-baked solutions if they are opened up to everyone, though.
Best regards
Tim Düsterhus
