LDP/LDP/howto/docbook/Mock-Mainframe.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

<article id="Mock-Mainframe">
<articleinfo>
    <title>The Mock Mainframe Mini-HOWTO</title>
    <date>06. October 2005</date>
    <author>
        <firstname>Scot</firstname>
        <othername>W.</othername>
        <surname>Stevenson</surname>
        <affiliation><address><email>scot@possum.in-berlin.de</email></address></affiliation>
    </author>
    <authorinitials>SWS</authorinitials>

<revhistory id="revhistory"><revision><revnumber>1.2</revnumber><date>06. October 2005</date><authorinitials>SWS</authorinitials></revision></revhistory>

</articleinfo>
<simpara>
A brief description of a standard way to set up and work with a computer
network for a small group of people that is inexpensive to build, easy to
administer, and relatively safe. It is written for users who might not be
completely familiar with all of the concepts involved.
</simpara>

<section>
<title>Introduction</title>
<section>
<title>Copyright and License</title>
<simpara>
This document, <emphasis>The Mock Mainframe Mini-HOWTO</emphasis> is copyrighted (c) 2003-2005 by
<emphasis>Scot W. Stevenson</emphasis> Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is available at
<ulink url="http://www.gnu.org/copyleft/fdl.html">GNU Copyleft</ulink>
</simpara>

</section>
<section>
<title>Disclaimer</title>
<simpara>
No liability for the contents of this document can be accepted.  Use the
concepts, examples and information at your own risk.  There may be errors
and inaccuracies that could be damaging to your system. Although this is
highly unlikely, the author does not take any responsibility. Proceed with
caution.
</simpara>

<simpara>
All copyrights are held by their by their respective owners, unless
specifically noted otherwise. Use of a term in this document should not be
regarded as affecting the validity of any trademark or service mark. Naming
of particular products or brands should not be seen as endorsements.
</simpara>

</section>
<section>
<title>Credits</title>
<simpara>
This document has benefitted greatly from the feedback, commentary, and
corrections provided by the following people among others:
</simpara>

<simpara>
Gareth Anderson, Jonathan Clark, Jim Dennis, Adam Hawes, Doug Jensen,
Jim McQuillan, Volker Meyer, Binh Nguyen, Douglas K. Stevenson, Paul Sunners
</simpara>

</section>
<section>
<title>Feedback</title>
<simpara>
Feedback is most certainly welcome for this document. Please send your
additions, comments and criticisms to the following email address:
scot@possum.in-berlin.de. Feedback can be in English or German.
</simpara>

</section>
<section>
<title>Translations</title>
<simpara>
There are currently no translations.
</simpara>

</section>
<section>
<title>Future Versions</title>
<simpara>
At some point in 2004, my wife and I realized that we were spending so much time
on the road that it made more sense to move all our stuff to laptops. The
home network has been restructured accordingly. In other words, the
maintainer of the Mock Mainframe HOWTO isn't using a mock mainframe
anymore, which means I am looking for somebody who is to take over this document. Volunteers are welcome to email me at the address given above.
</simpara>

</section>
</section>
<section>
<title>Background</title>
<section>
<title>Why This Text?</title>
<simpara>
In the last decade of the past millennium, I moved out of my parents' house
and into a small apartment with my girlfriend. I left behind not only the
comfort of a magically refilling refrigerator, but also a computer network
that suddenly had to survive daily and sometimes creative usage by my mom,
dad, and kid sister for months without me. After some gentle persuasion, my
girlfriend not only switched from Windows to Linux, but also became my
fiancee. I left grad school and got a real job, which left me with even
less time to fool around even with my &#8212; er, <emphasis>our</emphasis> &#8212; network, let alone my
parents' computers. My fiancee became my wife, we left the apartment for a
small house, and then I found myself spending more time changing diapers
than floppies.
</simpara>

<simpara>
In other words, somewhere along the way, I turned into an adult.
</simpara>

<simpara>
It happens to the best of us, I'm told, and there are benefits that go
beyond a <emphasis>de facto</emphasis> unlimited budget for ice cream.  Having all the time in
the world to keep computers running, however, is not one of them. I needed
some sort of setup for the systems I am responsible for that is
</simpara>

<simpara>
<emphasis role="strong">Easy to administer.</emphasis> I don't have the time to do the same thing on three
different machines, or figure out which machine needs which patch. Ideally,
I only have to take care of one single computer in each network, and that
infrequently. Some of the computers should not require <emphasis>any</emphasis> maintenance at
all for months at a time.
</simpara>

<simpara>
<emphasis role="strong">Easy to afford.</emphasis> My hardware budget now competes with house payments, food
bills, and the cost of clothes that my daughter seems to grow out of faster
than we can buy them. Getting more done with less is not just an
intellectual challenge, but a pressing necessity.
</simpara>

<simpara>
<emphasis role="strong">Easy to secure.</emphasis> The network's very structure should make it harder for
outsiders to do evil things, and, more important, make it easy for me to
create a safe "lock-down" state where threats are minimal
until I find the time to patch holes.
</simpara>

<simpara>
After a few years of trial and error and a lot of time spent thinking about
setting up computers while rocking screaming babies in the middle of the
night, I created a "standard" setup. It is not a terribly clever or
ingenious way of doing things, and there are probably thousands of systems
out there organized along exactly the same lines.  The aim of this text is
to present this setup in a coherent form so that other people don't have to
invent the wheel all over again when faced with the same problem.
</simpara>

</section>
<section>
<title>Reasoning and Overview</title>
<simpara>
Most desktop computers nowadays are insanely overpowered for what they are
doing most of the time: Email, surfing, and text processing, while maybe
listening to music.  Unless you are still using a 486DX at 66 MHz, your
processor is probably bored out of its registers even if it is doing all of
this at once. Check any program that shows the system load &#8212; such as
<literal>xload</literal>, <literal>top</literal>, or <literal>uptime</literal> &#8212; and you'll see just how much of your
expensive hardware is busy doing nothing.
</simpara>

<simpara>
With all of those resources left over, there is no technical reason why
more than one person can't use the computer at the same time. This concept
seems strange and downright alien to most home users today, thanks in no
small part to Microsoft's philosophy of "a computer on every desktop" and
the hardware companies' ad campaigns that imply that you are, among other
things, sexually inadequate if you don't have your very own super-charged
computer under your desk.
</simpara>

<simpara>
There are good commercial reasons for hard- and software companies not to
like <emphasis>multiuser</emphasis> setups. Even if you have to upgrade the central machine,
you are going to need less high-quality hardware than if everybody has
their own computer; and if four people could use one Windows machine at the
same time, that would be three copies less for Microsoft to make money on.
You obviously don't save money if you just install Linux on one machine
instead on four, but your hardware costs and administration time will drop.
</simpara>

<simpara>
Of course there are other reasons than big company ad pressure why few
people have multiuser setups.  One is computer games: Many of them suck up
so much hardware that a multiuser-system is usually not the best idea.
Also, until a short time ago, there was no easy way to actually have more
than one person log on, since most desktop computers come with only one
keyboard, one mouse, and one monitor.  This has changed: You can now create
inexpensive and reliable graphic terminals (also known as <emphasis>thin clients</emphasis>)
with very little hassle and expense. This allows us to get away with one
big machine and a couple of little ones. Last but not least, sharing a
machine means you have to behave and get along with other users.
</simpara>

<simpara>
In a nutshell, this text is about <emphasis>centralizing small computer systems to save time and money</emphasis>. The mainframe vendor IBM wants us to believe that
this is just what the big boys are doing, too.  Now that the age of server
mania is over, they say, companies are moving stuff back onto those
mainframes.  Since more and more of those mainframes are running roughly
the same Linux you have at home, the only difference between a real
mainframe and your computer is a bit of hardware. A few hundred thousand
dollars worth of hardware at least, granted, but that doesn't mean that you
can't use the same design principle and enjoy the benefits of a "little"
mainframe &#8212; a "mock" mainframe, if you will.
</simpara>

