Work – Page 13

Weird TS3500 problem

June 2, 2009June 21, 2013 Christian 1 Comment

Well, today we had a rather weird problem with our TS3500. TSM running on AIX basically went bonko and spit out weird media sense errors, all stating that there is a hardware or media error of unknown nature:

ANR8943E Hardware or media error on library LIB3584 (OP=00006C03, CC=-1,
KEY=04, ASC=44, ASCQ=00,
SENSE=70.00.04.00.00.00.00.46.00.00.00.00.44.00.00.00.00-
     .00.40.82.00.00.00.40.00.00.02.00.48.01.A1.00.00.00.00.0-
      0.06.1B.00.01.09.00.00.00.00.00.00.00.00.00.00.00.00.00.-
      00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00-
     .00.00.00.00.00., Description=An undetermined error has occurred).
Refer to Appendix C in the &#039;Messages&#039; manual for recommended action.
ANR8381E LTO volume HG4480L4 could not be mounted in drive DR9 (/dev/rmt8).

ANR8943E Hardware or media error on library LIB3584 (OP=00006C03, CC=-1,

KEY=04, ASC=44, ASCQ=00,

SENSE=70.00.04.00.00.00.00.46.00.00.00.00.44.00.00.00.00-

.00.40.82.00.00.00.40.00.00.02.00.48.01.A1.00.00.00.00.0-

0.06.1B.00.01.09.00.00.00.00.00.00.00.00.00.00.00.00.00.-

00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00-

.00.00.00.00.00., Description=An undetermined error has occurred).

Refer to Appendix C in the 'Messages' manual for recommended action.

ANR8381E LTO volume HG4480L4 could not be mounted in drive DR9 (/dev/rmt8).

After restarting the TSM server (as in the service, not the whole box) five times, which didn’t resolve squat we decided to take a look at the TS3500 itself. We opened up the Management interface and tried moving a tape into a drive. That didn’t work. Hrmmmmm.

We tried the manual move from the LCD display mounted on the front of the TS3500 base frame, that didn’t work either. So we figured the gripper was stuck and placed a call with our trustworthy support provider.

After a few minutes, they called us back and told us: “Try the following: Place the library in “Pause”-Mode and open it up, maybe a tape fell down …“.

We did exactly that, the gripper moved back to it’s pause position (which is in the base frame), and we started looking inside after opening up the base frame and an expansion frame. Nothing …

So we closed it back up, and let the base frame resume it’s normal duties … guess what: After resuming normal operations, it worked again *shrug*

Novell KMP: vmware-tools-kmp and ibm-lin_tape-kmp

May 10, 2009August 8, 2014 Christian Leave a comment

Disclaimer: I don’t take any responsibility for faults within the software, I just provide the RPM’s! Feel free to ask me about stuff concerning these RPM’s, but I ain’t accountable if your stuff goes kaboom … Oh, and those RPM’s aren’t recommended or supported by Novell or IBM!

After working with the novell-kmp solution, I think it’s actually rather easy to create a “Kernel Module Package“. In the end, I created two additional KMP’s, one for the tools component of the VMware-Tools shipped with VMware ESX, and another for the lin_tape SCSI driver, used by our IBM TS3400 as well as the IBM TS7530.

Some parts (especially the build system used within the VMware kernel modules) took some figuring out/playing around, but I actually got it working. Now each time I update the VMware-Tools I just need to install the new RPM, tada! No need for a fully fledged build environment on every box.

SUSE Linux Enterprise Server 10:

ibm-lin_tape-1.24.0_2.6.16.60_0.37_f594963d-0.1 (i586, x86_64, ~~SRPM~~)
- ibm-lin_tape-kmp-bigsmp (i586)
- ibm-lin_tape-kmp-debug (i586, x86_64)
- ibm-lin_tape-kmp-default (i586, x86_64)
- ibm-lin_tape-kmp-kdump (i586, x86_64)
- ibm-lin_tape-kmp-kdumppae (i586)
- ibm-lin_tape-kmp-smp (i586, x86_64)
- ibm-lin_tape-kmp-vmi (i586)
- ibm-lin_tape-kmp-vmipae (i586)
vmware-tools-kmp-3.5.0_153875_2.6.16.60_0.37_f594963d-0.1 (~~SRPM~~)
- vmware-tools-kmp-bigsmp (i586)
- vmware-tools-kmp-debug (i586, x86_64)
- vmware-tools-kmp-default (i586, x86_64)
- vmware-tools-kmp-kdump (i586, x86_64)
- vmware-tools-kmp-kdumppae (i586)
- vmware-tools-kmp-smp (i586, x86_64)
- vmware-tools-kmp-vmi (i586)
- vmware-tools-kmp-vmipae (i586)
- vmware-tools-kmp-xen (i586, x86_64)
- vmware-tools-kmp-xenpae (i586)

