Re: OpenVPN Questions

[David Zeuthen <davidz redhat com>]

On Tue, 2005-11-15 at 11:59 +0100, Tim Niemueller wrote:
> * skdaz.conf: Note that the OpenVPN-plug-in does _not_ read
> OpenVPN-config files but rather uses some special ini files that contain
> the information needed. I will put up some documentation on this with
> next check-in. The reason why I did this is mainly that this was the
> easiest way to go without creating a new parser. Does anyone think there
> is an urgent need to be able to parse the real OpenVPN config files? One
> pro I can think of is that the IT department would not need to create
> special NM config files.

So, basically, one of the design goal with the whole VPN framework
within NetworkManager was to store VPN connection settings in the
desktop session; basically you have two kind of settings

 1) non-sensitive settings; e.g. the hostname of the concentrator
    to connect to; what kind of encryption to use and so forth; and

 2) sensitive settings; e.g. passwords and other information that
    you don't want an attacker to get access to even though they
    have access to your home-directory

Both information from 1) and 2) is retrieved through NetworkManagerInfo
and thus, can use the desktop-specific storage API's. Which means
gconf/gnome-keyring for GNOME and other stuff for other desktops.

Now, for GNOME, the idea is to store settings 1) in gconf; it is
basically just an array of key-value pairs. This is clever, because
system-administration-wise it means you can store this in the
mandatory/default section of gconf and simply distribute an RPM with
this, e.g. my company might distribute an internal RPM with VPN
connections for the seven different VPN concentrator points around the
world (e.g. Boston, Raleigh, Mt. View, APAC and so on).

In GNOME we store settings 2) in gnome-keyring. This is basically just
an array of secrets passed on (see nm-vpnc-auth-dialog).

I haven't looked at your code but I sounds like you are advocating
configuration files in e.g. /etc or ~/.local/etc (I could be wrong
though) and I think this is not something we want. Think of the benefits
of using gconf here.

Cheers,
David