Re: Prepackaged indirected X terminal
[ BTW. List, is this the right place to have the discussion on ? ] Why not then have have xdm manage the :0 display and start another X for that specific work while true; do X :1 -indirect $host; done # or while true; do X :1 vt10 -indirect $host; done will basically start up a new display on the next virtual terminal, or the given vt. C-A-F7 will take you to the local managed server C-A-F8 will take you to the "indirected" server I don't know what your users will think about that, but if it solves your maintainance headaches, why not. Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: Alexander Perry [EMAIL PROTECTED] Subject: Re: Prepackaged indirected X terminal Date: Mon, 27 Nov 2000 22:37:58 -0800 Thanks, Karl, that is much neater than the way I was doing it. What I'm trying to set up is this ... The nameservers are all running xdm to catch broadcast xdmcp requests. These are given the chooser with a list of host names that is automatically derived from the nameserver content. Each calling server is thus indirected to the desired computer; in many cases, this will be the localhost just like the default. Why ? I'd like to set this up because we have computers sitting around, most of which are connected to a variety of experimental systems. If two people want to work on the same system, or if the area around that system is not conducive to placing a human nearby, people simply grab the console of a nearby computer and work normally. It gets irritating fast, having to deal with a display manager that starts applications locally when you really want to run the apps on the target system. Starting the X server from inittab with the -indirect option implements this very nicely, but it is a pain switching each machine over by editing Xservers and inittab, putting in the tweaks that would normally live in Xreset (for a given server) and making sure the command line options in inittab match up with the values that were being used in xdm ... so it works! Thus, I was wondering whether there was a clean way to have xdm start (and restart) the X on the local computer, and send the display off for an xdmcp indirect where it would normally use the xlogin interface immediately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
Thanks, Karl, that is much neater than the way I was doing it. What I'm trying to set up is this ... The nameservers are all running xdm to catch broadcast xdmcp requests. These are given the chooser with a list of host names that is automatically derived from the nameserver content. Each calling server is thus indirected to the desired computer; in many cases, this will be the localhost just like the default. Why ? I'd like to set this up because we have computers sitting around, most of which are connected to a variety of experimental systems. If two people want to work on the same system, or if the area around that system is not conducive to placing a human nearby, people simply grab the console of a nearby computer and work normally. It gets irritating fast, having to deal with a display manager that starts applications locally when you really want to run the apps on the target system. Starting the X server from inittab with the -indirect option implements this very nicely, but it is a pain switching each machine over by editing Xservers and inittab, putting in the tweaks that would normally live in Xreset (for a given server) and making sure the command line options in inittab match up with the values that were being used in xdm ... so it works! Thus, I was wondering whether there was a clean way to have xdm start (and restart) the X on the local computer, and send the display off for an xdmcp indirect where it would normally use the xlogin interface immediately.
Re: Prepackaged indirected X terminal
[ BTW. List, is this the right place to have the discussion on ? ] Why not then have have xdm manage the :0 display and start another X for that specific work while true; do X :1 -indirect $host; done # or while true; do X :1 vt10 -indirect $host; done will basically start up a new display on the next virtual terminal, or the given vt. C-A-F7 will take you to the local managed server C-A-F8 will take you to the indirected server I don't know what your users will think about that, but if it solves your maintainance headaches, why not. Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: Alexander Perry [EMAIL PROTECTED] Subject: Re: Prepackaged indirected X terminal Date: Mon, 27 Nov 2000 22:37:58 -0800 Thanks, Karl, that is much neater than the way I was doing it. What I'm trying to set up is this ... The nameservers are all running xdm to catch broadcast xdmcp requests. These are given the chooser with a list of host names that is automatically derived from the nameserver content. Each calling server is thus indirected to the desired computer; in many cases, this will be the localhost just like the default. Why ? I'd like to set this up because we have computers sitting around, most of which are connected to a variety of experimental systems. If two people want to work on the same system, or if the area around that system is not conducive to placing a human nearby, people simply grab the console of a nearby computer and work normally. It gets irritating fast, having to deal with a display manager that starts applications locally when you really want to run the apps on the target system. Starting the X server from inittab with the -indirect option implements this very nicely, but it is a pain switching each machine over by editing Xservers and inittab, putting in the tweaks that would normally live in Xreset (for a given server) and making sure the command line options in inittab match up with the values that were being used in xdm ... so it works! Thus, I was wondering whether there was a clean way to have xdm start (and restart) the X on the local computer, and send the display off for an xdmcp indirect where it would normally use the xlogin interface immediately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
Thanks, Karl, that is much neater than the way I was doing it. What I'm trying to set up is this ... The nameservers are all running xdm to catch broadcast xdmcp requests. These are given the chooser with a list of host names that is automatically derived from the nameserver content. Each calling server is thus indirected to the desired computer; in many cases, this will be the localhost just like the default. Why ? I'd like to set this up because we have computers sitting around, most of which are connected to a variety of experimental systems. If two people want to work on the same system, or if the area around that system is not conducive to placing a human nearby, people simply grab the console of a nearby computer and work normally. It gets irritating fast, having to deal with a display manager that starts applications locally when you really want to run the apps on the target system. Starting the X server from inittab with the -indirect option implements this very nicely, but it is a pain switching each machine over by editing Xservers and inittab, putting in the tweaks that would normally live in Xreset (for a given server) and making sure the command line options in inittab match up with the values that were being used in xdm ... so it works! Thus, I was wondering whether there was a clean way to have xdm start (and restart) the X on the local computer, and send the display off for an xdmcp indirect where it would normally use the xlogin interface immediately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
What, is it this problem you are trying to solve: #!/bin/sh h=$1 # hostname scp $h:.Xauthority . || xhost +$h while /bin/true do X -query $h done Your - remote: the server is local and management is remote line is the same as your "foreign" or "xdmcp" line from what I can see. Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: Alexander Perry [EMAIL PROTECTED] Subject: Re: Prepackaged indirected X terminal Date: Sat, 25 Nov 2000 23:25:17 -0800 From: Karl Hammar [EMAIL PROTECTED] $ man Xserver | sed -n -e '288,340p' Yes, I know. From: Alexander Perry [EMAIL PROTECTED] [...] I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. xdm (for example) supports - local: the server is local and the management is local - foreign: the server is remote and we need to kick it - xdmcp: the server is remote and it will come to us I was wondering whether there was a way to request - remote: the server is local and management is remote I'd like xdm to deal with monitoring and restarting the server, yet not try to take control of that display. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
From: Karl Hammar [EMAIL PROTECTED] $ man Xserver | sed -n -e '288,340p' Yes, I know. From: Alexander Perry [EMAIL PROTECTED] [...] I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. xdm (for example) supports - local: the server is local and the management is local - foreign: the server is remote and we need to kick it - xdmcp: the server is remote and it will come to us I was wondering whether there was a way to request - remote: the server is local and management is remote I'd like xdm to deal with monitoring and restarting the server, yet not try to take control of that display. Alex.
Re: Prepackaged indirected X terminal
What, is it this problem you are trying to solve: #!/bin/sh h=$1 # hostname scp $h:.Xauthority . || xhost +$h while /bin/true do X -query $h done Your - remote: the server is local and management is remote line is the same as your foreign or xdmcp line from what I can see. Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: Alexander Perry [EMAIL PROTECTED] Subject: Re: Prepackaged indirected X terminal Date: Sat, 25 Nov 2000 23:25:17 -0800 From: Karl Hammar [EMAIL PROTECTED] $ man Xserver | sed -n -e '288,340p' Yes, I know. From: Alexander Perry [EMAIL PROTECTED] [...] I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. xdm (for example) supports - local: the server is local and the management is local - foreign: the server is remote and we need to kick it - xdmcp: the server is remote and it will come to us I was wondering whether there was a way to request - remote: the server is local and management is remote I'd like xdm to deal with monitoring and restarting the server, yet not try to take control of that display. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
Have you tried one of $ X -query otherhost $ X -broadcast $ X -indirect otherhost or $ man Xserver | sed -n -e '288,340p' XDMCP OPTIONS X servers that support XDMCP have the following options. See the X Display Manager Control Protocol specification for more information. -query host-name Enable XDMCP and send Query packets to the speci fied host. -broadcast Enable XDMCP and broadcast BroadcastQuery packets to the network. The first responding display man ager will be chosen for the session. -indirect host-name Enable XDMCP and send IndirectQuery packets to the specified host. -port port-num Use an alternate port number for XDMCP packets. Must be specified before any -query, -broadcast or -indirect options. -class display-class XDMCP has an additional display qualifier used in resource lookup for display-specific options. This option sets that value, by default it is "MIT-Unspecified" (not a very useful value). -cookie xdm-auth-bits When testing XDM-AUTHENTICATION-1, a private key is shared between the server and the manager. This option sets the value of that private data (not that it is very private, being on the command line!). X Version 11 Release 6.3 5 XSERVER(1) XSERVER(1) -displayID display-id Yet another XDMCP specific value, this one allows the display manager to identify each display so that it can locate the shared key. $ Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: Alexander Perry [EMAIL PROTECTED] Subject: Prepackaged indirected X terminal Date: Fri, 24 Nov 2000 13:30:46 -0800 I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
From: Karl Hammar [EMAIL PROTECTED] $ man Xserver | sed -n -e '288,340p' Yes, I know. From: Alexander Perry [EMAIL PROTECTED] [...] I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. xdm (for example) supports - local: the server is local and the management is local - foreign: the server is remote and we need to kick it - xdmcp: the server is remote and it will come to us I was wondering whether there was a way to request - remote: the server is local and management is remote I'd like xdm to deal with monitoring and restarting the server, yet not try to take control of that display. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
Have you tried one of $ X -query otherhost $ X -broadcast $ X -indirect otherhost or $ man Xserver | sed -n -e '288,340p' XDMCP OPTIONS X servers that support XDMCP have the following options. See the X Display Manager Control Protocol specification for more information. -query host-name Enable XDMCP and send Query packets to the speci fied host. -broadcast Enable XDMCP and broadcast BroadcastQuery packets to the network. The first responding display man ager will be chosen for the session. -indirect host-name Enable XDMCP and send IndirectQuery packets to the specified host. -port port-num Use an alternate port number for XDMCP packets. Must be specified before any -query, -broadcast or -indirect options. -class display-class XDMCP has an additional display qualifier used in resource lookup for display-specific options. This option sets that value, by default it is MIT-Unspecified (not a very useful value). -cookie xdm-auth-bits When testing XDM-AUTHENTICATION-1, a private key is shared between the server and the manager. This option sets the value of that private data (not that it is very private, being on the command line!). X Version 11 Release 6.3 5 XSERVER(1) XSERVER(1) -displayID display-id Yet another XDMCP specific value, this one allows the display manager to identify each display so that it can locate the shared key. $ Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 70 511 97 84 Computers Sweden Consulting --- From: Alexander Perry [EMAIL PROTECTED] Subject: Prepackaged indirected X terminal Date: Fri, 24 Nov 2000 13:30:46 -0800 I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Prepackaged indirected X terminal
I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prepackaged indirected X terminal
I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex.
