SLES10 – Page 2

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 …

TSM client: Backing up files with umlauts on SLES

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

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] &gt; env | grep ^LC
LC_CTYPE=de_DE.UTF-8

1 2	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] &gt; LC_CTYPE=&quot;en_US&quot; dsmc incr

1	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=&quot;de_DE@euro&quot;
export LC_CTYPE=&quot;$lang&quot;
export LANG=&quot;$lang&quot;
export LC_ALL=&quot;$lang&quot;

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 …

Installing SLES10 via network with no DHCP available

January 30, 2009August 8, 2014 Christian Leave a comment

In our current fight against the BladeCenter switches, we’re currently facing the problem that the blades ain’t able to send/receive DHCP-traffic.

So in order to move forward, we had to use static IP addresses. And since SLES10 ain’t straight forward on that, I had to look it up. Now, here’s for me (and everyone else tired of searching) how to do it:

install=http://ftp.barfoo.org/install/SLES10-x64/CD1
  netdevice=eth0
  hostip=10.0.1.240
  netmask=255.255.255.0
  gateway=10.0.1.1
  nameserver=10.0.1.2
  domain=home.barfoo.org
  insmod=bnx2
  splash=verbose

install=http://ftp.barfoo.org/install/SLES10-x64/CD1

netdevice=eth0

hostip=10.0.1.240

netmask=255.255.255.0

gateway=10.0.1.1

nameserver=10.0.1.2

domain=home.barfoo.org

insmod=bnx2

splash=verbose

Automatic updates on SUSE Linux Enterprise 10

January 23, 2009June 21, 2013 Christian Leave a comment

I had the problem, that the automatic update function of YaST doesn’t work like I want it to. I just wanted it to install only those updates, that ain’t interactive, don’t need a service restart and don’t need a reboot.

YaST does only feature an online update that skips “interactive” updates (I’ve never even encountered an interactive update up till now). So I went ahead and wrote a (hackish) script, that achieves what I need.

#!/bin/bash

TMPDIR=&quot;$( mktemp -d /tmp/autoupdate-XXXXXX )&quot;

# Wake up rug
rug --quiet ping -a

# Get the patchlist from rug
rug --terse pch -u | grep &quot;|Needed&quot; | cut -d| -f2 | 
  sed -e &quot;s,sdkp2-,,&quot; -e &quot;s,slesp2-,,&quot; | 
  sort -u &gt; $TMPDIR/patch-list

for package in $( &lt; $TMPDIR/patch-list ); do
  # Get the patch-details
  rug --terse patch-info slesp2-$package &gt; $TMPDIR/patch-details

  # Parse those patch-details for &quot;unwanted&quot; interactions
  is_interactive=&quot;$( cat $TMPDIR/patch-details | 
    grep &quot;^Interactive:&quot; | cut -d &quot; &quot; -f2 )&quot;
  needs_restart=&quot;$( cat $TMPDIR/patch-details | 
    grep &quot;^Restart Required:&quot; | cut -d &quot; &quot; -f3 )&quot;
  needs_reboot=&quot;$( cat $TMPDIR/patch-details | 
    grep &quot;^Reboot Required:&quot; | cut -d &quot; &quot; -f3 )&quot;

  if [ &quot;$is_interactive&quot; == &quot;No&quot; -a &quot;$needs_restart&quot; == &quot;No&quot; 
      -a &quot;$needs_reboot&quot; == &quot;No&quot; ] ; then
    tmp_package=&quot;$( cat $TMPDIR/patch-details | grep ^atom | cut -d  -f2 |
      sed &#039;:a;N;$!ba;s/n/ /g&#039; )&quot;
    for i in $tmp_package; do
      RPM_STATUS=$( rpm -qi $i )
      if [ &quot;$RPM_STATUS&quot; != &quot;package $i is not installed&quot; -a 
        &quot;$( rug --terse lu | cut -d| -f4 | grep &quot;$i$&quot; )&quot; ] ; then
        patch_list=&quot;$patch_list $i&quot;
      fi
    done
  fi
done

rug --quiet install --no-confirm $patch_list

rug --quiet clean-cache

trap &quot;rm -rf &quot;$TMPDIR&quot; &gt;/dev/null 2&gt;&amp;1&quot; ERR EXIT INT TERM HUP
# vim: set tw=80 ts=2 sw=2 et softtabstop=2

#!/bin/bash

TMPDIR="$( mktemp -d /tmp/autoupdate-XXXXXX )"

# Wake up rug

rug --quiet ping -a

# Get the patchlist from rug

sed -e "s,sdkp2-,," -e "s,slesp2-,," |

sort -u > $TMPDIR/patch-list

for package in $( < $TMPDIR/patch-list ); do

# Get the patch-details

rug --terse patch-info slesp2-$package > $TMPDIR/patch-details

# Parse those patch-details for "unwanted" interactions

is_interactive="$( cat $TMPDIR/patch-details |

grep "^Interactive:" | cut -d " " -f2 )"

