[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
X Terminals help appreciated
>>>>> Steve == Steve Tickle <s.tickle [at] quarndon.co.uk> writes:
Steve> Many of the computer illiterate here, log on to that system
Steve> via VT100 terminals, and it is for this reason that I think
Steve> any Linux set up we go to would best be as a main server
Steve> with user access via PC as X Terminals.
You're planning to do those over ethernet, right? Serial lines could
be done, but you'd need to get into complications with lbx (low
bandwidth X, which for those of you who haven't tried it makes text
editing over a 14.4kb line in a native Emacs X frame pleasant---you
English speakers may not need it, but if you're doing multilingual
editing or Asian scripts it makes life a whole lot easier).
I think this is an excellent way to go. Not only can you use your
current terminal-based software in xterms, but you can start adding
point-and-click style utilities using any of several scripting
languages, with GUI interface (Perl has a GUI binding, Python has
several, Tcl/Tk is also available). I would say sorta like Visual
Basic except I have no idea since I have committed no sin serious
enough to require that kind of penance.
Steve> This system is not so drastically different from the Nova
Steve> system.
Right. In fact, the Nova can either be networked or accessed by Linux
boxes through the serial ports. You could, without too much trouble,
arrange for a Linux box with a multiport serial card to just translate
network connections to serial connections. I don't know how hard your
port would be (Nova to Linux) for the main applications, this wouldn't
be too expensive and probably could be done fairly easily.
Steve> I am currently trying to configure a Linux OS'ed PC to
Steve> access another by this method (using xdm) but am struggling
Steve> to find the right level of documentation to do this. As a
Steve> Linux newbie I don't have the prior depth of knowledge
Steve> assumed by some of the HOWTOs etc.
The Linux Administrator's Guide and Linux Network Administrator's
Guide are available both in printed form as regular books and as
online docs; check your package listing in your distribution for the
online versions, they're surely there.
I'm not sure from what you write why you're struggling; the following
may be a lot more elementary than you need.
The basic experimental setup you should start with looks like this:
1. Two PCs with network connection between them. I would suggest a
standalone LAN with a single hub, each with an /etc/hosts that looks
like
localhost 127.0.0.1
pc1 192.168.0.1
pc2 192.168.0.2
Once the computers are booted, set up the network by hand:
# # on pc1 as root
# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.0
# route add -net 192.168.0.0 eth0
# # on pc2 as root
# ifconfig eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.0
# route add -net 192.168.0.0 eth0
You can worry about proper network configuration later.
2. A vanilla Linux installation on each, including the standard
xserver packages and xclient packages. Check /etc/inetd.conf on
both for telnetd so you can log in from one to the other. The
installation should start you with xdm on most distributions, dunno
mandrake, though.
3. Do `xhost +' on both hosts. _Don't do this ever once you've got
them hooked to a network._ Read the man page and figure out how
you want to handle it then. But for now it's convenient.
4. On pc1, open an xterm and do
pc1$ telnet pc2
<login>
pc2$ xclock -display pc1:0.0
pc2$
5. On pc2, enable rshd in /etc/inetd.conf. You can probably do this
just by uncommenting it. You'll need to be root to edit that file.
(This is a potential security problem once you are hooked to the
internal net, and especially if you're on the Internet.) On pc1 do
pc1$ echo pc2 >> ~/.rhosts
pc1$ rsh pc2 'oclock -display pc1:0.0 '
pc1$
This is a primitive way to arrange that an application on the server
starts up with display to your local machine.
Once you've gotten this far, you can start thinking about how you want
to scale up to real applications running on a remote host.
You could, especially if you're very security conscious, turn pc1 (the
client workstation in the example) into a pure X terminal with no
local programs to speak of. Then manage it with xdm on the server
(pc2 in the example). But I don't think this is necessary. Operating
all of the PCs as full-fledged workstations, even if your users never
need it, is probably just as cheap and easier to configure.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
What are those two straight lines for? Free software rules.
Start your own FREE mailing list at
© 2000 Microsoft Corporation. All Rights Reserved