| Message ID | 20180401131615.12567-1-a@unstable.cc |
|---|---|
| Headers | show |
| Series | add netlink support for Linux | expand |
Hi all, in case anybody cares, I have updated my patchset on GitHub[1] (I didn't want to create more noise on the mailing list since it is still RFC). This new version is quite different as I implemented a major architectural change: instead of creating a standalone sitnl module, I introduced a generic "networking API" (this is a concept that has been discussed with Gert and other devs in the past, but that never came into being). This "networking API" is the glue code between tun.c/route.c and the Linux specific code. Two new files, namely networking_sitnl.c and networking_ip.c, provides two implementations for this API: one uses the new sitnl code (netlink) and one uses iproute2. This new architecture could be re-used in the future to move other platforms specific code (i.e. for drawin, openbsd, etc..) to their own files and hide all the details behind the new API. If you try to compile my branch, openvpn will use sitnl by default unless you specify --enable-iproute2 at configure time. Comments are review are welcome! Cheers, [1] https://github.com/ordex/openvpn/tree/sitnl
Antonio Quartulli <a@unstable.cc> on Fri, 2018/04/06 15:43: > Two new files, namely networking_sitnl.c and networking_ip.c, provides > two implementations for this API: one uses the new sitnl code (netlink) > and one uses iproute2. This complicates the situation for my followup code: Running the process with unprivileged user works with netlink interface only. If we want to support netlink and iproute2 we end up with creating the files from templates (or carry static files in at least two versions). This kicks into the discussion we had about supporting newer systemd features selectively... Shipping different static files for distributions and/or systemd versions duplicates the number of files.
Hi Christian, On 11/04/18 15:15, Christian Hesse wrote: > Antonio Quartulli <a@unstable.cc> on Fri, 2018/04/06 15:43: >> Two new files, namely networking_sitnl.c and networking_ip.c, provides >> two implementations for this API: one uses the new sitnl code (netlink) >> and one uses iproute2. > > This complicates the situation for my followup code: Running the process with > unprivileged user works with netlink interface only. If we want to support > netlink and iproute2 we end up with creating the files from templates (or > carry static files in at least two versions). Keeping support for iproute2 is part of our agreement during the discussion at the last hackathon. Some of the reasons might be summarized in the hackathon page on the wiki. Therefore, we need to find a way to deal with that. > > This kicks into the discussion we had about supporting newer systemd features > selectively... Shipping different static files for distributions and/or > systemd versions duplicates the number of files. > I am not into systemd, therefore I am not able to comment on the strategy we need to adopt. However, what I imagine is that each distribution, when deciding what library to use (sitnl vs iproute2), will also decide which of the provided unit files to ship (if we have multiple precompiled files). Or our Makefile should generate the right ones based on the --enable-iproute2 switch (maybe this is what you meant with templates?). Cheers,
Hi, On Wed, Apr 11, 2018 at 03:43:11PM +0800, Antonio Quartulli wrote: > However, what I imagine is that each distribution, when deciding what > library to use (sitnl vs iproute2), will also decide which of the > provided unit files to ship (if we have multiple precompiled files). This is how I envisioned how the alternatives would look like - if you compile yourself, it's your own responsibility, but for the distro maintainers, they need to ensure that different pieces match. > Or our Makefile should generate the right ones based on the > --enable-iproute2 switch (maybe this is what you meant with templates?). That would be an interesting idea :-) - not sure it's worth the extra complications, though. gert
On 11/04/18 09:43, Antonio Quartulli wrote: > >> This kicks into the discussion we had about supporting newer systemd features >> selectively... Shipping different static files for distributions and/or >> systemd versions duplicates the number of files. > > I am not into systemd, therefore I am not able to comment on the > strategy we need to adopt. > > However, what I imagine is that each distribution, when deciding what > library to use (sitnl vs iproute2), will also decide which of the > provided unit files to ship (if we have multiple precompiled files). > Or our Makefile should generate the right ones based on the > --enable-iproute2 switch (maybe this is what you meant with templates?). Systemd is developing quite fast, and is consistently improving on the security side - with more and more interesting lock-down features, most which can be automated if enabled correctly in the unit files. But newer features may not work so well on older systemd releases. So this is actually a two-fold challenge - How to figure out which features systemd supports? We can here presume the host building the package runs the systemd version OpenVPN needs to integrate against. - How to output/generate unit files which are consistent with the available features? We will most likely need some kind of template solution to achieve this. The template approach used with Makefile.am/Makefile.in is too limited for our need - that's essentially just a wrapped in sed, which replaces defined variables with something else. There's plenty of other alternatives as well. But that can easily mean increasing the build time dependencies. I'm not convinced that is the right approach for this need. I've been pondering on what would be the best approach ... using plain bash with friends (awk, sed, etc), using Python (lots of template engine alternatives, some are built-in) or even possibilities with XML+XSLT. All of these required tools for either approach are mostly available by default on most Liux distributions. Since systemd is Linux only, that's the base restriction. All of these alternatives have some pros, but more cons. But in the end, I believe that currently it is probably better to have a simple shell script doing the generation. A unit file typically consists of three sections (Unit, Service and Install). Now, the Service section is the one which will be mostly modified. In the Unit section, only the description is slightly modified between server and client variants. Such a generator script typically need to have some kind of "feature matrix" which enlists which features we're interested in using in the currently available systemd version on the system. Then pass this "detected features" to a function which creates the [Service] section on-the-fly and dumps everything to stdout. The [Unit] section to use would be determined by the role (client or server), which could be an argument to the script. This role would need to also be used when creating the [Service] section too. Thoughts?
On 11/04/18 19:50, David Sommerseth wrote: > But in the end, I believe that currently it is probably better to have a > simple shell script doing the generation. > +1 Unless we have to create something quite complex (not the case here) that needs further extensions in the future (probably not the case too) we should keep this simple and use a plain bash script. my 2 cents. Cheers,