Hi, I have for a long time pondered on how we can make the management API more suitable for more modern tools and tasks. So I am just giving an extremely early heads-up on on what I'm poking at ... and hopefully receive some feedbacks on what you think.
One of the things which have struck me is that D-Bus is adopted a lot of places, and its internal API have been considered stable for about 10 years or more. Even though there are areas where D-Bus seems a bit over-engineered, it has proved to be a very useful IPC mechanism for a lot of software. Currently, each tool and application who wants to integrate with the management API today, needs to write their own TCP connect code and implement various methods to send, receive and parse the data to and from the management interface. And the management interface doesn't scale well if you want to add support for more advanced management. Yes, the current interface solves most of today's challenges reasonably well. But I believe it can be improved so that it can be even more flexible and more easily integrable with various set of management tools. * Why D-Bus? It provides a standardised API with integrations to most programming and scripting languages. It is asynchronous and it you can both send messages but also have management tools act upon signals the application sends. The way messages are sent are standardised, and all the connectivity and data exchange is covered by the D-Bus libraries. Even data types are standardised and there is type safety on all data exchanged in a D-Bus message. D-Bus is also pretty much installed by default on any modern Linux distribution today. And as far as I have seen, it exists on most POSIX based platforms. I am somewhat uncertain on the Windows and macOS side, though. More on that towards the end. * How will a D-Bus improve OpenVPN? With D-Bus we can provide a better integration towards GUIs as well as other management tools. OpenVPN can much more easy alert D-Bus listeners about things which requires attention. And we can more easily extend the management interface to also cover more areas of OpenVPN more easily, as D-Bus will describe the API through its built-in introspection. This can also enable us to provide plug-ins to be managed via the management interface, where each plug-in can individually provide it's own API without requiring any changes to the OpenVPN core. The plug-in just needs to provide an init call which tells the OpenVPN server it has D-Bus support, and introspection takes care of providing the proper message passing from a management client down to the plug-in itself. And it can enabled more modern and advanced management tools to be integrated more easily with OpenVPN. For example the Cockpit project[1] is a a web based management interface for Linux systems with systemd. Cockpit depends entirely on D-Bus to do the management. Writing a new module in Cockpit requires only to write a module covering the D-Bus methods defined in OpenVPN, the presentation and interaction is covered by the Cockpit framework. A demo how to implement setting the time zone as a Cockpit module can be seen here[2]. [1] <http://cockpit-project.org/> [2] <https://www.youtube.com/watch?v=97l1qf2sZtk&feature=youtu.be&t=1754> Other features where this can be useful is to provide D-Bus signals when users log in and out for audit purposes. It is possible to add methods where you can set thresholds on bytes sent/received or how long a session have been running, and then send a signal when those thresholds are reached; then a management tool can decide what to do when these signals happens. As a Cockpit feature, could be to list all connected VPN clients on a Cockpit enabled OpenVPN server, and have a button kick them out or otherwise manage these VPN clients. Many of these things requires today a poll mechanism which doesn't scale too well as only one instance can be connected to the management API today. With D-Bus you can have many instances connected to the interfaces OpenVPN would provide at the same time - which again simplifies implementing new management tools for OpenVPN. Similar D-Bus interfaces will also be added to the OpenVPN 3 codebase when that arrives, which should help migration between OpenVPN 2 and OpenVPN 3 setups as well. * What comes next? Right now I am digging into the whole feature set of the management interface and wrapping my head around how this could look like through a D-Bus interface. The next thing I am will do is to provide some proof-of-concept code, which first will just connect to today's management API and be a broker between OpenVPN and D-Bus. This won't scale well, but it will at least give something we can play with. Then comes the job of implementing D-Bus natively into OpenVPN and then start to provide more advanced features over D-Bus which today is be harder to achieve. This will be an iterative process. But ... It would be very useful to get some input from especially macOS and Windows developers on how the state of D-Bus are on those platforms. AFAIK, D-Bus is available on most *BSD platforms, so that shouldn't be an issue. It is not being planned to remove the management interface. If D-Bus works well for everyone on all platforms, then we can discuss what to do next. But as of now, I have no plans to remove this part of the code. And of course ... plenty of discussions along the road :) But I chose to start this discussion in the public before actually starting to coding and submitting patches - just as a heads up and to get feedback before moving on further. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