needs_restart="$( cat $TMPDIR/patch-details |

grep "^Restart Required:" | cut -d " " -f3 )"

needs_reboot="$( cat $TMPDIR/patch-details |

grep "^Reboot Required:" | cut -d " " -f3 )"

if [ "$is_interactive" == "No" -a "$needs_restart" == "No"

-a "$needs_reboot" == "No" ] ; then

tmp_package="$( cat $TMPDIR/patch-details | grep ^atom | cut -d -f2 |

sed ':a;N;$!ba;s/n/ /g' )"

for i in $tmp_package; do

RPM_STATUS=$( rpm -qi $i )

if [ "$RPM_STATUS" != "package $i is not installed" -a

"$( rug --terse lu | cut -d| -f4 | grep "$i$" )" ] ; then

patch_list="$patch_list $i"

done

rug --quiet install --no-confirm $patch_list

rug --quiet clean-cache

trap "rm -rf "$TMPDIR" >/dev/null 2>&1" ERR EXIT INT TERM HUP

# vim: set tw=80 ts=2 sw=2 et softtabstop=2

And just for me, the crontag entry:

30 22 * * *     root  /usr/local/sbin/autoupdate

1	30 22 * * * root /usr/local/sbin/autoupdate

Opsview installation reviewed

January 21, 2009August 8, 2014 Christian 2 Comments

Well, I recently (well, yesterday) built the opsview RPM’s for SLES10, and started fiddeling about with it today. Alex “recommended” I should rather look at Opsview instead of Centreon, but boy was there a surprise waiting for me …

Opsview has the advantage that it at least lets you use the package manager. But, it also needs *a lot* of handy work (just like Centreon, which I really dislike since it’s real error prone).

I started doing the setup, but gave up halfway through … ❗ Dude, and they expect people to pay money for training ?!?

I mean, come on .. you can do a better job at making this thing fit a bit better into the system, and even make the install a bit more straight forward.

Building opsview for SUSE Linux Enterprise 10

January 21, 2009January 21, 2009 Christian 1 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 …

Well, I just looked at opsview again (haha, thanks Alex :-P). Only trouble is, the people over at opsview don’t distribute RPM’s for that … After registering for their site, to download the SRPM’s (or to download anything), I got the RPM’s and started looking at them.

Well, the only things I needed to adjust in opsview-base, opsview-core and opsview-perl were the dependencies. I also needed to rebuild a RPM for perl-Version from Dag Wieers, since opsview-perl required them to even build.

opsview 2.14.1 (build 1695-1)
- opsview-agent (i586, x86_64)
- opsview-base (i586, x86_64)
- opsview-core (noarch)
- opsview-perl (i586, x86_64)
- opsview-reports (noarch)
- opsview-slave (i586, x86_64)
- opsview-web (noarch)
opsview 3.0.0 (beta, build 1895-1)
- opsview-agent (i586, x86_64)
- opsview-base (i586, x86_64)
- opsview-core (noarch)
- opsview-perl (i586, x86_64)
- opsview-reports (noarch)
- opsview-slave (noarch)
- opsview-web (noarch)

Installation order is like this:

opsview-base
opsview-perl
opsview-web
opsview-core
opsview-reports

If you are looking for older versions, try the respective directory on distributions.barfoo.org (for example i586 for SLES10).

If you encounter a missing link (either ~~striked~~ or just missing), please note that older builds aren’t available anymore.

Trusted vendors in SUSE Linux Enteprise 10

January 19, 2009June 21, 2013 Christian Leave a comment

The other day I had a closer look at the zypper logs (well, I was digging for a time-history of installed packages). First … damn does zypper produce a *lot* of logs on a “productive” (or rather on a maintained – as in up-to-date) system.

