Hardware Multicast Daemon
hwmultd began as an ad hoc soluton to a practical problem we had in our server room. Like so many other projects, it began to reveal its usefulness in ways other than its original intent and started to accumulate features. We are releasing it in the hopes that others might see usefulness in the features it already has and/or contribute to other potential uses.
The original problem was that we have a server room with a UPS that backs about a dozen servers. It is air conditioned, but the air conditioning unit is on a different circuit than our power feed to the UPS, so we can be in the situation where power is still on for our servers, but not the air! You can imagine what happens to a bunch of servers, each spewing out 500W of heat, in a small closet. Since there was no other practical way of communicating to the servers that power to the air conditioning unit was down, we took a direct approach and purchased a hardware device which monitors ambient temperature. (The device we settled on can be found at temperaturealert.com.) We then hacked up a multicast daemon which would probe the temperature on one server and share this information with others on the same subnet. These, in turn, would decide if the room was too hot and shutdown if necessary.
The next problem was entropy. Some of our servers get entropy starved because of the type of activity they are engaged in. There are some software daemons for enhancing the entropy available in /dev/random(eg haveged and audio-entropyd), but we wanted a hardware device to generate entropy and then share it with the rest of the subnet. Again, hwmultd came to mind! We figured we could multicast entropy information from the hardware source on one box and add it to the pools on the other boxes. We understood that sharing the same entropy on different machines has security implications, but given how we planned to use it, we felt this was not a major concern.
So what exactly does hwmultd do? It operates in one of two modes, or both at the same time if need be. As a server, hwmultd monitors some hardware device and multicasts whatever information it gathers to the subnet. As a client, hwmultd joins some multicast group and listens for that information. Once it receives a message, it decides what to do and acts accordingly. Sometimes, you want the server to also be its own client. For example, in the above example where the temperature in the server closet gets too high, you will want the server itself to shutdown; after, of course, it has alerted the clients on the subnet to do the same! Such cases, hwmultd will run in both modes at the same time.
hwmultd is currently under heavy development and so it has some limitations. The first limitation is that its protocol for communicating the hardware information is pretty lame. Basically, it is just a single string of data in clear ascii. This serves its purpose well if both server and clients are configured properly so that a single string "26" means 26oC and not, say, 26oF. But any misconfiguration is likely to lead to disaster. The plan here is to markup the data with xml and make clear the meaning of each field in the communicated data. The second limitation is security related. Currently, hwmultd multicastings are sent and received clear text. So, any malicious user on the same subnet can falsify temperature data, say, and shutdown all the servers. Or worse, falsify entropy data. Bad entropy is worse than no entropy at all. Still, within these limits, hwmultd has usefulness and we believe in "release early, release often."