Persistent Terminals For a Dedicated Computing Box?

Theovon writes "I just built a high-end quad-core Linux PC dedicated to number-crunching. Its job is to sit in the corner with no keyboard, mouse, or monitor and do nothing but compute (genetic algorithms, neural nets, and other research). My issue is that I would like to have something like persistent terminal sessions. I've considered using Xvnc in a completely headless configuration (some useful documentation here, here, here, and here). However, for most of my uses, this is overkill. Total waste of memory and compute time. However, if I decided to run FPGA synthesis software under WINE, this will become necessary. Unfortunately, I can't quite figure out how to get persistent X11 session where I'm automatically logged in (or can stay logged in), while maintaining enough security that I don't mind opening the VNC port on my firewall (with a changed port number, of course). I'm also going to check out Xpra, but I've only just heard about it and have no idea how to use it. For the short term, the main need is just terminals. I'd like to be able to connect and see how something is going. One option is to just run things with nohup and then login and 'tail -f' to watch the log file. I've also heard of screen, but I'm unfamiliar with it. Have other Slashdot users encountered this situation? What did you use? What's hard, what's easy, and what works well?"

Comments

Screen works welll

[Miros]

For your standard persistent terminals, SCREEN is really your best bet

Re:Screen works welll

[Anonymous Coward]

Screen is a most excellent utility for persistent terminals, but (as far as I know) it will not let you keep persistent X11 information.

Re:Screen works welll

[Lord Apathy]

Agreed. I built something like that a few years ago. It had a vt100 sitting on top of it and I used screen to keep up with the data. Screen is easy to use. The only real command that you will need is screen -R. The -R will tell it to resume the screen session in the background and if there isn't one to create it.

Re:Screen works welll

[alta]

The article seemed to mention 2 stages, first needing persistant terminals, which screen is PERFECT for... The second stage will require wine, which means X, which means VNC...

The guy has answered his own questions.

Re:Screen works welll

[Dr. Winston O'Boogie]

Nothing new to add, but did want to emphasize that if a text-only terminal is all you need, 'screen' is the way to go. It is one of the lesser known unix goodies, and a true "wonder tool": a tool you cannot live without once you use it.

The quick primer:

First time:
    ssh mymachine
    screen
    <do some work>
    CTRL-a-c <create another login session>
    <do some more work in diff dir>
    CTRL-a-1 <back to first login session>
    CRTL-a-d <disconnect>
    exit

Future times:

    ssh mymachine
    screen -r <resume screen>
    CTRL-a-2 <back to second login session>
    <do some work>
    CTRL-a-d <disconnect>
    exit

You can create many login sessions inside one screen instance or launch multiple instances of screen on the same box by giving them a name. See the man page for all the goodness.

Re:Screen works welll

[JamesTRexx]

I use screen in combination with X11vnc to keep a desktop open to the media server.
If for whatever reason I lose the connection, I can start ssvnc again and get the desktop back.

Re:Screen works welll

[ckthorp]

I prefer screen -R -D to detach any other screen connections which I might have forgotten about.

Re:Screen works welll

[FMZ]

Throw this in your .bashrc: alias s="screen -RAad" . This makes multiple screen session management really easy. When I want to IRC, I just type "s irc". When I'm checking out how my torrent is going, "s tor". The beauty is, you don't have to do anything different for a new session. If you forget which sessions you have going, just type "s" and you'll be provided with a list of existing screen sessions.

Re:Screen works welll

[Cillian]

I like screen -x, so I can access my stuff wherever I want it, with no hassle. It can get slightly funky with different terminal sizes, but screen handles that well.

Re:Screen works welll

[Anonymous Coward]

iirc, you can use x forwarding (ssh -X) with screen. ssh in, open up the screen and you've got secure persistant x.

Re:Screen works welll

[Al Dimond]

My understanding, which might be wrong, is that you can't do this with just screen and an ssh-forwarded X server.

In X, for those that don't know, applications are clients and the display is the server. So when you run apps from your server box and display them on your laptop, the app on the server box is the client and your laptop display is the server.

An X client needs to be connected to an X server. I think it would be possible to write ones that could handle dropping and resuming their server connections, but I don't think any programs actually act this way in practice. So to have clients running persistently while you're not connected you need a locally-running X server that those clients remain connected to. The traditional thing to do, then, is to use VNC to let other computers access that local X session. Compared to what you were doing, forwarding the actual X connection over SSH, this has the advantage that a smart VNC client/server can adjust for slow network connections by combining messages to be sent, remembering the display state on the client side so window redraws (as a result of overlapping windows) don't require any network activity, and image compression (for some kinds of windows sending an X11 command stream is more efficient than sending compressed image data, but for others it's the other way).

