Hi Patrick, On Sat, Oct 15, 2016 at 01:10:39AM -0400, [email protected] 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 : - interface - namespace - 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 idea. Willy
