Timothy Freund (t...@digital-achievement.com)

Hey Everyone --

I migrated to a new server, and the Typo theme repository
(http://proofread.digital-achievement.com) didn't move all that
gracefully.  I'm in the process of restoring it, but the upload is
taking a while.  (My DSL upload speed leaves much room for improvement).

I hope to get it back up and running before I call it a night, but if it
takes a *really* long time, it won't be until tomorrow night that things
are back to normal.

Just a reminder, if anyone wants to submit patches or new themes, I'm
easy to please: just have an interest in the work and send me the output
of "htpasswd -ns USERNAME".  The username 'tim' is taken, but you're
free to pick anything else.   ;-)

Thanks for your patience,

Tim

I have done a little bit of investigation -- here's the situation as
relayed to us by David Gibbons at Planet Argon:

> Within the last few weeks it was up, we were seeing cpu usage
> and memory usage skyrocket, IT'd peg the cpu at 100%, peg memory
 > usage at 2 gigs.  Disabling it was the only way we could keep
 > the server usable for the other people on it.  This happens with
> trac via mod_python, cgi, and tracd.

... and in a later message he said ...

> ...it seems programmatic in nature as it takes a very short period
 > of time for it to start blowing out our resources.  I didn't
> find anything conclusive in my testing, except that it occurs
> under cgi, mod_python as well as tracd.

Just to complete the picture, David said this is what our installation
looks like:

Trac .10 from subversion
Sqlite 3
Akismet for spam protection

This weekend I sent the following back to David, Scott, and Kevin:

> I was digging through Trac's mail list, and I found references to
> two tickets that might be similar to our problem:
>
> http://trac.edgewall.org/ticket/3779
> http://trac.edgewall.org/changeset/4127
>
> So if one of our attacking spambots posted changes to a page
> that triggered either of these bugs, we would see the CPU
 > spike whenever someone viewed that page.  None of the messages
> on the list mention excessive memory usage, so perhaps these
> bugs aren't the same as what we are seeing.
>
> These changes have been rolled into branches/0.10-stable of Trac.

So we basically need someone with both time and a shell account on the
machine to test fixes for our Trac instance.  Sprewell and I have some 
time, but no shell account.

Anyone with experience fixing broken Trac installations, now would be a
great time to offer up any advice gained from the experience.  :-)

Best regards,

Tim

If you are interested in leveraging Proofread[1] and turning it in to a
general purpose Typo enhancement catalog, I'd be willing to push it in
that direction.

I'm already versioning themes, and I'm working* on better test scripts.
  Managing the plugins in the same way could be nice.  Having themes and 
plugins available in one place would be very nice.

How does that match up with what you had in mind for listing Typo plugins?

Tim


[1] http://proofread.digital-achievement.com/catalog/

*OK, not so much this week -- not much code until I get wedding
invitations in the mail, otherwise I'll have two mothers and a bride
upset. :-)

That was my thought as well, although I have never seen Gallery2.

What about rgallery[1]?  It's a rails application -- I haven't looked 
into it in any detail, but if it supports the rails theme plugin[2] we'd
be 1/2 way there to having a gallery that supports existing Typo themes.

Typo themes and themes for the rail theme plugin are close enough that
getting a theme to work for both apps would be easy.

Does rgallery support themes out of the box?

Tim

[1] http://rgallery.dk/wiki
[2]
http://www.mattmccray.com/archives/2006/04/09/rails-theme-support-plugin-v-14/

I just filed ticket #1085.

The Aggregator object, in addition to RSS 2.0, has basic support of Atom
feeds.  More importantly it logs errors to the application log so that 
users have some starting point to work from when dealing with sidebars
that won't display.  So it is verbose, but hopefully in a constructive way.

I included Flickr and 43Things model implementations as examples of how
subclassing the Aggregator class works.

The Aggregator class has a field called errors.  I use that to collect 
errors that I then look for in the unit tests, but I can also imagine
one day exposing those errors in the admin console.  If a user was 
confronted with "Error opening url ($FEED_URL): 404" while configuring a
sidebar they will be more likely to fix the problem without becoming
frustrated.

Any comments or suggestions are very appreciated.

Thanks,

Tim