The VNC protocol, however, doesn't have many security features built in, and there are lots of different client-server combinations that use non-standard or semi-standard compression techniques. The standard answer to VNC's lack of built-in security features is to forward VNC connections through SSH. That, plus any modern VNC client-server combo, generally gets the job done. But there's a relatively new program that essentially is a better VNC. It's called NoMachine. Google it. For some uses it's free-as-in-beer, and I think they release some source code, but they are a for-profit company and generally use a proprietary model IIRC. If that doesn't bother you, their product is good as far as I've seen. If you want to stay with Free Software, you'll probably want VNC+SSH.

Re:Screen works welll

[Anonymous Coward]

No, X doesn't mean VNC, X means VNC or plain X11 or FreeNX. The latter of which is far faster than the previous two.

Re:Screen works welll

[sys_mast]

Have you ever used an IP KVM? My experince has been that the mouse sync is annoying to use for long periods, it gets the job done until you can connect with RDP/VNC/X11.

I'm not sure if a mouse is needed, Keyboard access is basically find via IP KVM. Also I'm not sure how long this access is needed on a number cruncher. For short periods they do work fine.

Thinking of that has anyone found an IP KVM that works really well for the mouse sync? To the point of being able to use it all the time?

Re:Screen works welll

[maverickbna]

Try NX. It's free edition will do what you need just fine, and provides persistent X11 connections. www.nomachine.com

How about NX/nomachine.com?

[vlad_petric]

Yeah, it's not free as in speech, but otherwise beats the crap out of vnc.

Captain Obviousman.

Re:How about NX/nomachine.com?

[agoliveira]

Yeah, it's not free as in speech, but otherwise beats the crap out of vnc.

Captain Obviousman.

FreeNX is free and works to what he wants as well.

Re:How about NX/nomachine.com?

[billcopc]

From my experience, everything keeps running. All the "suspend" does is leave your X-session open, so you can reconnect to it later.

"Terminate" kills any open apps and logs out of that X-session.

ssh + vnc

[Destrius]

You could use VNC, but set it up so the vnc server is only accessible via localhost, and then use ssh to create a secure tunnel back to your client. Alternatively I sometimes use vnc and ssh with X11 forwarding, i.e. the actual graphical data being sent over the network is over X11 as opposed to VNC's protocol.

screen is cool and pretty easy to use, RTFM. But its command-line only, so not applicable if you need GUI as well.

Re:ssh + vnc

[Curtman]

Or just forward the VNC port. Should be 5900 for screen :0. It'll be faster than raw X11 forwarding.

Re:ssh + vnc

[Scherpbier]

If you use xtightvncviewer, it has the "-via" option which sets up a tunnel (ssh is the default) for the connection. Only ssh needs to be exposed through the firewall that way.

Alternatively, set up OpenVPN (either through a dedicated firewall or on your linux box) or other VPN so you can access the VNC server as if you were local to your network.

screen

[Chris Snook]

Yum distro:
yum install screen
man screen

Apt distro:
apt-get install screen
man screen

Re:screen

[Ice Wewe]

Gentoo distro:

emerge -av screen

Mac OS X:
fink install screen

Re:screen

[SuperQ]

And of course my favorite thing in my .screenrc:

# turn sending of screen messages to hardstatus off
hardstatus on
# Set the hardstatus prop on gui terms to set the titlebar/icon title
termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007
# use this for the hard status string
hardstatus alwayslastline
#hardstatus string "%h%? users: %u%?"
hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d %C%a "

Re:screen

[pathological liar]

I'm a zsh user, I've got this in my .zshrc ... I've never tried to post a code snippet to Slashdot, hopefully it doesn't mangle it too badly...

