As reported by The Washington Examiner on 3/26:
D.C Councilmember Tommy Wells, D-Ward 6, called Saturday's Wirefly National Marathon "awful planning" after hearing complaints from some Southwest residents who awoke to find a section of M Street closed to vehicle traffic. Wells said marathon organizers never briefed him on the route, adding Mayor Adrian Fenty, who ran in Saturday's race, called him Friday night to apologize for poor planning. "I've got a staff who could sit down and look at it and say, "I think we have a problem here."
Without even checking the facts here, it seems rather strange that the Mayor himself participated in the marathon, yet at the 11th hour is apologizing for poor planning. Did it not occur to him that the marathon in which he planned to participate, might have some impact on the city? But a little research reveals yet another case of selective memory loss by D.C. politicians.
Where to begin? Well how about Tommy Wells' website. On Wednesday the 21st, Charles Allen, Wells' chief of staff (presumably, one of the ones who could sit down and say "I think we have a problem") posted a Community Advisory describing all the road closures, and even including a link to a map of the actual race course.
Then, there's a letter from Joseph Fengler, an ANC representative in Tommy Wells' district, to race director Christopher Browne. In this letter Fengler notes that "at our regularly scheduled Commission meeting on December 14, 2006, we voted unanimously to support the 2007 National Marathon scheduled for March 24, 2007." So, at least one of the ANCs in Tommy's district knew about this months ahead of time, and in fact even went on the record supporting the race.
The MPD issued an advisory. The Washington Times reported on March 11 that "[race official] Sweeney spent Friday afternoon before city officials hammering out the final course to be run in two weeks. Although a course was approved on Aug. 14, Sweeney said, the Metropolitan police had logistical concerns..." and consequently they changed the course at the request of MPD. (The course change did not affect Wells' ward, but altered the course in Northwest DC to open certain evacuation routes.)
I have been told that the race organizers have been in weekly planning meetings with the District of Columbia government for 6 months. There have been frequent stories in the news about the marathon, in particular related to Fenty's participation.
So, the rest of the world -- including MPD, Wells' staff, Wells' ANC representatives, and the media -- knew all about this event months ago. So where does Wells get off throwing the marathon organizers under the bus? Sounds to me like they did everything right here, while he and the mayor were out to lunch.
Tuesday, March 27, 2007
As reported by The Washington Examiner on 3/26:
Friday, March 16, 2007
Sorry to make my first post in two weeks be a boring technical one, but I've been too busy to let my mind ponder the vagaries of the universe lately.
I use LogWatch on a Linux box to keep me up to date on the previous day's hacking attempts, disk usage, backup status, and so on.It includes a module for use with ProFTP, the FTP server, but it never worked right. I tooled around Google for a while trying to find a version that worked, but only found others looking for the same thing with no solution. So I took matters into my own hands and updated the filter to correctly parse current ProFTP message log files.
A lot of this is untested, but the corrections mostly involved what seemed to be a pretty simple change in the the log format from whenever the script was originally created. I also added some code to summarize "unmatched" entries rather than spewing out every single one of them so my logwatch emails won't be gigantic if I missed something... If anyone uses this script and finds that it doesn't properly parse anything, post a comment or send me an email with a copy of any offending log entries, and I'll update the filter.
On my Fedora box this is /etc/log.d/scripts/services/proftpd-messages. I also added an option to "summarize unmatched entries" which means that if the script can't figure out what to do with a log entry, instead of copying every unmatched line (of which there might be a lot, if there was a hacking attempt or other repeated error of some kind that isn't handled yet by the script) into the logwatch message, it will summarize the "unmatched" entries the same as any other one that is recognized. To enable this, set:
$ftpd_ignore_unmatched = 2
Update 3/21/2007: I fixed a few bugs and added support for some more messages that weren't handled by the old script. The current version is now at the link above.
Also, in an exchange with the current developer of this script on the logwatch-devel list, I suspect that the problems with this script have to do with operating system. He is running on Solaris and the log format that his installation of ProFTPD produces remains consistent with the "old" version of the script. So, chances are, this script will be good for Linux but maybe not for other *nix variants such as Solaris. The next official release will likely be capable of handling either format log file, though.
Update 3/27/2007: The original changes I made have been committed to the CVS, so the latest version will work for either log format. I have a few other additions that I need to extract from this version, but consider the CVS version better at this point.