Software development techniques behind the magic user interface

Multi-Touch Developer Journal

Subscribe to Multi-Touch Developer Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Multi-Touch Developer Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Multi-Touch Authors: Qamar Qrsh, Suresh Sambandam, Jayaram Krishnaswamy, Kevin Benedict, Jnan Dash

Related Topics: MultiTouch Developer Journal, Apache Web Server Journal

Multi-Touch: Article

How to install Linux over a network

Part 5 in our series 'How to create a Linux-based network of computers for peanuts'

(LinuxWorld) -- Linux doesn't exist in a vacuum. The PC industry remains driven by Microsoft and the ever-upward hardware requirements of each successive transmogrification of Windows.

Linux distribution developers recognize this and expend great effort attempting to ensure each new release of their product installs and configures more easily than previous versions -- on well-equipped, late-model PCs.

That's a good thing, but as a result recent Linux converts have never installed Linux on the sort of minimal hardware that makes Linux server-centrism so cost effective: Aged 486s and first-generation Pentiums with little RAM and no CD-ROM drive.

In Part 4, we ripped into the nuts and bolts of post-installation Linux PC X terminal configuration. For those whose powerful network still lies dormant for lack of an installed operating system on the desktop machines, we turn now to Part 5.

In Part 4, I revealed my preference (you may read that as "my strong prejudice," if you like) for the Slackware Linux distribution when configuring X terminals. I'm eclectic in my tastes when configuring any machine and prefer to pick and choose between all available distributions to use the one I find most suited (read that as "easiest") to deploy for specific tasks. For X terminals -- and for me -- the easiest has been Slackware, and since we are doing this the Cheap and Easy way, that is the first distribution we will discuss.

The PC X terminal does not need the latest version of Linux. In fact, it is often better to step back two or three years and choose a release designed to install on the hardware many people were using to experiment with Linux at the time. One of my more recent acquisitions was a stack of P75 machines. Each has 8 megabytes RAM, hard drives between 300 and 500 megabytes, built-in S3 Trio64 video adaptors with 1 megabyte of VRAM, a single 3.5-inch floppy drive, and a tape drive that remains useful for plugging what would otherwise be a hole on the front panel. Network adaptors had been removed before they came into my possession.

These machines became available for the asking when a local agency upgraded from Windows 95 to Windows 2000. A bit short of RAM, perhaps, but otherwise ideal for use as X terminals following the installation of a $1 NIC from a cache I keep on hand. A good operating system to power these machines? Slackware 3.5.

Follow along now as I describe the basics of installing Slackware 3.5 on one of them. You will find that the network installation of Linux doesn't differ greatly from a standard installation that uses a local CD-ROM, and you will find that it meets our twin criteria of Cheap and Easy. Cheap, because it eliminates redundant hardware. As for Easy, well, keep reading and find out for yourself.

In this installment, we also discuss How to make AbiWord run properly and touch on security issues you need to keep in mind.

Before we begin, review Part 3 to ensure that your application server is ready to export the CD-ROM drive to support NFS (Network File System) installation. Part 4 also has information on how to obtain a Slackware 3.5 CD. If you are unsure your application server is running nfsd, try running ps ax to determine what is running. As always, the man pages and the Linux Documentation Project are good places to start. (See resources below.) In many cases, there is nothing you will need to do beyond the simple configuration detailed in Part 3. There is a good chance your Linux distribution installs and starts nfsd by default.

You need two freshly formatted 3.5-inch floppy disks to create the Slackware "boot" and "root" disks. Defective floppies are the No. 1 problem stalling installation. Use good floppies. Have spares. Format them yourself, even if they are pre-formatted. (You have been warned.)

Step 1. Mount the CD

At your application server, as root, enter the following command after placing the Slackware 3.5 CD in the CD-ROM drive:

mount /dev/cdrom /mnt

This command may need to be adjusted accordingly to reflect the distribution you are using on the application server and choices you made during installation and configuration of that machine. Our example is based on the assumption that the mount point for the CD-ROM is /mnt. If you use a different mount point, substitute that mount point for /mnt in the following steps. (Duh!)

Step 2. Create a boot floppy for X terminal installation

Change to the /mnt directory:

cd /mnt

Examine the contents of the Slackware 3.5 CD

ls -l

See a directory named bootdsks.144? This directory contains boot images for use with 3.5 inch floppies, hence the 144 extension. Change into that directory and run ls -l again -- use less because there are lots of different images.

ls -l | less

The one we are looking for is called net.i. A logical choice of names, if a bit terse, because this file is a "NET"work boot "I"mage.

