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
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
