Thema: Linux-Skriptzauberei

[Pyromancer]

Folgene Situation:
Rechner A generiert Daten. Viele und dauernd. Weil Rechner A nur einen kleinen Speicher hat, soll Rechner B regelmäßig (jede Stunde einmal) die Daten von Rechner A runterkopieren und dort löschen, damit wieder Platz für neue Daten ist.
Theoretisch sollte das ja mit cron-job, bash-script und ssh kein allzu großes Problem sein, nur bei der Praxis hapert es bei mir.

Dazu kommt, dass ich aus Prinzip ungern das Passwort für Rechner A im Klartext in ein Skript auf Rechner B eintragen würde.
Weiterhin: Die Daten werden in fortlaufend nummerierte Dateien geschrieben. Rechner B soll die allerneueste Datei weder kopieren noch löschen, weil bei der Rechner A ja noch zu Gange ist.

Mag jemand helfen?

[Turgon]

Klar.
Du hast PN.

[Würfelspucker]

Ich bin Müde, deshalb nur kurz zur Anmeldung:

Die Anmeldung machst Du am besten mit einem ssh-Key ohne Passwort[1]. Weiter können die ssh-Keys mit einem Befehl verbunden werden: Jedes mal wenn sich jemand mit diesem Schlüssel anmeldet wird ein Befehl ausgeführt (und nichts weiter, keine Shell).

[1] http://wiki.ubuntuusers.de/ssh#Authentifizierung-ueber-Public-Keys

[Bombshell]

Hallo,

@Turgon: Warum werden solche Dinge per PM geklärt?

Aber zum Problem: Ist die Schreibgeschwindigkeit der Dateien von Recher A ein Problem, d.h. werden diese Dateien sehr schnell geschrieben und können langsame Schreibprozesse die Datenerfassung beeinflussen? Wenn nicht, dann wäre es doch eine Alternative wenn Rechner A direkt auf Rechner B schreibt, d.h. Rechner A mounted über sshfs ein Verzeichnis von Rechner B ins eigene Dateisystem und schreibt seine Daten direkt dort rein. Dann würden auf Rechner A keine Daten anfallen und Rechner B müsste nichts abholen. Ich habe so etwas ähnliches auf meinem Raspberry Pi eingerichtet, um auf die Musik auf dem NAS zuzugreifen und abspielen zu können. Dazu habe ich folgende Schritte durchgeführt:

1. Auf Rechner A erzeugst du einen ssh-key ohne Passwort.
2. Auf Rechner B trägst du den gerade erzeugten Public-Key in die authorized_keys des Benutzers ein, mit dem sich Rechner B anmelden soll.
3. Auf Rechner A installierst du sshfs.
4. Du führst auf Rechner A folgendes aus:

Code: [Auswählen]

/usr/bin/sshfs -o idmap=user download@192.168.1.110:Musik /media/Musik/usr/bin/sshfs Der Pfad zu sshfs
download ist der Benutzer auf Rechner B mit dem man sich anmelden soll
192.168.1.110 ist die Ip von Rechner B
:Musik ist das Verzeichnis auf Rechner B auf das zugegriffen werden soll (wenn es direkt ins Homeverzeichnis des Benutzers soll, dann kannst du das auch weglassen)
/media/Musik ist das Verzeichnis auf Rechner A unter den man das entfernte Verzeichnis erreichen kann

Ich habe bei mir noch auf Rechner A einen Cron-Job laufen, damit das Verzeichnis erst versucht wird zu mounten sobald eine Netzwerkverbindung da ist, aber ich gehe in deinem Fall davon aus, dass die Verbindung immer da ist.

Schöne Grüße

Stefan

[Pyromancer]

Danke erstmal für die Hilfe.
Das ist natürlich Geschmackssache, aber mir ist es lieber, wenn der "große" Rechner B auf den "kleinen" Rechner A zugreift. Und auch ein Abbruch der Netzwerk-Verbindung sollte kein Beinbruch sein.

Ich hab jetzt mal folgendes Skript gebastelt, aber vor dem Ausprobieren Schlaf ich lieber noch eine Nacht drüber:

Code: [Auswählen]

#!/bin/bash

#Wie viele Dateien sind da?
nrOfFiles=`ssh name@ip 'ls /Quellverzeichnis/* | wc -l'`

#Eine Datei weniger
oneFileLess=`expr $nrOfFiles - 1`

