Setting up WP Whois Proxy Service

rev 0.7 date 2004-09-05

Contents: [ Prep | Apache | DNS | Settings | Appearance | Credits ]

# Step 1 : decide where to untar wp

Note - for the purposes of this tutorial, we'll assume your normal web document root is /var/www/html and we will untar wp into /var/local/wp to keep it away from our normal web site. (But you could just dump it all into your regular cgi-bin if you wanted to... )

# Step 2: get Net::DNS Perl Lib

If you dont have the Net::DNS Perl Lib get it from http://www.net-dns.org/ or CPAN

Not sure? Try this on the commandline:
perldoc Net::DNS

Or try this as root user:
find / -name DNS.pm

If you find it somewhere in the neighborhood of
/usr/lib/perl5/site_perl/5.8.2/Net/DNS.pm
or where ever else your perl install is, it's highly likely that you already have it.

If you don't have it, pay a visit to http://www.net-dns.org/ and download the most recent version. Their install instructions are quite straightforward.

# Step 2.1: get HTML::Parser Perl Module (optional)

You may also want to install perl HTML::Parser Module from CPAN WP will run without it, but this would make it vulnerable to x-site scripting attacks (xss), should someone put malicious html into a whois registry entry.

# Step 2.2: get File::Cache Perl Module (optional)

Caching is also possible if you have File::Cache also available from CPAN.

The POSIX and CGI libraries are also used, but are part of the standard perl distribution.

Top

# Step 3: mkdir

cd to (e.g.) /var/local and mkdir wp

# Step 4: untar

I tend to keep downloaded source in /usr/src/redhat/SOURCES, which after cd'ing to that directory -
tar -zxvf wp-x.x.x.tar.gz

(Substitute x.x.x for whatever the current version is). It will uncompress as wp-x.x.x, now cd into that directory and
cp -R * /var/local/wp

# step 5 mkdir

mkdir /var/local/wp/Data
This will be used later for tracking hits.

Edit (very carefully) both wp.cgi and wp_config.cgi to make sure that the path to your perl interpreter is correct.
In most cases the first line should read
# !/usr/bin/perl -w
or
# !/usr/local/bin/perl -w
Note: do not use the -T (taintcheck) switch (or if you can figure out why it fails, let me know!)
Be *very* careful that your editor does not wrap any long lines!

Versions since 1.1.5 have a new BEGIN block. You can specify the location of wp.config inside that block, then specify a location for wp.error_log in wp.config (which can be modified with the web form at wp_config.cgi). Removing the reference to 'Carp' and 'carpout' will cause errors and debug warnings to be written to your Apache error_log instead of WP's own error log.

You will want to make the same tweaks to wp_config.cgi telling it where to find wp.config. Nothing else needs editing in these files.

Top

# Step 6: Apache Settings

Important:
First, make sure that the user Apache is running as has write permissions to the cgi-bin folder. If not, you won't be able to run wp_config.cgi. Perl-heads can skip wp_config.cgi and edit wp.config manually, but in either case, remove wp_config.cgi from the cgi-bin folder when you've finished configuring!

For the purposes of the following sections let's assume that your computer's hostname is host.example.com and you already have a website running there, but you want to get wp to run somewhere there as well, say wp.example.com. Additionally, lets assume that you only have one ip on the external interface and don't have the option to use another ip for an additional wp site.

The easiest way to do this is with some virtual server directives in your httpd.conf file.

Find Section 3 in your httpd.conf file and uncomment the 'NameVirtualHost *' directive

Next find the <VirtualHost *> section and uncomment the section

Edit it to look like the following:
<VirtualHost * > ServerAdmin you@host.example.com DocumentRoot /var/www/html # see note from step 1 ServerName host.example.com ErrorLog logs/error_log # or where ever your logs go CustomLog logs/access_log common # same disclaimer as above # note: combined can be sub'd for common </VirtualHost> <VirtualHost *> ServerAdmin you@host.example.com ScriptAlias /cgi-bin "/var/local/wp/cgi-bin/" DocumentRoot /var/local/wp ServerName wp.example.com ErrorLog logs/error_log # or where ever your logs go CustomLog logs/access_log common # same disclaimer as above </VirtualHost>

The above two sections basically tell the web server to accept connections and route them to the appropriate directory based upon the site name requested by the client.

