rev 0.7 date 2004-09-05
Contents: [ Prep | Apache | DNS | Settings | Appearance | Credits ]
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... )
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:
Or try this as root user:
find / -name DNS.pm
If you find it somewhere in the neighborhood of
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.
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.
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.
cd to (e.g.) /var/local and mkdir wp
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
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
# !/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.
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 firstname.lastname@example.org 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 email@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
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
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
restart apache (and named if you edited your zones)
Point your browser at this form:
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:
Now press Submit Query
Verify your entries are correct and submit
If all is well, move wp_config.cgi out of your cgi-bin!
In almost all cases, tweaks to the appearance should
be modified in
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.
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