Dienstag, 25. September 2012

Recheck eines Nagioschecks

So, meine 2 Wochen Urlaub sind rum. Also vielleicht auch mal wieder Zeit was zu schreiben. Heute morgen bin ich über ein altes Skript gestolpert welches für einen kleinen Post genau das Richtige zu sein scheint.

Wir checken zB den Debian Paketstatus einmal am Tag. Kommen jetzt über Nacht ganz viele dieser Updates, so haben wir für 24 Stunden ein schönes rotes Nagios. Also macht man Updates und rechecked den Service, alleine schon wegen der Übersicht. Aber muss man das von Hand machen? Nö!

#!/bin/bash
# kickrecheck.sh 
# by j AT xadmin DOT info

if [ -z "$1" ];
then
echo "Please tell me which check to kick by usage: sh kickrecheck.sh <service>"
else
for host in `grep 'host_name=' /var/nagios/rw/status.dat | cut -f 2 -d "=" | sort | uniq`
do
/usr/bin/printf "[%lu] SCHEDULE_SVC_CHECK;${host};$1;1110741500\n" `date +%s` > /var/nagios/rw/nagios.cmd
done
fi

Der einfache Aufruf sh kickrecheck.sh apt sorgt nun dafür das alle apt services auf jedem Server neu gechecked werden.

Geht natürlich auch mit anderen :-)
UPDATE!:

Was Squeeze da anscheinend ein wenig anders macht
nagiosserver ~ # locate status.dat
/var/cache/nagios3/status.dat
nagiosserver ~ # locate nagios.cmd
/var/lib/nagios3/rw/nagios.cmd
Also
#!/bin/bash
# by j AT xadmin DOT info

if [ -z "$1" ];
then
echo "Please tell me which check to kick by usage: sh kickrecheck.sh <service>"
else
for host in `grep 'host_name=' /var/cache/nagios3/status.dat | cut -f 2 -d "=" | sort | uniq`
do
/usr/bin/printf "[%lu] SCHEDULE_SVC_CHECK;${host};$1;1110741500\n" `date +%s` > /var/lib/nagios3/rw/nagios.cmd
done
fi

(Nagios) SMS senden via sms4.de

(Nagios) SMS senden via sms4.de
Ich hätte da mal wieder eine Howto von gestern
Auf dieser Seite:
http://sms4.de
sendsms4.py

es kann ja mal vorkommen das es wichtige Ereignisse in der Infrastruktur gibt welche uns zwar von Nagios gemeldet werden aber wir sind im Wochenende oder ähnliches. Handelt es sich hierbei Aber zb um das Mailgate oder die Klimaanlange interessiert es uns ja bestimmt doch.

Einfache Lösung!?! Einfach per sms benachrichtigen.

Mit einem Anbieter wie http://sms4.de geht es hierbei wohl am einfachsten. Aber der Reihe nach.

Schritt 1
Einen Kontakt anlegen.
Hierzu legt man eine datei contacts.cfg an und in dieser einen Kontakt. Der Einfachheit halber und damit man Kontakte unterscheiden kann lege ich zu jedem User der eine SMS bekommen will in der Datei contacts-sms.cfg einen sms Kontakt an.

define contact{
contact_name Testuser-sms
alias Ein test user
service_notification_period 24x7
host_notification_period 24x7
service_notification_options u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-sms
host_notification_commands host-notify-by-sms
pager 49123456789
}
Für üns interessant ist hierbei die Angabe Pager, hier lässt sich nun eine Handynummer eintragen.
Wichtig! ist auch das der Eintrag der notification richtig gesetzt ist.

Schritt 2
Ein Befehlsskript findet man unter sendsms4.py welches ich in python geschrieben habe. Nun muss man diesen Befehl noch in Nagios anlegen.
Eine Datei misccommands.cfg enthält das script

define command{
command_name notify-by-sms
command_line /usr/local/bin/sendsms4.py $CONTACTPAGER$ "$NOTIFICATIONTYPE$: $HOSTNAME$: $SERVICEDESC$ is $SERVICESTATE$ ($SERVICEOUTPUT$)"
}

Somit ist nun möglich das ganze Abzuschicken.

