Description of Problem:
rhn_register should try to get the system type/information from BIOS DMI
or SMBIOS tables.
Alan Cox wrote a nice dmidecode.c application. Version 1.1 of such is
available from ftp://ftp.linux.org/uk/pub/linux/alan/DMI/. I provided a
patch to Alan on 7/2/01 to add additional structures and fix a few minor
bugs. That patch is available at http://domsch.com/linux/dmi/.
Based on that, I've stripped out a lot of code, and created rhn_sysinfo.c,
also available at http://domsch.com/linux/dmi/ which displays info
relevant to registering a system:
[root@tux dmidecode]# ./rhn_sysinfo
Vendor: Dell Computer Corporation
Product: PowerEdge 4300/400
Serial Number: 1KSVR
Asset Tag: (null)
Using this information, rhn_register could then re-direct customers to a
vendor-specific RHN server, and could pre-populate the server name field
with the Serial Number.
How stable/reliable is this on dodgy hardware?
Poking around in /dev/mem as root makes me
a little iffy, especially on something that
tons of boxes will be running.
Is the "Asset Tag" field ever populated? the
couple of machines I tried it on seem to
all report (null) (and these were Dell boxes...)
asset.com is a DOS utility to set the asset tag.
I've tried the dmidecode.c app on several PowerEdge servers (including the
Itanium server), and it's worked on everything so far. It *should* work on all
systems that properly have SMBIOS/DMI, and we can test it on all the PowerEdge
servers we'd want to see supported on at least.
The original dmidecode should be rock solid. It scans only ROM and bios private
memory areas. Matt's changes will segv on a few boxes I think (doesn't check for
a value out of range and wants auditing for signedness).
Personally I would find the DMI table, grab the table and ship the table back.
In terms of robustness for the basic stuff - we walked the table at boot time
too, so it should be fine
Okay, dfor now we are going to be using Alan's code and try to integrate that
piece of information into rhn_register.
Matt, can you try to address Alan's issues - once that is done we'll look at
using the new features from your patch.
I still think simply sending back the table itself might be better by sending it
back as is you can use local tools on it. The table itself is a single linear
block of rom
I believe I've addressed Alan's concerns, and have posted a new rhn_sysinfo.c
app at the address above if you'd care to use it. Alan's suggestion of
grabbing the whole table and parsing it locally to rhn would be fine with me
Using asset.com, I am able to set the asset tag info. Then these DMI-parsing
apps do properly retrieve the serial number and asset tag for the system.
Vendor: Dell Computer Corporation
Product: PowerEdge 2400
Serial Number: BA8ZR
Asset Tag: 180537
Where do I get the Linux version of asset.com ;) or what interfaces does it use
Sending back the DMI table as a whole is not a problem; the problem comes when
we need to decide how do we store the thing in the database.
If we store that as a BLOB, then whatever local tools we design we'll be a pain
to use, on top of the fact that BLOBs can not be used really easily for
displaying data on a website. If we parse it before we stick it in the
database, we're back to the same question fo what we parse and what we don't.
So far I am planning on parsing out the bios, board, system and chasis block
information and send those back. I can do more if we agree on what else needs to
show up on our database.
> Where do I get the Linux version of asset.com ;)
> or what interfaces does it use
Essentially, the asset tag info is stored in NVRAM but, the indices vary
somewhat system-to-system, so the method of looking it up is the SMBIOS table,
structure 0xD4, parsing that looking for the right token to find out what the
REAL I/O ports, indices, field lengths, and CRC types are. All of that is in a
Dell-internal-only document. I'll see about making public enough of that spec
to write a Linux assettag app, but politics being what they are, it could take
And, of course, changes don't take affect in the SMBIOS tables until after a
The registration client to be shipped in the next release includes DMI support.