Wer Server betreibt möchte in der Regel seine Ruhe haben (ausgenommen Windows Administratoren, die haben immer was zu tun). Damit das so ist, gilt es an einen Punkt zu kommen, an dem ein "Status Quo" erreicht ist. Diesen Status gilt es dann zu halten.
Nun kann man zu Fortuna beten oder sich ein Monitoring einrichten. Dienste und Co lassen sich in der Regel ziemlich einfach beobachten und dementsprechend prüfen. Bei der Hardware sieht es zumeist anders aus. Wer nun denkt das man aufwendige Agenten installieren muss und sonst welche Bemühungen zu betreiben hat, damit man an die Daten kommt liegt einfach falsch. Natürlich kann man mit einem Agenten eine ganze Menge machen. Wenn man das aber nicht will oder gar die gewünschte Funktion nicht gegeben ist, dann braucht man die Möglichkeit den ohnehin vorhandenen SNMP-Server um die gewünschten Werte zu erweitern.
In meinem Fall wollte ich wissen wie es den eingebauten Festplatten geht. Zunächst reicht mir erst einmal der HEALTH-Status des S.M.A.R.T. Will man mehr ist das aber auch kein großes Problem.
Wenn man seinen RAID-Controller ordentlich installiert hat, so kann man sich beliebige Ausgaben zusammenbauen. Zunächst einmal muss aber herausgefunden werden, was da so geht.
Ich wollte erst einmal wissen welche Festplatten an dem Controller hängen.
smartctl --scan /dev/sda -d scsi # /dev/sda, SCSI device /dev/bus/0 -d megaraid,8 # /dev/bus/0 [megaraid_disk_08], SCSI device /dev/bus/0 -d megaraid,9 # /dev/bus/0 [megaraid_disk_09], SCSI device /dev/bus/0 -d megaraid,10 # /dev/bus/0 [megaraid_disk_10], SCSI device /dev/bus/0 -d megaraid,11 # /dev/bus/0 [megaraid_disk_11], SCSI device /dev/bus/0 -d megaraid,14 # /dev/bus/0 [megaraid_disk_14], SCSI device /dev/bus/0 -d megaraid,15 # /dev/bus/0 [megaraid_disk_15], SCSI device
Mit diesen Informationen schaue ich nun, wie es der jeweiligen festplatte geht:
smartctl -H /dev/sda -d megaraid,8 | grep -i health SMART overall-health self-assessment test result: PASSED
Damit kann ich nun schon beginnen mein Monitoring aufzubauen. Dazu gebe ich in die /etc/snmp/snmpd.conf folgende Inhalte hinzu:
exec smart-sda1a /bin/sh -c "/usr/sbin/smartctl -H /dev/sda -d megaraid,8 | grep -i health
Nun gehe ich weiter zu meinem Icinga und erstelle zunächst einen Checkcommand:
define command {
command_name snmpsmarthealth
command_line /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C public -o $ARG1$ -r $ARG2$
}
In der jeweiligen Host-Konfiguration erstelle ich nun einen Service, welcher mir abbildet, was ich zu prüfen gedenke
define service {
use snmp-service
host_name SERVERNAME
service_description HDD 1 Health
check_command snmpsmarthealth!iso.3.6.1.4.1.2021.8.1.101.2!PASSED!
}
| snmpsmarthealth | Aufruf meines Checkcommands |
| ! | Trennzeichen |
| iso.3.6.1.4.1.2021.8.1.101.2 | Jeweiliges Unterverzeichnis des SNMP Baums |
| PASSED | Zu suchender Begriff |
Das Ganze wiederhole ich nun für sämtliche lokal ausgeführten Kommandos des zu überwachenden Servers.
wie komme ich denn nun zu den komischen SNMP-Tailbäumen mit den merkwürdigen Zahlen? Im Zweifelsfall starte ich dazu einen Suchlauf mittels snmpwalk
snmpwalk -c public -v 2c SERVERNAME | grep -i BEGRIFF DEN ICH ERWARTE
Nun kann ich alles Monitoren, was ich will oder benötige. Ohne Agenten, ohne viele Plugins. Das Leben ist so einfach!
Seiten die mir geholfen haben:
http://www.bitbull.ch/wiki/index.php/Simple_way_to_read_SMART_status_from_harddisk_via_SNMP
Das Ansible für mich der logische nächste schritt nach der Shell ist, sobald es um die Verwaltung von Servern geht, habe ich vielleicht hier und da schon mal durchblicken lassen. Der Hintergrund ist einfach:
Mit Ansible Playbooks habe ich als Systemverwalter die Möglichkeit meine Schritte in einfacher Art und Weise (fast schon stenografisch) nieder zuschreiben und so einen Ablauf zu skizzieren, welche Arbeiten/Schritte/Rahmenbedingungen auf dem von mir zu verwaltenden System durchgeführt/vorhanden sein sollen.
Ansible selbst kümmert sich dann um die Abstraktion zum System hin, auf dem ich dann letztendlich die Skizze ausführe.
Wenn ich nun eine gewachsene Landschaft mit unterschiedlichen Linux-Distributionen habe, kann Ansible mir helfen diese aktuell zu halten. Das einfache Playbook dazu sieht wie folgt aus:
--- - hosts: all:!switche:!windows user: root gather_facts: true tasks: - name: apt update action: apt update_cache=yes when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian" - name: apt upgrade action: apt upgrade=dist force=yes when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian" - name: yum upgrade action: yum name=* state=latest when: ansible_distribution == "CentOS" - name: dnf upgrade action: yum name=* state=latest when: ansible_distribution == "Fedora"
Wenn ich dieses Playbook nun auf meine Landschaft loslasse:
ansible-playbook playbooks/linux-upgrade.yml
spielt es keine Rolle mehr, ob die Eingesetzte Distribution ein Debian, Ubuntu, Fedora oder CentOS ist. Alle werden mit den eigenen Paketmanagern aktualisiert
Es ist schon ein kleines Trauerspiel. Da begleitet mich Samba mindestens genau so lange durch meinen Linux/Unix Alltag wie die Erkenntnis, dass ein XClient getrennt von einem Server läuft und dann bemerkt man im langen Wechsel von Version 3 zu 4 doch einen erheblichen Hipster-Beigeschmack.
Die Rede ist davon, dass noch bei Samba3 wunderbare Bücher zu finden waren. Werke die nicht nur die Technik, sondern auch Charakter beschrieben und mitgebracht haben. Auf diesem Wege wurde man tief in die Möglichkeiten und Werkzeuge eingeführt, welche sich hier bieten. Mit Samba4 ist hiervon kaum noch die Rede. Klar, Microsoft ist im Boot und ich finde es sehr löblich, dass hierdurch die Schritte der Entwicklung vereinfacht wurden. Doch der Beigeschmack, wenn man sich die Topics des LPI anschaut und noch mehr wenn man ein Buch oder Informationen sucht ist ein wenig Bitter.
So erging es mir auch bei meinem Bestreben einen Samba4 Server als neuen Fileserver bereitzustellen, welcher seine Benutzer gegen ein OpenLDAP authentifiziert. Insgesamt kein reisen Hexenwerk möchte man meinen. Verschafft man sich einen Überblick indem man im Netz sucht und auf Erfahrungsberichte hofft, so wird man schnell enttäuscht. Die Rede ist immer wieder "der Aufwand lohnt nicht!" oder "Migration zu Samba Active Directory"... Sorry, dass ist nicht das was ich will. Ich will weder einen Nameserver auf meinem Fileserver laufen lassen, noch will ich meinen vorhandenen Stamm auf selben migrieren und alle Dienste umbauen. Ich will einfach nur einen Dateiserver haben der tut, was ein Dateiserver tut. Nur eben neuer und vielleicht ein wenig besser.
Lange Rede kurzer Sinn. Fündig geworden bin ich nicht. Die Tägliche Unruhe lies mich auch keine klaren Tage damit verbringen die Manpages auf eventuelle Fallstricke hin zu untersuchen. Also habe ich zunächst einmal gebaut, was ich so bauen konnte. Als dann eine ruhige Minute kam und die Muse stieg, warf ich beherzt den Debug-Modus an und kam recht schnell auf eine mögliche Ursache.
Die Lokale Domänen-SID des Samba, welche durch das Eintragen der OpenLDAP Daten in der Konfiguration einen Zugriff auf das Verzeichnis ermöglichte stimmte nicht mit der bestehenden Domäne überein. Das schien der Grund zu sein, weshalb eine Authentifizierung fehlschlägt.
Ironischer Weise findet man mit diesen Informationen dann auch Gleichgesinnte (http://lapsz.eu/blog/2013/09/04/standalone-samba-server-with-ldap-authentication/). Somit war mein "Problem" dann auch kein Problem mehr und wir konnten uns alle lieb haben. Seit dem arbeitet fröhlich der Samba als lokaler (neuer) Fileserver im Netzwerk und wartet auf all die Tollen Verbindungen.