On Mon, 2008-01-14 at 17:51 -0500, Dan Williams wrote: > On Mon, 2008-01-14 at 16:12 -0500, David Hollis wrote: > > On Mon, 2008-01-14 at 14:40 -0600, Steven Pritchard wrote: > > > > > It was brought up at the time, but everyone was saying NetworkManager > > > was going to take over the world, so making ifup/ifdown work didn't > > > seem like a terribly high priority. NetworkManager-openvpn has been > > > around for a while... > > > > > > > > > Though it seemed abandoned at some point in time and the last time I > > checked, it didn't support some options that I use in my config namely > > 'tls-auth/tls-remote'. > > > > Maybe it's interface needs some simple option to add 'custom' name/value > > pairs that get passed to the openvpn program to allow for future > > enhancements or local customizations and such. > > That's part of the problem. OpenVPN has so many options that adding > everything to a dialog really isn't going to work. That may be a > symptom of OpenVPN's feature-creep and attempt to work in every > conceivable situation, which makes it less and less easy to actually set > up, but I digress. (note also vpnc 0.4's addition of > application-version, no-encryption, pfs, natt-mode, etc). There are so > many obscure options that at least one person needs that there's no way > either OpenVPN or vpnc will ever Just Work for the user. They basically > require a sysadmin or somebody who really knows what they are doing to > set up the VPN for them, which sucks. > Plus some folks may compile in different options and such (like NTLM support or something). In my org, I administer the OpenVPN configuration used and I have a standard config file that I blow out to users with specific client certs. Unfortunately, I the NM-openvpn component doesn't allow me to just import that file, or link right to it so I have to manually add the config information to the client. It would seem that it wouldn't be to horrible for the cfg tool to be able to import a config and to just have a name/value grid kind of thing for non-gui-ified options. Maybe put that under an 'advanced settings' kind of thing. It definitely would be good to have some kind of filter to ensure that people aren't trying to inject bogus commands to the OS as root or something. That's where things can get sticky, especially with passing scripts to be run on ifup/down etc... > That said, allowing options not handled in the GUI bits to be added is > probably the something that should be done; but it needs to be done in > such a way that if the option is sanely added to the GUI later on, that > it supersedes the custom-option-entry bit. I'm also a bit reluctant to > take out the option filter/validator for VPN methods that don't support > config-on-stdin, because passing random text on the command line is a > security risk. About the last thing we want to be doing is executing a > root process with random arguments entered by some trojan that stuffed > values into GConf. > > Dan > > > > -- David Hollis <dhollis@xxxxxxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
