www.mikrocontroller.net

Forum: PC-Programmierung Probleme mit Script (Linux)


Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
#============================
# copy_and_encrypt
#============================
copy_and_encrypt()
{
  # copy
  #-----
  cd $myFileSystem/$myDate
  find . -depth -print | cpio -pd /home/tmp_backup/$myDate

  # encrypt
  #--------
  passwort="irgendeinpasswort"
  cd /home/tmp_backup/$myDate
  for file in `find /home/tmp_backup/$myDate -type 'f'`;
  do
    ccrypt -ev -K $passwort $file
  done
}

Weiss jemand Rat?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 \;

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> find /home/tmp_backup/$myDate -type 'f' -exec ccrypt -ev -K $passwort
> $file \;

sorry war noch ein fehler drin, so müsste es gehen

find /home/tmp_backup/$myDate -type 'f' -exec ccrypt -ev -K $passwort
"{}" \;

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sämtliche Leer- und Sonderzeichen-Probleme kann man lösen, indem man die 
for-Schleife komplett ersetzt durch:
    find /home/tmp_backup/$myDate -type 'f' -print0 |xargs -0r ccrypt -K $passwort

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:
    logfile=/tmp/x-debug-$myDate.log
    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.

Autor: Mehmet Kendi (mkmk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
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)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht es mit den Dateiberechtigungen aus? Hat der Benutzer des 
cron-Jobs evtl. nicht für alle Dateien Schreibrechte?
x

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cron hat root Rechte.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:) 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.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ...

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt versteh ich aber gar nichts mehr.

Mit der veraenderten Zeile
ccrypt -ev -K $passwort $file >> /tmp/backup_tmp.log 2>&1
wurde alles korrekt verschlüsselt.

Zur Erinnerung: im Orginal war die Zeile ccrypt -ev -K $passwort $file

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zufall?

Solange es so bleibt, ist ja alles in Ordnung.
Oder ein Temperaturproblem? Oder habt ihr immer noch 21°?

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll's? Das Problem ist gelöst.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
: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

Autor: Mehmet Kendi (mkmk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Log Datei enthaelt nichts besonderes. Siehe Beilage.

Autor: A.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf diesem System hatte ich keinen MailServer installiert. Und in 
/var/log habe ich keine Datei gefunden, die irgendwas von ccrypt 
enthalten haette.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, werde es heute abend ausprobieren. Wieder mal was dazugelernt. 
Danke.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.