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
[ 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
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]
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
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]
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]
