Autor: kero

Centreon 2.2.0 und Nagios 3.06

kero Schreib einen Kommentar

Nach dem Update auf Centreon 2.2.0 lieferte Nagios beim generieren der Konfigurationsdateien

Error in configuration file ‚/usr/local/centreon/filesGeneration/nagiosCFG/1/nagiosCFG.DEBUG‘ – Line 91 (UNKNOWN VARIABLE)

Grund war die Variable check_for_updates, die von Centreon gesetzt wird aber meinem Nagios noch nicht bekannt ist (wohl erst ab 3.1.0). Die Variable kann nicht im Centreon Webinterface gesetzt werden, sondern steht hardcoded in der Datei (variiert je nach Installation)

/usr/local/centreon/www/include/configuration/configGenerate/genMainFile.php

Dort einfach am Ende der Datei die  Zeilen

if (isset($tab['monitoring_engine']) && $tab['monitoring_engine'] == "NAGIOS") {
$str .= "check_for_updates=0\n";
}

auskommentieren und schon sollte wieder alles funktionieren.

update:
also doch apt-get install dpkg aptitude apt && apt-get dist-upgrade
und mitten beim Updaten verlaesst uns eine der beiden Raid-1 Systemplatten und man denkt natuerlich egal macht ja alles der Raidcontroller…einen Scheiss macht der.
Also hard reset und weitermachen…

Tag 0

kero Ein Kommentar

So im Linuxhotel angekommen…Zimmer anders als erwartet, Anlage wird morgen angeschaut. Wlan ist auf jeden Fall bei mir im Zimmer an der unteren Grenze. Da sind wir mal gespannt was die naechsten Tage so bringen.

TSM 5er Client und ext4

kero Schreib einen Kommentar

Der TSM 5er Client unterstuetzt offiziell kein ext4 als FS. Abhilfe schafft das Definieren von Virtualmountpoints in der dsm.sys:

VIRTUALMOUNTPOINT /
VIRTUALMOUNTPOINT /home

Der 6er Client soll es koennen, habe ich aber nicht im Einsatz. Am besten testen ob Daten auch restored werden koennen und diese wie gewunescht aussehen.

KVM- und XEN-VMs untereinander erreichbar

kero Schreib einen Kommentar

Ich wechsle zur Zeit von XEN zu KVM. Das ganze System verteilt sich ueber 4 Rechner. 3xKVM und 1xXEN. Jeder Host beherbergt 3-4 virtuelle Maschinen. Die VMs nutzen alle NAT im 192.168er Netz. Nun war es bei XEN kein Problem, dass sich die VMs ueber die Hostgrenzen hinweg erreichen konnten. XEN1-VM1 konnte also ohne Umwege  auf XEN2-VM1 zugreifen. Das vereinfacht natuerlich sehr viele Dinge (Mysql Replikation, failover und und und). Noetig war quasi nur ein

ip route add XEN2-VM1 via XEN2 dev eth0?

auf XEN1, damit von den XEN1-VMs auf die XEN2-VM1 zugegriffen werden konnte.  Entweder fuer jede VM einzeln oder fuer das ganze Netz eintragen, falls moeglich.

Nun kam KVM ins Spiel. Bei KVM konnte ich problemlos noch von XEN1-VM1 auf KVM-VM1 zugreifen. Umgekehrt, also von KVM-VM1 auf XEN1-VM1 funktionierte nicht. Abhilfe schaffte

?for i in /proc/sys/net/ipv4/conf/*/proxy_arp
do
echo 1 >>$i
done

Kann man natuerlich  auf die noetigen Interface begrenzen. Bei XEN war proxy_arp bereits aktiviert, daher gab es dort keine Probleme.

KVM image file vergroessern

kero Schreib einen Kommentar

1.?

cd /meine/images/
???truncate --size=+10G mein.img
virsh pool-refresh poolname

2. Dort http://gparted.sourceforge.net/download.php runterladen
3. Via virt-manager (oder Konsole) die VM von der CD starten
4. Mit gparted solange rumfrickeln bis man zufrieden ist (und ja Partitionen zu verschieben, die durch andere Partionen begrenzt sind bzw. durch Anfags- und Endsektor , ist nicht moeglich)
5. Das gparted iso wieder auswerfen und die VM von HD booten lassen
6. fertig

Das ist bei XEN ein bisschen schicker, aber darueber habe ich  irgendwann schon mal was geschrieben. Nutzt man LVM sieht das natuerlich alles anders aus. Auf jeden Fall sollte man vorher die Maschine zur Sicherheit klonen.

Als naechstes bauen wir uns einen KVM Cluster.