- Integrated Systems
- About Us
- Integrated Systems
- About Us
08-14-2014 10:33 AM - edited 08-14-2014 11:13 AM
HPSUM -- localhost use?
A firmware question from Joseph:
Hey folks-- Scratching my head on this . . .
Got a customer who simply wants to use HPSUM CLI to inventory a node for current firmware/driver versions. And I’ve been fighting the hpsum command to get this done in an easy fashion. So far I’m losing the fight . . .
Things done thus far on a RHEL 6.4 server . . .
- Perused the HP SUM User Guide
- Downloaded/installed the hpsum RPM on a RHEL instance
- # hpsum login ß To start hpsum “session”(?)
- # hpsum add –nodes localhost ß To add local node
Frustratingly, HPSUM wants a baseline established before it can inventory the system. Why is this?
So, in the spirit of “simply wants to use it for a quick inventory” . . I’m thinking I’ll just point “hpsum add –baselines type=http . . .” to get something from hp.com. But this command balks at “type=http”. And the documentation/manpages/blah are not very helpful :^(
- Is there a better local-to-node method for a customer to get HP-centric firmware/driver information using HPSUM?
- Any pointers on the above command line syntax/semantics?
Input from Dan:
I could be wrong but I think HPSUM is slightly dumb in this manner in that it needs the .scexe files in order to scan the local firmware of some devices.
I would try a custom SPP built elsewhere that only has the Linux drivers and firmware.
Then use that either via ISO or NFS mount as your baseline and scan.
And from Srikanth:
HPSUM has two modes of CLI operations. One is using the legacy switches, where you can give all the options in one single command, and wait for HPSUM to finish the complete operation. The other way is using the new console mode. In this mode you can do the operations more granular as tried by Joseph below.
We can use any of the modes to generate a report, to find all the firmware versions that are installed on the node. To generate a complete report we definitely need a SPP. The reason is we need some self-discovery components to find out the devices and firmware installed on the node. This is not a weakness HPSUM or SPP. HP doesn’t manufacture all the devices that are used in our server. There are many third party devices, where they retain rights to their intellectual property, and we need to use their tools to discover or update them. These tools are in their respective components.
Get an SPP, copy it locally or sharing it using NFS or mount the spp iso using an iLO virtual media. These are all the options to get the spp accessible locally
The console mode help is available using the command “hpsum --help”
hpsum add –-nodes localhost
hpsum add --baselines “<copied/mounted/shared spp root>/hp/swpackages>”
hpsum inventory –-baselines “<copied/mounted/shared spp root>/hp/swpackages>”
hpsum inventory –-node locahost –-baseline “<copied/mounted/shared spp root>/hp/swpackages>”
hpsum getcurrentlyinstalledversions –-nodes localhost
hpsum generatereports –-type combined –-nodes localhost
The CLI mode help is available in CLIHelp.txt in the same folder where HPSUM is located.
Also from John:
I have always wondered about this, and with Dan’s comment, I’m also curious. Does not the host OS give you some mechanism to capture the driver and firmware settings ? I realize each device manufacturer might put this information in a different place, but seems to me that an online-inventory should be possible without the need to run all of the .scexe file ( both the discover what you have, and then interrogate the version of what you have found) ?
Reply back from Srikanth:
HPSUM does capture lot of information. There are some devices that are not known by the operating system. Only way to access them is through proper drivers and tools from the component. The common drivers that come packaged with any type of OS(Windows 2008,RHEL) that HP supports, may not be able to pull up all the details.
There is a method to get the discovery details that HSPUM was able to inventory without the components, but I would not recommend this to any customer. This method will not give you the complete details.
- Create a temp directory. Place couple of the scexe or exe components in the folder even, if they are not applicable also its fine.
- hpsum login
- hpsum add –-nodes localhost
- hpsum add --baselines “<temp directory with few components>”
- hpsum inventory –-baselines “<temp directory with few components>”
- hpsum inventory –-node localhost –-baselines “<temp directory with few components>”
- hpsum generatereports –-type combined –-nodes localhost
You may not get the complete install set. But you will be able to at least see the details that hpsum was able to discover
Some info from David:
I note linux: (most excellent). For the linux aficionado’s:
There is a add_repo.sh (right-hand side of above web page) which will let yum() fetch direct from HP.
OR if really keen, (selectively – the whole thing is about 100GB give or take) rsync() the repository, and modify the add_repos.sh to point to the local rsync() repository of same.
Then of course, commands like “yum check-update” work brilliantly.
Add in dsh() and there’s the fleet covered.
Joseph replied to all:
Thanks all for the valuable feedback. Responses in bullet form . . to avoid my usual overdose of adjectives, adverbs, pronouns, etc. that make my emails much too long. (As I’ve been told by customers . . hah!)
- Setting up YUM against our SDR is fabulous-- Been leveraging that for years. But it doesn’t solve #1) why I need a baseline in the first place (see next bullet), and #2) why “type=http” doesn’t work
- Sri’s detailed explanation, as surmised by Dan, answers my question #1 above. Makes sense!
- Any pointers for #2 above?
- I’ve informed the customer that the spirit of HPSUM is as a “hub and spoke” tool . . i.e., it’s most efficient on a centralized management node with baselines (SPP, custom, etc.) already established. Then add nodes, run reports, etc. against gaggles of servers in the datacenter. Using HPSUM in this client/server sense on individual nodes is do-able but not efficient.
Other comments or questions?