Bug 47437 - [RFE] rhn_register to get system type/info from DMI/SMBIOS
Summary: [RFE] rhn_register to get system type/info from DMI/SMBIOS
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rhn_register
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-05 14:54 UTC by Matt Domsch
Modified: 2015-01-07 23:47 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-07-12 21:02:19 UTC
Embargoed:


Attachments (Terms of Use)

Description Matt Domsch 2001-07-05 14:54:31 UTC
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-06 02:54:36 UTC
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-06 03:31:51 UTC
Alan, comments?

Comment 3 Matt Domsch 2001-07-06 03:42:46 UTC
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.


Comment 4 Alan Cox 2001-07-06 08:02:05 UTC
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 17:26:18 UTC
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 18:54:51 UTC
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 17:42:40 UTC
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



Comment 8 Alan Cox 2001-07-12 18:43:38 UTC
Where do I get the Linux version of asset.com ;) or what interfaces does it use 


Comment 9 Cristian Gafton 2001-07-12 18:54:40 UTC
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 21:02:15 UTC
> 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.


Comment 11 Cristian Gafton 2001-10-01 23:44:11 UTC
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.