<simpara>
The basic setup has three parts:
</simpara>

<simpara>
<emphasis role="strong">The Mock Mainframe</emphasis>. The one and only core machine. All users access this
computer, either by sitting in front of it or (more likely) from a
terminal, and they can do so at the same time. In the simplest setup, this
machine is home to all users, holds all files, and runs all programs.
</simpara>

<simpara>
<emphasis role="strong">The Terminals.</emphasis> What the user actually touches. Cheap, easy to maintain,
and expendable, they can be dual-boot machines, Linux Terminals, thin
clients, or even X Window server programs for other operating systems.
</simpara>

<simpara>
<emphasis role="strong">Support Machines.</emphasis> Optional computers that perform a special task that for
reasons of security or performance you'd rather not have on the mock
mainframe. The most common support machine is a "guardian" that handles
Internet connections.
</simpara>

<simpara>
Parts of this text will deal with installing software that is covered in
far greater detail in other Linux HOWTOs.  Caught between the extremes of
just referring to those texts and copying everything, I have decided to
give a very brief description of the installation procedure on a standard
system.  You'll get a general idea of what needs to be done, but for the
details, you'll need the specialized text.  This does mean that there are a
<emphasis>lot</emphasis> of references, but that just goes to show how much
I am standing on the shoulders of others here.
</simpara>

<simpara>
(Various nice people have suggested various ways of combining the basic idea with VNC. After reading their explanations and studying the documentation, I have realized that I am too out of my depth here to give sensible advice. This would be the first project for the next caretaker of this document.)
</simpara>

</section>
<section>
<title>What You Should Be Aware Of</title>
<simpara>
A mock mainframe setup is not for everybody. It is based on the following
assumptions:
</simpara>

<simpara>
<emphasis role="strong">A small group of users.</emphasis> Though it should scale well from a family setup
to at least a classroom full of people (depending on the hardware and
programs used), this is not something you want to run a university or
Fortune-500-company with.  If you are alone, it doesn't make much sense
either. Go find somebody to move in with, then read on.
</simpara>

<simpara>
<emphasis role="strong">A sane system load.</emphasis> Unless you can really, really fork out a lot of money
for serious hardware (in which case, you should probably not be looking for
a <emphasis>mock</emphasis> mainframe), this is not a setup where you should have your kids
playing <emphasis>Quake 3</emphasis> while you are encoding Ogg Vorbis files and your partner
is watching a DVD, all at the same time. It is designed primarily for
pedestrian workloads like email, browsing, chatting, and text processing.
</simpara>

<simpara>
<emphasis role="strong">Some downtime tolerance.</emphasis> We will be using standard, off-the-shelf,
home-user-grade hardware. These parts are not built for enterprise strength
work, and sooner or later, something is going to break or fail.  If
whatever you are doing urgently requires anything even close to 24/7
uptime, you'll have to go out and buy industrial strength hardware &#8212; and
remember to get somebody to guarantee that uptime in writing while you are
at it.
</simpara>

<simpara>
Some examples of when a mock mainframe might make sense:
</simpara>

<itemizedlist>
<listitem>
<simpara>
You have a family of email, surfing and chat freaks who all want to be
    online at the same time but don't use serious resources when they are.
</simpara>
</listitem>
<listitem>
<simpara>
You have a small, closed teaching system that can't be expensive or take
    too much time to administer.
</simpara>
</listitem>
<listitem>
<simpara>
You and your dorm buddies each have those high-powered
    computers to blow each other away with computer games, but don't want
    to go through the hassle of installing a serious Linux system on every
    one to do something as trivial as your actual course work.
</simpara>
</listitem>
<listitem>
<simpara>
Your organization has absolutely no money and the only
    hardware you can get is stuff so old, it doesn't even have scrap value
    anymore, but you still have to give your people computer access.
</simpara>
</listitem>
</itemizedlist>
<simpara>
(If you have found other situations where this setup works, please let me
know.)
</simpara>

</section>
<section>
<title>How This Text Is Organized</title>
<simpara>
First, we will take a look at the individual parts of the setup &#8212; the mock
mainframe, the terminals, the support computers.  Then we'll discuss ways
of putting these elements together.  This is also where we will talk about
security. We'll also discuss life with more than one user and setups for
very weak hardware.
</simpara>

</section>
</section>
<section>
<title>The Individual Pieces</title>
<section>
<title>The Mock Mainframe</title>
<section>
<title>The Hardware</title>
<simpara>
<emphasis role="strong">Examining your needs.</emphasis> If the load that is going to be placed on the mock
mainframe is more or less constant and won't change too much over time, you
are in the wonderful position of being able to tailor your hardware to your
needs. This probably will let you get away with second-hand hardware, which
leaves you with more money for, say, a new surround sound system (or more
realistically, a new dish washer).
</simpara>

<simpara>
The simple way to find out just what you need is to throw together a
machine, just about <emphasis>any</emphasis> machine, and then see how it performs under the
load it will actually be asked to bear. Then experiment a bit: Will the
computer start to swap if you take out half of the RAM, will it speed up if
you put in double the amount? See if you can get away with a slower
processor or a smaller hard disk. If you can, get feedback from your users.
</simpara>

<simpara>
These trial runs can take time and may seem like a lot of work. The idea
here is to fit the mock mainframe's hardware as exactly as possible to the
task at hand so you can use the rest of the hardware for other stuff. Also,
these trial runs can have surprising results. Most people have little
experience in building a system for more than one user, and tend to
overestimate the processor strength required while underestimating the
amount of memory they need.
</simpara>

<simpara>
For example, for our setup at home in 2003 &#8212; two people running
SuSE 8.2 and KDE 3.1 with a regular load of email clients, multiple browser
windows, chatting and music playback &#8212; an AMD Duron 1.0 GHz processor
turned out to be overkill. We ended up with a secondhand SMP mainboard with
two used Intel Pentium II Xeon 450 MHz CPUs (yes, Pentium "two"). Further
experiments showed that 512 MByte RAM was slightly too much RAM: 384 MByte
is fine, if you can live with the system going into swap once in a blue
moon.
</simpara>

<simpara>
<emphasis role="strong">Multiple vs. single processors</emphasis> With more and more people working on one
computer at the same time, you'll start having moments when a single
processor machine seems to stall.  Also, if somebody's process goes berserk
and starts hogging the CPU, it can freeze the whole system. This is bad.
</simpara>

<simpara>
Decades of hardware marketing have produced computer users who reflexively
go out and buy a faster processor when things slow down. But even the
fastest CPU can't do more than one thing at once (we're ignoring tricks
like hyperthreading here), it is just somewhat better at faking it.  To really
do two things at the same time, you need more than one processor. Such
systems are usually referred to as "SMP"-computers, from <emphasis>symmetrical
nultiprocessing</emphasis>. You can get them with eight processors or more (Intel
Pentium II Xeon, AMD Opteron, Intel Xeon) but in our price range, two CPU
(<emphasis>dual-processor</emphasis>) systems are the most common.
</simpara>

<simpara>
More than one processor will go a long way towards keeping the system
responsive even when there are lots of processes running. What it will
<emphasis>not</emphasis> do is make a single process run twice as fast as on a system with a
single processor of the same speed. One way to visualize this is to imagine
you are doing your laundry: Two washing machines will get the whole job
done in about half the time, but that does not mean that they now each spin
twice as fast; each load still takes just as long as before. Things are
actually more complicated, but this is a good rule of thumb.
</simpara>

