skyPipes Installation Manual

	skyPipes Manual Index
	Red Hat -- Linux, Embedded Linux and Open Source Solutions
	Fedora Project, sponsored by Red Hat
	GNU's Not Unix! - the GNU Project and the Free Software Foundation (FSF)
	netfilter firewalling, NAT, and packet mangling
	Julian Anastasov's Linux Kernel Patches
	LARTC Linux Advanced Routing and Traffic Control: A very useful reference site with a Routing HOWTO and mailing list
	Alexey Kuznetsov's `ip` Command Reference ip-cref
	The Apache HTTP Server Project
	The Comprehensive Perl Archive Network
	PHP Hypertext Preprocessor (documentation)
	PostgreSQL Relational Database Management System "The most advanced Open Source database system in the world" (documentation)
	Open Secure Shell
	The National Institute of Standards and Technology Internet Time Service
	WebMin a web-based interface for system administration for Unix

This is the process for configuring a new Red Hat 9/Fedora Core 1-4 host for installation of skyPipes Advanced Rules and Routes Configurator. No other distributions have been tested as of this date, but there are no known issues to prevent the Apache/PHP/PostgreSQL version of skyPipes from running in any Linux or other Unix-like environment. In order to be capable of this, there are a few required services and utilities:

An httpd service with Middleware: Apache mod_php
A Relational Database Service: PostgreSQL
Secure Sockets Layer: Apache mod_ssl and openssl for secure web communication
Secure Shell Service: openssh
Editing and Network Utilities: the GNU Project system of software tools
Linux development tools, including the kernel source

  To acquire these services and utilities, the following package categories should be selected during the Red Hat/Fedora Core install process, starting from a Server profile.
  Required package categories:
  Development Tools
  Kernel Development
  SQL Database Server
  System Tools (nmap in particular)
  Web Server

  Required packages:
  php-pgsql (under Web Server)

  Recommended package categories:
  DNS Name Server
  Editors (emacs and vi are available here)
  FTP Server (for use as SFTP)
  Text-based Internet

  And recommended packages:
  lynx (under Text-based Internet)

These services will require the following ports to be opened:

ssh: 22
https: 443

Install Red Hat 9 or Fedora Core 1, 2, 3, or 4
See the Fedora site for full freely downloadable distribution and documentation.

Partitioning recommendation:

name	recommended	format
/	15%	ext3
/boot	100MB	ext3
/swap	2xRAM	N/A (linux swap)
/tmp	2GB	ext3
/home	15%	ext3
/var	42%	ext3
/usr	28%	ext3

Configure one ethernet interface for each of your service providers' networks and one for the internal LAN/DMZ. Each of the external interfaces must be assigned an address which will be considered its primary address, unique to this host. Secondary addresses will be assigned later by the skypipes application, but they will be subject to Network Address and Port Translation. These primary addresses will not, and will be required for settings later in these instructions. The internal interface should be assigned the gateway IP address for the internal LAN/DMZ (usually .1 in that space).

The host name selected for this Advanced Router should have DNS records pointing at the routable address for each external interface on the Domain Name Servers serving your domain. Reverse lookup records should also be maintained on the appropriate servers.

In order for hosts in the internal LAN/DMZ to be able to make requests of one another without inconvenient latency, they should be able to resolve one another's host names to their internal numbers. To this end, it is recommended that an internal Domain Name Server (or two) be maintained with forward lookup zones for all domains represented internally, and a reverse lookup zone. This internal Domain Name Server should use each of your external Domain Name Servers for name service. Each host in the internal LAN/DMZ should in turn use the internal DNS only, so that internal requests will be resolved by it and external requests will be forwarded to the external DNS servers. See the DMZ Host Configuration Manual for further details on how to configure a host to work with the Advanced Router.

A note about iptables: Red Hat/Fedora Core automatically configures a few firewall rules by default. They are kept in a chain called RH-Lokkit-0-50-INPUT, and apply to all traffic going through the Advanced Router. All ports below 1024 are closed unless they were selected during installation of the system. If your network requires any of these ports to be open, such as 80 (HTTP), 22 (SSH), 25 (SMTP), 143 (IMAP), or 443 (HTTPS), they must be opened in this chain (unless this chain is replaced by other rules). This chain applies to all addresses, including the primary addresses that will serve the skyPipes application. For more information about iptables, there is extensive technical documentation available at netfilter and LARTC.
If you wish to apply port filtering to individual hosts in the DMZ, be sure to create an identical rule for each external IP address that is translated to match the internal IP address of the host. Be sure to complete installation of skyPipes and apply your configuration prior to adding any extra port filtering, so you can become familiar with the shell script arrc.sh, which lives in the application site directory. This script contains all the iptables commands which establish the translation rules. These are the rules that must be modified in order to perform port filtering for the internal hosts. Be sure to back up any filtering rules you create, as the arrc.sh file will be overwritten by the skyPipes application whenever the configuration is applied. Any custom port filtering will have to be pasted back in after each application.

Enable ssh for all users who will require remote access.

  SSH lives in the directory /etc/ssh.
  Open the file /etc/ssh/sshd_config for editing in your favorite editor.
  Go to the end of the file.
  After the last line, add a line that reads "AllowUsers" followed by a tab followed by a space-delimited list of usernames to allow.
  Restart the ssh service:
    # service sshd restart
  The service should reply OK.
  Test login.
    # ssh <username>@localhost

Some general information about the service:

/etc/httpd is the program directory
/etc/httpd/conf/httpd.conf is the configuration file
/var/www/html is the wwwroot or home directory for the server
# service httpd [start|restart|stop|status] can be used to control the service. # man service for details.

Set httpd to start on boot and start httpd.

To check the current setting:
# chkconfig httpd --list
To set the service to start on boot:
# chkconfig httpd --level 345 on

To check if the httpd service is running:
# service httpd status
If it replies that httpd is stopped, then the httpd service is not running. To start it:
# service httpd start
service should reply OK.

Edit the Apache configuration file to prevent insecure browsing and to make the skyPipes manual browsable.

Open /etc/httpd/conf/httpd.conf in your favorite editor
Find the line that says:
Listen 80
and comment it out by putting a # at the start of the line:
# Listen 80
Find the line that says:
Alias /manual "/var/www/manual"
and edit it to say:
Alias /apachemanual "/var/www/manual"
Save and exit

Make a new directory for the skyPipes application to serve from.
This directory should be named using the fully qualified domain name of the new site. For the examples in this HOWTO, the example domain name "pipes.example.tld" will be used. The suggested location for the new directory is alongside the default web root (in this case /var/www/html/). Using the example the new directory would be at /var/www/pipes.example.tld/.
# mkdir /var/www/pipes.example.tld

  SSL should automatically have been configured during OS installation. However, in order for the skyPipes application to take advantage of SSL, a Secure Certificate Signing Request and associated Key must be generated. There is a requirement that in order to become a Secure Certificate, the Request must be digitally signed in order to operate, to authorize it. This does not add any security, rather it acts as a guarantor to strangers that the Certificate really belongs to the organization it says it does. Certificate Authorities such as VeriSign charge money for the identity verification and authentication service, but for an internal application like this one, their services are not strictly necessary, as a certificate can be "self-signed" (if you are interested in using their services, feel free; their site should have full instructions on generating a certificate and key which can be substituted for the indicated part of this section below). Self-signing allows the generating organization to enable their own, equally secure Certificates, generally only used internally, or by other trusting organizations.
  Thanks to Fermilab for their helpful, easy-to-follow instructions, which also link to further, more in depth material on the subject of SSL, for those who are interested.
  The process:

