sshcode
sshcode copied to clipboard
coder
Hold on any future development
I've written a shell script in /bin/sh to automatically and correctly install code-server on any MacOS and Linux system.
It'll be in the main code-server repo.
See https://github.com/cdr/code-server/pull/1701
At the moment it does not support installing over ssh but it will soon and the plan is for it to replace and deprecate sshcode as something we'll maintain alongside code-server.
Please let me know your thoughts in this issue.
I dont see the point for this as it will require the user to install code-server or download code-server onto the client machine, while sshcode works as a functional and prooven tool to achieve this. The only problem with sshcode and code-server is that the way in which code-server is packaged keeps changing, requiring sshcode to be updated to support the new packaging
i see no reason to depreciate sshcode at all,
I dont see the point for this as it will require the user to install code-server or download code-server onto the client machine,
It won't require anyone to install code-server locally.
They'd just run the script like so:
# This would install code-server on user@host, forward the port and open it for you.
curl -fL https://get.code-server.sh | sh -s -- user@host
Or if they already had it downloaded somewhere they could just use it and get rid of the curl.
that is more work for a user, who may, depending on local restrictions, not be able to access specific resources. also with the command being longer than needed.
This method would have them be required to contact a remote server every single time to get a script that may be vulnerable to a mitm attack.
and how would configuring code-server via this new shell script even work? sshcode has flags and allow the user to upload their own binary. How would this script implement that?
In the long run, you are making a tool to replace the original, when the original isnt broken nor needs to be replaced. The only thing that needs to be fixed with the original is one component not following a consistent packaging method. which iirc, can be fixed easily by keeping the binary in one spot relative to the extraction point. (see #182 )
Edit:
And you have users who are actively contributing code to the original with the intent of making the tool even better.
Edit2: and there are libraries and add-ons that allow a go binary to auto update itself so ease of updates isn't an actual issue here, just add a check when the program is ran if there if there is an update, and then the user can use a --update flag to update sshcode on the client
i am willing to put work in to make the update flag work in the first place
that is more work for a user, who may, depending on local restrictions, not be able to access specific resources. also with the command being longer than needed.
Well you can curl it into a file and then run it wherever if you don't expect to have internet access all the time. Though you need internet access to fetch code-server anyway.
This method would have them be required to contact a remote server every single time to get a script that may be vulnerable to a mitm attack.
You have to fetch code-server every time too. I think the risk of a mitm is blown out of proportion when referring to a install script.
and how would configuring code-server via this new shell script even work? sshcode has flags and allow the user to upload their own binary. How would this script implement that?
We'd have an option that lets you pass in any flags for code-server. or an environment variable. Haven't decided.
Same with uploading your own code-server release.
In the long run, you are making a tool to replace the original, when the original isnt broken nor needs to be replaced. The only thing that needs to be fixed with the original is one component not following a consistent packaging method. which iirc, can be fixed easily by keeping the binary in one spot relative to the extraction point. (see #182 )
Yea sorry about that, I added a symlink in the latest release and replaced the binaries so you can still use code-server at the root of the release.
sshcode isn't broken but it can be significantly improved. I think the script would be a much better UX, easier to maintain and already works across a very wide variety of OSes as it installs packages with the system package manager instead of what sshcode does.
/bin/sh is a much better tool for what we want to do than a Go binary.
Edit2: and there are libraries and add-ons that allow a go binary to auto update itself so ease of updates isn't an actual issue here, just add a check when the program is ran if there if there is an update, and then the user can use a --update flag to update sshcode on the client
To clarify I don't think updating sshcode is a big deal, I just feel no installation at all like you can with a shell script is much nicer.
Well you can curl it into a file and then run it wherever if you don't expect to have internet access all the time. Though you need internet access to fetch code-server anyway.
True on this part, i was a bit heated and didnt think things fully over, however sshcode allows you to upload your own binary. IE: You could have a specific version downloaded or a custom build. In that case you can use that build over the latest official release. meaning if some accident were to happen like the ISP buggering everything up, and you loose internet, you can still access servers locally This can happen and companies and normal users would have to use local networking over remote resources
Yea sorry about that, I added a symlink in the latest release and replaced the binaries so you can still use code-server at the root of the release.
Very much thanks!
sshcode isn't broken but it can be significantly improved. I think the script would be a much better UX, easier to maintain and already works across a very wide variety of OSes as it installs packages with the system package manager instead of what sshcode does.
Alot of usecases where someone would use code-server that i can think of, they would not have admin access to the remote server, and therefore would be unable to install code-server via the OS package manager. sshcode gets around this by downloading code-server to the remote users home, the 3.X patch uses ~/.sshcode-server to mimic VSCode-Remote with .vscode-server,
/bin/shis a much better tool for what we want to do than a Go binary.
Really depends on what you are doing. For something like sshcode, i dont see how it could be a simple or a complex sh script as, as far as i know. it doesnt really have all the features one would need for it to work. (I may be wrong in that department, i dont do alot of shell scripting)
To clarify I don't think updating sshcode is a big deal, I just feel no installation at all like you can with a shell script is much nicer.
I would rather have a tool installed on my system, that can update with my package manager like sshcode, over a shell script i have to manually download every time it gets an update or i wish to use it. And sshcode could contain a v2 build or a v3 targz of code-server as bindata and simply extract and send to the remote if it is unable to acquire a release from the server
Alot of usecases where someone would use code-server that i can think of, they would not have admin access to the remote server, and therefore would be unable to install code-server via the OS package manager. sshcode gets around this by downloading code-server to the remote users home, the 3.X patch uses ~/.sshcode-server to mimic VSCode-Remote with .vscode-server,
The script allows you to do this as well with the -s option.
Really depends on what you are doing. For something like sshcode, i dont see how it could be a simple or a complex sh script as, as far as i know. it doesnt really have all the features one would need for it to work. (I may be wrong in that department, i dont do alot of shell scripting)
Shell scripting works really well for this. It's how a lot of people install docker. See
https://github.com/docker/docker-install/blob/master/install.sh
Another cool thing is the --dry-run option so you can see the commands that would be ran to install but not actually run them.
I would rather have a tool installed on my system, that can update with my package manager like sshcode, over a shell script i have to manually download every time it gets an update or i wish to use it. And sshcode could contain a v2 build or a v3 targz of code-server as bindata and simply extract and send to the remote if it is unable to acquire a release from the server
go get is definitely really nice but idk, curling isn't that bad and we can always add it to the code-server distribution so anywhere you install code-server, you'd have access to the install script via say code-server-install.sh.
It would be untenable to add a release into sshcode as it's nearly 100 MB for every OS/Arch.
True on this part, i was a bit heated and didnt think things fully over, however sshcode allows you to upload your own binary. IE: You could have a specific version downloaded or a custom build. In that case you can use that build over the latest official release. meaning if some accident were to happen like the ISP buggering everything up, and you loose internet, you can still access servers locally This can happen and companies and normal users would have to use local networking over remote resources
The script could totally have an option to use a local release archive, it wouldn't be very difficult.
Let's get more opinions in here.
@ammario @coadler @sreya92 @sreya92 @deansheather @kylecarbs
I don't have a super big opinion but the script makes a lot more sense to me considering there haven't been any commits to this in the past year, and we don't have anyone dedicated to maintaining this. The script would simplify things a lot.
+1 for script, it'll get updated/fixed more regularly if it's a script
@Merith-TK sshcode was created to provide an easy-to-use, secure way to install/access your code-server instance from a remote server. Though we picked Go to do this originally, it makes for a poor scripting language. Given the updates that @nhooyr has provided, could you elaborate on the objections you still have. I'm failing to understand how Go accomplishes the goal of sshcode better than a bash script.
... considering there haven't been any commits to this in the past year
See the open PR and the msys-support PR. it is being relatively maintained and is doing its job rather well.
+1 for script, it'll get updated/fixed more regularly if it's a script
What makes you say this? why would a script be regularly updated over a program that works just fine with minor tweaks?
Though we picked Go to do this originally, it makes for a poor scripting language. I'm failing to understand how Go accomplishes the goal of sshcode better than a bash script.
Can you explain why you say this? i havent had any issues with go at all in my time using it and im failing to see how bash can do what is already done, better.
What makes you say this? why would a script be regularly updated over a program that works just fine with minor tweaks?
More people are proficient in sh/bash than Go. Given that this is a script, it's generally less code to fix a bug in bash than in Go.
Can you explain why you say this? i havent had any issues with go at all in my time using it and im failing to see how bash can do what is already done, better.
If you look at the code you'll notice that any meaningful work that is being done is calling out to exec.Command. We even embed full bash scripts in our Go code. None of the strengths of Go are being utilized here. While it is not hard to write this in Go it's certainly easier and more appropriate to write this in a shell script.
Also it is hard to beat the workflow of curl https://get-code-server.sh | sh. You either remove the dependency on Go (if you are using go get to update your binary) or you are removing the manual step of downloading a new release to your path every time.
All sshcode does is run rsync, run ssh, then run rsync again. There's lots of boilerplate involved in executing programs in golang, whereas a shell script would be much smaller and easier to read
sshcode has much less visibility than code-server as well. With a script inside code-server we can get many more eyes on it and ensure it's always up to date.
- sshcode's lack of commits isn't necessarily bad. It's simple software with a simple scope.
- The script's UX seems dramatically different than what sshcode does? I don't personally care what language it's written in, but doing
sshcode user@serveris quite a nice workflow.
I think self-competition is the best way to resolve this problem. sshcode is clearly a succesful workflow, but it's hard to see if the new script will be. I think we should track and measure the usage of both and reconvene after a month of data.
@ammario From what I gather, you could do:
curl -fL https://get.code-server.sh > sshcode.sh
chmod +x sshcode.sh
./sshcode.sh user@host
Yes it'd be as simple as:
# This would install code-server on user@host, forward the port and open it for you.
curl -fsSL https://code-server.dev/install.sh | sh -s -- user@host
sshcode as it stands right now is just a glorified script written in golang, most of it's functionality is handled by calling out to rsync and ssh, most of the other code is just args handling. The shell version would just do the same steps as the go version but in a more cross-platform fashion.
Since sshcode isn't really maintained anymore anyways I think we should archive this repo when the shell script alternative lands in code-server. If people are still attached to sshcode they could still use it even if it's archived
@Merith-TK If you fork I'd be happy to add a link in the README.md to your fork so anyone who still prefers this over the install script can use it.
Alright, that would work, Would need to figure out how to do repo packaging and how to use the build tools you guys have, but i would be alright with that
if that outcome is the final outcome, I would be happy to have some of the team here occasionally reveiwing PRs on it when i cant
Maybe instead we could just not archive the repo and just keep committing fixes if it breaks. The maintenance work would be minimal, probably only when code-server version changes to update the args/download script.
It would still be deprecated in favor of the script though, and we wouldn't add any new features. It would only not be archived so we can make sure it still functions.
maybe in the readme have it state there are two methods, the recommended and the alternative?
like for example
### This Tool is no longer officially maintained
This tool is being replaced by a shell script that can use via `curl -fsSL https://code-server.dev/install.sh | sh -s -- user@host` or `curl https://code-server.dev/install.sh > sshcode.sh`
[sshcode](/cdr/sshcode) will still be open to RP's to fix bugs and add features the community wants. And will still be updated to support newer versions of code-server, however there will be no active [Coder](/cdr/] developers working on this project, PR's will still be reviewed and accepted.
This Tool is no longer officially maintained
This tool is being replaced by a shell script that can use via curl -fsSL https://code-server.dev/install.sh | sh -s -- user@host or curl https://code-server.dev/install.sh > sshcode.sh
sshcode will still be open to RP's to fix bugs and add features the community wants. And will still be updated to support newer versions of code-server, however there will be no active [Coder](/cdr/] developers working on this project, PR's will still be reviewed and accepted.
just an example of what could be put at the begining of the readme, obviously it would need to be better,
@nhooyr
If you fork I'd be happy to add a link in the README.md to your fork so anyone who still prefers this over the install script can use it.
I do have a fork, a bit out of date with other PR's iirc
I would love to read through the whole issue as well as check the shell script to see if it addresses my use-case. Unfortunately can do it during the weekend. So I would kindly ask you to hold on for couple of days if possible 😃
We're not deleting or archiving the repo at the moment, we're just expressing that this repo will most likely become deprecated soon. You're still free to use sshcode. The script version will accomplish mostly the same things as the go version