-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change default timeout #73
Comments
I'm having the same problem with connections closing after a couple of minutes. We're running the server using Docker with the images of version 0.0.12-beta and Cloudflare Thanks for a great product/project 🙏 Kind regards, |
Thanks
The auto-config file creation is only tested locally. I can add the check, but you can manually create the configuration file. Use this template server_url: example.org
ssh_url: example.org:2222
secret_key:
tunnels:
- name: portr
subdomain: portr
port: 4321
|
@jacobhallenborgprototyp Does the disconnect issue happen too frequently? I have faced the issue, but not frequently; upon re-connecting, it works fine. Nevertheless, it is something I will look into. |
@amalshaji Thanks for your reply :) We've upgraded to It's ofc easy to restart the tunnels, but we'd really like to have them running continuously, since we're using them to receive webhooks. Let us know if we can gather more info somehow, like in the logs? |
@molander GitHub auth is now optional https://github.com/amalshaji/portr/releases/tag/0.0.17-beta |
@jacobhallenborgprototyp Does it happen too frequently? Like you connect and after some time you see the |
The setup script should auto download the config file into your clients. |
I my opinion it happens too frequently. The manual reconnection works, but it would be smoother not having to worry at all about the tunnels once they are started. |
@jacobhallenborgprototyp This is most likely a connection drop; we will implement re-connections. |
That would be awesome :) |
+1 :D |
@jacobhallenborgprototyp @molander The latest release should auto reconnect on connection drop |
TL;DR DROPPING CONNECTION, GETTING 'Unregistered subdomain' CONSTANTLY on client. Have to restart client and comes back up.
The longer version:
First of all, thank you for your project! It is EXACTLY what I was had in mind. Yay!
I have used ngrok since before it was ngrok and ssh tunnels for Xen, bhyve, and other virt hosts before that.
And this is SO MUCH BETTER than the horrible script(s) I wrote in zsh that I used for a couple of years.
So, thanks for open sourcing your project, it is awesome and I really appreciate it! <3
FYI: I had some issues getting set up and I figured that if I am having issues, you can definitely assume others are or will be, too.
Least I can do is take some time to report in with my thoughts and nitpicks :P
Couple of things (both with the binary and building the project, didn't try on mac as I am assuming that's what you dev on and prob works solid I'm guessing):
Now, some 'get off my lawn' gripes:
Out of those 3, Github auteh dependency would be my REALLY want to have. Then Cloudflare, then docker.
++++++++++++++++++++++++++++++++
Alrighty then, now for my ACTUAL problem lol:
** Unregistered Subdomain =Timeout Too Soon? **
++++++++++++++++++++++++++++++++
So, I have a flaky service on a flaky box at a flaky location (only half-kidding!) and so I have Supervisor kicking the service constantly to keep it available. It seems like the portr server endpoint drops it in a hot microsecond.
Is that adjustable anywhere somewhere? Like, it's not a big deal for me if it doesn't check for a minute or 3, you know? It would be extra sweet if that was a knob that was tunnel adjustable! Like tunnel1 is high availability if it isn't there in 5s, it's already spinning up elsewhere and trying to connect but tunnel2 is my sad offsite server in the desert on a satlink. Shady. It can wait 5m.
Anyway, I am also most likely 'doing it wrong', so feel free to educate me :D
Along those lines, can I easily turn a knob to quiet the logging too?
Once again, thanks for open sourcing, it was the right choice.
Maybe you will be bigger ngrok one day.
ciao,
-matt
The text was updated successfully, but these errors were encountered: