D-Bus service activation and access control

[David Sommerseth]

On 01/08/17 02:42, Thiago Macieira wrote:
> On segunda-feira, 31 de julho de 2017 15:00:59 PDT David Sommerseth wrote:
>> All that said; OpenVPN 2 will continue to live along side OpenVPN 3 for
>> a noticeable time - at least until we have both client and server
>> support in OpenVPN 3.  We will _not_ do a hard-drop of OpenVPN 2 any
>> time soon.  But once we have a critical mass using OpenVPN 3 client and
>> server components, OpenVPN 2 will get a sunset plan.
> 
> You'll only get a critical mass of OpenVPN 3 client when the all current 
> network management tools (not just NetworkManager) have been ported to it. But 
> for NM, please take into consideration how much you're duplicating of it and 
> how much new state is required in your implementation to do exactly what v2 
> did.

I've been involved in upstream OpenVPN 2 development for many years now.
 And the OpenVPN v2.x code have code paths which are horrendous to work
with.  We've been cleaning up and improving many areas since v2.2; and
it feels like we've barely started.

OpenVPN 2.x design principles are based on OpenVPN 1.x; which had one
process per VPN tunnel.  OpenVPN 2.x added a scheduler/event handler to
support multiple connections to the server side.  At that time SMP
systems where scarce and expensive, so multi threading was not part of
the design.  Further, there are lots of other issues as well; such as
listening to UDP and TCP ports simultaneously as well as multiple ports
in general - several people have tried to solve that issue and is still
fighting this.  All this is due to OpenVPN being developed with those
days needs, expectations and available features.

The OpenVPN 3 design principles are quite different, it uses the same
wire protocol but utilizes more modern approaches of resolving similar
issues.  Instead of implementing its own event handler, ASIO is used -
which also handles socket handling in a far more generic and standard
way.  And it is written to be able to use threads as well.  And I'm just
barely scratching the surface now.  And due to using C++ it enables
extensibility through polymorphism and class inheritance; which makes it
easier to make OpenVPN fit into a broader range of use cases.

> As for the server, make sure it runs on an 8 MB flash OpenWRT image that uses 
> uClibc and no D-Bus (it uses ubus).

Currently D-Bus is the requirement for the Linux client.  But I'm trying
to end up with a design where the D-Bus implementation can be replaced
by a different IPC as well.  But first it is needed to get one
implementation somewhat settled, to flush out all the IPC requirements,
then we can look further at other IPC frameworks.

And perhaps such small environments (such as the majority of OpenWRT
devices) will have a very different and smaller OpenVPN 3
implementation, with reduced features.  Or perhaps it will stay on
OpenVPN 2.  We will have to see.

All I can say is that while the OpenVPN 2 and OpenVPN 3 code bases are
very different, we are targeting the wire protocol to be compatible (as
long as no obscure OpenVPN 2 features are used).


-- 
kind regards,

David Sommerseth