Bug 47437 - [RFE] rhn_register to get system type/info from DMI/SMBIOS
[RFE] rhn_register to get system type/info from DMI/SMBIOS
Product: Red Hat Linux
Classification: Retired
Component: rhn_register (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2001-07-05 10:54 EDT by Matt Domsch
Modified: 2015-01-07 18:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-12 17:02:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2001-07-05 10:54:31 EDT
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.
Comment 1 Adrian Likins 2001-07-05 22:54:36 EDT
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...)
Comment 2 Cristian Gafton 2001-07-05 23:31:51 EDT
Alan, comments?
Comment 3 Matt Domsch 2001-07-05 23:42:46 EDT
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.
Comment 4 Alan Cox 2001-07-06 04:02:05 EDT
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
Comment 5 Cristian Gafton 2001-07-06 13:26:18 EDT
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.
Comment 6 Alan Cox 2001-07-06 14:54:51 EDT
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
Comment 7 Matt Domsch 2001-07-10 13:42:40 EDT
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.
# ./rhn_sysinfo
Vendor: Dell Computer Corporation
Product: PowerEdge 2400
Serial Number: BA8ZR
Asset Tag: 180537

Comment 8 Alan Cox 2001-07-12 14:43:38 EDT
Where do I get the Linux version of asset.com ;) or what interfaces does it use 
Comment 9 Cristian Gafton 2001-07-12 14:54:40 EDT
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.

Comment 10 Matt Domsch 2001-07-12 17:02:15 EDT
> 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 
Comment 11 Cristian Gafton 2001-10-01 19:44:11 EDT
The registration client to be shipped in the next release includes DMI support.

Note You need to log in before you can comment on or make changes to this bug.