The usual IT babble
Posts tagged Work
Nagios: SNMP OID’s for IBM’s RSA II adapter
Apr 1st
Well, after some poking around I finally found some OID’s for the RSA’s (only through these two links: check_rsa_fan and check_rsa_temp).
For Nagios, I dismissed the fans, since the fan speed is only passed on in percent values. So I only added this:
define hostgroup{
hostgroup_name rsa-snmp
alias Remote Supervisor Adapter (allowing SNMP connections)
}
define service{
use generic-perfdata
check_command check_rsa_snmpv1_public!.1.3.6.1.4.1.2.3.51.1.2.1.2.1.1!45!60!°C!Temperature CPU0!
hostgroup_name rsa-snmp
service_description TEMP CPU0
}
define service{
use generic-perfdata
check_command check_rsa_snmpv1_public!.1.3.6.1.4.1.2.3.51.1.2.1.2.2.1!45!60!°C!Temperature CPU1!
hostgroup_name rsa-snmp
service_description TEMP CPU1
}
define service{
use generic-perfdata
check_command check_rsa_snmpv1_public!.1.3.6.1.4.1.2.3.51.1.2.1.5.1.0!29!35!°C!Temperature Ambient!
hostgroup_name rsa-snmp
service_description TEMP AMBIENT
}
Oh, and if anyone else is curious like me, here’s the list with the OID’s, courtesy of Gerhard Gschlad and Leonardo Calamai.
For the fans:
Fan1: .1.3.6.1.4.1.2.3.51.1.2.3.1.0
Fan2: .1.3.6.1.4.1.2.3.51.1.2.3.2.0
Fan3: .1.3.6.1.4.1.2.3.51.1.2.3.3.0
Fan4: .1.3.6.1.4.1.2.3.51.1.2.3.4.0
Fan5: .1.3.6.1.4.1.2.3.51.1.2.3.5.0
Fan6: .1.3.6.1.4.1.2.3.51.1.2.3.6.0
Fan7: .1.3.6.1.4.1.2.3.51.1.2.3.7.0
Fan8: .1.3.6.1.4.1.2.3.51.1.2.3.8.0
Fan9: .1.3.6.1.4.1.2.3.51.1.2.3.9.0
Fan10: .1.3.6.1.4.1.2.3.51.1.2.3.10.0
Fan11: .1.3.6.1.4.1.2.3.51.1.2.3.11.0
Fan12: .1.3.6.1.4.1.2.3.51.1.2.3.12.0
And for the temperatures:
CPU1: .1.3.6.1.4.1.2.3.51.1.2.1.2.1.1
CPU2: .1.3.6.1.4.1.2.3.51.1.2.1.2.2.1
CPU3: .1.3.6.1.4.1.2.3.51.1.2.1.2.3.1
CPU4: .1.3.6.1.4.1.2.3.51.1.2.1.2.4.1
Ambient: .1.3.6.1.4.1.2.3.51.1.2.1.5.1.0
I just found a proper list of OID’s for the IBM RSA adapter. That’s rather nice, since I really was looking for the OID’s for the VRM failure OID and other warning/critical events.
RPM spec: Installing a custom init-script
Mar 26th
Well, I’m sitting again here grinding my head on how to fix up a certain package. Now, I had to look it up again, so this time I’m writing it down!
Source1: ${name}.initd
...
install -o root -g root -m 755 %{S:1} $RPM_BUILD_ROOT/etc/init.d/ndo2db
Linux-HA: Creating a random authkey
Mar 18th
I just looked over the slides of a presentation one of my trainees bought back from Chemnitz, and there was this nifty one-line command, with which you can generate a random sha1sum for your authkeys file.
Now, since I’m a bit lazy here’s the full command line to fill /etc/ha.d/authkeys for you:
node2 ~ [0] > echo "auth 1 1 sha1 $( dd if=/dev/urandom count=4 2> /dev/null | openssl dgst -sha1 )"
TSM client: Backing up files with umlauts on SLES
Mar 2nd
In the past, I always had problems with SLES and our Tivoli Storage Manager client’s when backing up files with german umlauts. Well, today I looked a bit harder, and quite quickly found a solution.
sles9 root [0] > env | grep ^LC LC_CTYPE=de_DE.UTF-8
As you can see from the above, SLES9/10 ain’t setting LANG or LC_ALL (which I searched for first), but is setting LC_CTYPE.
So, simply changing the LC_CTYPE in the init-script and/or prepending the dsmc command line with a new LC_CTYPE fixes my umlauts problems!
sles9 root [0] > LC_CTYPE="en_US" dsmc incr
Well, I had a long’ish talk with one of my trustworthy IBM senior consultants the day after writing this …
He told me something along the lines of this:
If you would like to back up files with names containing characters with a code > 127 please ensure that you have chosen a SBCS character set for your locale. The default code page C or the code page POSIX supports characters up to 127 only. Files whose names contain special characters will be skipped if C or POSIX is used. It is strongly recommended to perform a system backup by using a SBCS character set to prevent any file or directory from being skipped. This behavior for different locales is intended.
And this:
The UTF-8 locale is default on some Linux platforms. However, TSM Client currently does not support running under UTF-8 locales (such as en_US.UTF-8 and ja_JP.UTF-8). Export your LANG and LC_ALL environment variables to the iso8859-1 or EUC versions of your locale and then start a new xterm (or mlterm) session prior to running TSM Client.
That basically means, at least for using the TSM Client Java Interface (dsmj) and the scheduler/client acceptor daemon you have to switch your locales to something _not_ UTF-8 capable.
He also mentioned, that IBM doesn’t have a real solution for this problem, as well that there is no real workaround. You need to invest some time into figuring out the “right” locale setting for your system(s), since after writing the above I came to the result that it ain’t enough ..
You need to do the following:
lang="de_DE@euro" export LC_CTYPE="$lang" export LANG="$lang" export LC_ALL="$lang"
After doing so, the scheduler and the command-line client works …
Nagios: check_snmp again
Feb 27th
Well, today I had to grind my head again, regarding the way check_snmp handles WARNING and CRITICAL events. From my point of view, check_snmp is really just retarded sometimes.
As you know, all the other plugins accept WARNING and CRITICAL-thresholds based on the calculation, if the return integer is above this threshold it reached WARNING/CRITICAL state. But check_snmp doesn’t play that way.
It expects only ranges, which are NOT gonna result in warning or critical events. Which is kinda stupid, since you gotta rethink twice about the thresholds 
define service {
use generic-service
host_name ibm-bc1-mgmt
service_description Chassis Cooling - Bay 1
check_command check_snmpv1_public!.1.3.6.1.4.1.2.3.51.2.2.3.20.0!\
1900:8000!1900:0,10000:8000!\
RPM!Chassis Cooling - Bay 1
action_url /pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$
notes View PNP RRD grap
}
All in all, another lesson learned 