search

wavetermdev / waveterm

An open-source, cross-platform terminal for seamless workflows
https://www.waveterm.dev
Apache License 2.0
4.46k stars 118 forks source link

Error: cannot resolve remote host #289

Closed gonzolively closed 8 months ago

gonzolively commented 9 months ago

Describe the bug When creating a remote session (and selecting a remote host) the host does not change to the selected host. When I go back and try to edit the connection I get an error that reads:

`Error: cannot resolve remote 'ubuntu@127.0.0.1:22022': not found`

The only way I can successfully connect to the remote host is by issuing the cr command in the terminal: specifically cr vm as vm is my remote hostname.

To Reproduce Steps to reproduce the behavior:

  1. Click "+" to start a new tab
  2. Select remote host from the dropdown menu (in my case, ubuntu@127.0.0.1:22022)
  3. Discover/verify that you are NOT on the desired host. I confirmed by issuing echo $HOSTNAME and receiving the hostname of my local machine.
  4. Try editing the connection by clicking the elipses and once again selecting the remote host.
  5. DIscover the error , Error: cannot resolve remote 'ubuntu@127.0.0.1:22022': not found

To Resolve

  1. Issue cr <connection_alias> command

Expected behavior Upon starting a new tab and selecting the appropriate remote connection from the dropdown I expect to be connected to that host within a matter of seconds.

Screenshots

Desktop (please complete the following information):

Additional context The connection in the error exists in the connections tab and is a live and working connection. Not sure why it wouldn't find it.

sawka commented 9 months ago

I'm wondering if there is a problem resolving hosts with the port numbers (the ":"). We recently added the ability to have remotes with port numbers as part of their canonical name.

oneirocosm commented 9 months ago

I think you're right. A quick fix would be to strip the port number from the hostname before running the command. This isn't necessarily great, but it should make it usable while still allowing separate ports to be used. Longer term, I think we'll need more changes around this, but they are somewhat dependent on the other ssh work that's being done right now.

oneirocosm commented 9 months ago

I've looked into this more, and I think I was wrong with my initial assessment. Now that #300 has been created, I think this is more likely an issue with the way we resolve remotes. It's very possible that these functions did not expect a port number tacked onto the end of the canonical name. I'm going to investigate it more to see what a good fix would be.

oneirocosm commented 8 months ago

Fixed in v0.7.0