[Openvpn-devel] Modernising the management interface

[David S. <op...@sf...>]

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