X Window System/remote session - Revision history

Woozle: more succinct explanation that gets to the point in the first sentence

2015-10-09T23:11:45Z

more succinct explanation that gets to the point in the first sentence

← Older revision		Revision as of 23:11, 9 October 2015
Line 1:		Line 1:
	==About==		==About==
	~~Unlike many other more popular windowing systems, the~~ [[X Window System]]~~, carefully separates the '~~'client~~'' (~~i.e. ~~the part which~~ the user ~~sees and interacts~~ with~~) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as~~ the ~~server. It is possible to set up a window~~ on one machine ~~which is actually a session running on another machine – similar to [[VNC]]~~, but ~~designed into~~ the ~~system rather than being a kluge~~ on ~~top of it. (However, see [[#Bugs]]~~.)		The [[X Window System]]'s client-server architecture makes it possible to run graphical applications remotely – i.e. the user is interacting with the application on one machine, but the actual execution is taking place on another.

	There are actually ''two'' ways to run remote graphical applications:		There are actually ''two'' ways to run remote graphical applications on X Windows:
	* [[/application]]: run a single application		* [[/application]]: run a single application
	* [[/desktop]]: run a complete desktop environment		* [[/desktop]]: run a complete desktop environment

Woozle: moved different methods into separate subpages

2015-10-09T21:27:35Z

moved different methods into separate subpages

@@ Line 2: / Line 2: @@
 Unlike many other more popular windowing systems, the [[X Window System]], carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine &ndash; similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)
-There are actually ''two'' ways to run remote graphical applications.
+There are actually ''two'' ways to run remote graphical applications:
-===Single Application===
+* [[/application]]: run a single application
-Perhaps the simplest method is to use this command:
+* [[/desktop]]: run a complete desktop environment

Woozle: workaround; better sectioning

2015-10-09T20:24:13Z

workaround; better sectioning

← Older revision		Revision as of 20:24, 9 October 2015
Line 2:		Line 2:
	Unlike many other more popular windowing systems, the [[X Window System]], carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)		Unlike many other more popular windowing systems, the [[X Window System]], carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)

	There are actually ''two'' ways to run remote graphical applications. Perhaps the simplest is to use this command:		There are actually ''two'' ways to run remote graphical applications.
			===Single Application===
			Perhaps the simplest method is to use this command:
	* [[ssh]] -X <u>account</u>@<u>machine</u> {{optarg\|<u>command</u>}}		* [[ssh]] -X <u>account</u>@<u>machine</u> {{optarg\|<u>command</u>}}

	This causes any X commands invoked during the session to run using your local machine's X server. (Note that some GUI applications, including [[Firefox]] and [[Thunderbird]], are configured to look for a locally-running copy and, if found, bring that to the foreground instead of running on the remote system and merely ''displaying'' locally. ~~The purpose of~~ this behavior is ~~not clear, and HTYP does not currently know of any workarounds~~.)		This causes any X commands invoked during the session to run using your local machine's X server.

			Note that some GUI applications, including [[Firefox]] and [[Thunderbird]], are configured to look for a locally-running copy and, if found, bring that to the foreground instead of running on the remote system and merely ''displaying'' locally. Such applications typically have command-line options to suppress this behavior, e.g.:
			* <code>firefox --no-remote</code>
			* <code>thunderbird --no-remote</code>
			===Full Desktop===
			Alternatively, you can set up a window on your machine which will appear like a monitor which is booting into the remote system.

	~~Alternatively, you can set up a window on your machine which will appear like a monitor which is booting into the remote system; the rest of this page describes that technique.~~
	~~==How==~~
	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]]).

Line 23:		Line 29:
	** [[startxfce4]] is reputed to start [[Xfce]]		** [[startxfce4]] is reputed to start [[Xfce]]

	==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.)
	* <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.)		* <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.)		* 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==		====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.		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.

Woozle: tweaks & updates

2015-10-09T19:42:13Z

tweaks & updates

