Remote Window Managers

 in

Lots of times it's extremely frustrating or time consuming to run an xterm on a remote host just to fork your programs from that remote machine. Why not just run your window manager there even though you're not on its console? The window manager is just another X application, after all, isn't it?

Fire off your local X server

xinit /usr/bin/xterm -- :1 &

yields a vanilla X session with merely an xterm running - no window manager. Now you need to add permissions to this window session for the remote host. You can tunnel the connection through SSH if your network is insecure but there's a distinct performance hit. If your network is secure, you can just "xhost +remotehost" and spray directly to your X server:

Tunneled SSH:

ssh -fY remotehost /usr/bin/wmaker

or spray directly:

xhost +remotehost
ssh -f remotehost /usr/bin/wmaker -display localmachine:1

The first option, if your remote SSH server supports it, will use a locally defined DISPLAY that then gets tunneled to your local side over SSH. The second option allows remotehost to send X data directly to your local display, then runs WindowMaker there but displaying it locally. Now all your desktop actions are done on the remote machine, not locally.

Our special thanks to Bill from Washington state for this tech tip.
__________________________

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"Extremely frustrating"?

janpla's picture

It seems like a lot of work - are you guys running Windows on desktop machines?

This is what I do - I find it works a charm; but then I run Linux on my desktop:

Open a local xterm or similar. Log on to the remote machine with 'ssh -X user@remote'. The '-X' means that X programs on the remote machine are displayed on your local desktop. No need for 'export DISPLAY' or 'xhost +'. You have to set up the configuration files on you local as well as remote machine, though (they are in /etc/ssh).

Couldn't make it run.

JM's picture

Its a pity that it does not work for me because I am needing desperately such a kind of feature for my system. I Installed wmaker in the remote host, but it didn't work. It says:

/usr/bin/wmaker fatal error: could not open display "CompUBUNTU:1"

where "compUBUNTU" is the name of my local machine which, by the way, runs a UBUNTU Hardy distro, while the remote host is running Fedora 8. It shouldn't be a network issue because the two computers are connected to the same LAN with no particular filters or firewalls between them.

Any suggestion?

And if you dislike Window Maker?

Jay Dugger's picture

Will this tech tip still work with a window manager that doesn't have a "-display" option, such as xmonad?

Sometimes the delete key serves best.

Used to do this

jonadair's picture

I used to do this, holy moley, 18 years ago. We had a lab full of Mac II's running Apple's A/UX. The machines struggled to run much besides the X server. Since I was already running most everything else remotely, one day I fired up TWM remotely and it worked reasonably well. So I hacked up my .xinitc so that when I started X on one of the A/UX boxes, it ran TWM and everything else from our 10 processor Sequent box.

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions