Most Web developers are on the constant lookout for the most powerful and flexible applications they can find to assist them in developing their Web sites. A lot of developers have grown fond of using tools like Perl and PHP to help build their sites, but they are then stuck using traditional HTML design tools to create their site. Perl and PHP offer no ways of actually creating the site.

One very popular site-creation and management tool is Zope (Z object publishing environment). Zope is a set of programs and modules written in Python that help you create and manage dynamic Web applications via the Web itself. Have I caught your interest yet?

Zope allows you, and any other users you designate and give access, to log into it through your Web browser and modify and create Web content. It does this through a series of forms and modules that interact with databases and other legacy data. Also, Zope supports many open Web standards such as XML_RPC, DOM, and Web DAV.

Zope accomplishes all of this quite nicely by providing an Internet server (both Web and FTP), a transactional object database, a search engine, and a Web page template system. Zope itself is a powerful Web-development and Web-management program that can be easily extended. This means that you can easily download third-party modules written for Zope (and there are many!) that will extend the functionality of your Web site.

While a transition from an existing Web site to a Zope-managed Web site may be a difficult task, Zope is perfect for people who are thinking of creating a new Web site or redoing their existing Web site.

In this Daily Drill Down I’ll show you how to install and configure Zope, and then I’ll explain how to use it to maximize your new Zope-driven Web site.

Installing Zope
Installing Zope is pretty simple, and there are two routes you can take. A few vendors have created RPMs for Zope that you can download and install. Normally, I recommend RPM-based installations as being the easiest and most hassle-free, but with Zope it doesn’t seem that way. I had more difficulties attempting to get Zope to run from an RPM-based install than by building it manually.

For this illustration, I’ll build Zope manually and I’ll also assume that you will be running it with Apache. There are two ways that you can run Zope: stand-alone or with another Web server. You can even run the two together. The Zope server (aptly called Zserver) usually listens to port 8080, so you can use it in conjunction with another Web server. It even provides an FTP interface on port 8021. But we’re getting ahead of ourselves here.

First, download the Zope source package. The current version at the time of this writing is version 2.2.2. You can download the source code from the Zope Web site. Download the file called Zope_2.2.2_src.tgz and save it to a local directory.

You now have to make a decision. You can run Zope as root, as a normal user, or as a special user (like nobody). I’d recommend running Zope as the same user your Web server is running as. If your Web server is Apache, it may run as the user nobody or as the user apache. An easy way to determine this is to execute
ps aux|grep httpd

and look for the name at the beginning of each line. It should say either nobody or apache. Of course, you must have Apache running for this to be at all effective. On our machine, Apache runs as the user apache.

You must also select a home directory for Zope to live in. I chose /home/Zope because it makes more sense to me than /usr/local/Zope or any other directory structure. Some may argue that it belongs in /var/Zope, but the choice is entirely up to you. For this example, I’ll install Zope into /home/Zope and assume that you saved the source file into /tmp when you downloaded it. Follow these commands:
cd /home
tar xvzf /tmp/Zope_2.2.2_src.tgz
mv Zope_2.2.2_src Zope

Zope is now located in the /home/Zope directory. Enter that directory and prepare yourself for another critical decision: You must decide whether to run Zope stand-alone—which uses Zserver, or use PCGI (Persistent CGI)—which is a wrapper between your Web server and Zope. Since you have a Web server, select the PCGI method and run the following commands to build Zope and its components:
cd /home/Zope
python w_pcgi.py

If you wanted to have Zserver running without PCGI support, you could use these commands:
cd /home/Zope
python wo_pcgi.py

The names clue you in a little bit. The first compiles Zope with PCGI support, which means that it will work with any Web server front end. Zope can also run stand-alone in this mode! Your best bet, if you aren’t sure which way to go, is to select PCGI support and use the first command. The second builds Zope without PCGI support, which means that if you want it later, you’ll have to build Zope again.

Depending on your computer, you may have a little or a long time to wait while Zope builds. Once it’s done, pay very close attention to your screen. Near the end of the screen, you’ll see a message from the script that indicates the default user information. It will be the user superuser with a randomly generated password. You must write this down as the password is stored encrypted, and if you forget it, you’ll have to use the zpasswd.py program—also in the directory where you built Zope—to assign a new username/password for the superuser. This superuser is like root on your Linux system. It can do anything, so you want to protect the password and make sure that the /home/Zope/access file, which stores the encrypted password, is given 600 permissions (read/write by the user running Zope only).