But glazing over the logs, I found out something new about zypper. It actually has an internal list, which only purpose is to identify a trusted vendor …

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 Trusted Vendors: {
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   ati technologies inc.
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   jpackage project
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   novell
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   nvidia
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   opensuse
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   sgi
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   silicon graphics
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128   suse
[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 }

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 Trusted Vendors: {

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 ati technologies inc.

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 jpackage project

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 novell

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 nvidia

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 opensuse

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 sgi

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 silicon graphics

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 suse

[zypp::VendorAttr] VendorAttr.cc(VendorAttr):128 }

As you can see from the log, the list of trusted vendors is:

ati technologies inc.
jpackage project
novell
nvidia
opensuse
sgi
silicon graphics
suse

Automating zypper updates

January 17, 2009June 21, 2013 Christian Leave a comment

Well, I just looked into using zypper up to update some of our boxen (I do have a script, which holds the boxen it needs to process in a variable and simply goes through them one by one) — yes, I could activate auto-update, I just don’t want that at this point 😉

So at first I tried just using zypper to automatically update that given list, but even if you pass –no-confirm, zypper would still ask for your confirmation (which seems kinda stupid). After a short while thinking about it, a lesson from solar@gentoo.org came to mind. When working in a chroot, he simply used this:

echo -5 | etc-update

1	echo -5 \| etc-update

And analog to that, I simply tried this:

echo y | zypper up

1	echo y \| zypper up

And guess what: it worked 😉

Distribution running on IBM TS7530 Virtualization Engine

January 9, 2009June 21, 2013 Christian Leave a comment

Well, I was just a bit curious earlier what distribution might be running on our IBM TS7530 Virtualization engines .. well, I just had a look-see ..

vetapeservice@VTL-B:~&gt; cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL=1

vetapeservice@VTL-B:~&gt; uname -a
Linux VTL 2.6.16.46-229-smp #1 Sun Apr 13 05:21:49 UTC 2008 x86_64 GNU/Linux

vetapeservice@VTL-B:~&gt; free -m
             total       used       free     shared    buffers     cached
Mem:          4022       1378       2643          0        342        552
-/+ buffers/cache:        484       3537
Swap:         3815          0       3815

vetapeservice@VTL-B:~&gt; cat /proc/cpuinfo
processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 65
model name      : Dual-Core AMD Opteron(tm) Processor 8218
stepping        : 3
cpu MHz         : 2600.186
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2

vetapeservice@VTL-B:~> cat /etc/SuSE-release

SUSE Linux Enterprise Server 10 (x86_64)

VERSION = 10

PATCHLEVEL=1

vetapeservice@VTL-B:~> uname -a

Linux VTL 2.6.16.46-229-smp #1 Sun Apr 13 05:21:49 UTC 2008 x86_64 GNU/Linux

vetapeservice@VTL-B:~> free -m

total used free shared buffers cached

Mem: 4022 1378 2643 0 342 552

-/+ buffers/cache: 484 3537

Swap: 3815 0 3815

vetapeservice@VTL-B:~> cat /proc/cpuinfo

processor : 1

vendor_id : AuthenticAMD

cpu family : 15

model : 65

model name : Dual-Core AMD Opteron(tm) Processor 8218

stepping : 3

cpu MHz : 2600.186

cache size : 1024 KB

physical id : 0

siblings : 2

core id : 1

cpu cores : 2

Main difference to a “normal” SUSE Linux Enterprise Server 10 installation (there’s about zip normal with that kind of installation, thus the quotes) thus far are:

the build for the VE uses busybox as init
IBM stripped man/info
they are running Xorg/Fluxbox on it

Just don’t ask me why there’s a DE (desktop environment) running, it ain’t even hooked up to a monitor. Only reason would be for the RSA’ remote monitor stuff … *lala*

Adapter bonding on Linux

October 16, 2008June 21, 2013 Christian Leave a comment

Well, today I had a rather weird error. I was testing the adapter bonding on one of the boxen designated as Tivoli Storage Manager Server, when I noticed that the bonding wasn’t working as expected when simulating an error (that is unplugging one of the TP cables for the bond).

Now, the bond had “mode=6 miimon=100” as options. After running “linux bond debug” through Google (which turned up nothing useful, besides one document on the Oracle Wiki about IOS/Linux adapter teaming), I figured “Hey, just lets test switching the arguments.” And guess what ?

Afterwards, it just works when you unplug one of the cables of the bond, while it didn’t work before … *shrug*