No Such Thing As One Program
As Craig Andera observed last March, there’s no such thing as “just one application”. Every real program is surrounded by ancillary tools to pre- and post-process its data files, monitor its status, connect it to other programs, and so on. Six months after deploying DrProject in classrooms at U of T, here’s a snapshot of what else our doughty system administrator has to mess with when he’s messing with DrProject:
/home/software/rcto restart various instances (one per course) when the server goes down and comes back up. This file is executed upon boot by being symlinked in as/etc/rc2.d/S99zlocal./usr/local/bin/stopstart, a script he wrote to stop and re-start instances. It would not be necessary to do this in such a "user-friendly" way if DrProject didn't crash occasionally (due to a concurrency bug we're still trying to track down). Once that's solved, it would suffice for the sys admin to be the one to restart wedged instances, because that would be rare again. On the other hand, Apache still comes with a user-friendly stop/start script…/usr/local/bin/stanleywatchis another script that periodically checks the URLs of running instances and notifies us if they're down. It takes its name from the server's (stanley.cs.toronto.edu). We'll keep this even when DrProject is rock solid—in fact, it'll probably be even more important then.pingdrprojectis a script driven by a cron job that accesses a mail URL in each instance every few minutes so that mail will be pushed out. It should be possible to get this to be triggered by the arrival of new mail instead, or (better yet) DrProject could supply a program which the sys admin could set as a pipe-type target in the.forwardfile or/etc/aliasesentry. Instead of the/etc/aliasesentry or.forwardhaving to put the mail message in a file in the right directory in the right format, and then strobe DrProject so that it actually processes the new mail, there could be a program which receives a raw e-mail message on standard input and just processes it right there. That is, the arrival of new mail would itself trigger the processing, and there would be no issue of maildir versus spooldir and so on./etc/apache2/sites-enabled/000-default, which is the standard Apache config file for the primary virtual host on that machine. It maps the URLhttps://stanley.cs.toronto.edu/svn/course-id/project-idto run the DAV Subversion module for the directory name/home/courses/course-id/drproject/repos/project-id, and the URLhttps://stanley.cs.toronto.edu/course-id/drproject/project-id/wiki/PageNameto be relayed to the DrProject server process listening on port 4003 with pathname/project-id/wiki/PageName. It also has other mappings for the normal server web pages and such, which don't change as courses come and go.
It’s more to install, configure, test, and keep consistent than we’d like; one of the goals of Engenuity’s work in the coming weeks will be to simplify this as much as possible.