+[[!meta title="Project Ideas"]]
+
+A lot of what SIPB does which is not helping users with immediate
+problems and answering questions falls under the heading of SIPB
+projects. SIPB projects are usually things that a member or two have
+decided are worth doing and are working on. The main qualification of
+SIPB projects is that they help the MIT community or the world at large
+in some way. In general they also involve computers.
+
+Here's a list of SIPB project ideas that have been mentioned recently,
+along with the person who's suggested the project or a team that would
+be good to contact. Feel free to get in touch if something sounds
+interesting or you want advice getting started.
+
+## "add me to this list" button
+
+If I'm a webmaster for some group with an announcement list, it would be
+really nifty if I could add some HTML code to my page to create a button
+that, if someone clicks it, would use MIT certificates to find their
+username and automatically add them to a list. This isn't particularly
+difficult; you'll need to get a keytab (essentially, an account in
+Kerberos / Moira) for the website, and write a script to set that keytab
+as the list's "membership ACL" and a webapp to use that capability to
+add or remove people from the list.
+
+_Contact: geofft_
+
+## debdiffs of Debathena packages
+
+We have [a webpage](http://debathena.mit.edu/package-list/proposed) to
+list all Debathena packages in the ["proposed"
+repository](http://debathena.mit.edu/experimental#proposed), i.e., things
+we just changed and are waiting a few days for testing before pushing to
+the clusters, etc. However, that page gives you no information on what
+the change was. A very useful addition would be to use the `debdiff`
+tool to link to the changelog and code changes for each new package.
+
+_Contact: broder, debathena_
+
+## Better Trac-email integration
+
+A bunch of SIPB projects use [Trac](http://trac.edgewall.org/) as a bug
+tracker. The current email adapter we use [isn't very
+clever](http://debathena.mit.edu/trac/ticket/308); it'll send
+out each update to a ticket with a generic subject line, so it doesn't
+easily indicate whether the bug was resolved or someone just commented
+on it. It also doesn't know how to receive e-mail, so we can't reply to
+the e-mails it generates and have our comments go back into the bug
+tracker, and we can't (make bugs@mit.edu create Trac
+tickets)[http://debathena.mit.edu/trac/ticket/216]. There are one or two
+alleged plugins to do this, but they create a new ticket on every
+e-mail, rather than doing something intelligent with replies; a better
+plugin in both directions would be extremely helpful.
+
+_Contact: debathena, geofft, broder_
+
+## PulseAudio support for the office sound system
+
+There's a server in the SIPB office that you can "print" MP3 files to,
+and they will get played one by one. A significantly more modern
+interface to this would be to make a
+[PulseAudio](http://www.pulseaudio.org/wiki/AboutPulseAudio) server out of the
+computer hooked up to our sound system; this lets computers running
+PulseAudio (notably, most recent desktop Linux distributions, but
+Windows computers that install Pulse as well) route their sound to the
+office speakers.
+
+_Contact: geofft_
+
+## Snapshotted virtual machines for all popular Linux distributions
+
+A common need for people writing Linux software is to check that their
+software works on many popular distributions (Red Hat, SuSE, Debian,
+Ubuntu, Xandros, etc. etc.), and on multiple versions of these
+distributions. The qemu system emulator, and its virtualization cousin
+kvm, support image snapshots and a fairly lightweight process for
+running virtual machines, so you could set up an Athena locker with a
+few commands that give you a temporary copy of a Linux system for a
+particular distro and version that runs inside your terminal.
+
+_Contact: geofft_
+
+## Efficient disk snapshot support
+
+The previous project and a lot of other work could be made significantly
+more efficient by rethinking the design decisions in qemu's snapshot
+support. If this is the kind of thing that interests you...
+
+_Contact: nelhage_
+
+## inotify logger for scripts and Debathena
+
+On both our [web hosting platform](http://scripts.mit.edu/) and Athena
+cluster machines, we have way more software packages installed than we
+suspect people use, but no good way of determining this. There's a Linux
+interface called [inotify](http://en.wikipedia.org/wiki/Inotify) that
+lets you get notifications when another user accesses the filesystem: it
+would be pretty simple to use this to collect aggregate (anonymous)
+statistics of what programs and packages are used frequently or even at
+all.
+
+_Contact: geofft_
+
+## SIPB PostgreSQL server
+
+A lot of people prefer Postgres to MySQL, so having a community Postgres
+server akin to [sql.mit.edu](http://sql.mit.edu/), with similar access
+control, could be a useful project. You could set it up on
+[XVM](http://xvm.mit.edu/) with an eye to redoing the configuration on a
+scripts-hosted VM at some future point.
+
+This could easily become a bigger project, integrated with scripts'
+autoinstallers, etc., depending on ambition. Or it can just be a
+standalone server for people who want access to a Postgres database, but
+don't want to set up and maintain a server on their own.
+
+_Contact: mitchb, geofft_
+
+## Rewriting "add", "attach", etc. for Debathena
+
+Athena used to have a system _liblocker_ for managing the /mit
+directories and attaching and detaching links to networked filesystems.
+Debathena and Macathena come with an automounter for /mit, so links
+automatically appear when you use them, and nobdy cares much about
+detaching them, but we still use most of the complexity of liblocker
+because we haven't gotten around to cleaning it up. There's a [design
+proposal](http://debathena.mit.edu/trac/wiki/FixingLiblocker) on the
+Debathena bug tracker listing what should be a better implementation.
+
+_Contact: broder, debathena_
+
+## Checking scripts.mit.edu servers for consistency
+
+Now that we have five or six web servers (I've lost count), it's
+become entirely too easy to change something on one or some but not
+all of the servers. We often test changes, like newer versions of
+packages or tweaked configuration, in place on one of the servers, but
+we'd like something to remind us if we don't copy these changes to all
+the other servers. This involves checking packages (RPM, perl, etc.) as
+well as config files in /etc and possibly other things like LDAP config.
+
+I've also been told by multiple people that
+[Puppet](http://reductivelabs.com/products/puppet) or some other
+configuration mangement framework is the Right Answer here. We looked at
+Puppet and a bunch of others last summer and concluded none fit our
+workflow well, but we could re-evaluate that.
+
+_Contact: geofft, scripts-team_
+
+We'd like a cron job to automatically tell us if
+there are RPM packages installed on some but not all of the servers,
+or if there are changes in /etc, other than hostname and such, that we
+haven't committed to the scripts Subversion repository.
+
+## Your Project Here
+
+SIPB can help you out in terms of both computing resources and
+experienced people to bounce ideas off of. If you've got an idea for
+something cool to advance the state of computing at MIT or just
+computing in general, [[drop by our office|office]] and say hello.
sipb-www / wiki.git / commitdiff
