Archives / Search ›

Upgraded to WordPress 2.0.3

Comment spam really is annoying, though it’s getting a run for its money from random Unicode glyph-abusing Brazilians I don’t know asking me to be their friend on Orkut. But four requests in one day!?

It seems WP-Cache was causing the weird blank-page-until-reload issues with WordPress 1.5, which translated into no-page-at-all issues in WordPress 2. Since TextDrive finally seems to have a handle on the server-crashing and performance issues (this server has been up for over 31 days), the caching plugin isn’t as imperative as it used to be, though I do like to be nice about using shared server resources where I can.

Quick WordPress 2 review: AJAXification is good. I don’t like the new admin color scheme; looks too much like a bad ripoff of Slashdot. From time to time gigantic fonts appear, for no apparent reason; being on a 1024×768 display, this sucks. The new WYSIWYG editor isn’t perfect (it turned a paragraph break into a line break the first time I posted this message), but it’s a lot better than most I’ve seen. The dynamic resizability of this editing window is especially slick—alternately, you could say we should have had this kind of stuff on the Web 10 years ago :-)

Still, I think I’ll be going back to MarsEdit as soon as I can; hopefully it’ll get some attention in the form of WebKit content-editable support soon. I’m already very addicted to NetNewsWire 2.1’s syncing, even with the known problems, it works well 99% of the time. When RSS feeds get messed up on iTunes, I end up with tens of old podcasting episodes, which is a lot of data to needlessly download. It’d be cool if I could tell it “don’t accept any posts with dates earlier than the newest (or even oldest) preexisting item in the feed”.

If you notice any site flakiness, please let me know. I realize some of the old posts from the PyCS and (especially) Radio sites still have formatting issues; fixing this is on my to-do list, just rather far down it.

Safari crashes

Safari crashes in exactly one situation in my daily browsing habits: while rendering macworld.com. It’s totally reproducible and happens virtually every day.

Macworld is the most popular US Mac magazine. Safari is the most popular Mac Web browser. Does this seem completely bizarre to anyone else?

Configuring Trac with FastCGI and lighttpd

I initially tried getting tracd to work, but couldn’t get it to generate URLs that made sense. So, I decided to investigate all the fuss about using lighttpd and FastCGI. It works, better than tracd likely, and is certainly more flexible.

Here’s my lighttpd.conf for dev.sabi.net. It essentially implements the “Global authentication” example from the TracMultipleProjects page on the Trac wiki. You need a trunk version of Trac for this to work; 0.8.x don’t have FastCGI support.

server.port         = 9013
server.document-root= "/home/nriley/web/public/"
server.indexfiles   = ( "index.html" )
server.pid-file     = "/home/nriley/var/run/lighttpd.pid"
server.errorlog     = "/home/nriley/logs/lighttpd.error.log"
accesslog.filename  = "/home/nriley/logs/lighttpd.access.log"
url.access-deny     = ( "~", ".inc" )
compress.cache-dir  = "/home/nriley/var/cache/lighttpd/compress/"
compress.filetype   = ( "text/plain", "text/html" )
fastcgi.server      = ( "/trac" =>
                       ( "trac" =>
                        ( "socket" => "/home/nriley/var/run/trac-fastcgi.sock",
                          "bin-path" => "/home/nriley/cgi-bin/trac.fcgi",
                          "bin-environment" =>
                           ( "TRAC_ENV_PARENT_DIR" => "/home/nriley/trac" )
                        )
                       )
                      )
alias.url           = ( "/media/" => "/home/nriley/share/trac/htdocs/" )
auth.backend        = "htdigest"
auth.backend.htdigest.userfile= "/home/nriley/etc/trac.digest.passwd"
$HTTP["url"] =~ "^/trac/[^/]+/login" {
    auth.require    = ( "/" =>
                       ( "method" => "digest",
                         "realm" => "sabi.net Subversion repository",
                         "require" => "user=nicholas"
                       )
                      )
}

In order for the above FastCGI association to work, I must create a file named trac in the server’s document root, so lighttpd has something to pass along to the FastCGI script. (I got this tidbit from this article on using Django with lighttpd).

I needed to use /media instead of /trac or something like /trac-common or /trac/common because I couldn’t get lighttpd to give up the FastCGI assocation with /trac.

It appears there’s nothing equivalent to “Require valid-user” in lighttpd, and the “require” statement isn’t parsed until a request is received, so you’ll need to add a bunch of users to a group and require a group, likely. The parsing error is very poorly identified, too: (http_auth.c.345) = is missing. I had to dig through the lighttpd source to see what it was referring to.

So, everything seemingly works; the only problem I’m having is my log file getting polluted with these messages:

2005-08-01 03:08:38: (mod_fastcgi.c.2110) FastCGI-stderr:  

which I’ve filed as a bug in Trac.

I also had to do some digging to figure out how to enable anonymous access to Subversion via WebDAV. The Subversion repository’s DAV interface was created as private to begin with, a sensible precaution. However, I couldn’t use <LimitExcept> to apply permissions, so instead I have a AuthzSVNAccessFile svn-access.conf that looks like this:

[dev:/]
nicholas = rw
* = r

Then I open up Apache access with Satisfy Any. Some more discussion of this technique is here.

‹ Newer Posts