Schritt 3
Nun müssen wir noch einmal alles verheiraten. Hierzu habe ich in der Datei contactgroups.cfg Eine Gruppe für die neuen sms Kontakte angelegt. Nun wird bei jedem Service, die notification auf unserer sms gruppe gesetzt. Hier die linux-admins-sms

define service{
host_name linux-server
service_description check-disk-sda1
check_command check-disk!/dev/sda1
max_check_attempts 5
normal_check_interval 5
retry_check_interval 3
check_period 24x7
notification_interval 30
notification_period 24x7
notification_options w,c,r
contact_groups linux-admins-sms
}

Und das War es auch schon!

Skript Nachtrag

damit mein Python Skript auch richtig funktioniert gibt es ein paar Sachen zu beachten.

1 Die Konfiguration bzgl der Zugangsdaten findet im Skript statt, also einfach Ihre Accountemail nehmen und dann die Daten einfügen.

2 Es gibt eine log Datei. Diese muss aber von Hand angelegt und frei gegeben werden. Natürlich ist der Pfad der Datei auch im Quelltext editierbar. Per default sollten sie so vorgehen


echo '' > /var/log/sendsms4.log

chmod 777 /var/log/sendsms4.log

Donnerstag, 13. September 2012

Job of the (to)day

Today i had a lot of fun (!!!!)

I worked with Nginx to establish a fill working redirect and proxy server. There are customers which like the idea of having multiple domains pointing to the same webserver. There are several ways to do this. Mostly used is apache with reddirets or proxy settings. The real way to do it in my eyes is nginx.

So what do you need, lets take a look at basic 301 redirects
server {
server_name test.xadmin.info;
reweite ^ http://example.com;
}

adding this to your default.conf of nginx sets redirecting from test.xadmin.info to example.com. quite easy(!).

UPDATE:
In addition to above you can do "hidden" redirects which dont show the url you refer to. I used to do that via proxy_pass

server {
server_name xadmin.info;
location / {
proxy_pass http://www.example.com;
proxy_redirect off;
proxy_set_header Host www.example.com;
}
}

The above code does that. So any connection to xadmin.info goes directly to www.example.com whitout changing the url bar in your browser.
proxy_set_header Host www.example.com;

Passes the refer url to the other webserver. This is needed if on example.com would run more then one Apache (lighty , whatever) instances. Not passing the Host would let to using the default host on the other side.

Montag, 10. September 2012

Finally it works... Canyon Edge view_ Mageia

on the weekend i gave a try to Mageia.

It took a while to set it up, mainly caused by graphic issues. My Nvidia 7200 GS isnt that well supported by the shipped moveau driver. And setting up the mageia box is a bit tricky if you dont have an x windows to set your wifi and such things. But some guys on the mageia forum pointed me in the right direction. Comming from openSUSE it is quite different.

Mageia vs. openSUSE

  • zypper VS rpmi and drake
    installing the Software works fine on X window, there is a "great mageia control center", trying using the console leads to urpmX where X could be i for install, e for erase anf f for find (i guess)

  • SUSEFirewall VS shorewall
    i was really happy to se that mageia have a setup and running firewall right after install


in addition, i first tried gnome, which sucks, really. I dont like it, and it died right after reboot, giving me everything twice, logout button, starting button, everything. KDE looks very good and was easy to install using just one meta package. Yes openSUSE also has this meta packages, but last time i failed using it :-)

I dont know how long i will use it... we will see!

Bacula und Nagios

Bacula und Nagios
Wenn man eine Monitoring Lösung wie Nagios am Start hat, dann möchte man Zwangsläufig das die Backuplösung sich hier integriert. Wenn man dann sich umschaut, findet man einiges an HowTo Lösungen, die irgendwie alle nicht so recht wollten.
Ich habe mich jetzt mal einen Tag mit der Problematik befasst und fasse mal zusammen was man tun muss...

Schritt 1: PASSIV CHECK
Bacula soll nach beendetem Job uns eine Information geben was mit dem Job passiert ist, hierzu erstellen wir einen Passivcheck innerhalb von Nagios, dieser könnte so aussehen
define service {
hostgroup_name bacula
service_description bacula-fd
use generic-service
check_command check_dummy_crit
max_check_attempts 1
check_interval 1440
retry_interval 1440
check_period workhours
notifications_enabled 0
register 1
}

