Running a Perfect Internet Site with Linux 16-05141.doc
Notice: This material is excerpted from Running A Perfect Internet Site with Linux, ISBN: 0-7897-0514-1. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp .com.
You'll upgrade your site's software much more often than you'll upgrade its hardware. By software, I'm referring to everything from the kernel itself to your server programs, including new applications that you add for yourself or your users. Kernels change especially often with updates sometimes coming out every few days.
In this chapter, you learn how to:
With some software, an upgrade means completely replacing what you have, including getting a whole new version of the source. As discussed in chapter 1, "Why Create Your Own Site with Linux," the Linux kernel advances in small steps involving patches. Each time a fix or improvement is added, a patch is released. You then apply this patch to the source code.
All of the backup warnings apply heavily when you upgrade your kernel. Do backups before doing any major system changes!
You won't always want to apply patches to bring your kernel up to the version you want. This is especially true if you haven't patched it in a while and are a number of patches behind. Sometimes it's easier to grab a whole new version of the kernel source than to have to apply ten small patches in a row.
It's not necessary to apply patches immediately when they come out. In fact, it's not always wise to do so. Unless you absolutely need to upgrade in order to get a driver for a piece of hardware, you probably don't want to do so more often than every six months or so. This is simply because you will likely run into problems you need to diagnose and fix with most patches, and if you have paying customers you don't want to risk having to take your site down for a major kernel problem from a new patch.
Also, if you need three or more patches to be able to move to the new kernel version you want, you may as well download the whole kernel source for that version. Using a large number of patches can get messy.
When a new patch comes out, an announcement is posted to the newsgroup comp.os.linux.announce (and often most of the other Linux groups as well).
If you're not sure of exactly what kernel version number you're using, type uname -r at the prompt to display it.
Take note of what the patch announced is declared to fix, what drivers it adds and, in some cases, what it's known to break (shown in the changes directory listed below if you didn't see the announcement on a newsgroup). In fact, if you don't need any of the new items, it's good to wait and see if anyone complains that something you need is now broken. If so, you'll want to wait for a new patch to fix that item and then apply both of them, or wait awhile through a number of patches until a feature you want is offered.
All of the kernel and patch items are available via FTP at sunsite.unc.edu-or one of its mirror sites-in a subdirectory of /pub/Linux/kernel. The kernel directory contains (according to the INDEX file) the following:Table 16.x The Contents of /pub/Linux/kernel on Sunsite
Item Description COPYING The Linux kernel copyright notice INSTALL Installation instructions for the kernel changes/ List of what's changed with each kernel release changes-new/ Changes to recent kernels cipher.tar.gz Driver for cipher 9000 ATC-16 card w/ M995 9-track tape config/ Various configuration utilities images/ Floppy disk images for booting and installing Linux kdebug-1.1.tgz Package to allow simple kernel debugging kernel.txt.gz Some unofficial docs on kernel compiling kguide-0.2.tgz Help on compiling a new kernel linux-1.0.patch.alpha.gz Patch from ALPHA 1.0 to 1.0 linux-1.0.tar.gz Source tree for Linux 1.0 menu2.01.linux.tar.gz Menu based shell tool w/ user customizations modules-1.1.87.tar.gz@ Utilities for making/using kernel modules old/ Old versions of the kernel - history mostly patches/ Various kernel enhancements and fixes pcmcia/ Support for PCMCIA card & card services scend-0.5.tar.gz Full-screen editor for structured configuration data. sound/ Support for SoundBlaster, PRO-16, GUS, etc. tapes/ Various tape backup drivers v1.0/ Version 1.0 patches (obsolete) v1.1/ Version 1.1 developers track (obsolete) v1.2/ Version 1.2 and patches (stable) v1.3/ Latest development kernels (ALPHA)
If you want to start from scratch and grab a full version of kernel source, first you need to move your old source directory to another location. Your kernel source, if you have it on your system, is in the directory /usr/src/linux. As root, simply move this to another directory (e.g., /usr/src/linux-old).
You could also have no real /usr/src/linux directory, and instead put kernel source into directories related to the version (e.g., /usr/src/linux-1.2.13) and then make a soft link from the current version's directory to /usr/src/linux.
Now, set up your source for compilation. Log in as root and FTP to Sunsite or your favorite mirror site.
Change to the directory /pub/linux/kernel.
Then, change to the directory v1.2 unless Linux has reached version 1.4 at the time that you are following these instructions; then, change to v1.4.
If an experimental kernel has options you want to use, it's often safe to try it out. Ask around on the Linux newsgroups and see if the problems it has will effect you, and be sure to test it out for a while before trusting it completely. If you choose to use one, you'll be going to 1.3 or 1.5.
Currently, the latest kernel version is 1.2.13, so I'll download the file linux-1.2.13.tar.gz. This is about a 2.3M file, so depending on the speed of your connection, it might take a while.Then, move the file to /usr/src, gunzip and untar it.
If you're short on hard drive space, then go ahead and delete the old kernel when you're sure the new one is working fine.
If you want to add a patch or a few patches to the source you already have instead of downloading a whole new source version, follow these instructions. Log in as root, and FTP to Sunsite or your favorite mirror site.
Change to the directory /pub/linux/kernel, and then to the directory v1.2 (same version notation as in previous section). All of the files that start with patch are the patch files. You must apply all patches below the one you want in the end, as they make changes to your source code. For example, if you want to apply patch 1.2.5, you need to get patches 1.2.1 through 1.2.5. Then, just move the patch files to /usr/src.
If you downloaded patches, you need to apply them to the source code before you can compile it. To apply your patches, log in as root and change to /usr/src. You must apply the patches in order. To actually apply a patch, type zcat patchname.gz | patch -p0 (e.g., zcat patch-2.1.1.gz | patch -p0).
You must apply the patches in numerical order. Each one makes changes to the source code, and so the source must be in the full state it's expecting.
Apply the next patch in line. Continue applying patches until you've reached the last one you need. If the patch fails, double-check and make sure you have the patch for exactly the next kernel after the source you're using. You can even look through the patch file and see the changes that are being made, and make them by hand.
If you can't seem to solve the patch problem, you can always download the full version of the source for the kernel you want to compile.
Now, it's time to configure the kernel so it's compiled for your site's specific needs. Because the instructions here are for when this book was written, I recommend you read the README file in your new /usr/src/linux directory. In the "INSTALLING the kernel" section, you will find detailed instructions on how to proceed.
I'll walk you through the compiling of this kernel: version 1.2.13. First, I'll make sure that everything is properly in place, as follows:
Now, to configure the kernel to suit your needs, do the following as root:
When in doubt over whether you need a feature or not, it's generally safe to choose y for yes. Then at least, you won't have to recompile to add a needed feature. If you choose no for something, it's not included in the compiled kernel, and you'll have to go back and compile it all over again! The main difference is the more things you say yes to, the larger the kernel is.
The hardware discussed here is explained in more detail in chapter 2.
A module, or loadable module, is a piece of kernel code that isn't always needed. Instead, it's saved out into a piece of code that can be loaded into memory when it's necessary (e.g., FTAPE). This helps to keep down on how much RAM your system kernel eats up on a regular basis.
Now, you can create your kernel! This requires the following steps:
The speed it takes to compile a kernel depends on how fast your machine is and how much RAM it has. On a 386 machine, it can take over an hour, while on a Pentium or high end 486, it may take less than 30 minutes. You'll probably want to recompile your kernel when you have something else you can do while you wait.
Instead of completely replacing the old kernel at the moment, I'm going to add a reference for the new one. This way, I can reboot with the new kernel and test it to make sure it works. Then, if it works satisfactorily, I can come back and remove the old one.
The value assigned to root may be different if you didn't use /dev/hda1 initially. Just make sure the original root reference and the following one match.
Now, when you boot with LILO, you can type linux-new instead
of linux and boot with the new kernel. When you're confident
it's stable, erase the old kernel (the old zImage file) and move
zImage2 to zImage.
Upgrading Your Servers
When new versions of servers come out, it often means that they have-or are meant to have-fewer bugs than previous versions. This in itself is a good reason to upgrade. There might also be new features added that are useful to you, as in more functions being automated, or even more functions available. Also, if new standards have come out, a new server will be released to support those standards.
To actually upgrade a server, first download the new source code for the server. You should be able to find its home location in its own documentation files. If you can't, try looking on Sunsite first. Then, move it to /usr/src.
Next, take a look through the information files (e.g., README) that came with the source to see what you need to do before compilation. The differences between the previous version and the new version could be minor or massive, depending on how many bug fixes there are, how many new features were added, how standards have changed, and how the interface has changed.
Back up your old server in case you find you would rather return to it, or the new server simply doesn't work.
Follow the precompilation instructions carefully. After all, if there are any options that need to be configured before you compile the program, you don't want to forget about them until you're almost finished setting up! Then you'd have to turn around and start all over. Then, once you've set it up for compilation, compile the program according to the instructions in the README files.
As you've seen throughout this book, once you get the program compiled there is often more configuration to do. Follow the instructions in the information files on any post-compilation configuration necessary.
Test the new server and make sure it does what you expected and
wanted it to do. If you don't like the new server, erase it. If
you do like it, erase the old server. Though, you may want to
keep the old one around for a week or so in case it takes a while
for problems with the new server to show themselves.
Adding New Applications
Every once in awhile, you'll see a new application that you decide you want for your site, a particular machine, or even a particular user (could be an IRC client or server, a game, a WAIS server, graphics viewer for a graphics-capable machine where you don't have to use X-Windows, fax programs, or any other number of applications available on the Internet).
To find most of the applications, go to Sunsite in /pub/Linux and look through the directories there. You can also find the Linux Software Map on the Linux Documentation Project pages, which is a catalog of applications available for Linux and where to find them.
The difficulty or ease of installing this application depends on the application itself and how diligently you read the instructions before going at it.
The basic instructions for installing a new application are similar to the instructions listed in the previous section.
Download the application, and take a look through the information files (e.g., README) that came with it. It may have come as source, or as a binary. If it came as source, see what configuration you need to do before compilation, follow the instructions, and compile the program according to the instructions in the README files.
Follow the instructions in the information files on any further setup, whether you got the file as source or as a binary. Then, test the program to make sure it does what you want and does it the way you want it done.
