Slashdot Mirror
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?"
For your standard persistent terminals, SCREEN is really your best bet
Captain Obviousman.
The Raven
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.
Use the free, NX server from nomachine.com. Works great, high performance and session disconnection/reconnection ability.
Yum distro:
yum install screen
man screen
Apt distro:
apt-get install screen
man screen
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
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.
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.
SIG: 11
The usefulness of screen cannot be overstated.
Use screen. Ocams razor approach...
Use screen for terminals. x11vnc for GUI. x11vnc can be run over encryption. Look at http://www.karlrunge.com/x11vnc/ for more info.
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
we use nomachine for this, you can try the free edition: http://www.nomachine.com/select-package.php?os=linux&id=1
If you don't *require* X11, try screen. It's simple and lightweight.
http://wiki.redbrick.dcu.ie/mw/Screen
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.
http://libcaca.zoy.org/wiki/neercs
Keep it simple - this is what screen was meant for. Install it and read the man page, it's really easy to use.
Moral indignation is jealousy with a halo - H. G. Wells
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
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
vncserver :1 -name parngr -geometry 1024x768 -depth 16
You should really check out screen, because that's exactly what you are looking for!
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:
Voila: VNC connection, secured by SSH. When you are done just
. :1 VNC session, 5902 means :2, etc.
Note that 5901 means the
Try conspy, very handy utility.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
If your needs for number crunching are purely that, I wouldn't add any overhead at all for this, but run a script on the client side (your main computer) to suck results back to your machine. Unless you're running real time visualized simulations, there probably isn't a necessity for what you state anyhow.
I used to work with GA based algorithms (I didn't research them, just tested them for my uses), and one thing at the time that I did was run a PowerMac G5 headless. Basically, everything that could be turned off was turned off, memory was beefed up to the max, and it just ran. Of course, at the time, a single session was something like 8 hours of straight computing, so I would usually just check in via ssh once in a while to see if it was done. I would still need to log in to see how things were doing, or stop a session mid-way to check results etc., but this was all accomplished via SSH. If I were to do it again, I would probably use the same setup. Even with today's computing power, GA and other algorithms still tend to require a huge amount of computing power for complex problems, so I would want to dedicate as much power as possible to the problem, and bear the burden of access.
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
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 ;-)
-- All that's left of me, is slight insanity, whats on the right, I don't know. -- Bob Mould
Read about detaching screen sessions.
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.
I'm a CLI bigot, so I love screen. I do much of my work over a VPN, so screen is essential so I don't lose my place when routes flap or something. I find it's much better than the 'nohup; tail -f' method.
Once catch is that CTRL-a is the default screen metakey, which collides with the bash emacs-mode start-of-line. I change that to CTRL-n in my ~/.screenrc, though CTRL-[ might also be a good choice (never tried it).
Screen is also useful for training/t-shooting, when you set up it as multi-user.
I wrote a couple of recipes about it in O'Reilly's _bash Cookbook_ if you have that laying around. (And if you don't, why not?!? :-)
-JP
i'd go for 'screen' too for the persistent terminal sessions...sincerely u dont even need to read the manual
just prepend 'screen' in any command that you would normally type in a console window ... the terminal will spawn another terminal (running on top of the first - NOT in a separate tab or smth) and the command will then be executed.
you can then detach the session by pressing ctrl-A then D... and you'll be back to the previous session..
if you want now to check back the progress of your execution do 'screen -ls'
and then 'screen -r '
thats it..
i use it mostly to run rtorrent - a command line torrent client
and occasionally for some long 'wget's
note that once the execution of the program terminates.... the screen session that you have spawned will be terminated too... so remember to redirect any final output to a file too in order not to miss it :)
btw, i would hardly call the use of Xvnc 'resource hungry'.. i mean first make sure that your code uses threads to fully utilise ur 4 processors!
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.
All code except system calls runs natively, and therefore just as fast as native code.
VNC probably doesn't use much memory or CPU time when it's not active. Do a benchmark.
"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!"
Why on earth would you open the VNC port in your firewall? Just tunnel through SSH. The TightVNC client has that builtin, just use the -via option.
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
dtach -A /tmp/session1
[ do some work and type Ctrl-\ to detach ]
dtach -A /tmp/session1
[ continue where you left off ]
Screen is definitely what you want. Its always the first thing I install on my new lab machines.
I have been using screen for a couple of years now.
I use it on a daily basis to access my desktop station or computing servers at work from home (or wherever I am) through a ssh session when I want to launch jobs requiring quite a long time to complete.
This allows (among others):
1/ not to fear ssh connection drops. If the connection drops, your shell just continues to work on the distant machine. You can reconnect to it whenever the network is back on track.
2/ I can start a job while at work in a screen terminal. Then I detach it. Go back home, ssh, log back and reattach the terminal. Therefore I can keep on monitoring the task I launched.
I kept logged through the same screen session on servers for weeks without any problem so far.
Screen doesn't provide x11 session afaik, however, it is a very reliable, simple and light tool I just couldn't live without.
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...
...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 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.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
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.
If you don't mind Microsoft, server 2008 with Hyper-V (still in beta) takes up very few resources, and RDP is the best remote protocol that I have ever delt with. ever. Low bandwidth and all you have to do when you are done is close the application and your programs continue to run.
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.
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.
I use the same on my home box. I setup kdm to automatically log my default user in right after startup, and put this
.kde/Autostart/x11vnc /usr/bin/x11vnc -forever -nopw; sleep 10; done) &
s2@fresh:~$ cat
#!/bin/bash
(while true; do
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.
I just don't trust anything that bleeds for five days and doesn't die.
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.
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.
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?
You can use screen for your persistance...
Karem
When all is said and done, nothing changes...
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.
---- Booth was a patriot ----
What is this for a joke!!!??? Are we going to read more of this stuff on Slashdot? I thought this used to be a news filter/aggregator + discussion site not a discussion board for dummies.
Horse shit.
You mean your applications are sooooo performance critical that running them on a homemade x86 box is ok, but you're concerned about how many resources vnc takes up? Nice troll.
I'd love to see a "ps -ef", "lsof" and "cat /proc/meminfo" of that box.
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.
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!
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...)
Love many, trust a few, do harm to none.
Altera and Xilinx have software that run under Linux. Why do you need WINE? Is there another FPGA vendor that makes usable circuits? :-)
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
Gui solution:
Client script (if windows use cygwin):
- start local x client
- ssh to the dedicated server with X11 forwarding
and using keys (no password needed)
On the dedicated server: .profile .xinitrc if needed
- put startx or xinit in your
- edit
Voila, no login needed and X at your disposal.
Screen is the perfect terminal session tool !
You could think about changing ssh for persistent connections.
Nice and easy due to the wonderfullnes of good unix standards
(where is the inittab in Ubuntu aaarrrggghh, damn event.d !!!!!, going to start a topic about that one of these days)
Greets
Joe Swampfoot
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 ...
WTF am I doing replying to an AC at 5 A.M on a Friday night?
dtach is a lightweight alternative to screen.
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 .... you get the idea ..... ... etc ...
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
bindkey -k k; select 110
bindkey -k F1 select 11
bindkey -k F2 select 12
Oh and set a useful caption line too.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Does the hardware have a console with a network port?
/etc/syslog.conf and set the correct loghost in /etc/hosts.
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
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.
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
By and large, language is a tool for concealing the truth. -- George Carlin
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.
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 !!
[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 :)
ssh -X for the occasional X redirect and screen for everything else.
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.
Think global, act loco
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.
Your god may be dead, but mine aren't!
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.
why not use some sort of application framework to run your processes where you use a web interface to check status and output? such as Zope or Grok
These are just some of my favorites.
Any framework could be good, but you could use supervisord to detach your process from the terminal.
One word of warning: if you use emacs under screen's default key bindings, all hell is going to break loose rather quickly.
detachtty
Looks like i win /. today, yay!\
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.)
----- obSig
You could use http://en.wikipedia.org/wiki/Port_knocking. It will give you more security.
since you're too much of a neophobe to learn screen, these require no new software learning at all, and they're completely intuitive. and totally retro style, d00d, almost steampunk, I hear that's all the rage with the kids these days...
http://en.wikipedia.org/wiki/ASR33
or
http://www.columbia.edu/acis/history/la36.html
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 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%"
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.
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.
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!
Cube On! (http://stores.ebay.com/PuzzleProz)
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.
Help us build a better map!
Most of the distro's packages don't compile screen with the ultra productive nethack option, so you have to compile it yourself.
Well.. maybe. Or Maybe not. But Definitely not sort of.
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
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.
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
--
Thorbjørn Ravn Andersen "...and...Tubular Bells!"
I third..or tenth.. that. screen for terminal apps. "screen -d -r" to reattach to your detached session. And "Control-A foo" to do things in screen. Values for "foo" that I use are:
Control-A (that is ctrl-a ctrl-a) types literal control-a (for minicom or the like that you have to type control-a for.)
c creates a new screen
n goes to next screen
p goes to previous screen
0-9 go to screens 1 to 9
d detaches (exits screen while keeping your sessions going) -- or you can quit ssh (or have it bail) and the sessions also stay up.
? shows a help screen.
Oh I forgot -- you can cut and paste, and scroll back!
escape goes to copy'n'paste mode. vi-stle ijkl are arrows, OR the arrow keys, pageup, pagedown, etc work too. spacebar to start selection, arrow to the end of your selection and press space again. Then Control-A ] pastes that back in. If you don't want to copy-and-paste, hit escape, scroll back, and hit escape (or most non-arrow keys) and it says "copy mode aborted".
VNC? I've already seen a post telling how to run ssh with port forward commands. As they say, vnc screen :0 is port 5900, :1 5901, etc.
I have used x11 forwarding as well, for that I recommend telling ssh to do compression (-C option, or edit ssh_config), X11 was originally designed for 25mhz or less machines on 10mbit ethernet, it doesn't compress a thing on it's own, so ssh can probably shrink your X11 stream by over 90%.
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.)
After all, I am strangely colored.
Xwin32 from Starnet has a feature (requiring a special install on the unix side I believe) that allows you to reconnect to existing session.
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.
xkcdsw: the unofficial archive of Making xkcd Slightly Worse
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.
MrCreosote Meow!Thump!Meow!Thump!Meow!Thump! "You're right! There isn't enough room to swing a cat in here!"
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.
Just another "Cubible(sic) Joe" 2 17 3061
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.
screen is a vulnerability-ridden chunk of bloatware.
Check out tmux instead.
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.
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...
...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.
I want to delete my account but Slashdot doesn't allow it.
If FPGA synthesis is your only problem, and you are using Xilinx's tool set, they run natively under linux. In fact, I have found that they work better run from the command line then run from the ISE GUI. If you tell ISE to build an FPGA, it creates a log of all the command being run. It is easy to add and remove files from the design, all the source files are listed in a text file.
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.
I'm not much of a linux person but remote desktop (or RDP) is simply fantastic. Encryption is even built in but you CAN run it over a secure protocal if you really want to.
I was under the impression that X was the best thing since sliced bread because you could route the display anywhere you wanted. I don't know the terminology but what is the big deal with having X draw the screen over a remote connection and sending vectors or bitmaps as needed? Isn't that what it's designed to do? Too much bandwidth?
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.
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!
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
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.
screen is good for basic terminal stuff, but check out twin (text mode window manager, twin.sf.net). you can have many terminals open in managable windows, and de-tach like screen as well. its like screen on crack.
Xrdp exists.
Sun Secure Global Desktop, aka Tarantella, yeah it's not open, but its not expensive compared to Windows either.
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!
Take a look at NXserver from No-machine
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.
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.
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.
google for xrdp
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.
Ruth Ivimey-Cook
Software Engineer and Author
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.)
Wolde you bothe eate your cake, and have your cake?
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.