<simpara>
Although processor speed might be important for gamers on the bleeding edge
or people who want to simulate nuclear explosions on their desktop machine,
the current clock speeds are simply perverse for normal use.  You can
usually get away with far slower processors than the market is trying to
force down your throat, especially if you have more than one CPU. This is a
good thing because SMP-mainboards are more expensive than normal,
single-processor boards, and then you still have to buy that second
processor. Keep in mind that more recent (AMD Opteron / Intel Xeon) SMP
systems can have expensive needs such as a special power supply and extra
large cases.
</simpara>

<simpara>
A multi-processor mainboard is not a must for a mock mainframe. But if you
find your system groaning under multiple users, adding processors might
give you a better deal than adding MHz.
</simpara>

<simpara>
(At the time of writing, there was also the problem of latency in the Linux
kernel. In the 2.4.x series, the kernel is not pre-emptable, so
occasionally a one-processor system will stall while something is happening
in the bowels of the operating system. The 2.6.x kernels are supposed to be
far more responsive, which would be the end of that problem and of this
paragraph,too).
</simpara>

<simpara>
<emphasis role="strong">Storage: SCSI vs. IDE, RAID</emphasis>. You might want to take a look at using SCSI
instead of IDE for hard disks and other drives. One advantage of SCSI is
that you can connect more drives to one computer than the four you are
usually limited to with IDE. SCSI drives are also better at moving data
back and forth amongst themselves without bothering the processor. They are,
however, more expensive and can be louder. On smaller systems with few
users and low loads, you should be able to use IDE drives with no problem.
</simpara>

<simpara>
If you are going to build a system where it is important you don't loose
your data even between those regular backups you perform every night right
after you floss your teeth, you might want to consider a RAID (<emphasis>Redundant
Array of Inexpensive Disks</emphasis>) setup. Very roughly speaking, a RAID setup
duplicates the data on more than one hard disk, so that if one drive
crashes, the others still have copies.
</simpara>

<simpara>
<emphasis role="strong">Sane graphics.</emphasis> Most graphics cards cater to the game freak who has an
unlimited hunger for speed, speed, and more speed and the pocket depth to
match. An AGP graphics card with 128 MByte of RAM and dazzling 3D functions
is not necessarily a bad thing in a mock mainframe, but be sure that you
actually need it. A good used PCI card will usually do just fine for email
and surfing.
</simpara>

<simpara>
<emphasis role="strong">Heat and Lightning.</emphasis> Beyond the normal hardware considerations mentioned
here, give some thought to the parts that protect your machine from threats
such as power surges or brown outs, or makes sure that everything stays
cool, or shields your drive bays from inquisitive little children with
popsicle sticks. A good modern mainboard has temperature alarms and all
sorts of other features to help you monitor your system's heath.
</simpara>

<simpara>
In summary:
</simpara>

<orderedlist>
<listitem>
<simpara>
<emphasis>Think RAM before processor speed.</emphasis> With more than one user, you'll be
    using more memory and less CPU time than you expect.
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>Two slower processors can be better than one fast one.</emphasis> A faster
    processor can switch between more than one task faster than a slow one,
    but two processors don't have to switch at all. This means you can use
    older hardware, which will almost always be less expensive even though
    you will need more of it.
</simpara>
</listitem>
<listitem>
<simpara>
<emphasis>Consider SCSI and RAID.</emphasis> SCSI instead of IDE gives you more drives on
    one machine, and they are able to play amongst themselves without
    processor supervision. However, SCSI drives are more expensive and make
    more noise. RAID helps protect your data from hard disk failure. Both
    are for more ambitious setups.
</simpara>
</listitem>
</orderedlist>
<simpara>
When buying hardware for a mock mainframe, online auctioneers are your
friends. Whereas your local computer store will try to sell you the newest
fad, there is no shortage of previous-generation hardware at affordable
prices online.
</simpara>

</section>
<section>
<title>The Software</title>
<simpara>
<emphasis role="strong">Some background on X.</emphasis> The X Window System (<emphasis>X Windows</emphasis> or just <emphasis>X</emphasis> for
short) is the graphics layer that most Linux systems use. Almost all
current window managers &#8212; KDE, Gnome, Blackbox &#8212; sit on top of X, and
almost all variants of Unix use X.
</simpara>

<simpara>
X Windows has one important aspect that we make extended use of with the
mock mainframe: It is <emphasis>network transparent</emphasis>. The software responsible for
controlling the input/output devices &#8212; screen(s), keyboard, and mouse &#8212;
can be on a different computer than the programs you are actually running.
With X, it is possible to sit in Beijing, China, with a 486DX and run your
programs on a supercomputer in Langley, Virginia.
</simpara>

<simpara>
This has a whole number of advantages. Graphics are hard work for a
computer; having them processed on a different machine than the program
they belong to takes a big load off of the central computer. They are not
so hard, however, that they can't be handled by an older processor. In the
distant past of computer technology, there were special machines called <emphasis>X
Terminals</emphasis> that did nothing but display graphics.  Today, a spare computer
with an Intel PentiumPro or an AMD K6 with 300 MHz is enough.  This lets
you have one big, fat machine running the actual programs and a whole host
of cheap, small machines doing all the graphics.  Which is exactly what we
are looking for.
</simpara>

<simpara>
X Windows does have some drawbacks. It gobbles up a lot of bandwidth, so
you will want a fast network. Also, some of the terminology is strange. The
computer (or rather the software) that controls screen, mouse, and keyboard
is called the "X server", because it "serves" the actual program, which in
turn is called the "X client". In this text, we'll stick to "host" and
"terminals" to avoid confusion.
</simpara>

<simpara>
There are all kinds of good Linux HOWTOs about X Windows, so again we'll
just go through the basic steps and let you consult the special texts.  I'm
assuming that you already have X set up on the mock mainframe; your
distribution should handle that part for you.
</simpara>

<simpara>
First, we have to start the program that handles remote X logins. This is
<literal>xdm</literal> (<emphasis>X Display Manager</emphasis>). Depending on your system and taste, you might
want to use the KDE version <emphasis>kdm</emphasis> or Gnome version <literal>gdm</literal> instead; both have
nicer graphics and more features. Check the <emphasis>XDMCP Mini-HOWTO</emphasis> by Thomas
Chao for more details.  Normally, you'll want <literal>xdm</literal> (or whatever) to start
up in the run level that you ususally use for graphics (for example, run
level 5 for SuSE 8.2).
</simpara>

<simpara>
Even when <literal>xdm</literal> is running, the mock mainframe should not let you connect
from the outside, which is good security. You distribution might let you
change this with a simple entry in one of its configuration files (for
example, SuSE 8.2 uses <literal>/etc/sysconfig/displaymanager</literal>). If you have to do
it the hard way, you will want to change <literal>/etc/X11/xdm/xdm-config</literal> and
<literal>opt/kde3/share/config/kdm/kdmrc</literal> if you are using <literal>kdm</literal>.
</simpara>

<simpara>
After all of this is done, you are ready to test the link.  Get a computer
you know has a functioning X system, boot it in console mode &#8212; <emphasis>not</emphasis> in
graphics mode (runlevel 3 instead of 5 on SuSE systems, use <literal>init 3</literal> as
root from a shell). Log in and type
</simpara>

<screen>
        /usr/X11/bin/X -terminate -query &lt;host&gt;
</screen>
<simpara>
where "&lt;host&gt;" is the name or IP-address of the mock mainframe. You should
get the same X login prompt as if were sitting at the host machine.
</simpara>

<simpara>
Even if you have booted into graphical mode, you can try the following to force the X server to start a second display:
</simpara>

<screen>
        /usr/X11/bin/X :1 -terminate -query &lt;host&gt;
