Servus allerseits
Seit Jahr und Tag wird auf einem Linux Server um 22 Uhr ein Backup
gemacht und anschliessend diese Daten auf einen externen Server kopiert.
Seit Tagen versuche ich nun diese Daten zuerst mit ccrypt zu
verschlüsseln und erst dann zu kopieren.
Wenn ich die Script-Datei vom shell aus aufrufe, klappt es.
Wenn's aber cron macht, gibts ein Mischmasch, bei dem ich keine
Regelmaessigkeit festellen konnte.
Dem Script hatte ich nur die Funktion copy_and_encrypt hinzugefügt.
Diese Funktion kopiert den soeben neu erstellen Backup-Order in einen
temporaeren Ordner, wo es dann verschlüsselt wird.
Kopieren klappt immer. Aber im temporaeren Ordern werden (falls es cron
macht) nicht alle Dateien verschlüsselt, sonder nur zufaellig
irgendwelche. Mehrheitlich wird nicht verschlüsselt.
warum so kompilziert mit der for schleife? (aber wo das Problem liegt
kann ich leider nicht sagen, teste mal mit:
find /home/tmp_backup/$myDate -type 'f' -exec ccrypt -ev -K $passwort
$file \;
Haben die Dateinamen, die von cron verwurstet werden, Leerzeichen
im Namen oder Pfad?
Genauer gesagt, die ausgelassen werden.
Dann könnte es helfen, die Zeile so abzuändern:
ccrypt -ev -K $passwort "$file"
@Klaus Wachtler: wegen den Leerzeichen werde ich morgen darauf achten.
Aber vermutlich wird es das nicht sein, denn das waere mir schon
aufgefallen.
@Peter: werde morgen es mit Deinem Vorschlag versuchen.
Danke für die Hinweise.
PS, ich würde das Password anders angeben. So nähmlich bekommt jeder das
Password mit, welcher ein ps ausführen kann, oder auch das Proc
implementiert ist. Besser ist, das password aus einem File lesen, dann
ist nur ein `cat crypt.pwd` ersichtlich.
Das geht auch eine Idee schneller, weil ccrypt weniger oft gestartet
wird.
Dazu ist chris Empfehlung, das Passwort nicht auf der Commandline
anzugeben, wirklich sinnvoll zumal ccrypt ja mit "-k" eine gute
Möglichkeit dafür anbietet.
Zu den eigentlichen Problemen:
Wenn cron und ein manueller Aufruf unterschiedliche Dinge tun, hat das
typischerweise folgende Gründe:
- andere Umgebungsvariablen, insbesondere PATH und LD_LIBRARY_PATH,
- anderer Umgang mit Standard-Eingabe bzw. -Ausgabe,
- andere Berechtigungen / Benutzer.
Das Einfache zuerst:
- Der Cron-Job läuft unter root-Rechten oder mit einem anderen techn.
Benutzer?
Zu den Umgebungsvariablen:
- Die "zufällig verschlüsselten Dateien" sind nicht zufällig die, die
schon vorher verschlüsselt waren?
- Ist ccrypt im Standardpfad, also in /bin oder /usr/bin ?
- Wenn es daran nicht liegt, füg doch bitte mal sowas in dein Script
ein:
1
logfile=/tmp/x-debug-$myDate.log
2
declare -p > $logfile
Die unterschiedlichen Ausgaben in den Dateien helfen dabei,
einzugrenzen, welche Unterschiede in den beiden Aufrufszenarien
existieren. Insbesondere lassen sich interaktiv die Werte vom cron-Lauf
nach und nach setzen bzw. mit "unset VARNAME" löschen. Nach jeder
Änderung nachmal probieren. Wenn es dann auf einmal nicht mehr geht, war
es die letzte Änderung :-)
Zu STDIN/STDOUT:
Wenn es daran hakt, wird es gruselig, das überhaupt herauszufinden bzw.
zu beheben. Probier erstmal das andere.
Nochmals Dank für all die Hinweise. Leider komme ich nur step by step
dazu, Eure Vorschlaege in die Tat umzusetzen, da ich mit incremental
backup arbeite und deshalb nur einmal pro Tag die Script starten möchte.
Also um ein Problem mit Leerzeichen handelt es sich nicht. Sowohl
Dateien mit als auch Dateien ohne Leerzeichen im Namen wurden von ccrypt
(gestartet von cron mit root Berechtigung) verschlüsselt.
Als naechstes habe ich den Vorschlag von Herrn Wachtler aufgegriffen und
die Zeile mit den Ausdruch $file im Befehl ccrypt -ev -K $passwort $file
in Ausführungszeichen gesetzt:
1
ccrypt -ev -K $passwort "$file"
Hat aber auch nichts gebracht. Den naechsten Versuch mache ich morgen.
Ich habe noch ein Bild angehaengt. Vielleicht sieht einer von Euch ein
Muster, wieso ccrypt manche Dateien verschlüsselt und manche nicht.
Mit freundlichen Grüssen aus Istanbul (21 Grad)
Mehmet Kendi schrieb:> (21 Grad)
Das ist mies!
Du solltest hier Schnee schippen, anstatt von 21° zu erzählen! :-)
Aber wenn du sowieso änderst, könntest du vor der Schleife noch
ein:
rm /tmp/backup_tmp.log
einbauen und in der Schleife vor dem ccrypt noch eine Zeile:
echo "verschlüsseln von ["$file"]" >>/tmp/backup_tmp.log
Dann würde man hinterher sehen, welche Dateien er versucht zu
verschlüsseln.
Noch eine Idee:
Da tauchen eher etwas, naja, schrullige Dateinamen auf (nicht böse
nehmen).
Wenn du ohnhehin schon wie von mir vorgeschlagen eine kleine
Logdatei erzeugst, könnte man auch gleich dort die
Environmentvariablen mit ausgeben, also z.B.:
rm /tmp/backup_tmp.log
set >/tmp/backup_tmp.log
Weiterhin in der Schleife auch gleich die Ausgabe des ccrypt mit
ablegen:
for...
echo "verschlüsseln von ["$file"]" >>/tmp/backup_tmp.log
ccrypt -ev -K $passwort $file >> /tmp/backup_tmp.log 2>&1
Die Ausgabe von dem set könnte man dann mal vergleichen
mit der entsprechenden Ausgabe einer normalen Sitzung.
Beim Initialisieren einer Shell wird ja zwischen einer
Login-Sitzung und einem nicht-Login unterschieden.
Vielleicht wirkt sich das (je nach init-Dateien
~/.bashrc, ~/.profile, /etc/bashrc, /etc/profile etc.)
auf Variablen wie LANG aus.
Das wiederum kann man auch mit einem kleinen Skript
testen, das als cron-Job eingetragen wird unabhängig
von der Datensicherung. Dann musst du nicht jeweils eine
Nacht auf einen Test warten...
:) Die schrulligen Zeichen sind türkische Karakter.
Der Server wird nur als Samba und SQL-Server benutzt, d.h., diese
schrulligen Zeichen kriege nur ich zu Gesicht.
Ich habe die Script gemaess Deinem Vorschlag geaendert. Mal schauen, was
heute Nacht rauskommt.
>Mehmet Kendi schrieb:>> (21 Grad)>Das ist mies!>Du solltest hier Schnee schippen, anstatt von 21° zu erzählen! :-)
Ich bin froh, daß hier keine 21°C sind. Stell Dir vor, Du müsstest bei
21°C Schnee schippen ...
Nein, Zufall ist es bestimmt nicht. Seit sicher etwas mehr als 2 Wochen
hat die Script nur fehlerhaft die Verschluesselung bearbeitet.
Ich habe, weil so paff, die Script soeben nochmals gestartet. Funzt
problemlos, hat wieder alles verschluesselt.
Ich verstehe das nicht.
Interessant wäre noch, was in der Log-Datei steht.
Vielleicht wollte das ccrypt gelegentlich etwas ausgeben und
konnte nicht, z.B. wegen fehlender Rechte, und musste deshalb abbrechen.
:D neee, so einfach mache ich mir das Leben nicht! Ich muss schon
wissen, wieso es jetzt klappt und vorher es nicht geklappt hat.
Die Temperatur ist übrigens auf 12 Grad runter. Aber bitte keine
Schadenfreude aufkommen lassen. Ab Dienstag geht's wieder obsi und am
Donnerstag sollten wir gemaess Wetterdienst wieder bei 20 Grad
angekommen sein.
Persönlich waeren mir aber Minustemperaturen und Schnee lieber.
MfG aus Istanbul
In der Datei stehen aber nur die Ausgaben von echo, die Ausgaben von
ccrypt fehlen. Da ja "ccrypt -ev" verwendet wurde, müsste noch jeweils
mindestens eine weitere Zeile vorhanden sein.
Sollte also ccrypt irgendwelche Probleme haben, so wüssten wir nichts
davon.
Ach ja: "ccrypt -ev" sollte doch eigentlich schon vor der Änderung
Ausgaben erzeugen. Diese sollte cron dann eigentlich per Mail zustellen.
Wo sind diese Logs? Steht da was Auffälliges drin?
Also ich hatte auch shconmal das Phänomen, dass wenn ich die
Standard/Error Ausgabe nicht lese das Programm seinen regulären Dienst
verweigert...
Interessehalber kannst du ja die Zeile wieder auf "orginal" ändern und
dann schauen ob der Fehler wieder auftritt.
Mehmet Kendi schrieb:> Auf diesem System hatte ich keinen MailServer installiert.
Hast du den entfernt? Normalerweise wird doch bei den meisten Distros
automatisch einer installiert, gerade weil sonst wichtige Nachrichten
von Diensten wie cron oder smartd verlorengehen.
Läubi .. schrieb:> Interessehalber kannst du ja die Zeile wieder auf "orginal" ändern und> dann schauen ob der Fehler wieder auftritt.
Okay, werde es für heute abend wieder aendern.
Rolf Magnus schrieb:> Hast du den entfernt?
Nöö, wieso soll ich mir eine Mehrarbeit machen? Wie ich soeben sehe,
werden auch die Systemlogs von cron nicht nachgeführt.
Ziemlich ein altes System (Ubuntu 7.04). Kann also auch sein, dass ich
der Schuldige war und mich jetzt nicht daran erinnere.
Habe es nicht abwarten können und einen neuen cron-Eintrag eingetragen.
Es scheint, dass die Vermutung von Herrn Läubi
Läubi .. schrieb:> Also ich hatte auch shconmal das Phänomen, dass wenn ich die> Standard/Error Ausgabe nicht lese das Programm seinen regulären Dienst> verweigert...
die Erklaerung für dieses Phaenomen zu sein scheint.
Nochmals ein herzliches Dankeschön für all die Hilfe.
In dem Fall bietet sich an, für das gesamte cron-Script klare
Verhältnisse zu schaffen und alle Ein- und Ausgabeströme zu schließen
bzw. in ein Logfile umzuleiten.
Am einfachsten geht das, indem man folgende Zeile ganz am Anfang des
cron-Scripts einfügt:
exec < /dev/null >> /var/log/backup.log 2>&1
A.H. schrieb:> ganz am Anfang des cron-Scripts einfügt:
Genauer (nur zur Sicherheit): fast am Anfang, also zumindest
nach dem #!/bin/bash und vor der ersten wirklichen Aktion.
A.H. schrieb:> Am einfachsten geht das, indem man folgende Zeile ganz am Anfang des> cron-Scripts einfügt:>> exec < /dev/null >> /var/log/backup.log 2>&1
Yep; nach dem Einfügen dieser Zeile kann man das Orginal-Script sowohl
von cron, als auch von der Shell aus starten.