SUSE Linux Enterprise Server 11:

ibm-lin_tape-1.24.0_2.6.27.21_0.1-0.1 (i586, x86_64, ~~SRPM~~)
- ibm-lin_tape-kmp-debug (i586, x86_64)
- ibm-lin_tape-kmp-default (i586, x86_64)
- ibm-lin_tape-kmp-pae (i586)
- ibm-lin_tape-kmp-trace (i586)
- ibm-lin_tape-kmp-vm (i586, x86_64)
vmware-tools-kmp-3.5.0_153875_2.6.27.21_0.1-0.1 (~~SRPM~~)
- vmware-tools-kmp-debug (i586, x86_64)
- vmware-tools-kmp-default (i586, x86_64)
- vmware-tools-kmp-pae (i586)
- vmware-tools-kmp-trace (i586, x86_64)
- vmware-tools-kmp-vmi (i586)
- vmware-tools-kmp-xen (i586, x86_64)

Novell KMP: Useable version of ibm-rdac-ds4000

May 9, 2009August 8, 2014 Christian 1 Comment

After some more tinkering, a lot more looking at the macros in /usr/lib/rpm/rpm-suse-kernel-module-subpackage and /usr/lib/rpm/suse_macros, I think I finally have a usable RPM’ified version of IBM’s Multipathing driver ready for use.

There is still one major annoyance left: each time you install a new ibm-rdac-ds4000-kmp RPM, you also need to reinstall the corresponding ibm-rdac-ds4000-initrd package, as the macros in /usr/lib/rpm don’t allow for custom %post or %postun.

As mentioned before, I’m gonna send them to LSI/IBM for review, and maybe, MAYBE they are actually gonna make use of that.

Without further delay, here’s the list of packages. Just a short explanation: you need mppUtil-%version, in order to install the ibm-rdac-ds4000-kmp.

mppUtil-09.03.0C05.0030-0.2 (i586, x86_64, ~~SRPM~~)
ibm-rdac-kmp-09.03.0C05.0030_2.6.16.60_0.37_f594963d-0.2 (SRPM)
- ibm-rdac-kmp-bigsmp (i586)
- ibm-rdac-kmp-debug (i586, x86_64)
- ibm-rdac-kmp-default (i586, x86_64)
- ibm-rdac-kmp-kdump (i586, x86_64)
- ibm-rdac-kmp-kdumppae (i586)
- ibm-rdac-kmp-smp (i586, x86_64)
- ibm-rdac-kmp-vmi (i586)
- ibm-rdac-kmp-vmipae (i586)
ibm-rdac-ds4000-initrd-09.03.0C05.0030_2.6.16.60_0.37_f594963d-0.2
- ibm-rdac-initrd-bigsmp (i586)
- ibm-rdac-initrd-debug (i586, x86_64)
- ibm-rdac-initrd-default (i586, x86_64)
- ibm-rdac-initrd-kdump (i586, x86_64)
- ibm-rdac-initrd-kdumppae (i586)
- ibm-rdac-initrd-smp (i586, x86_64)
- ibm-rdac-initrd-vmi (i586)
- ibm-rdac-initrd-vmipae (i586)

This package should be usable with System Storage DS4000 as well as System Storage DS3000 (they use the exact same source code).

I also know, that this solution isn’t really perfect. I’ve been looking at the %triggerin/%triggerun macros, but right now I can’t draw up a scenario (an easy one at that) to successfully use triggers in this situation. Only idea coming up looks like this:

Put the triggers into ibm-rdac-ds4000
When installing the kernel module packages, ~~write the kernelversion/-flavor into a temporary file~~ (impossible, since the macros don’t let you influence %post), and then let the trigger create/update the MPP initrd

If anyone knows a better solution (as in easier, without the writing to a separate file), I’m all ears.

Novell KMP: KMP’ing IBM’s RDAC driver

May 8, 2009August 8, 2014 Christian 1 Comment

Well, after yesterday’s lesson about getting the IBM RDAC to install for a not-yet-running kernel, I decided to take it a step further. Novell does have some documentation about KMP’s, which is actually rather good, especially the guide written by Andreas Grünbacher.