case $TERM in
xterm*|screen*)
preexec () {
export CURRENTCMD="$1"
if [ x$WINDOW != x ]; then
print -Pn "\ek$1\e\\"
else
print -Pn "\e]0;[$USER@$HOST] $1\a"
fi
}
precmd () {
if [[ ! -z $CURRENTCMD ]]; then
if [ x$WINDOW != x ]; then
print -Pn "\ek($CURRENTCMD)\e\\"
else
print -Pn "\e]0;[$USER@$HOST] $CURRENTCMD (done)\a"
fi
fi
}
if [[ "$TERM" == "screen" ]]; then
print -Pn "\ekzsh\e\\"
fi
if [[ "$TERM" == "xterm" ]]; then
print -Pn "\e]0;[$USER@$HOST]\a"
fi
;;
esac

Inside screen, that will set the window title to the currently executing command.. nice if you're quickly flipping back and forth between windows and don't want to bother renaming them yourself.

I'm not sure that will work with any other shell, I don't know of anything else with preexec/precmd offhand.

Use screen

[Whatsisname]

Nothing beats screen for terminals.

I use irssi + screen so I can be in some of my irc channels all the time, and connect to it from wherever I can run an ssh client.

Go with screen

[DigiDarkCloud]

Given that it's made specifically for persistent terminals across login sessions, Screen is definitely worth learning. If your needs are text-based, it's the best way to go.

It sounds like your GUI needs are rare. In those occasions you could probably fire up a VNC or other session when you need it (from the remote screen session) and shut it down again when you're done.

Simple answers.

[crazyvas]

Use screen for terminals. x11vnc for GUI. x11vnc can be run over encryption. Look at http://www.karlrunge.com/x11vnc/ for more info.

freenx / nxserver

[mikey573]

For persistent GUI sessions, I generally use nx/nxserver/freenx:
http://freenx.berlios.de/

For console sessions, nothing beats "screen". I use the command "screen -m -R" to create and/or reconnect to an existing session.

I used to like VNC, but I got tired of how difficult it was to set up. On Windows boxes, I stick to Remote Desktop Connection.

Persistent X and others

[mrmeval]

http://www.icsi.berkeley.edu/~wooters/persistentX.html

I've not tried this but it looks good.

Some for vnc
http://www.novell.com/coolsolutions/feature/16011.html

With xinetd?
http://newsgroups.derkeiler.com/Archive/Uk/uk.comp.os.linux/2006-02/msg00109.html

SSH Tunnel to protect VNC

[brownsteve]

This is what I do every morning to get into work.

Start up a VNC server on the remote box and leave it running. No need to open holes in your firewall except for SSH, which is pretty safe to do.

To tunnel through the firewall and log in, type these commands on your local machine:

ssh -f -N -L 5901:localhost:5901 -X username@remotebox.example.com
vncviewer localhost:5901

Voila: VNC connection, secured by SSH. When you are done just

killall ssh

.
Note that 5901 means the :1 VNC session, 5902 means :2, etc.

Re:SSH Tunnel to protect VNC

[ink]

