Vor einiger Zeit bin ich auf die Gnome 3 Shell umgestiegen und habe dort einige Extensions installiert die ich auf meinem Laptop total praktisch finde. Die wichtigsten hier zur persönlichen Dokumentation festgehalten:
Schlagwort: shell
HowTo: Zertifikatsdatei .crt direkt mit Nagios ueberwachen
Bei einem OpenVPN Server besteht das Problem, das sein Zertifikat nicht aktiv von aussen ueberprueft werden kann. Um es dennoch mit Nagios zu ueberwachen muss die .crt Datei auf dem Server direkt ueberprueft und die Informationen zum Nagios Server gepusht werden.
Ich habe das mit dem Shellskript ssl-cert-check (mirror v. 3.27) von prefetch.net geloest.
Das Skript habe ich unter /usr/local/bin/ abgelegt:
cd /usr/local/bin wget http://prefetch.net/code/ssl-cert-check |
Dann gibt es ein Mini-Skript unter /root/skripte/nagios/check_openvpncert.sh, dass das ssl-cert-check Skript aufruft, und die Rueckgabe per NSCA an den Nagios Server pusht:
#!/bin/bash send_nsca=/usr/sbin/send_nsca send_nsca_cfg=/etc/send_nsca.cfg nagioshost=nagios.example.org host=$1 service=$2 plugin=/usr/local/bin/ssl-cert-check output=$($plugin -n -x 30 -c /etc/ssl/certs/openvpn.example.org.crt) rc=$? echo -e "$hostt$servicet$rct$output" | $send_nsca -H $nagioshost -to 30 -c $send_nsca_cfg exit 0 |
Das Mini-Skript selbst wird regelmaessig mit cron aus der /etc/cron.d/nagios-passive aufgerufen:
LANG=C # # Regular cron jobs for nagios passive checks # HOST=openvpn.example.org */20 * * * * root /root/skripte/nagios/check_openvpncert.sh ${HOST} SSL-Cert_OpenVPN 1>> /dev/null 2>> /dev/null |
Und nach der Einbindung als passive Check in Nagios wird auch das Ablaufdatum eines lokalen Zertifikats ueberprueft:
Remote Kommandos auf Server via xinetd ausfuehren / Adminfun
Es gibt Sachen die machen Spass, z.B. diese Spielerei. Es geht darum auf einem Server ein Remotekommando / Shellskript via Webbrowser auszufuehren, ohne das dafuer irgendeine grosse Software-Remotemanagement-Loesung laufen muss. Die Antwort ist der gute alte (x)inetd verbunden mit einem kleinen PHP-Skript. Ich kommentiere das jetzt hier nicht weiter sondern schreibe es einfach mal runter:
Als erstes muessen die Programme installiert werden:
aptitude install xinetd php5-cli |
Danach die folgende Datei unter /etc/xinetd.d/test ablegen
# description: xinetd + php = fun service test { socket_type = stream protocol = tcp wait = no user = root server = /usr/bin/php5 server_args = /root/test.php disable = no } |
Anschliessend die /etc/services editieren und die folgende Zeile einfuegen:
test 44444/tcp # test |
und nun noch diese PHP-Datei unter /root/test.php ablegen:
<?php echo "+++ xinetd + php = fun +++ "; ## read parameter $handle = fopen('php://stdin','r'); $input = fgets($handle); fclose($handle); ## split get parameter $out1=str_replace("GET /", "", $input); $out2=str_replace(" HTTP/1.1", "", $out1); $parameter=explode("/", $out2); ## check if we shall do sth. and if we know it if (trim($parameter[0]) == "doStuff") { if (empty($parameter[1])) { echo "no job start requested... "; } elseif (! trim(empty($parameter[1])) AND trim($parameter[1]) == "psaux") { $out = shell_exec('ps aux'); echo "$out"; } } else { echo "no job start requested... "; } ?> |
Ich denke die PHP-Datei erklaert sich von selber und kann beliebig erweitert werden. Ein Aufruf von http://example.net:44444/doStuff/psaux gibt dann die Ausgabe des Befehls „ps aux“ wieder. Nun sind bei dem shell_exec keine Grenzen gesetzt… ;-) Wichtig daran ist, dass wir die GET Parameter via stdin auslesen, da der xinetd das Zeugs ja nicht per GET an das php-Skript weiterleitet. Aber was solls… Der Kreativitaet sind da keine Grenzen gesetzt.
Ich wuerde natuerlich noch den Zugriff ueber irgendeine iptables Regel beschraenken ala:
iptables -A INPUT -p tcp -m tcp --dport 44444 -s 1.2.3.4 -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 44444 -j REJECT |
Und ueber Security von wegen das Skript als root laufen zu lassen usw. reden wir hier nicht weiter, es geht ja auch nicht darum das als Superloesung zu verkaufen, sondern einfach als simple kleine Adminspielerei ;-)