After a short tinkering, I got it actually working. I was kinda surprised, at how easily it actually is. One problem I still have to deal with, is modifying the %post, to generate the mpp-initrd image. For now, the KMP only contains the default %post, which updates the modules.* stuff.

Name:            ibm-rdac
License:         GPL
Group:           System/Kernel
Summary:         IBM Multipathing driver for DS4000 disk subsystems.

Version:         09.03.0C05.0030
Release:         0.1
Source0:         rdac-LINUX-%version-source.tar.gz
BuildRequires:   kernel-source kernel-syms
BuildRoot:       %{_tmppath}/%{name}-%{version}-build

Requires(post):    mppUtil-%{version}, module-init-tools
Requires(preun):   module-init-tools
Requires(postun):  module-init-tools

%suse_kernel_module_package um

%description
This is the Engenio Linux RDAC Driver Package for IBM DS4000
Storage Subsystems.

%package KMP
Group:     System/Kernel
Summary:   IBM Multipathing driver for DS4000 disk subsystems.

%description KMP
This is the Engenio Linux RDAC Driver Package for IBM DS4000
Storage Subsystems.

%prep
%setup -n linuxrdac-%{version}
set -- *
mkdir source
mv "$@" source/
mkdir obj

%build
export EXTRA_CFLAGS='-DVERSION="%version"'
for flavor in %flavors_to_build; do
    rm -rf obj/$flavor
    cp -r source obj/$flavor
    make -C /usr/src/linux-obj/%_target_cpu/$flavor modules 
            M=$PWD/obj/$flavor
done

%install
export INSTALL_MOD_PATH=$RPM_BUILD_ROOT
export INSTALL_MOD_DIR=updates
for flavor in %flavors_to_build; do
    make -C /usr/src/linux-obj/%_target_cpu/$flavor modules_install 
            M=$PWD/obj/$flavor
done

%changelog
* Thu May 07 2009 - 09.03.0C05.0030-0.1
  - Initial package.

Name: ibm-rdac

License: GPL

Group: System/Kernel

Summary: IBM Multipathing driver for DS4000 disk subsystems.

Version: 09.03.0C05.0030

Release: 0.1

Source0: rdac-LINUX-%version-source.tar.gz

BuildRequires: kernel-source kernel-syms

BuildRoot: %{_tmppath}/%{name}-%{version}-build

Requires(post): mppUtil-%{version}, module-init-tools

Requires(preun): module-init-tools

Requires(postun): module-init-tools

%suse_kernel_module_package um

%description

This is the Engenio Linux RDAC Driver Package for IBM DS4000

Storage Subsystems.

%package KMP

Group: System/Kernel

Summary: IBM Multipathing driver for DS4000 disk subsystems.

%description KMP

This is the Engenio Linux RDAC Driver Package for IBM DS4000

Storage Subsystems.

%prep

%setup -n linuxrdac-%{version}

set -- *

mkdir source

mv "$@" source/

mkdir obj

%build

export EXTRA_CFLAGS='-DVERSION="%version"'

for flavor in %flavors_to_build; do

rm -rf obj/$flavor

cp -r source obj/$flavor

make -C /usr/src/linux-obj/%_target_cpu/$flavor modules

M=$PWD/obj/$flavor

done

%install

export INSTALL_MOD_PATH=$RPM_BUILD_ROOT

export INSTALL_MOD_DIR=updates

for flavor in %flavors_to_build; do

make -C /usr/src/linux-obj/%_target_cpu/$flavor modules_install

M=$PWD/obj/$flavor

done

%changelog

* Thu May 07 2009 - 09.03.0C05.0030-0.1

- Initial package.

Now, I’m kinda asking myself, why don’t more vendors submit their drivers to Novell in form of KMP’s … Anyway, I’m gonna send mine the LSI/IBM way, maybe they’ll pick it up …

IBM RDAC: Installing the driver for a (not yet) running version

May 7, 2009June 21, 2013 Christian 2 Comments

Well, kernel updates on our Linux servers running IBM’s RDAC driver (developed by LSI) is a real pest .. especially if you have to reboot the box two times in order to install the drivers/initrd correctly.

So I sat down and looked at the Makefile. Turns out, it just needs four tweaks in order to be working with a different kernel version (which you have to pass using environment variables to make).

--- linuxrdac-09.03.0C05.0030.orig/Makefile
+++ linuxrdac-09.03.0C05.0030/Makefile
@@ -25,7 +25,10 @@
 #
 #######################################################################
 
