revoke scripts were broken

PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately.

[If you reply, please add a CC, I'm not on the list]

Quoted 3 lines · Jan Kiszka

PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it
- unfortunately.

Quoted 1 line

[If you reply, please add a CC, I'm not on the list]

I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though!

I don't want to bother this list with basic C programming issues though, but if someone is used to classic C programming and message handeling in windows, please contact me offlist if you got a spare minute. A pointer to a good mailing-list for discussion about classic C programming in windows would be appreciated too.

I would furthermore suggest to discuss the required interface between the GUI and the OpenVPN daemon on this list. Starting and stopping would be possibly by just running the main binary, but I think a more sophisticated status and diagnosis interface requires some other mechanism (e.g. a local socket). Such an interface could furthermore prevent that the actual user who switches some configuration or just checks the status must own superuser privileges to start/stop a OpenVPN service and - even worse - read the secret key files.

Hi all,

here is a tiny patch to make revoke-crt and make-crl work seamlessly within the easy-rsa environment. Seems that no one used it before ;)

Quoted 3 lines

Quoted 1 line

PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario?

I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though!

While considering a similar interface for some other project, I once took a closer look at wxWindows (http://www.wxwindows.org). Before you start hacking your own message handling routines in C or switching over to the Windows-only MFC library, this project may be worth some thoughts because

A) it capsulates most of the annoying GUI work, and
B) it opens to possiblity to port your work later to Linux as well!

I think not only Windows users would appreciate a simple management interface for OpenVPN clients very much...

The only problem so far: You have to consider writing your program object-oriented, i.e. in C++. Did you ever worked with some OO languages (Java e.g.)?

Quoted 8 lines

I would furthermore suggest to discuss the required interface between the GUI and the OpenVPN daemon on this list. Starting and stopping would be possibly by just running the main binary, but I think a more sophisticated status and diagnosis interface requires some other mechanism (e.g. a local socket). Such an interface could furthermore prevent that the actual user who switches some configuration or just checks the status must own superuser privileges to start/stop a OpenVPN service and - even worse - read the secret key files.

Yes, I would like to see some kind of interface for control of OpenVPN from external programs.

The mechanism of the interface would be a socket on *nix or a named pipe on Windows.

The interface would primarily be for interaction with a GUI agent and would allow for:

* Stop/Restart control
* Get status (like SIGUSR2)
* Provide authentication info

...
No, I'm not used to OO languages, unfortunally. The reasons why I started to write this in C was:

1) I only know how to code in C, VisualBasic and Assembler. Assembler is out of the question, and I'm tired of VBs dependency for a bunch of DLLs. I like beeing able to compile just one compact exe file and not need to create an installation package just to get the application working on another machine.

2) The egoistic one! I've though of learning to develop windows gui applications in C for a long time, but never really got to it. Now I saw an opportunity to write something useful and learn something I've wanted to learn at the same time.

3) OpenVPN is written in traditional C, so if I for any reason would like to integrate the gui into the openvpn binary, that would be very easy if the gui itself was written in C.

4) I like traditional C, and dislike object oriented languages! Don't ask me why, it's just my personal taste, and I can fully understand that other prefer OO languages...

I do agree with you though that makeing it portable would have been prefered, but just like you, I don't got that much spare time, so I'm not sure that I want to spend it learning yet another development environment.

James, do you put any preferance in what language/environment a gui for OpenVPN is developed in, if you would distribute it together with the main application in the future?

Quoted 3 lines

James, do you put any preferance in what language/environment a gui for OpenVPN is developed in, if you would distribute it together with the main application in the future?

These are my current thoughts on this:

* Preferably, the language development tools and environment are open source,

so there's no impediment to anyone building from source.

* The total size of included libraries should be reasonable, so it doesn't excessively push up the size of the Windows self-installing exe.

Having said that, I'm certainly going to be pragmatic here -- if someone puts

together a great GUI agent that requires Visual C++ to build, I'm not going to belabor the point.

On the other hand if it's written in Visual Basic and increases the Windows package size by 10 MB then I'm going to have to think twice about actually bundling it. But if it's up to standard, I'd still link to it from the website in a heartbeat.

James

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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?

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.

Quoted 5 lines · Brandon Knitter

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.

There are no hooks as of yet to control a running OpenVPN instance (other than sending signals).

While I initially thought that named pipes might be the appropriate channel for this, I'm wondering if if might make more sense (for portability) to use a local TCP/IP socket as the control channel, such as 127.0.0.0:[some port].

Then for testing purposes, you could just telnet to the socket.

I am thinking the interface should consist of a standard ascii command response loop, such as is used by SMTP.

Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them to the daemon via a "send auth credentials" command

