X Window System/remote session/desktop - Revision history

Woozle: possible command for MATE; error message

2015-12-29T15:31:33Z

possible command for MATE; error message

← Older revision		Revision as of 15:31, 29 December 2015
Line 14:		Line 14:
	** [[startkde]] starts [[KDE]]		** [[startkde]] starts [[KDE]]
	** [[startxfce4]] is reputed to start [[Xfce]]		** [[startxfce4]] is reputed to start [[Xfce]]
			** [[mate-wm]] may be the command to start [[MATE]]

			Note: all of these are found in /usr/bin
	==Notes==		==Notes==
	* Xnest may not be installed by default; use the package manager to install it.		* Xnest may not be installed by default; use the package manager to install it.
	* there are apparently better alternatives to Xnest; xserver-xephyr seems worth trying -- but it's basically the same mechanism, just with some more sophisticated capabilities under the hood (as far as I can tell).		* there are apparently better alternatives to Xnest; xserver-xephyr seems worth trying -- but it's basically the same mechanism, just with some more sophisticated capabilities under the hood (as far as I can tell).
			==Error Messages==
			* [[Window manager error: Unable to open X display]] {{arg\|hostname}}
			*: This would seem to indicate that the remote machine is unable to contact the local machine's X server. This may happen even when Xnest is running and remotemachine is able to ping localmachine.
	==Bugs==		==Bugs==
	* <s>Resized windows often don't display properly; the controls within the window resize, but the window itself won't grow past its original size. Controls which move outside the visible area become inaccessible, including the window-frame controls (max/min/close).</s> (This problem seems to have been fixed as of July 2006; not sure whether it was with the client or the server, but it now works fine with Kubuntu 6 connecting to Fedora Core 4.)		* <s>Resized windows often don't display properly; the controls within the window resize, but the window itself won't grow past its original size. Controls which move outside the visible area become inaccessible, including the window-frame controls (max/min/close).</s> (This problem seems to have been fixed as of July 2006; not sure whether it was with the client or the server, but it now works fine with Kubuntu 6 connecting to Fedora Core 4.)

Woozle: similarity to VNC

2015-10-09T23:10:44Z

similarity to VNC

← Older revision		Revision as of 23:10, 9 October 2015
Line 1:		Line 1:
	You can set up a window on your machine which will appear like a monitor which is booting into the remote system. This is a little more complicated than the other remote session method, but is more like "being there".		You can set up a window on your machine which will appear like a monitor which is booting into the remote system. This is a little more complicated than the other remote session method, but is more like "being there". (This is similar to the functionality of [[VNC]], but designed into the system rather than being a kluge on top of it.)

	It also can't work if your local machine is not exposed directly to the remote machine – the remote needs to be able to access your local machine directly via an IP address. This means that the local machine cannot be behind a NAT wall.		It also can't work if your local machine is not exposed directly to the remote machine – the remote needs to be able to access your local machine directly via an IP address. This means that the local machine cannot be behind a NAT wall.

Woozle: can't do this from behind a firewall; tidying and rearranging

2015-10-09T21:56:13Z

can't do this from behind a firewall; tidying and rearranging

