Linux.com

Feature

Using screen for remote interaction

By Philip J. Hollenback on August 22, 2006 (8:00:00 AM)

Share    Print    Comments   

Recently I needed to do some distance education; one of my coworkers wanted me to show him how to do software builds on Linux. The only problem was that I'm on the East Coast and he is on the West. How could I show him the build and install process? After considering some alternatives, we found our solution in GNU Screen.

I considered using the standard Unix utility script to save a log of my typing. script has several problems, not the least of which is the horrible resulting output (script saves everything, including carriage returns and corrections). In addition, this would be completely non-interactive. If my coworker had a question or needed a clarification, we would have to correspond via email afterward. That would be a frustrating experience for both of us.

Another possible solution would be to use VNC. My coworker could connect to my display, and we could alternate control of the mouse and keyboard. That approach seemed like overkill, since what I wanted to demonstrate was purely command-line work. It would also be difficult to generate a log of a VNC session. Finally, technical limitations dictated that the only way he could connect to my machine for the demonstration was over a simple SSH connection, so this dictated a purely command-line solution.

Screen is one of those tools that is hard to explain but pure genius once you see it in operation. The description from its official Web site doesn't help much:

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

Basically, screen allows you to create virtual terminals which are not connected to your actual xterms or console screens. You can then disconnect from a screen session and reconnect from somewhere else while preserving your shell or other running processes. For an introduction to screen, check out this Linux.com article.

This is just the beginning of screen's power and flexibility. You can connect to a session more than once using the -x argument to screen. That means you can for example leave your mail program running in a terminal (under screen) at work and then connect from home to read your mail in the same process. There's no need to disconnect at work, and when you come back in the next morning your mailer will be exactly as you left it, with all your state perfectly preserved.

Screen takes this feature, which is called multi-display mode, to the next level with multi-user mode. In multi-user mode more than one user can access and control a screen session. The problem with this mode is that it's not obvious how to set it up. Here's what I ultimately figured out with the help of some Google searching:

  1. Set the screen binary (/usr/bin/screen) setuid root. By default, screen is installed with the setuid bit turned off, as this is a potential security hole.

  2. The teacher starts screen in a local xterm, for example via screen -S SessionName. The -S switch gives the session a name, which makes multiple screen sessions easier to manage.

  3. The student uses SSH to connect to the teacher's computer.

  4. The teacher then has to allow multiuser access in the screen session via the command Ctrl-a :multiuser on (all screen commands start with the screen escape sequence, Ctrl-a).

  5. Next the teacher grants permission to the student user to access the screen session with Ctrl-a :acladd student where student is the student login ID.

  6. The student can now connect to the teacher's screen session. The syntax to connect to another user's screen session is screen -x username/session.

At this point the teacher and student both have control of the session. Note that there are security implications to this -- the student is operating the session as the teacher and could potentially do something to damage the system. If you don't trust your students then you should probably use a special teacher account and not your normal login account. The teacher can also make the student's session read-only. To do this, use the aclchg screen command to remove write access for the student: Ctrl-a :aclchg student -w "#". The student can then only observe the teacher's actions. Otherwise, the teacher will have to let the student work on the honor system.

While my example centers on one teacher and one student, many users could attach to one session. There could even be multiple teachers and students.

What about communication between teacher and student? Well, we used a telephone, but you could use instant messaging, IRC, or VoIP for asking questions. There is also an message feature in multiuser screen: Ctrl-a :wall message will write a message to all users connected to a screen session. One problem with this is that it uses the terminal status line. In an xterm this is the window titlebar area, which, depending on your window manager, may not be very obvious.

The final ingredient for using screen as a teaching tool is logging. With a log of all the terminal output, my coworker and I would have an exact transcript of what we did in case there were any questions later. As I mentioned earlier, the standard Unix tool script is the obvious answer, but it is a very limited tool and does not produce very readable output. You also can't turn it on and off inside a session if for example you want to run a full-screen tool such as a text editor.

