Vergleichbares Programm zum File Server Resource Manager für Linux?

[Holzohrwascherl]

Mich interessiert eine Funktionalität des Windows Servers, nämlich der File Server Resource Manager (FSRM). Gibt es ein Programm vergleichbarer Funktionalität auch für Linux?

Ich würde gerne ausgewählte Netzwerkfreigaben (alles Samba-Shares) z. B. auf folgende Aktionen überwachen:

• Dateien mit einem bestimmten Dateityp werden inhaltlich geändert.
• Mehr als 10 Dateien werden pro Minute umbenannt.
• Der Dateityp einer Datei (Dateiendung) wird geändert.

Das sind nur Beispiele. Ich würde das Programm gerne auf einem separaten Rechner, z. B. einem Raspi laufen lassen. Immer wenn eine definierte Aktion durchgeführt wird, soll eine E-Mail versendet werden.

 

[0x8100]

was fertiges kenne ich dafür nicht. ich würde mir auf dem samba-server ein überwachungsscript auf basis von inotify bauen.

 

[PHuV]

Suche von 5 Sekunden per Google:
https://www.tpsort.com/similar-to/4...rce-manager-alternative-and-similar-softwares

Wobei das meiste wohl für Windows und MacOS ist. Für Linux gibts anscheinend nur so altes Zeugs.
https://sourceforge.net/projects/daemonfs/
http://iwatch.sourceforge.net/index.html
https://github.com/Tripwire/tripwire-open-source
https://emcrisostomo.github.io/fswatch/

 

[Holzohrwascherl]

was fertiges kenne ich dafür nicht. ich würde mir auf dem samba-server ein überwachungsscript auf basis von inotify bauen.

Danke für den Hinweis. Das da sieht recht interessant aus und baut auf inotify auf: https://wiki.ubuntuusers.de/systemd/Path_Units/

Ergänzung (6. Januar 2022)

… Für Linux gibts anscheinend nur so altes Zeugs.

iwatch und fswatch sehen aber interessant aus. Danke für die Tipps.

 

[Holzohrwascherl]

Habe iWatch angetestet. Das Programm ist für Linuxanfänger ohne ausgeprägte Lernbereitschaft und für meine Zwecke wenig praxistauglich. Es schreibt alle Ergebnisse nach /var/logs/syslog, das ist unpraktisch, da man kein separates Logfile konfigurieren kann.

Außerdem fehlen wichtige Funktionen, obwohl dokumentiert. Das Programm protokolliert zwar, wenn eine Datei geschlossen wird aber nicht, wenn sie z. B. verändert wurde.
In einem Forenbeitrag habe ich gelesen, dass einige Funktionen im Quelltext nur als Vorschläge formuliert, aber nicht implementiert seien. Schade, das Programm ist an sich flink konfiguriert.

Morgen sehe ich mir fswatch an.

 

[andy_m4]

Es schreibt alle Ergebnisse nach /var/logs/syslog, das ist unpraktisch, da man kein separates Logfile konfigurieren kann.

Ich weiß nicht, wie das jetzt konkret bei iwatch ist. Aber üblicherweise werden Dinge via syslog protokolliert. Du musst also syslog entsprechend konfigurieren, wenn Du für irgendein Service eine getrennte Protokolldatei willst.

 

[Holzohrwascherl]

Ja, war ganz einfach: In der Datei /etc/rsyslog.d/syslogserver.conf einfach eine Zeile einfügen:

if $programname == 'iWatch' then /var/log/iwatch

Dann Neustart, und es hat geklappt.
Schaut sehr gut aus.
Morgen werde ich einige Testfälle durchspielen …

 

[Holzohrwascherl]

Mannomann, das Programm sieht nicht gut aus.
von etwa 30 Dateioperationen werden gerade einmal 10 gemeldet. Ich habe den Eindruck, da wurde nur ein Bruchteil der in der Dokumentation erwähnten Funktionalitäten implementiert. Oder ich sitze einem Bug systematisch auf. Oder mehreren.
Es könnte aber auch an einem Fehler in inotify liegen.

 

[andy_m4]

Es könnte aber auch an einem Fehler in inotify liegen.

inotify sammelt direkt alle Filesystem-Events ein. Das klappt aber so wirklich gut nur bei lokalen Zugriffen, wo der Kernel quasi vollen Zugriff drauf hat. Bei Netzwerkdateisystemen wo auch von anderen Clients Änderungen durchgeführt werden ist das prinzipbedingt nicht gegeben und da kann schon mal was durchrutschen.

Programme die inotify am direktesten nutzen sind die inotify-tools (die auch in fast jeder Linux-Distribution im Repository zu finden sind). Damit kannst Du natürlich auch mal drauf gucken. Fehlen dann immer noch Events, dann hast Du hier vermutlich die Problematik mit den Netzlaufwerken.
Falls nicht, ist es vielleicht doch ein iwatch-spezifisches Problem.

