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

[mrmeval]

Screen works for text. Does it allow persistent and secure connections for types of programs mentioned in the article?

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

[Anonymous Coward]

Why not just run it on the console, and connect a KVM with network access to that sucker?

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

[daliman]

Also, a trivial script to go through your open screens (useful if you run a bunch of torrents on some server somewhere...)

#!/bin/bash
for screen in $(screen -x | grep `hostname` | cut -f2); do
screen -x $screen;
done

Re:Screen works welll

[Cillian]

Persistent? The point is, screen runs on the server. So whatever you run in it is persistent. Security is handled by whatever you use to connect to the server, i.e. SSH.

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

[The_Wilschon]

You want to use screen -x for that. There are some trickinesses to it, though, and I've never made it work with multiple different users connecting to one session. Different people logged in using the same username, yes. different usernames, no. But then I didn't try all that hard.

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

[El_Isma]

Indeed, Screen is the way to go for text.

"man screen" should get you on your way.
I've found useful the following website:
http://gentoo-wiki.com/TIP_Using_screen
Near the bottom is a "live" session example.

This one is good too:
http://www.kuro5hin.org/story/2004/3/9/16838/14935

Re:Screen works welll

[simcop2387]

screen -xr

Re:Screen works welll

[Cillian]

screen -x is your friend

Re:Screen works welll

[lostguru]

vi?

Re:Screen works welll

[LeafOnTheWind]

If all you are doing is establishing a persistent ssh connection, you may want to think about using dtach. It's the equivalent of vi to emacs. Why use an operating system when all you need is a text editor?

Re:Screen works welll

[koreanbabykilla]

yes screen -X

Re:Screen works welll

[Lord Apathy]

Yes, -x is one of it's more useful features. I use it to check the output on the console in the system room from my office.

Re:Screen works welll

[Lynx]

http://www.emacswiki.org/cgi-bin/wiki/GnuScreen

Re:Screen works welll

[the donner party]

I don't know about canonical, but I use control-backspace for the escape character - that's "escape ^\\" in ~/.screenrc. Works great. The standard function of control-backspace in a terminal would be to send SIGQUIT, but I never needed that anyway. The only problem is when you think you're in a screen but you aren't, and end up killing the foreground process. That is easily remedied by never running anything out of a screen.

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

[wereHamster]

Of course two different users can't connect to the same screen session. That would be a big security risk. Look into /var/run/screen and you'll see that only you have access to the directory where your screen sockets are stored. Maybe it's possible to fiddle with the file permissions, but I wouldn't recommend it. Just create a new use that all the people have access to and tell them to use 'screen -x'

Re:Screen works welll

[irc.goatse.cx troll]

Of course you can, and its one of the more useful features of screen.
MultiUser sessions

You configure ACL's per user, allowing you to give someone read access to your screen but not actually giving them control. This works really well for demonstrations.

It's also a very convenient way to demonstrate to another user on the system some sort of odd behavior you're experiencing, or get feedback on something.

As for the security of it, if security was a serious concern you shouldn't run things in a multiuser system let alone deal with permissions. I trust it, but I also trust every user on the machine. YMMV.

Re:Screen works welll

[ari_j]

I don't, because I multi-attach screens all the time. What I have is "alias scr='screen -xRR main'" in my bash rc setup, running it only when $WINDOW is not defined (which is a quick way to know whether you're in a screen session already). I also have "alias emacs='screen -c ~/.screenrc-emacs -xRR emacs'" with the relevant screenrc file set to start up a single window with an Emacs session in it.

Anyhow, I agree that -D is a good option to know about and to make a conscious decision whether you want to use it or not.

Re:Screen works welll

[chrispatch]

try ssh -C -X myserver.mydomain.com

for remote X, compression is a big win for me.

As always YMMV.

Re:Screen works welll

[glarbl_blarbl]

I like to run a screen session on my file server with uTorrent running and attach with screen -x. That way I can leave my seeds up all of the time and take my macbook with me to check on them if necessary. With -x it will share the session between two terminal sessions -- you can even share it with another user on the system if you set up the permissions correctly.

Re:Screen works welll

[tog000]

If you run screen -x it will print the output (or your written text) in any console that is connected to that session, some sort of a chat. It can be really useful if you are showing something to someone and you want to show them the commands and the output, but certainly not very practical in a production environment.

Re:Screen works welll

[Jellybob]

It's a bit off topic, but the curses version of btlaunchmany is great for that sort of thing - give it a directory to watch, and it'll automatically start downloading any torrent files you put in it, giving you a curses GUI to show how things are going.

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

Re:Screen works welll

[sgbett]

I agree 100% with this post, however since the new version of nzbget (interactive curses) came out I don't think i will ever BT again

Re:Screen works welll

[jetmarc]

Another important one is screen -x to attach to a screen from multiple machines at once. Very useful if you are in the office and find you forgot to close the connection at home. I used to use -R but now use -x almost exclusively.

Re:Screen works welll

[laddiebuck]

I prefer the same, but use screen -ROAD (actually screen -ROAD main, to jump to my "main" session). This additionally resizes the terminals and fixes the termcaps, plus of course it's a great mnemonic.

Re:Screen works welll

[ckthorp]

I like that mnemonic!

Re:Screen works welll

[harshmanrob]

I use no machine and for both local and over the internet connections (including slow DSL) it is AWESOME. It is just like a session locally and plus it is secure traffic over port 22, SSH. I would go with this.

Re:Screen works welll

[Ciaran_H]

Very useful if you are in the office and find you forgot to close the connection at home.

You can also use 'screen -d -R' if you wanted to detach it first.

(I use 'screen -x' myself, but just letting you know there are other, perhaps better ways to do what you're looking to do.)

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?

[Anonymous Coward]

Considering he seems to want number crunching (or at least applications that continue to work when he does not have the window open), does FreeNX's "suspend" allow the programs to continue running or are they all "paused" until you log in again (i.e. screen/vnc behavior or computer suspend/hibernate behavior)?

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.

Re:How about NX/nomachine.com?

[Red Storm]

I've got it running on my personal machines which are sitting in a colo. It runs over SSH which is great and I locked down SSH to only allow "trusted" users and everything works great! I haven't played with it's Samba integration but it's supposed to allow you to share files from your windows Client with your NX session. Also NX will apparently pipe audio across the link but I haven't played with this yet. For my needs it's been perfect.

Oh ya... the server (Linux) and client (Windows/Linux) are both free as in beer.

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.

Re:ssh + vnc

[hedwards]

I wouldn't personally log into an account via a public terminal, unless I was using a one time password set up or it was a junk account.

Considering the person asking the question has control of his own box, that's definitely doable without too much trouble. The only other bit is having the calculator or printed card.

Re:ssh + vnc

[Malc]

Two problems:
1) X11 over SSH is fine, until the tunnel disconnects. Then all the apps go
2) VNC totally sucks performance-wise. If I'm forced to use VNC, these days I RDP to a Windows machine on the same network, and then do a nested VNC session from there. It performs better, especially when latency is above 100ms (as measured by 56 byte ping).

Is there no good UNIX remote access GUI protocol? Something that allows you to disconnect and reconnect? Years of using RDP to Windows boxes has left things like VNC totally irritating as it just doesn't work as well. I'm really surprised that Apple hasn't got a better solution for OS X too.

Re:ssh + vnc

[drsmithy]

I'm really surprised that Apple hasn't got a better solution for OS X too.

It's a long, long way out of any market Apple has interest in.

Re:ssh + vnc

[barry_the_bogan]

What makes you say this? They have xserves which, from what I've seen, are mostly configured with a GUI. I know they have some remote GUI management tools to some of this, but having a graphical connection back to the server is also a helpful think to have at times. Why wouldn't they want something that works better than the current tools?

Re:ssh + vnc

[drsmithy]

What makes you say this?

Because the scenario being described is interactive, multi-user servers. Which bears no resemblance to any market Apple is interested in (largely because, these days, it's a tiny niche).

They have xserves which, from what I've seen, are mostly configured with a GUI. I know they have some remote GUI management tools to some of this, but having a graphical connection back to the server is also a helpful think to have at times. Why wouldn't they want something that works better than the current tools?

Graphical, centralised management is better done with (scriptable) client/server tools (as on Windows), not some equivalent of VNCing in.

Re:ssh + vnc

[cps42]

Check out the above posts on NX and FreeNX -- at the place where I work, we use it on a number of client systems that are accessed from all over the world by test engineers for replicating customer issues. NX was the only one of the *nix X11 front-ends that effectively worked from the APAC region to PACNW, over high latency, low bandwidth links.

2, the NX client handles client-side optimizations like providing remote sound and local drive/printer access, a significant improvement over VNC. However, don't try that from very far away. That's not low bandwidth.

3, NX allows you to disconnect your session, and re-establish it later, like RDP and Citrix. It really does work pretty well.

Re:ssh + vnc

[WhiteWolf666]

As everyone else says, check out FreeNX

It's simply fantastic. Works great over low bandwidth connections, easy to setup, supports suspending sessions.

It's awesome. Check it out.

Re:ssh + vnc

[milgr]

2) VNC totally sucks performance-wise.

I use VNC all the time. The way to get good performance is to minimize the number of colors and color changes. I set the background to a solid color. My performance this way is almost as good as being at work. It doesn't hurt that my connection is 5Mb, but I think that I used VNC over a dialup connection years ago.

Re:ssh + vnc

[Malc]

I do that thanks, and if I don't care about reading the text, I crank up the JPEG compression. It's not the connection speed/bandwidth that's the problem, it's the latency. After using RDP, even 120ms for VNC is painful (like when I'm at home in Toronto on a 6mbs connection working on computers in California connected via DS3). But just try it over a 400ms link (like when I'm visiting our office in China and working on machines in California). Unusable (as opposed to sluggish RDP that keeps going, and feels like VNC on a 125ms link). Then there are the bugs in VNC. It's been plagued over the years where on some machines the screen doesn't refresh. That means after every click or typing, requesting a screen refresh. VNC's crap, but I guess you get what you pay for, and it's the only choice if you're not connecting to Windows machines (although NX mentioned elsewhere sounds interesting).

screen

[Chris Snook]

Yum distro:
yum install screen
man screen

Apt distro:
apt-get install screen
man screen

Re:screen

[Lord Apathy]

Screen is one of the greatest and useful commands ever envisioned.

Re:screen

[Ice Wewe]

Gentoo distro:

emerge -av screen

Mac OS X:
fink install screen

Re:screen

[jgercken]

don't forget the emerge distro :)
emerge sync
emerge -p screen
emerge screen

Re:screen

[clang_jangle]

Mac OS X:
fink install screen

That or:
sudo port -v 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

[kamochan]

Actually, for Mac OS X it's even simpler, as screen comes with the base OS:

mymac:~ username$ which screen
/usr/bin/screen

Re:screen

[sonicattack]

And Screen, used as directed, is absolutely safe.

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.

Re:screen

[Yogiz]

Slackware distro:
cd /usr/src/tar
wget ftp://ftp.gnu.org/gnu/screen/screen-4.0.2.tar.gz
cd ..
tar -xzf tar/screen-4.0.2.tar.gz
cd screen-4.0.2
CFLAGS=" -O2 -march=pentium-m -pipe -fomit-frame-pointer"./configure --prefix=/usr
make
mkdir /tmp/screen_install
make DESTDIR=/tmp/screen_install install
cd /tmp/screen_install
mkdir install
vim install/slack-desc
makepkg screen-4.0.2-i686-1.tgz
installpkg screen-4.0.2-i686-1.tgz
cp screen-4.0.2-i686-1.tgz /usr/src/packages
cd ..
rm -r screen_install

What? Difficult? What are you talking about, that's the only good way.

Re:screen

[Fatalis]

except it's not a command, but an application. commands are a part of your shell.

Re:screen

[Lord Apathy]

Yes, that is true. It one of the most useful applications then.

Re:screen

[DarkOx]

Stop frightening the non-slackers, screen is in the disto slashdoters.

1.Insert dvd or download slackpack from ftp.slackware.com (Hey you could even use your browser!)
2.cd /{directory containing package}
3.installpkg screen-X.X.X-i386-1.tgz (replace X as required: hint match the file name.)

A bit easier then the above I think, and no you won't get any uber-leet-performance by doing your own build.

Re:screen

[Yogiz]

Yeah, I was just fooling around. I don't actually use Slack but a LFS system that uses Slackware's package management. On my system it would actually be just:

pkginstall ftp://ftp.gnu.org/gnu/screen/screen-4.0.2.tar.gz

Re:screen

[clang_jangle]

or:
cd /usr/ports/sysutils/screen && sudo make install clean

Re:screen

[RiotingPacifist]

Or for most distros just:
screen
I mean if ubuntu contains it you'd assume all the 'geekier' distros do too.

Re:screen

[houghi]

openSUSE 11.0: Click here

So easy, even a Windows user can do it.

Re:screen

[neurovish]

emerge -uv screen ...and people say that gentoo is a nightmare?
I wish I was still elite enough to run slackware fulltime.

Re:screen

[laddiebuck]

Oh, it's hardstatus wanking, is it? :P

Just kidding, I love it too. My hardstatus shows my next calendar item, latest email from and subject, followed by hostname and current command. On the right is a little elinks-style "led" with one-character status messages (away on irc, screen locked, new irc messages, how many new emails) followed by the date and time. The caption (caption always and hardstatus alwayslastline) above it is then given entirely to the windows, with the current one highlighted.

Re:screen

[laddiebuck]

That's the main reason I use zsh in the first place -- no other shell can do that, and it makes screen usage so much better.

Re:screen

[wolftone]

...now why on earth would a Slackware user build a new package for 4.0.2 when 4.0.3 is installed by default? And if, for instance, the user opted initially to install a lean system without screen, it would be rather easy to download the official package. Or, just type 'slackpkg install screen' (assuming that the user has installed extra/slackpkg).

Re:screen

[Ster]

`/usr/bin/screen' is installed by default on OS X. On fully up-to-date OS X 10.5.3:

[machine:~] user% screen -v
Screen version 4.00.03 (FAU) 23-Oct-06
[machine:~] user%

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.

screen

[vengeful]

The usefulness of screen cannot be overstated.

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.

stupid question

[Miros]

This might be a stupid question, but does it really actually make sense to run big number crunching applications on top of WINE? I know WINE performance is really quite amazing considering what it is, but at the same time, if you have a job that you expect to run for a long time doing a lot of work (especially a threaded one) repeatedly you should probably re-implement it if you can natively. OpenMP is kind of fun

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.

Re:freenx / nxserver

[Covener]

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.

I've always found VNC dead-simple to install/configure/run, except on the cruftiest of old unix systems where the environment setup was busted.

Typically it's one-liner native package install, run 'vncserver', and change your window manager if you're picky.

Screen.

[ari{Dal}]

Keep it simple - this is what screen was meant for. Install it and read the man page, it's really easy to use.

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

this one

[corporatefucker]

vncserver :1 -name parngr -geometry 1024x768 -depth 16

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

[spydum]

Mod parent up -- this is probably the best approach. Just be sure that VNC is only listening on localhost. No need to have it binding to other IP's.

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.

Re:SSH Tunnel to protect VNC

[gbjbaanb]

and if you use pageant, password is a one-time affair. However, if he's using a closed-lan system, then he could use a passwordless key so he can SSH on just by clicking a link.

Re:SSH Tunnel to protect VNC

[LeafOnTheWind]

No need to open holes in your firewall except for SSH, which is pretty safe to do.

I would strongly disagree with this statement. Because ssh has the ability to do so much, it deserves special attention to security. The default implementation should be tweaked more than a little bit, including disabling password login, changing the port and, please don't forget, disabling ssh1. There are other, more subtle, cryptographic attacks, but even those few changes should make it more secure.

Re:SSH Tunnel to protect VNC

[ink]

The default implementation should be tweaked more than a little bit, including disabling password login, changing the port and, please don't forget, disabling ssh1.

Disabling passwords is a double-edged sword. On the one hand, it's more difficult to forge credentials, but on the other hand, a stolen, carelessly-maintained laptop grants full access. Either way, you trust the end-user to secure her system -- it's just that with passwords, they are more likely to re-type them every time (most ssh clients do not save the password). With a key exchange, they are much more likely to have it fire-and-forget.

Re:SSH Tunnel to protect VNC

[Blakey Rat]

Would be nice if VNC just did the freakin' encryption and screen locking by default and automatically, like Windows Remote Desktop.

Why does Linux stuff always have to be so goddamned hard to use? I swear, Linux coders simply hate end-users, there's no other explanation.

Re:SSH Tunnel to protect VNC

[ystar]

Feeding trolls is always fun, so:

The idea is modularization. VNC does one thing, and does it (sort of) well. SSH does one thing and does it well in version 2. If you can't use SSH authentication in a setting, then you're still able to use VNC with some other auth mechanism. RemoteDesktop is inflexible and monolithic, if one component in the chain is a problem you have to abandon the whole solution. The modularity of *nix is it's strength, but it also makes things more difficult for novices. Windows is there for a reason - for people like you, who need things to 'just (sort of) work (with luck)'. Don't complain just because you think you can have your easy to use GUI cake and eat an extremely powerful implementation too. Developer man-hours are limited. They'll get to it when they have time away from their REAL jobs that PAY. Linux distros are so much more userfriendly these days because of many people willing to put hard work into it without reward, not because Blakey Rat sat around complaining on slashdot until someone got off their butt and started working on a trivially easy coding task.

Time for a car analogy: "This Minivan sucks. It can't go fast at all. The designers hate drivers, there's no other explanation." Well, a minivan is cheap and designed for carrying a lot of people. Pay more, get a better solution for your needs - Porsche.

Ok, I just compared Windows to a Porsche.

Re:SSH Tunnel to protect VNC

[Dr. Winston O'Boogie]

Not to mention that "safe" here is probably assuming you do not care about security issues originating from within your system. SSH forwarding/tunneling ability can result in inadvertently or deliberately introducing a whole set of new security issues to worry about: "All your port belong to us."

Re:SSH Tunnel to protect VNC

[Two9A]

Agreed; special precautions are needed when ssh is open.

I left mine on the default port, but added an IP whitelist to my firewall rules. In the rare case that I'm not connecting from a previously-added IP, I can call my brother who'll run a local script to add my IP. I've only had to do it once, and it seemed to work well.

People can throw themselves at my ssh port all they like, they won't get through. [The old adage about inviting trouble may be appropriate here.]

Re:SSH Tunnel to protect VNC

[Duckie01]

I made it even more secure, and at the same time got rid of the worms trying to brute force my sshd 40 million times a day... Not that they were likely to succeed, but I dont want my hd to wear down in a year.

So I configured the linux firewall to drop all traffic to port 22. At same time I wrote a small php script that'll insert a firewall rule accepting packets to port 22 from the IP I'm at. Then I simply password protected the php script with .htaccess and voila...

Pretty damn safe ssh access for me when I need it... and no more worms banging on my door :)

Re:SSH Tunnel to protect VNC

[Blakey Rat]

What I'm complaining about has *nothing* to do with being modular.

There's no reason VNC couldn't just use the SSH "module" automatically and by default. It just ... doesn't. Saying VNC should automatically use encryption != saying Unix should no longer be modular.

That aside, though, the modular approach seems kind of ridiculous if you took it to the logical extreme. I mean, every time VNC needs to draw a rectangle on the screen it should use another executable to do it, right? Otherwise, it's just not modular-- and if someone came up with a better way to draw rectangles, VNC wouldn't be able to take advantage of it.

Re:SSH Tunnel to protect VNC

[mollymoo]

Get over the open-source-coding-is-unpaid thing. Loads of the coders, particularly of larger projects, are full-time professionals employed by Novell, IBM, RedHat etc. Unpaid open-source work is hardly without reward either, I find the emails of thanks I get for the (incredibly minor) projects I've released hugely rewarding.

Re:SSH Tunnel to protect VNC

[v1z]

Actually with newer versions of vnc/tightvnc this is now even easier:

    xvncviewer -via username@remote.host localhost

Equivalent to:
    ssh -f -N -L5901:localhost:5901 username@remote.host
    vncviewer localhost:5901

   

Re:SSH Tunnel to protect VNC

[cymru_slam]

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.

Leaving ssh open is *NOT* "pretty safe" unless you know exactly what versions of sshd you have running and how they are configured. Depending on what version of SSHD and SSL you have installed this could end in tears!

Re:SSH Tunnel to protect VNC

[jesboat]

Easy as pi? Sounds pretty hard then... I never could do the arithmetic to get a computation with pi exactly right :-P

Terminals mainly?

[LinuxGeek]

Try conspy, very handy utility.

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

Re:Quick primer

[ablcmx]

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

Or use screen -S NAME to name all of your sessions. Then you can reattach with the logical name rather than numerical pty.

Re:Quick primer

[NoSpamPlease]

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.

This is where the "-S sessionname" option is handy. I used to have multiple instances of long computations running, and each screen session would have multiple windows containing the code editing, compiling, and execution. Using the session name made it very easy to tell which was which.

Use the "screen -list" command to see all the different screen sessions you have started, along with their names.

Re:Quick primer

[bucky0]

the day that my grandmother is leaving persistent terminal sessions around is the day I pick up cross-stitching.

It's an advanced thing to do, why would it influence "linux on the desktop (tm)"

Re:Quick primer

[LihTox]

So, I would have to open 5 or so terminals, and run
    screen -r -d pts-1
    screen -r -d pts-2
    screen -r -d pts-3
    screen -r -d pts-4
    screen -r -d pts-5 ..in each of the terminals? It's not terrible, but would be better if there was a few shortcuts.

That's what shell scripts are for, no? :)

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 ;-)

Re:fpga tools

[julesh]

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.

Yep, Altera's tools are available for Linux also.

The other thing that occurs to me based on the suggestion that the box will be used for FPGA synthesis: this is a very resource-intensive app. X11, not so much. Just run a damned X server and ignore the ~20MB it'll use. You presumably have at least 1/2 gig of RAM in that machine -- if not, you really need more for the application you want it 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.

dtach beats screen

[djarum72]

dtach doesn't mess with the keys like screen. Easier to do interesting things like sharing screens without being SUID.
Man page is measured in pages not reams.

Yeah it makes sense

[Nicolas MONNET]

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

Re:Yeah it makes sense

[Miros]

to be honest, that's pretty sweet =)

Re:Yeah it makes sense

[bucky0]

That's true, but if he's talking about graphics things, there is a LOT that is emulated. Google "DIB engine wine" for a look.

Basically, unless you're using DirectX/OpenGL, windows makes assumptions about the graphics layer that can't be directly done in X. AFAIK (it's hard to understand), many of the earlier windows libraries give the program direct shared access to where they are rendering, but X11 has the program and the actualy framebuffer divided by the X11 layer. Emulating that blows in terms of performance.

If his program is using directX, there is also an emulation layer to convert the calls to opengl.

IANAWH (wine hacker) so I could be off.

Re:Yeah it makes sense

[Digi-John]

Synthesizing FPGA designs (the given example) is not graphics-intensive.

What I read

[krappie]

"I really want this feature. I've heard of this program that's made for exactly the feature that I want, but I'm unfamiliar with it. HELP ME SLASHDOT YOU'RE MY ONLY HOPE!!1!"

Re:What I read

[rhizome]

"There should be a way to send words to another computer about things that I would like to know more about. I bet someone could make a lot of money by inventing a service such as this."

NX

[Bert64]

Try NX, http://www.nomachine.com/
It's orders of magnitude faster than VNC or native X11, and supports persistent sessions as you describe...
It also runs over SSH, so it benefits from the inherent security of SSH.

I would never even consider using VNC, entirely pointless... slower than native X11.

Re:NX

[Covener]

I would never even consider using VNC, entirely pointless... slower than native X11.

In my experience, once you go beyond two systems on the same LAN, vnc copes with the latency much better than native X11. For some reason, swing apps seem to suffer the most (more round-trips baked into how they use X?)

There's also the issue of unreliable links/roaming/etc which are big pluses for vnc/nx.

IMO NX is only marginally better performing than vnc.

Re:NX

[srh2o]

In my experience NX has always blown away VNC in performance. VNC isn't in the same league performance wise.

Re:NX

[Zardus]

Another vote for NX here. I've been using it for years and VNC doesn't hold a candle.

Also, NX tunnels communications over ssh, so if you're ok punching ssh through the firewall (or already do so), there's no problem.

Re:NX

[genericpoweruser]

Perhaps not the vanilla VNC but TightVNC supports many kinds of compression, most notably jpeg. I've found it usable. Though I prefer not using GUI stuff over the internet as it is too slow.

I've never found a FOSS NX server that had a working download link.

Re:NX

[Seraphim_72]

In all the times that I have tried it I have never seen the performance increase. Never. Multiple systems multiple networks. It was so unimpressive that I actually hadn't even thought about it until this thread. I suppose I should try it again ... but I am not going to hold m breath. Yeah, It left me that flat.

Re:NX

[empaler]

I heart my 20mbit connection. Not only because it's fiber and cheap as free, but also because it's a symmetric line. The only time I run into latency or bandwidth issues is if I try to remote to a laptop on wifi.

nx* = PITA

[Nicolas MONNET]

You think VNC is difficult to set up? Well NX is just absurdly complicated. That one time I managed to get it working, it was indeed vastly superior to VNC, but I just can't fucking understand why they have to install their own damn SSH server and keys. Why? WHY???
How come it's not been picked up by any major distribution? Probably because installing it by following the megabyte-long HOWTOs feels like an exercise in computer masochism.

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).

Re:nx* = PITA

[Red Storm]

How come it's not been picked up by any major distribution?

SuSE has had it for a while now. My recollection of seeing it in YAST goes back at least a year. It's a *SNAP* to setup under SuSE. Select the package, then go to the docs directory and read the SuSE readme, run the setup program. Done, less than 10 minutes start to finish. If anything the windows client is more confusing than the Linux server under SuSE. :-)

Re:nx* = PITA

[yerdaddy]

Well NX is just absurdly complicated.

How long ago was this?

I've been using it for a year or so. Just installed the RPM and it worked fine.

Re:nx* = PITA

[neurovish]

"yum install freenx nxclient" works on Red Hat derived distributions if you have the dag or atrpms repository.

RTFM!

[jhealy]

translation: can someone tell me how to use screen?

let's see, how can i write this so no one will call RTFM on me...

Re:RTFM!

[bsims]

Well the docs are well written...
But the config files out there are extremely poorly commented...

Here's a link to mine: http://home.insightbb.com/~bmsims1/Scripts/Screenrc.html

I actually show you what the line noise does and
what it will look like.

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.

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.

Re:Sun Rays

[Paul Jakma]

Huh.. If all the other posters who read the question as being about purely *text* terminals (despite mention of VNC) are correct, then their suggested answer of "use screen or dtach" are of course much better than using Sunrays. ;)

Re:Sun Rays

[florin]

I really wish Sun Secure Global Desktop were a free product or had some sort of free edition. It's all the things VNC and FreeNX aren't, and compares well with Remote Desktop and Citrix, but at 100$/seat it's never gonna matter.

Re:Sun Rays

[McKing]

Uh, the original poster talked about persistent X11 sessions. The Sun Rays are perfect for this. The OP can even have one at home set up to connect to his Sun Ray server at work, detach from the session at the end of the day and reconnect to it from home.

Sun Rays are really one of the coolest technologies to come out of Sun in the last 20 years, but unfortunately, they are such a shift from the norm (and until recently needed Solaris on Sparc for the server) that most companies have no idea of their potential. Sun even has gateways to Citrix so that the same little desktop box can display Solaris, Linux, and Windows apps all at the same time.

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.

Re:Long term != poor comprehension

[Eric Smith]

I don't know about Altera's software, but the Xilinx FPGA software definitely can be used from the command line. The GUI stuff just provides a fancy IDE. The "FPGA Editor" (tweak the FPGA down at the bit level) doesn't have a non-GUI version, but it also isn't part of the standard development flow.

Re:Long term != poor comprehension

[hpa]

Altera's can too (we used to use it from a Makefile at a previous company I worked for.) Unfortunately, they charge money for their Linux-native version, which is a bummer since it's quite a bit faster than the Windows version, or at least was at that time.

why not just use ssh, then the screen utility?

[MarkWatson]

Screen is a great utility. I wrote about it here: http://markwatson.com/blog/2007/04/cant-believe-i-missed-this-unix-utility.html and will not repeat myself.

GPU instead of CPU or FPGA?

[raftpeople]

I know this is offtopic and you didn't ask this question, but instead of using CPU (or ultimately FPGA like it sounds you might), have you looked into running calcs on a graphics card?

I also have a genetic algorithm, neural net, artificial life project that needs lots of processing power, after looking at my options (cluster of pc's, cluster of PS3's, FPGA's, GPU's), I found that GPU's look like the best bang for the buck by far.

I've just started the process of converting my critical code to nvidia's CUDA technology.

kdm/gdm with autologin, X, xvnc, ssh and screen

[Simon (S2)]

I use the same on my home box. I setup kdm to automatically log my default user in right after startup, and put this

s2@fresh:~$ cat .kde/Autostart/x11vnc
#!/bin/bash
(while true; do /usr/bin/x11vnc -forever -nopw; sleep 10; done) &
s2@fresh:~$

autostart file in as well, so I have a vnc server listening and sharing that desktop. The vnc port (5900) is firewalled from outside the lan, so it's relatively secure. To access it I use an ssh tunnel, so traffic is encrypted, and when I close my vncviewer window and reconnect later everything is still there and running.
For the terminal I use screen, and I usually have one window open with an irc client, one that tails some log files, one with mutt, and so on. You could run your number-crunching stuff.
It's really a nice setup, I work like this every day and I am really pleased with how good it works.

Xvfb

[kreuzotter]

I use Xvfb to make a virtual screen on the number cruncher (comes with xorg). I don't need to see the display, it just has to be there for wine. If something goes wrong (error box pops up) and there is no progress I take a screen dump of the vortual screen to see it. This eliminates traffic on the network too.

Re:Xvfb

[HoboCop]

I have used this approach too. Works well, and works with pretty much any unix variant.

Re:Xvfb

[Joe Enduser]

You can simply combine Xvfb + a simple environment like blackbox + x11vnc to monitor the screen. Run x11vnc on localhost only, and tunnel in through SSH. Very easy and pretty safe way of running a persistent X11 session. See this forum for the exact commands.

XRDP

[maz2331]

XRDP works pretty well. It's basically an RDP "wrapper" for VNC, and should be secure "enough" for your use.

If you need a GUI for the apps, then you need a GUI for the apps. I wouldn't worry much about the overhead since WINE itself will have much more anyway. We're talking here about under 0.5% of your CPU/Memory, which is trivial.

I like it for conveninece since there's no need to install "agents" or specific client-side software. Any Windows box (Post Win2K) has an RDP client, as do most Linux distros.

Re:XRDP

[Kymermosst]

Windows XP SP3 can't connect to xrdp though. The Windows TS client says "protocol error."

Re:XRDP

[Kymermosst]

Correcting myself. If you look at the devel list, there is a link to a build that fixes it.

SSL-Explorer

[D4C5CE]

If you can't be sure yet what else you might need to export from this machine, in particular for access as a roadwarrior too (just terminals or also file shares to get data into and out of future projects, and possibly even forwarded access to further machines on the LAN?), 3SP's SSL-Explorer might be a good package comprising VNC, RDP etc., console prompts, network paths, web forwards (mostly through a Java helper that runs from many browsers), all encrypted as the name implies, and even more in in its commercial Enterprise Edition, which has a free trial for 2 users as well.

There had been a flurry of versions (all very usable indeed) and lively discussion up until RC19, with the project even proposed for inclusion into Ubuntu, but just before the final release, suddenly not much has been heard from the project since May anymore, and http://www.3sp.com/forums/forums/show/18.page (as well as the fact that http://www.sshtools.com/showSslExplorerCommunity.do now redirects to the commercial version) gets me a bit worried - does anyone have more recent news on this promising project?

SSH (PuTTY) + XMING

[Karem Lore]

Just use ssh with X forwarding through to your box with an XMING (if using windows, or any linux bbox can do this) windows server running on your workstation. Advantage: no xserver running on your crunch machine, good security, simple setup.putty -http://www.chiark.greenend.org.uk/~sgtatham/putty/ Xming - http://www.straightrunning.com/XmingNotes/

You can use screen for your persistance...

Karem

Dont Use Xvnc as a daemon

[nurb432]

The easiest way to get a persistent session is to Use the regular vncserver from a SSH command line.

I do it all the time. I suggest you make sure to enable compression and don't go overboard with graphical apps if you access it from the WAN.

I use....

[whiskey6]

a program called thinstuff www.thinstuff.com I have a similar setup, a server stuffed in the corner with just a couple of NICs and a power cord. I can use RDP on my handy windows lappy to get to said server and my x session is persistent. Licenses are cheap, too.

Here is where microsoft nailed it - remote desktop

[Anonymous Coward]

Microsoft's remote desktop simply works better than anything in the unix world. Screen is wonderful, but if you want to maintain an entire work session state across several locations, nothing beats RDP.

Why hasn't someone made an X server that uses RDP as the graphics device? Xnest is already 99% of the way there. I'd log in, and if I don't have a session it would create one, if I do have one it would reattach to that one, or maybe give me the option to create a new one.

I could use this in a 100% linux environment using rdesktop to connect to the server (instead of using xdm and Xnest, for instance). It would also work really well in a mixed windows/linux environment because I could use the windows remote desktop client to connect to a linux server and use X programs. Lastly, it would be great for POS applications because 99% of thin client systems already use RDP.

lets get cracking!

Answer, and a question...

[PhotoGuy]

I agree, "screen" is the absolute best answer. I've been using it since the early days, and it's only gotten better (split screens, etc.)

My question: I'd like to be able to list the files in a directory. I've been using "echo *", but it's formatting is a little rough. I've also heard of "ls", but I'm unfamiliar with it. Have other Slashdot users encountered this situation?

(Seriously, though, this seems like a pretty light question to warrant a slashdot article. *Any* semi-experienced Unix admin should be intimately familiar with "screen." I wouldn't hire one that wasn't. A google of "terminal unix reconnect" finds it as the first result. Not bashing the original poster, but I'm surprised /. editors approved this. Wait a minute, I must be new here...)

Re:Answer, and a question...

[PhotoGuy]

Also, the poster indicated he had already heard of screen. An "apt-get install screen" and "man screen" would have answered his question pretty quickly.

(On the other hand, I'm such a big fan of screen, having the word spread on it a bit more is for the common good, I guess...)

For text based apps, screen is THE answer

[ivan_w]

I have this application that DOES require a terminal.. And 'screen' has always been my primary choice to run that application unattended (it's served me for that purpose for many years).. The only thing to remember : be careful about "login" and "su" - something to do with ownership of the PTY.. But otherwise, it's a wonder tool ! --Ivan

We have really lowered our standard ...

[GNUALMAFUERTE]

Man ... Xvnc server, screen.

Really, it's not like you are asking for something complex or new or specific. You just throw in the fact that you are doing research in genetic algorithms and somehow think that makes your need for persistent sessions new???

The answer was only one google away ...

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:modify your bash profile

[vlm]

Err forgot about this.... although it should be pretty obvious.

Good luck running emacs without this line:

escape ^zz

in your screenrc. On the other hand you better read the screen man page and understand what that does before you try it.

Personally, I feel control-A is more useful in emacs, etc, than control-Z. Who needs control-Z when you can just open another screen window with a quick "control-Z c"

I have heard of people remapping the screen control key to other keys but people mostly use the default "a" or my choice, "z".

Re:modify your bash profile

[dewarrn1]

I like F12:

escape ""
bindkey -k F2 command

Hardware option?

[Sun.Jedi]

Does the hardware have a console with a network port?

Examples:
- On DELL systems, there are these DRAC cards allowing a https connection to the console.
- On SUN hardware, there is ILOM (x86) and RSC (sparc).
- IBM xSeries has this thing.
- You may be to connect a serial line to ttyA from another server to 'tip' for console, making the security a little easier. See this.
- I'm sure there are others for HP, etc...
- Fancy "KVM swicthes.
- There may even be a 3rd party PCI option

Advantages:
- Console sessions require login/pass (some even accept keys)
- You can set your firewall rule to specific IP endpoints
- Minimal cost
- Minimal techy techy knowledge
- No extra software to install

To solve your 'tail -f' requirement; run nrpe/nagios, or even simpler use *.* @loghost in /etc/syslog.conf and set the correct loghost in /etc/hosts.

I understood that you presently run X11, if that isn't necessary with a hardware option and shipping logs, you may be able to run a straight terminal on the host. Unless, of course, your number cruncher requires it.

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

mingetty + serial cable

[EmagGeek]

That's about as cheap as you are going to get by way of memory and processor time. If you got a halfway decent motherboard, it probably has an option to pipe the console to a serial port with no intervention from the O/S... I had a Tyan TigerMP board that did this back when I was doing computational electromagnetics.

Use NX

[Amamdouh]

NX works great supports ssh and rsa keys for login as well, it was a bit of a hassle to get it working (somehow the latest client for windows does not work with the latest server for linux) so be careful with the version numbers. Definitely worth a trial !!

Re:Here is where microsoft nailed it - remote desk

[florin]

[quote]Microsoft's remote desktop simply works better than anything in the unix world[/quote]

Sadly, you're not wrong, even though many will refuse to admit it. There's a bit of NIH syndrome going on here and also a general lack of understanding why neither X nor VNC are as functional as Remote Desktop.

Sun's Secure Global Desktop (previously known as SCO Tarantella) actually compares really well in the Unix world, but it's payware even if you need just 1 or 2 seats - functionality that is included with the OS with Remote Desktop. Sun, do all of us, Unix and yourself a favor, and give this product away. Sell licenses to compete with Terminal Server and Citrix, not with Remote Desktop. Pretty please :)

Isn't this an ideal case for EC2?

[shis-ka-bob]

I would think that you could just sign up with Amazon and run a virtual linux instance under Xen on their Elastic Compute Cloud. I don't mean to sound like a commercial, but it seems perfect for this sort of number crunching. You start a virtual server, push your code onto it (in a bash script) and you run. If you want to run multiple instances, its just as cheap to run 4 concurrent servers as it would be to run one server 4 times as long. At $0.10/hour, this should be a good deal.

VNC is a "waste"???

[5pp000]

I've used VNC routinely for this kind of purpose for years -- in fact, I do almost all my programming work using it. I have not found it to be a resource hog by any means. Just checking some of my VNC sessions now, resident memory use by the Xvnc process seems to stay between 20 and 60MB. At current memory prices, this is pretty much negligible (and I would assume you have plenty of DRAM on your compute box -- 8GB at least, yes?).

Others have mentioned SSH tunnelling -- I can assure you this is reliable; I've used it day in and day out for years.

Use Screen if you want, but personally I wouldn't even think twice about using VNC.

Step 1: type 'man screen'...

[demontechie]

Spend the few minutes it'll take to learn to use screen. It's absolutely the way to go:

- You won't need to open any extra ports
- All you'll need is an ssh client to get in
- It should already be there and won't require extra software/complexity.

Screen is overkill

[rawtatoor]

detachtty

Looks like i win /. today, yay!\

Shouldn't this be mandatory knowledge?

[vinn]

Wow.. a decade ago knowing about screen would have been pretty common and necessary knowledge. Now we have to Ask Slashdot for instructions for using it?

It seems like we've some how failed in the Linux community to instill this knowledge. Even worse, Soulskill felt that it was important enough to warrant posting to Ask Slashdot.

Don't get me wrong - I don't think we need another tutorial. In fact, quite the opposite. I bet if you put "screen tutorial" into Google it'll come up with tens of thousands of matches. Instead, we really need some way to educate people on using Linux and doing it in such a way that people will actually learn it quickly. It's the million dollar question and I don't think any of us know the answer.

Ironically, the way we've chosen to integrate users into the community is to make all of our concepts like Windows - windowing, mouse events, session initiating, etc. I don't think that's a bad thing at all and anything that expands the community is good. But it also makes people think within the same box they've always known. Linux lets you do a lot of other things - those need to be championed!

(On a side note, I had a Sun engineer explain ZFS to me. Up until then, I had just written it off as another advanced filesystem. Once I 'got it' I realized what a powerful concept it was and how those filesystem changes made me rethink everything I knew about how applications interact with the OS.)

Port knocking

[Helio Campos]

You could use http://en.wikipedia.org/wiki/Port_knocking. It will give you more security.

Get familiar with SCREEN

[KlomDark]

Screen is designed for exactly what you are wanting. I wouldn't look at anything else.

It's easy to use, takes about 5 minutes to figure out how to use it.

Screen rc config file mods

[nkhorman]

Screen is the only way to go for cli persistance.
I've been using it for years now, and would have a hard time going without it.
I always mod the default screen rc by adding the following, it gives you a status bar line at the bottom of your screen to show you what sessions you have running;
startup_message off
shell -$SHELL
shelltitle "\$: |"
caption always "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%"

REALLY old-school and local for text apps

[FranTaylor]

Run getty on a serial port with no hardware flow control. Run a terminal emulator on a laptop. Use a null-modem cable to connect. Unplug when you are done and the session continues to run. Security is either great or it sucks, depending on your situation, because physical access is necessary and sufficient. Very old-school, but cheap and easy. Run screen if you need multiple sessions. Text-only, though.

Screen if you are going with text-terminal.

[bill_kress]

It's 100% exactly what you are asking for. So exact, in fact, that I wonder why somebody didn't just answer you before this even became a story.

Do Not Taunt Screen

[davidpfarrell]

Screen!

        * Warning: Pregnant women, the elderly and children under 10 should avoid prolonged exposure to Screen.
        * Caution: Screen may suddenly accelerate to dangerous speeds.
        * Screen Contains a liquid core, which, if exposed due to rupture, should not be touched, inhaled, or looked at.
        * Do not use Screen on concrete.

Discontinue use of Screen if any of the following occurs:

        * Itching
        * Vertigo
        * Dizziness
        * Tingling in extremities
        * Loss of balance or coordination
        * Slurred speech
        * Temporary blindness
        * Profuse sweating
        * Heart palpitations

If Screen begins to smoke, get away immediately. Seek shelter and cover head.

Screen may stick to certain types of skin.

When not in use, Screen should be returned to its special container and kept under refrigeration...

Failure to do so relieves the makers of Screen, Wacky Products Incorporated, and its parent company Global Chemical Unlimited, of any and all liability.

Ingredients of Screen include an unknown glowing substance which fell to Earth, presumably from outer space.

Screen has been shipped to our troops in Saudi Arabia and is also being dropped by our warplanes on Iraq.

Do not taunt Screen.

Screen comes with a lifetime guarantee.

Screen - ACCEPT NO SUBSTITUTES!

You already asked this question and got answers

[Baloo Ursidae]

Siberian, already asked this question on FurryMUCK in the unixgeeks scream. You were told by all involved to use screen, and exactly how to use it. Grow some balls and listen to the advice you were given.

NetHack!

[Bill, Shooter of Bul]

Most of the distro's packages don't compile screen with the ultra productive nethack option, so you have to compile it yourself.

Re:NetHack!

[empaler]

I'm one of the lucky souls who never found much fun in nethack.

The 'ol ssh -x ??? simple is best!

[mckillnm]

Folks, The best of both worlds... "ssh -x user@machine", now you have a term window.. if you run any X aps, they will appear on the host machine. I would only use VNC going from a Windows box. -Marko

Screen+SSH+VNC

[Sedennial]

If you have the skillset to build and maintain such a box as you've described, frankly I'm slightly surprised that you are asking this question. Use SSH (Cygwin+SSH or Putty if you run windows on the far side) for your remote connections and tunnel your VNC connection through your SSH. Use screen to maintain your CLI/term windows.

Problem solved. I would expect that with minimal reading you should be able to become comfortable with this in less than a day.

Use a suitable virtual machine...

[Thunderbear]

I'd suggest using a virtual machine, with a suitable (for you) interface.

vmware player/workstation can connect over the network, virtualbox has a remote desktop interface to its console, etc.

Otherwise Xvnc might be just right for you

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

[poopdeville]

Okay then -- how would you go about installing Linux on a PowerPC laptop with a working DVD drive but a broken screen? No, using a DVI adapter and an external monitor did not work. I will consider any distribution, but would strongly prefer something Debian-based. (A Gentoo derivative would be preferred as well, from an administrative standpoint, but I would rather not compile shit in the middle of a heat wave.)

Re:RDP FTW

[NoOneInParticular]

Although good, RDP is just too expensive. First you have to port all your applications to their proprietary framework to be able to run over RDP. Luckily there is some gcc support for that, but still. Then you have to buy the license. That one is not too steep, but is single user. If you want multiple users to use RDP on the same box, with session persistence, you will have to buy the much more expensive server version of RDP, for which you pay per user. And even then, you are stuck with one persistent RDP session per user.

No, I guess VNC is still the better option.

Use xwin to reconnect sessions

[trevnick]

Xwin32 from Starnet has a feature (requiring a special install on the unix side I believe) that allows you to reconnect to existing session.

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.

Don't need to open VNC port in the firewall

[MrCreosote]

First, make sure VNC only accepts connections from its localhost. Then port-forward the VNC port in your ssh session and connect your vnc client to the forwarded port on your client's localhost.

SCREEN and XMOVE

[ratboy666]

SCREEN for persistent terminal connections,
XMOVE for X programs (although xmove is a bit of a bear to use, and is suffering a slight case of bitrot) ftp://ftp.cs.columbia.edu/pub/xmove/
VNC is probably a better choice for "generic" use.
VNC can be tunneled through SSH, which is better than opening a port for it (by itself, VNC isn't secure).

Hope this helps.

Re:SCREEN and XMOVE

[TerranFury]

Have you (or anyone) found a way to get XMOVE to work with MIT MAGIC COOKIE authentication? Or working with SSH X-forwarding? I can't seem to get that to work.

Re:SCREEN and XMOVE

[ratboy666]

No, I haven't ever figured it out -- I'll consider forking xmove and x2x, and doing a bit of maintaining. The largest issue is access to "off-brand" X servers for testing. As a general question: is this something that others want?

My experience: I worked on the Hummingbird X Server for Windows, including LBX proxy; but haven't been in the space for a decade. I would like generic xmove/x2x myself, I just want to know if its worth something to anyone else. I would need "off-brand" testing with other PC X Servers, Mac X Server, HP, IBM, old DEC. I work with SUN kit all day, and Xorg, but don't have easy access to XFree86. Send me email at fred_weigel@hotmail.com if you are interested, and have access to those X Servers, and are capable of using tunneling with ssh.

VNC made easy

[ClarisseMcClellan]

So the number cruncher sits in the corner, not a million miles away on the interwebs. I recommend using X-window and the standard VNC options built into your distro. With RH/fedora go to System -> Remote Desktop and set the appropriate options. Then go to your notebook/other PC and then vnc onto it. This all works fine and provides the persistent desktop. Even better, it takes two minutes to setup.
Clearly you can also put the server on the internet and use the SSH options listed above, getting rid of SSH 1.0 if you want to be paranoid about man-in-the-middle attacks.
Another thing that you might want to consider is running VNC-reflector on another server. This will enable you to record all of your VNC sessions. This is most useful if you cannot remember what you did - just 'play' the VNC data recording back and watch what you did.

Eggdrop!

[nhtshot]

I'll echo all the praise for Screen, it really is a great tool. That brings me to the reason that most of us know about it.

It was the best way to set up egg-drop bots back in the old days.

Linux a Windows Remote Desktop Termianl Server?

[Bulldozer2003]

FreeNX seems nice, but in my experience your connections are only persistent on the remote host you used. Go use another host to login and you get a new session! RD allows you to lock your session, logout, and log into that session on another box...

"heard of screen"

[Gothmolly]

...but am unfamiliar with it...

Ah, the signs of our times. I must be getting old. I bet you don't know what rn is either.

why do you need X?

[mnslinky]

Screen or tmux is a great persistent terminal. If you're going to go down the xvnc route, don't expose VNC to the world, even on a different port. Tunnel this over ssh with a command similar to the following:

ssh -l username -L 5900:hostname:5900 hostname cat -

This will give you a terminal the nothing on the screen (ctl-c will end the tunnel). From this point on, simply VNC to your local system's port 5900 and it'll get tunneled to the remote hostname's port 5900.

man ssh for more information.

XDMCP anyone?

[flnca]

Why not just run "xdm" or other XDMCP compatible display manager on the box? Then you can log in remotely via Exceed , Cygwin/X (on Windows) or similar tools with built-in XDMCP browser. (See also: Linux XDMCP How-To) -- With XDMCP, you can have full access to a Linux (or other Unix) desktop.

vnc server

[Cylix]

I have multiple vnc sessions specified attached to specific users.

It's fairly straight forward, just vnc in to the host:1 or host:2 (ultravnc supports this behavior) and bammo. I'm not sure how to get any more persistent.

I have no idea how well this scales, but it currently supports 3 people just fine.

If it's going to be accessible to the world, you may want to insert your favorite ACL's combined with a tasty dash of vpn. (ala ssh tunneling or any other setup of your voice)

Of course I use screen for console!

Yep, screen.

[norova]

Yeah "screen" all the way for text-based / curses based things. On another note... I'm curious if there are any projects or anything I could use my extra linux machine for as far as number-crunching goes. I don't have any research to be doing myself, but the box is on 24/7 and doesn't really do much. It bothers me to have all of those unused CPU cycles.

Re:Yep, screen.

[Gori]

There is always http://www.worldcommunitygrid.org/ Pick a project you like and crunch away...

Re:Yep, screen.

[norova]

There is always http://www.worldcommunitygrid.org/ Pick a project you like and crunch away...

Fantastic. Thank you!

Try NX-server from No-Machine

[masikh]

Hi, Being a sysadmin at a univ. I had encountered this problem before. The solution is twofold: Screen and No-machine's NX server. The latter is a Xvnc like connection based on ssh. It works fast (very usable on a xDLS) and save due to ssh. Have a nice day!

Re:Here is where microsoft nailed it - remote desk

[masikh]

Take a look at NXserver from No-machine

screen, xmove and recon-x

[spinctrl]

screen is possibly the most underrated GNU tool ever. I could never do without it, but I'm amazed by how many "seasoned" sys admins don't use it. You can learn to use screen in a day -- Ctrl-A and ? will help. I change this keyboard binding with the "escape" command, since I'm a bash user.

Start your screen sessions from the console when you boot the box, then attach to it under X and remotely over Ssh.

Unfortunately screen does not solve the problem of persisting X-windows applications, and if you use an server over Wifi, this can be a real problem. Try xmove, though it doesn't cope well with loss of connectivity. There's a little tutorial here.

There is a commercial app called Recon-X, which I haven't had a chance to try and would like to know of any FOSS alternatives. Check the product page here.

Not quite expected...

[BloodyIron]

I've used XRDP in some instances. I am not certain how big of a resource footprint it has, but it is worth looking into.

Re:Here is where microsoft nailed it - remote desk

[laddiebuck]

I've used VNC (TightVNC) heavily a few years ago (before I went completely text-mode) and I can recall that though it was annoying to have a speed lag, it was still perfectly usable, and I used it a lot.

During that time, I was also given access to a Windows box via RDP, from a Windows client. It was on the same pipe, but what struck me was how awfully, awfully slow it was. I could watch the mouse trails crawl across the desktop. Obviously, they may have improved their compression over the past few years.

Getting back to screen though, I think it would be very difficult to argue that any product, from any computing world, even approaches it in terms of features and power. I don't know what you mean by "maintain an entire work session state across several locations", but if you mean accessing a remote session, then sure screen can do that. You can also use the session from multiple locations at once, it has a built-in window manager, it can monitor windows, filter the output or input of windows into pipes, keep and search (vi-style) the scrollback buffer, etc. A lot of its power is admittedly due to the fact that text is inherently more flexible and simple than graphical widgets. You can't, for instance, filter the output of an arbitrary (say, non-modifiable) application in a GUI without a hideous amount of pain and effort (basically by converting it to text). I can access my screen session using just a javascript-enabled browser, for instance (anyterm and ajaxterm).

These are just some reasons I went text-mode. I just found replacements for all the last graphical apps I had been using (firefox->elinks, gaim->irssi/bitlbee) and in a few weeks I was more productive than I had been before.

Try Starnet's XWin32?

[rivimey]

You could look at Starnet's XWin32... I don't know whether it's any good, and it's also payware, but the latest versions support suspend/resume of sessions which seems to be what the poster wants.

Re:Here is where microsoft nailed it - remote desk

[WuphonsReach]

During that time, I was also given access to a Windows box via RDP, from a Windows client. It was on the same pipe, but what struck me was how awfully, awfully slow it was. I could watch the mouse trails crawl across the desktop. Obviously, they may have improved their compression over the past few years.

I suspect that you may have had 15/16/32 bit color enabled then.

Comparing RDP vs VNC for the same color-depth, you'll find that RDP is simply a lot more responsive over the same connection.

(I've been using both for quite a few years now.)

http Server and a CGI

[Boaz17]

I would just Cooke up a simple cgi script. Some thing like: http://www.icthus.net/CGI-City/scr_cgicity.shtml#COMMANDER

If you have some scripting skills I would go for an http server like apache + CGI. you can also use ssh tunnel and load apache on localhost only.
no need for X or any thing like that. OK You will need the offscreen X for wine.