HP Proliant Support Pack on SLES 10
ProLiant Support Packs (PSP) represent operating system (OS) specific bundles of ProLiant optimized drivers, utilities, and management agents for HP ProLiant hardware and available for SUSE Linux Enterprise Server 10.
It includes utilities to query, modify, etc. your BIOS, perhaps your SmartArray configuration or your HP SAN LUNs. Besides these, it includes SNMP agents to monitor the hardware and email the system administrator in case of a failure.
Keep it simple
Don’t try to fix the non existing problem, install only the packages you really need. I prefer the stock SUSE drivers and only install HP ones if I experience compatibility problems or require a certain feature not provided by the stock driver. I usually install the monitoring components and some command line utilities such as:
HP Proliant Channel Interface
HP System Health Application
HP SNMP agents
HP System Management Homepage
If you have local RAID arrays configured via HP SmartArray then additionally:
HP Array Configuration Utility
HP Array Configuration Utility CLI
HP Array Diagnostics Utility
HP Array Diagnostics Online Edition
Get the right package for your architecture (32/64bit) from the link above then extract the tarball followed by executing the installer shell script as shown. Without parameters it would fire up the GUI but WARNING: if you do this through shell and X11 forwarding is not enabled, the installer script will not be able to open the GUI and as a result will carry out full CLI installation of all packages available for your hardware!
sles10:~ # tar zxf psp-8.11.sles10.i686.en.tar.gz sles10:~ # cd compaq/csp/linux sles10:~/compaq/csp/linux # ./install811.sh
Otherwise you could do unattended or scripted install (only for experienced users):
sles10:~/compaq/csp/linux # ./install811.sh --help
I recommend unselecting everything (GUI) then re-selecting just what you need. It’s smart enough to mark all dependent packages too automatically. Don’t you worry, you will not miss anything out of the installation. The process takes a little while, be patient you will get a nice report about it.
It depends on the stock snmp service which comes with the standard SLES 10 installation anyway hence I will not cover this in this guide. Luckily the HP agents need no configuration anymore, they work out of the box with the SUSE snmp service, some minor fixes are essential though. The installer sets the necessary services up for boot, puts necessary LSB scripts into the right place but one of them has a typo!
I tried my best to get this fixed by HP people, seem they either ignore this completely or think I’m wrong hence we need to fix this ourself.
SUSE LSB scripts use headers to describe what they provide, what they depend on, etc. It’s essential for the OS to start the services in the right order, in our case the SUSE snmpd service must start before the HP agents, makes sense right?
We must ensure that when we refer to another dependent service in LSB script headers we use the name in the Provides: field not the name of the LSB script! It’s commonly identical but not always!
sles10:~ # grep Provides /etc/init.d/snmpd # Provides: net-snmp snmp sles10:~ # grep Required-Start /etc/init.d/hp-snmp-agents # Required-Start: hp-health snmpd
Hope you see the problem above. The solution is now obvious, correct LSB script:
sles10:~ # grep Required-Start /etc/init.d/hp-snmp-agents # Required-Start: hp-health snmp
With the wrong script, snmpd service actually starts after the agents which causes improper operation and error messages sent to the root user.
After the fix you have to reconfigure the service to correct the startup orders:
sles10:~ # insserv hp-snmp-agents
These agents will monitor your hardware and warn you by email as soon as the failure occurs. To get these emails in time I usually forward the root email messages to myself or to a group of people:
sles10:~ # vi /etc/aliases -snip root: firstname.lastname@example.org -snip sles10:~ # newaliases
System Management Home Page
It installed a web frontend as well what you can reach on a certain port of your host for example:
You can initially log in with the root account of your local server only then query your hardware, look at system health, etc. It may be handy to gather information about a failed component (if any) if you are not familiar with the CLI utilities.
These are fairly safe nowadays even if some components compiled to the running kernel only. What happens is that components realize the new kernel and give errors on console after first reboot but in the meantime they actually rebuild themselves. Double reboot should make your console errors disappear for sure.
SNMP agents on XEN host
On XEN host we have issues with the stock snmpd service because it starts before xend in default. It generates similar errors as discussed earlier due to xend modifies the networking and creates software bridges on the physical interfaces. To avoid issues on XEN host we need to make the snmpd service dependent of xend service in similar fashion as before:
sles10:~ # grep Required-Start /etc/init.d/snmpd # Required-Start: $network xend sles10:~ # insserv snmpd