[Babel-users] [PATCH v3 1/2] Rework sysctl writing to only write when needed.

2015-08-12 Thread Toke Høiland-Jørgensen
This reworks the sysctl handling to only write a sysctl if it is not already the desired value. In addition, the Linux sysctl knobs are now stored in a lookup table which is looped through, to avoid code duplication in the setup routine. Signed-off-by: Toke Høiland-Jørgensen --- kernel_netlink.c

[Babel-users] [PATCH v3 2/2] Add configuration flag to skip initial kernel setup.

2015-08-12 Thread Toke Høiland-Jørgensen
This adds a configuration flag to skip kernel (sysctl) setup on daemon startup. This can be useful if running in, e.g., a container environment where setting sysctls are not allowed. Signed-off-by: Toke Høiland-Jørgensen --- babeld.c | 1 + babeld.h | 1 + babeld.man | 5 ++

Re: [Babel-users] [PATCH v2] Smarter sysctl handling

2015-08-12 Thread Juliusz Chroboczek
Thanks Toke. 1. Please split that into two patches, one that changes the default behaviour, and one that includes the new patch. 2. The flag should be called "no-kernel-tweaks" or something like that, and should unconditionally disable any kernel tweaks rather than merely continuing if tweaking f

Re: [Babel-users] [babel] Babel to standard

2015-08-12 Thread Alvaro Retana (aretana)
On 8/12/15, 4:38 AM, "babel on behalf of Henning Rogge" wrote: Hi! >The problem is that the selected solution heavily depends on the >network you plan to deploy. This is an excellent point ‹ not just related to security, but in general. The applicability ‹ what problem will Babel solve? Where

Re: [Babel-users] [babel] Babel to standard

2015-08-12 Thread Henning Rogge
On Wed, Aug 12, 2015 at 3:23 AM, Russ White wrote: >> * lower-layer security (e.g. put a frightening guy or gal with >> a truncheon in front of each Ethernet plug, or use 802.1X); >> * HMAC authentication (RFC 7298); >> * Stenberg-style authentication (move everything to unicast except >

Re: [Babel-users] [babel] Babel to standard

2015-08-12 Thread Russ White
> Which, if any, of the currently defined extensions should be merged into the > base spec? My opinion is that the extension mechanism should be merged, > but that the actual extensions should remain separate documents. I would agree with this assessment -- the extension mechanism should be merg