Ticket #817 (closed enhancement: fixed)
Athinfo query for USB HIDs
Reported by: | jdreed | Owned by: | jdreed |
---|---|---|---|
Priority: | normal | Milestone: | Natty Release |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
A common problem in the clusters is mice and keyboards walking off. It might be helpful to hotline if they could check remotely what was missing so they had the necessary components with them when they visited clusters. In our modern USB world, this is trivial. I propose an athinfo "usb-hid" query (I'd also be fine with a generic lsusb, but whatever). If we install python-usb in the clusters, this Python snippet should do what we want:
#!/usr/bin/python # import usb protocols = { 1: 'keyboard', 2: 'mouse'} found = { 'keyboard' : 'no', 'mouse' : 'no' } for b in usb.busses(): for d in b.devices: i = d.configurations[0].interfaces[0][0] if i.interfaceClass == 3 and \ i.interfaceProtocol in protocols.keys(): found[protocols[i.interfaceProtocol]] = 'yes' print found
Change History
comment:2 Changed 14 years ago by jdreed
Right, the issue with lsusb is that unless we parse -v, which we'd have to do on the client side, the devices are not reliable, because they're susceptible to typos or omitted information (e.g. "Intellipoint" vs "Mouse") in usb.ids. I vaguely like the idea of searching for unusual devices, but I'm concerned about the large number of false positives. We could certainly have an lsusb query in addition. OTOH, if a USB keylogger actually advertises itself as such, that's kind of stupid.
comment:3 Changed 14 years ago by jdreed
- Owner set to jdreed
- Status changed from new to accepted
Er, that should say "... the device _names_ are not reliable..."
Also, if we ship this in athinfod-cluster-config, should it go in /usr/libexec or /usr/share or what? We'd also have to depend python-usb, but that's in every cluster distro, so *shrug*.
comment:5 Changed 14 years ago by jweiss
A common problem in the clusters is mice and keyboards walking off.
Really? When I was in w20 a few weeks ago, I noticed a number of these unplugged, but generally still there, and in fact, with their cables going through some sort of lock-down device. I suppose it is still useful for hotline to know that they're unplugged, but it's not like they have to bring anything with them to solve that problem. Or are tehy not as well secured in other clusters?
comment:6 Changed 14 years ago by jdreed
They're not as well secured, because in many cases, the metal loop used to secure them to the anchorpad cable is large enough to allow a plug to pass through it. I was inspired to write this when two machines in 37-332 were missing mice. Anyway, unplugged is still useful to know about, since if the user disconnects it at the back, it may not be obvious.
lsusb might also be helpful for detecting screw cases like "someone left a thumbdrive in the machine and logged off" (or, heaven forbid, "someone plugged a hardware keylogger in"), in that Nagios can be taught to check for both missing devices and unexpected devices.
Your Python script is nice and short. lsusb does have the advantage that it does have its own database of human, but searching for keyboards and mice in particular is a little more awkward (unless we parse lsusb -v).