The runzope: A custom Zope wrapper script
The build process also created two more files in your /home/Zope directory, namely start and stop. The start file is a bash script to start the Zserver, and the stop file is a script to stop it. By default, the start script turns on debug logging, so if you want to disable this, you’ll need to remove the -D command. For instance, the script is written as
#!/bin/sh
reldir=`dirname $0`
PYTHONHOME=`cd $reldir; pwd`
export PYTHONHOME
exec /usr/bin/python \
     $PYTHONHOME/z2.py \
     -D “$@”

Change the last line to simply
     “$@”

if you do not want debug logging. I would also advise you write a wrapper to the start script. Zserver offers a number of options and it needs to be running, regardless of whether you choose to use Zserver to serve your Web pages or you choose to use Apache to do so. The PCGI program, which is called /home/Zope/Zope.cgi, talks to the Zserver via a UNIX domain socket and will return an error if you’re not running Zserver. This does not mean that you must run Zserver to serve your Web pages, however.

You can get all of the options for Zserver by taking a look at the /home/Zope/z2.py script. It will provide you with all of the options, but here are some scenarios that may be of interest. Make a wrapper script called /home/Zope/runzope and place inside it the following:
#!/bin/sh
/home/Zope/start -d 192.168.5.25 -u apache

What this will do is run the start script with a few parameters. The -d switch tells Zope what IP address to use for DNS queries, so this must be a valid DNS server IP address. The -u switch tells Zope to run as the user apache. This is important!

Another possible scenario might be
#!/bin/sh
/home/Zope/start -u apache -X -f 1221

This tells Zope to run as the user apache and to turn off all servers. Because Zserver provides a Web server, an FTP server, and a secure monitor server, you may not wish to have all of these open and running. For instance, if you’re using Apache, you may not want the Web server to run. To disable all servers, use the -X switch. You can then enable any server you want afterwards. The -f 1221 switch tells Zserver to run the FTP server and listen to port 1221. The standard ports that Zserver listens to are 8080 for Web, 8021 for FTP, and 8099 for the secure monitor server.

You can also start Zope like this
#!/bin/sh
/home/Zope/start -u apache -X

to run the PCGI server by itself. This turns off all servers except the PCGI server, which listens to the UNIX socket /home/Zope/var/pcgi.soc.

The next step is to make sure that all the files in your /home/Zope directory are owned by the user you have chosen to run Zope. In your case, it is the user apache, so do the following:
cd /home
chown -R apache.apache Zope

Now, all of the files in the /home/Zope directory are owned by the user and group apache.

The last step in a PCGI setup is to make the /home/Zope/Zope.cgi script available via your Web site. Let’s assume that your Web site is stored in /home/httpd/html and the cgi-bin directory is /home/httpd/cgi-bin. Perform the following:
cd /home/httpd/cgi_-ln _s /home/Zope/Zope.cgi Zope

You have now created a symlink to the Zope.cgi file in your cgi-bin directory. This way, if a user (or you) goes to http://www.mydomain.com/cgi-bin/Zope, they will enter the Zope system.

Configure Apache to work with Zope
By default, Apache doesn’t allow symlinks in the cgi-bin directory. To change this, you’ll need to edit your httpd.conf file, which can be found in the /etc/httpd/conf directory on Red Hat and Linux-Mandrake systems. Edit your /etc/httpd/conf/httpd.conf file and look for the following section:
<Directory /home/httpd/cgi-bin>
AllowOverride None
Options ExecCGI
</Directory>

You will want to change the Options line to this:
Options ExecCGI FollowSymLinks

This will tell Apache to observe symbolic links in your cgi-bin directory. For the security conscious, you may choose to go another route. Instead of making your symlink to Zope.cgi in your /home/httpd/cgi-bin directory, you may choose to place it in its own directory, such as /home/httpd/zope. If you do this, you’ll need to add a few things to your httpd.conf file. First of all, if you do decide to go this route, do not change your cgi-bin Directory setting as mentioned previously. Instead, add the following to your httpd.conf file:
ScriptAlias /zope/ /home/httpd/zope/

<Directory /home/httpd/zope>
AllowOverride None
Options ExecCGI FollowSymLinks
</Directory>

By doing this, you will have to connect to http://www.mydomain.com/ to access Zope. The benefit to this is that your regular cgi-bin directory is not tampered with, as many people feel (and I agree) that to allow symlinks in your cgi-bin directory is not safe at all. By placing Zope in a nonstandard secondary cgi-bin directory, you reduce the chances of anyone tampering with your system. If you’re going to use Zope on an intranet or for local testing and want to further secure it, you can use the following Directory clause instead:
<Directory /home/httpd/zope>
order deny,allow
deny from all
allow from localhost
allow from .mydomain.com
AllowOverride None
Options ExecCGI FollowSymLinks
</Directory>

