On Tuesday 06 July 2004 16:58, Mathias Sundman wrote:
> Some more things to consider...
>
> 1. On Windows, if the the service wrapper has started some openvpn
> processes before our gui agent is started, how should find out about
> those processes?
>
> I can think of the following ways:
>
> 1a. Ask the service wrapper via the socket interface that I'm working on
> right now. This will require the service wrapper not only start the
> processes, but keep a table over running processes.
I think it's an important point worth some discussion on whether to (a) put
all the "intelligence" in the GUI applet and have the service wrapper just be
a basic proxy to an admin-privileged CreateProcess, or (b) write a portable
service wrapper that's designed to run on all the OSes which OpenVPN
currently supports, and which would do all the "under-the-hood" work in
starting/stopping/managing of different OpenVPN processes, and the GUI applet
would do nothing more than export the control interface of the portable
service wrapper to a platform-specific, lightweight GUI.
(a) is probably simpler to develop, but (b) may be a better solution long-term
because it handles the management interface in a portable way, and makes the
GUI itself (which probably needs a separate admin module for Win32, YaST, X,
http, etc.) as lightweight and stateless as possible.
Now the way I would implement (b) is to design as much of the "portable
service wrapper" code as is possible without actually coding any function
calls to create windows or dispatch window messages or do any GUI stuff
directly. The service wrapper would take care of instantiating OpenVPN
processes, managing the 127.0.0.1 port pool to communicate with the
processes.
Now the GUI applet itself becomes very simple and stateless, it only needs to
connect to the service wrapper, and any window message corresponding to a
user mouse action gets encoded into a simple command that gets sent to the
service wrapper.
I agree that this is a more complicated problem to solve because now we have
the service wrapper which is talking to the individual OpenVPN processes, and
we have the GUI applet talking to the service manager.
But long term (IMHO) this gives us great flexibility to easily port the GUI
applet to other interfaces, such as even http. It would be very cool, for
example, if with a little bit of php programming, you could control your
OpenVPN instances via a web interface for example. You wouldn't need to
rewrite a huge program which deals with all the details of
starting/stopping/managing the pool of OpenVPN processes, because that
program would already exist as the cross-platform service wrapper daemon.
> 1b. Scan a defined directory for config files, and require the config
> files to have a management option. Then we can try connecting to the
> specified tcp port to find if there is a running ovpn process.
No, I don't think people should explicitly put the management option in their
config files.
> 1c. Query the system for processes with the name "openvpn", and which
> sockets this process has opened. Then we could try connecting to those
> ports to find the management socket.
I don't like the idea of querying the system for "openvpn" processes (for one
there's no portable API for querying the system for processes). I would
rather see the manager deal with managing a pool of local ports.
> I dislike 1b because it would complicate for the user, that he has to have
> the management option in his config-file. If using 1a that is handled
> automaticly by the gui or service wrapper.
I agree, the management option is something that should be programmatically
placed on the command line by the program which does the CreateProcess to
start the OpenVPN instantiation on a given config file.
> The drawback with 1a is, how do we handle the same thing on unix? There
> could be situations where we would like start the vpn before a gui agent
> here to. Are we back to what Jan K said, we need a "service wrapper" for
> unix to, that can run at al ltime as a deamon and keep track of our
> openvpn processes? It would require some extra work writing this deamon
> to, but it would give us a consistent way of starting openvpn processes
> from a gui agent regardless of the platform.
I'm not sure that we need to add the complexity of a service wrapper on unix,
because most unix users take it as a matter of course that touching the
network configuration requires root privileges.
I think it's fair to say that root is required, and if someone _really_ wants
to control tunnels from non-root, then they must SUID the binary, or change
the permissions on the tun/tap device node.
>
>
>
> 2. How should the service wrapper know which configs to launch at
> start-up? To maintain backwords-compatibility it should launch all config
> files in the config folder. However the gui agent should be able to
> handle both processes started at boot-time and other that is
