Jump to content




nsh - Now With Previous Session Resume!


71 replies to this topic

#1 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 26 November 2012 - 11:05 AM

nsh, or Net Shell, is an advanced remote shell program that you can use to control any computer remotely! Simply install nsh on both computers and run it in hosting mode on the machine you'd like to connect to.

nsh features:
  • Connect any combination of advanced computer, regular computer and turtle.
  • See the remote shell as if you were at that computer.
  • Use the hosting computer's local shell like nothing is different.
  • Run specific programs for incoming sessions and the local session (authentication!).
  • Transfer files between client and server (requires get and put programs).
  • Client file protection prevents server from overwriting local files.
  • Forward connections seamlessly (connect to another computer from a remote session).
  • Resume a previous remote session you had forcefully disconnected from.
Screenshot of an advanced computer connected to a turtle:
Spoiler

To specify a program to run for each client that connects (like an authentication program), as well as a program to run locally, use the following command. Both of these options default to /rom/programs/shell.

nsh host [outbound] [local]

The best way to get nsh is via packman, with the command packman install nsh, as this will fetch nsh and its dependencies automatically. You could also grab it from pastebin:

nsh: X5Fysdi4, or simply: pastebin get X5Fysdi4 nsh
framebuffer (suggested)I: Aaza6h5v, or simply: pastebin get Aaza6h5v framebuffer

You can start nsh with nsh host on the server computer and nsh <serverID> on the client.

nsh comes with the ability to send and receive files! You can add the get (KJ9Tu2Y9) and put (zeS6uFY7) programs (also available via packman as nsh-get and nsh-put, respectively) to the nsh host and connected clients can use these to send and receive files. The syntax is from the client's perspective, so running get file1 file2 while connected will get file1 from the server and save it as file2 on the client. When saving files to the client, you cannot overwrite existing files. This is to prevent the possibility of a rogue nsh server luring clients into connecting, then overwriting their startup with something nasty without asking the client. Binary files are also now somewhat supported. There are binary versions of the get and put programs available on the github repository. The put program works quite well, but the get program needs to be given a moment or two to save the file to prevent some odd behavior or disconnections due to the nature of the binary file writing procedure.

With the addition of the framebuffer API (you do not need to separately install it if you have LyqydOS installed, it will find that copy), nsh can now handle session resuming. When connecting to a server, simply type nsh <server> resume to resume a previous session. If no previous session is available, you will simply start a new session. This is the only way to prevent killing a process started in a previous session when reconnecting. The framebuffer API being present also provides a significant reduction in rednet usage, so you should notice better responsiveness on slower connections. Of course, the framebuffer API is not required, but you will notice significant benefits to having it present.

Also available is a small nsh API that programs on the server can use. It exposes the following functions while nsh is running:

nsh.getRemoteID() --returns the computer ID of the client who is connected to the session the function is called from, or nil if called from local session.
nsh.send(<message>) --sends a rednet message to the connected client.
nsh.receive([timeout]) --returns any messages received from the connected client that are not intercepted by nsh itself.  For instance, you cannot receive the event packets with this method.
nsh.getClientCapabilities() --requests the capabilities string from the connected client. Returns nil if a response is not received within one second.
nsh.getRemoteConnections() --fetches a list of all directly connected computers.

A sample authentication program, available via packman as nsh-auth or fetchable from pastebin: ySEWczEr or simply: pastebin get ySEWczEr auth
Spoiler

I will be further extending nsh in the (hopefully near) future to be able to run programs on the client to handle responses from programs running on the server, to further extend the capabilities beyond what can reasonably be built into nsh itself.

#2 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 26 November 2012 - 02:55 PM

If you had previously downloaded nsh, please re-download, as I've fixed an unpleasant bug causing the client to hang when exiting from the shell, requiring manual termination. The correct, updated version is at the same pastebin ID.

#3 BigSHinyToys

  • Members
  • 1,001 posts

Posted 26 November 2012 - 04:50 PM

while I wouldn't call this the first http://www.computerc...ontroll-system/ I would call it the best.

One small problem if you run a program the redirects terminal then it causes issues.

