Introduction

I like to set up my servers to have one or two functions on them, largely to take advantage of application partitioning by virtualizing the servers. This walkthrough will show you most of what you should do in setting up a Ubuntu 9.04 server running Plone 3. We'll have a Ubuntu 9.04 server running in front of this machine as a reverse proxy with some mod_rewrite magic to support running several sites on this Plone server.

Installing Ubuntu

You should be able to find any number of Ubuntu 9.04 "perfect" setup tutorials on the web, so I'll point you at the one that I like and will meet you back here after the OS is installed (HowToForge, stop at the bottom of page three).

Got it installed and ready? Great. I expect that your machine:

• is running without errors
• has been assigned a local static IP address
• has had its hosts file adjusted to refer to itself by name
• had its apt sources updated to allow packages from the universe, multiverse and security restricted repositories
• has SSH running
• has root access available (I run this install as root for sanity's sake, but you are welcome to "sudo" each command if you like)
• has apparmor disabled
• has NTP running
  

My next step is to use the console on VMware ESX to install and configure the VMware Tools for this VM. The steps are not included here as VMware is a moving target for installing the latest tools, but again, there are many sites on the web offering help in installing and activating the Tools.

Next, I find it helpful to alter the udev configuration files so that udev doesn't lock out the new MAC address generated by the virtual NIC swap. If you are using a physical machine, you can probably skip this step, but it won't hurt anyways.

Edit "/etc/udev/rules.d/75-persistent-net-generator.rules" and add the following line just below the first comments section to keep this script from firing:

GOTO="persistent_net_generator_end"

Now edit "/etc/udev/rules.d/70-persistent-net.rules" and comment out the devices that may be listed here so that they aren't blackballed on the next restart.

Installing Plone 3

Before we install Plone, let's install some dependencies for Plone. Run the following using sudo or as root:

aptitude install gcc g++ make readline libxml2 wv wget libjpeg62-dev

The easiest way to install Plone is to use one of the Unified Installers that plone.org offers. We'll start collecting the software we need in our current account's user directory. The current version as of this writing is 3.3.

cd ~
mkdir Plone3
cd Plone3
wget http://launchpad.net/plone/3.3/3.3/+download/Plone-3.3-UnifiedInstaller-20090907.tgz
tar zxvf Plone*.tgz

Now we can enter the Plone directory and start the install. My preference is to specify the admin password, install directory, and instance name as I expect to install more than a single instance of Plone on this server. Where the command specifies <pswd> or <instance_name>, pick a password or instance name (with no spaces) that suits you and remember those values.

cd ~
cd Plone*
./install.sh standalone --password=<pswd> --target=/var/plone3 --instance=<instance_name>

The installer will start churning away, installing the Python, Zope and Plone packages. Incidentally, keep this Plone directory around as you will use it when adding another Plone instance. The installer is aware enough to realize that it doesn't need to re-install the Python and Zope packages again and will just create the new instance you requested.

Configuring the instance

With the first Plone instance installed and dormant, we need to adjust the configuration files so that we can arrange the ports used for HTTP traffic. This is done in Plone 3 by editing the buildout.cfg located in the instance directory. Edit the file and then adjust the port to something other than port 80 for simplicity's sake.

cd /var/plone3/<instance_name>
nano ./buildout.cfg

    ...
    http-address = 10080
    ...

Save the change (in nano, Ctrl-O to save, then Ctrl-X to exit). To properly update the instance, run the buildout tool to apply your change to the instance.

./bin/buildout

With these changes applied, you should be able to start the instance by hand and look for any show-stopper errors in the console logging:

/var/plone3/<instance_name>/bin/plonectl start

If the instance starts with no critical errors, you can kill the process using Ctrl-C. We'll set up an init script to start the site on boot and then execute it by hand to start the instance as a service.

ln -s /var/plone3/<instance_name>/bin/plonectl /etc/init.d/<instance_name>
/etc/init.d/<instance_name> start
update-rc.d <instance_name> defaults

You should be able to point a web browser to http://<host_ip>:10080/manage and get an authentication prompt back. Use "admin" with the password you specified above to gain access to the Zope Management Interface (ZMI). From here, you can continue to customize the Plone instance.

Adding another instance to the same server

What's the fun in running one site per server? I'd rather have several sites running next to each other so as to share the installed Zope and Python packages, differentiated only by the port they answer on.

To add another instance, go back to the Plone installation directory (you kept that, right?) and run the install script again with different parameters:

cd ~
cd Plone*
./install.sh standalone --password=<pswd> --target=/var/plone3 --instance=<instance_name>

Next, update this instance's buildout.cfg and use a different port:

cd /var/plone3/<instance_name>
nano ./buildout.cfg

    ...
    http-address = 10081
    ...

Try running it as  test instance as in the set up section above, and then create a link in the startup directory and lastly use update-rc.d to add this new instance to the list of services to start at boot. Rinse, repeat until your server runs out of capacity.

Enabling caching for performance improvements

This is assuming that you are using Apache 2.0 or 2.2. First, we'll need to enable disk caching:

a2enmod mod_cache
a2enmod mod_disk_cache

This enables the modules that support caching within Apache. With that done, we'll need to add an enabling section to the config for the particular site we're adding caching to.

 <IfModule mod_cache.c>
    <IfModule mod_disk_cache.c>
      CacheRoot /var/cache/apache2/proxy/<instance_name>
#      CacheSize 100
      CacheEnable disk /
      CacheDirLevels 2
      CacheDirLength 1
#      CacheGcInterval 4
#      CacheMaxExpire 3600
#      CacheLastModifiedFactor 0.1
#      CacheDefaultExpire 60
    </IfModule>
 </IfModule>

Note that some directives, such as CacheSize and CacheGcInterval, have been discontinued with Apache 2. I've set the caching directory for this site to be "/var/cache/apache2/proxy/wgpta"; adjust as you wish to match your site identifier.

Next, you need to create that directory and give the apache process owner rights to use it:

mkdir /var/cache/apache2/proxy/<instance_name>
chown www-data:www-data -R /var/cache/apache2/proxy

Now restart the apache2 service, visit the site and you should see a handful of new directories in the CacheRoot directory.

/etc/init.d/apache2 restart

You can use the "du" command to check on disk space used for your proxy cache:

du -h --max-depth /var/cache/apache2/proxy

Run this occasionally to see if any particular cache directories are getting overly large.

Security Changes

Hardening against spammers

Some of the features of your site can be used against you, such as mis-use of the "Send To" feature. This feature normally allows someone to email a friend a link to the page on your site that they are looking at, largely as a "hey, look at this" gesture. However, the address checking on this page is loose and will normally allow anyone to send to anyone else. As such, it has become a favorite loophole for spammers to use. Let's remove it now.

Here's a checklist to get rid of Plone's send-to functionality:

• Take the "send to" ability away from unauthenticated users
• In the Zope Management Interface (ZMI) of your Plone site, select the "Security" tab.
• Scroll down to the "Allow sendto" permission and uncheck the "Acquire" and "Anonymous" boxes in its row. This will make it so that unauthenticated people can still reach the sendto form, but when they attempt to send, they'll get an error. This is the minimum to fix the problem.
• Remove the sendto document action
•  In the ZMI of your Plone site, select portal_actions
•  In portal_actions, select document_actions

•  Do one of the following (the second is recommended)
•   Delete sendto
•   Click the "sendto" item to open its properties, then uncheck "visible?" and save
  
• Replace the sendto_form page with a disabled message
•  In the ZMI of your Plone site, select portal_skins
•  Select the plone_forms folder
•  Click the "sendto_form" item, then click the Customize button
• In the customizable field, delete the contents between the "<body>" and "</body>" tags and put in "This form/action has been disabled" instead. Save the form. For example:

  <body>

    <div metal:fill-slot="main"
         tal:define="errors options/state/getErrors;">

        This page/feature has been disabled.

    </div>

  </body>

The first step removes a visitor's ability to use the send_to form. The second step hides it from them, and the third step makes those who try to get to it by hand aware of the change.