The idea is, of course, that all (or just some) of your OS X Server users can authenticate against a Plone instance using the same credentials that they use to access all the other services (usually filesharing).

Requirements

I'm assuming a buildout based setup, so you will need to add the following bits to your buildout.cfg:

[buildout]
parts =
    ...
    productdistros
    openldap
...
[openldap]
recipe = zc.recipe.cmmi
url = http://www.openldap.org/software/download/OpenLDAP/openldap-release/openldap-2.3.27.tgz 
extra_options= --disable-slapd --disable-backends
...
[productdistros]
recipe = plone.recipe.distros
urls =
    ...
    http://plone.org/products/ploneldap/releases/1.0/PloneLDAP-bundle-1.0.tar.gz

nested-packages =
    ...
    PloneLDAP-bundle-1.0.tar.gz

You will also need python-ldap, for which even some eggs exist, however, I found that they didn't work on my test server (Ubuntu, 64bit) as they seem to have some .so files that assume a 32bit architecture (just a wild guess on my part), so instead I just installed it via apt-get (Ubuntu really has good support for Python2.4 based packages btw, no wonder it's so popular among Zopistas and Plonistas!)

sudo apt-get install python2.4-ldap

Now you can run ./bin/buildout and restart your instance.

Adding the plug-in

In the ZMI, navigate to your Plone instance's acl_users and add a Plone LDAP Plugin from the upper right hand select box. Obviously, filling out the following form with exactly the right values is the trickiest bit of the entire operation, so I've tried to make the example values as self-evident as possible. They all assume that the FQDN of your Mac OS X server is my.ldap.server.tld, so it should be a no-brainer to substitute all values according to your own setup.

