-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/08/16 21:37, Илья Шипицин wrote: > I'd bet many people would like to see REST here
You might be right here. But that would actually be far more complicated to implement, as then OpenVPN needs to be a HTTP server - with all the complications that involves. In addition you loose some features, such as asynchronous communication and the signalling (think "PUSH" instead of "POLL"). And the data types are loosely defined over a HTTP (unless you start pulling in XML, DTD, Schemas, relaxng, etc). Or to say it differently, REST is more like an interface than an API itself. However, with a D-Bus interface it actually is much easier to write a REST-dbus bridge - as the D-Bus API is very well defined and offers introspection to what is connected to the D-Bus. That gives the bonus that such a bridge can tackle more than just OpenVPN too. For a D-Bus example - this one is in C: <https://leonardoce.wordpress.com/2015/04/01/dbus-tutorial-a-simple-serv er/> - -- kind regards, David Sommerseth OpenVPN Technologies, Inc > 2016-08-31 23:55 GMT+05:00 David Sommerseth > <open...@sf.lists.topphemmelig.net > <mailto:open...@sf.lists.topphemmelig.net>>: > > > 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 > > <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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXxznlAAoJEIbPlEyWcf3yH5cP/i8yXnaiwC6yqyyfTaOtrfAR m1TKn7w+AJDQdpQXylaj9FD3O3bYqOZ3fTPQG6u3iGk9MdyWWLdFHdOO/G/Vxadf OH9WjFVYJOGj+IGb+wfH63qercregeALNz2AGlp0FJbvoPw3vNaviKg3OyIIiGPa TogjIu59WYvbzxzwK5o1Vppy0sZZcKRDgKIw8hGxy4TR7V//bb0J5C8a0xQIVUY7 WRcCeMvUhz5lNsjM3fYOZ8lf3U7u0ny92c2VOxQGbSiOU9JKN5njlY5OhbtdgVU4 GjGhNOfkF6qUcUuojNwoqS1Reoyy/Wx9h0LOVSKZFmvJ3PN1MvBB6bNM0E2cOIjP ZCL2YWV66iooBSBzuvN80DHB4FPxf0Nv0OgpsWTqEr3XScgAd4ybjfYyN3DpZJyF pjkrN+VeQsigqRuPM6XqPv0pru/BbEIb89Zn/KfAwRe4DhkjFvviPg3reRJqH+TS DEn6d11S5bTLFGmStCVrbxutFas5Lhwat9AipK/umIaJJ2qThDeuCpYAhPZp0tyR t4lPNhfiVCjg+sf/cjU7w+wOCGy1Ntg3OKbUZBny0PU581c4PRLeII9NxFPhxI9c GEBP0qAdAp90pUhfwwiEXteJTNAvvsM70TdhojB9W2P2LikHn+LCFyfKrNp+7t1Q ljOIVpmJtW7UDuXxs6mt =0tPq -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
