openfortivpn
openfortivpn copied to clipboard
Added daemon run mode
As title says, adding daemon mode to run tunnel in background, like most servers do.
There have already been discussion about this specific issue: #93, #594, #791. Does this pull request add anything new or address #791?
There have already been discussion about this specific issue: #93, #594, #791. Does this pull request add anything new or address #791?
I haven't checked issues. But it looks like it addresses most from #791 ;) I just didn't implement privilege deescalation.
Why not use systemd instead?
Why not use systemd instead?
Because our system is pure embedded one without systemd and with read-only fs ;)
See https://bitbucket.org/pedro311/freshtomato-arm/commits/
Hello @mobrembski, why not writing a small wrapper on your system, to daemonize openfortivpn?
nohup openfortivpn 0<&- &>/dev/null &
Almost all systems have their services/daemons manager (systemd is an example), so a deamon mode in openfortivpn wouldn't be used much, and would probably too basic for most uses (auto-restart on crash, etc.)
Well, maybe it's a good idea :) i will have a look :) thanks!
@mobrembski Indeed we'd rather not add functionality in openfortivpn if the same can be achieved by a small script. That said, if you feel changes in openfortivpn are required to obtain extra functionality, we're happy to hear about it.
This is a feature that I would find very useful and it is included in other command line VPN tools we use. That said, we would be open to using a "small script" if that was straightforward. However, across all the tickets mentioned, I have struggled to understand and get any working as expected.
@adrienverge are you able to expand on the nohup openfortivpn 0<&- &>/dev/null &
command you have posted? For example, where do I reference my .conf file?
Other implementations I have seen have for example a -b
command to send to background. It is simple to use and works as we expect.
@charlietomo The conf file question seems orthogonal to sending openfortivn to the background. You need to read about the command line options.
@charlietomo The conf file question seems orthogonal to sending openfortivn to the background. You need to read about the command line options.
I have read the documentation and prefer to use a .conf
file as, in my setup, it is more secure than having all the credentials in the command. I am aware I may be missing something, but have not found that missing information from my searching and reading so far. For example, in the nohup openfortivpn 0<&- &>/dev/null &
command I am not aware of what the 0
does.
It seems I am not the only one expecting this feature and struggling to make it work through other means, although I understand it is not a feature that wants to be included. If you have any time to write a brief explanation of your command that would be very much appreciated.
You still need to read the command line options to learn how to reference your conf file.
As for what 0
means, this is specific to the shell, not to openfortivpn. If it works, you don't need to be fully aware of what it does. If you do want to be aware of what it does, you need to read about the shell. Yet I agree it would be great to document how to run openfortivpn in the background in more detail, for example in the wiki or even as an example in the man page. Speaking of wiki, you will find a starting openfortivpn as a system service paragraph there.
@charlietomo I'm not sure what the 0
does in nohup openfortivpn 0<&- &>/dev/null &
. I found this command on a well-known search engine, while looking for a solution for you. Maybe you could look it out?
PS:
I have read the documentation
I doubt that. How to use a config file is at the very top of the man page: -c <file>, --config=<file> Specify a custom config file (default: /etc/openfortivpn/config).
Apologies I think I may not have worded my question well and misunderstood @DimitriPapadopoulos reply re "The conf file question seems orthogonal to sending openfortivn to the background."
I have read the documentation and have multiple successfully working config files. What I do not have is a successful "send to background" mode, which is what this thread was started about (not by me).
@DimitriPapadopoulos thank you for the link to the wiki. That may be worth linking to from the README.md
file. It may also be worth noting in the README.md to check the man page for additional options. I was unaware of the two additional (wiki and man) pages - despite reading the README.md
@adrienverge I'm not the original poster and only commented after you detailed the command, which I assumed you may have used or had knowledge of, which you might have been able to share. I have searched and used the various comments in other threads, but to date have not been successful. I will go back to searching and experimenting.
nohup openfortivpn 0<&- &>/dev/null &
the 0<&-
closes the input file descriptor (see man bash
for instance).
to supply a config file just put the usual -c configfile
between openfortivpn
and these redirects (see man openfortivpn
)
For completeness: &>/dev/null
redirects both stdout and stderr to /dev/null, but if you omit that, the nohup
command will redirect them to a nohup.out file in the current directory ;)
nohup openfortivpn 0<&- &>/dev/null &
the
0<&-
closes the input file descriptor (seeman bash
for instance).to supply a config file just put the usual
-c configfile
betweenopenfortivpn
and these redirects (seeman openfortivpn
)For completeness:
&>/dev/null
redirects both stdout and stderr to /dev/null, but if you omit that, thenohup
command will redirect them to a nohup.out file in the current directory ;)
Many thanks. I will experiment with this whilst reading further, but your explanation was very useful.
nohup and systemd are not a replacement for background mode in some cases. As soon as 2FA is enabled it needs to stay in foreground until the user has entered the token and then it can daemonize.
This is also how --daemon in openvpn works.
True, see also https://github.com/adrienverge/openfortivpn/issues/791. Meanwhile 2FA is not implemented.
I have a connection where I either get the token via EMail or SMS so 2FA is definitely working - I use it all the time.
Yes, SAML is not working, sorry. Still it's best implemented together with a patch for #791.
Any update on this PR?