Troubleshooters.Com and T.C Linux Library Present

Pre and Post Installation Procedures

Copyright (C) 1999 by Steve Litt, All rights reserved. Material provided as-is, use at your own risk. 


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.


Back up everything you'll need to make things easier on the new machine. At a minimum this includes: 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 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

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:
#DocumentRoot /www/docs/
#ErrorLog logs/
#TransferLog logs/

Add the following text below it (using troubleshooters.cxm at as an example)
DocumentRoot /web/sites/troubleshooters.cxm
ServerName www.troubleshooters.cxm
ErrorLog logs/troubleshooters.cxm-error_log
TransferLog logs/troubleshooters.cxm-access_log
Note use IP addr so reverse DNS is unnecessary
Root directory of the site
Error log
Transfer log

Reset and Test


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

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:
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
but never just

Troubleshooting CGI

It's just like troubleshooting CGI on your ISP --
  1. first you do it from the command line using the PERL command
  2. then you do it from the command line without the PERL command
  3. then run it from the command line and pipe it into junk.html, which you can then observe in a browser
  4. and finally you do it from html.
Also remember these common causes of problems: 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:
  1. back up /etc/httpd/conf/httpd.conf
  2. edit /etc/httpd/conf/httpd.conf
  3. Find these two lines:
  4. For each of those lines, change nobody to your username. For me, that's
  5. Restart httpd with the command: kill -HUP `cat /var/run/`
  6. On your browser, clear cache, both memory and disk. Then do it again.
  7. On your browser, reload the page which calls the CGI
  8. On your browser, click the link or button calling the CGI. Note whether it now works.
  9. If it now works, exploit the differences between user/group nobody and your own. Look at some of the following:
  10. 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 (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...]


Back to Troubleshooters.Com * Back to Linux Library