We don't simply copy this boot image to the floppy disk: We use the dd utility. Label one of the freshly formatted floppies "net.i" and place it in the first floppy drive of the application server. Use the following command, as root, to create the boot floppy:

dd if=net.i of=/dev/fd0

Once the lamp on the floppy drive is extinguished, and you are returned to the command prompt, you may remove the floppy disk. See man dd for additional details.

Step 3. Create a root floppy for X terminal installation

Label the remaining floppy color.gz and place it in the first floppy drive. Then cd .. to leave the bootdsks.144 directory. You are now looking for the repository of root disks and the ls -l command will reveal -- surprise! -- rootdsks. No extension to the name this time, just rootdsks. So,

cd rootdsks

and prepare to place the mother of all root disks, the Slackware color.gz root image, on the floppy. (This is the same root disk used for most Slackware installations whether from a local CD-ROM or via the network). Again you will use dd:

dd if=color.gz of=/dev/fd0

As soon as the floppy drive's lamp goes dark and you are returned to the command prompt, remove the floppy. You are done at the application server for now, but don't unmount the CD-ROM.

Step 4. Boot the X terminal with the net.i boot disk

The faint of heart may need to break for a wee dram but those made of sterner stuff will recover quickly from the stress of carrying two floppy disks all the way from the application server to the first X terminal machine. (Review part 1, part 2, part 3, and part 4 if you're confused by how the network, server, and local clients are set up.)

As soon as you are seated at the X terminal workstation, insert the net.i boot disk into the floppy drive of the X terminal PC and turn on the power. If you haven't already done so, it may be necessary to enter the BIOS setup utility to permit the machine to boot from the floppy drive first. Chances are, the hard drive has a bootable installation of MS-DOS or Windows 95 already installed. (It makes you wonder sometimes -- do people really want me to see the files they leave on their machines when they get rid of them? I mean, I've been to New Orleans, but come on, people! Attention Windows users: Use format c: as the last step before disposal.)

The floppy will then load and you are presented with some on-screen information that is worth reading... and a boot prompt. As soon as you are ready, press the ENTER key.

Step 5. Write down the information about your network card

It will take a few minutes, but the computer will eventually pause and prompt you to:

Insert root floppy disk to be loaded into ramdisk and press ENTER

Don't do that.

Look above this admonition and locate a line that references eth0. eth0, is of course, your NIC and you may need the information later. The Slackware net.i boot disk looks for the NIC as it boots and reports it's findings on-screen -- including both the type (NE2000, 3c509, etc.,) and values for IRQ and IO (irq 5, 0x280 etc.,). I often grab my Dymo Label Maker and put this information on the case of the machine below the label I made earlier with the IP address assigned to it.

NOW you can Insert root floppy to be loaded into ramdisk and press ENTER. Replace the net.i boot disk with the color.gz root disk in the floppy drive and let it load.

Step 6. Login as "root" and create Linux partitions

After the color.gz root disk is finished loading, you will be prompted to login as root without a password. You will then want to use fdisk to create two primary partitions just as described in part 4.

Since this machine is a Pentium 75, from prior experience, I know that it will likely permit me to enter the ncurses-based setup utility without difficulty as soon as I am done with fdisk -- even though it has only 8 megabytes RAM. But if it happened to give me any trouble during installation that appears to be the result of insufficient RAM, I would repeat Step 4 and Step 5. As soon as I partition the disk, I would put the swap partition to work:

mkswap /dev/hda2

And then:

swapon /dev/hda2

If the machine had been an 486, and if increasing the RAM from 8 megabytes up to 12 or 16 megabytes hadn't been an option (maybe I'm too lazy to open the case, or I don't have any spare RAM, or I'm stubborn) -- I would plan to do this in every case. The net.i installation is slightly more "resource intensive" than installation from a local CD-ROM.

Step 7. Launch the setup utility

Simply type setup and press enter. No different than an installation from a local CD-ROM. If it had been necessary to initialize a swap partition before running setup, I would not permit the setup utility to format and initialize the already running swap partition. That too, is no different from a standard installation -- you simply follow the script. You may need to remap your keyboard, and you will be asked to select your / directory. Very standard stuff and quite easy to follow.

Step 8. Select source media

This is the first significant departure from the usual installation from a local CD-ROM. You will be asked to select between several possible sources. Although you are actually using a CD-ROM, it is not located on this computer. It is mounted and exported as an NFS partition at the application server, so select Install via NFS.

Step 9. Orient the installation utility to your network configuration

The first question you will be asked is your IP address. This series (including part 1, part 2, part 3, and part 4) assumes you are following along and creating a LAN that includes eight X terminals with Class C addresses in the range 192.168.1.20 through 192.168.1.27. If this is the first X terminal you are setting up, then enter the first IP address:

