2.1. Why This Text?

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, our — 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.

In other words, somewhere along the way, I turned into an adult.

It happens to the best of us, I'm told, and there are benefits that go beyond a de facto 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

Easy to administer. 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 any maintenance at all for months at a time.

Easy to afford. 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.

Easy to secure. 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.

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.

2.2. Reasoning and Overview

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 xload, top, or uptime — and you'll see just how much of your expensive hardware is busy doing nothing.

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.

There are good commercial reasons for hard- and software companies not to like multiuser 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.

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 thin clients) 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.

In a nutshell, this text is about centralizing small computer systems to save time and money. 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 — a "mock" mainframe, if you will.

The basic setup has three parts:

The Mock Mainframe. 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.

The Terminals. 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.

Support Machines. 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.

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 lot of references, but that just goes to show how much I am standing on the shoulders of others here.

(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.)

2.3. What You Should Be Aware Of

A mock mainframe setup is not for everybody. It is based on the following assumptions:

A small group of users. 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.

A sane system load. 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 mock mainframe), this is not a setup where you should have your kids playing Quake 3 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.

Some downtime tolerance. 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.

Some examples of when a mock mainframe might make sense:

• 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.

• You have a small, closed teaching system that can't be expensive or take too much time to administer.

• 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.

• 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.

(If you have found other situations where this setup works, please let me know.)

2.4. How This Text Is Organized

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.