Hide Forgot
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.
hmm, interesting. 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...)
Alan, comments?
asset.com is a DOS utility to set the asset tag. http://ftp1.us.dell.com/utility/asset.com 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 too. 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. # ./rhn_sysinfo 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 some time. And, of course, changes don't take affect in the SMBIOS tables until after a reboot.
The registration client to be shipped in the next release includes DMI support.