Troubleshooters.Com and T.C Linux Library Present

Pre and Post Installation Procedures

Introduction

With modern installation programs, a clean Linux install is pretty easy. The tough part is making it into the server or workstation you want it to be. The purpose of this document is to make that easier. This document is based on the Red Hat 5.2 Linux distribution.

Pre-Installation

Back up everything you'll need to make things easier on the new machine. At a minimum this includes:

The /etc tree, to have a copy of your original configuration. Recommend use Linux's included zip program.
/var/named (or wherever you keep your DNS). Recommend use Linux's included zip program.
Any Linux additions or upgrades in .gz or .rpm or whatever format (newer Samba, dnswalk, dbi:dbd, etc.)
Anything you don't have on distribution media

Note: The purpose of these backups is not to restore over the newer version. That would be irresponsible and would cause ghosts of operating systems past. The purpose is to have a comparison copy to cut and paste from. Only rarely is replacement appropriate.

Make a note of your mount points like this:

mount > mounts.txt

mounts.txt becomes another one of your backup files. If you wish to make a record of the partition table, you can do it by running this command:

/sbin/fdisk > parts.txt

Then press the p key to print the partition table, then type quit to quit fdisk. parts.txt becomes another of your backup files.

CAUTION! Any use of fdisk involves risk of data, OS and program loss. Do not do this unless you're thoroughly backed up. **DO NOT** press the w key -- that will rewrite the partition table and most likely trash your OS.

Make Partition Bootable if Necessary

An intermittent bug in the RH5.2 install leaves the new installation without a bootable partition. I observed this on a new Celeron 333/chaintech motherboard/64meg sdram/ibm 14.4gig 7200rpm IDE drive. The solution is simply to use fdisk to make the boot partition bootable. Get into fdisk either by booting the bootable floppy you made during install, or boot the installation floppy or cd, pick expert mode, and navigate to fdisk. Note which partition should be bootable with the p command, then use the a command to make the partition bootable, then use the p command again to verify it worked. Use the w command to write the info back to the partition table. If you forget the fdisk commands, use the m command to list them. The machine should now boot through LILO without need of a floppy.

Note: Any write to the partition table carries the possibility of lost data. The intent of the above advice is ONLY to make a new install bootable, and should not be used on a system already containing valuable data.

Test Medium Level Networking

Before we can even worry about network communication, we must make sure the machines can see each other. We use ping to determine that.

Make sure your new machine can ping the address of its eth0. If not, troubleshoot.

Then make sure it can be ping'ed from other machines in its subnet. If not, look at hubs, cabling, and make sure the other machine is really on the new machine's subnet. Do not continue until you can ping this machine's eth0 ip address from other machines on its subnet. Note that if the ethernet ip address is defined by DHCP, a simple ifconfig eth0 command will tell you what that address is.

Create an Ordinary User

You can't access uid root remotely. So create a new user (let's call it myuid) with these two commands:

adduser myuid
passwd myuid

Note that the passwd command will ask you for the password, then ask you for the password again.

Enable FTP

Without FTP, there's no good way to get files to and from the new server. Hence FTP must be enabled right away. Fortunately it's usually easy.

If machines that ping your new machine cannot FTP to it (ftp xxx.xxx.xxx.xxx does not produce a user: prompt), it's most likely timing out due to bad reverse dns. The usual cure is to rename /etc/resolv.conf. The machine can run on many levels without a resolv.conf, but having a resolv.conf with an incomplete DNS setup will time out on many processes, often including ftp, sendmail, amd, and telnet.

If it still doesn't host ftp after renaming resolv.conf, use Linuxconf (Config:Networking:Client tasks:Host name search path) to set the the host name search path to hosts only.

If it still doesn't work, troubleshoot and report the answer to Steve Litt's email address.

FTP Backup Files

As a first step to restoring websites, configuration, data, etc, the backups must be copied to the new machine.

In ftp, log in as your normal user (myuid in this example), create a directory called zips off myuid's home directory, and put all your backups (binary mode) to that directory.

Unzip your backup files

Most configuration involves copying selected text from older config files and pasting it into the newer ones. Therefore, the backups are unzipped into alternate trees, rather than over the ones created by your recent install.

Make sure the decompression/restore process does NOT overwrite your new installation files in the case of OS files. In the case of data, of course, you'll want to restore to the original location.

Restore your websites

If you're anything like me, most of your documentation is html. You want to access it locally on your new machine. The first step in this access is to restore it to the proper directories. For instance, /web/sites/troubleshooters.cxm.

Take care to make file modes (read, write, execute -- user, group, everyone) correct.

Enable virtual hosting (minus domain names and CGI)

Before those websites can be seen via the http engine, IPs for the site must be created via linuxconf, those ip's must be mapped to directories via /etc/httpd/conf/httpd.conf. In addition, proper recognition of cgi and .htm must be maintained. Since the website IP's are often not in the new machine's subnet, proper firewall ip forwarding must be established, although usually the default will suffice as a start (later you'll want to close some security holes).

Enable low level Networking to Website IPs

Use Linuxconf (Config:Networking:Server tasks:IP aliases for virtual hosts) to assign the proper IP numbers as aliases to the lo network interface. Note that these numbers *DO NOT* need to be in your machine's subnet. Verify that you can ping those numbers from the new machine. Reboot as necessary.
Enable ping of those addreesses from other machines on the new machine's subnet (but not necessarily on the websites' subnet). Make sure the new machine's default gateway is the IP address but with 254 as the last byte. Make sure the other machines have default gateways such that they can reach the ethernet interface ip of the new machine (for instance, the new machine's ethernet interface ip if the new machine is the subnet server). Reboot the other machines, or reset networking, as appropriate.
Test by pinging the ip's of the websites (which are in a different subnet than the machine itself).
If there are still problems, investigate firewall/forwarding with these commands:

