Am running this on Laravel 5.8 on Ubuntu 18.04 (works fine on my dev environment on OSX)
Few things I noticed, this is true of both my prod and osx environments, when I run php artisan tunnel:activate it always returns $this->warn('I have no idea how this happened. Let me know if you figure it out.');
If you change dispatch to dispatch_now ($result = dispatch_now(new CreateTunnel());) in TunnelerCommand.php then it works as intended and returns an integer if the tunnel is detected
Furthermore, on Ubuntu 18.04, every time I try either tunnel:activate or dispatch(new \STS\Tunneler\Jobs\CreateTunnel()); or dispatch_now(new \STS\Tunneler\Jobs\CreateTunnel());
I always get an error
Could Not Create SSH Tunnel with command:
/usr/bin/ssh -o StrictHostKeyChecking=no -N -i /home/web/.ssh/id_rsa -L 13306:127.0.0.1:3306 -p 22 forge@188.166.81.133
Check your configuration.
This is a false-positive however, because the tunnel IS created, the failure is due to the NC command not being able to properly verify that the tunnel is already created
The command /bin/nc -z 127.0.0.1 13306 (/bin/nc is my nc path on Ubuntu 18.04) simply returns nothing. On OSX /usr/bin/nc -z 127.0.0.1 13306 does correctly detect the tunnel
On Ubuntu, this command does show that the tunnel is active and listening lsof -i -n | egrep '\<ssh\>'
But the NC command does not.. so it throws the error every time because it can't verify that it's active. That means that having dispatch_now(new \STS\Tunneler\Jobs\CreateTunnel()); in your script prior to an occasional use of the tunnel will always fail because the error is thrown and uncaught in this scenario. But scheduling the 'tunnel:activate' command will work out, although it will pollute your log files with false errors
After a little digging around, I found this thread that describes what seems to be a bug with the newer version of netcat.. where using -z alone does not return any output, but using it with -v does.. but then it also provides output in case of a failure
So I've adjusted the script so that it works with old and new netcat like this:
/usr/bin/nc -vz 127.0.0.1 13306 2>&1 | grep succeeded -> ok
/usr/bin/nc -vz 127.0.0.1 10000 2>&1 | grep succeeded -> not ok
I'm going to make these changes in a fork, and if things seem to work ok I will submit a PR, unless you want to beat me to it :)
Am running this on Laravel 5.8 on Ubuntu 18.04 (works fine on my dev environment on OSX)
Few things I noticed, this is true of both my prod and osx environments, when I run
php artisan tunnel:activate
it always returns$this->warn('I have no idea how this happened. Let me know if you figure it out.');
If I dd the content of $result it prints:
If you change
dispatch
todispatch_now
($result = dispatch_now(new CreateTunnel());
) inTunnelerCommand.php
then it works as intended and returns an integer if the tunnel is detectedThis resolution is also mentioned in https://github.com/stechstudio/laravel-ssh-tunnel/issues/16#issuecomment-365669198
Furthermore, on Ubuntu 18.04, every time I try either
tunnel:activate
ordispatch(new \STS\Tunneler\Jobs\CreateTunnel());
ordispatch_now(new \STS\Tunneler\Jobs\CreateTunnel());
I always get an error
This is a false-positive however, because the tunnel IS created, the failure is due to the NC command not being able to properly verify that the tunnel is already created
The command
/bin/nc -z 127.0.0.1 13306
(/bin/nc
is my nc path on Ubuntu 18.04) simply returns nothing. On OSX/usr/bin/nc -z 127.0.0.1 13306
does correctly detect the tunnelOn Ubuntu, this command does show that the tunnel is active and listening
lsof -i -n | egrep '\<ssh\>'
But the NC command does not.. so it throws the error every time because it can't verify that it's active. That means that having
dispatch_now(new \STS\Tunneler\Jobs\CreateTunnel());
in your script prior to an occasional use of the tunnel will always fail because the error is thrown and uncaught in this scenario. But scheduling the 'tunnel:activate' command will work out, although it will pollute your log files with false errorsAfter a little digging around, I found this thread that describes what seems to be a bug with the newer version of netcat.. where using -z alone does not return any output, but using it with -v does.. but then it also provides output in case of a failure
So I've adjusted the script so that it works with old and new netcat like this:
/usr/bin/nc -vz 127.0.0.1 13306 2>&1 | grep succeeded
-> ok/usr/bin/nc -vz 127.0.0.1 10000 2>&1 | grep succeeded
-> not okI'm going to make these changes in a fork, and if things seem to work ok I will submit a PR, unless you want to beat me to it :)
Thanks!