--
X Window is X Window. The answer is yes.
--
JP
JP, could you point me to some info on how to do this?
>I'm using Corel Linux
Why Corel?
Oh yeah, they include a cute little stuffed penguin inside their
gigantic shelf-hogging box. Let me guess... you also went to Linux
World Expo in SJ. I thought the devils horns the BSDI guys were
giving away were cool. No pocket protectors this year.
>and I'm wondering if its
>possible to use this as an X client to run a
>scologin to a SCO 5.0.5 box?
Sure.
Some potential headaches:
How can I turn off the XDMCP facility provided by
scologin?
http://www.sco.com/cgi-bin/ssl_reference?109077
I've installed a non-standard shell, but now I can't log
in with scologin.
http://www.sco.com/cgi-bin/ssl_reference?110222
--
Jeff Liebermann je...@comix.santa-cruz.ca.us
150 Felker St #D Santa Cruz CA 95060
831-421-6491 pager 831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/ SCO stuff
man X, man scologin; pattern-search on display. Edit your /etc/Xn.hosts
file(s).
TA 109158 discusses this for scohelp, but scologin will work the same
way.
--
JP
>>I'm using Corel Linux
> Why Corel?
> Oh yeah, they include a cute little stuffed penguin inside their
> gigantic shelf-hogging box. Let me guess... you also went to Linux
> World Expo in SJ. I thought the devils horns the BSDI guys were
> giving away were cool. No pocket protectors this year.
It is a cute penguin, my sister has it sitting on top of her computer
monitor. The reason I'm using Corel is because it came with the
oss sound drivers, which are about $50 if I had to buy them. I need
those drivers to get my Yamaha onboard sound to work. Secondly it
came with Word Perfect. Also it has a nice file manager for browsing
network shares. My second choice would be Caldera, but for the reasons
listed I'm using Corel for now.
>>and I'm wondering if its
>>possible to use this as an X client to run a
>>scologin to a SCO 5.0.5 box?
> Sure.
> Some potential headaches:
> How can I turn off the XDMCP facility provided by
> scologin?
> http://www.sco.com/cgi-bin/ssl_reference?109077
This looks like something to do if I don't want to run a
scologin remotely. I do want to run it remotely from the
Linux box.
>
> I've installed a non-standard shell, but now I can't log
> in with scologin.
> http://www.sco.com/cgi-bin/ssl_reference?110222
I think this is if I installed bash on the SCO box, which
I didn't do.
I've ran a scologin remotely on a Win98 computer running
Xvision. How do I do this from a Linux box without using
a program like Xvision?
>TA 109158 discusses this for scohelp, but scologin will work the same
>way.
Typo error.
Try:
How to set up SCOhelp to display on a remote host.
http://www.sco.com/cgi-bin/ssl_reference?109058
yes
the basic functionality goes like this:
start X on the linux box
open an xterm and type "xhosts +"
telnet to sco box
run any X application, try scoadmin or anything else in /usr/bin/X11.
it takes a while, even if both you and the sco box have cable-modem/dsl net
connections, for the window to first appear, after that it's basically
pretty useable on a good connection.
in real life however, instead of "xhosts +" you would read the man pages
associated with xhosts and xauth, and put something in your .Xdefaults or
.xinitrc (on linux) to the tune of "xhosts + <sco box>" (I think), to allow
just that box to connect to your x server. xhosts + by itself allows anyone
to display things on your display.
I've just been working on a few customers machines from home by doing this.
to run scologin... I guess you could do that, but I think it'd be a lot more
efficient to just run the programs you want. if you want the whole desktop,
then do like above, but run /usr/bin/X11/xdt3 on the sco box.
--
Brian K. White http://www.squonk.net/users/linut
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
That is how I have done it in the past using X under OS/2, and also on RH6
Wayne
"Chad Lemmen" <ch...@lemmen.com> wrote in message
news:8njid...@news2.newsguy.com...
> yes
> the basic functionality goes like this:
> start X on the linux box
> open an xterm and type "xhosts +"
> telnet to sco box
> run any X application, try scoadmin or anything else in /usr/bin/X11.
It tryed to start the X session on display 0, but that is already in
use by kde. I'm not sure how to specify that it use display 1.
There must be a way to redirect the output to a different display.
> it takes a while, even if both you and the sco box have cable-modem/dsl net
> connections, for the window to first appear, after that it's basically
> pretty useable on a good connection.
> in real life however, instead of "xhosts +" you would read the man pages
> associated with xhosts and xauth, and put something in your .Xdefaults or
> .xinitrc (on linux) to the tune of "xhosts + <sco box>" (I think), to allow
> just that box to connect to your x server. xhosts + by itself allows anyone
> to display things on your display.
> I've just been working on a few customers machines from home by doing this.
> to run scologin... I guess you could do that, but I think it'd be a lot more
> efficient to just run the programs you want. if you want the whole desktop,
> then do like above, but run /usr/bin/X11/xdt3 on the sco box.
> --
> Brian K. White http://www.squonk.net/users/linut
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
--
Thanks this worked, but I had to type:
X :1 -query ip_of_sco_XDMCP_box or
X :1 -broadcast
I needed to specify display :1 because kde is running on
:0, so when it tryed to start it on :0 if failed.
I tryed it with and without the -bpp. That sets
the number of bits per pixel and defaults to 8.
It seems to work either way so I just left it off.
you don't need a different display. to get another display, you need to run
another x server process. 99% sure that your startx script is not fancy
enough to automatically handle running more than one xserver process at
once, but it doesn't mean you can't do it.
do "man xinit" and man startx
there are a couple options here:
1) best option: don't run the whole desktop, just run individual programs,
or at least, only run xdt3 and not pmwm and not scologin. xdt3 provides the
taskbar on top and the icons and the file manager, and does not conflict
with your existing window manager fataly. It is a neusance howver, because
it draws on the root window the same as k<something> does. the reason is
because xdt3 is no the window manager, there can only be one window manager
at a time. Also You don't want to run the window manager over the network
anyways. the window manager should always be local to the display, just run
the programs over the net. The reason I purposefully didn't mention
anything about the DISPLAY setting, was because when you log in to another
host from an xterm, the correct DISPLAY is already set for you. You just run
an X program on the remote host, and it displays on your screen. If it
doesn't
you need to check two things:
- did you run "xhost +" first? (on your machine, not on the remote machine)
- possibly the display did not get set correctly for you on the remote end.
verify that it is "HOST-or-IP:0.0" and not simply ":0.0" or worse,
"localhost:0.0". set (and export) DISPLAY to <IP of your machine>:0.0" if it
isn't already. On you machine, in an xterm it is supposed say ":0.0"
(otherwise local programs will use TCP instead of unix sockets to talk to
your own screen), but in the telnet session to the remote machine it should
be a full display with a hostname or IP.
2) next best option: run an xnest xserver within your current x session.
xnest is a special xserver that provides another display, which is a whole x
session of it's own that takes place in a window in you current x session. I
*think* in this case, the display will be "[host]:0.1" and further xnests.
.2 .3 .4 atc... I think.
Using this, you could run the whole desktop, including pmwm (the window
manager)
and since it is in a window of your current session, I think you can cut &
paste from the xnest session to the parent one. I've never used xnest, so no
detailed walk-through here. "man xnest", http://www.google.com/ "xnest"
3) not so great option (IMO), run another X session on another console, with
no window manager. Do this by switching to console 2 (ctrl-alt-F2), do
something like:
xinit -- ":1.0"
it should start up with a single xterm window and no window manager. use
the xterm to telnet to the remote host and run the full X session. Don't try
to set the display, it should be correct by itself.
note: be sure that there are existing tty device files numbered higher than
the one your current X session is using. if the X session is using tty7 then
be sure there is a tty8 or higher that is not already being used for getty
or perhaps system messages. (just now I had to do "mknod -m 600 /dev/tty13 c
4 13" to test the above command because i have consoles 1-10 available for
login, 11 was X, and 12 is syslog :)
The original X session will still be on console 7 (on most stock linux
distributions) and the new one will be on console 8, so it's ctrl-alt-F7/F8
to switch between them.
The reason this option is "not so great", is the this is a whole seperate
session. aside from hogging unnecessary resources, you can't cut & paste
across the sessions, and it's somewhat of a pain to try and read docs in a
netscape window on your linux session, and switch back and forth to the SCO
session trying to test what your reading, for example.
4) by now I forgot what the fourth option was. I'm sure there was one, but
it was not desirable.
Really though Just do like I originally suggested, (same as option 1 above).
For one thing, using that method, you could have 10 windows open to 10
different hosts at the same time with no more fuss than opening up more
xterms. imagine trying to deal with 10 full X sessions on 10 different
consoles...
> > it takes a while, even if both you and the sco box have cable-modem/dsl net
> > connections, for the window to first appear, after that it's basically
> > pretty useable on a good connection.
>
> > in real life however, instead of "xhosts +" you would read the man pages
> > associated with xhosts and xauth, and put something in your .Xdefaults or
> > .xinitrc (on linux) to the tune of "xhosts + <sco box>" (I think), to allow
> > just that box to connect to your x server. xhosts + by itself allows anyone
> > to display things on your display.
>
> > I've just been working on a few customers machines from home by doing this.
>
> > to run scologin... I guess you could do that, but I think it'd be a lot more
> > efficient to just run the programs you want. if you want the whole desktop,
> > then do like above, but run /usr/bin/X11/xdt3 on the sco box.
>
> > --
> > Brian K. White http://www.squonk.net/users/linut
> > +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> > filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
>
> --
On Corel comand prompt (NOT X) :
xinit
In Corel Xterm Window:
xhost SCObox
telnet (or ssh or rlogin, etc..) SCObox
(login to the SCObox)
DISPLAY=Corel:0.0
export DISPLAY
startx -t
------------------------------
All this where Corel is the name or IP address of the Corel Linux Box and where
SCObox is the name or IP address of the SCO Unix Box. This should get you
right in as it works at my house :-)
-Linc.
The DISPLAY variable was the problem. It was set to chad.lemmen:0. I change
it to <IP address>:0 and then if I type scoadmin it starts up the X program
scoadmin right on my kde linux desktop. I suppose if I put chad.lemmen into
/etc/hosts on my SCO box it would work also.
The other thing that did work was 'X :1 -broadcast' this starts a scologin
on display 1 so to switch between displays I have to to ctrl-alt-f7 and
ctrl-alt-f8
--