</screen>
<simpara>
This can be done from within a terminal program such as <literal>xterm</literal> on the running display. Note that by default, the first display is :0.
</simpara>

<simpara>
The rest of the text is written under the assumption that you will be using some standard distribution such as SuSE or RedHat or Gentoo for the mock mainframe. However, it should also be little trouble to adapt the Knoppix terminal server package (see <ulink url="http://www.knoppix.net">http://www.knoppix.net Knoppix</ulink>) so that it boots right off a ramdisk.
</simpara>

</section>
</section>
</section>
<section>
<title>The Terminals</title>
<simpara>
The machines you use to connect to the mock mainframe should be
inexpensive, easy to maintain and, from a security point of view,
expendable.
</simpara>

<section>
<title>Dual Boot Machines</title>
<simpara>
Some people &#8212; those without a time consuming job, a spouse, or children,
for example &#8212; 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 <emphasis>dual boot machines</emphasis>.  The messy details
are usually handled automatically by whatever distribution you are using;
if not, check out the <emphasis>Linux Installation Strategies mini-HOWTO</emphasis> Tobby
Banerjee.
</simpara>

<simpara>
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:
</simpara>

<orderedlist>
<listitem>
<simpara>
Go to <literal>/etc/X11/xdm/</literal>. In the file <literal>Xservers</literal>, comment out the line
  that is either <literal>:0 local /usr/X11R6/bin/X :0 vt07</literal> or something similar
  by putting a hash mark ("#") at the beginning.  This will stop the
  computer from starting up X locally during boot time.
</simpara>
</listitem>
<listitem>
<simpara>
In <literal>etc/inittab</literal>, insert a new line such as (for SuSE 8.2)
     <literal>xx:5:respawn:/usr/X11R6/bin/X -query &lt;host&gt;</literal> where "&lt;host&gt;" 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 <emphasis>(please be careful:</emphasis> Playing around with <literal>inittab</literal> 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.
</simpara>
</listitem>
</orderedlist>
<simpara>
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.
</simpara>

</section>
<section>
<title>Linux Terminals</title>
<simpara>
The <ulink url="http://www.ltsp.org">Linux Terminal Server http://www.ltsp.org</ulink> (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.
</simpara>

<simpara>
<emphasis role="strong">Required hardware.</emphasis> 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.
</simpara>

<simpara>
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 &#8212; "decent" doesn't necessarily mean a
AGP graphics card with 128 MByte RAM, it means a clear, crisp picture.
</simpara>

<simpara>
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
(<emphasis>Media Access Control</emphasis> 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:
</simpara>

<screen>
        00:50:56:81:00:01
</screen>
<simpara>
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.
</simpara>

<simpara>
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.
</simpara>

<simpara>
<emphasis role="strong">How they work.</emphasis>
</simpara>

<simpara>
The LTSP home page has an in-depth technical discussion of what happens
when the system powers up. In brief, human terms:
</simpara>

<simpara>
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 (<emphasis>or</emphasis> a boot
ROM in the network card.) It starts the boot program. This in effect tells
the Linux Terminal:
</simpara>

<literallayout class="monospaced">
       Got your MAC? Good. Now scream for help as loud as you can.
</literallayout>
<simpara>
The terminal's call goes through the whole (local) network. On the mock
mainframe, a program called <literal>dhcpd</literal> (<emphasis>Dynamic Host Configuration Protocol
Server Daemon</emphasis>) 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.
</simpara>

<simpara>
Using some more code from the boot program, the terminal starts a program
called <literal>tftp</literal> (<emphasis>Trivial File Transfer Protocol</emphasis>, a stripped-down version of
the venerable <literal>ftp</literal>. This downloads the kernel from the host machine. The
terminal then boots this kernel.
</simpara>

<simpara>
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 <literal>NFS</literal> (<emphasis>Network File System</emphasis>). 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 <literal>xdm</literal>, and throws up the
login screen.
</simpara>

<simpara>
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.
</simpara>

<simpara>
Running <literal>dhcpd</literal>, <literal>tftpd</literal>, and <literal>nfsd</literal> 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.
</simpara>

<simpara>
<emphasis role="strong">Setting up the software.</emphasis> On the server (mock mainframe) side, you need to
install <literal>nfsd</literal> <literal>tftpd</literal>, and <literal>dhcpd</literal>, which your distribution should include
as standard packages.
</simpara>

<simpara>
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:
</simpara>

<variablelist>
<varlistentry>
<term>
<literal>/etc/dhcpd.conf</literal>
</term>
<listitem>
<simpara>
       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.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>/opt/ltsp/i386/etc/lts.conf</literal>
</term>
<listitem>
<simpara>
       These options control the terminal itself.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>/etc/hosts</literal>
</term>
<listitem>
<simpara>
       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.
</simpara>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>/etc/hosts.allow</literal>
</term>
<listitem>
<simpara>
       Though not mentioned in the current LTSP documentation, you probably
       will have to add the following lines to this file:
       <literal>rpc.mountd : &lt;terminal&gt; : ALLOW</literal>
       <literal>rpc.mountd : ALL : DENY</literal>
       where "&lt;terminal&gt;" is the terminal's IP address. This tells the host
       to allow the terminal to mount the NFS file system.
</simpara>
</listitem>
</varlistentry>
</variablelist>
<simpara>
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
<ulink url="http://www.rom-o-matic.net/">ROM-O-Matic Website http://www.rom-o-matic.net/</ulink>,
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.
</simpara>

<simpara>
If you have a more modern motherboard on your Terminal machine, you might be able to get around all of this by selecting "PXE" (<emphasis>Pre-eXecution Environment</emphasis>), "MBA" (<emphasis>Management Boot Agent</emphasis>) or "Network" from the boot sequence (CMOS) menu.
</simpara>

<simpara>
<emphasis role="strong">Using the terminals.</emphasis> Just how many Linux Terminals can one mock mainframe
support? The LTSP documentation gives the following example:
</simpara>

<literallayout class="monospaced">
    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!
</literallayout>
<simpara>
(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.)
</simpara>

<simpara>
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 (<emphasis>but only in a safe environment!</emphasis>), sit
down at a terminal and type
</simpara>

<screen>
       xhost +&lt;host&gt;
</screen>
<simpara>
where "&lt;host&gt;" is the name of the mock mainframe. Then, move to a different
terminal and start a program such as <literal>xeyes</literal> or <literal>xroach</literal>:
</simpara>

<screen>
       xeyes -display &lt;terminal&gt;:0 &amp;
</screen>
<simpara>
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
</simpara>

<screen>
       xhost -&lt;host&gt;
</screen>
<simpara>
You can also use this example to point out why it is dangerous to use the
<literal>xhost</literal> command.
</simpara>

<simpara>
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 <literal>xlock</literal> suite. For example
</simpara>

<screen>
       xlock -inwindow -mode kumppa
</screen>
<simpara>
or more generally
</simpara>

<screen>
       xlock -inwindow -mode random
</screen>
<simpara>
Though the results will depend on your hardware, this usually takes care of
any doubts.
</simpara>

<simpara>
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 <emphasis>just turn off the power</emphasis> 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.
</simpara>

</section>
<section>
<title>Real X Terminals</title>
<simpara>
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.
</simpara>

<simpara>
The Linux Documentation Project has a number of general and special HOWTOs
on how to set up X Terminals, for example the <emphasis>Connecting X Terminals to
Linux Mini-HOWTO</emphasis> by Salvador J.  Peralta or the <emphasis>NCD-X-Terminal
Mini-HOWTO</emphasis> by Ian Hodge.
</simpara>

</section>
<section>
<title>X11 Forwarding with ssh</title>
<simpara>
If you are on a machine that already supports X, you might be able to use the X11 Forwarding function of the Secure Shell (<literal>ssh</literal>) program. This is invoked with
</simpara>

<screen>
ssh -X &lt;HOST&gt;
</screen>
<simpara>
and creates a cryptographically protected tunnel to the host machine. X forwarding has to be configured on both machines &#8212; in <literal>/etc/ssh/sshd_config</literal> on the host machine, <literal>X11Forwarding</literal> must be set to <literal>yes</literal> &#8212; and it can be a little clumsy to use every day. However, for quick and dirty work, this is a good alternative.
</simpara>

</section>
<section>
<title>X Server Programs</title>
<simpara>
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.
</simpara>

<simpara>
Most X servers for <emphasis role="strong">Windows</emphasis> cost money, in some cases a lot of money. The
single <ulink url="http://cygwin.com/xfree/">Cygwin http://cygwin.com/xfree/</ulink>, which
ports X (and GNU tools) to Windows machines.
</simpara>

<simpara>
If you have an <emphasis role="strong">Apple</emphasis> 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:
</simpara>

<screen>
#!/bin/bash
/usr/X11R6/bin/X -terminate -query "&lt;HOST&gt;" :1
exit
</screen>
<simpara>
Note the window number is :1, because :0 is used by Aqua. Do not use the X11 Server in
<literal>/Applications/Utilities/X11.app/Contents/MacOS/X11</literal>, as this doesn't understand the <literal>-query</literal> 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 <literal>SystemPreferences -&gt; Sharing -&gt; Firewall</literal> 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 <literal>Command-Option-a</literal>. (Note: This has not been tested with Mac OS X 10.4 "Tiger")
</simpara>

<simpara>
You can also check the <ulink url="http://www.xdarwin.com/">XDarwin http://www.xdarwin.com/</ulink> project. XDarwin is an Apple version of the X Window System that sits on the Darwin
operating system &#8212; a variant of BSD &#8212; that is the core of OS X.
</simpara>

<simpara>
(There is one GPL X Server written in <emphasis role="strong">Java</emphasis> you might try:
<ulink url="http://www.jcraft.com/weirdx/">Weirdx http://www.jcraft.com/weirdx/</ulink>,
though the author points out it is not made for heavy loads.)
</simpara>

<simpara>
In this chapter, we have examined terminals that will give you a GUI
(<emphasis>graphical user interface</emphasis>). If you are tough enough, you can also hook up
a text terminal to your mock mainframe and access the system via a CLI
(<emphasis>command line interface</emphasis>). This option is covered further down.
</simpara>

</section>
</section>
<section>
<title>The Support Machines</title>
<simpara>
In theory, you should need no other computers than the mock mainframe and
whatever you use as terminals. In practice, you'll probably want additional
machines for specific tasks. Usually this will be because of security, not
performance.
</simpara>

<simpara>
For example, let's assume you have a network with a dial-up connection to
the Internet for email and browsing. Of course you could put all the hard-
and software required on the mock mainframe and not see much of a
performance hit (in fact, if your network is slow, it might even be
faster). But that puts your most valuable computer right where everybody
who is on the Internet &#8212; which increasingly means anybody on the planet &#8212;
can attack it.
</simpara>

<simpara>
For better security, put a machine between the mock mainframe and the
outside world. Make sure this <emphasis role="strong">Guardian</emphasis> machine is not only heavily
fortified, but also expendable, so if it is taken over by the forces of
evil or compromised in any other way, you won't lose anything valuable. To
lock down the network in an emergency, all you have to do now is to
physically turn off the power of the guardian machine (assuming this is the
only entry point to your local net). This can be very useful if you can't
sit down and go though security measures the moment you see a problem,
because, say, your boss at the burger grill just does not realize how
important that dorm network is and unfeelingly insists you show up on time
to flip the meat.
</simpara>

<simpara>
Other functions you might want to isolate on different machines are web- or
other servers on your net that people from the Internet can access. You can
also have a support machine tend your Linux Terminals (a <emphasis role="strong">Terminal Mother</emphasis>)
or to burn CDs (a <emphasis role="strong">Burner</emphasis>).
</simpara>

</section>
<section>
<title>Putting the Pieces together</title>
<simpara>
So after reading this far, you know what you want, know where to get it,
how to set it up, and want to get going. There are few things you should
think about, however, before you start editing configuration files and
stringing cables.
</simpara>

<section>
<title>Security</title>
<simpara>
There is only a limited amount I can tell you about your security needs:
Everybody faces different threats. All I can do here is give some basic
background on how to secure a mock mainframe setup. If you are looking for
a good general introduction to security, try the book <emphasis>Secrets &amp; Lies</emphasis>
by Bruce Schneier.
</simpara>

<section>
<title>Needs revisited</title>
<simpara>
In most books on securing computer systems, there comes a point where the
author tells you to sit down and "formulate a security policy". This sounds
like such a bureaucratic nightmare that most people skip the whole chapter.
I'm not going to suggest you formulate anything. But the next time you're
taking a shower, ask yourself what kind of defenses you need.
</simpara>

<simpara>
<emphasis role="strong">What are you trying to protect?</emphasis> Are you worried about somebody hacking
into the mock mainframe and stealing your data, the classic Hollywood
threat to computers? Or that your hardware could be destroyed by lightning?
Or that somebody will sit down in front of a terminal when the user is off
to the bathroom and write emails in his name? Or that people will open the
computer cases and steal the processors?  Another way to look at this is to
figure out what parts of the system would be hard or even impossible for
you to do without. For example, the digital photos and films of my daughter
when she was a baby are simply irreplaceable.
</simpara>

<simpara>
<emphasis role="strong">Who or what are the forces of evil?</emphasis> Once you know what you are trying to
protect, think about whom you are protecting it against, maybe while you
are brushing your teeth. Are you worried about crackers from the Internet,
or that the flaky power company you are stuck with will zap your computers
with a power surge? Remember those little kids with popsicle sticks?
</simpara>

<simpara>
If your system is connected to the Internet 24/7, you need to worry about
worms and crackers. If you are only online for as long as it takes to pick
up those three emails from your mother, you risk in this area is
drastically reduced.  This shows how the "probability" of an attack figures
in.  How likely is it for somebody to hit your system during those 20
seconds?  If an attack is highly improbable, you won't want to go to the
effort of protecting yourself against it. Some things you will probably
dismiss without even thinking: Just how were you going to defend your
system against attacks by rust monsters?
</simpara>

<simpara>
Once you know what you are afraid of and how probable an attack is, you
should have a feeling for the <emphasis>risks</emphasis> you are facing.  There are three ways
of handling risk: You can <emphasis>take it</emphasis>, <emphasis>minimize it</emphasis>, or <emphasis>insure against it</emphasis>.
The first option is not as negligent as you might think: Given our budget,
most of us are simply taking the risk of meteor strikes. The third option
usually costs money, which we don't have, so we will ignore it here.
</simpara>

<simpara>
The second option is touches the three major parts of any security process:
<emphasis>prevention</emphasis>, <emphasis>detection</emphasis>, and <emphasis>response</emphasis>. Most computer security deals
with prevention: Making sure the cases are locked so nobody can steal the
CPUs, for example. Detection is usually skimped &#8212; when is the last time
you looked at one of the files in <literal>/var/log/</literal>?  &#8212; and usually little
thought is given to the response, because people figure none of this is
going to happen anyway.  Unfortunately, you need all three, always, at
least to some extent.
</simpara>

<simpara>
Even if you decide that detection systems like <literal>tripwire</literal> are too much of a
hassle to install and you don't have the time to read log files every day,
give some thought to how you could tell that your system has been
compromised. In some cases, it will be hard to miss, say, when men with
badges knock at your door and take you away because your computer has been
sending spam related to an improbable sexual act with squirrels to all of
South Korea. Other intrusions might be more subtle.  Would you know if
somebody copied the files from your letter folder?
</simpara>

<simpara>
Think about how you would respond to at least the most likely attacks and
failures. What would you do if your hard disk crashed? If you logged in as
root and the system told you that your last log in was on Friday &#8212; except
that you were still in London, England on Friday, singing drinking songs as
you happily stumbled from one pub to the next.  With a normal home system
and good backups, you might be able to get away with <emphasis>reinstall from scratch</emphasis>
as the standard response all problems great or small (but
make sure that your backups are not compromised).
</simpara>

<simpara>
By the time you are putting on your socks, you'll have probably found out
that your greatest risks are quite different from those the press talks
about all of the time.  If you have no Microsoft products on your network,
you don't have to worry too much about anti-virus software or Active X
vulnerabilities. However, Linux does not enjoy any special bonuses when it
comes to power surges, flooding, or broken fans.
</simpara>

</section>
<section>
<title>Security Principles</title>
<simpara>
Back to prevention: When you design your system, keep these security
principles in mind:
</simpara>

<simpara>
<emphasis role="strong">Building better baskets.</emphasis> Putting all of your files on one computer might
seem like putting all of your eggs in one basket, which proverbial
grandmothers say is a bad thing to do. In fact, from a security point
of view, this can actually be a good strategy: Since it is almost always
easier to defend one thing than it is to defend many, one basket my be fine
as long as you make sure that is a <emphasis>very, very good</emphasis> basket.
</simpara>

<simpara>
<emphasis role="strong">Avoiding complexity.</emphasis> A centralized system is usually less complex to set
up and to administer: If you have all of your users on one machine, you
don't have to worry about network file systems, network logins, network
printers, and all other kinds of clever but complicated ways to connect
computers. Keeping things simple keeps things safe. This is true as well
for the support machines: They should do one job and one job only.
</simpara>

<simpara>
<emphasis role="strong">Encapsulation.</emphasis> This is the process of isolating a part of the system so
that if it is compromised, the whole of the system doesn't go down with it.
The Guardian is an example of encapsulation: The dangerous work of
connecting to the Internet is handled by a cheap, expendable machine that
gives attackers few tools to work with. Another example is taking those
parts of the system that the user can actually touch with his grubby little
hands &#8212; monitor, keyboard, and mouse &#8212; and putting them on a Linux
Terminal. The mock mainframe setup, however, is obviously not that good at
encapsulation: The whole idea of doing everything on one machine runs
contrary to this concept.
</simpara>

<simpara>
<emphasis role="strong">Defense in Depth.</emphasis> Preventative security measures are only ways of buying
time until your response kicks in &#8212; given enough uninterrupted time, the
attacker will always win. To increase the time you have to respond, deploy
your defenses in depth: After the attacker has trekked through kilometers
of dense jungle, he reaches the moat which surrounds a twenty meter high
outside wall, which is followed by a mine field and poisoned bamboo spikes.
And in the end, the secret plans to your magical chocolate machine will not
only be in code, but also written in invisible ink. That's defense in
depth.
</simpara>

<simpara>
The guardian is an extention of your defenses; installing a second firewall
on the mock mainframe is another one. It might sound trivial, but use
different passwords for the mock mainframe and the guardian. If you have
other support machines, putting them on a different network also means more
room between them and the attacker. If you have data that you have to keep
confidential at all costs (wink-wink nudge-nudge), encrypt it, or at least
those backup CDs.  After a few years of backups, you won't know where they
have all ended up.
</simpara>

<simpara>
But keep in mind that even the deepest defenses only buy you more time. As
Indiana Jones and Lara Croft will tell you, getting by the preventative
measures is the easy part: All you need is a whip or a few well-timed
jumps. The problems start when the locals start shouting and the guys with
the guns arrive.
</simpara>

<simpara>
<emphasis role="strong">Choke Points.</emphasis> If there is only one way to get into the system and you can
control that way completely, that system will be easier to secure in time
of danger. We turn to the guardian one more time for an example of a choke
point: Turn off the machine, and you are safe from Internet villains,
<emphasis>provided it is really the only access point</emphasis>. The problem with many
networks is that somewhere, somebody has a connection to the outside that
the system administrator doesn't know about. Think of all the laptops that
now come with a modem or, even worse, a wireless LAN card built in.
Connect those laptops to your net, and you have an instant back door.
Remember your history: Your main gate can be high and strong and crawling
with orcs, but miss one single little spider hole, and two hobbits can ruin
your whole day.
</simpara>

</section>
</section>
<section>
<title>Network Hardware</title>
<simpara>
If you are setting up a network from scratch, go with Fast Ethernet. The
cables and network cards are not that much more expensive than the older,
10 MBit/sec Ethernet. X Windows is bandwidth-hungry, and needs always grow
before they shrink.
</simpara>

<simpara>
One note about running X terminals over a wireless LAN: I have been told in no uncertain words to avoid this. Two problems are mentioned: Variable bandwidth, which can leave your session slowing to a crawl when your neighbor does something major, and dropouts, which can lead to the whole session being shut down with all X programs using the connection terminated and your work gone. There are also the usual caveats about the security of WiFi connections.
</simpara>

</section>
<section>
<title>Network Geography</title>
<simpara>
You can make life a little easer for yourself by picking a sane and
systematic way to name your computers: Pick a set of addresses for your
system based on what each machine does.  Internally, use the IPv4 address
space of 192.168.<emphasis role="strong">.</emphasis> that is reserved for networks without direct contact
to the Internet.  For example, let's take 192.168.1.*. The mock mainframe
could be 192.168.1.1, the support machines 192.168.1.10 to 192.168.1.19,
and the terminals 192.168.1.100 to 192.168.1.199.  This way, you can
immediately see the type of computer based on the IPv4 number, and the less
trusted a machine is, the larger the last number will be.
</simpara>

<simpara>
Combine this with a naming system that is easy to use. For example, you can
name the mock mainframe <emphasis>fatcat</emphasis> and the terminals <emphasis>kitten00</emphasis> to <emphasis>kitten99</emphasis>
(with IPv4 numbers from 192.168.1.100 192.168.1.199). Giving the support
machines names based on their function is probably easier than something
systematic. In the feline theme, try <emphasis>claws</emphasis> for a guardian machine or
<emphasis>mamacat</emphasis> for a terminal mother.
</simpara>

</section>
</section>
<section>
<title>Life With Multiple Users</title>
<simpara>
Having everybody using a common machine gives your users far more
opportunity to get in each other's hair. Even though Unix (and therefore
Linux) was designed from the bottom up as a multi-user system, there are
only so many resources available, and having one user hogging them will
annoy everybody. And they will all come to you and say it is your fault.
</simpara>

<section>
<title>Shared Resources</title>
<simpara>
One of your biggest headaches will probably be <emphasis role="strong">CD-ROMs</emphasis> and
<emphasis role="strong">CD-R/Ws</emphasis>. In theory, they belong on the mock mainframe like everything
else, but this creates lots of problems. Your users need to be able to
physically get to the machine to put the CDs in, which might not be a good
idea from the security point of view. Once the CD is in the drive, you can
get various people trying to mount, unmount or eject it, and getting upset
if they can't. Reading a CD (for example with <literal>cdparanoia</literal>) can interfere
with multimedia programs and cause sound tracks to skip.  Writing CDs is
even worse because it requires the system to pay attention for a certain
uninterrupted amount of time. If you only have one processor on the machine
and other users decide to do something intensive while the burn is going
on, the write might fail, and somebody is going to be really upset, because
he just lost a blank CD.
</simpara>

<simpara>
One thing you can do is to move the CD-R/W onto a dedicated support machine (the
<emphasis role="strong">Burner</emphasis>) that does nothing else. Such a machine can be set up with Jörg P. M. Haeger's
<ulink url="http://joerghaeger.de/webCDwriter/">http://joerghaeger.de/webCDwriter webCDwriter</ulink>. It has a graphical interface written in Java and runs under any operating system with a Java Virtual Machine. This preserves the principle of encapsulation. Make sure there is nothing else on the Burner that you can't afford to use if the system is compromised. There are of course other, more primitive ways: You could export the user's home directory by NFS, which is, however, exactly the sort of thing we are trying to avoid. Or have the user create an image of the CD as an ISO file, and then let him send it to the support machine via <literal>sftp</literal> or <literal>scp</literal>. Then the user can walk
over to the machine and burn it by hand.
</simpara>

<simpara>
In a family setting, none of this might be a problem. For a larger
configuration, with untrusted users, it could be a big problem. You might
end up telling everybody that they can't burn CDs on this system, period.
</simpara>

<simpara>
Other resources are less of a problem. Traditionally, you used a <emphasis role="strong">quota</emphasis>
setting to limit the amount of disk space any single user could use. With
hard disks becoming less expensive by the month, this is not much of a
problem anymore, but depending on your user base, you might consider
installing very large quotas just to be safe. Users, however, are easily
upset by the very idea of quotas, especially if they hit their limit while
most of the harddisk is still free.
</simpara>

</section>
<section>
<title>Screen Savers and Other Gimmicks</title>
<simpara>
The original aim of screen savers was to keep whatever was being displayed
on the screen from burning itself into the monitor's phosphorous coating
while you were off to the water cooler. Soon, however, clever, cute, and
intricate screen savers became an end in themselves. Today's screen savers
have become so resource-hungry that some actually require you to have
certain types of hardware (like OpenGL support) before they will run.
</simpara>

<simpara>
If you have a mock mainframe with X Windows, you can be sure that every
single one of your users will have a screen saver setup that will test the
system to its limits (just for fun, log into every terminal attached to the
mainframe once you have set everything up, and let each one run a different
screen saver. Watch the system load while you do this. Try not to whimper
too loudly). To make matters worse, some desktops like KDE let the user set
the screen saver's priority. The idea is that the user can set a low
priority, but in reality, they increase the priority until their jumping
OpenGL balls don't jerk anymore.
</simpara>

<simpara>
Users consider playing around with their screen savers one of their basic
computer rights, so just blocking everything except the "blank screen" mode
can lead to people showing up in your office with pitchforks and torches.
One way around this is to put a <emphasis>wrapper</emphasis> around the screen saver that
makes sure the priority is set low. For example, if your setup uses the
<literal>xlock</literal> command as a screen saver, you can move it to <literal>xlock.real</literal> and then
create a shell script named <literal>xlock</literal>:
</simpara>

<screen>
        #!/bin/bash
        nice -19 xlock.real "$@"
</screen>
<simpara>
This is a very crude script, but you get the point. This lets your users
keep their beloved screen savers but makes sure that the performance hit
won't be deadly to the whole system.
</simpara>

</section>
<section>
<title>Idle Terminals</title>
<simpara>
Another annoying habit users have is to walk away from their terminals
while they are still logged in. KDE and Gnome have a "Lock Screen" button
right next to their "Logout" button, but you might have problems getting
your users to use it, at least until the first person finds that somebody
has had fun with his email account.
</simpara>

<simpara>
One way to deal with this is to have the system shut down abandoned
terminals with the idle daemon, which should be included
in your distribution. Use this with care: If you force a user off the
system when he still has some half-written letter on his screen, he isn't
going to like it. The program <literal>xautolock</literal> can be set up to invoke a screen saver or a different program after an X session has been idle for a configured amount of time.
</simpara>

</section>
</section>
<section>
<title>Going Hardcore: Non-GUI Systems</title>
<simpara>
As nice as KDE and Gnome are, they use system resources like popcorn. If
you are only starting an application, try a desktop that is more
lightweight such as <literal>Blackbox</literal>.  Though your distribution should set up the
basics for you, you will probably have to edit the configuration files (in
this case, the <literal>Blackbox</literal> menu file that is specified in <literal>~/.blackbox</literal>) for
each user. Also, make sure your users know how to work the environment. At
the very least, teach them that <literal>CTRL-ALT-BACKSPACE</literal> kills the X server.
</simpara>

<simpara>
But real men and women don't need a graphical user interface (GUI) at all:
They use a command shell such as <literal>bash</literal>.  Before X Windows gave us
graphics, the Free Software Foundation (FSF) had created the GNU tools that
are as rock steady as any piece of software on the planet. They are the
heart of every distribution, and without them, there would be no "Linux"
system (which is why "GNU/Linux" is the more percise term).  If you have no
choice but to get by with really weak hardware &#8212; we're talking anything
down to a 386SX here &#8212; you can dump X Windows altogether and get along
just fine. Even if you stick to GUIs, some basic knowledge of the shell
can help you get far more out of your system.
</simpara>

<section>
<title>Why the Command Line Is Cool</title>
<simpara>
Think of Linux on the command line as the Willow Rosenberg approach to
computers: Whereas GUIs are as spectacular as a punch on the nose by
vampire slayer Buffy Summers, even a little knowledge of the shell will let
you work nuanced magic of nearly unlimited power with little effort. True
fans of the TV series will realize that there is a warning implied here:
The power of the shell can become habit forming, if not downright
addictive, and you can destroy your whole system with no chance of recovery
if you mess things up. Using <literal>bash</literal> takes you as close to
the raw energies of your machine as you can get without using a C compiler,
and the danger rises accordingly.
</simpara>

<simpara>
It took Willow six years to become a witch powerful enough to end the
world, but it should take you a few weeks at most to become familiar with
the command line. Here are four paragraphs to help you decide if you want
to make the effort:
</simpara>

<simpara>
The power of the command line environment is rooted in its design
philosophy: Each tool is designed to do one job and one job only, but to do
that job superbly. Also, almost every tool can be connected to every other
tool to create processing chains with just a few commands. Since these
tools are (almost) all general purpose, you can solve just about any
problem with the right combination. With these same commands, you can write
little programs (<emphasis>shell scripts</emphasis>) for everyday tasks. If you look closely
at the programs your distributor includes, you will see that a lot of the
are in <literal>bash</literal>. Other script languages such as Python or Perl might be more
powerful, but the command line is always included and has far less
overhead.
</simpara>

<simpara>
It is learning the individual tools of the CLI that is somewhat daunting.
A lot of commands have strange names that don't even pretend to be mnemonic
(the pattern scanning tool <literal>awk</literal> is named for its creators Aho, Kernighan,
and Weinberger), only make sense in a historical context (the <emphasis>tape
archiving utility</emphasis> <literal>tar</literal> is now used to distribute compressed files), or
look like they are typos (<literal>umount</literal> instead of "unmount", <literal>passwd</literal> instead
of "password"). There can be dozens of options for each command, and they
can be just as cryptic. Because the system was written by hackers in the
true sense of the word who wanted the computer to get the job done and not
talk about it, the shell normally will not ask you for confirmation, even
if you tell it to delete every single file on your hard disk. This is where
the end of the world scenario from <emphasis>Buffy</emphasis> comes in.
</simpara>

<simpara>
Once you <emphasis>have</emphasis> mastered the basics of the shell, however, you will get
stuff done a lot faster, you will understand jokes such as <literal>rm -rf
/bin/laden</literal>, and you will develop a spring in your step and a glint in
your eye. This is why even people who are young enough to have been born
after the invention of the mouse develop a  tendency to use X Windows
merely as a comfortable way to open a lot of terminal windows (either
<literal>xterm</literal> or the less resource-hungry <literal>rxvt</literal>).
</simpara>

<simpara>
The CLI has just about every tool you'll need: <literal>mutt</literal> or <literal>pine</literal>
for email (real hard-core basket cases use <literal>mail</literal>) <literal>w3m</literal> or <literal>lynx</literal> for
surfing, and of course the legendary editors <literal>vi</literal> (more commonly <literal>vim</literal>
these days) or <literal>emacs</literal>. The obvious exception to this rule are programs
that let you view pictures. But then you probably aren't interested in that
sort of thing anyway, are you.
</simpara>

</section>
<section>
<title>Setting Up Text Terminals</title>
<simpara>
Basically, you have the same options for text terminals as you do with X
terminals. Everything is just a bit easier.
</simpara>

<simpara>
For example, you don't have to reboot if you are forced to use a different
operation system: Any program that lets you log in via <literal>telnet</literal> (on secure,
closed networks) or <literal>ssh</literal> (everywhere else) will do. Microsoft Windows
includes a <literal>telnet</literal> client that is best described as rudimentary; for
serious work, try a free Win32 implementation such as Simon Tathamt's
<ulink url="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY http://www.chiark.greenend.org.uk/~sgtatham/putty/</ulink>. Apple users with Mac
OS X should have no problems with their clients.
</simpara>

<simpara>
The Linux Terminal Server Project also has a package for text terminals.
The hardware can be as basic as it gets: Go find yourself a 386DX (for
those of you who don't remember the Soviet Union or the first <literal>Star Trek</literal>
series: This is the original Pentium's grandaddy). The mainboard will
probably not have a PCI slot, so you'll need an ISA graphics card and an
ISA network card. These are so low down the hardware chain you might have
problems finding them, because they are being junked, not sold second hand.
</simpara>

<simpara>
There is no reason, though, why your computer has to be advanced enought to
understand the TCP/IP protocol and be part of your local network at all.
You can connect just about any computer to the serial port(s) of the mock
mainframe: For example, there is a Linux HOWTO for older Macs by Robert
Kiesling (<emphasis>The MacTerminal MINI-HOWTO</emphasis>); in an article in
<ulink url="http://www.linuxgazette.com/issue70/arndt.html">The Linux Gazette http://www.linuxgazette.com/issue70/arndt.html</ulink>, Matthias Arndt shows how
to convert an Atari ST into a terminal; Nicholas Petreley explains in
<ulink url="http://www.itworld.com/Comp/2384/LWD010511penguin2/">IT World.com http://www.itworld.com/Comp/2384/LWD010511penguin2/</ulink> how to use your Palm
Pilot. If you can get it connected to the serial port, chances are you can
get it running on Linux. There are special cards with multiple serial ports
for larger setups. Of course, there is a HOWTO for that as well: <emphasis>The
Serial HOWTO</emphasis> by David S.Lawyer.
</simpara>

<simpara>
You can also get special text terminals as individual machines.  David S.
Lawyer has written an extensive Linux HOWTO on the subject
(<emphasis>Text-Terminal-HOWTO</emphasis>) that explains how they work, how you set them up,
and why you would want one.
</simpara>

</section>
<section>
<title>Useful Shell Commands</title>
<simpara>
To get you started on the shell, here are a few commands that are
especially useful if you are sharing a system. These very basic examples
were chosen to be useful to normal users.
</simpara>

<simpara>
<emphasis role="strong">Play nice</emphasis>. The <literal>nice</literal> command is one of those things that would make the
world a better place if everybody used it more often, but nobody does. It
allows you to lower the <emphasis>scheduling priority</emphasis> of a process so that less
important programs don't get in the way of the important ones.
</simpara>

<simpara>
For example, assume you have a WAV recording of your own voice as you sing
a song under the shower, and you want to convert it to the Ogg Vorbis
format to distribute to your fans on the Internet, all three of them. A
simple command to do this is
</simpara>

<screen>
         oggenc -o showersong.ogg showersong.wav
</screen>
<simpara>
Encoding music formats is a CPU intensive process, so performance will
drop. Now, if a few minutes more or less don't matter, just start the line
off with <literal>nice</literal>:
</simpara>

<screen>
         nice oggenc -o shower.ogg shower.wav
</screen>
<simpara>
Now the encoding will be run with a lower priority, but you will still have
to wait for it to finish before you can use the shell again. To have the
computer execute a command in the background, add an ampersand ("&amp;") to the
end of the line:
</simpara>

<screen>
         nice oggenc -o shower.ogg shower.wav &amp;
</screen>
<simpara>
The shell will respond by giving you a <emphasis>job number</emphasis> and a <emphasis>process id</emphasis>
(PID), and then will ask you for the next command.
</simpara>

<simpara>
The <literal>nice</literal> command is a good example of the power that was lost when
graphical interfaces became the default: There is no simple way to adjust
the priority of a process with a mouse-driven interface.
</simpara>

<simpara>
<emphasis role="strong">Do it later.</emphasis> Another way to spread the load is to have an intensive
process start at a time when the system is not being used much. Depending
on who is on the system with you, this could be three  o'clock in the
morning or any time until two o'clock in the afternoon.
</simpara>

<simpara>
The <literal>at</literal> command lets you set a time to start a program or any other
process that can be run from the command line. To have our shower song
encoded at eight in the evening when you are out watching meaningful French
love films, you enter the command "at" followed by the time you want
execution to start, and then hit the <literal>ENTER</literal>. Then you type in the command
itself, followed by another <literal>ENTER</literal>, and finally a <literal>CTRL-d</literal> to finish the
sequence:
</simpara>

<screen>
         me@mycomputer:&gt; at 20:00
         warning: commands will be executed using /bin/sh
         &gt; nice oggenc -o shower.ogg shower.wav
         &gt; &lt;CTRL-d&gt;
         job 1 at 2003-09-28 20:00
</screen>
<simpara>
The <literal>at</literal> command accepts just about any time format: Americans get to use
their quaint "08:00pm" notation instead of "20:00", and there are a whole
set of shortcuts like <literal>midnight</literal>, <literal>noon</literal> or even <literal>teatime</literal>.  <literal>at</literal>
sends the output of the command to your mailbox.
</simpara>

<simpara>
<emphasis role="strong">Do it when you are bored.</emphasis> A close relative of <literal>at</literal> uses system load, not
time of day to determine when a command should be run: <literal>batch</literal> saves the
execution for a time when the system load has fallen below a certain value
(to see what your system load currently is, run <literal>uptime</literal> from a shell or
<literal>xload</literal> under X Windows). The documentation gives this value as 0.8. The
syntax for <literal>batch</literal> is basically the same as for <literal>at</literal>, except that the time
field is optional.
</simpara>

</section>
</section>
<section>
<title>Odds and Ends</title>
<section>
<title>Mock Mainframe Case Studies</title>
<literallayout class="monospaced">
Two People Home Setup

Mainframe: Dual Intel Pentium II Xeon 450 MHz 512 KByte cache CPU, 384 MByte
           PC-100 RAM, PCI graphics card.
Terminal:  AMD K6-2 300 MHz, 64 MByte SDRAM.
Guardian:  PentiumPro 200 MHz, 64 MByte RAM.
Other:     AMD Duron 1.0 GHz, 512 MByte DDR RAM (for games).
</literallayout>
<simpara>
Guardian and Terminals are on two different networks. Regular load: Two
people with KDE 3.1 with kmail, konqueror and/or Mozilla Firebird under
SuSE 8.2.
</simpara>

</section>
<section>
<title>And Finally</title>
<simpara>
This text is dedicated to my uncle Gary W. Marklund, who gave me the Unix
bug.
</simpara>

</section>
</section>
</article>