The basic mechanism of operation to enable the management interface would be to pass an option like this in the config file:

management 127.0.0.1 20001

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port.

It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface.

Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.

This is all just a proposal, no code has been written yet, comments are welcome.

Quoted 43 lines · James Yonan

Quoted 5 lines · Brandon Knitter

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.

There are no hooks as of yet to control a running OpenVPN instance (other than sending signals).

While I initially thought that named pipes might be the appropriate channel for this, I'm wondering if if might make more sense (for portability) to use a local TCP/IP socket as the control channel, such as 127.0.0.0:[some port].

Then for testing purposes, you could just telnet to the socket.

I am thinking the interface should consist of a standard ascii command response loop, such as is used by SMTP.

Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them to the daemon via a "send auth credentials" command

The basic mechanism of operation to enable the management interface would be to pass an option like this in the config file:

management 127.0.0.1 20001

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port.

It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface.

Quoted 7 lines

Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.

This is all just a proposal, no code has been written yet, comments are welcome.

This sounds good to me, and will allow us to start with a basic set of "commands", and add more as we find the need for a specific function.

One little wonder though, is it good to have a bi-directional protocol over a single socket. Ofcource replys to command can go over the same channel, but if both the server and the client is allowed to "start the conversation", how do we handle the case when both the server and client sends a command at the same time.

How will we know if what we recieve is an answer to our command, or a command from the server?

In addition to the information given by SIGUSR2 I'd would like to be able to get current state of the the link. We should be able to define several STATEs during the establishing of the connection. Like:

STATE_WAIT_FIRST_RESPONE - When we have tried to connect to the remote peer but still not recieved any answer.

STATE_WAIT_AUTH - We have recieved some answer from the remove peer, but not yet fully authenticated. (This state will never happend when using static keys.)

STATE_WAIT_PUSH - We wait for options to be pushed from the server.

STATE_WAIT_SETIP - We are waiting for the system to set the ip address.

STATE_WAIT_APPLY_SETTINGS - We are waiting for the system to set other pushed parameters like routes.

STATE_CONNECTED - We are fully connected!

I have not though through the absolute meaing of those states or if the names are any good, but it gives you an idea of what kind of information I'd like to get.

The reason for several states during the init is ofcource that it will allow me to set timeout values for every step and report to the user at what step the connection failed.

I suppose it will be best if the gui client query the server for the current state.

/Mathias

Quoted 29 lines

Quoted 29 lines

There are no hooks as of yet to control a running OpenVPN instance (other than sending signals).

While I initially thought that named pipes might be the appropriate channel for this, I'm wondering if if might make more sense (for portability) to use a local TCP/IP socket as the control channel, such as 127.0.0.0:[some port].

Then for testing purposes, you could just telnet to the socket.

I am thinking the interface should consist of a standard ascii command response loop, such as is used by SMTP.

Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them to the daemon via a "send auth credentials" command

The basic mechanism of operation to enable the management interface would be to pass an option like this in the config file:

management 127.0.0.1 20001

Quoted 8 lines

Quoted 3 lines

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port.

One little wonder though, is it good to have a bi-directional protocol over a single socket. Ofcource replys to command can go over the same channel, but if both the server and the client is allowed to "start the conversation", how do we handle the case when both the server and client sends a command at the same time.

TCP connections are always full duplex so both sides can send and receive at the same time without collision issues.

Having said that, the application needs to support bidirectionality, by always having a listen queued on the port for possible incoming data.

On Windows, the best way to do this is to use the WSAAsyncSelect or WSAEventSelect functions. WSAAsyncSelect is particularly useful for Windows GUI-based programs because it gives you notification of incoming data on a TCP socket through the standard Windows message notification mechanism.

Quoted 2 lines

How will we know if what we recieve is an answer to our command, or a command from the server?

The unsolicited notification from the server would have a specific prefix that indicates that it is an asynchronous notification from the server, as opposed to a response to a client->server command.

For example, the server would say something like this:

NOTIFY:NEED_AUTH,USER,PASS

The "ASYNC" indicates that the message is an asynchronous notification.

NEED_AUTH is the command, and USER/PASS indicates that the GUI should prompt the user for and return both username and password.

Then the GUI would reply back:

AUTH_USER [username]
AUTH_PASS [password]

Quoted 11 lines

In addition to the information given by SIGUSR2 I'd would like to be able to get current state of the the link. We should be able to define several STATEs during the establishing of the connection. Like:

STATE_WAIT_FIRST_RESPONE - When we have tried to connect to the remote peer but still not recieved any answer.

STATE_WAIT_AUTH - We have recieved some answer from the remove peer, but not yet fully authenticated. (This state will never happend when using static keys.)

Quoted 8 lines

STATE_WAIT_PUSH - We wait for options to be pushed from the server.

STATE_WAIT_SETIP - We are waiting for the system to set the ip address.

STATE_WAIT_APPLY_SETTINGS - We are waiting for the system to set other pushed parameters like routes.

STATE_CONNECTED - We are fully connected!

We already have something like this in ssl.h (see "key negotiation states"), but your idea expands beyond this.

I think the states are a good idea. The state info, like the request for auth credentials, will be an asynchronous server -> client notification.

For example:

NOTIFY:STATE,STATE_CONNECTED

management 127.0.0.1 20001

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port.

It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface.

Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.

Quoted 5 lines · James Yonan

management 127.0.0.1 20001

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management interface port.

Quoted 7 lines

It's important, of course, that the management port always be local, since we are using it to potentially pass passwords and other sensitive data that should never actually touch a real network interface.

Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.

Please don't do too much of that. I've seen this auth featuritis creeping in ntp and ups tools(!). Results ain't pretty...

Reconfiguration of openvpn can always be done by editing config file and restarting openvpn daemon. Simple. Elegant. No additional coding
- no risk of introducing bugs.

This can be done via systray app, too.

...
Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them to the daemon via a "send auth credentials" command

The basic mechanism of operation to enable the management interface would be to pass an option like this in the config file:

management 127.0.0.1 20001

Quoted 7 lines

Quoted 4 lines

Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.

Please don't do too much of that. I've seen this auth featuritis creeping in ntp and ups tools(!). Results ain't pretty...

Quoted 5 lines

Reconfiguration of openvpn can always be done by editing config file and restarting openvpn daemon. Simple. Elegant. No additional coding
- no risk of introducing bugs.

This can be done via systray app, too.

I can understand your concerns, and mostly you are right. However, there is one quite important scenario - at least as I see it - where you need the core daemon and the GUI running in different accounts: whenever the key or secret has to be looked away from the user while it shall still be possible for her/him to start/stop VPN connections. One reason for this may be that the key is bound to the device and not the user. The other one is security. Through this separation, malicious programs running in the context of the user can not so easily access the secret.

And for those who don't trust this new interface (which will surely need a careful implementation): what about adding a configure switch and putting the respective code in some #ifdefs?

Quoted 12 lines

Quoted 4 lines

Thinking ahead, the challenge/response sequence for passing authentication info should be open-ended to provide for future implementation of alternative authentication methods such as Radius, LDAP, NT Auth, etc.

Please don't do too much of that. I've seen this auth featuritis creeping in ntp and ups tools(!). Results ain't pretty...

Reconfiguration of openvpn can always be done by editing config file and restarting openvpn daemon. Simple. Elegant. No additional coding
- no risk of introducing bugs.

Quoted 1 line

This can be done via systray app, too.

I can understand your concerns, and mostly you are right. However, there is one quite important scenario - at least as I see it - where you need the core daemon and the GUI running in different accounts: whenever the key or secret has to be looked away from the user while it shall still be possible for her/him to start/stop VPN connections. One reason for

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.

Quoted 4 lines · Jan Kiszka

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.

Quoted 6 lines · Mathias Sundman

Quoted 4 lines · Jan Kiszka

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.

Quoted 7 lines

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.

Quoted 2 lines

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.

...

Quoted 2 lines

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.

Quoted 7 lines · James Yonan

...

Quoted 2 lines

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...

Quoted 12 lines · Jan Kiszka

Quoted 9 lines · James Yonan

...

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 9 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

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?).

Quoted 12 lines · Jan Kiszka

Quoted 10 lines · James Yonan

...

Quoted 2 lines

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.

Quoted 1 line

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?

Quoted 4 lines · Jan Kiszka

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

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...

Quoted 5 lines

Quoted 5 lines

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?

Quoted 6 lines

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.

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...

Quoted 11 lines · Mathias Sundman

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.

Quoted 43 lines · James Yonan

Quoted 11 lines · Mathias Sundman

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.

Quoted 8 lines

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.

Quoted 3 lines

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.

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.

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

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.

Quoted 9 lines

Quoted 9 lines

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.

Quoted 5 lines

Quoted 5 lines

(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.

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.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

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?

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

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.

Quoted 7 lines

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?

Quoted 5 lines · Mathias Sundman

Quoted 5 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

...
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)

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.

...

Quoted 6 lines

Quoted 6 lines

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.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

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.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

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/.

Quoted 5 lines · Mathias Sundman

...
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:

Quoted 1 line

* 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.