← Older revision		Revision as of 19:42, 9 October 2015
Line 1:		Line 1:
	==~~Navigation~~==		==About==
	~~[[computing]]: [[Linux]]: [[running a remote X session]]~~		Unlike many other more popular windowing systems, the [[X Window System]], carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)
	~~==Explanation==~~
	~~The [[X Windows]] system, unlike~~ many other more popular windowing systems, carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)

	There are actually ''two'' ways to run remote graphical applications. Perhaps the simplest is to use this command:		There are actually ''two'' ways to run remote graphical applications. Perhaps the simplest is to use this command:
	* [[ssh]] -X <u>account</u>@<u>machine</u> {{optarg\|<u>command</u>}}		* [[ssh]] -X <u>account</u>@<u>machine</u> {{optarg\|<u>command</u>}}

	This causes any X commands invoked during the session to run using your local machine's X server.		This causes any X commands invoked during the session to run using your local machine's X server. (Note that some GUI applications, including [[Firefox]] and [[Thunderbird]], are configured to look for a locally-running copy and, if found, bring that to the foreground instead of running on the remote system and merely ''displaying'' locally. The purpose of this behavior is not clear, and HTYP does not currently know of any workarounds.)

	Alternatively, you can set up a window on your machine which will appear like a monitor which is booting into the remote system; the rest of this page describes that technique.		Alternatively, you can set up a window on your machine which will appear like a monitor which is booting into the remote system; the rest of this page describes that technique.
Line 30:		Line 28:
	* 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.)		* 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.)

	==~~Issues~~==		==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.		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.

Woozle: Woozle moved page running a remote X session to X Window System/remote session: reorganizing

2015-10-09T19:37:21Z

Woozle moved page running a remote X session to X Window System/remote session: reorganizing

← Older revision	Revision as of 19:37, 9 October 2015
(No difference)

Woozle: /* How */ startxfce4

2010-03-02T17:53:15Z

How: startxfce4

← Older revision		Revision as of 17:53, 2 March 2010
Line 21:		Line 21:
	export DISPLAY=''yourmachine'':1		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.		...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]]~~. Not sure what other commands might be available.~~		* You will then need to run the command to start a GUI session:
			** [[startkde]] starts [[KDE]]
			** [[startxfce4]] is reputed to start [[Xfce]]

	==Bugs==		==Bugs==

Woozle: The Easy Way, at long last. :-P

2007-09-28T19:04:45Z

The Easy Way, at long last. :-P

← Older revision		Revision as of 19:04, 28 September 2007
Line 4:		Line 4:
	The [[X Windows]] system, unlike many other more popular windowing systems, carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)		The [[X Windows]] system, unlike many other more popular windowing systems, carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)

			There are actually ''two'' ways to run remote graphical applications. Perhaps the simplest is to use this command:
			* [[ssh]] -X <u>account</u>@<u>machine</u> {{optarg\|<u>command</u>}}

			This causes any X commands invoked during the session to run using your local machine's X server.

			Alternatively, you can set up a window on your machine which will appear like a monitor which is booting into the remote system; the rest of this page describes that technique.
			==How==
	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]]).
	~~==How==~~
	* On the local (client) machine (note the space before the ":"):		* On the local (client) machine (note the space before the ":"):
	[[Xnest]] -ac :1		[[Xnest]] -ac :1

Woozle: un-hid navbar header; changed fainted bugs to strikethrough

2007-04-12T13:43:07Z

un-hid navbar header; changed fainted bugs to strikethrough

← Older revision		Revision as of 13:43, 12 April 2007
Line 1:		Line 1:
	==~~{{hide\|~~Navigation}}==		==Navigation==
	[[computing]]: [[Linux]]: [[running a remote X session]]		[[computing]]: [[Linux]]: [[running a remote X session]]
	==Explanation==		==Explanation==
Line 17:		Line 17:

	==Bugs==		==Bugs==
	* ~~{{faint\|~~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).}} (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.)
	* ~~{{faint\|~~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.}} (This problem also has gone away.)		* <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.)		* 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.)

	==Issues==		==Issues==
	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.		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.

Woozle: updated navbar after move

2006-09-24T12:22:39Z

updated navbar after move

← Older revision		Revision as of 12:22, 24 September 2006
Line 1:		Line 1:
	[[~~Computing~~]]: [[Linux]]: [[~~Running~~ a remote X session]]		=={{hide\|Navigation}}==
			[[computing]]: [[Linux]]: [[running a remote X session]]
	==Explanation==		==Explanation==
	The [[X Windows]] system, unlike many other more popular windowing systems, carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)		The [[X Windows]] system, unlike many other more popular windowing systems, carefully separates the ''client'' (i.e. the part which the user sees and interacts with) from the ''server'' (i.e. the part which does all the work behind the scenes). This means that the client does not actually have to be running on the same machine as the server. It is possible to set up a window on one machine which is actually a session running on another machine – similar to [[VNC]], but designed into the system rather than being a kluge on top of it. (However, see [[#Bugs]].)

Woozle: Running a remote X session moved to running a remote X session

2006-09-24T12:22:08Z

Running a remote X session moved to running a remote X session

← Older revision	Revision as of 12:22, 24 September 2006
(No difference)