Minimal Nginx front end configuration for Plone on Ubuntu/Debian Linux using virtual hosts

Here is the minimal Nginx web server configuration in order to needed to run Nginx at the front of Plone open source CMS site.

This is a minimal Nginx configuration for Ubuntu/Debian Nginx to run at the front of Plone. These instructions are not for configurations where one uses buildout configuration tool to build a static Nginx server.

  • Plone sites will by default served from port 8080, as set by Plone installer
  • We use a VirtualHostMonster URL rewriting mechanism to pass the orignal protocol and hostname to Plone. VirtualHostMonster is a way to rewrite the request path.
  • We also need to rewrite the request path, because you want to site be directly serverd from port 80 root (/), but Plone sites are nested in the Zope application server as paths /site1, /site2 etc.
  • You don’t need to configure VirtualHostMonster in Plone/Zope in any way, because all the installers will automatically install one for you. Nginx configuration is all you need to touch.
  • The URL passed for VirtualHostMonster is the URL Plone uses to construct links in the template (portal_url in the code, also used by content absolute_url() method). If your site loads without CSS styles usually it is a sign that VirtualHostMonster URL is incorrectly written – Plone uses the URL to link stylesheets also.
  • Plone itself contains a mini web server (Medusa) which servers the requests from port 8080 – Nginx acts simple as a HTTP proxy between Medusa and outgoing port 80 traffic. Nginx does not spawn Plone process or anything like that, but Plone processes are externally controlled, usually by buildout created bin/instance and bin/plonectl commands.

Create file /etc/nginx/sites-available/yoursite.conf with contents:

# This defines in which IP and port Plone is running.
# The default is
upstream plone {

# Redirect all www-less traffic to domain
# (you could also do the opposite www -> non-www domain)
server {
    listen 80;
    rewrite ^/(.*)$1 permanent;

server {

    listen 80;
    access_log /var/log/nginx/;
    error_log /var/log/nginx/;

    # Note that domain name spelling in VirtualHostBase URL matters
    # -> this is what Plone sees as the "real" HTTP request URL.
    # "Plone" in the URL is your site id (case sensitive)
    location / {
          proxy_pass http://plone/VirtualHostBase/http/;

Then enable the site by creating a symbolic link:

sudo -i
cd /etc/nginx/sites-enabled
ln -s ../sites-available/ .

See that your Nginx configuration is valid:

/etc/init.d/nginx configtest

configuration file /etc/nginx/nginx.conf test is successful

If the config was ok then restart:

/etc/init.d/nginx restart

More info

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Extending buildout.cfg to create a separate production.cfg for the production deployment

This is a short blog post how to use buildout configuration tool to create separate configurations for development and production runs for Plone CMS, If you want to know something about deploying ZEO cluster to the production servers then this blog post might make some sense for you.

In buildout configuration files, you can extend

  • Different buildout.cfg files
  • Different buildout sections

Here is a short example how to split your buildout to development and production configurations. We create two files:

  • buildout.cfg – singles process Zope instance for the development – base configuration
  • production.cfg – ZEO cluster installation for the production server, containing production specific bits

production.cfg extends buildout.cfg inherithing all the setup and simply declares more clients.

buildout.cfg can be any normal Plone Zope installation file e.g. one provided with Unified Installer.

The following production configuration is created by the example velow

  • ZEO database server (port 13000)
  • Four ZEO front end clients, clustered through a front end web server (13001..13004) with production grade cache sizes
  • One debug client, accesible over special SSH tunnel for debugging production bugs
  • One command line client, to be used for long-running tasks like migration runs

Note: There seems to be slight issue extending parts from other configuration files, so we cannot directly extend [instance]

Example production.cfg:

extends =

# We re-declare are parts here (though parts can come from buildout.cfg)
parts =

# On prod. server have a shared cached eggs folder

newest = false

recipe = plone.recipe.zeoserver
zeo-address =

# We need to re-declare instance as "head", as for some reason
# extending sections from the parent configuration file directly
# does not work
recipe = plone.recipe.zope2instance
debug-mode = off
verbose-security = off
zeo-client = true
zeo-address = ${zeoserver:zeo-address}
zeo-address =
zodb-cache-size = 200000
shared-blob = on
user = admin:admin
zeo-var = ${buildout:directory}/var
eggs = ${instance:eggs}
products = ${instance:products}
environment-vars = ${instance:environment-vars}

<= head
http-address = 13001

<= head
http-address = 13002

<= head
http-address = 13010
debug-mode = on
verbose-security = on

<= head
http-address = 13003

<= head
recipe = plone.recipe.zope2instance
http-address = 13004

<= head
recipe = plone.recipe.zope2instance
http-address = 99999
debug-mode = on
verbose-security = on

recipe = plone.recipe.unifiedinstaller
primary-port = 13001
sudo-command =
zeoserver = zeoserver
clients=client1 client2 client3 client4

Remember to run as bin/buildout -c production.cfg or symlink production.cfg as buildout.cfg on the production server. The latter is better as then you don’t forget the extra switch needed for bin/buildout command.

1. More info

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Install Internet Explorer 6-IE9 virtual machines on OSX and Linux using one liner script and VirtualBox

This is a must for every web developer out there.

VirtualBox is a virtual machine application for Windows, Linux (Ubuntu and others) and OSX for running different operating system inside your host OS. Install VirtualBox first.

Running more than one version of Internet Explorer per Windows installation is difficult, so you need to resort virtual machines even on Microsoft Windows itself when doing web development and testing in IE. xdissent (Greg Thornton) provides one liner command line script for automated installation of the Microsoft IE App Compat virtual machines for Linux and OSX. The source code of the script is on GitHub and easily maintained for your own purposes. On Windows, you can use native Microsoft Virtual PC download for running these virtual machines, so no scripting needed.

E.g. to install IE9 to a specific location on your hard-disk (/fast/ie) on OSX you can simply do:

curl -s | IEVMS_VERSIONS="9" INSTALL_PATH=/fast/ie bash

If you for some reason fail your install (download error, etc.) you can reset the installation

 rm -rf /fast/ie/vhd/IE9/

Warning: The download of IE9 alone is ~7 GB and with the downloaded RAR files, extracted virtual machine image and initial snapshot around 19 GB disk space is consumed. However you can remove downloaded image files after the installation.

In the end of the script you should see something like:

Creating IE9 VM
Virtual machine 'IE9' is created and registered.
UUID: e1733dd1-79d9-4c12-8770-131591d3d485
Settings file: '/Users/moo/VirtualBox VMs/IE9/IE9.vbox'

… and this virtual machine is added to VirtualBox registry automatically.

The Windows user username/password is: admin / Password1

Naturally, honoring the traditions of Microsoft, you might need to restart your virtual machine couple of times before you can do anything useful with it. Interestingly, only 256 MB of RAM is configured for Windows 7.

1. Other goodies

You’ll naturally get a copy of Windows 7 / Windows XP with the installation. However, this version of Windows is 30-days time limited and special Microsoft licensing terms apply. However, VirtualBox snapshot is created upon creation and you can always revert back to this clean snapshot. You may not use the virtualized Windows copy for any other purposes besides web development and testing. I am not entirely sure if this allows you to install Windows Mobile SDK and do testing of Windows Phone 7.1 (Mango) mobile browser…


\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Downgrading Subversion to older 1.6 release with Macports for compatibility

Subversion source code version control tool had recently version 1.7 release. The new version has different repository layout in local copies (files are different on your hd). Downsides of SVN version 1.7 include

  • You need to manually upgrade every repository on your hard disk
  • Third party tools don’t yet like the new Subversion. For example, I had hard time try to make Aptana Studio (Eclipse) + Subclipse to pick up new libsvn version. The latest Subclipse did not come with pure Java compatible libraries and native libraries just didn’t activate. Thus, one couldn’t use Aptana Studio’s integrated SVN Team features

Macports project provides open source tools for OSX. If you install Macports or run Macports self update it will pull the latest Subversion command line command and then the havoc breaks loose. For me this happened when I tried to use jarn.mkrelease, a tool to simplify the releasing of Python packages on PyPi, on non-upgradable repository: svn 1.7 command wanted to upgrade the repository, but this would have broken my workspace in Aptana.

1. Fetching and activating the older SVN version

First you can check what versions of SVN you have installed already

$ port installed subversion
The following ports are currently installed:
  subversion @1.6.17_1
  subversion @1.7.1_0 (active)

You can browse the available Macports packages and their versions here. Use Revision log link to see the older release. Then it is simple matter installing or activating the old versions

2. Activate old version

If you have older version installed you can fall back to it

sudo port activate subversion @1.6.17_1

3. Installing old version

This is more complex task because Macports do not have packages of older software releases. You need to

  • Browse the source packages in Trac
  • See the Revision log for Portfile of the package
  • Pick the SVN revision where the change was released
  • Map the Trac path to Macports SVN path in your head (no, there is no link…)
  • Manually checkout this SVN revision
  • Run package build from this checkout


cd /tmp
svn co --revision 76647 # gets 1.6.16
sudo port instal

The first attempt will fail because of the changes in the dependencies and you need to manually specify what serf variant to use

--->  Computing dependencies for subversion
--->  Dependencies to be installed: serf
--->  Configuring serf
Error: Please use serf0 or serf1 instead.
Error: Target org.macports.configure returned: obsolete port
Error: Failed to install serf
Log for serf is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/serf/main.log
Error: The following dependencies were not installed: serf
Error: Status 1 encountered during processing.
To report a bug, see <>

We need to manually edit checked out Portfile to reflect this change and change the depedency line to this:

depends_lib        port:expat port:neon \
            port:apr port:apr-util \
            port:db46 port:sqlite3 \
            port:gettext port:libiconv \
            port:serf0 port:cyrus-sasl2

Then it is sudo port install again and now we can see the old version is activated:

port installed subversion
The following ports are currently installed:
  subversion @1.6.16_0 (active)
  subversion @1.6.17_1
  subversion @1.7.1_0

4. More info


\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+