Navigate to /etc/httpd/:
# cd /etc/httpd
Make a new directory called cert and navigate into it (this is where your certificate and key will be kept):
# mkdir cert
# cd cert
Create the Certificate Request:
# openssl req -new > pipes.cert.csr
The openssl command will now ask a few questions to identify the certificate. The crucial one is called Common Name. The value entered for Common Name must be the fully qualified host and domain name of the server. For this example, "pipes.example.tld" will be used. This name must perfectly match the name of the machine. The other key ones are the PEM pass phrase, which will be required in the following step of the process, and the Challenge Password, which should not be lost. Here is an example of its operation, with some example answers:
# openssl req -new > pipes.cert.csr Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key .........+++++ ....+++++ writing new private key to 'privkey.pem' Enter PEM pass phrase: pick something Verifying password - Enter PEM pass phrase: pick something ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Massachusetts Locality Name (eg, city) []:Boston Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example LLQ Organizational Unit Name (eg, section) []:IT Department Common Name (eg, YOUR name) []:pipes.example.tld Email Address []:dtd@example.tld Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
The output of the previous step should be pipes.cert.csr, the Request file, and privkey.pem, the PEM file that contains the Key. In this step, the pass phrase supplied above will be exported from the PEM file encrypted, so that the certificate can use it:
# openssl rsa -in privkey.pem -out pipes.cert.key
The openssl command will now prompt you for the pass phrase to authorize the export, then generate the file pipes.cert.key, the Key file.
Sign the Request. Either self-sign it or get it signed by a Certificate Authority.
To self-sign the Request:
# openssl x509 -in pipes.cert.csr -out pipes.cert.crt -req -signkey pipes.cert.key -days 365
The openssl command should reply something like:
Signature ok subject=/C=US/ST=Massachusetts/L=Boston/O=Example LLQ/OU=IT Department /CN=pipes.example.tld/Email=dtd@example.tld Getting Private key
This should generate the file pipes.cert.crt, the Certificate file.

To submit the Request to a Certificate Authority:
Either send the Request file to a Certificate Signing Authority as an email attachment or upload it through their web site.
Put the resulting PEM file into the /etc/httpd/cert/ directory as pipes.cert.crt
The Certificate and Key have now been generated

Apache SSL configuration is managed in a file called /etc/httpd/conf.d/ssl.conf. This config file works in concert with httpd.conf, and shares its style and syntax. Specifically, this file already has a Listen 443 line in it, so there is no need to put one into httpd.conf.

Edit /etc/httpd/conf.d/ssl.conf
Look for the section in the file with the heading "SSL Virtual Host Context". Beneath this heading should be a line that reads "<VirtualHost _default_:443>". Comment out the VirtualHost line by putting a # (the comment character) at the front of it. Directly after that line, enter a line that looks just like it, but repeat _default_:443, substituting the IP address of each interface (including the internal interface) in place of _default_. Using the example:
<VirtualHost 206.253.4.30:443 64.119.133.30:443 64.2.134.190:443 10.10.10.1:443>
In the subsection immediately follwing, called "General setup for the virtual host", comment out the lines that have the DocumentRoot, ServerName, and/or AddType directives and insert these lines (substituting your server name where appropriate):
  DocumentRoot "/var/www/pipes.example.tld/"
  ServerName pipes.example.tld
  AddType application/x-httpd-php .php .php4 .php3 .phtml .html .xml .xsd .rdf .rdfs
At the bottom of a subsection (two or three subsections down) called "Server Certificate:", comment out the line with the SSLCertificateFile directive and insert the line:
SSLCertificateFile /etc/httpd/cert/pipes.cert.crt
At the bottom of the subsection beneath that one called "Server Private Key:", comment out the line with the SSLCertificateKeyFile directive and insert the line:
SSLCertificateKeyFile /etc/httpd/cert/pipes.cert.key
Save and exit
Restart the server httpd:
# service httpd restart
The Application Site is now configured

