Question

Notes of a sample TWiki installation on DreamHost.

-- IsaacRabinovitch - 25 Jan 2004

Answer

I've been fiddling with my new TWiki for a couple of days. Now I've gone and broken it with a botched plugin install. I'm having trouble backing out my changes, so I think I'll just start from scratch. I won't lose much work, and this time I'll take the trouble to record the process for posterity. And of course make a few comments about various TWiki, uhm, issues.

My web site is at DreamHost. All in all a good outfit, though I've had issues with some of their policies. RichardDonkin has written some useful DreamhostSetupNotes on his own experiences installing TWiki on DreamHost.

I'm going to to follow the TWikiInstallationGuide as closely as possible. I might volunteer to rewrite this thing at a later date, so here's my chance to read it closely. I'll refer to Richard's notes only where necessary.

But first, technical backstory. When you create a virtual web site on Dreamhost, the root directory of the site is a directory off the home directory of a specified Linux user. This user owns the files (except for webdav directories) and all CGIs run SETUID to that user. (There's no provision to run CGIs as "nobody".) In my case, the user name is "picknit" and my personal site is at ~picknit/picknit.com.

My desktop system is an XP Pro box that connects to the Internet via a Linksys router and an SBC DSL line. (I suspect my use of the router is what prevents me from mounting DreamHost's Samba shares.) For static content, I have a directory under "My Documents" that servers as a staging area. The content is visible through a local Apache server (IIS and I do not get along). When working on web apps like TWiki, I prefer to use a shell running on DreamHost. Be nice to have some way of mounting my DreamHost directories, though.

I use SSH to access the DreamHost shell, and also to support file transfer via rsync. I actually have two sets of SSH tools. First, there's the command-line stuff that comes with Cygwin, which I use to generate keys and to support rsync. For shell access, I use PuTTY.

Step 1 (create and arrange directories)

Unzipped into ~picknit/picknit.com/twiki-impl. (From now on, assume partial path names are in this directory. The reason for the weird name will become clear.) DreamHost is very CGI-friendly (maybe a little too much so), so the default subdirectory layout will work fine.

Under DreamHost's default setup, I could enable the CGIs merely by changing their names to end in .cgi or .pl. I don't care for this feature, and have disabled these extensions on my site. I don't want to rename .htaccess.txt yet, so as a temporary measure, I've created a .htaccess with the single line SetHandler cgi-script.

Step 2 (file ownership and permissions)

DreamHost has Perl 5.6.1 and all the Perl modules you could want. I do wish they would upgrade to a later version, because some of the core library routines for 5.6.1 aren't taint-safe.

The instructions say to do chmod 755 for all the scripts in in bin. It's tempting to skip this step, since the files are provided with necessary read and execute permissions. But DreamHost won't execute your CGIs unless you're the only user who can write to them. That also applies to the directory they're in. So it's:

  cd bin
  chmod 755 *
  chmod 755 .
  chmod 644 setlib.cfg

The instructions for permissions and ownership on the files under data are much too specific. In my case, it suffices to make everything readable and writable only by the user "picknit", which already owns the files:

    find data -exec chmod u+rw,go-rwx '{}' ';'

There are no instructions for lib or templates but it makes sense to do the same thing:

    find lib -exec chmod u+rw,go-rwx '{}' ';'
    find templates -exec chmod u+rw,go-rwx '{}' ';'

Similarly, pub needs to be writable only by "picknit" but readable by everybody — or rather, to be readable by the httpd daemon:

    find pub -exec chmod u+rw,go+r-w '{}' ';'

The basic principle: static content and scripts need to be readable by everybody, so the HTTP daemon can get at them. Everything else only needs to be readable (and writeable) by the scripts, which execute as "picknit". You can impose these restrictions with .htaccess, but using file permissions is easier, and also protects you from other DreamHost users.

Mung the data RCS files:

    cd data
    perl -pi~ -e 'NR <= 10 && s/nobody:/picknit:/ ' */*,v

Step 3 (Config files)

Modifying lib/TWiki.cfg pretty straightforward. One rough spot is that DreamHost doesn't support en_US.ISO-8859-1. My choices seem to be en_US and en_US.utf8. TWiki support for UTF8 seems to be a little problematic, so en_US it is.

Oops! I just did Step 4, didn't I? OK, on to...

Step 5 (Configure Site-Wide Email Preferences)

Set WIKIWEBMASTER. There's other stuff I'm tempted to fiddle with, but better not.

TWikiInstallationGuide assumes that you'll use SMTP only if sendmail isn't available. But some other docs seems to assume otherwise, and sendmail is kind of old-fashioned. So I'll configure Set SMTPMAILHOST = mail.picknit.com

Skipping over to TWikiSiteTools, I learn how to enable WebChangesAlerts with the appropriate crontab entry:

     15,45 * * * * (cd /home/picknit/picknit.com/twiki-impl/bin; ./mailnotify -q)

-- IsaacRabinovitch - 25 Jan 2004