This will protect your /zope/ directory from unauthorized people by allowing access only to localhost and to computers in the domain mydomain.com.

The next step is to perform some rewrite rules with Apache. This means you must have mod_rewrite installed on your system. You can easily find this out by checking if mod_rewrite.so exists on your system (with Linux-Mandrake, it is in the /usr/lib/apache directory). You can also check by looking in your /etc/httpd/conf/httpd.conf file and looking for the following:
LoadModule rewrite_module modules/mod_rewrite.so

If that statement exists, you most likely have mod_rewrite.so installed on your system. Make sure that line is not commented out.

We’ve illustrated a few ways to add PCGI access to your httpd.conf file, but let’s take a look at a full top-to-bottom configuration with the rewrite rules we need to use. At the end of your httpd.conf file, add the following:
Include conf/vhost/zope.conf

This assumes you have an /etc/httpd/conf/vhost directory where you normally store virtual host information. Next, hop into your favorite editor and insert the following into a new file called /etc/httpd/conf/vhost/zope.conf:
# Insert your IP address here
NameVirtualHost 192.168.5.25

<VirtualHost 192.168.5.25>
DocumentRoot /home/httpd/html
ServerName www.mydomain.com

ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/
ScriptAlias /zope/ /home/httpd/zope/

<Directory /home/httpd/cgi-bin>
AllowOverride None
Options ExecCGI
</Directory>

<Directory /home/httpd/zope>
AllowOverride None
Options ExecCGI FollowSymLinks
</Directory>

RewriteEngine on
RewriteLog logs/rewrite_log
RewriteLogLevel 0
RewriteConf %{HTTP:Authorization} ^(.*)
# The following belongs on one long line:
RewriteRule ^/zope(.*) /home/httpd/zope/Zope$1
[e=HTTP_CGI_AUTHORIZATION:%1,t=application/x-httpd-cgi,l]

</VirtualHost>

What you have done is defined a virtual host for your primary server. You must tell Apache what IP address to listen to, which in the above example is 192.168.5.25. Then you define the server name and some script aliases (these are directories that are allowed to execute CGI scripts). Finally, you add two Directory directives, one for regular CGIs and one for your Zope CGI. Finally, you have to enable the mod_rewrite module engine and write your rewriting rules.

Be very aware that mod_rewrite is extremely powerful! You can cause some serious havoc with your system if you don’t use it properly. The first statement, Rewrite Engine, enables mod_rewrite. The RewriteLog and RewriteLogLevel deal with logging levels and the actual rewrite log file itself. The fourth statement, RewriteCond, tells Apache the conditions of the rewrite. For Zope, you want to pass authorization information to the CGI script, so we use HTTP:Authorization on all files. The final statement, RewriteRule, deals with the actual rewrite rule.

Basically it is saying that if someone attempts to reach http://www.mydomain.com/ the URL should be rewritten to point them to the Zope CGI script contained in /home/httpd/zope. We also want to pass the authorization to the CGI. Note that the last two lines are one long line and should be written as such. Also note that the last character before the closing square bracket is the letter “L” in lowercase, not the number “1”.

If you choose not to use the virtual hosting method to set up Zope (which I highly recommend as being the easiest method), you must insert those same rewrite rules in your httpd.conf file. Personally, I prefer breaking up the Apache configuration, because this way your Zope configuration is preserved across upgrades, especially if you use RPM-based installations and the RPM happens to overwrite your httpd.conf file.

Whatever method you decide to use, you’ll have to restart your Apache server by issuing
/etc/rc.d/init.d/httpd restart

You must then start your Zope server by issuing
/home/Zope/runzope &

if you chose to write the runzope wrapper script we discussed earlier.

Once this has completed successfully, you can connect to your Zope system! The initial page has a link to a management screen that you can log in to in order to begin managing your Zope Web site. Depending on whether or not you disabled the Zserver Web server, you can connect to the management screen by using http://www.mydomain.com/.

Conclusion
In this Daily Drill Down, I have explained how to install a Zope system on to your server. Although I have not looked at many of the features and functions that Zope provides, you have seen how to set it up and start it. Obviously, this is a pretty important first step. In another Drill Down, I will take a closer look at some of the features and possibilities that Zope affords to new and existing Web masters.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.