#Die Dateien werden sortiert, die Schleife läuft aber nur bis zur Vorletzten
for f in `ssh name@ip 'ls /Quellverzeichnis/* | sort -n | head -n$oneFileLess'`
do
  scp name@ip:$f ./Zielverzeichnis/
  ssh name@ip 'rm $f'
done

Altmodisch, sollte aber funktionieren, oder?

[Bombshell]

Ich glaube du solltest dir mal rsync ansehen. Das kann auch schon von Haus aus mit SSH umgehen.

[Turgon]

Naja, ob man jetzt rsync aufruft oder scp ist egal.
Da die Dateien nach dem Holen sowieso gelöscht werden sollen, bringt rsync keinen Vorteil.

@Pyromancer:
Das "sort" in deiner Zeile zur Auswahl der Dateien sollte eigentlich nicht nötig sein. ls sortiert automatisch.
Wieviele Dateien erwartest du zum Kopieren pro Cronjob-Lauf?

[Genion]

rsync kann mit dem Parameter --remove-source-files die Daten direkt abholen und aus dem Quellordner löschen.

Generell würde ich auch dazu raten unfertige und fertige Daten strikt voneinander zu trennen. Du legst die anfallenden Daten erstmal temporär in einen Ordner und schiebst die am Ende in das Verzeichnis, das regelmäßig zur Übertragung geprüft wird. Dann brauchst du dich nicht drum zu kümmern unfertige Dateien noch vom Transfer auszuschließen.

Befehl zum Übertragen wär dann:

Code: [Auswählen]

rsync --remove-source-files -pt "remoteuser@server:/pfad/" /lokalerpfad/-p: Behält Dateiberechtigung bei (Besitzer und Gruppe ändern sich allerdings auf den gerade ausführenden Benutzer)
-t: Behält Zeitstempel bei

Nachtrag:
rsync nutzt zur Dateiübertragung ssh und kann damit auch einen SSH-Key zur Authentifizierung nutzen.

[oliof]

Wer rsync mit --remove-source-files aufruft, lebt aber auch gerne gefährlich (-:. Aber wers mag.

In dem Shellskript solltest du übrigens statt `...` besser $(...) nehmen.

[Turgon]

In dem Shellskript solltest du übrigens statt `...` besser $(...) nehmen.

Wenn's die Shell kann.
Aber eine halbwegs aktuelle bash kann das.

[Genion]

Wer rsync mit --remove-source-files aufruft, lebt aber auch gerne gefährlich (-:.

Huh? Inwiefern gefährlich? Bzw. wo ist der Unterschied zwischen rsync --remove-source-files und scp mit anschliessendem ssh rm?

[oliof]

Ach, das ist kein Unterschied, in der Tat. Ich wäre da vorsichtiger und würde die Daten auf dem A-Rechner noch ne zeitlang nachhalten um zu verhindern dass durch Übertragungsfehler was kaputt geht; die Dateien werden nämlich im scp-Fall gelöscht, auch wenn beim scp was schief geht. Eigentlich will man da dann scp ... && ssh ... um nur im Erfolgsfall zu löschen. Aber das skript hat noch andere Probleme; zum Beispiel geht es davon aus, dass ls immer eine Datei pro Zeile anzeigt, und dann diese komische Mathe um eine Zeile zu ignorieren, das ist mir alles suspekt. rsync ist da wirklich die bessere Wahl.

[Turgon]

Bei rsync muss man aber ebenfalls aufpassen, dass die aktuelle Logdatei nicht weggeräumt wird.
Wie Genion schon geschrieben hat, am besten gibt man den zu archivierenden Dateien ein eigenes Verzeichnis.

[oliof]

Ja, ich wollte das Thema jetzt nicht durch die Backup Diskussion verkomplizieren; aber genau das ist der grund warum ich --remove-source-files für riskant halte.

Es kommt ja auch ein bisschen drauf an was das für Daten sind, und ob man die gut komprimieren kann; bei Datenreihen könnte man evtl. auch in der Art von RRD historische Daten verdichten anstatt sie ganz wegzuschmeissen. Da gibts viele Möglichkeiten, und das Ausgangsszenario ist sehr allgemein gehalten.

[Turgon]

Hm, stimmt :-)

Hat denn Rechner A CPU-Kapazitäten frei, und lassen sich die Daten gut mit bzip2, xz oder 7z komprimieren?