Falls es das Problem mit den Netzlaufwerken ist, solltest Du Dir überlegen ob es nicht doch möglich ist das "Watching" direkt auf dem Server zu machen.
Alternativ kannst Du natürlich auch händisch (also ohne Zuhilfenahme Filesystem-Monitoring-Frameworks; sondern durch prüfen der Daten "zu Fuß") das Verzeichnis überwachen. Je nachdem wie viel Verzeichnisse/Dateien zu überwachen sind kann das natürlich ein aufwändiger Prozess sein und ist natürlich nicht so effizient, kann aber durchaus auch ein gangbarer Weg sein.

 

[Holzohrwascherl]

Das mit Netzlaufwerken wäre der absolute Volltreffer, ich wäre aber überrascht, wenn das funktionieren sollte. Ich habe ausschließlich mit Ordnern meines Heimatverzeichnisses experimentiert. Einge Male hat er korrekt „Datei 1.txt wurde geschlossen.“ gemeldet. Dann ein Mal korrekt, dass eine Datei gelöscht wurde. Das Meiste hat er aber ignoriert.

 

[Holzohrwascherl]

Habe soeben im Debianforum erfahren, dass das Programm höchstwahrscheinlich seit Jahren nicht mehr funktioniert und nicht mehr gewartet wird.

Jetzt versuche ich es mit den inotify-tools.

 

[PHuV]

Da solltest Du aber aufpassen:
https://www.linux-community.de/ausgaben/linuxuser/2017/01/bescheid/3/

Bei der Konfiguration von Programmen wie Incron gilt es, mit Vorsicht zu agieren. Solche Tools kommen oft beim Überwachen großer Verzeichnisbäume zum Einsatz. Passt man dabei nicht penibel auf, treten Endlosschleifen auf, weil Incron die Ergebnisse in Dateien ablegt, die wiederum in den überwachten Bereichen liegen. Solche Schleifen legen im schlimmsten Fall das gesamte System lahm.

 

[Holzohrwascherl]

Ja, wegen der Endlosschleifen. Ich werde mich da mit einem eigenen PC (altes Notebook) herantasten …

 

[Holzohrwascherl]

Ich bin bei iWatch einen entscheidenden Schritt weiter, nachdem ich den Entwickler angeschrieben habe. Ich bin einem trivialen Fehler aufgesessen: In den Ordnernamen der zu überwachenden Ordner darf kein Leerzeichen enthalten sein. D. h. in den Ordnernamen selbst schon. Der zu überwachende Order sei Ordner 1.
Aber wenn man das Programm in der Konsole aufruft und den zu überwachenden Ordner übergibt, muss man das Leerzeichen maskieren:

sondern so:

iwatch -s -e access /home/max/Ordner\ 1

Jedem, der mit der Kommandozeile zu tun hat, ist das bekannt. Dennoch habe ich das übersehen. Ich habe nun die wichtigen Ereignistypen systematisch durchgetestet (access, open, close, create, move, modify, delete, attrib), und so weit funktioniert auch das meiste.

Dann teste ich noch stichprobenartig den daemon-Modus durch. Ich erwarte aber dasselbe Verhalten, da im daemon-Modus einfach aus der Konfigurationsdatei die Eingaben generiert werden, die ich in den Tests im Terminal manuell reingeklopft habe.

Es sieht also bisher recht gut aus.

Sogar ein Kurztest mit einem gemounteten Samba-Share hat geklappt. Bin jetzt mäßig zuversichtlich …

 

[Holzohrwascherl]

@andy_m4: Es ist so, wie du sagst: Für die Überwachung der Ordner- und Dateizugriffe auf Samba-Shares ist iWatch nicht geeignet.
Wenn ich auf dem Rechner, auf dem iWatch läuft, auf Ordner/Dateien in einer Netzwerkfreigabe zugreife, werden die Ereignisse gemeldet. Greift aber ein Client im Netzwerk auf den Ordner/die Datei zu (der Normalfall), so geht das an iWatch vorbei. (Man müsste quasi auf jedem Rechner im Netzwerk, der auf Samba-Freigaben zugreift, iWatch laufen lassen …)

Das bedeutet, einen Raspi für die Überwachung eines Samba- oder NFS-Netzwerks einzusetzen, geht nicht.
Ich werde daher versuchen, auf meinem QNAP iWatch zum Laufen zu bringen.

Das Ganze war aber einen Versuch wert und nicht unspannend.

 

[foo_1337]

Ich bin mir nicht sicher, ob ich deine Anforderung richtig verstanden habe, aber wäre nicht https://www.samba.org/samba/docs/current/man-html/vfs_full_audit.8.html das passende?

 

[Holzohrwascherl]

Das klingt sehr interessant, ich werde mir das in nächster Zeit ansehen. Das Problem, das ich befürchte: Ich setze keinen normalen Rechner mit Linux drauf ein, sondern Samba läuft auf einem QNAP-NAS. Ich muss mich erst schlau machen, was da alles (nicht) geht oder doch mit Linux in einer VM geht.

 

[Evil E-Lex]

Auch auf einem NAS verhält sich Samba nicht anders als in einer beliebigen Linux-Distro. Am wahrscheinlichsten wird dein Problem sein, dass Config-Änderungen an der NAS-Oberfläche vorbei durchaus bei Updates verloren gehen können.