Re: TLS-PSK support for haproxy?

[Igor Pav]

Tested and it works! Could we expect a rtt reduce?

On Mon, Jan 9, 2017 at 8:07 AM, Nenad Merdanovic  wrote:
> Hello,
>
> On 1/5/2017 4:47 PM, Emeric Brun wrote:
>> On 01/05/2017 04:22 AM, Nenad Merdanovic wrote:
>>> I have a working patch for this, but it's very ugly currently (minimal
>>> error checking, no warnings/messages, no docs, very basic tests done
>>> only, etc.)
>>>
>>> I expect to have a version for review by EOW (depending on the workload,
>>> maybe a bit sooner).
>>>
>>> Regards,
>>> Nenad
>>
>> Great news Nenad!
>
> I haven't really had as much time as I wanted for this, but I am
> attaching a patch that I think is good enough for review as I don't
> expect design decisions to change.
>
> There are some minor things I want to improve (rename things like
> 'psk_key'), add some ifdefs for OPENSSL_NO_PSK and write the
> documentation of course. Depending on the client/server side:
> - On the bind line, there is a psk-file keyword that loads a series of
> PSKs and any can be used
> - On the server line, there is a psk keyword, that takes the same format
> as the file (:) and is used for the backend connection.
>
> I'll send a full Git patch if this looks OK within the next few days.
>
> Regards,
> Nenad

Re: Dynamically adding server's to backend

[Michał]

For the first iteration I just dynamically added server to proxy and then
called
check_config_validity() which resolves all track's and checks things.
IMHO check_config_validity() need some refactoring, because in current state
it not only check config, but also resolves some dependencies and state, so
it
can't be called repeatedly. It can be done in two ways - move resolving of
all
those thing to separate function(s) or place additional checks to prevent
overwrtiting data that is already in memory.

Now after you wrote about possible problems I'll look into them and try to
find
ways to fix them. I'll let you know with some patches if I will find some
good
way to do it. The more people looking into it the more ways to find better
solution :)

Michał

2017-01-20 11:02 GMT+01:00 Willy Tarreau :

> On Thu, Jan 19, 2017 at 11:54:32PM +0100, Micha?? wrote:
> > Hello,
> >
> > What do you think about making possible to add servers to backend at
> > runtime via CLI/socket?
>
> This is exactly what is being worked on, but it's not as trivial as you
> imagine :-)
>
> > Changing addresses and wieghts of servers is ok,
> > because we can use "placeholders", but it's not the best solution and
> > requires to configure many placeholders when it comes to autoscaling.
>
> We'll still use placeholders, we'll just ensure they're more discrete.
> Eg with Baptiste we discussed the idea of a "server template" which
> would declare a number of server slots at once that will be usable to
> be enabled on the CLI or via the DNS.
>
> > This problem solves reloading haproxy with safe loading certificates to
> > encrypted volume which takes some time and in dynamically changing world
> of
> > microservices - it just kills whole load balancing solutions with endless
> > reloads.
>
> Sure it solves a lot of things but it creates a vry long trail of
> new problems at the same time. Just one example : assigning automatic
> cookie values for servers created on the fly, that do not conflict with
> existing ones and which are invariant between multiple LB nodes and along
> DNS updates. Another one ? Consistent server IDs across all LBs for shared
> stickiness and consistent stats. There will also be quite a number of
> functional limitations, such as the impossibility to use such servers
> in "use-server" directives, the impossibility to reference them in ACLs
> (eg: srv_is_up()), impossibility to track them from other servers, etc.
> All this because these references are resolved upon startup and are
> mandatory to validate the consistency of the configuration.
>
> But some progress is being made in this area (and in 1.7 you can at least
> start a server with no address and fill it later, which is a huge progress
> compared to 1.6).
>
> Best regards,
> Willy
>