Fortunately screen comes with a comprehensive logging facility that is much more sophisticated than what script can do. Screen's logging can be turned on or off at any time with Ctrl-a H, or you can use the -L switch when starting screen to enable it by default. The log file is written to the current directory under the name screenlog.n, where n is incremented by one for each new log.

The logfile will contain the output of your session with corrections and cursor movements already evaluated and applied. One caveat is that programs that send control sequences to the screen will still confuse the output. One example of this is GNU ls, which by default colorizes output. You should turn this off in your session by using something like the following bash alias:

 alias ls='ls --color=none'  

With that, all the pieces are in place: multiple users can share a screen session for any sort of command-line-based instruction. The teacher can at any time take control of the session by switching all other users to read-only access. Finally, you can turn on the logging facilities in screen to get an accurate and usable log of the entire session (or just portions of the session if you desire).

I found screen to work extremely well for this purpose, and my coworker was also pleased with the results. Some of the options and controls in screen can be hard to figure out because screen is so powerful and flexible. But I plan to use this tool in the future, and I encourage anyone in a similar situation to try it.

Share    Print    Comments   

Comments

on Using screen for remote interaction

Note: Comments are owned by the poster. We are not responsible for their content.

Have you tried kibitz?

Posted by: Anonymous Coward on August 23, 2006 10:43 PM
Hi,
You might want to look at kibitz from the tcl/expect package. Two or more people can share a single terminal. However, there is not the presistence that Screen offers you... it's just a shared terminal. At any rate, there you have it...
-Mike Schwager

#

Or my favorite, VNC

Posted by: Anonymous Coward on August 24, 2006 08:06 AM
Most distros nowadays have a version of VNC bundled in them. It gives a persistent X server and can hold graphical state between sessions as well as be shared among more than one user. It does run a bit slower than screen, but much faster than remotely exporting an X session and allows for the same lexibility, as well as multiple terminals in view at same time.

-Tim Renner

#

"Simple" SSH connection.

Posted by: Anonymous Coward on August 22, 2006 05:29 PM
Finally, technical limitations dictated that the only way he could connect to my machine for the demonstration was over a simple SSH connection, so this dictated a purely command-line solution.
<tt>man ssh
/-L</tt>
SSH tunnels. Use them, love them.

#

Re:"Simple" SSH connection.

Posted by: Anonymous Coward on August 23, 2006 01:49 AM
I prefer the screen based solution myself, but if you prefer to use VNC and share a full GUI, vncviewer has ssh forwarding support built in:


        vncviwer -via sshhost vnchost

#

Re:"Simple" SSH connection.

Posted by: Anonymous Coward on August 23, 2006 09:03 PM
One problem. The author did not specify the nature of the technical limitation. For example, what if the problem were bandwidth related? If the author was stuck on a dial-up connection or other slow connection (shared wifi at a coffee shop?), VNC (or anything else) tunnelled over SSH would be too slow to be useable. Even moreso given that the connection between the two computers probably has a fair amount of latency as well since they're on opposite coasts.

#

ytalk

Posted by: Anonymous Coward on August 23, 2006 02:31 AM
<a href="http://en.wikipedia.org/wiki/Talk_(Unix)" title="wikipedia.org">http://en.wikipedia.org/wiki/Talk_(Unix)</a wikipedia.org>

I used to use ytalk all the time, it allowed you to drop to a shell in your half of the screen, and the others connected could watch what you are doing in realtime.

#

expect and kibitz / xkibitz

Posted by: Anonymous Coward on August 23, 2006 02:50 AM
As a simple alternative, check out expect (<a href="http://expect.nist.gov/" title="nist.gov">http://expect.nist.gov/</a nist.gov>) scripts kibitz, or X11 capable xkibitz (included in examples directory of expect source tarball).

Its easy to use:

1) Start an xterm that you wish to share
2) start xkibitz "/path/to/xkibitz"
3) ^] escapes to a xkibitz> prompt where you can do "+ displayname:0" for any # of displays
4) typing "return" returns you to the shell which is now shared