192.168.1.20

Next, you will be asked for your netmask and you will read a hint that this will typically be 255.255.255.0, and unless you did something different when you set up the application server, you will want to take the hint and enter:

255.255.255.0

Leave the following field asking for a gateway IP blank. (If your application server is on the other side of a gateway, then you aren't following our basic recipe and you will have to adjust procedures to fit your unique circumstances.)

When you are asked for your NFS server IP, enter the address you assigned when we configured the application server in part 3 of this series. I'll assume you assigned that machine:

192.168.1.10

Finally, you will be asked for the Slackware source directory. Now then, if your application server's CD-ROM is mounted as /mnt you will enter:

/mnt/slakware

Yes, that's slakware without the "c." (Windows compatibility, and all that.)

Step 10. Confirm that the NFS partition is mounted

As soon as you pressed enter, the installer will advise that it is temporarily switching to text mode as it configures the Ethernet card and connects to the server's CD-ROM. If all goes as expected, it should report as the last line under Current Mount Table:

192.168.1.10:/mnt/slakware on /var/log/mount type nfs (ro, addr=192.168.1.10)

And below that:

"If you see errors above and the mount table doesn't show your NFS server, then try setting up NFS again. Do you think you need to try this again ([y]es, [n]o)?"

If it all looks okay, the correct response is [n]o.

Step 11. Select disksets to install

Slackware divides the distribution into groupings of packages that are easy and intuitive to select for installation called disksets: a legacy of the days when floppy installations were common. For an X terminal, everything we need is contained in disksets:

  • A The base Linux system
  • N Networking utilities
  • X X Free86 and X Window System utilities

If this example machine had been equipped with a very small hard drive, or if it was intended for use in a network where additional security considerations are necessary, I would opt to select packages and delete things like Apache, chat clients, all window managers, etc. In this instance, I have plenty of room and the default installation is adequately secure, so I let the installation utility install everything in these three disksets.

Step 12. Carry on

The remainder of the installation is no different than any other Slackware Linux installation, and similar enough to many other distributions that you shouldn't have any real difficulties. The Slackware site, and the books I mentioned in part 4 are good sources of Slackware-specific information.

The information provided by the net.i boot disk (Step 3, above) may come in handy following the first reboot of the installed system. A number of factors, including your choice of installed kernels, may render the network unreachable after the network installation of Slackware. The easiest fix is usually to open /etc/rc.d/rc.modules with a text editor, such as vi, and uncomment (delete the leading hash mark{#}) of the line that corresponds to your NIC, so that the appropriate kernel module will load during system initialization. The easiest way to get the module loaded is to then reboot.

Step 13. Testing, testing

Once the network is up and running ping the server IP to test the connection:

ping 192.168.1.10

You can turn to the xf86config utility and configure the X terminal as per part 4 of this series.

Several machines can share the CD-ROM on the application server for simultaneous NFS installation. Even an 8X CD-ROM can support more than one installation. You can make multiple copies of the boot and root disks (handy if you have an assistant) or you can perform all the installs yourself in "round robin" style: Move to the next machine at the completion of each step. A clipboard and check list can help prevent disaster!

Step 14. Unmount the CD-ROM on the server

Once you are done installing Linux on the X terminals, return to the application server and unmount the CD-ROM:

umount /mnt

And that's it!

In Part 6, I'll touch upon some of the differences between NFS installation of Slackware 3.5 and the more contemporary 7.x series as well as providing some pointers for installing other distributions via the network.

Until then, let's move on, for the benefit of the majority of readers who are already far more adept than I am at these basic tasks -- and who have a network of X terminals running -- running but, shall we say, with an embarrassing little problem?

How to make AbiWord run properly

AbiWord is one of the gems of the free software and open source movements. Yes, it may still be somewhat beta-quality code, but most of the 0.7.x releases are already quite useful for a variety of word processing tasks. Abiword ranks high among software applications that are useful to demonstrate the vitality of open source development to non believers. It is probably something you want to include in your Cheap and Easy network of X terminals.

If you are actually creating a network to make a demonstration to management, don't get in a big hurry. You want to make sure that when the boss clicks on that icon, he or she gets AbiWord -- and that you don't get a red face.

AbiWord is simple to install and configure on standalone machines, and our "mini-mainframe" -- a commodity PC that acts as the file/print/application server to our network of X terminals -- is no exception.

Unfortunately, the first time you log on from one of the "Cheap and Easy" X terminal workstations and attempt to open AbiWord, the familiar little brief case toting bipedal ant that now graces the AbiWord splash screen appears -- followed by an error message that may flash by too quickly to read -- and then AbiWord goes away. You are back to looking at your window manager desktop and wondering, "What just happened here?"

You try it again -- same result. Quit wasting time and get this system ready for management to look at! The problem is rooted in fonts. AbiWord insists on using its own.

There are a number of things you could do, including configuration of a font server, but why bother? This is Cheap and Easy server centrism and we want a Cheap and Easy fix that will work on virtually any distribution without a lot of configuration.

AbiWord gets installed in different locations depending upon several factors. These include the particular Linux distribution you have chosen to use on the application server, the AbiWord package you selected for installation (tar.gz, rpm, deb, etc.,) and choices permitted you, as root, during installation. AbiWord installs in a directory named AbiSuite.

Login at the application server and look for AbiSuite with the whereis utility:

whereis AbiSuite

It should report something like /opt/AbiSuite or /usr/local/AbiSuite. Change to that directory and run the ls utility. You will see a fonts directory under the AbiSuite directory.

Next, return to /etc, and with a text editor, open the /etc/exports file. Below the line you added in part 3 to export your CD-ROM, add a line to export the fonts directory -- adjust this to reflect the actual location of the fonts directory on your system -- in our example it might be:

/usr/local/AbiSuite/fonts (ro)

Save your changes to /etc/exports. The easiest way to cause Linux to read this file and make it available for export is a reboot.

Now, sit down at an X terminal, kill X with Ctrl + Alt + Backspace and login as root. Create an empty fonts directory on the X terminal's hard drive in precisely the same location that AbiWord's fonts are located on the application server. In this example, it will be in /usr/local, so:

cd /usr/local
mkdir AbiSuite
cd AbiSuite
mkdir fonts

Next, still seated at the X terminal machine, mount the fonts directory from the application server as an NFS partition on the mount point /mnt:

mount -t nfs 192.168.1.10:/usr/local/AbiSuite/fonts /mnt

Then:

cp /mnt/*.* /usr/local/AbiSuite/fonts/

As soon as the fonts are copied, unmount the NFS partition:

umount /mnt

And reboot the X terminal. When AbiWord is next opened, your users will get more than a mere glimpse of that ant on the splash screen. Administrators of large networks of X terminals, and any network of diskless machines, will probably prefer to run a font server somewhere on the network. But for demonstrations, home use, heterogeneous networks of different Unixes, and for that matter, most small production deployments of less than 15 or 20 workstations, this approach is a reasonable compromise between simplicity and repetitive labor.

An example of an exception to the rule about not creating user accounts on X terminals...

Consider security

The preceding example of a method to permit use of AbiWord on X terminals is also an example of how an ordinary user account (without a /home directory) on an X terminal can save time and steps for you, as the system administrator. Most Linux distributions deny root logins via telnet by default. During X terminal installation and configuration, creation of an ordinary user account and password with no /home directory with the useradd and passwd utilities, makes it easy for you to remotely log in to an X terminal, su to root, and perform tasks like creating the AbiWord fonts directory or configuring an X terminal to also act as a print server. (Even a 486 multi-tasks well when running Linux.)

It also has the potential to render your network more vulnerable to attack. Nevertheless, it may be something you can use without seriously compromising security. X terminal operation is best conducted behind a firewall anyway.

Using Linux doesn't absolve an administrator of the responsibility to consider security. A home network, perhaps shared by you, your spouse, and your children, and connected to the Internet via an IP masquerading router on an intermittent dial-up connection, is not at much risk from outside attack. If you are concerned about an inside job in this situation, you are more in need of family counseling than heightened security policies.

The opposite would apply to administrators of large networks where many people are involved. telnet, and the additional potential for exploit made possible by ordinary user accounts without /home directories, would represent an intolerable risk for a Fortune 500 company.

The only fully secure computer is one without an operating system, no network connection, disconnected from power, and locked away inside a bomb proof vault. The fully secure computer is also unavailable for use. You must decide this one for yourself.

In Part 6, we will examine some minor differences in network installation between Slackware 3.5 and later releases, as well as some of the other popular distributions. We will also take up the matter of performance. Many people assume that while an inexpensive network of X terminals and a commodity PC application server will work -- the load represented by multi-user operation will yield sluggish performance at best. I'll show you why this isn't particularly true, and how, in many cases, an inexpensive network of obsolete PCs can blow the doors off a network of new machines costing tens of thousands more.

More Stories By Colin Mattoon

When not buried under his real job in commercial two-way radio system design and sales, Colin Mattoon is a part-time Linux system administrator at Northwest Communications in Lewiston, ID.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.