After receiving my new toy at work three days ago, a SunFire X2200 with 16Gb RAM, today I finally got around to set it up.

Now, while my server OS of choice is definitely FreeBSD this particular machine is going to be used as a development machine for a Plone project which will eventually be hosted at a provider who doesn't support FreeBSD but instead Ubuntu. Also, the machine came without an optical drive. So after a few fruitless attempts to boot from an USB stick, I simply stuck to what I already know and chose a TFTP based route using Mac OS X's built-in tftp server.

Basically, I just followed my previous how-to on how to install FreeBSD on a (headless, keyboardless) soekris machine. Only, this time, I installed the dhcp server from mac ports, instead of compiling it manually:

sudo port install dhcp

Then I downloaded the Ubuntu Server ISO image and mounted it.

In my dhcpd.conf I modified the root-path and filename options thus:

option root-path "/Volumes/Ubuntu-Server 8./install/netboot/";
filename "pxelinux.0";

Next modified the (existing) /System/Library/LaunchDaemons/tftp.plist so that it looked like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>InitGroups</key>
    <true/>
    <key>Label</key>
    <string>com.apple.tftpd</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/libexec/tftpd</string>
        <string>-i</string>
        <string>/Volumes/Ubuntu-Server 8./install/netboot</string>
        <string>-u</string>
        <string>root</string>
        <string>-s</string>
        <string>/Volumes/Ubuntu-Server 8./install/netboot</string>
        <string>-l</string>
    </array>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockServiceName</key>
            <string>tftp</string>
            <key>SockType</key>
            <string>dgram</string>
        </dict>
    </dict>
    <key>inetdCompatibility</key>
    <dict>
        <key>Wait</key>
        <true/>
    </dict>
</dict>
</plist>

Now all I needed to do was to start both daemons...

sudo /opt/local/sbin/dhcpd 
sudo service tftp start

...finally fire up the machine and press F12 at the boot prompt and Bob was my proverbial uncle.

I'm using the blueprint CSS framework for a new site that I'm working on and am rather enjoying the process (as far as that is humanly possible, given that it by definition involves working with CSS... cough).

One of the neat features of blueprint is a compressor script that not only renders all the various CSS bits that you want according to the given column numbers and sizes for each project into one neat (and compact) CSS file, but it also lets you define semantic classes and ids, so you can use something like class="navigation" instead of class="span-6 last". And on top of that, the compressor script will also generate a PNG image that conforms to the column size and padding you've selected. This proved to be really helpful in debugging the pages. Simply add the class showgrid to your outer most container div and presto!

When demonstrating the layout to the client, though, I wanted a less obtrusive way of switching the grid on and off and I thus came up with little jQuery script to generate a toggle switch for each page. And since jQuery will be the standard javascript library for Plone from version 3.1 onward, anyway I thought I might as well share the following snippet:

$(document).ready(function() {
    $("body").append("<div id='debug'>turn grid: <a href='' id='togglegrid'>" 
    + gridstate() + "</a></div>";);
    $("#debug").css("position", "absolute");
    $("#debug").css("bottom", "0");
    $("#togglegrid").click(toggle_grid);
});

function toggle_grid () {
    $(".container").toggleClass("showgrid");
    $("#togglegrid").text(gridstate());
    return false;
}

function gridstate () {
    if ($(".container").hasClass("showgrid")) {
        return 'off';
    } else {
        return 'on';
    };
}

P.S. I'm not exactly a fan of the Javascript language but I do appreciate jQuery a lot and for the sanity that it partially restores when working with Javascript. The snippet above is a good example of that in my opinion. Javascript can't get any more "pythonic" than that IMHO ;-) (But please prove me wrong!)

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.

Out of a whim I decided to join today's CSS Naked Day. After all, as a Plone Site there is no need to be ashamed :-)