829 lines
20 KiB
HTML
829 lines
20 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>The Terminals</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Mock Mainframe Mini-HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="The Individual Pieces"
|
|
HREF="x109.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="The Support Machines"
|
|
HREF="x337.html"></HEAD
|
|
><BODY
|
|
CLASS="section"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Mock Mainframe Mini-HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x109.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x337.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H1
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN187"
|
|
></A
|
|
>4. The Terminals</H1
|
|
><P
|
|
> The machines you use to connect to the mock mainframe should be
|
|
inexpensive, easy to maintain and, from a security point of view,
|
|
expendable.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN190"
|
|
></A
|
|
>4.1. Dual Boot Machines</H2
|
|
><P
|
|
> Some people — those without a time consuming job, a spouse, or children,
|
|
for example — will want to be able to spend lots of time playing hardware
|
|
intensive computer games. Although more and more games are coming out for
|
|
Linux, this usually means running a machine that has a closed source
|
|
operating system such as Microsoft Windows. The solution to this problem is
|
|
to set up the game computers as <EM
|
|
>dual boot machines</EM
|
|
>. The messy details
|
|
are usually handled automatically by whatever distribution you are using;
|
|
if not, check out the <EM
|
|
>Linux Installation Strategies mini-HOWTO</EM
|
|
> Tobby
|
|
Banerjee.
|
|
</P
|
|
><P
|
|
> The mock mainframe setup lets you keep the size and complexity of the Linux
|
|
partition on a dual boot machine to a minimum: All it has to do is to get X
|
|
running and connected. There are various way to do this, I usually just do
|
|
the following:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Go to <TT
|
|
CLASS="literal"
|
|
>/etc/X11/xdm/</TT
|
|
>. In the file <TT
|
|
CLASS="literal"
|
|
>Xservers</TT
|
|
>, comment out the line
|
|
that is either <TT
|
|
CLASS="literal"
|
|
>:0 local /usr/X11R6/bin/X :0 vt07</TT
|
|
> or something similar
|
|
by putting a hash mark ("#") at the beginning. This will stop the
|
|
computer from starting up X locally during boot time.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> In <TT
|
|
CLASS="literal"
|
|
>etc/inittab</TT
|
|
>, insert a new line such as (for SuSE 8.2)
|
|
<TT
|
|
CLASS="literal"
|
|
>xx:5:respawn:/usr/X11R6/bin/X -query <host></TT
|
|
> where "<host>" again is
|
|
the name of the mock mainframe. The "5" is the runlevel that boots
|
|
with X; "xx" is just a label I picked; you might have to adapt both to
|
|
your system <EM
|
|
>(please be careful:</EM
|
|
> Playing around with <TT
|
|
CLASS="literal"
|
|
>inittab</TT
|
|
> can
|
|
cause serious trouble). This will start X with a call to the mock
|
|
mainframe, and you should get the login window when you are on the
|
|
dual boot computer.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> Dual boot machines are nice if you don't have to switch between operating
|
|
systems too often. All of the rebooting can quickly become a bore, though,
|
|
and a dual boot machine cannot be considered truly expendable, given the
|
|
price of closed source operating systems.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN209"
|
|
></A
|
|
>4.2. Linux Terminals</H2
|
|
><P
|
|
> The <A
|
|
HREF="http://www.ltsp.org"
|
|
TARGET="_top"
|
|
>Linux Terminal Server http://www.ltsp.org</A
|
|
> (LTSP)
|
|
lets you use old hardware to put together bare-bones computers without hard
|
|
disks that run as thin clients. These machines are cheap, quiet, quick to
|
|
set up, and once they are running, require just about zero maintenance
|
|
(unless, say, a fan breaks). The LTSP has taken all kinds of awards and is being used in situations far more demanding than a small mock mainframe for your home. For example, Orwell High School in England used LTSP machines and IBM Blade Servers for their complete system (see
|
|
http://www.cutterproject.co.uk/Casestudies/orwell_high_school_cutter_case_study.php ). If you are going to have terminals that are in use constantly, it is hard to see how this would not be the best solution.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Required hardware.</STRONG
|
|
> More likely than not, somewhere in your cellar or
|
|
garage (or wherever you keep the stuff your partner lovingly calls "all
|
|
that crap"), you probably have a hopelessly outdated mainboard and
|
|
processor that you've been saving because you never know. Well, guess what.
|
|
</P
|
|
><P
|
|
> If you are using a 100 Mbit ("Fast") Ethernet network, stay above a 486DX;
|
|
a Pentium II should be fine. See if you can scrape together about 32 MByte
|
|
of RAM. You'll need a floppy drive for the initial phase. You'll also need
|
|
a decent graphics card and a monitor — "decent" doesn't necessarily mean a
|
|
AGP graphics card with 128 MByte RAM, it means a clear, crisp picture.
|
|
</P
|
|
><P
|
|
> The only thing you have to pay slightly more attention to is the network
|
|
card. Find one that has a socket to plug ROM chips in: a "bootable" network
|
|
card. You can get away with one that doesn't have the socket, but then you
|
|
have to keep booting from the floppy. We'll also need the unique number
|
|
(<EM
|
|
>Media Access Control</EM
|
|
> or MAC number) of the network card. On good cards,
|
|
it is included on a little sticker on the board and looks something like
|
|
this:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> 00:50:56:81:00:01
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> If you can't find it on the card, try booting the system with a Linux
|
|
rescue floppy or any other kernel. The number should be displayed during
|
|
boot when the card is detected.
|
|
</P
|
|
><P
|
|
> Add a keyboard and a case and that's it. Notice we don't have a hard disk,
|
|
let alone a CD-ROM. With the right kind of fans for the power supply and
|
|
the processor, you have a very quiet machine.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>How they work.</STRONG
|
|
>
|
|
</P
|
|
><P
|
|
> The LTSP home page has an in-depth technical discussion of what happens
|
|
when the system powers up. In brief, human terms:
|
|
</P
|
|
><P
|
|
> When turned on, the Linux Terminal, like any other computer, looks around
|
|
to see what it has been given in way of hardware. It finds a network card
|
|
with a MAC and notices that it has a floppy with a boot disk (<EM
|
|
>or</EM
|
|
> a boot
|
|
ROM in the network card.) It starts the boot program. This in effect tells
|
|
the Linux Terminal:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="literallayout"
|
|
> Got your MAC? Good. Now scream for help as loud as you can.
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> The terminal's call goes through the whole (local) network. On the mock
|
|
mainframe, a program called <TT
|
|
CLASS="literal"
|
|
>dhcpd</TT
|
|
> (<EM
|
|
>Dynamic Host Configuration Protocol
|
|
Server Daemon</EM
|
|
>) is listening. It compares the MAC the terminal sent to a
|
|
list of machines it has been told to take care of, and then sends the
|
|
terminal an answer that includes an IP address and a location where the
|
|
terminal can get a kernel. The terminal then configures itself with its
|
|
new name.
|
|
</P
|
|
><P
|
|
> Using some more code from the boot program, the terminal starts a program
|
|
called <TT
|
|
CLASS="literal"
|
|
>tftp</TT
|
|
> (<EM
|
|
>Trivial File Transfer Protocol</EM
|
|
>, a stripped-down version of
|
|
the venerable <TT
|
|
CLASS="literal"
|
|
>ftp</TT
|
|
>. This downloads the kernel from the host machine. The
|
|
terminal then boots this kernel.
|
|
</P
|
|
><P
|
|
> Like every other Linux system, the terminal needs a root filesystem.
|
|
Instead of getting it from a harddisk, it imports it from the mock
|
|
mainframe via <TT
|
|
CLASS="literal"
|
|
>NFS</TT
|
|
> (<EM
|
|
>Network File System</EM
|
|
>). If the terminal has very
|
|
little memory, it can also mount a swap partition this way. The terminal
|
|
then starts X, connects to the mock mainframe via <TT
|
|
CLASS="literal"
|
|
>xdm</TT
|
|
>, and throws up the
|
|
login screen.
|
|
</P
|
|
><P
|
|
> This all happens amazingly fast. If you turn off all of the various BIOS
|
|
boot checks on the terminal and boot off of an EPROM in the network card
|
|
instead of a floppy, it happens even faster.
|
|
</P
|
|
><P
|
|
> Running <TT
|
|
CLASS="literal"
|
|
>dhcpd</TT
|
|
>, <TT
|
|
CLASS="literal"
|
|
>tftpd</TT
|
|
>, and <TT
|
|
CLASS="literal"
|
|
>nfsd</TT
|
|
> on the mock mainframe is a
|
|
security risk you might not be willing to take. In the chapter on Support
|
|
Machines, we'll show a way of getting around this.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Setting up the software.</STRONG
|
|
> On the server (mock mainframe) side, you need to
|
|
install <TT
|
|
CLASS="literal"
|
|
>nfsd</TT
|
|
> <TT
|
|
CLASS="literal"
|
|
>tftpd</TT
|
|
>, and <TT
|
|
CLASS="literal"
|
|
>dhcpd</TT
|
|
>, which your distribution should include
|
|
as standard packages.
|
|
</P
|
|
><P
|
|
> Leave their configuration files untouched for now. The LTSP configuration
|
|
and installation programs will do most of the work for you. Some files you should be aware of:
|
|
</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="variablelist"
|
|
><DL
|
|
><DT
|
|
><TT
|
|
CLASS="literal"
|
|
>/etc/dhcpd.conf</TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
> Provide the IP address of the terminal, the hostname, the IP address
|
|
of the mock mainframe, the MAC of the terminal, and the default
|
|
gateway. Check to see if the kernel pathname is correct.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="literal"
|
|
>/opt/ltsp/i386/etc/lts.conf</TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
> These options control the terminal itself.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="literal"
|
|
>/etc/hosts</TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
> The names of the Linux Terminals and their IP addresses must be
|
|
listed here. Further down, while describing the network, we'll
|
|
introduce a systematic naming convention to make this easier.
|
|
</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="literal"
|
|
>/etc/hosts.allow</TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
> Though not mentioned in the current LTSP documentation, you probably
|
|
will have to add the following lines to this file:
|
|
<TT
|
|
CLASS="literal"
|
|
>rpc.mountd : <terminal> : ALLOW</TT
|
|
>
|
|
<TT
|
|
CLASS="literal"
|
|
>rpc.mountd : ALL : DENY</TT
|
|
>
|
|
where "<terminal>" is the terminal's IP address. This tells the host
|
|
to allow the terminal to mount the NFS file system.
|
|
</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
> Creating a boot floppy for the Linux Terminal is usually trivial. Armed
|
|
with your type of Ethernet card, go to the website mentioned in the LTSP
|
|
documentation (currently Marty Connor's
|
|
<A
|
|
HREF="http://www.rom-o-matic.net/"
|
|
TARGET="_top"
|
|
>ROM-O-Matic Website http://www.rom-o-matic.net/</A
|
|
>,
|
|
and follow the instructions for a boot
|
|
floppy. This should produce a file of a few dozen kilobytes that you can
|
|
then put on a floppy and boot from. Later, when you are sure that your
|
|
hardware configuration is not going to change and your setup works, replace
|
|
the floppy by an EPROM that you plug into your Ethernet card.
|
|
</P
|
|
><P
|
|
> If you have a more modern motherboard on your Terminal machine, you might be able to get around all of this by selecting "PXE" (<EM
|
|
>Pre-eXecution Environment</EM
|
|
>), "MBA" (<EM
|
|
>Management Boot Agent</EM
|
|
>) or "Network" from the boot sequence (CMOS) menu.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Using the terminals.</STRONG
|
|
> Just how many Linux Terminals can one mock mainframe
|
|
support? The LTSP documentation gives the following example:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="literallayout"
|
|
> It's not unusual to have 40 workstations [Linux Terminals], all running
|
|
Netscape and StarOffice from a Dual PIII-650 with 1GB of ram. We know
|
|
this works. In fact, the load-average is rarely above 1.0!
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> (This part of the documentation was written in March 2002, hence the
|
|
reference to Netscape, an ancestor of Mozilla FireFox. StarOffice is a
|
|
commercial variant of OpenOffice.org.)
|
|
</P
|
|
><P
|
|
> Linux Terminals will probably require some user education. People who have
|
|
only ever used Windows tend to have trouble visualizing a system where the
|
|
graphics layer is not only independent from the rest of the operating
|
|
system, but can also be accessed from multiple screens. The best way to
|
|
explain this is with examples. One trick that people new to X just love is
|
|
when programs start on one terminal and then appear on a different one. To
|
|
enable this (<EM
|
|
>but only in a safe environment!</EM
|
|
>), sit
|
|
down at a terminal and type
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> xhost +<host>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> where "<host>" is the name of the mock mainframe. Then, move to a different
|
|
terminal and start a program such as <TT
|
|
CLASS="literal"
|
|
>xeyes</TT
|
|
> or <TT
|
|
CLASS="literal"
|
|
>xroach</TT
|
|
>:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> xeyes -display <terminal>:0 &
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> The eyes should appear on the first terminal's monitor, providing endless
|
|
amusement for all. When you are done explaining what happened, remember to
|
|
retract the privileges again on the first terminal with
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> xhost -<host>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> You can also use this example to point out why it is dangerous to use the
|
|
<TT
|
|
CLASS="literal"
|
|
>xhost</TT
|
|
> command.
|
|
</P
|
|
><P
|
|
> Another question that usually comes up is the speed of Linux Terminals.
|
|
One nice way to demonstrate this is to run a series of screen savers from
|
|
the <TT
|
|
CLASS="literal"
|
|
>xlock</TT
|
|
> suite. For example
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> xlock -inwindow -mode kumppa
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> or more generally
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> xlock -inwindow -mode random
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Though the results will depend on your hardware, this usually takes care of
|
|
any doubts.
|
|
</P
|
|
><P
|
|
> If you are using a desktop such as KDE that allows you to shut down the
|
|
computer when you log off, make sure that this function is disabled.
|
|
Otherwise, your users will shut down the mock mainframe when trying to get
|
|
out of the terminal. Tell them to <EM
|
|
>just turn off the power</EM
|
|
> once they have
|
|
logged out. Older users will feel a sense of nostalgia, and younger users
|
|
will stare at you as if you have gone mad. Such is progress.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN300"
|
|
></A
|
|
>4.3. Real X Terminals</H2
|
|
><P
|
|
> If fortune smiles on you or you are rich, you might find yourself with a
|
|
real thin client. Installing one is usually not much different than
|
|
setting up a Linux Terminal, except that you will need the software from
|
|
the vendor, you will probably have to pay for support, and when something
|
|
goes wrong, you won't be able to fix it yourself.
|
|
</P
|
|
><P
|
|
> The Linux Documentation Project has a number of general and special HOWTOs
|
|
on how to set up X Terminals, for example the <EM
|
|
>Connecting X Terminals to
|
|
Linux Mini-HOWTO</EM
|
|
> by Salvador J. Peralta or the <EM
|
|
>NCD-X-Terminal
|
|
Mini-HOWTO</EM
|
|
> by Ian Hodge.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN306"
|
|
></A
|
|
>4.4. X11 Forwarding with ssh</H2
|
|
><P
|
|
> If you are on a machine that already supports X, you might be able to use the X11 Forwarding function of the Secure Shell (<TT
|
|
CLASS="literal"
|
|
>ssh</TT
|
|
>) program. This is invoked with
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> ssh -X <HOST>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> and creates a cryptographically protected tunnel to the host machine. X forwarding has to be configured on both machines — in <TT
|
|
CLASS="literal"
|
|
>/etc/ssh/sshd_config</TT
|
|
> on the host machine, <TT
|
|
CLASS="literal"
|
|
>X11Forwarding</TT
|
|
> must be set to <TT
|
|
CLASS="literal"
|
|
>yes</TT
|
|
> — and it can be a little clumsy to use every day. However, for quick and dirty work, this is a good alternative.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN315"
|
|
></A
|
|
>4.5. X Server Programs</H2
|
|
><P
|
|
> As a final way of connecting to the mock mainframe, there are "X server"
|
|
programs that run under different operating systems (remember, the X server
|
|
powers the terminal side of things). These let you log onto Linux machines
|
|
with an operating system that does not natively run X.
|
|
</P
|
|
><P
|
|
> Most X servers for <STRONG
|
|
>Windows</STRONG
|
|
> cost money, in some cases a lot of money. The
|
|
single <A
|
|
HREF="http://cygwin.com/xfree/"
|
|
TARGET="_top"
|
|
>Cygwin http://cygwin.com/xfree/</A
|
|
>, which
|
|
ports X (and GNU tools) to Windows machines.
|
|
</P
|
|
><P
|
|
> If you have an <STRONG
|
|
>Apple</STRONG
|
|
> computer with OS X, you are in better shape. For OS 10.3 "Panther", you need to install the X11 package from the installation disks. Then, with any text editor, create an executable bash shell script such as:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> #!/bin/bash
|
|
/usr/X11R6/bin/X -terminate -query "<HOST>" :1
|
|
exit
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> Note the window number is :1, because :0 is used by Aqua. Do not use the X11 Server in
|
|
<TT
|
|
CLASS="literal"
|
|
>/Applications/Utilities/X11.app/Contents/MacOS/X11</TT
|
|
>, as this doesn't understand the <TT
|
|
CLASS="literal"
|
|
>-query</TT
|
|
> command: Apple doesn't seem to want people to run remote Aqua sessions. Then, tell the firewall what you are up to (you do have the firewall on, don't you): In <TT
|
|
CLASS="literal"
|
|
>SystemPreferences -> Sharing -> Firewall</TT
|
|
> create an new entry "X
|
|
Window System" for Port 6001 (not: 6000). Then, move the shell script icon to wherever you want to keep it. To start an X session, click on the icon. An "EXEC"-icon called "X" will appear in the Dock. Click on this. Enjoy your connection. To get out again, press <TT
|
|
CLASS="literal"
|
|
>Command-Option-a</TT
|
|
>. (Note: This has not been tested with Mac OS X 10.4 "Tiger")
|
|
</P
|
|
><P
|
|
> You can also check the <A
|
|
HREF="http://www.xdarwin.com/"
|
|
TARGET="_top"
|
|
>XDarwin http://www.xdarwin.com/</A
|
|
> project. XDarwin is an Apple version of the X Window System that sits on the Darwin
|
|
operating system — a variant of BSD — that is the core of OS X.
|
|
</P
|
|
><P
|
|
> (There is one GPL X Server written in <STRONG
|
|
>Java</STRONG
|
|
> you might try:
|
|
<A
|
|
HREF="http://www.jcraft.com/weirdx/"
|
|
TARGET="_top"
|
|
>Weirdx http://www.jcraft.com/weirdx/</A
|
|
>,
|
|
though the author points out it is not made for heavy loads.)
|
|
</P
|
|
><P
|
|
> In this chapter, we have examined terminals that will give you a GUI
|
|
(<EM
|
|
>graphical user interface</EM
|
|
>). If you are tough enough, you can also hook up
|
|
a text terminal to your mock mainframe and access the system via a CLI
|
|
(<EM
|
|
>command line interface</EM
|
|
>). This option is covered further down.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x109.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x337.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>The Individual Pieces</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>The Support Machines</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |