Just because I run KDE doesn’t mean I can’t run both K-whatever and G-whatever apps. For the most part (obvious brain-damaged developers still statically linking against libraries that get replaced faster than yesterday’s underwear notwithstanding) you can run Gnome apps on KDE and vice-versa. Now obviously I’m going to use yum whenever possible, but this particular app came as an rpm. I installed it by hand, and it worked just fine.

Remote X…

Here we go.

Aaron: I don’t know the environment as well as I’d like, so I’ll be making some assumptions here… Let’s see how close I come.

The X subsystem is actually kind of backwards to the way we typically look at this stuff. You run the XServer on your machine, and the remote system is the client. That’s the actual true description of an X session. How so? The machine you’re on needs to run software that provides a location for the remote X machine to connect back to as a client. So, there’s a couple scenarios you’re probably experiencing.

1) You have a windows box on your end without X Server software and aren’t really sure how to proceed.

2) You have a linux box, and you’re getting the whole “permission denied” thing, and can’t figure where the security is configured.

In case #1, there is a pile of software from the very expensive to the free out there to run an X server on your windows based system. I’ve used many, and tend to like Esker’s SmartTerm X. Xoftware is another, and Cygwin is the free offering. Having one of these on your Windows box is always a good idea if you’re working in UNIX. At the very least, Cygwin can foot this bill.

In case #2 you have a situation where you simply haven’t enabled access. We’ll cover that later.

Once you have an XServer involved, you have to configure thecliennt to know how to reach you. It needs to know how to send a display to you, the server. We do this by exporting our display address. (I’ll use private addresses for example)

Solaris: 192.168.1.15
You: 192.168.1.27

while connected to the remote system (via ssh, presumably), you would execute a command telling that system where you are like so:

export DISPLAY=192.168.1.27:0.0

or, if your shell doesn’t support that

DISPLAY=192.168.1.27:0.0; export DISPLAY

In doing this, you’ve told your client “I’m over here”. This works on both windows-based and linux-based systems.

Next, there is a security system associated with X sessions. It’s very simple, but you still need to execute the command to allow X connections. That security system is called “xhost”. Xhost is used to add granular (and massive) rights to a system. It’s usage is like so:

xhost [[+-]name …]

Now, the simple running of the command: xhost + will completely open up your system to any X connection from anywhere on the wire. However, you can also man the command out to see some options, and the addition of users to an ACL and the like. This is all part of the XSecurity subsystem, which also has some pretty detailed man pages.

Finally, once you’ve run your X server, run the xhost command to allow access, you then SSH to the machine in question (you must tunnel X over SSH…this is pretty clear in SSH’s config files). Once on the destination machine, you can type a known X command (like xclock or xterm. This would include any programs you could run under X.

Another way to connect to remote boxes is VNC. VNC is supported on most platforms now, and is an excellent way of doing what you’re asking. It’s by far the best performance, and you actually see the desktop you’re trying to control instead of just the command prompt, and you needing to launch the various programs from thaqt location.

If youhave any more questions, I’d be happy to answer. It’s late, and this feels like it was somewhhat hard to follow, but I’m not really feeling well.

Let me know if I can be of more help.

Xhost Man: http://www.netadmintools.com/html/xhost.man.html

Just because I run KDE doesn’t mean I can’t run both K-whatever and G-whatever apps. For the most part (obvious brain-damaged developers still statically linking against libraries that get replaced faster than yesterday’s underwear notwithstanding) you can run Gnome apps on KDE and vice-versa. Now obviously I’m going to use yum whenever possible, but this particular app came as an rpm. I installed it by hand, and it worked just fine.

Remote X…

Here we go.

Aaron: I don’t know the environment as well as I’d like, so I’ll be making some assumptions here… Let’s see how close I come.

The X subsystem is actually kind of backwards to the way we typically look at this stuff. You run the XServer on your machine, and the remote system is the client. That’s the actual true description of an X session. How so? The machine you’re on needs to run software that provides a location for the remote X machine to connect back to as a client. So, there’s a couple scenarios you’re probably experiencing.

1) You have a windows box on your end without X Server software and aren’t really sure how to proceed.

2) You have a linux box, and you’re getting the whole “permission denied” thing, and can’t figure where the security is configured.

In case #1, there is a pile of software from the very expensive to the free out there to run an X server on your windows based system. I’ve used many, and tend to like Esker’s SmartTerm X. Xoftware is another, and Cygwin is the free offering. Having one of these on your Windows box is always a good idea if you’re working in UNIX. At the very least, Cygwin can foot this bill.

In case #2 you have a situation where you simply haven’t enabled access. We’ll cover that later.

Once you have an XServer involved, you have to configure thecliennt to know how to reach you. It needs to know how to send a display to you, the server. We do this by exporting our display address. (I’ll use private addresses for example)

Solaris: 192.168.1.15
You: 192.168.1.27

while connected to the remote system (via ssh, presumably), you would execute a command telling that system where you are like so:

export DISPLAY=192.168.1.27:0.0

or, if your shell doesn’t support that

DISPLAY=192.168.1.27:0.0; export DISPLAY

In doing this, you’ve told your client “I’m over here”. This works on both windows-based and linux-based systems.

Next, there is a security system associated with X sessions. It’s very simple, but you still need to execute the command to allow X connections. That security system is called “xhost”. Xhost is used to add granular (and massive) rights to a system. It’s usage is like so:

xhost [[+-]name …]

Now, the simple running of the command: xhost + will completely open up your system to any X connection from anywhere on the wire. However, you can also man the command out to see some options, and the addition of users to an ACL and the like. This is all part of the XSecurity subsystem, which also has some pretty detailed man pages.

Finally, once you’ve run your X server, run the xhost command to allow access, you then SSH to the machine in question (you must tunnel X over SSH…this is pretty clear in SSH’s config files). Once on the destination machine, you can type a known X command (like xclock or xterm. This would include any programs you could run under X.

Another way to connect to remote boxes is VNC. VNC is supported on most platforms now, and is an excellent way of doing what you’re asking. It’s by far the best performance, and you actually see the desktop you’re trying to control instead of just the command prompt, and you needing to launch the various programs from thaqt location.

If youhave any more questions, I’d be happy to answer. It’s late, and this feels like it was somewhhat hard to follow, but I’m not really feeling well.

Let me know if I can be of more help.

Xhost Man: http://www.netadmintools.com/html/xhost.man.html