Es gibt Tage, an denen mag es einfach nicht laufen. So auch heute, als ich versucht habe ein Netzwerksetup an einem 3Com Baseline Switch 2952-SFP zu debuggen. In der (fürchterlichen) UI gab es viele Anlaufstellen. So viele, das ich irgendwann offenbar den Wald vor lauter Bäumen nicht mehr sah und mich kurzerhand ausgesperrt habe.
Gott sei dank hatte ich noch einen USB-Serielladapter und ein entsprechendes Konsolenkabel zur Hand. Kurzerhand bin ich dann zum Switch und wollte rückgängig machen was ich verbock hatte - doch ganz so einfach sollte es dann doch nicht sein.
Doch eine, zwei Suchen im Internet später bin ich dann zu den Informationen gelangt, welche mir das Tor zum Himmel öffnen sollten.
Die notwendigen Schritte sind die folgenden:
Jetzt ist man drin und alles ist gut - von wegen. Man hat nun so ziemlich keine brauchbaren Tools zur Hand um den Switch zu konfigurieren. Dazu ist erst ein wenig Magie notwendig um quasi in den VIP Bereich zu kommen:
jetzt kann es richtig losgehen und der Switch dankt es einem vielen vielen neuen Funktionen.
Quellen:
Immer mehr - vor allem kleine oder sogar mittelständische - Unternehmen begehen den "Fehler" und lassen die Absprachen der Mitarbeiter unkoordiniert über Dienste wie Whatsapp zu. Das ist deshalb doof, weil man zum einen ggf. Daten ins Ausland exportiert und damit gegen geltendes Recht verstößt. Die Rede ist hier von einer Verletzung des BDSG und zukünftig auch der DSGVO. Als auch die Möglichkeit verliert Einfluss auf die Nachvollziehbarkeit von Konversationen etc zu nehmen.
Schlimmer noch, geht betriebliches in privates über und schon ist das Chaos vorprogrammiert.
Eine mögliche Lösung ist Mattermost. Diese Software hat mittlerweile einen guten Status erreicht und ermöglich es unter einer Haube sowohl Teams zu erstellen, als auch innerhalb der Teams Kanäle zu gründen, private Gruppen zu erstellen oder schlicht und einfach den direkten Austausch zweiter Kontakte untereinander. Damit lassen sich nahezu alle Hirarchien abbilden und der Informationsfluss lenken.
Cool daran ist, dass eben auch bei einem späteren Beitritt nachgelesen werden kann - wie in einem Protokoll. Es ist natürlich möglich auf einzelne Nachrichten zu antworten, Bilder und Dateien zu posten und selbstverständlich ist auch die Integration in diverse Dienste denkbar. selbst Telefonate sollten bald darüber realisierbar sein.
Dazu kommt noch, dass es kostenlose Apps für alle gängigen Geräte gibt und somit der mobilen und schnellen Nutzung nichts im Weg steht. Das Unternehmen behält so die absolute Kontrolle über die Informationen und reagiert gleichzeitig auf das Bedürfnis der Mitarbeiter sich auf diese Art und Weise auszutauschen.
Schon steht dem nächsten Audit nichts mehr im Weg :).
In meinem aktuellen Monitoringsetup habe ich festgestellt, dass die ausgiebige Verwendung von SNMP zu einigen False/Positives führte. Das nervt gewaltig und ist zudem auch noch ziemlich unbequem.
Daher habe ich mich an eine Ansible-Rolle gemacht, welche meine Hosts vorbereitet zukünftig NRPE zu nutzen. Um es besser nachvollziehen zu können, welche Schritte gegangen werden müssen habe ich das ganze hier einmal niedergeschrieben.
yum Install nrpe.x86_64 nrpe-selinux.x86_64 nagios-plugins-*
Anschließend muss die Datei /etc/nagios/nrpe.conf angepasst werden. Standardmässig ist nur das ausführen von Commands ohne Parameter erlaubt. Daher will ich das ändern um mehr Flexibilität bei der Anpassung der Rahmenparameter zu haben. Damit mir das nicht auf die Füße fällt muss der Wert von dont_blame geändert werden. Damit mir aber niemand dazwischen funkt, schränke ich die Hosts ein, die Checkscommands aufrufen dürfen - dazu dient allowed_hosts. Zum Schluss werden noch lokale Commands definiert. Diese sind notwendig und müssen für alle gewünschten Checks eingerichtet werden. Andernfalls kann NRPE nicht tun wofür es da ist (Nagios Remote Plugin Execution). Die Betonung liegt hier ganz klar auf Remote und Execution.
dont_blame_nrpe=1
allowed_hosts=127.0.0.1,192.168.X.X
command[check_users]=/usr/lib64/nagios/plugins/check_users -w $ARG1$ -c $ARG2$
command[check_load]=/usr/lib64/nagios/plugins/check_load -w $ARG1$ -c $ARG2$
command[check_disk]=/usr/lib64/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -u GB -E -p $ARG3$
command[check_mailq]=/usr/lib64/nagios/plugins/check_mailq -w $ARG1$ -c $ARG2$
command[check_ntp_peer]=/usr/lib64/nagios/plugins/check_ntp_time -w $ARG1$ -c $ARG2$ -H $ARG3$
command[check_procs]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$
command[check_procs_zombie]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -s Z
command[check_procs_named]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C named
command[check_procs_java]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C java
command[check_procs_apache]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C apache
command[check_procs_httpd]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C httpd
command[check_procs_platform]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C platform
command[check_procs_dhcpd]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C dhcpd
command[check_procs_qemu]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C qemu
command[check_procs_mysqld]=/usr/lib64/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -C mysqld
command[check_sensors]=/usr/lib64/nagios/plugins/check_sensors
command[check_smtp]=/usr/lib64/nagios/plugins/check_smtp -H $ARG1$
command[check_swap]=/usr/lib64/nagios/plugins/check_swap -w $ARG1$ -c $ARG2$
command[check_security_updates]=/usr/lib64/nagios/plugins/check_updates --security-only -t 30
Nun sind wir fast fertig. Für müssen nun nur noch unserem icinga Monitoring-Server mitteilen, dass es doch bitte ein neues Checkcommand kennt und zum anderen natürlich noch einen zu monitorenden Service daraus machen. Anschließend wird der angegebene Dienst per NRPE auf dem neu installierten Host überwacht.
define command {
command_name check_nrpe
command_line /usr/lib/nagios/plugins/check_nrpe -H $ARG1$ -c $ARG2$ -a $ARG3$
}
$ARG1$ wird zum Hostnamen
$ARG2$ wird zum Command das auf dem Server definiert wurde (sehe oben)
$ARG3$ wird zu den Schwellwerten für Warning und Critical
define service {
hostgroup_name nrpe
service_description Check users on system
check_command check_nrpe!$HOSTNAME!check_users!2 5!
use generic-service
}