of course you need permission to open remote displays, but in LAN or VPN environment - works great.

#

ls color

Posted by: Anonymous Coward on August 24, 2006 03:46 AM
Our author says, "One example of this is GNU ls, which by default colorizes output."

Our man page says, "By default, color is not used to distinguish types of files."

What we have here is a failure to distinguish between 'default' and 'usually preconfigured'.

#

Re:ls color

Posted by: Anonymous Coward on August 24, 2006 05:09 AM
Who are you? The technicality police? I mean really, is it that big of a deal whether they view the preconfiguration of their operating system as being the default or not? Your missing the point, it was just a useful tip, I don't think the author was trying to win any extra geek points.

#

Re:ls color

Posted by: Anonymous Coward on August 24, 2006 08:52 AM
The grandparent is a fair comment. The statement in the article is factually incorrect. Whether it is a big deal or not is not up to you. Some people will be mis-informed by the article, and others will appreciate the correction. I also think it is important to understand the difference between preconfigured and default. Especially if, like me, the first thing you want to do is turn off those crappy colours. How can you fix it if you have been ill-informed about where the problem is comming from?

#

Re:ls color

Posted by: Anonymous Coward on August 24, 2006 11:15 PM
> The statement in the article is factually incorrect.

Yes, and so are many statements in print, television, and the www. The author has been notified (assuming they even read the comment) and I agree, the information in the article should be corrected. However, I believe that for most it will be enough that they mentioned the possibility of a program's output as being problematic. It would be unrealistic to expect the article to know what everyone's scenario will be. The inaccuracy about controlling the output of "ls" is noteworthy, but benign in comparison to the article as a whole.

There are false statements made elsewhere that are far more arrogant and dangerous than the one made here and in every case it's up to the reader to find the truth. Comments can help, but they're are just as susceptible to their accuracy.

#

Multiple -x connections?

Posted by: Anonymous Coward on August 29, 2006 08:41 PM
Hi,
do you know if there's a way such as that the teacher could connect to several students' screens?
I mean, If I had several screen sessions on one machine (for the students), how can I make the teacher have a single screen session where it has one screen window for each of the student sessions?
In other words, passing multiple -x parameters doesn't seem to work.

The obvious solution is to do screen -x once, and then create other windows and run screen -x on each of them, but this create many screen processes. It would be nice if just one would be necessary.

BTW, I'm not using this for teaching, I just used your context of use to ease the question.

#

Use watch

Posted by: Anonymous Coward on August 29, 2006 11:59 PM
I ssh into the student's machine and use 'watch -iW tty#' to run commands as he watches what I type. We type short comments on the command line followed by ^C. For longer comments and questions we use amateur radio.

Steve

#

Re: Use watch

Posted by: Anonymous [ip: 66.92.218.124] on February 07, 2008 01:11 AM
Could also use `kibitz`.

#

Thank you!!

Posted by: Anonymous Coward on February 15, 2007 06:22 AM
I have needed to do this for years... and the handful of times I searched around for a solution I came away even more confused than before.<nobr> <wbr></nobr>:)

ssh tunnels is great and all, but vnc IS overkill and has problems.

This is the exact solution I was hoping to one day find. The funny thing is I use 'screen' all the time, but never figured out this trick. Thank you!

#

One small Correction

Posted by: Anonymous [ip: 87.74.4.205] on February 15, 2008 01:42 PM
The student can now connect to the teacher's screen session. The syntax to connect to another user's screen session is screen -x username/session.

The username should be the root ( or whoever who has setup the account) root/sessionid or sessionname

#

Using screen for remote interaction

Posted by: Anonymous [ip: 4.226.144.110] on March 07, 2008 01:27 AM
Cannot identify account 'S-root'.
What does that mean?

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya