Gerade für Nagios checks dürften die OIDs für die Abfrage der Stati via SNMP recht interessant sein.
Eine Abfrage als Nagios check könnte dann wie folgt aussehen:

/usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -o .1.3.6.1.4.1.318.1.1.1.2.2.3.0

Folgende Werte kann man unter anderem per SNMP auf folgenden Geräten abfragen:

APC:

Status der Batterie (Integer)
.1.3.6.1.4.1.318.1.1.1.2.1.1.0
Kapazität der Batterie (%)
.1.3.6.1.4.1.318.1.1.1.2.2.1.0
Status über Batterietaus (1:Nicht | 2: Muss)
.1.3.6.1.4.1.318.1.1.1.2.2.4.0
Temperatur der Batterie (°C)
.1.3.6.1.4.1.318.1.1.1.2.2.2.0
Ausgangsspannung (in V)
.1.3.6.1.4.1.318.1.1.1.4.2.1.0
Auslastung der UPS (in %)
.1.3.6.1.4.1.318.1.1.1.4.2.3.0
Spannungseingang (in V)
.1.3.6.1.4.1.318.1.1.1.3.2.1.0
Laufzeit bei Stromausfall
.1.3.6.1.4.1.318.1.1.1.2.2.3.0
Temperatur (°C)
.1.3.6.1.4.1.318.1.1.10.2.3.2.1.4.1

Cisco Geräte:

Load IOS (%)
.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1
Memory (%)
.1.3.6.1.4.1.9.9.48.1.2.1.2.1
Temperatur (Chassy in °C)
.1.3.6.1.4.1.9.9.13.1.3.1.3.1

Dies wären ein paar Beispiele zur Abfrage der entsprechenden Werte per SNMP, um diese im Nagios zu erfassen.

Um Gloobus auf unserem System zu integrieren, werden zuerst weitere Quellen benötigt. Daher müssen folgende zwei Quellen hinzugefügt werden:

#Key apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 9E5DB0C8

deb http://ppa.launchpad.net/ricotz/testing/ubuntu karmic main
deb-src http://ppa.launchpad.net/ricotz/testing/ubuntu karmic main

Danach werden folgende Pakete installiert (clutter, clutter-gtk and gnomeui):

apt-get install libclutter-gtk-0.10-dev libclutter-1.0-dev libgnomeui-dev

Danach kann Gloobus Flow installiert werden:

cd
bzr branch lp:gloobus-flow
cd gloobus-flow
./configure –prefix=/usr
make
make install
apt-get build-dep nautilus
cd
bzr branch lp:~gloobus-dev/gloobus-flow/nautilus-clutter-gtklist
cd nautilus-clutter-gtklist
./autogen.sh –prefix=/usr
make
make install

Danach kann Nautilus neugestartet werden.

Irgendwie ist das Thema damals unter gegangen und die Lösung hatte ich nicht mehr geposted. Ziel war es auf einem Server den entsprechenden virtuellen Environments mit OpenVZ das IPv6 Protokoll mit einer nativen Adresse zur Verfügung zu stellen. Als Netz diente 2001:41D0:2:3941::/64. Erstmal musste dazu der Kernel neugebaut werden und mit den entsprechenden IPv6, SAN Storage Treibern, OpenVZ Patches & Co kompiliert werden. Als Basis diente der 2.6.27er Vanilla Kernel mit dem 2.6.27-aivazovsky.1 OpenVZ Patch aus dem Developement branch. Danach lässt es sich auch schon fast wie unter IPv4 vorgehen…

Folgende Änderungen müssen noch gemacht werden:

# sysctl.conf / Pakete für IPv6 forwarden
net.ipv6.conf.all.forwarding = 1

# /etc/vz/vz.conf / IPv6 für VEs und IP6Table Module aktivieren
IPV6=”yes”
IP6TABLES=”ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT”

# VE-ID eine IPv6 Adresse zuweisen
vzctl set 101 –ipadd 2001:41d0:2:3941::3 –save

# Auf dem Hostnode die entsprechenden Routen setzen
route -A inet6 add 2001:41D0:2:3900::/56 dev eth0
route -A inet6 add 2000::/3 gw 2001:41D0:2:39FF:FF:FF:FF:FF dev eth0

# IPv6 Proxy NPDs für jede VE hinzufügen da sonst keine Verbindung hergestellt werden kann
echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
ip -6 neigh add proxy 2001:41d0:2:2705::2 dev venet0

Danach haben auch die VEs eine eigene, native IPv6 Adresse und können als Feature bei Hostern entsprechend vermarktet werden.