← Older revision		Revision as of 21:56, 9 October 2015
Line 1:		Line 1:
	You can set up a window on your machine which will appear like a monitor which is booting into the remote system. This is a little more complicated than the other method, but is more like "being there".		You can set up a window on your machine which will appear like a monitor which is booting into the remote system. This is a little more complicated than the other remote session method, but is more like "being there".

			It also can't work if your local machine is not exposed directly to the remote machine – the remote needs to be able to access your local machine directly via an IP address. This means that the local machine cannot be behind a NAT wall.

	In order to do this, you will need [[Xnest]] running on the "client" machine. This is available in standard repositories for most [[Linux distributions]] (including [[Ubuntu]] and [[SuSE]]).		In order to do this, you will need [[Xnest]] running on the "client" machine. This is available in standard repositories for most [[Linux distributions]] (including [[Ubuntu]] and [[SuSE]]).

	* On the local (client) machine (note the space before the ":"):		* On the local (client) machine (note the space before the ":"):
	[[Xnest]] -ac :1		*: <code>[[Xnest]] -ac :1</code>
	* {{faint\|Notes:
	** Xnest may not be installed by default; use the package manager to install it.
	** there are apparently better alternatives to Xnest; xserver-xephyr seems worth trying.}}
	* On the remote machine (via [[ssh]] or equivalent):		* On the remote machine (via [[ssh]] or equivalent):
	export DISPLAY=''yourmachine'':1		*: <code>export DISPLAY=''yourmachine'':1</code>
	...where ''yourmachine'' is the name or IP address of your local machine. If you get messages indicating that it's having trouble connecting to ''yourmachine'', try using an IP address instead. If you are using a Windows ([[Samba]]) network and machine names do not automatically resolve to IP addresses, use "[[nmblookup]] ''yourmachine''" to get the address.		** ...where ''yourmachine'' is the name or IP address of your local machine (relative to the remote).
			** If you get messages indicating that it's having trouble connecting to ''yourmachine'', try using an IP address instead. If you are using a Windows ([[Samba]]) network and machine names do not automatically resolve to IP addresses, use "[[nmblookup]] ''yourmachine''" to get the address.
	* You will then need to run the command to start a GUI session:		* You will then need to run the command to start a GUI session:
	** [[startkde]] starts [[KDE]]		** [[startkde]] starts [[KDE]]
	** [[startxfce4]] is reputed to start [[Xfce]]		** [[startxfce4]] is reputed to start [[Xfce]]
			==Notes==
			* Xnest may not be installed by default; use the package manager to install it.
			* there are apparently better alternatives to Xnest; xserver-xephyr seems worth trying -- but it's basically the same mechanism, just with some more sophisticated capabilities under the hood (as far as I can tell).

	==Bugs==		==Bugs==

Woozle: extracted from parent article

2015-10-09T21:27:12Z

extracted from parent article

New page

You can set up a window on your machine which will appear like a monitor which is booting into the remote system. This is a little more complicated than the other method, but is more like "being there".

In order to do this, you will need [[Xnest]] running on the "client" machine. This is available in standard repositories for most [[Linux distributions]] (including [[Ubuntu]] and [[SuSE]]).

* On the local (client) machine (note the space before the ":"):
[[Xnest]] -ac :1
* {{faint|Notes:
** Xnest may not be installed by default; use the package manager to install it.
** there are apparently better alternatives to Xnest; xserver-xephyr seems worth trying.}}
* On the remote machine (via [[ssh]] or equivalent):
export DISPLAY=''yourmachine'':1
...where ''yourmachine'' is the name or IP address of your local machine. If you get messages indicating that it's having trouble connecting to ''yourmachine'', try using an IP address instead. If you are using a Windows ([[Samba]]) network and machine names do not automatically resolve to IP addresses, use "[[nmblookup]] ''yourmachine''" to get the address.
* You will then need to run the command to start a GUI session:
** [[startkde]] starts [[KDE]]
** [[startxfce4]] is reputed to start [[Xfce]]

==Bugs==
* <s>Resized windows often don't display properly; the controls within the window resize, but the window itself won't grow past its original size. Controls which move outside the visible area become inaccessible, including the window-frame controls (max/min/close).</s> (This problem seems to have been fixed as of July 2006; not sure whether it was with the client or the server, but it now works fine with Kubuntu 6 connecting to Fedora Core 4.)
* <s>New windows often don't display at all (except in the taskbar, if they would normally show up there), but you can make them appear by clicking on the K menu in the taskbar.</s> (This problem also has gone away.)
* The contents of the local X window are scaled to about 75%, making some things hard to read; there's probably a command-line option to change this, but it doesn't seem to be adjustable during runtime. (Automatic scaling when the user mouse-adjusts the window size would be nice; a drop-down menu on the Xnest window would also be good.)

==Question==
Is there any way to automate this whole thing? As it is, you have to have two console windows open – one for the remote ssh session and one for the local session to start Xnest. Neither of those windows can be closed without killing the session. There must be some way to have one session spawn a batch file (.sh) which spawns Xnest, then spawns an ssh session to the remote which runs export (using nmblookup to get the local machine's IP address automatically would be nice), and then exits – but I'm not enough of a Linux guru to know how to do most of that.