On Sat, Oct 15, 2016 at 01:10:39AM -0400, hapr...@stormcloud9.net wrote:
> Well nevermind. Applying the namespace to the remote peers isn't quite
> as simple. The local peer was simple as it behaves like a normal
> frontend bind. But it appears the remote peers are treated rather
> differently, and don't share anything with the server struct, and thus
> can't as easily accept all the server options.
I'm indeed not certain it's as simple, because peers use the same address
both for listening and for connecting. However I'm pretty certain that the
underlying infrastructure just needs to be told to use this or that namespace.
That's the same reason we still don't have SSL support on peers. We need to
find an elegant way to configure all this. I've thought about reusing what
default-server supports but that would cause much more confusion than anything
else, and would be incomplete.
Maybe in the end we should proceed differently and try to enumerate all the
bind+server settings we'd like to have on the peers. The following ones
immediately come out of my mind :
- ssl (+crt +cafile, for each direction)
- and maybe the source used to connect
In the end it's not *that* many parameters and maybe they should directly
be reimplemented on the "peer" line with their own keyword without trying
to copy-paste irrelevant options from other directives. But that's just an