• Set all three mappings (for Login Name Attribute, User ID Attribute and RDN Attribute) to UID (uid).
• Users Base DN to cn=users,dc=my,dc=ldap,dc=server,dc=tld
• Groups Base DN to cn=groups,dc=my,dc=ldap,dc=server,dc=tld
• Manager DN to uid=diradmin,cn=users,dc=my,dc=ldap,dc=server,dc=tld. You will obviously need to substitute diradmin for the id you chose when setting up the OpenDirectory server. Hint: it's the same id you use to log into the Workgroup Manager ;-)
• I have switched off encryption and SSL in my tests, so no guarantees that it will work with encryption (my Plone instance is running inside a VMware Fusion instance on the OS X Server itself, so I didn't see any need to bother with encryption, for a change)

Configuring the plug-in

Now you need to click on the newly created plugin at /plone/acl_users/ldap and activate all functionalities.

Still at /plone/acl_users/ldap click on Properties and User_Management and move the ldap plug-in to the top in both forms.

Finally, navigate to /plone/acl_users/ldap/acl_users and change the value for User object classes to posixAccount.

You now should be able to log into the Plone site using the credentials of a OS X Server user.

Currently I'm having lots of fun experimenting with WSGI, repoze and Deliverance. But while it's nice to know that it works in a development setup (i.e. deployed with paster) I needed to be sure it would work well in a production environment. And while there are already instructions floating around on how to deploy it with Apache and mod_wsgi, I wanted to know whether I could deploy WSGI-based sites using my trusted workhorse nginx.

Since nginx is much more monolithic than Apache (which is one reason why it can be so noticably more efficient than Apache in certain situations) you can't just drop in a plugin or module. Instead, you must compile nginx from sources and add the module at compile time.

The projects I'm working on will be deployed on Ubuntu and FreeBSD, but of course I will want to be able to test the same setup on my OS X development machine. So I've begun my tests with Ubuntu and OS X. Since nginx is available in all three systems' packaging system, my strategy is to install nginx via its respective package (which will integrate it nicely with start- and shutdown scripts) and simply replace the nginx binary with a self-compiled version that includes mod_wsgi.

So, here it goes: download and expand the sources for nginx (currently 0.5.35) and mod_wsgi (currently version 0.0.6):

wget http://sysoev.ru/nginx/nginx-0.5.35.tar.gz
wget http://hg.mperillo.ath.cx/nginx/mod_wsgi/archive/0.0.6.tar.gz
tar xzf nginx-0.5.35.tar.gz
tar xzf 0.0.6.tar.gz

*By the way, it seems to be a feature of mercurial unknown to the author of mod_wsgi Manlio Perillo to provide .tgz archives not only for the tip but also for each tag. Currently the tip of mod_wsgi doesn't compile on Mac OS X so I'm sticking with version 0.0.6 which has proven to be stable and contains the config fixes for Mac OS X.*

For both Ubuntu and Mac OS X we will need to explicitly tell the mod_wsgi plugin to use Python 2.4 rather than the default 2.5 version that comes with both systems, since I'm intending to run Zope based applications:

$EDITOR mod_wsgi-0.0.6/config

Change the second line of the file to:

PYTHON='python2.4'

Ubuntu

On Ubuntu you will need to install the following packages:

sudo apt-get install gcc
sudo apt-get install python2.4-dev
sudo apt-get install libxslt-dev
sudo apt-get install libssl-dev
sudo apt-get install libpcre3-dev

To take advantage of the start- and stop mechanisms provided by the official nginx package, let's first install that:

sudo apt-get install nginx

Now we can change into the nginx source directory and configure the build process to replace the packaged version of nginx with one that includes mod_wsgi like so:

cd nginx-0.5.35
./configure --add-module=../mod_wsgi-0.0.6/ --prefix=/usr/local --sbin-path=/usr/sbin \
    --conf-path=/etc/nginx/nginx.conf --with-http_ssl_module

You should receive a summary that looks like this:

Configuration summary
  + threads are not used
  + using system PCRE library
  + using system OpenSSL library
  + md5 library is not used
  + sha1 library is not used
  + using system zlib library

  nginx path prefix: "/usr/local"
  nginx binary file: "/usr/sbin"
  nginx configuration file: "/etc/nginx/nginx.conf"
  nginx pid file: "/usr/local/logs/nginx.pid"
  nginx error log file: "/usr/local/logs/error.log"
  nginx http access log file: "/usr/local/logs/access.log"
  nginx http client request body temporary files: "/usr/local/client_body_temp"
  nginx http proxy temporary files: "/usr/local/proxy_temp"
  nginx http fastcgi temporary files: "/usr/local/fastcgi_temp"

Make sure, the packaged instance of nginx is not running (we won't be able to replace it, otherwise):

sudo /etc/init.d/nginx stop

Now you can do the usual make ; sudo make install dance.

Before starting up the instance, we still need to run setup.py from the mod_wsgi folder:

cd ../mod_wsgi-0.0.6/
sudo python2.4 setup.py --prefix=/usr/local/ --sbin-path=/usr/sbin/ --conf-path=/etc/nginx/

Now you can start up your instance:

sudo /etc/init.d/nginx start

Mac OS X

On Mac OS X you will need to have the Developer Tools and MacPorts installed and the install the following in addition:

sudo port install python2.4
sudo port install libxslt # has libxml2 as auto-dependency
sudo port install py-libxml2
sudo port install nginx

For the configure process to find the 2.4 python libraries I found I needed to copy them to /opt/local/lib, as otherwise nginx would load the libraries of the system's 2.5 version at startup time which would throw mod_wsgi off track.

cp /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/libpython2.4.dylib /opt/local/lib/

Now we can configure it to match the nginx version from the ports collection like so:

./configure --add-module=../mod_wsgi-0.0.6/ --prefix=/opt/local --conf-path=etc/nginx/nginx.conf --sbin-path=sbin/ --with-http_ssl_module

Again, here's the summary output you should expect:

Configuration summary
  + threads are not used
  + using system PCRE library
  + using system OpenSSL library
  + md5 library is not used
  + sha1 library is not used
  + using system zlib library

  nginx path prefix: "/opt/local"
  nginx binary file: "/opt/local/sbin/"
  nginx configuration file: "/opt/local/etc/nginx/nginx.conf"
  nginx pid file: "/opt/local/logs/nginx.pid"
  nginx error log file: "/opt/local/logs/error.log"
  nginx http access log file: "/opt/local/logs/access.log"
  nginx http client request body temporary files: "/opt/local/client_body_temp"
  nginx http proxy temporary files: "/opt/local/proxy_temp"
  nginx http fastcgi temporary files: "/opt/local/fastcgi_temp"

Now you can do the usual make ; sudo make install dance.

Before starting up the instance, we still need to run setup.py from the mod_wsgi folder:

cd ../mod_wsgi-0.0.6/
sudo python2.4 setup.py --prefix=/opt/local/ --sbin-path=/opt/local/sbin/ --conf-path=/opt/local/etc/nginx/

Now we're finally ready to fire up our new instance. While testing and developing I can't be bothered to use launchctl so I chose a more pedestrian approach:

sudo killall nginx ; sudo /opt/local/sbin/nginx

Now you can take a look at the sample nginx.conf file provided in the examples directory of mod_wsgi to take the provided WSGI demos for a spin and, of course, to serve as a starting point to get your own apps running. Next I'll be looking at getting repoze.plone and repoze.grok running behind nginx+mod_wsgi, so stay tuned.

Earlier this week I bought a printer for the new project I'm working on. A big, bad-ass OKI 9800 A3 color printer for the price of a small car -- not my money -- the client's money ;-).

Since we're a Mac-only shop here, I made sure it's got postscript3 and ethernet, so that connectivity wouldn't be a problem. Well, it was. Of course. Long story short: if we used the offical, OKI supplied PPD, the printer wouldn't print. It only could be coaxed into printing when using the generic postscript PPD -- which of course knew nothing about the A3 paper size or any of the other nifty features.

After spending three days(!) with the OKI hotline (spent mainly with re-stating our problem and configuration to various operators) I finally hit gold. In the form of a friendly, competent and female(!) operator (Hallo, Frau Walther!) who didn't just resort to OKI's ticket database but (gasp!) to her memory. She actually remembered a similar case a while back, told me to hold, came back 30 seconds later and ever since we're able to print here!

Turns out, that OKI has been delivering a faulty PPD - ever since march 2005! In the end it's just a single % character that's missing. I have to ask myself: WTF did they not update that file? Anyway, I'm posting this so that any other fellow OKI users can find this (because until now googling for the error Missing filter "application/vnd.cups-postscript 0 fierycupsfilter" didn't deliver any results. Hopefully, this will have changed).