#4 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 26 November 2012 - 05:11 PM

Ah! Interesting that I missed that, then. Though, yours seems to hook os.pullEventRaw() to use the existing shell session to send events to, while mine spawns a new shell session per connection and manages these coroutines.

#5 BigSHinyToys

  • Members
  • 1,001 posts

Posted 26 November 2012 - 05:21 PM

View PostLyqyd, on 26 November 2012 - 05:11 PM, said:

Ah! Interesting that I missed that, then. Though, yours seems to hook os.pullEventRaw() to use the existing shell session to send events to, while mine spawns a new shell session per connection and manages these coroutines.
It was kind of a proof of concept and not a full functional program. It did as you say in hocking the existing shell and not starting a new shell instance.
It was terribly unstable and couldn't work even through the most basic of network routing systems.

#6 dissy

  • Members
  • 181 posts

Posted 26 November 2012 - 05:36 PM

View PostMechaTallon, on 26 November 2012 - 01:41 PM, said:

The names of these programs keep getting more random the more I look at them .-.

This is offtopic I know, but there is a long tradition of shell naming such as this one that goes back decades in the Unix world.
'sh' is short for shell, and was the name of the first shell in Unix.
Later came csh, for the C Shell (Named after the programming language, heavily tied in with Unix)
Then 'bash', the Borne Again shell, also the standard shell on most Linux systems out there today.
There is 'rsh' for the remote shell, one of the first networkable control systems made.
Today it's replacement is 'ssh', the secure shell, used to remotely manage Unix servers and other systems all over the world using public key encryption.

'nsh' for the network shell is a quite apt name, following this long tradition :}

One which I can't wait to try out. Thank you Lyqyd!

#7 Dlcruz129

    What's a Lua?

  • Members
  • 1,423 posts

Posted 26 November 2012 - 07:00 PM

Would that be pronounced "oonsh"? :P

#8 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 26 November 2012 - 07:14 PM

View Postdlcruz129, on 26 November 2012 - 07:00 PM, said:

Would that be pronounced "oonsh"? :P

I'd say that using it as a word, it'd be "nish" or "nesh" most likely. You could also go with the "en-ess-aych" or "net shell" pronunciations.

Thanks, dissy! Hope it proves useful.

#9 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 27 November 2012 - 03:30 PM

Updated to use the EV packet type and structure instead of custom-packing the event. See the TRoR RFC for discussion.

#10 Bubba

    Use Code Tags!

  • Moderators
  • 1,142 posts
  • LocationRHIT

Posted 27 November 2012 - 06:16 PM

Pretty interesting code - I like your execution of this. I started writing a remote VNC program this past week but it looks like this basically does all of that and more. Keep up the nice work :)

#11 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 28 November 2012 - 03:01 PM

New update today adds a handy feature: custom paths upon connection, and for the local shell. This enables things like authentication, by means of running a program beforehand to ask the connected user for a password, before running the shell. New usage is:

nsh host [program to run upon connection] [program to run locally]

Both options default to /rom/programs/shell, so no need to set any options if you just want a simple nsh session.

#12 rhyleymaster

  • Members
  • 186 posts
  • LocationCanada

Posted 28 November 2012 - 08:41 PM

off topic: Is he tittle the result of you smashing your face on the keyboard once???
On topic: Nice program.

#13 GopherAtl

  • Members
  • 888 posts

Posted 04 December 2012 - 07:19 PM

why all the name-bashing? it's a damned handy little utility. Ever needed to change the software in a gps sattelite placed by a turtle at y=255 in survival mode? nsh beats the hell out of programming a turtle to go update it for you.

#14 Dlcruz129

    What's a Lua?

  • Members
  • 1,423 posts

Posted 05 December 2012 - 05:17 PM

We're not name-bashing, it's just funny.

#15 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 23 December 2012 - 10:38 AM

New update today fixes a bug wherein two computers hosting nsh couldn't connect to each other. Download is at the same pastebin code from the original post.

Please note that attempting to connect two computers to each other at the same time through nsh (client sessions in both directions) does not work.

#16 ObtusePenguin

  • New Members
  • 7 posts