Test PHP

  Change directory to the web root (in this case '/var/www/html/' by default)
  Create a file called test.php and put into it one line: '<?php phpinfo(); ?>'
  Direct a browser (like lynx) at http://localhost/test.php and check the output. It should display a series of tables describing the machine and its php installation (see the php.net docs page on phpInfo() for more info).

Make appropriate changes to the file /etc/php.ini

Here are the lines to look for that show their default values, each followed by the line that should replace it (the preferred method is to comment out the default line to preserve it, and put the new setting on the following line - the comment character is a semicolon ';'):

short_open_tag = On
short_open_tag = Off
memory_limit = 8M
memory_limit = 16M
magic_quotes_gpc = On
magic_quotes_gpc = Off
file_uploads = Off
file_uploads = On
[This may default to 'On' in other versions of PHP]
upload_max_filesize = 2M
upload_max_filesize = 2000M
SMTP = localhost
; SMTP = localhost
sendmail_from = me@localhost.com
; sendmail_from = me@localhost.com
; sendmail_path =
sendmail_path = <path to sendmail>
[in this case "/usr/sbin/sendmail -t -i"]

Set the postgresql service to start on boot

To check the current setting:
    # chkconfig postgresql --list
To set the service to start on boot:
    # chkconfig postgresql --level 345 on

Check whether postgresql is running:
    # service postgresql status
If the service command replies that postgresql is stopped, then:
    # service postgresql start
  service should reply OK

PostgreSQL helpful hints

  This subsection is just a few helpful pointers and links about how to handle you PostgreSQL installation. Actual instruction begins again in the next subsection (Enable proper logging for PostgreSQL).
  PostgreSQL configuration is in /var/lib/pgsql/data/postgresql.conf
  Host Based Access configuration file is in /var/lib/pgsql/data/pg_hba.conf
  To make a database (which will be owned by the operating system user who issues the command):
    bash-2.05b$ createdb <dbname>
  All user and db management can be done through the PostgreSQL interactive terminal (which accepts both SQL statements and PostgreSQL metacommands) called psql (man psql for reference):
    bash-2.05b$ psql <dbname>
  which takes you to a prompt which looks like:
    <dbname>=#
  To add/manage users:
  PGSQL User Management
  To create users:
    <dbname>=# CREATE USER <username>
  Every db must be VACUUMed at least once every billion transactions with the vacuum command in psql (or risk catastrophic data loss). See Routine Vacuuming.
  A few useful tools.
  To list all PostgreSQL users:
    <dbname>=> SELECT * FROM pg_user;
  To list all PostgreSQL databases:
    <dbname>=> SELECT * FROM pg_database;
  To find out the currently selected database, look at the name in the prompt:
    <dbname>=>

Enable proper logging for the postgresql service

Edit the file /etc/init.d/postgresql in your favorite editor
Find the line that reads (below the line that says, "#all systems go -- remove any state loca files"):
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl -D $PGDATA -p /usr/bin/postmaster -o '-p ${PGPORT}' start > /dev/null 2>&1" < /dev/null
Edit the line to read (changes marked in bold, note double greater than after 'start'):
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl -D $PGDATA -p /usr/bin/postmaster -o '-i -p ${PGPORT}' start >> /var/log/pgsql 2>&1" < /dev/null
Save and exit
Restart postgresql:
# service postgresql restart
service should reply OK

Configure PostgreSQL users and databases

Assign a password to the PostgreSQL administration user

First, the user called postgres, who is the superuser for the postgresql service, must have a new, secure password assigned both in the operating system and in the postgresql service. Next, a file called 'admins' must be created to indicate that the postgres user can connect to any database with a password challenge. Then, a user must be added to pgsql for the skyPipes application. Finally, the new database(s) for the skyPipes application must be created.

Create the PostgreSQL admin user and set its password both in the system and in PostgreSQL:

