Opened 11 years ago

Closed 8 years ago

#252 closed Bug / Defect (fixed)

OpenVPN-GUI (64-bit) fails after installation

Reported by: Dirkjan Ochtman Owned by: Samuli Seppänen
Priority: major Milestone: release 2.4
Component: Windows GUI Version: OpenVPN 2.3-beta / 2.3-RC (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows
Cc: Gert Döring

Description

I installed OpenVPN-2.3.0 on my 64-bit Windows 7 install without uninstalling my older OpenVPN install. I install OpenVPN in a custom path. After installing, opening OpenVPN-GUI errors out with this error:

Error while creating HKLM\SOFTWARE\OpenVPN-GUI key.

I tried to remove any old OpenVPN-GUI keys I found in the Registry, but it doesn't appear to work.

Attachments (1)

openvpn-gui-registry-keys.png (15.8 KB) - added by Samuli Seppänen 11 years ago.
List of openvpn-gui registry keys

Download all attachments as: .zip

Change History (32)

comment:1 Changed 11 years ago by Gert Döring

Owner: set to Samuli Seppänen
Status: newassigned

comment:2 Changed 11 years ago by Gert Döring

Cc: Gert Döring added

comment:3 Changed 11 years ago by Dirkjan Ochtman

I tried uninstalling 2.3.0, then installing 2.2.2, then uninstalling 2.2.2 and installing 2.3.0, but it still failed the same way. I've now installed 2.2.2 again.

I should note that I successfully installed 2.3.0 on top of 2.2.2 on another box (which also runs 64-bit Windows 7), using the same custom path, although I'm only using the service there (i.e. no UI).

comment:4 Changed 11 years ago by Heiko Hund

Run the GUI as Administrator once. It will be able to create the keys then.

@mattock: the installer should create the GUI keys during installation.

comment:5 Changed 11 years ago by Dirkjan Ochtman

You mean the actual Administrator? I was running it as a user with Admin privs.

comment:6 Changed 11 years ago by Heiko Hund

Yes, the admin group alone won't do the trick as long as you have UAC enabled.

comment:7 Changed 11 years ago by Samuli Seppänen

This is somewhat related to ticket #249. I'll fix both in one go.

comment:8 Changed 11 years ago by Samuli Seppänen

Owner: changed from Samuli Seppänen to Samuli Seppänen

comment:9 Changed 11 years ago by Samuli Seppänen

Fixing this is not straightforward. So this is how it goes currently:

  • OpenVPN installer does not generate any OpenVPN-GUI registry keys.
  • OpenVPN uninstaller does not delete any OpenVPN-GUI registry keys.
  • When OpenVPN-GUI is launched the first time as admin, it reads the OpenVPN installation directory from the registry. It then creates a fair amount (see the attached image) of registry keys, some of which change dynamically based on OpenVPN install directory.

Currently openvpn-gui registry key generation logic is embedded into the openvpn-gui.exe executable, whereas openvpn registry keys are created by the openvpn installer.

Here are some options for fixing this:

  1. Move the openvpn-gui registry key generation logic into the OpenVPN installer. The downside is that it won't be possible to install openvpn-gui separately from OpenVPN. Also, any registry-related changes in openvpn-gui need to go into the openvpn(-build) project.
  2. Add registry key generation to the openvpn installer while keeping the same logic in openvpn-gui.exe. This creates redundancy and could possibly trigger some interesting bugs in openvpn-gui.exe.
  3. Create a proper installer script for openvpn-gui, which can be embedded into the openvpn installer. The installer could be fairly simple, as it only copies one file and creates some registry keys. More stuff, such as openvpn-gui documentation could be added later.
  4. Keep things as they are but document them properly. For example, openvpn-gui could pop up an understandable error message if it's not launched as admin.

I would definitely prefer option 3. Option 4 would be the second best option. I don't think options 1 or 2 make sense.

I don't think openvpn uninstaller should remove OpenVPN-GUI registry keys, either, as they contain some configuration options the user might want to keep. For example, the user could just be uninstalling an older version of openvpn before an upgrade, without any intention of getting rid of openvpn-gui completely. Similarly the openvpn uninstaller does not touch openvpn configuration files.

comment:10 Changed 11 years ago by Samuli Seppänen

OpenVPN-GUI could also check if the registry keys are reasonable (i.e. point to OpenVPN installation dir) when it launches. Currently the GUI just refuses to start up if, say, the user had previously installed OpenVPN to a non-standard directory.

comment:11 Changed 11 years ago by Gert Döring

I think we need to distinguish between "user related" and "program related" registry settings.

Stuff like "where is openvpn.exe?" is a registry key that should be created by the installer *and removed* upon uninstallation - there is no benefit in keeping it around after uninstallation, and no loss incurred by setting it again at re-installation. This would be in line with "option #3" above.

OTOH, options selected by the user in the GUI and stored in the registry should be made by openvpn-gui.exe (obviously), and should not be removed upon logout.

comment:12 Changed 11 years ago by Samuli Seppänen

The most important OpenVPN-GUI-specific user configuration parameters are the user interface language and the proxy settings. The rest of the information can probably be safely deleted when OpenVPN is uninstalled. That should solve this issue, provided that OpenVPN-GUI checks for the existence of individual registry keys during startup. If it only checks if the registry key "directory" (HKEY_LOCAL_MACHONE\SOFTWARE\OpenVPN-GUI) exists, then we still have a problem.

All this said, I'm thinking that the best solution is to create a separate, simple installer and uninstaller for OpenVPN-GUI and embed that into the OpenVPN installer. I'll discuss this with d12fk, maintainer of OpenVPN-GUI. If there are no complaints, I'll start writing an OpenVPN-GUI NSI installer.

Changed 11 years ago by Samuli Seppänen

List of openvpn-gui registry keys

comment:13 Changed 11 years ago by jeffasinger

This happened to me on Windows 7 32 Bit on two occasions, with the 32 bit installer. Adding the required key, in regedit fixed it for me.

Would it be possible for OpenVPN GUI to just do this instead of displaying that error message?

comment:14 Changed 10 years ago by Samuli Seppänen

Keywords: windows added
Milestone: release 2.4

I wrote an installer for OpenVPN-GUI, which is available here.

Integration with the openvpn-build buildsystem is still missing, but I plan on adding it before the 2.4 release. After that we can close this bug report, and a few other ones that are NSIS-related.

comment:15 Changed 9 years ago by Samuli Seppänen

Component: InstallationWindows GUI

The openvpn-gui-installer.exe is now integrated into the OpenVPN installer:

The changes are currently in my private openvpn-build fork in the "gui" .

The installer integration has been tested quite thoroughly, but there are a couple of known issues:

  1. OpenVPN-GUI installer is unable to restart the GUI
    • This was a fairly new piece of functionality in openvpn.nsi which was moved to openvpn-gui.nsi. Basically the installer stops the GUI if it it's running, and then should restart it after install. The restart part does not work currently, pobably because something is missing from the openvpn-gui.nsi.
  2. openvpn-gui.exe is unsigned
    • This is a bit annoying, as it's a regression. The problem is that the openvpn-gui build (in openvpn-build) does not sign any files. The signing part is only done after the build, which means that an unsigned openvpn-gui.exe will be embedded into signed openvpn-gui-installer.exe. The underlying problem is openvpn-gui's lack of a proper buildsystem of it's own. For example, tap-windows/tap-windows6 have buildsystems, which sign whatever files they need and then package them into an installer. A somewhat nasty workaround would be to hack signing into the openvpn-gui build functions in openvpn-build. Alternatively the openvpn-gui build could be separated from openvpn-build into a separate buildsystem, but that'd be a major effort probably.

I'll provide test installers later today.

comment:16 Changed 9 years ago by Samuli Seppänen

I sent the changes to openvpn-gui.nsi to the GUI's author. Hopefully they will get merged soon.

comment:17 Changed 9 years ago by Samuli Seppänen

OpenVPN-GUI installer is now fully functional and integrated into openvpn-build. A test installer can be downloaded from here. The associated NSI sources are available in these Git repositories:

The openvpn-gui.nsi script has some additional fixes/changes, but the two issues above still persist.

comment:18 Changed 9 years ago by Samuli Seppänen

Status: assignedaccepted

comment:19 Changed 9 years ago by Samuli Seppänen

New installers with a properly signed openvpn-gui here:

If you test these please report back. Making these required patches to openvpn-gui and openvpn-build which are still pending review.

comment:20 in reply to:  19 Changed 9 years ago by Samuli Seppänen

Replying to samuli:

New installers with a properly signed openvpn-gui here:

If you test these please report back. Making these required patches to openvpn-gui and openvpn-build which are still pending review.

These include the tap-windows6 (NDIS 6) driver and will not work on Windows XP.

comment:21 Changed 9 years ago by ValdikSS

I've tried to run fresh installed OpenVPN from comment 20 on Windows 8.1 x64 and got an error message that I should run it with administrator privileges once first. Am I missing something?

By the way, if OpenVPN gui still requires administrator privileges to add routes, then should it be better for installer to make a shortcut with "run as administrator" flag set?

comment:22 Changed 8 years ago by Selva Nair

A lot has changed over the years of this ticket's life. But the question of how to manage registry settings is still relevant.

In the next release of the the GUI, the registry keys will reside in HKCU, so the installer need not create any keys. Nor does the user would need admin rights if they use the interactive service -- hopefully that will be the default.

However, what happens when a new release of the GUI needs to change the default value of a parameter? It can't just overwrite the registry as it might have been customized by the user. A few options:

(i) Save the version of the GUI in registry to detect first run of a new version and then show a dialog to reset the parameters

(ii) Add a menu to edit all user configurable parameters with an option to reset to defaults

Finally, I think the GUI installer or uninstaller should optionally offer to remove the registry keys.

comment:23 Changed 8 years ago by Samuli Seppänen

The primary purpose for the installer was to create registry keys at install time. This is no longer necessary nor possible in the general case, so I'd just scrap the GUI installer. On top of this, the installer would just create issues with little gain:

  • A fair number of backwards-incompatible changes to openvpn-build would be required
  • Some of the useful functionality in the current NSI installer would break (and would difficult to fix)

As for modifying the registry keys... I think it would be best if OpenVPN-GUI could detect "incompatible" registry key values and notify the user about them, perhaps even offering to reset them to compatible default values. Is that what you were thinking about in (i)?

comment:24 Changed 8 years ago by Selva Nair

@samuli: Something like that. We could start by adding the GUI version to registry to detect upgrades. Then pop up a question to optionally reset all parameters to the default at first run after upgrade. This is easy to do. Offering to update only those params that are affected by the upgrade may be too complicated to implement.

Ideally the settings window in the GUI should show all parameters with current and default values and option to change them... Manually editing the registry is not for everyone. Wish, if _someone_ could contribute a patch.

In any case, agreed, the installed could ignore the registry keys now that we have them in HKCU.

comment:25 Changed 8 years ago by Samuli Seppänen

Selvanair: any thoughts about my proposal to scrap some of the openvpn-gui keys (see comment 23 of #249)?

comment:26 in reply to:  25 Changed 8 years ago by Selva Nair

@samuli

Yeah, we should do something about this: here is what I have been wanting to do but haven't found time to (part of this is also in comment 22):

(i) Add a version number to the registry so that the GUI can detect that it has been updated and modify registry keys as needed -- as some values may be customized by the user, this will need a dialog.

(ii) Have a menu/dialog to edit all the relevant parameters saved in the registry -- I do not particularly enjoy writing GUI, so hope for someone else to take this up ;)

Expecting the users to edit the registry to change --log to --log-append or a increase the script-timeout is not proper..

(iii) Get rid of some keys

  • allow_edit --> always show as it will automatically fall back to edit or view-only depending on user's privileges
  • allow_password --> automatically show or hide depending on user has permission to edit the key
  • allow_proxy --> always enable as its non-intrusive and hidden in the settings
  • disconnect_on_suspend --> we can just get rid of it and remove it from the installer too.
  • config_ext --> hard-code to ovpn?
  • service_only and use_service --> Myself and R Morris have been working on a patch to make the GUI control service-started instances as well. It works nicely in our tests but the changes are somewhat pervasive, needs more testing, so I prefer to keep it for the next version --- these keys will become obsolete at that stage.

comment:27 Changed 8 years ago by Samuli Seppänen

@selvanair: what about the proposal to read some values directly HKLM\Software\OpenVPN, instead of making copies to HKCU\Software\OpenVPN-GUI? For example, the openvpn.exe's location will always be there, and always pointing to the correct place.

comment:28 Changed 8 years ago by Selva Nair

Yes, values that need not be configurable by the user and available HKLM may be read from there. But I think those are available only if the service is installed, isn't it?

comment:29 Changed 8 years ago by Samuli Seppänen

The values are created in SecService in openvpn.nsi, but we can easily move that code to !SecOpenVPNUserSpace. I also think that that change would be safe to do.

comment:30 Changed 8 years ago by Selva Nair

Surely safe to do. At least exe_path and priority may be taken from these HKLM values and not duplicated in HKCU. The system_wide config-dir is currently guessed but could be read from HKLM as well. I'll do a patch.

comment:31 Changed 8 years ago by Samuli Seppänen

Resolution: fixed
Status: acceptedclosed

This problem is no longer present when relatively recent version of OpenVPN is coupled with similarly recent OpenVPN-GUI. For example, the snapshot installers do not have this problem, as registry keys are stored under HKCU and OpenVPN-GUI no longer needs to run as admin. Closing this as fixed.

Note: See TracTickets for help on using tickets.