Below you can find a diff of the the PPD or, for your convenience, you can download a patched version right here from tomster.org.

@@ -2947,5 +2947,5 @@

 *% PPD Last Modified 2005.03.10
 *% OS 10.2 PPD DB version 4/10/03 JDF
-*cupsFilter: "application/vnd.cups-postscript 0 fierycupsfilter"
+*% cupsFilter: "application/vnd.cups-postscript 0 fierycupsfilter"
 *% End of PPD file

I was just about to explain to somebody via email how to switch skins per url in Plone 3 when I realised I should rather blog it and send him the link instead of just explain it to him privately, so here it goes...

Add a file skinswitcher.py to the top-level of your product with the following contents:

def setskin(site, event):
    if event.request.URL.find('127.0.0.1') > -1 \
        or event.request.URL.startswith('https'):
        site.changeSkin('NuPlone', event.request)

then include the following snippet in your top-level configure.zcml:

<subscriber
    for="Products.CMFPlone.interfaces.IPloneSiteRoot
         zope.app.publication.interfaces.IBeforeTraverseEvent"
    handler=".skinswitcher.setskin" />

This particular example simply enables the NuPlone skin when the site is accessed via https or 127.0.0.1 (instead of localhost) and otherwise uses the default skin which is my usecase 99% of the time but it should be easy now to modify skinswitcher.py to your particular needs.

When doing maintenance work on a deployment site it is always a good idea (and in good taste) to show visitors a human-readable page explaining that you'll be back soon[tm] instead of letting them see ugly tracebacks etc.

Easy, right? Just put a static HTML file and configure it as the site root and you're done, right? Well, not quite. Because that will show the page to all visitors of the root of your site, but everybody else will get a 404.

Well, regular expressions and nginx to the rescue. The following configuration snippet displays the same index.html page to any request, not just the front page. I now keep it commented out in all my config files to be able to quickly turn on a maintenance message if something requires some fixing:

server {
    listen 80;
    server_name foobar.tld;

    root /usr/local/www/foobar/;
    index  index.html index.htm;
    location ^~ /index.html {
    }
    location / {
        rewrite "^/(.+)$" / last;
    }
}

The crucial part is the (empty) ^~ /index.html location that simply exists to stop an endless recursion that would take place otherwise. It also means, that your HTML file must be named index.html and reside in /usr/local/www/foobar/ on the file system.