Re: [Openvpn-devel] OpenVPN Interactive Service Branding

[Selva <sel...@gm...>]

Hi,

On Tue, Oct 31, 2017 at 5:19 PM, Simon Rozman <si...@ro...> wrote:

> Hi,
>
> > Instead of a pipe name set at compile-time, I think its better to make
> this
> > customizable by the installer. That is, we could take service name from
> an
> > optional registry entry so that it may be renamed by the installation
> package.
>
> Honestly, to make the name of the named pipe and the registry

dynamically configurable was my first idea too. Only to find out

that openvpnserv.exe already supports compile-time customization

of the settings registry key. Thus, extending this practice to the

named pipe was the "KISS" approach.
>
> I'd propose to use a service command line argument. Something

like "--instance name". When --instance is not specified the name

defaults to "OpenVPN". The service command line is stored in

registry after all: HKEY_LOCAL_MACHINE\SYSTEM\Curr
> entControlSet\Services\<service name>\ImagePath.

Example: Microsoft SQL Server is using service command

line arguments to support multiple instances.


> If we could make this patch merged into the official OpenVPN distribution,

it would be a big win for us too, as we would no longer require to compile

openvpnserv.exe ourselves anymore.
>

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.

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?

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

Selva