-
Notifications
You must be signed in to change notification settings - Fork 101
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
Feature Request - IP caching option to save my self-hosting behind #71
Comments
Ok, so just that I understand the problem correctly, you messed up your DNS and want to use IPs instead of host names for your ssh connections? But you don't want change manually between IPs and host names in the configuration window and instead want to be able to provide fallback IPs/host names that will be tried when the previous ones don't work? I.e. instead of having a single text field for the host entry, have one that allows to provide multiple entries? |
Furthermore, now that the XPipe 1.5 staging version supports importing hosts from ssh configs, would such a solution work for you: https://unix.stackexchange.com/a/454743 |
You understood my request correctly. That's intersting, I can play with it - this does make configuration more cumbersome. Compared to my idea where XPipe keeps track of the latest IP address, and auto-updates it. Thanks for the quick response, and for the tip. |
The technical implementation for such a thing would be quite difficult:
Now I haven't tested this, but due to XPipe just straight a passing your configured command to your shell, you can in theory embed shell expressions into your hostname. If you are using a posix shell and pass |
That's a problematic idea - sanitation of values is an important security topic, and allowing that should be diswaded. I get your point, about the comlpexity, and I thank you for entertaining the notion. How about just fetching an IP address if the 'additional addresses' is empty. This should remove the complexity of detection later on. |
I understand your concern about the sanitation of inputs. The reason this is currently allowed is that the user should be in full control over what values are entered in there. If somehow an adversary is able to modify your own configuration and embed expressions in it, you might have bigger problems. All inputs are properly sanitized at other locations, e.g. the file browser, I just left that in to give users more flexibility. The problem with DNS resolution via a Java method is that it would always resolve that using your local configuration. If your SSH connections have set a proxy/gateway, that DNS resolution does not match the one on the proxy machine. It would be nice if SSH would be able to provide the IP it last resolved when connecting via a hostname, but I don't think it can tell you that. |
I see your point. So if you chose this, you'll need to implement at least 3 separate methods: figuring out what is avialable, parsing the output - and dealing with this as these systems evolve. Better drop the auto-detection part. |
So I will see what I can come up with in the future. Out of all the things that I currently have on my to do list, this isn't very high right now though. |
Really appreciate you entertaining my idea, even on a low priority. |
I was thinking about adding a system information button for connections to display basic information, including things like the IP address. That information would be kept from the last successful connection attempt, this would also make solving your problem easier as you then could just copy that IP and it temporarily use it as the host address for the connection. Would that work? |
yes, that's not bad at all. Although it would still mean editing or creating a separate connection, but at least the detail is preserved somewhere. Thanks for thinking about solving this. |
A couple of quality of life related features that came up to me while I was troubleshooting local DNS issues.
Feature 1a:
Add a field in SSH connection (as well as tunnels) to enter an optional IP Address for a connection.
Add a right-click option to connect using IP Address instead of hostname.
Feature 1b:
Add an auto-update/cache switch, which will be ON by default.
When the switch is on, it will update the field with the latest successful connected IP address
To auto-update the latest successfully connected IP address.
This will allow Feature 1a to be avialable in case of DNS failing to resolve an IP.
Feature 2:
Can be combined or as an alternative to both 1a/b - if DNS resolution of the connection's hostname fails, prompt for a temporary hostname/IP Address to retry the connection with.
Use case:
I've just messed up my local DNS, which is hosted on one of the machines I reach out to via XPipe,
This seems like a common enough issue for self-hosters tinkering with environments.
I've never seen this done before, but with XPipe it suddenly made sense to me.
If it's unreasnoble, feel free to close this FR.
The text was updated successfully, but these errors were encountered: