I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
On Thu, Mar 3, 2011 at 2:36 PM, Sean Carolan scarolan@gmail.com wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
You wouldn't by any chance be using PuTTY to access the session? If so, you may need to play around with the terminal settings including the scroll type so that it displays correctly. I don't recall the specifics but a similar thing happened to me.
You wouldn't by any chance be using PuTTY to access the session? If so, you may need to play around with the terminal settings including the scroll type so that it displays correctly. I don't recall the specifics but a similar thing happened to me.
Actually, no I'm using gnome-terminal on Ubuntu 10.10. I wonder if it's due to the fact that I'm ssh-ing to other machines within each screen window? Sometimes I will do this if I have a dozen servers to work on at the same time, I have a little script that spawns a new ssh session to each box in separate windows. Here's a little tidbit that I just learned; you can send the same command to all windows at the same time:
[CTRL-A] :at # stuff "pwd; hostname; uptime^M"
That will send the pwd, hostname, and uptime commands to all windows. YMMV.
On Thu, Mar 3, 2011 at 4:10 PM, Sean Carolan scarolan@gmail.com wrote:
You wouldn't by any chance be using PuTTY to access the session? If so, you may need to play around with the terminal settings including the scroll type so that it displays correctly. I don't recall the specifics but a similar thing happened to me.
Actually, no I'm using gnome-terminal on Ubuntu 10.10. I wonder if it's due to the fact that I'm ssh-ing to other machines within each screen window? Sometimes I will do this if I have a dozen servers to work on at the same time, I have a little script that spawns a new ssh session to each box in separate windows.
[...]
Yes, this is probably the reason. I would guess that you see the same behavior if you are directly sshed into a server not going through screen. My guess is that since screen isn't running directly on the host creating the output, it cannot reflow correctly since that output has already been printed out.
You can see this on a raw ssh session (no screen) if you run "ls -l" on a really small window (40 chars wide) and then resize it. The 'ls' output will not automatically rewrap itself. If you then try the same experiment when running screen, after you resize the output will rewrap correctly.
on 13:36 Thu 03 Mar, Sean Carolan (scarolan@gmail.com) wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
Is your local terminal type known to all remote systems (in termcap)?
I find I have to re-map $TERM to some low-common standard (e.g.: xterm) on many systems. Legacy Unix vendors being the most eggregious for this.
You can test $TERM compatibility in your shell login:
tput -T $TERM init >/dev/null 2>&1 && echo yes || echo no
In this case, you might want to conditionally assign some reasonable value on failure. Say:
tput -T $TERM init >/dev/null 2>&1 || export TERM=xterm
'tset -q' is another test which can be used.
On 3/3/2011 3:34 PM, Dr. Ed Morbius wrote:
on 13:36 Thu 03 Mar, Sean Carolan (scarolan@gmail.com) wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
Is your local terminal type known to all remote systems (in termcap)?
I find I have to re-map $TERM to some low-common standard (e.g.: xterm) on many systems. Legacy Unix vendors being the most eggregious for this.
I tried to forget the incompatibilities in different old terminal types after about everything settled on xterm compatibility. Instead of running screen, can you run a desktop session under freenx on a server somewhere and run everything in terminal windows there (even ssh sessions that go elsewhere)? If you haven't tried it, the NX client has great performance with freenx, even remotely, and lets you disconnect/reconnect with everything still running. Assuming you have something locally that can run the NX client (windows/mac/linux) you also get mouse based cut/paste and the only down side is a slightly longer time to do the initial screen refresh when you connect.
I tried to forget the incompatibilities in different old terminal types after about everything settled on xterm compatibility. Instead of running screen, can you run a desktop session under freenx on a server somewhere and run everything in terminal windows there (even ssh sessions that go elsewhere)? If you haven't tried it, the NX client has great performance with freenx, even remotely, and lets you disconnect/reconnect with everything still running. Assuming you have something locally that can run the NX client (windows/mac/linux) you also get mouse based cut/paste and the only down side is a slightly longer time to do the initial screen refresh when you connect.
Hmm, this sounds like an interesting possibility. I don't think we have x-windows installed on any of our server machines but I can look into it. You have gotten the gist of my thoughts here though; being able to return to something I was working on before, without having to log onto every machine again!
on 16:07 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 3:34 PM, Dr. Ed Morbius wrote:
on 13:36 Thu 03 Mar, Sean Carolan (scarolan@gmail.com) wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
Is your local terminal type known to all remote systems (in termcap)?
I find I have to re-map $TERM to some low-common standard (e.g.: xterm) on many systems. Legacy Unix vendors being the most eggregious for this.
I tried to forget the incompatibilities in different old terminal types after about everything settled on xterm compatibility. Instead of running screen, can you run a desktop session under freenx on a server somewhere and run everything in terminal windows there (even ssh sessions that go elsewhere)?
No xlibs on our servers.
On 3/3/2011 4:19 PM, Dr. Ed Morbius wrote:
on 16:07 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 3:34 PM, Dr. Ed Morbius wrote:
on 13:36 Thu 03 Mar, Sean Carolan (scarolan@gmail.com) wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
Is your local terminal type known to all remote systems (in termcap)?
I find I have to re-map $TERM to some low-common standard (e.g.: xterm) on many systems. Legacy Unix vendors being the most eggregious for this.
I tried to forget the incompatibilities in different old terminal types after about everything settled on xterm compatibility. Instead of running screen, can you run a desktop session under freenx on a server somewhere and run everything in terminal windows there (even ssh sessions that go elsewhere)?
No xlibs on our servers.
You need _a_ machine somewhere that can host a freenx session. It doesn't need to be the target of the ssh connections, just something that will mostly stay powered up if you want the session to stay active all the time. A development box or even a VM session that would work - or a desktop machine if it stays on all the time. It doesn't even have to run X on its own console.
on 16:30 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 4:19 PM, Dr. Ed Morbius wrote:
on 16:07 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 3:34 PM, Dr. Ed Morbius wrote:
on 13:36 Thu 03 Mar, Sean Carolan (scarolan@gmail.com) wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I
Is your local terminal type known to all remote systems (in termcap)?
Instead of running screen, can you run a desktop session under freenx on a server
No xlibs on our servers.
You need _a_ machine somewhere that can host a freenx session. It doesn't need to be the target of the ssh connections, just something that will mostly stay powered up if you want the session to stay active all the time. A development box or even a VM session that would work - or a desktop machine if it stays on all the time. It doesn't even have to run X on its own console.
Frankly, given the alternative ease of automatically redefining $TERM, that strikes me as a slightly overengineered solution.
Not that I'm intrinsically opposed to overengineering.
On 3/3/2011 4:36 PM, Dr. Ed Morbius wrote:
Instead of running screen, can you run a desktop session under freenx on a server
No xlibs on our servers.
You need _a_ machine somewhere that can host a freenx session. It doesn't need to be the target of the ssh connections, just something that will mostly stay powered up if you want the session to stay active all the time. A development box or even a VM session that would work - or a desktop machine if it stays on all the time. It doesn't even have to run X on its own console.
Frankly, given the alternative ease of automatically redefining $TERM, that strikes me as a slightly overengineered solution.
Not that I'm intrinsically opposed to overengineering.
Don't knock it until you've tried it. A full GUI desktop, even mostly hosting a bunch of terminal windows is a lot more comfortable place to work than a screen session, and mousable cut/paste that works even with the local OS running the NX client is extremely handy (how many times do you do the same command on several machines?). I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
on 16:50 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 4:36 PM, Dr. Ed Morbius wrote:
Instead of running screen, can you run a desktop session under freenx on a server
No xlibs on our servers.
You need _a_ machine somewhere that can host a freenx session. It doesn't need to be the target of the ssh connections, just something that will mostly stay powered up if you want the session to stay active all the time. A development box or even a VM session that would work - or a desktop machine if it stays on all the time. It doesn't even have to run X on its own console.
Frankly, given the alternative ease of automatically redefining $TERM, that strikes me as a slightly overengineered solution.
Not that I'm intrinsically opposed to overengineering.
Don't knock it until you've tried it. A full GUI desktop, even mostly hosting a bunch of terminal windows is a lot more comfortable place to work than a screen session
I use screen *very* extensively, including locally. It works quite well.
I run Linux locally, not just remotely.
and mousable cut/paste that works even with the local OS running the NX client is extremely handy
I've got that natively via X11.
(how many times do you do the same command on several machines?).
for host in <list>; do ssh $host 'commands'; done dsh hostgroup 'commands'
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
What's your desktop system?
I'm living in X11 on a laptop with good suspend/restore. A new terminal is hotkeyed, so no mousing around to get that. If I'm on a host frequently I'll generally have a screen session or several running there. Few if any remote clients have any X support. Works pretty well for me. There's no win (in this case) for freenx.
I meant to note earlier: the upstream NX developers have gone non-free, no? Is there a free software development branch?
On Thu, 3 Mar 2011, Dr. Ed Morbius wrote:
(how many times do you do the same command on several machines?).
for host in <list>; do ssh $host 'commands'; done dsh hostgroup 'commands'
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
What's your desktop system?
OP might want to look into cssh (cluster ssh) or pconsole or the multi-window control capabilities of the various terminal emulation programs as well. I know the kde variant has an "echo to all tabs" setting and believe the gnome one does as well.
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.net "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
On 3/3/2011 5:49 PM, Dr. Ed Morbius wrote:
Not that I'm intrinsically opposed to overengineering.
Don't knock it until you've tried it. A full GUI desktop, even mostly hosting a bunch of terminal windows is a lot more comfortable place to work than a screen session
I use screen *very* extensively, including locally. It works quite well.
I've forgotten - does a vi session in screen window resize correctly like it does in an xterm if you want to change it?
I run Linux locally, not just remotely.
NX works on Linux too. But 'locally' to me means a bunch of different machines.
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
What's your desktop system?
Mostly windows at work, mac at home, but sometimes I'll be at a linux console and pick up the session there too.
I'm living in X11 on a laptop with good suspend/restore. A new terminal is hotkeyed, so no mousing around to get that. If I'm on a host frequently I'll generally have a screen session or several running there. Few if any remote clients have any X support. Works pretty well for me. There's no win (in this case) for freenx.
I can do pretty much everything you can do in the desktop session. Playing video isn't great, but it would be hard to tell the difference for about anything else. The difference is that mine keeps running while my laptop is suspended or I've disconnected with no need to start a screen session separately for long-running jobs. And I can grab the session from the mac at home if I don't want to use the laptop.
I meant to note earlier: the upstream NX developers have gone non-free, no? Is there a free software development branch?
I don't think so for the next version - but the current one does everything I need.
on 18:10 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 5:49 PM, Dr. Ed Morbius wrote:
Not that I'm intrinsically opposed to overengineering.
Don't knock it until you've tried it. A full GUI desktop, even mostly hosting a bunch of terminal windows is a lot more comfortable place to work than a screen session
I use screen *very* extensively, including locally. It works quite well.
I've forgotten - does a vi session in screen window resize correctly like it does in an xterm if you want to change it?
Yes. Assuming your termcap library/ies are consistent.
I run Linux locally, not just remotely.
NX works on Linux too. But 'locally' to me means a bunch of different machines.
I'm aware of that. However the power of tunneled X sessions (when necesary) and ssh (when not) makes having a full-desktop tool (NX, VNC, etc.) markedly less attractive.
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
What's your desktop system?
Mostly windows at work, mac at home, but sometimes I'll be at a linux console and pick up the session there too.
That would explain a lot of your perspective.
On 3/3/2011 6:46 PM, Dr. Ed Morbius wrote:
NX works on Linux too. But 'locally' to me means a bunch of different machines.
I'm aware of that. However the power of tunneled X sessions (when necesary) and ssh (when not) makes having a full-desktop tool (NX, VNC, etc.) markedly less attractive.
Oh - NX runs entirely over ssh in the default setup. You don't need any other ports and the whole session is encrypted. Plus it gives reasonable performance over high latency and low bandwidth connections.
And you can still tunnel 'other' X windows into your freenx desktop if you want - it is just a normal X session on that end.
on 19:21 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/2011 6:46 PM, Dr. Ed Morbius wrote:
NX works on Linux too. But 'locally' to me means a bunch of different machines.
I'm aware of that. However the power of tunneled X sessions (when necesary) and ssh (when not) makes having a full-desktop tool (NX, VNC, etc.) markedly less attractive.
Oh - NX runs entirely over ssh in the default setup. You don't need any other ports and the whole session is encrypted.
It's not the ports. It's the graphical presentation. Oh, and I've run NX.
I'm really just fine with terminal windows and SSH-forwarded apps if those are necessary.
I don't keep enough state running remotely to make it worth my time to have another level of nested desktop cruft to deal with. Ties up too much real-estate for no win. As I've noted several times: I've already got SSH local/remote. For NX I'd have to install clients and servers, and X libraries. For something I really don't want or need in the first place.
While I could see the value for someone /not/ running a native Linux desktop environment. I'm /not/ trying to change your mind about anything, maybe just open it up a tad to see my PoV.
I believe I've talked myself in a circle at least once, and we're pretty far from anything particularly CentOS related.
On 3/3/11 7:48 PM, Dr. Ed Morbius wrote:
It's not the ports. It's the graphical presentation. Oh, and I've run NX.
I do like the way gnome collapses the icons in the task bar when you have enough of them - and pops up the list so you can see it. It makes it easy to find the terminal session connected to some particular remote host.
I'm really just fine with terminal windows and SSH-forwarded apps if those are necessary.
But why do you need screen, then?
I don't keep enough state running remotely to make it worth my time to have another level of nested desktop cruft to deal with. Ties up too much real-estate for no win. As I've noted several times: I've already got SSH local/remote.
I don't think of it as a remote desktop - it's 'my' desktop. It just goes where I go with everything still running.
For NX I'd have to install clients and servers, and X libraries. For something I really don't want or need in the first place.
That makes it sound complicated. It's really just having what you have on your current desktop running in a freenx session and connecting from a client wherever you are.
While I could see the value for someone /not/ running a native Linux desktop environment. I'm /not/ trying to change your mind about anything, maybe just open it up a tad to see my PoV.
Having cut/paste access between applications on different OS's is a plus, but the real benefit is always having access to the same desktop that almost never stops. And no need to run something like screen. I do run a separate session in a remote office as well for better connectivity to machines in that location and a few others for special purposes, but I prefer it even for the main way I access a local machine.
on 21:24 Thu 03 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/3/11 7:48 PM, Dr. Ed Morbius wrote:
I do like the way gnome collapses the icons in the task bar when you have enough of them - and pops up the list so you can see it. It makes it easy to find the terminal session connected to some particular remote host.
WindowMaker has a windowlist. Even better. I usually last 1-4 hours when I periodically try GNOME. KDE and XFCE I might last a few days. Then it's back to the One True Window Manager.
I'm really just fine with terminal windows and SSH-forwarded apps if those are necessary.
But why do you need screen, then?
Terminal multiplexing, session persistance, scrollback/logging, split screen (top running in the top panel, shell underneath, etc.), workflow organization (similar processes are grouped in a screen session).
I'm writing this mail in mutt, in a screen session with multiple mailboxes open, each to its own screen window. It's like a multi-tabbed GNOME or KDE terminal, except that the session persists even if the controlling terminal is killed, or X dies altogether.
Screen is one of those amazingly powerful Linux tools, once you stumble across it.
On 3/4/11 12:15 AM, Dr. Ed Morbius wrote:
I do like the way gnome collapses the icons in the task bar when you have enough of them - and pops up the list so you can see it. It makes it easy to find the terminal session connected to some particular remote host.
WindowMaker has a windowlist. Even better. I usually last 1-4 hours when I periodically try GNOME. KDE and XFCE I might last a few days. Then it's back to the One True Window Manager.
I don't care about the mechanism so much as having everything I do on one screen, under one window manager. So all of my terminal sessions collapse in one place that becomes a popup list. Likewise all of my firefox windows (and for this reason I like separate windows better than tabs).
I'm really just fine with terminal windows and SSH-forwarded apps if those are necessary.
But why do you need screen, then?
Terminal multiplexing, session persistance, scrollback/logging, split screen (top running in the top panel, shell underneath, etc.), workflow organization (similar processes are grouped in a screen session).
But all of that just happens by itself in a GUI screen and isn't limited to text mode.
I'm writing this mail in mutt, in a screen session with multiple mailboxes open, each to its own screen window. It's like a multi-tabbed GNOME or KDE terminal, except that the session persists even if the controlling terminal is killed, or X dies altogether.
Yes, but you are limited to text mode apps. I actually have a GUI session that persists even if my local connection breaks. And it performs pretty well when I pick it up remotely. And I can't recall a time when the server side of the X connection ever died.
Screen is one of those amazingly powerful Linux tools, once you stumble across it.
But NX/freenx does the same and more. The only down side I can see is the time for the initial screen draw over a slow connection.
on 08:15 Fri 04 Mar, Les Mikesell (lesmikesell@gmail.com) wrote:
On 3/4/11 12:15 AM, Dr. Ed Morbius wrote:
But why do you need screen, then?
Terminal multiplexing, session persistance, scrollback/logging, split screen (top running in the top panel, shell underneath, etc.), workflow organization (similar processes are grouped in a screen session).
But all of that just happens by itself in a GUI screen and isn't limited to text mode.
I think you're fundamentally failing to understand my operating mode.
Local system == Linux === my administrative center.
Remote hosts. May be a dozen. May be 20,000. Or some number between or beyond.
Desktop persistance is local.
If I have to interactively operate on an individual remote host, I'm doing my job wrong. Preferably that's limited to initial provisioning and possibly hardware troubleshooting. Ideally, not even then (I haven't met my ideal). I'm really not particularly interested in having some complex GUI state on multiple remote systems.
Again: my objective isn't to change your mind but possibly open it a tad. That appears to be increasingly unlikely.
I'm writing this mail in mutt, in a screen session with multiple mailboxes open, each to its own screen window. It's like a multi-tabbed GNOME or KDE terminal, except that the session persists even if the controlling terminal is killed, or X dies altogether.
Yes, but you are limited to text mode apps.
Feature.
Running remote GUI management apps is an utter fail.
If you've *GOT* to run some remote GUI application, then yes, you're going to want a tool that supports it, of which there are several, and of which NX is merely one of many options. It's not a best, standard, open, free, or actively developed (in free software) solution.
I'm done here.
On 3/4/2011 12:07 PM, Dr. Ed Morbius wrote:
But why do you need screen, then?
Terminal multiplexing, session persistance, scrollback/logging, split screen (top running in the top panel, shell underneath, etc.), workflow organization (similar processes are grouped in a screen session).
But all of that just happens by itself in a GUI screen and isn't limited to text mode.
I think you're fundamentally failing to understand my operating mode.
Local system == Linux === my administrative center.
No, I've done things that way too. And I've had a linux box at my desk and can boot my laptop into it when I want. I just prefer NX with what looks exactly like a local linux desktop because when I'm at my desk it's essentially the same (minor plus for having windows on the same box, but I could run a separate computer if I wanted) - and when I'm remote I still have it all.
Remote hosts. May be a dozen. May be 20,000. Or some number between or beyond.
Same. Mine are clustered in a few locations though, so I normally have some strategically located ssh connections to run management scripts to local sets instead of directly from my desktop session. And if I need to connect to one from home, I'll grab my desktop screen and pick up from there.
Desktop persistance is local.
But my desktop includes my terminal windows and ssh connections.
If I have to interactively operate on an individual remote host, I'm doing my job wrong. Preferably that's limited to initial provisioning and possibly hardware troubleshooting. Ideally, not even then (I haven't met my ideal). I'm really not particularly interested in having some complex GUI state on multiple remote systems.
Agreed, but much of my development/testing is in a lab across the country. For a few things, like working in a GUI report writer, I run a separate NX session to a box there, but for text work, it is just ssh in another terminal window on my main desktop.
Again: my objective isn't to change your mind but possibly open it a tad. That appears to be increasingly unlikely.
It isn't like I've never worked in text mode before, or directly in a Linux X desktop without NX, so I don't see anything I need to be 'open' to. I'm just saying NX is better than all the other ways I've tried. If you don't care about letting programs run essentially forever on your desktop or being able to continue work-in-progress from other places, fine, but no, you aren't going to convince me I don't like it.
I'm writing this mail in mutt, in a screen session with multiple mailboxes open, each to its own screen window. It's like a multi-tabbed GNOME or KDE terminal, except that the session persists even if the controlling terminal is killed, or X dies altogether.
Yes, but you are limited to text mode apps.
Feature.
No accounting for taste, I guess. I'll take thunderbird over mutt anytime, although that's an exception to my normal operating mode because I tend to run that on the local OS/screen instead of on the NX desktop. My accounts are all IMAP on a server reachable from the internet so there's no need to maintain a local state and thunderbird works more or less the same regardless of the OS. But that's just a practical matter of sometimes wanting email without the Linux desktop.
Running remote GUI management apps is an utter fail.
I'm agnostic about that. The only thing I depend on that you might call a GUI management tool is having firefox access to an assortment of monitoring, reporting, ticketing, etc. applications on the private side of the network. There are other ways this could be handled, but it is nice to just have already-open windows on the desktop that has access to everything. So if I'm connecting from home to work on some problem, I automatically have access to everything related including still-open monitor sessions, etc. You can do that with everything on a laptop but it's a lot harder to keep running sessions going while you drive home.
If you've *GOT* to run some remote GUI application, then yes, you're going to want a tool that supports it, of which there are several, and of which NX is merely one of many options. It's not a best, standard, open, free, or actively developed (in free software) solution.
The GUI apps mostly run on 'my' desktop without much concept of whether they are remote or not. I think that's the real difference in the way we are thinking. The text windows run there too - and they both run very nicely. The current NX client is free in the sense of cost and works with freenx. I've always wished that RAM had been cheap back when X was originally designed so that they would have put the proxy/cache that you need for performance in from the start, but as things stand, NX is as good as I've seen. If you think there is something better, cheaper, and standard that is equally functional, I'm very interested, but I'm not going back to mutt or screen or having to constantly think in different terms about local and remote applications (at least local/remote 'to me' which can change from hour to hour).
On 3/4/2011 12:07 PM, Dr. Ed Morbius wrote:
I think you're fundamentally failing to understand my operating mode.
Local system == Linux === my administrative center.
Remote hosts. May be a dozen. May be 20,000. Or some number between or beyond.
After reading this again, I'm wondering if you thought I was advocating running NX sessions directly to some large number of remote hosts. I didn't mean that. I just park a desktop session in a convenient place that doesn't happen to be at my own desk but I can pretend like it is, and almost all of my remote work originates from this desktop, mostly in terminal windows.
I do have a few other sessions for work in a remote lab, access to VM's and some experimental stuff, but those are special cases where it is handy to only connect as needed.
On Fri, Mar 4, 2011 at 4:09 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 3/4/2011 12:07 PM, Dr. Ed Morbius wrote:
I think you're fundamentally failing to understand my operating mode.
Local system == Linux === my administrative center.
Remote hosts. May be a dozen. May be 20,000. Or some number between or beyond.
After reading this again, I'm wondering if you thought I was advocating running NX sessions directly to some large number of remote hosts. I didn't mean that. I just park a desktop session in a convenient place that doesn't happen to be at my own desk but I can pretend like it is, and almost all of my remote work originates from this desktop, mostly in terminal windows.
I do have a few other sessions for work in a remote lab, access to VM's and some experimental stuff, but those are special cases where it is handy to only connect as needed.
-- Les Mikesell lesmikesell@gmail.com
Can you stop please? This thread is related to 'screen', not the intricate details of using NX. In the thread context, the initial suggestion of NX was useful, but we're beyond that now.
Some people like GUIs (NX), others like command line (screen). Next topic.
On 3/4/2011 8:15 AM, Les Mikesell wrote:
I do like the way gnome collapses the icons in the task bar when you have enough of them - and pops up the list so you can see it. It makes it easy to find the terminal session connected to some particular remote host.
WindowMaker has a windowlist. Even better. I usually last 1-4 hours when I periodically try GNOME. KDE and XFCE I might last a few days. Then it's back to the One True Window Manager.
I don't care about the mechanism so much as having everything I do on one screen, under one window manager. So all of my terminal sessions collapse in one place that becomes a popup list. Likewise all of my firefox windows (and for this reason I like separate windows better than tabs).
The reason I like this might not be clear if you don't use Gnome much. It's a combination of the way gnome-terminal puts usr@host:/path in the window title bar and keeps it updated when you ssh to compatible systems, and the way the Gnome desktop collapses many task bar items into one for each application when enough are open at once. I end up with a 'Gnome-terminal (count)' task bar item that when clicked pops up the list of window titles making it easy to go back to anywhere I already have a connection by yanking that screen to the front. Firefox does the same by putting the page names in the collapsed list which is easier to use than tabs within a screen.
On Thu, Mar 03, 2011 at 03:49:37PM -0800, Dr. Ed Morbius wrote:
I meant to note earlier: the upstream NX developers have gone non-free, no?
https://secure.wikimedia.org/wikipedia/en/wiki/NX_technology#License
Is there a free software development branch?
Presumably the freenx developers will fork the 3.x branch, but this relies on NoMachine continuing to distribute a 3.x-compatible client. If they cease distributing the older client, the freenx-server folks will have difficulties.
Some other alternatives, references from the above wikipedia page:
http://code.google.com/p/neatx/ (no client?) http://code.google.com/p/partiwm/wiki/xpra (not a remote desktop, but at least GPL)
--keith
On Fri, Mar 4, 2011 at 3:03 AM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On Thu, Mar 03, 2011 at 03:49:37PM -0800, Dr. Ed Morbius wrote:
I meant to note earlier: the upstream NX developers have gone non-free, no?
https://secure.wikimedia.org/wikipedia/en/wiki/NX_technology#License
Version 4, which is in beta, looks non free. We'll see what happens there.
Is there a free software development branch?
Presumably the freenx developers will fork the 3.x branch, but this relies on NoMachine continuing to distribute a 3.x-compatible client. If they cease distributing the older client, the freenx-server folks will have difficulties.
Some other alternatives, references from the above wikipedia page:
http://code.google.com/p/neatx/ (no client?)
Neatx is entirely reliant on the "nx" toolkit, it's only python wrappers to get a server to work. I've personally written and submitted .spec files for it, and for various reasons just wrote a RHEL 6 .spec file for it.
I can't recommend it. It's incomplete abandonware, nominally easier to set up than FreeNX (which is why someone I worked with wound up using it) but entirely unmaintained, and it has significant bugs with dead session, especially on reboot, and it lacks other useful features such as shared sessions.
It's more abandonware. I'm afraid that for personal use, I'm recommending a test of the version 4 and consider using the free, though closed source, tools from the company that wrote the protocol, or buying licenses.
http://code.google.com/p/partiwm/wiki/xpra (not a remote desktop, but at least GPL)
Potentially useful for persistent X sessions, I see. If I didn't benefit from all the other features of NX (such as the bandwidth reduction and cheap/free and lightweight X server for Windows), I'd consider pursuing it.
On Mar 3, 2011, at 17:50, Les Mikesell wrote:
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
I didn't know you could do this with NX. I've been using VNC to connect to my session at work from home, but it's kinda slow. So how do you use NX technology to connect to an *existing* GUI session (in my case Gnome if that matters)? Sorry, I know this is off topic, but then again this entire thread seems to be headed off on a tangent...
Alfred
On 3/4/2011 8:51 AM, Alfred von Campe wrote:
On Mar 3, 2011, at 17:50, Les Mikesell wrote:
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
I didn't know you could do this with NX. I've been using VNC to connect to my session at work from home, but it's kinda slow. So how do you use NX technology to connect to an *existing* GUI session (in my case Gnome if that matters)? Sorry, I know this is off topic, but then again this entire thread seems to be headed off on a tangent...
Theoretically NX can do a 'shadow' session where the client connects to an existing current connection, and as a special case, this can be the console. However, I've had trouble getting those connections to work at all (I think the size and color depth has to match exactly or something) and when they do, they don't really perform any better than vnc anyway and you can't resize the desktop to match your local screen. So, the way to do it is to start the session under NX to begin with. There's some overhead if you do it on the local machine but except for playing video it shouldn't be enough to notice. But if you can run your session on a faster server box that is noisy enough that you don't want it at your desk - or you have a slow/cheap box at your desk, or move around to different machines, or need access to a different OS, it comes out as a win to run everything that way. In my case I generally park it filling one screen of a dual-headed windows box. And even those things don't apply for your main work, you might park a session on some well-connected machine that you can reach remotely through vpn or ssh. Then a single client connection to that gives you access to both whatever you left running there and all of the internal machines it can reach.
On Fri, Mar 4, 2011 at 9:51 AM, Alfred von Campe alfred@von-campe.com wrote:
On Mar 3, 2011, at 17:50, Les Mikesell wrote:
I almost never log in directly at a linux console anymore and if I need to do something from home or remotely, I just pick the session that was my last desktop at work.
I didn't know you could do this with NX. I've been using VNC to connect to my session at work from home, but it's kinda slow. So how do you use NX technology to connect to an *existing* GUI session (in my case Gnome if that matters)? Sorry, I know this is off topic, but then again this entire thread seems to be headed off on a tangent...
Alfred
It's default behavior for the Nomachine Windows client. When you close it, it asks if you want to "disconnect" or "terminate" the session. Whether it works well is heavily dependent on the server, whether Neatx, FreeNX, or the NoMachine server.
In this case, you might want to conditionally assign some reasonable value on failure. Say:
tput -T $TERM init >/dev/null 2>&1 || export TERM=xterm
'tset -q' is another test which can be used.
The remote host's $TERM variable is in fact xterm. When I connect to the screen session the $TERM variable is 'screen'. I think it's because I'm opening a new ssh session in each screen window. Not a huge deal; I mainly use this for short commands, and if I need to run something longer I just write it all out in a text editor and paste it into the terminal.
on 09:10 Fri 04 Mar, Sean Carolan (scarolan@gmail.com) wrote:
In this case, you might want to conditionally assign some reasonable value on failure. Say:
tput -T $TERM init >/dev/null 2>&1 || export TERM=xterm
'tset -q' is another test which can be used.
The remote host's $TERM variable is in fact xterm. When I connect to the screen session the $TERM variable is 'screen'.
Are you running screen locally or remotely?
My experience is it's best to launch SSH sessions in their own terminal(s), then start screen on the remote side. This also generally provides more utility (you want a single session to a host, and a logically grouped set of shells / processes on that host).
Nesting screen sesssions is possible, but generally not terribly friendly due to having to hit multiple C-a escapes for screen commands.
I think it's because I'm opening a new ssh session in each screen window. Not a huge deal; I mainly use this for short commands, and if I need to run something longer I just write it all out in a text editor and paste it into the terminal.
Or you could write a script, scp it to the hosts you want to run it on (testing first, natch), and exec it:
for host in <hostlist>; do scp myscript $host:.; done
[fiddle around with tests or verification as necessary]
for host in <hostlist>; do echo "** $host **"; ssh $host ./myscript; done
... which is a shell idiom that shows up a LOT in my history.
As I mentioned earlier, dsh (distributed ssh) is a very powerful tool for running multiple remote commands. Puppet, cfengine, and other tools may also be useful.
Scales from low multiples through thousands and more of hosts.
The remote host's $TERM variable is in fact xterm. When I connect to the screen session the $TERM variable is 'screen'.
Are you running screen locally or remotely?
Remotely. My work machine is a laptop, which is not powered on all the time. Hence I use a remote box as a jumping-off point, and run my screen sessions there.
Or you could write a script, scp it to the hosts you want to run it on (testing first, natch), and exec it:
for host in <hostlist>; do scp myscript $host:.; done
[fiddle around with tests or verification as necessary]
for host in <hostlist>; do echo "** $host **"; ssh $host ./myscript; done
Yes, I do this quite a bit. But there are often times when I have to do interactive work, running different commands on various hosts.
As I mentioned earlier, dsh (distributed ssh) is a very powerful tool for running multiple remote commands. Puppet, cfengine, and other tools may also be useful.
Yes, thank you for the pointers. I'm familiar with both puppet and cfengine. The GNU screen sessions are mainly used during the build process, before a server has puppet or cfengine up and running.
On Thu, Mar 3, 2011 at 2:36 PM, Sean Carolan scarolan@gmail.com wrote:
I really like gnu screen and use it everyday but there's one thing that is a bit inconvenient, and that's the odd line wrapping and terminal size issues that seem to pop up. The problem crops up when I type or paste a really long command, and then go back and try to edit it; the text starts to wrap over itself and you have no idea what you are editing. Any fixes for this?
I've given up on screen and switched to "NX" for recoverable sessions. It works with X windows, the personal version is free for up to two simultaneous connections, and there are even hooks in CentOS not found in RHEL for the "nx" and "freenx" tools.
It works *much* better than installing a $500 X server on the Windows client side, too.
-
Alfred von Campe -
Brian Mathis -
Dr. Ed Morbius -
Jim Wildman -
Keith Keller -
Kwan Lowe -
Les Mikesell -
Nico Kadel-Garcia -
Sean Carolan