Posted 27 December 2012 - 10:01 PM

I know you guys may not want to hear this, but could you give a more detailed description of how to install/operate this shell if you have time?

Reason I ask is that I'm new to ComputerCraft and am trying to learn for the sake of having a server and client setup, where servers send messages to clients (either other computers, or turtles), and from what i understand, something like this can help me. I know VERY basic Lua but judging from the above comments this can be used to do something along the lines of what I require...

Thank you so much.

#17 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 28 December 2012 - 04:50 AM

Basically, you put the nsh program (available from the pastebin link in the first post) on each computer you want to connect to or from with it. Then, on the computer(s) you wish to connect to, simply type: nsh host. The screen will clear and a fresh shell will appear if it starts correctly. You'll need the ID of this computer, so type: id. Remember that number. Now, go to any other computer that has nsh installed and type nsh and the ID of the first computer. For instance, to connect to computer 12, type: nsh 12. Type exit when finished to disconnect, or use ctrl-T to disconnect without ending the session (reconnecting will end the previous session and start a new one).

You can also specify programs to run, both for new connections, and for the local computer. You might write an authentication program that requires a password before starting the shell and use it for incoming connections. You can specify these:

nsh host [remote [local]]

Both options default to /rom/programs/shell. For example, if your authorization program was named auth, you might run:

nsh host auth rom/programs/shell

Or just:

nsh host auth

Hope that helped! Feel free to post any more questions you might have.

#18 ObtusePenguin

  • New Members
  • 7 posts

Posted 28 December 2012 - 06:35 AM

View PostLyqyd, on 28 December 2012 - 04:50 AM, said:

Basically, you put the nsh program (available from the pastebin link in the first post) on each computer you want to connect to or from with it. Then, on the computer(s) you wish to connect to, simply type: nsh host. The screen will clear and a fresh shell will appear if it starts correctly. You'll need the ID of this computer, so type: id. Remember that number. Now, go to any other computer that has nsh installed and type nsh and the ID of the first computer. For instance, to connect to computer 12, type: nsh 12. Type exit when finished to disconnect, or use ctrl-T to disconnect without ending the session (reconnecting will end the previous session and start a new one).

You can also specify programs to run, both for new connections, and for the local computer. You might write an authentication program that requires a password before starting the shell and use it for incoming connections. You can specify these:

nsh host [remote [local]]

Both options default to /rom/programs/shell. For example, if your authorization program was named auth, you might run:

nsh host auth rom/programs/shell

Or just:

nsh host auth

Hope that helped! Feel free to post any more questions you might have.

Thank you tons for this detailed explanation. I'm going to give it a shot and I'll report my feedback :)

#19 ObtusePenguin

  • New Members
  • 7 posts

Posted 28 December 2012 - 10:17 PM

Okay, so i've tried this, but any time I run "nsh <ID>" it returns 'Connection failed'. I have rednet modems on the wireless turtles, as well as the computer itself. Or does this not work with turtles?

To clarify:

I first install nsh on a turtle, then run 'nsh host'

Then I move to the server computer, and type 'nsh <id of turtle>'

The above procedure returns 'Connection failed'

#20 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 29 December 2012 - 06:18 AM

View PostObtusePenguin, on 28 December 2012 - 10:17 PM, said:

Okay, so i've tried this, but any time I run "nsh <ID>" it returns 'Connection failed'. I have rednet modems on the wireless turtles, as well as the computer itself. Or does this not work with turtles?

To clarify:

I first install nsh on a turtle, then run 'nsh host'

Then I move to the server computer, and type 'nsh <id of turtle>'

The above procedure returns 'Connection failed'

Well, that is strange indeed. Are your turtle and computer within rednet range of each other? Default range at sea level is 64 blocks; 16 during a storm. I have successfully connected to a wireless turtle before, so I know that that is not an issue. If it's not a range issue, I've got a little utility I can put up on pastebin tonight that can log the connection attempt, which will make it easier to analyze the fault.

Also, do you have any kind of rednet API or OS or some such installed that might be interfering with or intercepting rednet traffic?





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users