-
Notifications
You must be signed in to change notification settings - Fork 215
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think instead of exposing the flag to the user, we should detect the remote environment from within sshcode
and if the remote environment is ChromeOS we modify the host value.
I am not entirely sure that there is a way to detect if the OS is ChromeOS. I have looked at |
If you had a malicious user on your local network then it could be dangerous, though I would agree in practice that's unlikely to happen. To reiterate I'd rather not expose that option to the user, the goal of |
I'll do some research to see if we can detect if an environment is ChromeOS |
what would you propose as the resolution? |
To update the |
@sreya92 It looks like |
- Added check for gentoo on remote instance.
Gentoo is an actual Linux distribution which I assume ChromeOS builds off of. This solution will also work on actual Gentoo distributions as well. |
How is it possible to differentiate the two? |
@roberthmiller I looked into this a good bit too and couldn't find a good indicator...after talking with @ammario I think the best solution is to go with a flag that we expose to the user like you originally proposed, I think we call it |
- Added check for gentoo on remote instance.
I did not remove localPort from the options struct because the test was using it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also need to update the test to reflect the updated changes to the options
I'm not sure the bind to localhost is the right option for ChromeOS. Running this on ChromeOS is likely to only be done through Crostini. Crostini is a Debian Stretch based container that sits inside the ChromeOS managed by a VM (Termina). It can be reached by the name "penguin.linux.test" in it's default state and anything listening in the container on 0.0.0.0 will generally be able to be hit. I don't really think there will be a huge need to ssh into the Crostini container as it's not exposed externally by default. You can use sshcode from inside that container to an external ssh host and it opens up in the ChromeOS browser just fine using The real I would simply add either a --chromeos flag, or a --local flag, or actually have it detect the crostini container by looking for /opt/google/cros-containers folder, or /ChromeOS/ folder or a few others. The /opt/google/cros-containers contains some binaries (such as garcon) with are only present in correctly setup and mounted penguin containers under ChromeOS (so far that I have seen). If you accurately work out its Crostini, or allow the users to specify via a flag, you basically just "skip" the shh part and pretend this is the server you ssh'd to and set everything up. Download the binary, setup the folders etc (no where really to sync the extensions etc from unless perhaps from a local vscode install). You then call the www-browser binary and pass it the http://penguin.linux.test:port url and it will pop up inside the regular ChromeOS environment and work as if it was remote. Why would someone want this? Well, the experience of running code inside a browser is actually smoother than running it natively in the crostini container in my testing. Plus having it just in a tab vs a stand alone window is simple and easy. I've got some code somewhere I could dig up that got this working on my pixelbook, plus some that started on porting sshcode to work under powershell/windows. (Kinda paused that to see how the new terminal on windows plays out). |
@Zate this is to fix using ChromeOS as a client not a server. Currently you cannot tunnel to localhost on a chromeOS client and access code-server from the browser |
sshcode.go
Outdated
o.localPort, err = randomPort() | ||
var bindHost string | ||
var bindPort string | ||
bindHost, bindPort, err = net.SplitHostPort(o.bindAddr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can short assign this :=
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't because of the reassignment of err
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try it :)
sshcode.go
Outdated
if err != nil { | ||
return xerrors.Errorf("failed to parse bind address: %w", err) | ||
} | ||
if bindPort == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would probably pull this out into a separate function func parseBindAddr(bindAddr string) (bindAddr string, err error)
that splits the address and ensures that neither host nor port is empty. If one is, it gets assigned a default value, 127.0.0.1
for host, and a random port for port and then join it back together with net.JoinHostPort
sshcode.go
Outdated
@@ -93,11 +101,12 @@ func sshCode(host, dir string, o options) error { | |||
return xerrors.Errorf("failed to find available remote port: %w", err) | |||
} | |||
|
|||
flog.Info("Tunneling local port %v to remote port %v", o.localPort, o.remotePort) | |||
flog.Info("Tunneling local host %v:%v to remote port %v", bindHost, bindPort, o.remotePort) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd probably reword to say Tunneling remote port %v to %v, o.remotePort, bindAddr
sshcode_test.go
Outdated
@@ -37,7 +37,7 @@ func TestSSHCode(t *testing.T) { | |||
defer wg.Done() | |||
err := sshCode("foo@127.0.0.1", "", options{ | |||
sshFlags: testSSHArgs(sshPort), | |||
localPort: localPort, | |||
bindAddr: fmt.Sprintf("127.0.0.1:%v", localPort), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
net.JoinHostPort("127.0.0.1", localPort)
main.go
Outdated
@@ -52,6 +54,8 @@ func (c *rootCmd) RegisterFlags(fl *flag.FlagSet) { | |||
fl.BoolVar(&c.skipSync, "skipsync", false, "skip syncing local settings and extensions to remote host") | |||
fl.BoolVar(&c.syncBack, "b", false, "sync extensions back on termination") | |||
fl.BoolVar(&c.printVersion, "version", false, "print version information and exit") | |||
fl.BoolVar(&c.noOpen, "no-open", false, "do not open web browser") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after speaking with a colleague let's handle the no-open
in a separate PR, sorry for indicating otherwise earlier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries. WIll change it
I assume by ChromeOS you mean the crostini container inside ChromeOS, or are you talking about a device in "dev mode" where you have shell access to ChromeOS itself, or even via crouton? Sorry I assumed this was related to something I posted a while ago #28 because I got a reference to this pull request. |
Yes, my bad. I thought that you meant via as a client, but did not fully understand your issue. Also, I believe that this fixes crostini, but am not completely sure as I do not have a chromebook. |
No worries apologies for any confusion, to clarify this fixes the specific
case of running sshcode to crostini.
…On Tue, May 7, 2019 at 8:13 PM Zate ***@***.***> wrote:
@Zate <https://github.com/Zate> this is to fix using ChromeOS as a client
not a server. Currently you cannot tunnel to localhost on a chromeOS client
and access code-server from the browser
I assume by ChromeOS you mean the crostini container inside ChromeOS, or
are you talking about a device in "dev mode" where you have shell access to
ChromeOS itself, or even via crouton? Sorry I assumed this was related to
something I posted a while ago #28
<#28> because I got a reference to
this pull request.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#82 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABFBTBDRHURWOH6S5FKRSZLPUISKTANCNFSM4HJQ7YAQ>
.
|
I'll do some testing with it but I don't think this is the right way to deal with crostini. Will let you know after I test it though. |
Resolves #78