Re: [Openvpn-devel] OpenVPN Interactive Service Branding

[Simon R. <si...@ro...>]

Hi,

> Named instances sounds like is a good idea. As you pointed out, Microsoft
> itself uses command line parameters on service (like -i NAME for SQL server)
> so that looks kosher.
>
> There is a problem though: multiple instances also need multiple service
> names but the service name is hardcoded in the source. In our case even
> the dispatcher needs to know the service name(s) as we use
> SERVICE_WIN32_SHARE_PROCESS and share the process between
> the legacy service[*] and the interactive service.
>
> Looks like the service name also will have to be dynamically-generated
> from the instance name.

There is a simpler solution for that:

1. Change the order of services listed in `dispatchTable` so the interactive 
service is listed first.

2. All non-default instances could install as `SERVICE_WIN32_OWN_PROCESS`, 
thus SCM will launch them as a separate process picking only the first entry 
in the `dispatchTable` ignoring the service name and ignoring all non-first 
entries.

> If you want to support multiple installations of openvpn.exe/service,
> building with a different PACKAGE_NAME can't be avoided, can it?.
> Instead, if using the "official" executables is ok, why not just use
> oepnvpnserviceinteractive as is. Does eduVPN really need its own instance
> of the service?

No, actually eduVPN client is quite happy with the official interactive 
service as it is. Until we hit deployment issues with the 
openvpn-install-2.4.4-I601.exe installer described below.

- When OpenVPN is not already installed, we would like to install it using 
only the minimum feature selection. You see, OpenVPN GUI desktop shortcut and 
auto-start in system tray is not desirable, as it will confuse the end users 
how to start using eduVPN.
This can be accomplished using the command line parameters. So far so good.

- When an older version of OpenVPN is already installed, we would like to 
update it. Unfortunately, the installer does not detect currently installed 
features. It just copies the default feature set overwriting previous 
installation. Again, users get the OpenVPN GUI desktop shortcut and system 
tray icon. Even if they were not installed before.
We could use the command line parameters again to suggest a feature selection, 
but if the OpenVPN GUI was installed before, the update would not update it, 
leaving behind some sort of Frankenstein OpenVPN installation.
The installer is missing a command line parameter to tell it "if feature is 
present then update, else leave it absent".

- eduVPN will require latest up-to-date OpenVPN. Should any user require a 
specific older version of OpenVPN to connect to other service providers than 
eduVPN, this would be a problem.

Because of those issues, we would like to install local OpenVPN - and keep it 
up-to-date - using an MSI package. While openvpn.exe and its dependency DLLs 
can easily be managed as a local copy, the interactive service cannot - 
without interfering with original OpenVPN installation.

> That said, I like the idea of being able to run multiple (named) instances
> of the service each with its own service pipe.

I shall prepare, test and git-send-email a patch for it shortly. Thank you for 
your valued opinion.

Best regards,
Simon