Disclosed Information

Spent the better part of the weekend working with Beej on redoing his server. It was a pretty heavy undertaking for an unprepared afternoon. Turned into an entire day’s work. It was good fun. We made such extensive use of a shared screen session that I feel the need to document and explain the process.

For the uninitiated, GNU Screen is

… a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. Each virtual terminal provides the functions of the DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g., insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows the user to move text regions between windows. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the users terminal.

.. Or more simply, you can have multiple usable terminals inside one terminal, almost like the way you have multiple webpages open in one firefox program. The NEAT part that I use more often is that last sentence: You can “detach” the session, and then reconnect to that server later and “reattach” to it as if you were connected the whole time. The sharing feature allows more than one person to be part of a session at once. We would both see what’s on the screen, and we could both type. We could change screens independently and work and such. Great troubleshooting tool. We’d be trying to figure out how to configure some program, and instead of both of us staring over the same computer monitor, saying “No, less that. grep for uh.. erg, just let me type.”, we could.. just work. (note: at one point there were four of us sitting on a couch and nearby chairs, all with laptops, view/configuring the server in the basement through the same shared screen session.)

The initial caveat of a shared screen session is that you have to run screen setuid root.
chmod u+s /usr/bin/screen
This is generally a Bad Idea. An executable being setuid causes it to run with the privileges of the owner, no matter who executes it. (as long as they have permission to execute it.) That means that screen will be running with the permissions of root. For more info, seek Wikipedia: Setuid. I’m perfectly comfortable with doing this on my machines, but I don’t have nuclear weapons attached to my serial ports or anything, so….

Next, start a screen session with a descriptive name.
screen -S serverhelp
To see a list of running screens and what their names are:
screen -list
And to connect to an exsting screen:
screen -x serverhelp

If you are not both using the same user, you’ll have to enable some multuser options that may not be on by default. Both can be enabled dynamically while screen is already running:
Ctrl-A :multiuser on
Ctrl-A :acladd username

There’s a nice little howto that included this and some other tips (like, starting programs automatically and setting a status bar) at Redhat Magazine.

Postscript: Leave A Comment // Subscribe (RSS Feed)

The Next Post: WIRES and bits
The Previous Post: Good Evening, Mr. FinePix.