-OS_VER := $(shell uname -r)
+ifeq (&quot;$(OS_VER)&quot;,&quot;&quot;)
+	OS_VER := $(shell uname -r)
+endif
+
 HOST_TYPE := $(shell uname -m)
 IS_SMP := $(shell (uname -v | grep -c &quot;SMP&quot;))
 # Kernel Distribution (either REDHAT or SUSE)
@@ -170,7 +173,7 @@ copyrpmfiles :
 
 moduledep :
 	@echo &quot;Generating module dependencies...&quot;
-	@/sbin/depmod $(uname -r)
+	@/sbin/depmod $(OS_VER)
 	
 setupfiles :
 	@install -o root -g root -m 0500 -D Makefile $(DEST_DIR)/opt/mpp/makefile.saved
@@ -190,7 +193,7 @@ setupfiles :
 	rm devicemapping; fi
 
 setupdriver:
-	@/opt/mpp/setupDriver.$(DIST)
+	@/opt/mpp/setupDriver.$(DIST) $(OS_VER)
 	@if [ -f /etc/SuSE-release ]; then 
 		/sbin/insserv  /etc/init.d/mpp; 
 	else 
@@ -266,7 +269,7 @@ uninstall_doer:
 	@echo &quot;The mpp RAMdisk image mpp-$(OS_VER).img has been removed. You may want to remove it from your boot loader config file.&quot;
 	@if test ! -s /var/mpp/devicemapping ; then rm -rf /var/mpp/; fi
 	@echo &quot;Generating module dependencies...&quot;
-	@/sbin/depmod $(uname -r)
+	@/sbin/depmod $(OS_VER)
 
 
 LINUX_RDAC_DIR :=  $(shell pwd)

--- linuxrdac-09.03.0C05.0030.orig/Makefile

+++ linuxrdac-09.03.0C05.0030/Makefile

@@ -25,7 +25,10 @@

#######################################################################

-OS_VER := $(shell uname -r)

+ifeq ("$(OS_VER)","")

+ OS_VER := $(shell uname -r)

+endif

HOST_TYPE := $(shell uname -m)

IS_SMP := $(shell (uname -v | grep -c "SMP"))

# Kernel Distribution (either REDHAT or SUSE)

@@ -170,7 +173,7 @@ copyrpmfiles :

moduledep :

@echo "Generating module dependencies..."

- @/sbin/depmod $(uname -r)

+ @/sbin/depmod $(OS_VER)

setupfiles :

@install -o root -g root -m 0500 -D Makefile $(DEST_DIR)/opt/mpp/makefile.saved

@@ -190,7 +193,7 @@ setupfiles :

rm devicemapping; fi

setupdriver:

- @/opt/mpp/setupDriver.$(DIST)

+ @/opt/mpp/setupDriver.$(DIST) $(OS_VER)

@if [ -f /etc/SuSE-release ]; then

/sbin/insserv /etc/init.d/mpp;

else

@@ -266,7 +269,7 @@ uninstall_doer:

@echo "The mpp RAMdisk image mpp-$(OS_VER).img has been removed. You may want to remove it from your boot loader config file."

@if test ! -s /var/mpp/devicemapping ; then rm -rf /var/mpp/; fi

@echo "Generating module dependencies..."

- @/sbin/depmod $(uname -r)

+ @/sbin/depmod $(OS_VER)

LINUX_RDAC_DIR := $(shell pwd)

After that, a simple make KERNEL_OBJ=/lib/modules/2.6.16.60-0.37_f594963d-smp/build OS_VER=2.6.16.60-0.37_f594963d-smp install correctly installs the modules in /lib/modules, rebuilds the correct modules dependencies and builds the correct initrd image.

TSM: Restoring the database/recovery log to a point-in-time

April 24, 2009June 21, 2013 Christian Leave a comment

Well, my co-worker just called on my cell (it’s Friday, 16:00), and asked me which start-up script he needed to change in order to restore the database. My first response was, “ummm, that’s gonna be hard, we’re using heartbeat”.

Okay, so after a bit of asking I got out of him what he wanted to achieve by changing the start-up script. Apparently he did something to crash Tivoli Storage Manager (or rather repeatedly crash it) and wanted to restore the database. He talked to one of the systems partner we do have (and I’m happy we have them most of the time), who in return told him how to do it, but forgot a minute after he hung up the phone.

