On Mon, 2014-04-14 at 09:19 +0200, Jan Just Keijser wrote: > I do like the idea of not needing root access to run openvpn - esp > windows users could benefit from this, as they're not always allowed to > install the tap-win adapter. Then again, it goes against the UNIX/Linux > philosophy that each tool (e.g. openvpn) should do one thing and it > should do it well. By adding patches like this left and right we're > steering away from that philosophy.
I'm inclined to agree about the philosophy, but I think it's a design decision made long ago in OpenVPN, and I wouldn't necessarily advocate changing it. One way of applying the UNIX philosophy in this context is to suggest that the "one thing" that a VPN tool should do well is the transfer of packets between an encrypted network link and a local one. If you take a look at vpnc and openconnect, you'll see that the nasty details of how you *configure* a network connection for every platform under the sun was considered to be outside the scope. It was farmed out to a separate tool, vpnc-script. Which allows us to *share* that vpnc-script between the two clients rather than reproducing the effort. If you look at the situation from that point of view, then yes — adding "patches like this left and right" is definitely steering away from the UNIX philosophy. But the "patches like this" could be seen to include all the existing support for configuring specific platforms such as Linux, *BSD, Solaris, Windows, OSX, Android, etc. :) But there are good reasons why openvpn does this stuff for itself, and I don't think it's very practical to change it. Kevin's patches are in line with the existing design. We have a lot of configuration cruft in openvpn, and fundamentally what it does is give the core code a file descriptor that it can shove packets in and out of. If Kevin offers a relatively clean way for that file descriptor to be a UNIX dgram socket which we handed to a spawned child process, instead of a handle to the kernel's /dev/net/tun device, I don't see why we'd consider that a violation of the philosophy. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