If you don't have any web sites besides wp running on this server, simply omit the first set of VirtualHost directives and use only the second set (don't forget to uncomment NameVirtualHost *) You will now at least be prepared to put other web services on at a later time, and no harm's done in the mean time. Additionally, I believe that the VirtualHost configuration route to be easier than using Alias directives.

There are many ways to do the above, but this will work. I'll address a more secure way of implementing the ScriptAlias directive in a later version of this document.

For more information on virtual hosting see: apache virtual hosting reference at
http://httpd.apache.org/docs/vhosts/name-based.html

Top

# Step 7: DNS Settings

DNS settings depend on lots of things and there are many ways to do this, but ultimately you need the host to recognize distinct and separate names for it's normal website and the wp site. If you run bind and host your own zones, simply add a cname for wp.example.com. in the example.com zone. You should already have an A record or a CNAME record for host.example.com.

Don't host your own zones on your own bind server? Easy enough, just make sure both the following lines are in your /etc/hosts file
192.168.16.33 host.example.com 192.168.16.33 wp.example.com

Of course you should replace 192.168.16.33 with your own ip(s) as appropriate.

Also check to make sure your /etc/host.conf file reads
order hosts,bind

restart apache (and named if you edited your zones)

Top

# Step 8: Settings

Point your browser at this form:
http://wp.example.com/cgi-bin/wp_config.cgi

Once again, your apache-user must have write permissions or wp_config.cgi will fail! When you have finished, remove wp_config.cgi from the cgi-bin directory!!

Your site specific configuration is done there. The variables written to wp.config are described if you click the Help box. (do NOT edit wp.config directly -- well, unless you're a perl head ;)

If you have followed this set up then the values you will use are below as is a bit more detailed explanation of their use.

You will probably want the following boxes to be checked:

• ZapTrash (removes verbose disclaimers etc)
• UseHTML (auto-overridden if called from the commandline)
• ChkAccess (turn on access control)
• LogHits (keep a log - name specified above)
• FilterHTML (iff HTML::Parser)
• AlwaysAskAbuseNet (if you want automatic queries to Abuse.net)

Now press Submit Query
Verify your entries are correct and submit
If all is well, move wp_config.cgi out of your cgi-bin!

# Settings Explained

BaseURL =

this is NOT a full path (it's a URL)
for queries that require you to click on successive links
A simple dot works, or e.g. '/cgi-bin'
if that'swhat your cgi directory is called.

WPBase =

real path to cgi-bin directory

WPTmpl =

real path to wp directory (poorly named..)

WhoisTemplate =

path to the wp.tmpl "template"
(this needs to be cleaned up, WPTmpl is now only used for 'denied.html'
which should be move into the same dir as the rest.

StyleSheet =

URL path and name of your stylesheet

ErrorLog =

real path to your error log

EmailAddr =

duh

AccessDB =

path and file name of the file that keeps track of the hits per IP

HitLimit =

this is an hourly limit which resets itself automatically., Exclude =

you can leave this one blank
unless you want to exclude your own IP from the logging procedures

FilterTags =

space-delimited list of HTML tags to filter if FilterHTML is on

FilterElements =

space-delimited list of HTML elements to filter if FilterHTML is on.
It's safest to only use "script" and/or "style" here.

AlwaysAskAbuseNet =

If checked, all queries will attempt a request
for Abuse addresses from whois.abuse.net.
NB: This includes IP numbers that have reverse DNS and thus resolve to domain names.

LanguageFile =

select your default language, and locate the file

Cache =

use caching module 0 or 1

CacheRoot =

where the cachefiles are written

TrashDir =

where to cache disclaimers..
if defined, WP will cache a copy of the disclaimer and provide a link in the output
note: this is not configurable from wp_config.cgi

Step #9 - obsolete

# Step 10 Appearance

In almost all cases, tweaks to the appearance should be modified in
wp_style.css.

However, if you know some perl, you can make major changes to the way the output looks by editing wp.tmpl. This is a perl function, not a simple template. WP is written to deliver plain text on the commandline (skipping wp.tmpl entirely) and different kinds of HTML to different browsers: NS4 gets HTML 4.01 (really more like 2.0 and sans style-sheet), while modern browsers get XHTML 1.0 strict.

Note: If your WP looks very plain, you probably have the path to wp_style.css wrong. There are also a couple images for valid-html and valid-css, which are expected to be found in /images.

That's it!

Credits

Written by Josh Beckett - socal_luckdragon(at)yahoo(dot)com adapted from original documentation written by John Bro, and updated by Bro 05 Sep 2004