[Beowulf] How do people keep track of computers in your cluster(s)?

[Robert G. Brown]

On Mon, 22 Oct 2007, Lombard, David N wrote:

> On Sun, Oct 21, 2007 at 04:26:19PM -0400, Robert G. Brown wrote:
>> On Sun, 21 Oct 2007, Bruno Coutinho wrote:
>>
>>> dmidecode can be used to gather vendor, serial number and firmware version
>>> of bios, processor and motherboard, and the machine as a whole  (if vendor
>>> fill it).
>>>
>>> smartctl can gather this information about disks
>>
>> I'll look into seeing if I can integrate some of this into xmlsysd,
>> then.  Ideally via a systems call, not a shell call, as the latter has a
>> lot of overhead.
>>
>>    rgb
>
> Modulo hot-plugging, dmidecode (as well as ownershipd and vpddecode) present
> static output.  As smartctl provides some dynamic info, this is more of an
> issue.

If you mean that it wouldn't be a lot of work to extract static
information at the time xmlsysd starts up with a one-time shell-based
information extraction step, I agree, although screen-scraping is still
ugly and a moderately risky thing to put into a program because
shell-based interfaces are more likely to change without warning.  I
already have some pretty serious issues with the transcendant ugliness
of /proc, where I have to use some think like four distinct KINDS of
utility programs to extract data from its damn near random layout(s).

dmidecode (and biosdecode, ownership, vpddecode, although the latter two
don't work on the system I'm sitting at as it isn't made by compaq or
ibm) produces a TON of information, and the output is formatted as pure
evil for anything but humans.  Furthermore, I'm willing to bet that its
output structure is somewhat freeform and varies from handle to handle
and system to system.  The designers clearly have never heard of xml and
hierarchical, extensible table design, so that parsing the output
(especially without a wide range of systems to test on) is going to be a
matter of doing lines one at a time, counting tabs, matching leading
strings to determine field names (where I don't have the full data
dictionary), using : as a delimiter following a single tab in a
field:value format unless (long list of exceptions) leading to
overloaded fields or vector fields with a second tab, plus parsing data
(e.g. interrupt number) out of field values on demand.

Truthfully I have to do all of this kind of thing in xmlsysd anyway as
parts of /proc are just as bad.  But it doesn't make it fun, and I'm
sure that when I'm done somebody will have a system where a third level
of tab indents are presented, or hardware I don't have appears that the
code won't know how to parse.

That's why I'm probably going to try to look at the source (and what the
source is good for).  With luck all the data will be extracted from a
raw /dev/mem read (no problem) and parsed from there with a library that
encapsulates all the field/value/characteristic output.  If there is, I
may make BOTH an xmlsysd routine to do it directly via the library and
maybe a dmi2xml program that precisely replaces all of the above with a
single tool that produces the output in xml, with a default-help option
that dumps its current data dictionary.

When I have time.  If it had been easy I would have done it right away,
but this is just plain evil incarnate -- a pain in the butt in perl, a
BIG pain in the butt in C even with my utility routines.  It looks like
some of the field names might even be reused to have different meaning
in context, and there are a LOT of cases where one has to use more than
just the first word in the field name to figure out what the field is.

Grrrr.

smartctl is if anything even worse, but again it would be pretty easy to
run it once to extract static information at the time xmlsysd is forked.
This much:

Model Family:     Hitachi Deskstar 7K250 series
Device Model:     HDS722516VLAT20
Serial Number:    VN64GMCDF3B93D
Firmware Version: V34OA6MA
User Capacity:    164,696,555,520 bytes

is fairly straightforward to parse and is probably all that is REALLY
needed per system.  Again, there may be a library interface or some way
to not screen-scrape, but to do only these five fields I wouldn't worry
so much about it.

    rgb

>
>

-- 
Robert G. Brown
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone(cell): 1-919-280-8443
Web: http://www.phy.duke.edu/~rgb
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977