You can also just end the SSH session (don't background it with '-f') to cut the tunnel. This also works with PuTTY for Windows machines. I've setup PuTTY shortcuts for some of my coworkers and they just double-click on them, enter their passoword, and they're using VNC just fine. When they want to stop using it, they just close PuTTY. Easy as pi.

Quick primer

[Nicodemus]

Here's a quick primer. These are the commands I use all the time. There are a ton more in the man pages or online help.

"screen" to start a new shell under screen

All commands start with CTRL-A, then another key for the command itself. If you really want to send a CTRL-A to your application (Like to go to the beginning of the current line in bash for example, hit CTRL-A twice.)

CTRL-A CTRL-D Detach your current session

"screen -rd" to get back to it

CTRL-A CTRL-C create another "window"
CTRL-A CTRL-N next window
CTRL-A CTRL-P previous window
CTRL-A " see list of current windows
CTRL-A [ Copy mode... you can see the scrollback buffer with this. Esc to exit
CTRL-A ? Help for further stuff.

I run just one instance of screen with multiple "windows." Works beautifully. When you start running more than one screen process under the same user it can make it difficult to re-attach because you have to tell it which pty to attach to.

Nicodemus

fpga tools

[scatterbrained]

The xilinx fpga tools run just fine (perhaps better) from the command line, and have native ports to linux. I believe the same is true for Altera. If you run the xilinx gui tool with the command line log file turned on, it will give you a look at what's required.

IIRC, screen has a pretty detailed man page and has been around a very long time, so should be pretty easy to find examples of setting it up.

For X, usually the real pig is the display server. If you have to run X read up on using the DISPLAY environment variable and just run the X clients on the box and run the server somewhere else - that's what it was made for ;-)

Sunrays

[Anonymous Coward]

Check out Sunrays. You can get them on ebay for cheap ( $20), and download the software from Sun. They have a linux version. Get some Sunray cards. You just stick the card into the slot, log in, and work. Remove the card, your session disappears from that terminal. Go to another terminal, put in your card, and your session appears.

Yeah it makes sense

[Nicolas MONNET]

All code except system calls runs natively, and therefore just as fast as native code.

FWIW, nxserver works great

[Burz]

...I've always had more luck getting it to work right than with freenx. But the latter has a KDE session integration now so the auther may want to look into that.

The session handling and preservation of nxserver is very good.

Re:nx* = PITA

[Burz]

Not seperate ssh server... unless you're on Windows?

Separate key is needed because nx must do session/login management from root. Simple as that. Once I grasped that, the rest came easy (I will admit to being familiar with ssh configuration though).

Sun Rays

[Paul Jakma]

Sun make pretty neat thin-client terminals called Sun Ray. Can work with either Linux or Solaris servers.

NB: I'm biased, as I work for Sun.

Long term != poor comprehension

[tepples]

From the article: For the short term, the main need is just terminals.

(my strong emphasis)

I would guess mrmeval was looking at "However, if I decided to run FPGA synthesis software under WINE, [some system that supports graphics] will become necessary." in the article. I don't think this FPGA synthesis software can be operated completely from the command prompt.

modify your bash profile

[vlm]

Once you're comfortable with screen, which only took me a couple days, back in the mid 90s, add this as the last line of your .bash_profile

exec /usr/bin/screen -xRR

Upon ssh'ing into the box, that'll set up a screen session, or if one currently exists, reattach to it.

Also, if you log in multiple times, from different PCs or whatever, all your logins see the same screen session, which can be convenient if you're "sharing" logins.

To disconnect from the session, just "C-a z" and your ssh connection will drop.

You'll probably want to customize your .screenrc file also. I advise setting

vbell off
escape ^zz
nonblock on
deflogin off
startup_message off
screen -t procinfo 0 watch -n 60 procinfo
screen -t bash 1
bindkey -k k1 select 1
bindkey -k k2 select 2 .... you get the idea .....
bindkey -k k; select 110
bindkey -k F1 select 11
bindkey -k F2 select 12 ... etc ...
Oh and set a useful caption line too.

Re:Screen works welll...read this link SUBBY

[xSauronx]

so is google. im not against people looking for help, but i would think ask slashdot could limit itself to unusual problems. ssh/x forwarding/screen is pretty elementary stuff.

what a ridiculous thing to put on the front page. any number of forums or HOWTOs probably provide all the information the submitter is looking for, so id like him to read this.it looks long, but its a quick read.

How to ask questions the smart way

/ill take the karma hit, if the subby will do his own research from now on

Re:Screen works welll...read this link SUBBY

[Two9A]

Easy; plug in the Ethernet, boot a Gentoo LiveCD, and a minute after the disc access has stopped, type the following (carefully) at the assumed # prompt:

# ifconfig eth0 [a known IP]
# /etc/init.d/ssh start
# passwd
[enter a password for root, twice]

SSH in from another box, and you're done! Worked fine for me, installing Gentoo on a Kanga with a broken screen from three timezones away.

Of course, it assumes that the Ethernet card is working, and that the kernel picks it up as eth0. If the network lights up but you get no joy, try a LAN-wide ping sweep; I've had to do that a coupla times when this kinda thing's cropped up.