(The Admirable) Innovation Group 3.

Crichton

The group developed Crichton, a modular, pluggable handler for bash's command not found events. There is Crichton documentation for computing staff and Crichton documentation for users.

Modules

Written

• because (user feedback for explicitly removed software perhaps)
  • and use cases: webots, matlab - see dice/options/crichton.h
• misspellings (suggests commands with a similar spelling)
• pkgmatch (not installed but in a repository -- request install by Support)
• pathCheck (checks if the user's PATH is messed up)
• baduser (asks user to please not run that command on this machine, it's deliberately not installed here)
• shellguards (detection of pipes, subshells etc. as per external link)
• mplayer (plays a random sound file picked from ~/.crichton.d/mplayer.d)
• classic (the classic "command not found" message)
• silly (a very large message)

Wish List

• The pkgmatch module matches on package names. We could in theory make it match on those packages' command names instead if we switched it to using yum provides but we'd have to make that a lot quicker. In particular we'd have to work round yum caching delays.
• It would be nice to have software package requests conveyed automatically to RT. We wrote a helper module which produced a script which when run would automatically file a software request in RT. However we then realised that this was a slippery slope to a general "file a support request" script and this seemed out of our jurisdiction.

---

Archive Material

InnovationGroup3Notes

WritingCommandNotFoundHooks

The Finalists:

(The search has been long and arduous, but we think we've narrowed the field to two (see the finalists below). An assessment of amenability to group-working will be made very soon, and rolled-up short-sleeves will follow shortly after that.)

• command-not-found hook (adapting to service type, package availability and user roles)
• An easier (large) file transfer (similar to http://zend.to)?

Second Rankers:

• Would it be handy to extend jabber somehow? (interfacing with RT?) It does meet a need but would have to be very visible (and the path of least resistance, for people to use it). How much storage required to operate this? Do we want yet-another-generic-MySQL-backed-web-service?
• Monitor IPMI states on the servers and alert us if something starts to look wrong (use the front panel display and/or SMS?).
• Do something with http://www.snort.org/

Also Rans:

• Make it possible for a DICE machine user to choose software and have it installed there & then.
• The servers can display a variety of things on their little front panel LED displays. Could we make it easier to program these displays somehow? For instance to temporarily display a custom message ("Answer the phone!") or to make the displays cycle through their standard repertoire (e.g. model number, mac address, current power consumption, inlet air temperature, host name, whatever it is that they can normally display) changing every few seconds.
• Cosigned web access to some cameras - e.g. roof garden, atrium (Food Cam!), etc