RRD-Tool
Das ursprünglich von Tobias Oetiker entwickelte RRD-Tool hat sich über die Jahre zum Quasi-Standard beim Speichern von Netzwerk-überwachungsdaten entwickelt. Es ist eine Software, mit der sich zeitbezogene Messdaten speichern und visualisieren lassen. Inzwischen steht RRD-Tool unter der GNU General Public License, sodass heute eine ganze Reihe von Autoren daran mitarbeiten. RRD-Tool ist im Sourcecode wie auch als Binary für eine Reihe von Betriebssystemen verfügbar.
Die Abkürzung RRD steht für Round Robin Database und somit die Art und Weise, wie es seine Daten speichert: Beim Anlegen seiner Datenbank reserviert das System Speicher nur für eine bestimmte Zeitspanne und erweitert die Datenbank nach deren Ablauf nicht etwa, sondern überschreibt die jeweils ältesten Daten. In der englischen Informatik heißen solche Reihum-Methoden auch Round Robin. Die Idee dabei: Stetig eintrudelnde zeitbezogene Messdaten sollen mit anwachsender Uptime nicht die Festplatte vollmüllen, denn bei älteren Daten reicht oft ein grober über- oder Rückblick, während sich das aktuelle Geschehen in der Regel durch wichtige Details offenbart.
Das Benutzer-Interface von RRD-Tool besteht aus einem Satz von Kommandozeilen-Tools, deren Funktion auf der Projektseite ausführlich erklärt ist. Außerdem sind APIs für viele Programmiersprachen definiert, allen voran C und Perl, damit sich RRD-Tool von anderen Programmen zum Speichern nutzen lässt. RRD-Tool ruft man normalerweise nicht über die Kommandozeile auf, meistens dient es anderen Programmen als Datenquelle- und/oder Speicher, etwa Cacti [9] oder MRTG [10] . Eine umfangreiche Liste findet sich ebenfalls auf der RRD-Tool-Homepage.
Der SMB Traffic Analyzer
ist ein als VFS-Modul realisiertes Tool, das einen Samba-/CIFS-Server in die Lage versetzt, Traffic-Statistiken im Samba-Netzwerk aufzuzeichnen. Der SMBTA-Daemon (SMBTAD) speichert diese in einer Datenbank und macht sie unter anderem via SQL verfügbar. Die Architektur ist übersichtlich und besteht aus einem Modul im Samba-VFS (Virtual File System), einem Daemon sowie einem Set von Client-Tools (
»smbtatools
«
) zum Auswerten und Visualisieren. SMBTA nutzt eine vorhandene SQL-Datenbank (
»sqlite3
«
) zum Speichern der Traffic-Daten.
SMBTA-Entwickler und Erfinder Holger Hetterich von Novell arbeitet seit der SambaXP-Conference 2007 in Göttingen an seinem Samba Traffic Analyzer und konnte bisher in Fachkreisen, etwa beim Samba-Team, viel Aufmerksamkeit erregen, was ihm eine Reihe von gut besuchten Vorträgen etwa auf der Samba Xperience und bei anderen Gelegenheiten in Deutschland und den USA bescherte. Inzwischen engagiert sich sogar Arbeitgeber Novell insofern, dass Hetterich einen Teil seiner Arbeitszeit auf SMBTA verwenden kann.
Leider fehlt es in der Öffentlichkeit noch am breit angelegten Interesse, was aber bisher primär daran lag, dass jegliches Nutzer-Feedback direkt von und über Holger Hetterich abgewickelt wurde und nicht über die passenden Mailinglisten oder sonstige Kanäle, was schlicht eine Frage gekonnter Öffentlichkeitsarbeit ist. Deshalb ist auch die Anzahl an Referenz-Nutzern derzeit noch überschaubar. Das dürfte sich aber mit der kommenden Samba-Version 3.6 ändern, die den SMB Traffic Analyzer als offiziellen Bestandteil von Samba enthalten wird [1] .
Zwar könnten versierte Admins auch mit einem gewöhnlichen Portsniffer ausgewählte Schnittstellen etwa auf typischen Netbios-Traffic abhören, SMBTA konzentriert sich aber ausschließlich auf Samba-Traffic und ermöglicht das Erstellen umfangreicher und aussagekräftiger Statistiken, weil das Tool quasi echtes Datamining betreibt, in dessen Zentrum die Sqlite-Datenbank steht. So ist es etwa mit SMBTA möglich, Analysen gezielt auf einzelne Benutzer, Shares oder Dateien zu beschränken. Auf Client-Seite stehen im Prinzip drei Tools zum Auswerten zur Verfügung, die Bestandteil des Pakets
»smbtatools
«
sind. Zum einem ermöglicht ein RRD-Treiber mithilfe von RRD-Tool (Round Robin Database
[2]
), sich in Echtzeit an den SMBTA-Daemon zu hängen, was die grafische Aufbereitung der Traffic-Daten oder deren Weiterverarbeitung etwa in Perl-Skripten ermöglicht, wahlweise via IP oder Unix-Domain-Sockets. Das Werkzeug
»smbtaquery
«
kann die Datenbank via XML auslesen. Wer eher auf visuelle Effekte steht, kann mit dem
»smbtamonitor
«
auch ganz ohne SQL-Kenntnisse auf die gespeicherten Daten zugreifen.
Wer SMBTA selbst einsetzen möchte, kann entweder die Sourcen der aktuellen Version 1.1.2 von [3] herunterladen oder sich von Holger Hetterichs Wordpress-Blog Binaries für Open Suse besorgen [4] . Allgemeine Informationen zu SMBTA finden sich unter [5] . Aufgrund der Tatsache, dass das Installieren von SMBTA Backports auf Samba 3.6 erfordert, fahren Anwender mit dem RPM-Binary oder dem One-Click-Installer für Open Suse 11.3 am besten. Selbstverständlich ist auch das Auschecken von SMBTA per Git möglich [6] .
Last but not least können Suse-Nutzer auch die Paketquelle [7] in Yast einbinden und SMBTA mit dem Paketmanager installieren ( Abbildung 1 und 2 ). Noch stressfreier gelingt das Ausprobieren von SMBTA mit der von Hetterich geschnürten Applicance "Stresstest", die aktuell in der Version 0.0.2 vorliegt [8] (siehe Kasten).
Stresstest
Bei Stresstest (aktuell: 0.0.2) handelt es sich um eine fix und fertig geschnürte Suse-Appliance mit installiertem Samba-Server inklusive aktiviertem SMBTA-VFS-Modul (
Abbildung 8
). Stresstest basiert zwar ebenfalls auf SMBA 1.2.2, enthält aber darüber hinaus eine Reihe von Patches, die nicht in 1.2.2 enthalten sind. Die Stresstest-Appliance ist primär für das Testen von SMBTA gedacht und wird auch von den Entwicklern dazu intensiv genutzt. Wer einen schnellen Blick auf die Analysequalitäten von SMBTA werfen möchte, ohne erst ein komplexes Szenario aufzusetzen, für den ist Stresstest die beste Lösung. Die Appliance im Open Virtualization Format (OVF) enthält dazu mit
»smbtatorturesrv
«
eine kleine Server-Applikation, die über mehrere Prozess-Instanzen Dateinamen und Pfade über die Testumgebung verteilt.
Bei Stresstest 0.0.2 sind sechs User aktiv, die allesamt die Applikation
»smbtatorture
«
benutzen, um den Serverprozess ausreichend zu bechäftigen. Smbtatorture ist quasi eine kleine Testsuite für SMBTA und wird bisher hauptsächlich von den Entwicklern selbst für Langzeittests genutzt. Das Tool simuliert ein typisches Load-Verhalten von Office-Anwendungen. Zwischen den einzelnen Verkehrsproduktions-Zyklen legt das Tool jeweils Pausen von einigen Sekunden ein. Außerdem misst es die Zeit, die es selbst läuft, und kann seine eigene Aktivität aufzeichnen und reproduzieren. Mehrere Smbtatorture-Prozesse können problemlos parallel laufen.
SMBTA-Stresstest benutzt übrigens Port 3491, über den die Werkzeuge aus smbtatools ihre Abfragen abwickeln, was bei der Firewall/Paketfilter-Konfiguration des Client-Rechners zu berücksichtigen ist. Ansonsten ist die Appliance wie folgt konfiguriert:
Netzwerk: DHCP Timezone: Europe/Berlin Language: de_DE.UTF-8 Firewall: disabled
Das Root-Passwort sowie die Passwörter der übrigen sechs User
»holger
«
,
»nelson
«
,
»john
«
,
»bjoern
«
und
»btram
«
sind jeweils
»linux
«
.
Wer SMBTA schnellstmöglich ausprobieren, dazu aber keinen dedizierten Samba-Server aufsetzen möchte, muss SMBTA und die
»smbtatools
«
aus den Quellen bauen. Damit das klappt, müssen
»cmake
«
,
»libsmbclient-devel
«
,
»libtalloc-devel
«
und
»ncures-devel
«
installiert sein. Außerdem müssen die Datenbankumgebung Sqlite3 und die zugehörigen Devel-Pakete installiert sein. Schließlich ist zu prüfen, ob
»libxslt
«
installiert ist, was bei Open Suse per Default der Fall sein sollte. Nun entpackt man zunächst die Sourcen
»smbtatools-1.2.2.tar.bz2
«
und wechselt in das entstandene Verzeichnis. Der passende Aufruf von
»cmake
«
ausgehend vom Build-Verzeichnis konfiguriert das Paket für die übersetzung:
cmake ../smbtatools-1.2.2
»make
«
und
»make install
«
kompilieren das Paket und kopieren die Programme in den passenden Ort.
Zum Starten des Daemons genügt
»smtad -u -n
«
, womit Daemon (
»u
«
) und Client (
»n
«
) über Unix Domain Sockets kommunizieren. Der SMBTA-Deamon hat primär die Aufgabe, die SQL-Datenbank mit den Daten zu füttern, die er vom VFS-Modul empfängt. Außerdem ist er für das Abhandeln sämtlicher Client-Anfragen an die Datenbank verantwortlich. Möchte der Admin nun jeglichen Traffic auf einer ausgewählten Freigabe aufzeichnen, muss er lediglich in der betreffenden Share-Definition das VFS-Modul wie folgt laden.
vfs objects = smb_traffic_analyzer smb_traffic_analyzer:protocol_version = v2 smb_traffic_analyzer:mode = unix_domain_socket
wobei sich der letzte Parameter vom Administrator an die eigenen Bedürfnisse anpassen lässt (siehe auch Abbildung 3 ). Soll die Kommunikation zum Beispiel über TCP/IP laufen, sähe eine entsprechende Share-Definition etwa so aus:
vfs objects = smb_traffic_analyzer smb_traffic_analyzer:protocol_version = v2 smb_traffic_analyzer:host = localhost smb_traffic_analyzer:port = 3490
Der SMBTAD-Daemon wäre in diesem Fall mit
smbtad -i 3490 -p 3491
zu starten und wartet damit auf Anfragen via Port 3490 an das VFS-Modul und behandelt Client-Anfragen auf Port 3491. Per Default legt
»smbtad
«
seine Sqlite-Datenbank unter
»$HOME/.smbtad/staddb
«
an, es sei denn, die Datenbank existiert bereits. Eine ganze Reihe weiterer Parameter lassen sich mit
»smbtad -help
«
in Erfahrung bringen. Eine ausführliche Erläuterung sämtlicher Parameter findet sich darüber hinaus in der hervorragenden Dokumentation. Selbstverständlich ist es auch möglich, alle benötigten Konfigurationsparameter in einer Konfigurationsdatei
»/etc/smbtad.conf
«
zusammenzufassen, im typischen Ini-Datei-Format, mit
»#
«
als Kommentarzeichen.