root@linuxhost sysconfig]# /sbin/ipfwadm -F -l

[root@linuxhost sysconfig]# /sbin/ipfwadm -A -l

[root@linuxhost sysconfig]# /sbin/ipfwadm -M -l

NOTE: If default forwarding policy is accept, you must tighten up security later!

Test again with ping. Troubleshoot as necessary.

Enable Proper .htm handling:

In /etc/mime.types

Change this line:

text/html                       html

to this:

text/html                       html cgi

Direct Website IP's to the Proper Directories via httpd.conf

Edit /etc/httpd/conf/httpd.conf

At or toward the bottom you'll see this text:

#<VirtualHost host.some_domain.com> #ServerAdmin webmaster@host.some_domain.com #DocumentRoot /www/docs/host.some_domain.com #ServerName host.some_domain.com #ErrorLog logs/host.some_domain.com-error_log #TransferLog logs/host.some_domain.com-access_log #</VirtualHost>

Add the following text below it (using troubleshooters.cxm at 192.168.200.113 as an example)

<VirtualHost 192.168.200.113> DocumentRoot /web/sites/troubleshooters.cxm ServerName www.troubleshooters.cxm ErrorLog logs/troubleshooters.cxm-error_log TransferLog logs/troubleshooters.cxm-access_log </VirtualHost>

Note use IP addr so reverse DNS is unnecessary Root directory of the site URL Error log Transfer log

Reset and Test

Reset

Get into the /etc/rc.d/init.d directory
./httpd stop
./httpd start
./network stop
./network start

Enable CGI .htm handling:

In /etc/httpd/conf/access.conf

Comment out this line if it exists:

Options Indexes IncludesNOEXEC

If you want to enable CGI in the entirety of a tree (/web/sites in this example), enable CGI for that tree with these three lines at the bottom of the file:

<Directory /web/sites>
Options ExecCGI
</Directory>

In /etc/httpd/conf/srm.conf

Make sure these lines are not commented out or missing:

ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/
AddHandler cgi-script .cgi

File Permissions for CGI

All cgi files should be configured as follows:

chmod a+x myfile.cgi

All directories containing cgi must be configured as follows:

chmod a+x mydirectory

chmod a+r mydirectory

All files written to by cgi scripts must be configured as follows:

chmod a+w myfile.whatever

All directories containing files written to by cgi scripts must be configured as follows:

chmod a+w mydirectory

If that last command sounds like too great a security risk, you can often write to a file in a read-only directory IF the writable file already exists. My experience has
been the directory need be writable only if you need to create files. Note, however, that if the file is deleted for any reason, your CGI that writes it will crash.

Perl Path for CGI

Every CGI script has a special comment on the first line. This special comment isn't a comment at all, but instead points to the Perl executable so the interpreter will run. On every cgi script, this must be correct. Here's an example:

#!/usr/local/bin/perl

Note that the #! simply tell the system that this is the path to the interpreter. Be sure you do this before finishing your configuration. If you get a message saying

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

then you might want to check this out. Note that another alternative is to copy Perl into the directory already expected by your CGI scripts. This is the way you'd do it if you are creating a test jig server to simulate your ISP.

Other CGI Issues

Your html files must call the cgi with a directory specification, as in

./myfile.cgi

cgi-bin/myfile.cgi

but never just

myfile.cgi

Troubleshooting CGI

It's just like troubleshooting CGI on your ISP --

first you do it from the command line using the PERL command
then you do it from the command line without the PERL command
then run it from the command line and pipe it into junk.html, which you can then observe in a browser
and finally you do it from html.

Also remember these common causes of problems:

Make sure all directories containing html or cgi are executable to all.
Make sure all .cgi's are executable to all.
Make sure all files written to by .cgi's are write-enabled to all.
Make sure that any directory in which a .cgi creates a file is writeable by all (this is one reason why so many ISP's won't let you put your .cgi just anywhere).

In every case, you exploit the differences (and the main difference between calls from html and the command line is the userid doing the call, with file permission and pathing considerations). A valuable test is to have httpd run under your username. Here's what you do:

back up /etc/httpd/conf/httpd.conf
edit /etc/httpd/conf/httpd.conf
Find these two lines:

User nobody
Group nobody

For each of those lines, change nobody to your username. For me, that's

User myuid
Group myuid

Restart httpd with the command: kill -HUP `cat /var/run/httpd.pid`
On your browser, clear cache, both memory and disk. Then do it again.
On your browser, reload the page which calls the CGI
On your browser, click the link or button calling the CGI. Note whether it now works.
If it now works, exploit the differences between user/group nobody and your own. Look at some of the following:

File permissions. Who is it executable by? user, group, other, combination of these?. Note that when httpd is run as nobody, any cgi owned by the user should be executable by user, group AND other.
Permissions of the directory

Either way, BE SURE to put User and Group back to nobody after troubleshooting, to avoid a horrible security breach and horrible future troubleshooting problems.

Apache documentation is available on your Linux machine and available from a link at http://192.168.100.3 (assuming you're using the conventions in this magazine). Perl info is available in your installed Perl's documentation, as well as Perl information sites such as Litt's PERL's of Wisdom.

Redirect Website IP's to Directories

[To Be Continued...]