Re: [Openvpn-devel] Re: Interface with GUI agent
On Sunday 11 July 2004 14:51, Jan Kiszka wrote: > Mathias Sundman wrote: > > ... > > One more thing to consider... Should we consider a system running this > > service manager an open system where all locally logged on users is > > allowed to fully manage openvpn connections, which includes: > > > > * Start/Stop openvpn processes > > As a first step, I think we should allow all users to access this > service. Later on, one may consider some authorisation mechanism to > access specific configurations. This could be some additional parameter > in a config file or some meta config file for the wrapping service. Just use ssh. Those who know username/password of special user able to control openvpn could log in via ssh and do it. -- vda
[Openvpn-devel] Re: Interface with GUI agent
James Yonan wrote: I'm not sure that we really need a wrapper for unix, because most unix users will control OpenVPN by: (1) editing config files and starting from /etc/init.d, or (2) using some sort of GUI-based admin tool such as YaST and both of these methods are traditionally done as root. You consider the typical openvpn user in a client scenario under unix as a command line freak - might be still true for the moment, but certainly not in the future. An increasing number of gui-oriented users are switching over to unix, in particular linux. And what would be better for a smooth switch-over than finding a similar gui on both platforms? Command line freaks already have anything the need with what openvpn now provides, so this is not the audience we should target. ... Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will then have to be implemented quite differently on Windows and Unix. On Windows, we would open a socket and both send the commands over it and receive the status. On Unix, we would first start the process and then connect to a socket for status information (BTW, which socket would then be used when multiple instances of openvpn are running?). Should the unix GUI be written for generic X, or should we develop admin modules for specific distros such as YaST? I would go for the latter, because it will make the interface fit more seamlessly into a distribution's existing admin infrastructure. I would not think about an admin gui at the moment. Maybe this will never be needed as configuration files are much easier to handle. I'm personally not looking for gui dialogs where I can select and combine graphically any option the openvpn service provides - in case this is the impression you got of my feature request. If SuSE, any other distributor, or projects like webmin are interested in providing some gui for creating the config file, let them do this. But we should first concentrate on an interface for *using* openvpn in daily work! Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] Re: Interface with GUI agent
Denis Vlasenko wrote: 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. (b) already exists. It's daemontools. (Does not exist on NT, though). Daemontools' license is not open enough, but there is a opensource clone at http://smarden.org/runit/. I actually don't see why we should add this external dependency to openvpn or its graphical frontend. The daemontools are just another layer which would just take us half the way to a gui, we would then still need to control the daemontools itself (starting/stopping openvpn via the respective command or grabbing the status from the tools). Basically, the only feature we really need is to start or stop some privileged process, that's all. Coding this into a service wrapper for openvpn takes as much effort as handling something like daemontools itself - both with respect to development time (a few hours up to a day) and to code size. Handling the status information of openvpn is so specific in any way, that daemontools cannot help us here. But hey, I guess you will never need that wrapper anyhow, because its only purpose will be to enable running the gui. There will be likely no impact on the openvpn core itself besides an extended status interface (probably via stdout only). Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] Re: Interface with GUI agent
Mathias Sundman wrote: ... One more thing to consider... Should we consider a system running this service manager an open system where all locally logged on users is allowed to fully manage openvpn connections, which includes: * Start/Stop openvpn processes As a first step, I think we should allow all users to access this service. Later on, one may consider some authorisation mechanism to access specific configurations. This could be some additional parameter in a config file or some meta config file for the wrapping service. * Create new openvpn configs * delete openvpn configs (Hereby not said that creating/deleting configs should be done via the service manager. I just want to discuss whether a normal user should be able to do this or not) As just said in my reply to an earlier mail, I don't think that modifying the configurations shall become part of the gui. This would be feature overloading, especially on a unix system where you typically configure using a text editor. Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Openvpn-devel] Re: Interface with GUI agent
> > IMHO daemontools for windows, if ported, can handle quite a variety > > of different setups, including one needed by openvpn. Then you can > > install it as part of openvpn install. > > If the only issue we had to solve here was how a normal user should be > able to spawn openvpn processes, I agree we should use already existing > software to solve this. > > However, this issue has grown abit larger than that. Our gui client needs > to: > > * Scan a directory for configuration files. > * A way to spawn processes (preferable portable) > * Maintain a table over on which port it can reach the openvpn >process management interface. > * Monitor that all openvpn processes are still alive > * Connect to all the openvpn processes and get status info :) I will append 'man svscan' and 'man supervise'. Judge for yourself how many of your points are covered by them. Also I'll append my current 'ps -AH e' output. You can see there how completely different daemons are controlled by those tools. > There is no fancy hardcoded things we are talking about, so it could all > reside in the gui client, however I liked the idea of moving this > functionallity into a portable service manager. > > I need to code this regardless if we put it in the gui agent itself, or in > this service manager, so I think it makes more sence to put the effort > into a deamon from which other gui clients can benefit on all platforms, > instead of into my not-so-portable gui. No need to code it. Port it to Windows. That's all. -- vda svscan(8)svscan(8) NAME svscan - starts and monitors a collection of services SYNOPSIS svscan [ directory ] DESCRIPTION svscan starts one supervise(8) process for each subdirectory of the current directory, up to a limit of 1000 subdirectories. svscan skips subdirectory names starting with dots. supervise(8) must be in svs- can's path. svscan optionally starts a pair of supervise(8) processes, one for a subdirectory s, one for s/log, with a pipe between them. It does this if the name s is at most 255 bytes long and s/log exists. (In versions 0.70 and below, it does this if s is sticky.) svscan needs two free descriptors for each pipe. Every five seconds, svscan checks for subdirectories again. If it sees a new subdirectory, it starts a new supervise(8) process. If it sees an old subdirectory where a supervise(8) process has exited, it restarts the supervise(8) process. In the log case it reuses the same pipe so that no data is lost. svscan is designed to run forever. If it has trouble creating a pipe or running supervise(8), it prints a message to stderr; it will try again five seconds later. If svscan is given a command-line argument directory, it switches to that directory when it starts. SEE ALSO supervise(8), svc(8), svok(8), svstat(8), svscanboot(8), readprocti- tle(8), fghack(8), pgrphack(8), multilog(8), tai64n(8), tai64nlocal(8), setuidgid(8), envuidgid(8), envdir(8), softlimit(8), setlock(8) http://cr.yp.to/daemontools.html svscan(8) supervise(8) supervise(8) NAME supervise - starts and monitors a service. SYNOPSIS supervise s DESCRIPTION supervise switches to the directory named s and starts ./run. It restarts ./run if ./run exits. It pauses for a second after starting ./run, so that it does not loop too quickly if ./run exits immediately. If the file s/down exists, supervise does not start ./run immediately. You can use svc(8) to start ./run and to give other commands to super- vise. supervise maintains status information in a binary format inside the directory s/supervise, which must be writable to supervise. The status information can be read by svstat(8). supervise may exit immediately after startup if it cannot find the files it needs in s or if another copy of supervise is already running in s. Once supervise is successfully running, it will not exit unless it is killed or specifically asked to exit. You can use svok(8) to check whether supervise is successfully running. You can use svscan(8) to reliably start a collection of supervise processes. SEE ALSO svc(8), svok(8), svstat(8), svscanboot(8), svscan(8), readproctitle(8), fghack(8), pgrphack(8), multilog(8), tai64n(8), tai64nlocal(8), setu- idgid(8), envuidgid(8), envdir(8), softlimit(8), setlock(8) http://cr.yp.to/daemontools.html supervise(8) # ps -AH e PID TTY STAT TIME C
Re: [Openvpn-devel] Re: Interface with GUI agent
On Fri, 9 Jul 2004, Denis Vlasenko wrote: On Friday 09 July 2004 00:35, Mathias Sundman wrote: What I am trying to say? I am very happy that you guys are actively working on openvpn. Really. Just please do not OVERdesign it. Maybe it's better to try to port daemontools to Windows and run openvpn daemon(s) under it. I agree that we must watch out so we don't overdesign it. It's easily done. However, one thing to keep in mind is that we're not talking about adding complexity to the openvpn binary (except for an interface to get status information), and we're not talking about removing current functionallity. IMHO daemontools for windows, if ported, can handle quite a variety of different setups, including one needed by openvpn. Then you can install it as part of openvpn install. If the only issue we had to solve here was how a normal user should be able to spawn openvpn processes, I agree we should use already existing software to solve this. However, this issue has grown abit larger than that. Our gui client needs to: * Scan a directory for configuration files. * A way to spawn processes (preferable portable) * Maintain a table over on which port it can reach the openvpn process management interface. * Monitor that all openvpn processes are still alive * Connect to all the openvpn processes and get status info There is no fancy hardcoded things we are talking about, so it could all reside in the gui client, however I liked the idea of moving this functionallity into a portable service manager. I need to code this regardless if we put it in the gui agent itself, or in this service manager, so I think it makes more sence to put the effort into a deamon from which other gui clients can benefit on all platforms, instead of into my not-so-portable gui. -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
Re: [Openvpn-devel] Re: Interface with GUI agent
On Friday 09 July 2004 00:35, Mathias Sundman wrote: > > What I am trying to say? I am very happy that you guys are actively > > working on openvpn. Really. > > > > Just please do not OVERdesign it. > > > > Maybe it's better to try to port daemontools to Windows > > and run openvpn daemon(s) under it. > > I agree that we must watch out so we don't overdesign it. It's easily > done. However, one thing to keep in mind is that we're not talking about > adding complexity to the openvpn binary (except for an interface to get > status information), and we're not talking about removing current > functionallity. > > Which means that it will still be perfectly possible to run openvpn just > like we have always done from the cmd-line or from the init-scripts, and I > think this will continue to be the most-used method on unix platforms. > > Windows users on the other hand tends to want automatic graphical > installation packages and a nice gui to click on, and get afraid if they > need to edit a textfile! So we need to keep the whole chain from > installation to operating really simple. > > Do you think we can achive this using deamon tools? IMHO daemontools for windows, if ported, can handle quite a variety of different setups, including one needed by openvpn. Then you can install it as part of openvpn install. -- vda
Re: [Openvpn-devel] Re: Interface with GUI agent
On Thu, 8 Jul 2004, Denis Vlasenko wrote: 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 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. (b) already exists. It's daemontools. (Does not exist on NT, though). Daemontools' license is not open enough, but there is a opensource clone at http://smarden.org/runit/. ... What I am trying to say? I am very happy that you guys are actively working on openvpn. Really. Just please do not OVERdesign it. Maybe it's better to try to port daemontools to Windows and run openvpn daemon(s) under it. I agree that we must watch out so we don't overdesign it. It's easily done. However, one thing to keep in mind is that we're not talking about adding complexity to the openvpn binary (except for an interface to get status information), and we're not talking about removing current functionallity. Which means that it will still be perfectly possible to run openvpn just like we have always done from the cmd-line or from the init-scripts, and I think this will continue to be the most-used method on unix platforms. Windows users on the other hand tends to want automatic graphical installation packages and a nice gui to click on, and get afraid if they need to edit a textfile! So we need to keep the whole chain from installation to operating really simple. Do you think we can achive this using deamon tools? -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
Re: [Openvpn-devel] Re: Interface with GUI agent
> > >> 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. (b) already exists. It's daemontools. (Does not exist on NT, though). Daemontools' license is not open enough, but there is a opensource clone at http://smarden.org/runit/. > > > (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. Let me hijack your attention for a moment. Once I bought an UPS. I googled for UNIX UPS tools and found package named NUT. I downloaded and installed it. It consists of low-level UPS drivers, UPS-monitoring daemons, servers listening on TCP and clients which can talk to these servers. And maybe something else, I forgot. A bunch of config files is used to configure things like how are UPSes connected, which users can do what to which UPS, etc, etc, etc. After an hour spent figuring out how to organize it, I managed to start it. Or shall I say 'them', because I needed to run several processes. I ended up with 2 Mbites of RSS spent for UPS monitoring. I didn't like it. I didn't like it at all. I didn't like multiple config files. I didn't like additional user auth and crypto (who can connect to my UPS daemon, passwords, encryption of TCP protocol used to talk with it). Why do I need Yet Another TCP Server, Auth, Crypto, Logging, Etc when ssh/ssl and daemontools already exist and is well debugged? I took NUT apart. I chainsawed away the cruft, all 99% of it, and made smallish daemon which connects to serial port and can (1) poll UPS about it's state and (2) can command UPS to e.g. test battery, shutdown, etc. I put it under daemontools. I don't need to control it over the net or from another user account, but if I'll need to, I will do it using existing tools like ssh. For example, ability to stop/restart daemon by user is controlled via chmod/chown'ing daemontools' control file. Daemontools are very elegant. Instead of reinventing ACLs, they _use_ ACLs already designed for filesystem access control. Cool, isn't it? When compiled against dietlibc, my ups daemon consumes 32 _kilobytes_ of RAM: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 884 root 15 032 3224 S 0.0 0.0 0:01 0 powermust What I am trying to say? I am very happy that you guys are actively working on openvpn. Really. Just please do not OVERdesign it. Maybe it's better to try to port daemontools to Windows and run openvpn daemon(s) under it. > All of this of course represents a lot of development effort, so I think it > makes a lot of sense to "evolve" towards these goals in small incremental > steps. Exactly what I meant. It's counterproductive to reinvent the wheel. NUT folks wrote a ton of code duplicated in ssh et al, and they need to debug it also. Nnd then it just sits there wasting RAM. Ugly. -- vda
Re: [Openvpn-devel] Re: Interface with GUI agent
On Thu, 8 Jul 2004, James Yonan wrote: 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 think that the goal here is to work towards putting all of the complexity into the portable service manager, so the GUI applet will only open a single local TCP connection to the service manager, and the service manager will deal with communicating with the individual OpenVPN processes. I agree. All of this of course represents a lot of development effort, so I think it makes a lot of sense to "evolve" towards these goals in small incremental steps. Agree here to. One more thing to consider... Should we consider a system running this service manager an open system where all locally logged on users is allowed to fully manage openvpn connections, which includes: * Start/Stop openvpn processes * Create new openvpn configs * delete openvpn configs (Hereby not said that creating/deleting configs should be done via the service manager. I just want to discuss whether a normal user should be able to do this or not) or, do we need to restrict this somehow. Two ways to restict this: 1. On filesystem level we could have the service manger only read config files from a prespecified directory, and can then disallow normal users access to that directory by normal FS restrictions. This would allow us to control which users is allowed to add/delete/modify config-files, but not stop them from starting/stopping preconfigured connections. 2. Use authentication on the socket to the service manager. This would allow us to fully control which user is allowed to do what, but it would add alot of complexity so I think it should be avoided, if really don't need this. Comments? -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
Re: [Openvpn-devel] Re: Interface with GUI agent
On Thursday 08 July 2004 02:55, Mathias Sundman wrote: > On Wed, 7 Jul 2004, James Yonan wrote: > > 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. > > I agree this seems to be the best way to proceed. On thing is unclear (for > me atleast) though. The gui should talk with the service manager to do the > follow things: > > * Get a list of running processes. > * Start a new process. > * Stop a running process. > > But, how should the "check tunnel status" part be implemented? > > 1. The gui applet gets information from the service manager about which > port each ovpn process is listening on. The gui then connects directly to > each process to monitor it's status. > > 2. The service manager connects to each process to monitor its "tunnel > status" and then maintain this information in its table over running > processes. The gui applet can then get this information from the > service manager over the same socket as it starts/stops the ovpn > processes. I think that the goal here is to work towards putting all of the complexity into the portable service manager, so the GUI applet will only open a single local TCP connection to the service manager, and the service manager will deal with communicating with the individual OpenVPN processes. So the GUI applet will send a command to the service manager to enumerate all configs. Each line of output from the service manager will list the name of the config file and a comma-separated list of status fields, including stuff like connection status, and traffic byte counts. There will also be a mechanism for the GUI to turn on asynchronous notification of various events from all or specific OpenVPN processes. As discussed before, such notifications (when turned on) will cause unsolicited output to be sent to the GUI applet with some kind of prefix which identifies the source of the notification. One thing that's nice about using 127.0.0.1 TCP ports for ascii-based communication is that you can telnet to the the service manager or the individual OpenVPN processes, on their TCP ports, and test various commands and responses. All of this of course represents a lot of development effort, so I
Re: [Openvpn-devel] Re: Interface with GUI agent
On Wed, 7 Jul 2004, James Yonan wrote: 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. I agree this seems to be the best way to proceed. On thing is unclear (for me atleast) though. The gui should talk with the service manager to do the follow things: * Get a list of running processes. * Start a new process. * Stop a running process. But, how should the "check tunnel status" part be implemented? 1. The gui applet gets information from the service manager about which port each ovpn process is listening on. The gui then connects directly to each process to monitor it's status. 2. The service manager connects to each process to monitor its "tunnel status" and then maintain this information in its table over running processes. The gui applet can then get this information from the service manager over the same socket as it starts/stops the ovpn processes. -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
Re: [Openvpn-devel] Re: Interface with GUI agent
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 st
[Openvpn-devel] Re: Interface with GUI agent
On Tuesday 06 July 2004 04:25, Mathias Sundman wrote: > On Tue, 6 Jul 2004, Jan Kiszka wrote: > > If it's not a windows specific problem, then I suppost it's best to > > add the functionallity in the openvpn binary so we get the > > portability. > > I don't think the openvpn binary needs to know about this. But the > service wrapper probably needs a second mode of operation, where > instead of getting its config files by scanning a directory, it > listens on a local socket for a command from the GUI to start an > openvpn.exe instance. > >>> > >>> Then don't forget that we will need a similar wrapper for unix as > >>> well... I'm not sure that we really need a wrapper for unix, because most unix users will control OpenVPN by: (1) editing config files and starting from /etc/init.d, or (2) using some sort of GUI-based admin tool such as YaST and both of these methods are traditionally done as root. > >> Why do we need a wrapper in unix? Can't the openvpn binary be run as a > >> normal user in unix? > >> > >> If we need root-privs, what's wrong with installing openvpn as suid > >> root and have it drop its privs after start-up? Not a big problem, though some might prejudice a package which requires SUID. > > Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will > > then have to be implemented quite differently on Windows and Unix. On > > Windows, we would open a socket and both send the commands over it and > > receive the status. On Unix, we would first start the process and then > > connect to a socket for status information (BTW, which socket would then > > be used when multiple instances of openvpn are running?). Should the unix GUI be written for generic X, or should we develop admin modules for specific distros such as YaST? I would go for the latter, because it will make the interface fit more seamlessly into a distribution's existing admin infrastructure. > Yes and No. The way the GUI starts an openvpn process will have to > implemented in diffrent ways for unix and windows. On Windows it will open > a socket to the service wrapper and tell it to start an openvpn process > with a specific config. On unix it will launch the openvpn process itself. > This is not many lines of code so I think it can be handled with ifdefs > quite cleanly. > > Then when the openvpn process has been started the gui connects to a > socket that openvpn is listening on to receive status or send other > commands that we can think of. > > The socket each openvpn process is listening on should be specified in the > config-file with an option like "management 127.0.0.1 6001", where 6001 is > the TCP port number. So each process should be listening on a unique port. > > A perhaps cleaner way is that the gui adds the manangement option when it > starts the openvpn process, so the user don't have to bother setting the > correct management option in his config-files. I agree. This is sort of like the way the current service wrapper passes --service to each OpenVPN process. So the system-tray GUI manages a pool of 127.0.0.1 ports and allocates them to OpenVPN processes. James
[Openvpn-devel] Re: Interface with GUI agent
On Tuesday 06 July 2004 03:46, Mathias Sundman wrote: > On Tue, 6 Jul 2004, Jan Kiszka wrote: > > James Yonan wrote: > >> ... > >> > >>> If it's not a windows specific problem, then I suppost it's best to add > >>> the functionallity in the openvpn binary so we get the portability. > >> > >> I don't think the openvpn binary needs to know about this. But the > >> service wrapper probably needs a second mode of operation, where instead > >> of getting its config files by scanning a directory, it listens on a > >> local socket for a command from the GUI to start an openvpn.exe > >> instance. > > > > Then don't forget that we will need a similar wrapper for unix as well... > > Why do we need a wrapper in unix? Can't the openvpn binary be run as a > normal user in unix? The sticking point for running in user mode is opening the tun/tap device node and adding routes. James
[Openvpn-devel] Re: Interface with GUI agent
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. 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. 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 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. 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. 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 started manually from the gui later. I've thought of two ways of doing this. 2a. Use a config file which list which configs that should be launched at boot-time. If that config file does not exist, it will launch all it finds, as it is today. A gui agent can then create this file to specify which configs should be launched at boot-time. 2b. Use another folder for configs that should not be started at boot-time. Please let me know how you think we should handle these issues before I put anymore work into the service wrapper in a wrong direction... -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
[Openvpn-devel] Re: Interface with GUI agent
On Tue, 6 Jul 2004, Jan Kiszka wrote: If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Then don't forget that we will need a similar wrapper for unix as well... Why do we need a wrapper in unix? Can't the openvpn binary be run as a normal user in unix? If we need root-privs, what's wrong with installing openvpn as suid root and have it drop its privs after start-up? Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will then have to be implemented quite differently on Windows and Unix. On Windows, we would open a socket and both send the commands over it and receive the status. On Unix, we would first start the process and then connect to a socket for status information (BTW, which socket would then be used when multiple instances of openvpn are running?). Yes and No. The way the GUI starts an openvpn process will have to implemented in diffrent ways for unix and windows. On Windows it will open a socket to the service wrapper and tell it to start an openvpn process with a specific config. On unix it will launch the openvpn process itself. This is not many lines of code so I think it can be handled with ifdefs quite cleanly. Then when the openvpn process has been started the gui connects to a socket that openvpn is listening on to receive status or send other commands that we can think of. The socket each openvpn process is listening on should be specified in the config-file with an option like "management 127.0.0.1 6001", where 6001 is the TCP port number. So each process should be listening on a unique port. A perhaps cleaner way is that the gui adds the manangement option when it starts the openvpn process, so the user don't have to bother setting the correct management option in his config-files. This interface to the openvpn deamon will be the same regardless of the platform. -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
[Openvpn-devel] Re: Interface with GUI agent
Mathias Sundman wrote: On Tue, 6 Jul 2004, Jan Kiszka wrote: James Yonan wrote: ... If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Then don't forget that we will need a similar wrapper for unix as well... Why do we need a wrapper in unix? Can't the openvpn binary be run as a normal user in unix? If we need root-privs, what's wrong with installing openvpn as suid root and have it drop its privs after start-up? Yes, this will work. But I'm afraid - maybe I'm wrong - that the GUI will then have to be implemented quite differently on Windows and Unix. On Windows, we would open a socket and both send the commands over it and receive the status. On Unix, we would first start the process and then connect to a socket for status information (BTW, which socket would then be used when multiple instances of openvpn are running?). We still need the management interface in openvpn though for all platforms so we can check the status of the connection from a gui, but that's another issue. Don't think so. We should first find a concept for both topics so that we can be sure that nothing interfers later. Jan smime.p7s Description: S/MIME Cryptographic Signature
[Openvpn-devel] Re: Interface with GUI agent
On Tue, 6 Jul 2004, Jan Kiszka wrote: James Yonan wrote: ... If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Then don't forget that we will need a similar wrapper for unix as well... Why do we need a wrapper in unix? Can't the openvpn binary be run as a normal user in unix? If we need root-privs, what's wrong with installing openvpn as suid root and have it drop its privs after start-up? We still need the management interface in openvpn though for all platforms so we can check the status of the connection from a gui, but that's another issue. -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
[Openvpn-devel] Re: Interface with GUI agent
James Yonan wrote: ... If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Then don't forget that we will need a similar wrapper for unix as well... Jan smime.p7s Description: S/MIME Cryptographic Signature
[Openvpn-devel] Re: Interface with GUI agent
On Mon, 5 Jul 2004, James Yonan wrote: On Monday 05 July 2004 14:49, Mathias Sundman wrote: On Sun, 4 Jul 2004, Jan Kiszka wrote: I would like to have some mechanism to fork an openvpn instance and let the new process use a specific configuration file. This would allow to start only certain VPN tunnels depending on what the user selects in the GUI. I've been giving this some more thought... and I agree we definitly need something like this. If it's a windows specific problem, then maybe this functionally should be in the service wrapper. If we add a simple interface to the service wrapper our gui client could tell the service wrapper to start new openvpn processes when we want. Yes, this is probably a better idea. If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. Do you have time to do this in the near future? Otherwise, I think I could do it. I'm pretty familiar with the service wrapper code now that I've copied most of it to my gui :-) So now I just need to put it back in the service wrapper! -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
[Openvpn-devel] Re: Interface with GUI agent
On Monday 05 July 2004 14:49, Mathias Sundman wrote: > On Sun, 4 Jul 2004, Jan Kiszka wrote: > > I would like to have some mechanism to fork an openvpn instance and let > > the new process use a specific configuration file. This would allow to > > start only certain VPN tunnels depending on what the user selects in the > > GUI. > > I've been giving this some more thought... and I agree we definitly need > something like this. > > Is it possible in windows to install a program as SUID in unix, so the > application is ran as administrator even though it is started by an > ordinary user? If yes, that would be eliminate the need to fork new > processes (as I can think of right now atleast). No, I don't think this is possible in Windows. > If no, Is it only on windows we can't do this, or do we have this problem > on other platforms too? Most other platforms support the SUID bit. > If it's a windows specific problem, then maybe this functionally should be > in the service wrapper. If we add a simple interface to the service > wrapper our gui client could tell the service wrapper to start new openvpn > processes when we want. Yes, this is probably a better idea. > If it's not a windows specific problem, then I suppost it's best to add > the functionallity in the openvpn binary so we get the portability. I don't think the openvpn binary needs to know about this. But the service wrapper probably needs a second mode of operation, where instead of getting its config files by scanning a directory, it listens on a local socket for a command from the GUI to start an openvpn.exe instance. James
[Openvpn-devel] Re: Interface with GUI agent
On Sun, 4 Jul 2004, Jan Kiszka wrote: I would like to have some mechanism to fork an openvpn instance and let the new process use a specific configuration file. This would allow to start only certain VPN tunnels depending on what the user selects in the GUI. I've been giving this some more thought... and I agree we definitly need something like this. Is it possible in windows to install a program as SUID in unix, so the application is ran as administrator even though it is started by an ordinary user? If yes, that would be eliminate the need to fork new processes (as I can think of right now atleast). If no, Is it only on windows we can't do this, or do we have this problem on other platforms too? If it's a windows specific problem, then maybe this functionally should be in the service wrapper. If we add a simple interface to the service wrapper our gui client could tell the service wrapper to start new openvpn processes when we want. If it's not a windows specific problem, then I suppost it's best to add the functionallity in the openvpn binary so we get the portability. -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
[Openvpn-devel] Re: Interface with GUI agent
On Sat, 3 Jul 2004, Brandon Knitter wrote: Hey there. James and I had a prior discussion about the systray app offline, but I thought I'd just poke my head in here. I'm not a strong Windows application programmer, but I've been doing a lot of C# these days. With that in mind, I was gonna whip together a quickie little systray app in C# which could control the openvpn server. I know that C# adds the rather large .NET framework runtime installation, so my app could be considered a prototype if you would like! Where do I start? Are the namedpipe hooks into the OpenVPN service built? I'm not too familiar with named pipes on Windows (done a bit on *nix), but I'm sure it can't be too hard. I guess what I'd need to know are the command to send to the named pipe, and also what I can get from the named pipe in regards to status and such. Any suggestions? Hi Brandon! Have you looked at the systray application I wrote and released on the users-list last night? If not, have a look at http://www.nilings.se/openvpn I'm working hard on next version right now and will probably release it tomorrow. This version will support controlling multiple tunnels simultaneously from the the menu, and monitor if the process ends before it is manually disconnected. My version is written in pure Win32 C code, but if you want to rewrite it using C# you are ofcource welcome... Best Regards Mathias -- _ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS ABXNO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail
