Archive for the 'Technical' Category

RSS feeds for private projects work now

January 15, 2008

Assuming your reader can do basic auth, follow redirects, and store cookies… they should work. Besides some of the simple aesthetic changes done recently (and you might notice new free accounts have text ads), I spent a big chunk of today trying to get RSS feeds and iCal for private projects working. The problem was that Trac would not properly tell feed readers to send authentication credentials, so trying to add the URL would fail because of permissions.

Turns out a long while back a patch was made to help solve the issue by allowing any URL to be prepended with /login (for example /timeline would become /login/timeline) and this would prompt you to enter authentication credentials, log you in and redirect you to the appropriate URL.

This works, and should work for you with most readers. Unfortunately Google Reader and Calendar don’t seem to work with anything that requires authentication, but I tried with Netvibes and iCal.app and they work just fine. Let me know how it works with other readers.

-Jeff

Consider daylight saving time with cron

November 8, 2007

I know it’s over a week after the fact, but a friend said it’s probably worth mentioning our experience with this recent daylight saving time switch. Ignore this if you don’t observe DST or your servers don’t use it (which might not be a bad idea).

If you have cron scripts that are meant to run only once a day and will run on Sundays (such as daily or weekly schedules), do not run them on or between 1am and 2am. Otherwise you risk them running twice or not at all.

Yes, it may seem obvious, but it’s probably overlooked. We certainly didn’t realize it, but since we just happened to be debugging a weekly cron script running at 1am that Sunday, we caught it in the act of doubling a long running, CPU intensive task.

Happy Wednesday!
-Jeff

WSGI makes us faster, simpler, nicer!

September 20, 2007

We’ve been working for a long time on getting certain infrastructural things fixed. For example, did you know up until now we’ve been running on CGI? As we posted before, the original plan was to get Trac running on a cluster of tracd’s, much like the cluster of Mongrel’s we use for the Rails part of DevjaVu.

Just think about that. At our simplest setup, we’d have 2 Mongrel processes and 2 tracd processes. Plus we have to run Apache for Subversion given our setup. But wait, then we have this load balanced across several machines! With every machine we add, we’d get another set of these processes to worry about.

I was okay with Mongrels, but really, I was a bit upset coming from PHP about how much more I had to worry about to make sure the application was running. With mod_php you can just assume that if Apache is up, the app is up. With Rails and any FCGI or Mongrel-like setup, there were now two layers, one of which is usually a cluster of processes that could die or leak memory.

So recently we started writing a new application to replace our Rails part of DevjaVu. We’re writing it in Pylons, which is really nice and Rails-like, while still very Pythonic. This led us to mod_wsgi, which boasted faster performance than mod_python, and was even easier to configure. We tried our new app on our dev server with mod_wsgi and it was very nice. Then I realized Trac had WSGI support, so I tried Trac on mod_wsgi. Perfect!

After a few changes, DevjaVu production is now running Trac on mod_wsgi. Pages are loading almost twice as fast! Our setup is simpler, too. Once we replace our Rails app with the Pylons app, we can run everything with Apache. We’re stuck with Apache for a while anyway, so why not roll everything in? Faster. Simpler.

And we can finally have nice URLs for real! Let me explain:

Before, we had to have URLs like this:
http://myproject.devjavu.com/projects/myproject/wiki

That was redundant, long and ugly. We were able to rewrite our ideal shorter URLs to the longer version, so you could use URLs like this: http://myproject.devjavu.com/wiki

However, that was just a cosmetic rewrite and Trac would always generate the long URLs.

Now, Trac generates the short URLs all the time and the short URLs are the proper, non-rewritten way Apache serves the request. We have the long versions that you probably have posted around the web do a permanent redirect to the short ones. This way you can still use them, but you should update your links at some point since they are now deprecated.

Anyway, that was fun. Hope you enjoy the changes. We have a lot more coming up. Let us know if you run into problems.

-Jeff