As the root user, change the password for user postgres in the operating system by using the command passwd:
# passwd postgres
This command will now challenge you for the new secure database admin password which should be carefully kept track of, with the usual precautions of length, and a mix of letters, numbers, and symbols. This password will be needed again in step 4.
Run a shell (a command line terminal) as the postgres user:
# su postgres
which takes you to a prompt which looks something like:
bash-2.05b$
Connect to template1 (PostgreSQL's template database) as user postgres by using the command psql, which opens the PostgreSQL interactive terminal. (Whenever in the psql terminal, be sure to expect confirmations of any action; a null response is a sure sign of no action performed.)
bash-2.05b$ psql template1
Change the password for user postgres in the PostgreSQL service by using the 'ALTER USER' command. Be sure to surround the password with single quotes/apostrophes as shown. The terminal should confirm by replying 'ALTER USER'. When using the following example, <newpassword> should be replaced with the new, secure password assigned in step 1. above. (Note that unlike the passwd command above, 'ALTER USER' will not automatically conceal the password as it is being typed. Be sure to enter it only in a secure environment.)
template1=# ALTER USER postgres WITH PASSWORD '<newpassword>';
Exit psql.
template1=# \q
Exit postgres user session.
bash-2.05b$ exit

Set permissions for the PostgreSQL admin users

Initially, PostgreSQL allows anyone from the local machine to connect to the databases without a password challenge, so as to allow the administrator to set the password for the postgres user. Once that has been done, access to the databases must be securely restricted. This is controlled from the file /var/lib/pgsql/data/pg_hba.conf.

Open /var/lib/pgsql/data/pg_hba.conf in your favorite editor and make the following edits:
1. Comment out the last line of the file (the default permission) by putting a # at the start of it.
2. Copy the following text and paste it in after the last line of the file:
      local sameuser all md5
      local template1 all md5
      local all admins md5
      host all all <ip address> 255.255.255.255 md5
3. Duplicate the last line of this inserted text until there is one for each external interface. Then, for each instance of the line, subtitute the primary ip address of an external interface for the portion of the line that reads <ip address>.
In the same directory /var/lib/pgsql/data/, create a file called 'admins'. Write into this file one word, the name of the database admin user, 'postgres' (excluding the single quotes/apostrophes in this case).
These configuration changes will only be applied the next time the service is restarted.
Restart the postgresql service.
# service postgresql restart

Create new users and databases

Run a shell (a command line terminal) as the user postgres to do some user management.
    # su postgres
Create a new database user. The name of this new user should correspond to the fully qualified domain name of the site that the database will be supporting, substituting underscores for the dots. For example, if your domain name is "pipes.example.tld", the corresponding user name should be "pipes_example_tld". This should also be the name of the database. Permissioning restricts users other than the admin user postgres to connect only to "template1" and the database with the same name as the user.
The command to make users (outside psql) as user postgres looks like:
    bash-2.05a$ createuser <options> <username>
The options that should be used are:
-d = allowed to create databases
-P = prompt for a password
-A = not allowed to create users
Using the example:
    bash-2.05a$ createuser -d -P -A pipes_example_tld
The password for the new user will now be prompted for. This should be another equally secure password, preferably different from the postgres user password. This password will be required by the skyPipes installation script later in order to initialize the database and enable the application.
The password will be challenged for a second time for confirmation.
Finally the postgres admin password will be asked for, to authorize the new user.
createuser should reply CREATE USER
The new user has now been created!
(man createuser for details, dropuser to delete users, and ALTER USER from inside psql to change settings for a user)
Exit the postgres shell to get back out to the root shell.
Connect to template1 as the new database user. You will be challanged for the new user's password. (Notice that the terminal prompt ends with a ">" rather than a "#", to show that you are not a superuser (postgres).)
# psql template1 <username>
Create the database for this user, named with the new user's username. Ownership of the new database is automatically assigned to its creator. The terminal should respond "CREATE DATABASE".
template1=# CREATE DATABASE <username>;
Using the example:
template1=# CREATE DATABASE pipes_example_tld;
Connect to the new database. This will confirm its existence. The terminal should respond "You are now connected to database <dbname>."
template1=> \c <dbname>;
The database for this skyPipes installation has now been created!
Exit the psql terminal to return to the root shell:
template1=> \q
PostgreSQL users and databases are now configured.

Download the skyPipes distribution archive file and extract it into the application site directory:

Navigate into the new application site directory made in the Apache Configuration section above (/var/www/pipes.example.tld/ from the example).
Download the installation archive file from downloads.skybuilders.com.
Decompress the installation archive into the the new directory (for this example skyPipes.tar.gz is the name of the downloaded archive file):
# tar -xvf skyPipes.tar.gz -z
All necessary application server pages, directories, and image files will now be in place.
Move all the files that don't need to be served over the web to the root directory. They are collected in the "skybuilders" subdirectory of the application root: # mv skybuilders /root
Permissions must be set on the application directory. Create a group called "skyapp", if it has not yet been created. This will be the group that gives anonymous and administrator access to the application site.
# /usr/sbin/groupadd skyapp
Add users to this group. The apache user (in this case "apache") must be added so that requests to the web server will have permission to operate on the site. Other users that may need to be added to this group are any non-root administrators of the machine or the site, or any users who require ftp or sftp access (though any users who require different permissioning from the web users should be permissioned separately).
# /usr/sbin/usermod -G skyapp apache
# /usr/sbin/usermod -G skyapp <username>
Change the group setting for the site directory (recursively, for all the files and directories below it).
# cd /var/www
# chown -R :skyapp pipes.example.tld
Set permissions for the site directory (recursively, for all the files and directories below it).
# chmod -R 770 pipes.example.tld
Restart the web server httpd.
# service httpd restart

Set skyPipes Advanced Router to start on boot:

Open the file /etc/rc.local for editing. Add the following lines to the end of the file (replacing pipes.example.tld with the new domain name):
    # skyPipes Advanced Router
    echo "Starting skyPipes Advanced Router"
    /var/www/pipes.example.tld/arrc.sh
Save and Exit

The version of iproute2 that is distributed with Red Hat (the same one as found in the RPM they offer) has a bug which is fixed in a later version (Fedora Core versions may or may not have the fixed version; check the version number). The later, fixed version can be found at ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz while any later versions in the future can be found in the same directory. The fixed version has also been included in the skyPipes distribution's skybuilders directory (which was moved to the /root directory in the previous step). No RPM of the fixed version is available; it must be compiled. To upgrade:

Change directory to the /usr/src directory, the traditional location for compiling:
# cd /usr/src
Create a symbolic link to the linux-x.x.xx-xx (for example, linux-2.4.20-8) directory called linux (the compile config expects this naming):
# ln -s linux-2.4.20-8 linux
Either download the archive file containing the source of the new version of iproute2 (wget recommended):
# wget ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz
Or use the version in the skybuilders directory:
# mv /root/skybuilders/iproute2-2.4.7-now-ss020116-try.tar.gz ./
Un-tar and -zip the file:
# tar -xvf iproute2-2.4.7-now-ss020116-try.tar.gz -z
Change directory to the new iproute2 directory:
# cd iproute2
Compile the utilities using make (this will have a lot of output; let it finish):
# make
Copy the newly compiled utilities to their new homes, replacing older versions where necessary (the commands may ask for confirmation):
    # cp ./etc/iproute2/* /etc/iproute2
    cp: overwrite `/etc/iproute2/rt_dsfield'? y
    cp: overwrite `/etc/iproute2/rt_protos'? y
    cp: overwrite `/etc/iproute2/rt_realms'? y
    cp: overwrite `/etc/iproute2/rt_scopes'? y
    cp: overwrite `/etc/iproute2/rt_tables'? y
    # cd ip
    # cp ifcfg ip routef routel rtacct rtmon rtpr /sbin
    cp: overwrite `/sbin/ifcfg'? y
    cp: overwrite `/sbin/ip'? y
    cp: cannot stat `rtacct': No such file or directory
    cp: overwrite `/sbin/rtmon'? y
    # cd ../tc
    # cp tc /sbin
    cp: overwrite `/sbin/tc'? y

Schedule skyPulse and NIST system clock synchronization using crontab (please man crontab for more information):

Change directory to the skybuilders directory:
# cd /root/skybuilders
Open the file skyPulse in your favorite editor. Find the line that reads:
$sSiteRootFSPath = '/var/www/skypipesa.skybuilders.com/';
and replace "skypipesa.skybuilders.com" with the domain name of your new skyPipes site.
Schedule an every-minute pulse for the pipes application and a daily clock synchronization using crontab:
# crontab skyPipes.cron
To see current schedule settings
# crontab -l

Apply a kernel that has been patched with Julian Anastasov's Static Alternative Routes and Dead Gateway Detection Patch.
A patched kernel and associated files for Red Hat 9/Fedora Core 1 (kernel v. 2.4.20) are included in the skyPipes distribution, in the /root/skybuilders/kernel/ directory. The routes patch is also included in the distribution, located in the /root/skybuilders/patches/ directory (appropriate patches for Linux 2.2 and 2.6 (for Fedora Core 2-4) are also available in version-named subdirectories), and its name looks like routes-x.x.xx-x.diff (where the "x"es represent version numbers). The official site for the routes patch is Julian Anastasov's Linux Kernel Patches. New versions, deeper help, and news can be found there. If you are not running Red Hat 9/Fedora Core 1, or otherwise need to patch and compile your own kernel, see our Patch Manual (the instructions there may be considered a replacement for this section, that is, do one or the other, not both). Using the supplied patched kernel and associated files:

Change directory to /root/skybuilders/kernel/, the directory that contains the files:
# cd /root/skybuilders/kernel/
Copy the bzImage-*, config-*, and initrd-* files into the /boot/ directory:
    # cp bzImage.skypipes.20031030 /boot/
    # cp config-2.4.20-8-20031030 /boot/
    # cp initrd-2.4.20-8skypipes.20031030.img /boot/
Back up the original grub configuration file:
# cp /boot/grub/grub.conf /boot/grub/grub.conf.orig
Replace the original grub configuration file with the one that points at the patched kernel (a confirmation to overwrite may be required):
# cp grub.conf /boot/grub/
Change directory to the operating system's modules directory:
# cd /lib/modules
Extract the contents of skyPipesModules20031030.tar.gz or current equivalent. This will have many lines of output, but should be quick:
# tar -xvf /root/skybuilders/kernel/skyPipesModules20031030.tar.gz -z
Reboot the machine:
# shutdown -r now

The new kernel will now be the default selection on boot. However, the original, non-patched kernel is still available. If there should be an error that causes the boot sequence to fail, reboot and choose the second entry, which will be your original kernel. Once booted to your original kernel, simply overwrite grub.conf with the original version of the file to restore the machine to booting from the original kernel. From there, reanalyze any error messages in the compilation output.

  Run the skyPipes installation script
  Please note that all operations of the skyPipes application are considered secure, and will only respond to requests using the https: protocol, rather than http:.
  This script will build the new database's schema and populate it with initial data. Open a skyPipes-compatible browser (Mozilla > 1.1, Netscape > 4.0, Internet Explorer > 4) and navigate to the following URL (where <domain name> is the domain name of your new site):
    https://<domain name>/install.html
  The skyPipes application will now challenge for the database password for the new site (as set in the PostgreSQL subsection "Configure PostgreSQL users and databases"). Initialization should take around two minutes.

skyBuilders skyPipes installation should now be complete!
Please report any bugs at our interactive Bug Report. Thank you.