So, I went digging while he still was telling me how he got Tivoli to kick his own ass … After a bit, I thought “hrrrrrm, shouldn’t this be covered in the Tivoli documentation ?”, and surprisingly it’s actually covered in the documentation.

It’s actually rather simple.

Stop the dsmserv Linux-HA cluster service (tsm-control ha stop tsm1)
Setup the environment (since we’re running multiple instances of Tivoli Storage Manager – export DSMSERV_DIR, export DSMSERV_CONFIG)
Enter the path of the server
Run dsmserv restore db
Wait some time (took about half an hour to restore the 95G database and the 10G recovery log)
Start the dsmserv Linux-HA cluster service (tsm-control ha start tsm1)
Update the server-to-server communication, since the restore db changes the communication verification token

&gt; tsm-control ha stop tsm1
  - tsm1 (dsmserv) -&gt; ha: [ OK ]
&gt; export DSMSERV_DIR=/opt/tivoli/tsm/server/bin
&gt; export DSMSERV_CONFIG=/opt/tivoli/tsm/server/tsm1/dsmserv.opt
&gt; cd /opt/tivoli/tsm/server/tsm1
&gt; /opt/tivoli/tsm/server/bin/dsmserv restore db todate=TODAY totime=08:00:00 source=dbbackup preview=no
.... wait some time ....
&gt; tsm-control ha start tsm1
  - tsm1 (dsmserv) -&gt; ha: [ OK ]

> tsm-control ha stop tsm1

- tsm1 (dsmserv) -> ha: [ OK ]

> export DSMSERV_DIR=/opt/tivoli/tsm/server/bin

> export DSMSERV_CONFIG=/opt/tivoli/tsm/server/tsm1/dsmserv.opt

> cd /opt/tivoli/tsm/server/tsm1

> /opt/tivoli/tsm/server/bin/dsmserv restore db todate=TODAY totime=08:00:00 source=dbbackup preview=no

.... wait some time ....

> tsm-control ha start tsm1

- tsm1 (dsmserv) -> ha: [ OK ]

Nagios: Service Check Timed Out

April 3, 2009June 21, 2013 Christian 6 Comments

Since I got the pleasure of watching some Windows boxen with Nagios, I took the Windows Update plugin from Michal Jankowski and implemented it. It took me some time, to initially set up the nsclient++ correctly so it just works, but up till now the check plugin sometimes reported the usual “Service Check Timed Out”.

Usually I ended up increasing the cscript timeout, or the nsclient++ socket timeout, but it still kept showing up. Since I rely heavily on my surveillance tools, I have the demand, that as few as possible false positives show up. So I ended up chasing down this error today, and after that I have to say it was quite simple.

In my case, it wasn’t cscript (that timeout is set to 300 seconds), neither nsclient++ (socket timeout is set to 300 seconds too), nor the nrpe plugin itself (that has 300 seconds as well).

As it turns out, Nagios got an additional setting controlling these things, called service_check_timeout which defaults to 60 seconds. Sadly the plugin, or rather Windows needs longer than those 60 seconds to figure out whether or not it needs updating, thus Nagios is killing the plugin and returning a CRITICAL message.

After increasing the value of service_check_timeout that’ll be fixed hopefully.

SLES10: zypper.log

April 3, 2009June 21, 2013 Christian Leave a comment

Well, I just stumbled upon something .. My Nagios at work wasn’t working anymore, and I went looking.

nagios3 ~ [0] &gt; tail -f /var/log/nagios/nagios.log
[1238658394] Error: Unable to save status file: No space left on device
[1238658403] Error: Unable to save status file: No space left on device
[1238658413] Error: Unable to save status file: No space left on device
[1238658423] SERVICE ALERT: tsm1;POWER WARN;OK;SOFT;4;-u OK - 0
[1238658423] Error: Unable to save status file: No space left on device
[1238658433] SERVICE ALERT: tsm2;LOAD;WARNING;SOFT;1;WARNING - load average: 6.25, 5.72, 5.36
[1238658433] Error: Unable to save status file: No space left on device
[1238658443] Error: Unable to save status file: No space left on device
[1238658453] Error: Unable to save status file: No space left on device
[1238658463] Error: Unable

nagios3 ~ [0] > tail -f /var/log/nagios/nagios.log

[1238658394] Error: Unable to save status file: No space left on device

[1238658403] Error: Unable to save status file: No space left on device

[1238658413] Error: Unable to save status file: No space left on device

[1238658423] SERVICE ALERT: tsm1;POWER WARN;OK;SOFT;4;-u OK - 0