check_dummy_crit ist hierbei das check_dummy script, welches immer critical ist, es sei denn es wird, in unserem Fall von Bacula, auf critical gesetzt.

Schritt 2: Bacula2Nagios
Wir brauchen für Nagios ein Script, dieses soll dafür sorgen das die Information von Bacula an nagios übermittelt wird. Hierbei müssen wir beachten, dass dieses Script nur auf dem Director liegen muss!
Denn, wir werden später die Funktion RUN AFTER JOB benutzen, ich musste auch lange recherchieren bis mir auffiel das der Director diesen Aufruf macht und nicht der Client :-)
Unser Script sieht dann so aus:
#!/bin/bash
# Bacula2Nagios V1
#/usr/bacula2nagios.sh
# args:
# $1: Job name
# $2: Status (0:OK)
# $3: Plugin Output
if [ $2 -eq 0 ]
then status=0
else status=2
fi


/bin/echo "$1;bacula-fd;$status;$3" | /usr/sbin/send_nsca -d ';' -c /etc/nagios/send_nsca.cfg -H

MAN BEACHTE!: Es ist hierfür wichtig das der "Job name" auich gleich dem Hostname in Nagios ist.

Schritt 3: RUN AFTER JOB
Nun fügen wir in jede JobDefs folgende beiden Zeilen ein

Run After Job = "sh /usr/lib/nagios/plugins/bacula2nagios.sh \"%n\" 0 \"%e %l %v\""
Run After Failed Job = "sh /usr/lib/nagios/plugins/bacula2nagios.sh \"%n\" 1 \"%e %l %v\""

Hierbei ist
%n : der Jobname
0/1: der Nagios Wert 0: OK 1: CRIT
%e der Job exit status
%l der job level
%v das Zielvolume
Requirements:
Nagios
Bacula
NSCA
bash und vi:-)
Viel Spass damit

Donnerstag, 6. September 2012

openSUSE 12.2 is out now & Event

So finally after some delay it is done, and 12.2 is ready!

To be honest i did not test it currently, i had some issues with rhe RC2 so i guess i will wait a day or two. So i gone post my experience the next week, if you want to know some details take a look at:

Or get your own copy

And if you want to talk about openSUSE 12.2 there will be


http://www.it-tag-saarland.de/


on 21. September 2012


at Saarbrücken


Andreas will be there an show a fresh install of openSUSE 12.2 at the OpenSaar e.V. booth. Maybe after my work i will show up to.

Dienstag, 4. September 2012

Roundcube am limit

Letztens ist es passiert das Roundcube auf einem unserer Rechner am Limit war.



Soll heissen das die Ausgabe von top eine Wait von 85% zeigte, und damit einhergehend natürlich auch Loginzeiten (bzw auch Seitenaufbauzeiten) jenseits der 1 Minute Grenze.


Der erste Lösungsansatz schlug leider fehl. Dieser bestand darin den Apache Server und den MySQL Server neuzustarten. Doch wie gesagt, dies führte zu einer Verbesserung für gerade mal 3 Minuten. Bevor die Wait auch hier wieder über einen Wert von 60% ging.
Allgemein sollte man vielleicht wissen das Wait zumeist mit Festplatten zugriffen zusammenhängt, also ein Prozess würde zwar gerne etwas tun, muss jedoch auf die I/O warten.

Also, da Roundcube primär auf MySQL basiert, bzw diese Datenbank als Backend nutzt, fand sich hier auch ein besserer Lösungsansatz und zwar über das löschen/leeren einer Roundcube Tabelle in Mysql.
Hierzu betrachtet ich mir die Zugriffe in MySQL selbst und fand schnell heraus das Roundcube mittels einer Tabelle eine Art Cache simuliert.Die Lösung und Vorgehensweise:



  • mysql -p



Dann natürlich das login in die Datenbank als root mit Passwort.



  • use roundcube;

  • select count(*) from cache;



Dies brachte einen Wert jenseits von 160.000 zurück.



  • truncate cache;

  • quit;



Die führte dazu das es ziemlich genau 3 Monate sehr gut lief, bis der Speicher auch hier wieder voll war.

Samstag, 1. September 2012

Schnelle Hilfe mit IPTABLES

Eines in meinen Augen beste und schnellste Tool wenn es um einen Schuz des eigenen Systems geht ist Iptables, die seit Kernel 2.4.x integrierte Firewall. http://de.wikipedia.org/wiki/Iptables. Natürlich gibt es hierzu mehr Howtos als man alleine lesen kann. Trotzdem möchte ich die IPtables noch einmal kurz beleuchten, da ich sie im täglichen Geschäft immer mal wieder brauche.

So habe ich in meinem Dokumenten Ordner eine Datei die nennt sich "iptables_fastuse.txt" hier befindet sich eigentlich nur eine kleine Übersicht über verschiedene Regeln die ich schonmal gebraucht habe, mit einer kleinen erläuterung was diese einegtlich tun (ich vergesse das nämlich dauernd).

Der Erste aufruf in meiner liste

iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP wie sich ebstimmt vermuten lässt, erstellt diese eine Regel welche jeden reinkommenden Traffic (INPUT) von einer gewissen Adresse (-s xxx.xxx.xxx.xxx) nicht an (DROP). Hierbei steht das -A für Append, also die Regel wird am Ende der "regelnliste" angestellt.

Wie sich also zeigt ist der Aufbau der iptables sehr einfach gehalten. Wir unterscheiden also eigentlich auf der einen Seite

INPUT
OUTPUT

hierbei gilt natürlich auch die Unterschiede zwischen -A -I -D zu beachten.
-A fügt die regel hinten an die Liste an
-I fügt die regel vorne in die Liste ein
-D löscht die passende Regel wieder aus der Liste

und auf der -j Seite (Also der "Was tun wir damit")

ACCEPT
REJECT
RETURN
DROP

Zunächst noch ein/zwei ganz wichtigen Hinweisen. Die Regeln der iptables werden von oben nach unten durchgegangen, also die erste Regel vor der Zweiten und so weiter. Somit muss man etwas aufpassen, wenn das System eine Default auf ACCEPT hat, dann muss man Verbindungen verbieten, ist die default ein DROP so kann man dies natürlich mit ACCEPT steueren.
In den folgenden Regeln gehen wir von einem default auf ACCEPT aus.

Löschen der ganzen Regeln geht einfach mit iptables -F, dan ansehen der Regeln via iptables -L.

Kommen wir nun also zu ein paar anderen Regeln, die man etwas besser benutzen kann, und ich denke das sie ein paar Feinheiten von iptables aufzeigen die man täglich benutzen kann.

iptables -A INPUT -p tcp --syn --dport <<PORT>> -m connlimit --connlimit-above <<ANZAHL>> -j REJECT --reject-with tcp-reset 
Dies ist ein sehr schöner Befehl, mit Hilfe von connlimit sperren wir den gleichzeitigen Zugriff von einer IP auf unseren PORT sobald diese über ANZAHL hinaus gehen, sehr schön um zB Kundenzugriffe auf Datenbanken einzuschränken

Dann erwähnen wir im gleichen Atemzug natürlich auch noch

iptables -A INPUT -p tcp -m limit --limit 1/s --limit-burst 3 -j RETURN 
Der Limit Funktion, anders als der connlimit, ist es egal von welcher IP die Zugriffe kommen sie sorgt eibfach dafür das in diesem Fall nur 1 Zugriff pro sekunde über tcp möglich ist. Diese Kommando lässt sich auch mit --dport PORT erweitern, um also einen Zugriff auf diesen Port zu beschränken

Es hat sich auch bewährt das ganze als Log zu schreiben, da man ja nachvollziehen möchte wen man so rausgeschmissen hat, folgender Eintrag vor dem eigentlichen Eintrag (z.B. einer der Erste) sorgt dafür das dies als zeile in /var/log/kern.log gespeichert wird

iptables -A INPUT -p tcp --syn --dport <<PORT>> -m connlimit --connlimit-above <<ANZAHL>> -j LOG man beachte also das für das REJECT ein LOG benutzt wird, also wird es in diesem Falle nur gelogt, die eigentliche Verbindung funktioniert aber trotzdem. Deshalb muss auch dieser Eintrag _vor_ dem Reject stehen, da ansonsten die Verbindung unterbrochen wird und kein LOG gschrieben wird.