LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/Mock-Mainframe.xml

1997 lines
101 KiB
XML
Raw Normal View History

new
2003-10-07 20:24:05 +00:00
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://docbook.org/xml/4.2/docbookx.dtd" []>
<!--
Future work:
- Sound to Linux Terminals
- Clustering (Mosix as mock mainframe core)
-->
<article id="mockmainframe">
<articleinfo>
<title>The Mock Mainframe Mini-HOWTO</title>
<author>
<firstname>Scot</firstname>
<othername>W.</othername>
<surname>Stevenson</surname>
<affiliation>
<address><email>scot@possum.EXSPAM.in-berlin.de</email></address>
</affiliation>
</author>
<pubdate>2003-10-07</pubdate>
<!-- Most recent revision goes at the top; list in descending order -->
<revhistory>
<revision>
<revnumber>1.0</revnumber>
<date>2003-10-07</date>
<authorinitials>sws</authorinitials>
<revremark>First finished release</revremark>
</revision>
<revision>
<revnumber>BETA 1.0</revnumber>
<date>2003-09-28</date>
<authorinitials>sws</authorinitials>
<revremark>Last public draft</revremark>
</revision>
<revision>
<revnumber>ALPHA 0.3</revnumber>
<date>2003-09-23</date>
<authorinitials>sws</authorinitials>
<revremark>Last internal draft</revremark>
</revision>
</revhistory>
<!-- Provide a good abstract; a couple of sentences is sufficient -->
<abstract>
<para>
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.
</para>
</abstract>
</articleinfo>
<sect1 id="intro">
<title>Introduction</title>
<!-- Legal Sections -->
<sect2 id="copyright">
<title>Copyright and License</title>
<para>
This document, <emphasis>The Mock Mainframe Mini-HOWTO</emphasis>,
is copyrighted (c) 2003 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">
http://www.gnu.org/copyleft/fdl.html</ulink>.
</para>
</sect2>
<sect2 id="disclaimer">
<title>Disclaimer</title>
<para>
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.
</para>
<para>
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.
</para>
</sect2>
<!-- Give credit where credit is due...very important -->
<sect2 id="credits">
<title>Credits / Contributors</title>
<para>
This document has benefitted greatly from the feedback,
commentary, and corrections provided by the following people:
</para>
<para>
Gareth Anderson,
Doug Jensen,
Jim McQuillan,
Volker Meyer,
Binh Nguyen,
Douglas K. Stevenson.
</para>
<!--
<itemizedlist>
<listitem>
<para>Individual 1 <email>someone1 (at) somewhere.org</email></para>
</listitem>
<listitem>
<para>Individual 2 <email>someone2 (at) somewhere.org</email></para>
</listitem>
</itemizedlist>
-->
</sect2>
<!-- Feedback -->
<sect2 id="feedback">
<title>Feedback</title>
<para>
Feedback is most certainly welcome for this document. Please send
your additions, comments and criticisms to the following
email address: <email>scot@possum.DESPAM.in-berlin.de</email>.
Feedback can be in English or German.
</para>
</sect2>
<!-- Translations -->
<sect2 id="translations">
<title>Translations</title>
<para>
There are currently no translations.
</para>
</sect2>
</sect1>
<!-- ######################################### -->
<sect1 id="background">
<title>Background</title>
<sect2 id="why">
<title>Why This Text?</title>
<para>
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 -- er, <emphasis>our</emphasis> --
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.
</para>
<para>
In other words, somewhere along the way, I turned into an
adult.
</para>
<para>
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
</para>
<itemizedlist>
<listitem>
<para>
<emphasis role="bold">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.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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
<quote>lock-down</quote> state where threats are
minimal until I find the time
to patch holes.
</para>
</listitem>
</itemizedlist>
<para>
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
<quote>standard</quote> 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.
</para>
</sect2>
<sect2 id="overview">
<title>Reasoning and Overview</title>
<para>
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 -- such as <filename>xload</filename>,
<filename>top</filename>, or <filename>uptime</filename> --
and you'll see just how much of your expensive hardware is
busy doing nothing.
</para>
<para>
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 <quote>a computer
on every desktop</quote> 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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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
<quote>little</quote> mainframe -- a <quote>mock</quote>
mainframe, if you will.
</para>
<para>
The basic setup has three parts:
</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">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.
</para>
</listitem>
<listitem>
<para><emphasis role="bold">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.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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 <quote>guardian</quote>
that handles Internet connections.
</para>
</listitem>
</itemizedlist>
<para>
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.
</para>
</sect2>
<sect2 id="consider"><title>What You Should Be Aware Of</title>
<para>
A mock mainframe setup is not for everybody. It is based on
the following assumptions:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis role="bold">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.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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 <quote>Quake 3</quote> 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.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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 -- and remember to get
somebody to guarantee that uptime in writing while you
are at it.
</para>
</listitem>
</itemizedlist>
<para>
Some examples of when a mock mainframe might make sense:
</para>
<itemizedlist>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
You have a small, closed teaching system that can't be
expensive or take too much time to administer.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</itemizedlist>
<para>
(If you have found other situations where this setup works,
please let me know.)
</para>
</sect2>
<sect2>
<title>How This Text Is Organized</title>
<para>
First, we will take a look at the individual parts of the setup
-- 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.
</para>
</sect2>
</sect1>
<!-- ######################################### -->
<sect1 id="pieces">
<title>The Individual Pieces</title>
<!-- ######################################### -->
<sect2 id="mainframe">
<title>The Mock Mainframe</title>
<!-- ######################################### -->
<sect3 id="hardware">
<title>The Hardware</title>
<formalpara><title>Examining your needs.</title>
<para>
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).
</para>
</formalpara>
<para>
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.
</para>
<para>
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.
</para>
<para>
For example, for our current setup at home in 2003 -- two
people running SuSE 8.2 and KDE 3.1 with a regular load of
email clients, multiple browser windows, chatting and music
playback -- 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 <quote>two</quote>). 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.
</para>
<formalpara><title>Multiple vs. single processors</title>
<para>
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.
</para>
</formalpara>
<para>
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), 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 <quote>SMP</quote>-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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
(At the time of writing, there was also the problem of
latency in the Linux kernel. In the 2.4.* 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.*
kernels are supposed to be far more responsive, which would
be the end of that problem and of this paragraph,too).
</para>
<formalpara><title>Storage: SCSI vs. IDE, RAID</title>
<para>
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
help of 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.
</para>
</formalpara>
<para>
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.
</para>
<formalpara><title>Sane graphics.</title>
<para>
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.
</para>
</formalpara>
<formalpara><title>Heat and Lightning.</title>
<para>
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.
</para>
</formalpara>
<para>
In summary:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis role="bold">Think RAM before processor
speed.</emphasis> With more than one user,
you'll be using more memory and less CPU time
than you expect.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">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.
</para>
</listitem>
</itemizedlist>
<para>
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.
</para>
</sect3>
<!-- ######################################### -->
<sect3 id="software">
<title>The Software</title>
<formalpara><title>Some background on X.</title>
<para>
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 -- KDE, Gnome, Blackbox -- sit on top of X,
and almost all variants of Unix use X.
</para>
</formalpara>
<para>
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 --
screen(s), keyboard, and mouse -- 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.
</para>
<para>
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.
</para>
<para>
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 <quote>X server</quote>, because it
<quote>serves</quote> the actual program, which in turn is
called the <quote>X client</quote>. In this text, we'll
stick to <quote>host</quote> and <quote>terminals</quote>
to avoid confusion.
</para>
<para>
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.
</para>
<para>
First, we have to start the program that handles remote X
logins. This is <filename>xdm</filename>
(<emphasis>X Display Manager</emphasis>). Depending on your
system and taste, you might want to use the KDE version
<filename>kdm</filename> or Gnome version
<filename>gdm</filename> 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 <filename>xdm</filename> (or
whatever) to start up in the run level that you ususally
use for graphics (for example, run level 5 for SuSE 8.2).
</para>
<para>
Even when <filename>xdm</filename> 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
<filename>/etc/sysconfig/displaymanager</filename>). If you
have to do it the hard way, you will want to change
<filename>/etc/X11/xdm/xdm-config</filename> and
<filename>/opt/kde3/share/config/kdm/kdmrc</filename> if
you are using <filename>kdm</filename>.
</para>
<para>
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 -- <emphasis>not</emphasis> in graphics
mode (runlevel 3 instead of 5 on SuSE systems, use
<command>init 3</command> as root from a shell). Log in
and type
<programlisting>
/usr/X11/bin/X -terminate -query &lt;host&gt;
</programlisting> where <quote>&lt;host&gt;</quote> 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.
</para>
</sect3>
</sect2>
<!-- ######################################### -->
<sect2 id="terminals">
<title>The Terminals</title>
<para>
The machines you use to connect to the mock mainframe
should be inexpensive, easy to maintain and, from a
security point of view, expendable.
</para>
<!-- ######################################### -->
<sect3 id="dualboot">
<title>Dual Boot Machines</title>
<para>
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
<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.
</para>
<para>
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:
</para>
<orderedlist>
<listitem>
<para>
Go to <filename>/etc/X11/xdm/</filename>. In the
file <filename>Xservers</filename>, comment out the
line that is either
<programlisting>
:0 local /usr/X11R6/bin/X :0 vt07
</programlisting>
or something similar by putting a hash mark
(<quote>#</quote>) at the beginning. This will stop
the computer from starting up X locally during boot
time.
</para>
</listitem>
<listitem>
<para>
In <filename>/etc/inittab</filename>, insert a new
line such as (for SuSE 8.2)
<programlisting>
xx:5:respawn:/usr/X11R6/bin/X -query &lt;host&gt;
</programlisting>
where <quote>&lt;host&gt;</quote> again is the name
of the mock mainframe. The <quote>5</quote> is
the runlevel that boots with X; <quote>xx</quote>
is just a label I picked; you might have to adapt
both to your system <emphasis>(please be
careful:</emphasis> Playing around with
<filename>inittab</filename> can cause big
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.
</para>
</listitem>
</orderedlist>
<para>
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.
</para>
</sect3>
<!-- ######################################### -->
<sect3 id="ltsp">
<title>Linux Terminals</title>
<para>
The <ulink url="http://www.ltsp.org">Linux Terminal Server
Project</ulink> [http://www.ltsp.org] (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). At LinuxWorld 2003 in San
Francisco, the LTSP project deservedly took the award for
<quote>Best Open Source Project</quote>. 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.
</para>
<formalpara><title>Required hardware.</title>
<para>
More likely than not, somewhere in your cellar or
garage (or wherever you keep the stuff your partner
lovingly calls <quote>all that crap</quote>),
you probably have a hopelessly outdated mainboard and
processor that you've been saving because you never
know. Well, guess what.
</para>
</formalpara>
<para>
If you are using a 100 Mbit (<quote>Fast</quote>)
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 -- <quote>decent</quote> doesn't necessarily mean
a AGP graphics card with 128 MByte RAM, it means a clear,
crisp picture.
</para>
<para>
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 <quote>bootable</quote> 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:
<programlisting>
00:50:56:81:00:01
</programlisting>
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.
</para>
<para>
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.
</para>
<formalpara><title>How they work.</title>
<para>
The LTSP home page has an in-depth technical discussion
of what happens when the system powers up. In brief,
human terms:
</para>
</formalpara>
<para>
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:
<blockquote><para><emphasis>
Got your MAC? Good. Now scream for help as
loud as you can.
</emphasis></para></blockquote>
The terminal's call goes through the whole
(local) network. On the mock mainframe, a program called
<filename>dhcpd</filename> (<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.
</para>
<para>
Using some more code from the boot program, the terminal
starts a program called <filename>tftp</filename>
(<emphasis>Trivial File Transfer Protocol</emphasis>), a
stripped-down version of the venerable
<filename>ftp</filename>. This downloads the kernel from
the host machine. The terminal then boots this kernel.
</para>
<para>
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
<filename>NFS</filename> (<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
<filename>xdm</filename>, and throws up the login screen.
</para>
<para>
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.
</para>
<para>
Running <filename>dhcpd</filename>,
<filename>tftpd</filename>, and <filename>nfsd</filename> 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.
</para>
<formalpara><title>Setting up the software.</title>
<para>
On the server (mock mainframe) side, you need to install
<filename>nfsd</filename>, <filename>tftpd</filename>, and
<filename>dhcpd</filename>, which your distribution should
include as standard packages.
</para>
</formalpara>
<para>
Leave their configuration files untouched for now. The
LTSP configuration and installation programs will do most
of the work for you. There are some things you still need
to do by hand (at time of writing, the LTSP people were
working on a more automatic installation system). Edit the
files:
<variablelist>
<varlistentry>
<term><filename>/etc/dhcpd.conf</filename></term>
<listitem>
<para>
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. Also, check to see if the
kernel pathname is correct.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<filename>/opt/ltsp/i386/etc/lts.conf</filename>
</term>
<listitem>
<para>
These options control the terminal itself.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>/etc/hosts</filename></term>
<listitem>
<para>
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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>/etc/hosts.allow</filename></term>
<listitem>
<para>
Though not mentioned in the current LTSP
documentation, you probably will have to
add the following lines to this file:
<programlisting>
rpc.mountd : &lt;terminal&gt; : ALLOW
rpc.mountd : ALL : DENY
</programlisting>
where <quote>&lt;terminal&gt;</quote> is
the terminal's IP address. This tells the
host to allow the terminal to mount the
NFS file system.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
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</ulink> [http://www.rom-o-matic.net/]), 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.
</para>
<formalpara><title>Using the terminals.</title>
<para>
Just how many Linux Terminals can one mock mainframe
support? The LTSP documentation gives the following
example:
<blockquote><para>
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!
</para></blockquote>
(This part of the documentation was written in March
2002, hence the reference to Netscape, an ancestor of
Mozilla Firebird. StarOffice is a commercial variant
of OpenOffice.)
</para>
</formalpara>
<para>
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
<programlisting>
xhost +&lt;host&gt;
</programlisting>
where <quote>&lt;host&gt;</quote> is the name of the mock
mainframe. Then, move to a different terminal and start a
program such as <filename>xeyes</filename> or
<filename>xroach</filename>:
<programlisting>
xeyes -display &lt;terminal&gt;:0 &amp;
</programlisting>
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
<programlisting>
xhost -&lt;host&gt;
</programlisting>
You can also use this example to point out why it is
dangerous to use the <filename>xhost</filename> command.
</para>
<para>
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
<filename>xlock</filename> suite. For example
<programlisting>
xlock -inwindow -mode kumppa
</programlisting>
or more generally
<programlisting>
xlock -inwindow -mode random
</programlisting>
Though the results will depend on your hardware, this
usually takes care of any doubts.
</para>
<para>
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.
</para>
</sect3>
<!-- ######################################### -->
<sect3 id="realxterms">
<title>Real X Terminals</title>
<para>
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.
</para>
<para>
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.
</para>
</sect3>
<!-- ######################################### -->
<sect3 id="xserverprogs">
<title>X Server Programs</title>
<para>
As a final way of connecting to the mock mainframe, there
are <quote>X server</quote> 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.
</para>
<para>
Most X servers for <emphasis role="bold">Windows</emphasis>
cost money, in some cases a lot of money. The single
exception I am aware of is <ulink
url="http://cygwin.com/xfree/">Cygwin</ulink>
[http://cygwin.com/xfree/], which ports X (and GNU tools)
to Windows machines.
</para>
<para>
If you have an <emphasis role="bold">Apple</emphasis>
computer with OS X, you are in better shape. Check the
<ulink url="http://www.xdarwin.com/">XDarwin</ulink>
[http://www.xdarwin.com/] 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.
</para>
<para>
(There is one GPL X Server written in Java you might try:
<ulink url="http://www.jcraft.com/weirdx/">WeirdX</ulink>
[http://www.jcraft.com/weirdx/], though the author points
out it is not made for heavy loads.)
</para>
</sect3>
<para>
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.
</para>
</sect2>
<!-- ######################################### -->
<sect2 id="support">
<title>The Support Machines</title>
<para>
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.
</para>
<para>
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 -- which increasingly means anybody on the
planet -- can attack it.</para>
<para>
For better security, put a machine between the mock mainframe
and the outside world. Make sure this <emphasis
role="bold">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.
</para>
<para>
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="bold">Terminal Mother</emphasis>) or to burn CDs (a
<emphasis role="bold">Burner</emphasis>).
</para>
</sect2>
</sect1>
<!-- ######################################### -->
<sect1 id="alltogether">
<title>Putting the Pieces together</title>
<para>
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.
</para>
<!-- ######################################### -->
<sect2 id="network_security">
<title>Security</title>
<para>
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.
</para>
<sect3>
<title>Needs revisited</title>
<para>
In most books on securing computer systems, there comes a
point where the author tells you to sit down and
<quote>formulate a security policy</quote>. 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.
</para>
<formalpara><title>What are you trying to protect?</title>
<para>
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.
</para>
</formalpara>
<formalpara><title>Who or what are the forces of evil?</title>
<para>
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?
</para>
</formalpara>
<para>
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 <emphasis>probability</emphasis> 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?
</para>
<para>
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.
</para>
<para>
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 -- when is the last time you looked at one
of the files in <filename>/var/log/</filename>? -- 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.</para>
<para>
Even if you decide that detection systems like
<filename>tripwire</filename> 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?
</para>
<para>
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 -- 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 <quote>reinstall from scratch</quote>
as the standard response all problems great or small (but
make sure that your backups are not compromised).
</para>
<para>
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.
</para>
</sect3>
<sect3>
<title>Security Principles</title>
<para>
Back to prevention: When you design your system,
keep these security principles in mind:
</para>
<formalpara><title>Building better baskets.</title>
<para>
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 stupid 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.
</para>
</formalpara>
<formalpara><title>Avoiding complexity.</title>
<para>
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.
</para>
</formalpara>
<formalpara><title>Encapsulation.</title>
<para>
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 -- monitor,
keyboard, and mouse -- 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.
</para>
</formalpara>
<formalpara><title>Defense in Depth.</title>
<para>
Preventative security measures are only ways of buying
time until your response kicks in -- 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.
</para>
</formalpara>
<para>
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.
</para>
<para>
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.
</para>
<formalpara><title>Choke Points.</title>
<para>
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.
</para>
</formalpara>
</sect3>
</sect2>
<!-- ######################################### -->
<sect2 id="network_phys">
<title>Network Hardware</title>
<para>
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.
</para>
<para>
(I have no experience of running X terminals over a
wireless LAN. If anybody does, I would be glad to hear from
them, because we could put in another paragraph right here.)
</para>
</sect2>
<!-- ######################################### -->
<sect2 id="network_geo">
<title>Network Geography</title>
<para>
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.*.* 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.
</para>
<para>
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.
</para>
</sect2>
</sect1>
<!-- ######################################### -->
<sect1 id="users">
<title>Life With Multiple Users</title>
<para>
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.
</para>
<sect2><title>Shared Resources</title>
<para>
One of your biggest headaches will probably be <emphasis
role="bold">CD-ROMs</emphasis> and <emphasis
role="bold">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
<command>cdparanoia</command>) 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.
</para>
<para>
One thing you can do is to move the CD-R/W onto a support
machine (the <emphasis role="bold">Burner</emphasis>). Then you
can either 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
<command>ftp</command> or <command>scp</command>. Then the user
can walk over to the machine and burn it by hand.
</para>
<para>
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.
</para>
<para>
Other resources are less of a problem. Traditionally, you used
a <emphasis role="bold">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.
</para>
</sect2>
<sect2><title>Screen Savers and Other Gimmicks</title>
<para>
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.
</para>
<para>
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.
</para>
<para>
Users consider playing around with their screen savers one of
their basic computer rights, so just blocking everything except
the <quote>blank screen</quote> 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 <filename>xlock</filename> command as a
screen saver, you can move it to
<filename>xlock.real</filename> and then create a shell script
named <filename>xlock</filename>:
<programlisting>
#!/bin/bash
nice -19 xlock.real $@
</programlisting>
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.
</para>
</sect2>
<sect2><title>Idle Terminals</title>
<para>
Another annoying habit users have is to walk away from their
terminals while they are still logged in. KDE and Gnome have a
<quote>Lock Screen</quote> button right next to their
<quote>Logout</quote> 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.
</para>
<para>
One way to deal with this is to have the system shut down
abandoned terminals with the <command>idle daemon</command>,
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.
</para>
</sect2>
</sect1>
<!-- ######################################### -->
<sect1 id="hardcore">
<title>Going Hardcore: Non-GUI Systems</title>
<para>
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 <filename>blackbox</filename>.
Though your distribution should set up the basics for you, you will
probably have to edit the configuration files (in this case, the
<filename>blackbox</filename> menu file that is specified in
<filename>~/.blackbox</filename>) for each user. Also, make
sure your users know how to work the environment. At the very least,
teach them that <command>CTRL-ALT-BACKSPACE</command> kills the X
server.
</para>
<para>
But real men and women don't need a graphical user interface (GUI)
at all: They use a command shell such as <command>bash</command>.
Before the XFree86 group 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
<quote>Linux</quote> system (which is why
<quote>GNU/Linux</quote> is the more percise term). If
you have no choice but to get by with really weak hardware -- we're
talking anything down to a 386SX here -- 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.
</para>
<!-- ######################################### -->
<sect2 id="cl_intro">
<title>Why the Command Line Is Cool</title>
<para>
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
<command>bash</command> 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.
</para>
<para>
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:
</para>
<para>
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
<command>bash</command>. Other script languages such as Python
or Perl might be more powerful, but the command line is always
included and has far less overhead.
</para>
<para>
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
<command>awk</command> is named for its creators Aho,
Kernighan, and Weinberger), only make sense in a historical
context (the <emphasis>tape archiving utility</emphasis>
<command>tar</command> is now used to distribute compressed
files), or look like they are typos
(<command>umount</command> instead of <quote>unmount</quote>,
<command>passwd</command> instead of <quote>password</quote>).
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.
</para>
<para>
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 <command>rm -rf /bin/laden</command>,
and you will have 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
<command>xterm</command> or the less resource-hungry
<command>rxvt</command>).
</para>
<para>
The CLI has just about every tool you'll need:
<command>mutt</command> or <command>pine</command> for email
(real hard-core basket cases use <command>mail</command>),
<command>w3m</command> or <command>lynx</command> for surfing,
and of course the legendary editors <command>vi</command> (more
commonly <command>vim</command> these days) or
<command>emacs</command>. 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.
</para>
</sect2>
<!-- ######################################### -->
<sect2 id="cl_textterms">
<title>Setting Up Text Terminals</title>
<para>
Basically, you have the same options for text terminals as you
do with X terminals. Everything is just a bit easier.
</para>
<para>
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 <command>telnet</command> (on secure, closed networks) or
<command>ssh</command> (everywhere else) will do. Microsoft
Windows includes a <command>telnet</command> 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</ulink>
[http://www.chiark.greenend.org.uk/~sgtatham/putty/]. Apple
users with Mac OS X should have no problems with their clients.
</para>
<para>
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 <emphasis>Star Trek</emphasis>
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.
</para>
<para>
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"><emphasis>The
Linux Gazette</emphasis></ulink>
[http://www.linuxgazette.com/issue70/arndt.html], 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</ulink>
[http://www.itworld.com/Comp/2384/LWD010511penguin2/] 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.
</para>
<para>
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.
</para>
</sect2>
<!-- ######################################### -->
<sect2 id="cl_commands">
<title>Useful Shell Commands</title>
<para>
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.
</para>
<formalpara><title>Play nice</title>
<para>
The <command>nice</command> 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.
</para>
</formalpara>
<para>
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
<programlisting>
oggenc -o showersong.ogg showersong.wav
</programlisting>
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 <command>nice</command>:
<programlisting>
nice oggenc -o shower.ogg shower.wav
</programlisting>
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 (<quote>&amp;</quote>) to the end
of the line:
<programlisting>
nice oggenc -o shower.ogg shower.wav &amp;
</programlisting>
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.
</para>
<para>
The <command>nice</command> 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.
</para>
<formalpara><title>Do it later.</title>
<para>
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.
</para>
</formalpara>
<para>
The <command>at</command> 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 <quote>at</quote>
followed by the time you want execution to start, and then hit
the <command>ENTER</command>-key. Then you type in the command
itself, followed by another <command>ENTER</command>, and
finally a <command>CTRL-d</command> to finish the sequence:
<programlisting>
me@mycomputer:~&gt; <command>at 20:00</command>
warning: commands will be executed using /bin/sh
at&gt; <command>nice oggenc -o shower.ogg shower.wav</command>
at&gt; <command>&lt;CTRL-d&gt;</command>
job 1 at 2003-09-28 20:00
</programlisting>
<command>At</command> accepts just about any time format:
Americans get to use their quaint <quote>08:00pm</quote>
notation instead of <quote>20:00</quote>, and there are a whole
set of shortcuts like <command>midnight</command>,
<command>noon</command> or even <command>teatime</command>.
<command>at</command> sends the output of the command to your
mailbox.
</para>
<formalpara><title>Do it when you are bored.</title>
<para>
A close relative of <command>at</command> uses system
load, not time of day to determine when a command should
be run: <command>batch</command> 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
<command>uptime</command> from a shell or
<command>xload</command> under X Windows). The
documentation gives this value as 0.8. The syntax for
<command>batch</command> is basically the same as for
<command>at</command>, except that the time field is
optional.
</para>
</formalpara>
</sect2>
</sect1>
<!-- ######################################### -->
<sect1>
<title>Odds and Ends</title>
<sect2>
<title>Mock Mainframe Case Studies</title>
<formalpara><title>Two People Home Setup (Sep 2003)</title>
<para>
<emphasis>Mainframe:</emphasis> Dual Intel
Pentium II Xeon 450 MHz 512 KByte cache CPU, 384 MByte
PC-100 RAM, PCI graphics card.
<emphasis>Terminal:</emphasis> AMD K6-2 300
MHz, 64 MByte SDRAM.
<emphasis>Guardian:</emphasis> PentiumPro 200
MHz, 64 MByte RAM.
<emphasis>Other:</emphasis> AMD Duron 1.0 GHz, 512 MByte
DDR RAM (for games).
</para>
</formalpara>
<para>
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.
</para>
</sect2>
<sect2>
<title>And Finally...</title>
<para>
This text is dedicated to my uncle Gary W. Marklund, who gave
me the Unix bug.
</para>
</sect2>
</sect1>
</article>