[1238658423] Error: Unable to save status file: No space left on device

[1238658433] SERVICE ALERT: tsm2;LOAD;WARNING;SOFT;1;WARNING - load average: 6.25, 5.72, 5.36

[1238658433] Error: Unable to save status file: No space left on device

[1238658443] Error: Unable to save status file: No space left on device

[1238658453] Error: Unable to save status file: No space left on device

[1238658463] Error: Unable

After that, zip – nada. Next thing, check whether or not the device is really full … Okay, df ..

nagios3 ~ [130] &gt; df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             3.5G  1.2G  2.1G  37% /
udev                  506M   88K  506M   1% /dev
/dev/sdb1             7.9G  7.7G     0 100% /var

nagios3 ~ [130] > df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda2 3.5G 1.2G 2.1G 37% /

udev 506M 88K 506M 1% /dev

/dev/sdb1 7.9G 7.7G 0 100% /var

So, it is actually completely filled up. So, now we need to find who’s hogging the space. Since I had a assumption (pnp4nagios), I went straight for /var/lib …

nagios3 lib [0] &gt; du -sh *
16K     CAM
1.1M    YaST2
8.0K    acpi
4.0K    apache2
28K     autoinstall
16K     dhcpcd
4.0K    empty
96K     hardware
4.0K    logrotate.status
8.0K    misc
78M     mysql
2.1M    nagios
4.0K    net-snmp
4.0K    news
24K     nfs
8.0K    nobody
36K     ntp
4.0K    pam_devperm
824K    php5
359M    pnp4nagios
22M     rpm
28K     scpm
4.0K    smpppd
4.0K    sshd
4.0K    support
8.0K    suseRegister
4.0K    uniconf
4.0K    update-messages
4.0K    wwwrun
33M     zmd
14M     zypp

nagios3 lib [0] > du -sh *

16K CAM

1.1M YaST2

8.0K acpi

4.0K apache2

28K autoinstall

16K dhcpcd

4.0K empty

96K hardware

4.0K logrotate.status

8.0K misc

78M mysql

2.1M nagios

4.0K net-snmp

4.0K news

24K nfs

8.0K nobody

36K ntp

4.0K pam_devperm

824K php5

359M pnp4nagios

22M rpm

28K scpm

4.0K smpppd

4.0K sshd

4.0K support

8.0K suseRegister

4.0K uniconf

4.0K update-messages

4.0K wwwrun

33M zmd

14M zypp

That wasn’t it .. so heading to the next place, that’s suspicious most of the time, /var/log.

nagios3 log [0] &gt; du -sh *
5.2G    YaST2
4.0K    acpid
1.4G    apache2
28K     boot.msg
28K     boot.omsg
4.0K    cups
4.0K    dsmerror.log
148K    dsmsched.log
4.0K    faillog
4.0K    krb5
12K     lastlog
4.0K    localmessages
16K     mail
16K     mail.info
198M    messages
0       mysqld.log
14M     nagios
0       ntp
4.0K    pnp4nagios
4.0K    sa
8.0K    scpm
4.0K    vmdesched.log
16K     vmware-imc
4.0K    vmware-tools-guestd
82M     warn
348K    wtmp
115M    zmd-backend.log
24M     zmd-messages.log

nagios3 log [0] > du -sh *

5.2G YaST2

4.0K acpid

1.4G apache2

28K boot.msg

28K boot.omsg

4.0K cups

4.0K dsmerror.log

148K dsmsched.log

4.0K faillog

4.0K krb5

12K lastlog

4.0K localmessages

16K mail

16K mail.info

198M messages

0 mysqld.log

14M nagios

0 ntp

4.0K pnp4nagios

4.0K sa

8.0K scpm

4.0K vmdesched.log

16K vmware-imc

4.0K vmware-tools-guestd

82M warn

348K wtmp

115M zmd-backend.log

24M zmd-messages.log

I was like “WTF ? 5.2G for YaST2 logs ?” when I initially saw that output … As of now, I got a crontab emptying /var/log/YaST2 every 24 hours …

Nagios: SNMP OID’s for IBM’s RSA II adapter

April 1, 2009June 21, 2013 Christian Leave a comment

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
}

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

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

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

March 26, 2009June 21, 2013 Christian Leave a comment

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

Source1: ${name}.initd

...

install -o root -g root -m 755 %{S:1} $RPM_BUILD_ROOT/etc/init.d/ndo2db