This project is on hold indefinately. -- After getting a new job in June of 2004 several rather predictable things have happened.I'm leaving this stuff here for historical reasons, and who knows, maybe someday I'll have enough time to revisit it.
- Zope is not part of my day-to-day job responbilites, nor will it be.
- I've come to the sad conclusion that nobody in the project cares about application server security enough to actually put necessary effort into digging Zope 2 out of the hole its in. (Evidently, they'd rather play with an entirely new code base.)
- As a result, my give-a-shit factor for the entire Zope project has decremented several more fathoms, and is now well into the Earth's mantle.
Less really is more.
Zope 2.6 and earlier used a program called z2.py to start Zope's services; it was huge ugly mess of code that tried to do way too much. My hatred of z2.py dates back to 2000 and was the impetus for writing strawweight. In 1999 I was hired as a systems administrator and programmer at a company that used Zope. At some point after that, I started using Zope myself. In November 2001, while I was on vacation, I broke down and wrote the first cut of strawweight in an effort to rid myself of z2.py reliability problems. I took advantage of the framework provided by Dan Bernstein's daemontools, because it allowed me to replace large portions of Zope's daemon and logging infrastructure with a collection of small programs. (Remember, UNIX teaches us that the sum of the parts is greater than the whole.) Encouraging simplicity, reducing the required code footprint, and improving modularity are strawweight's goals.
There are a variety of reasons why strawweight may be of no use to you. While Zope is written with a one-size-fits-all philosophy, strawweight isn't; strawweight supports a single HTTP server on a single port and that is all. If you need a ZEO client or server, or other ZODB aware servers (FTP, FastCGI, etc.) strawweight can't help you (yet). Because Zope 2.7 will be the first official release to support both graceful shutdowns and signal handling, strawweight is being released against it; earlier Zope releases aren't supported. Zope 2.7 and later supports a complex configuration file scheme and a process control utility replete with captive interface, but strawweight doesn't (and won't).
This is where I'd like to take strawweight, and where its been. There is no timeline and nothing is set in stone.
The installation process won't come as a great shock if you've ever installed any of DJB's software before; I borrowed his techniques and adapted them to Python.
$ zcat strawweight-0.6.tar.gz | tar xvf - $ cd strawweight-0.6
Read README, INSTALL; edit conf-* to taste.
$ make # make setup check
Read the man pages for zoped-conf and zoped. Decide on the users to use for running Zope and its logger. You may want to take into account what DJB has to say the subject of UNIX account names. Whatever you decide upon, do NOT, under any circumstances, run Zope as the superuser. Make a service directory with a log. You can use zoped-conf for this, or you can do it by hand if you prefer. For example, to make service directory /etc/zope, run zoped as user zope, and run multilog as user Gweblog:
# zoped-conf zope Gweblog /etc/zope
That will establish /etc/zope as the service directory, logs will be placed in /etc/zope/log/main. To start the service all that is left is:
# ln -s /etc/zope /service
Many people will want to customize their Zope services, as well they should. These are my notes and recipes for various configuration strategies.