Problem mit rsync unter Solaris 10 Sparc

[avalox]

Hi,

ich habe mir diese Woche 2 Sun-Fire-V210 mit Solaris 10 Sparc installiert.

Dazu habe ich noch rsync 3.0.0 installiert (inkl. aller Abhängigkeiten - die älteren Versionen habe ich auch versucht).

Wir backupen alle unsere Server per BackupPC, was auch bisher immer funktioniert hat.

Seitdem ich die beiden neuinstalliert habe, geht es nicht mehr.

Das Backup wird auf dem BackupPC Server gestartet

/usr/bin/ssh -q -x -l root IP /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --checksum-seed=32761 --log-file=/var/log/rsync.log --ignore-times . /


und nach kurzer zeit sieht man dann im Log auf der sun folgendes

2008/04/01 02:00:02 [11897] building file list
2008/04/01 02:00:23 [11897] rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
2008/04/01 02:00:23 [11897] rsync error: errors with program diagnostics (code 13) at log.c(230) [sender=3.0.0]

Die Verbindung zwischen den Servern ist einwandfrei. Keine Probleme. ssh login als root per key-auth geht auch wunderbar.

Wenn der Backup Prozess auf der sun dann beendet wurde, merkt der BackupPC Server das nicht mal. Dort sieht man den Aufruf per ps ax weiterhin. Auf der sun ist er weg.

Mehr Fehlermeldungen als die oben bekomme ich nicht.

Auf beiden Servern das gleiche (auch mit älteren rsync versionen).

Das komische ist, auf einer anderen Sun-Fire-V210 mit Solaris 10 funktioniert das alles wunderbar.

Dort läuft die gleiche ssh version mit der gleichen config und mit der gleichen rsync version (auch einfach nur installiert).

Ich weiss nicht wo der Unterschied bei den Servern sein soll?!

Vielleicht liegt es am Environment, weil das Backup ja per cron aufgerufen wird. Wenn ich den Aufruf oben per Hand starte bricht er nicht ab. Erst wenn man das aus dem Backup Webinterface oder per cron macht.

Ich weiss aber nicht, wie ich das checken kann.

Hoffe mir kann jemand helfen.

Gruß und danke
Sebastian

[Toktar]

Beim ersten Mal muss der Key des Servers bei der SSH bestätigt werden. Wenn der Job in einem anderen Env läuft, dann sollte das dort einmal gemacht werden, sonst funktioniert der Tunnel nicht.
Mit der Hand prima, per Cron gar nicht. Das kenne ich und meisst lag es am nicht bestätigtem Key.

[avalox]

blöde frage, aber wie mach ich das?

Also mit Environment meine ich die Umgebungsvariablen, die gesetzt werden.

Wenn ich mich in der Konsole wirkich einlogge, werden ja teilweise andere Variablen gesetzt als wenn der cron etwas als gleich user ausführt.

Falls ich mich vorhin blöd ausgedrückt habe.

Ich starte es in der konsole mit dem gleichen user als auch der cron das machen würde.

Der rsync befehl wird auch abgesetzt, also muss der ssh login klappen (ob nun per cron oder knsole).

per konsole bricht der rsync nur nicht ab wie per cron / webinterface

[Toktar]

Wie genau das bei solaris funktioniert, weiß ich nicht. Müsste ich mal testen, wenn ich zu Hause bin. Unter Linux schreibe ich ein Script, welches auch beim Cron das Env des Users setzt.
Entweder ich starte vor meinem Hauptscript die .profile oder ich setze schnell die notwendigen Varaiblen vorher per Hand

Code: [Auswählen]

#/bin/bash

export Var1=Guten
export Var2=Tag

echo $Var1 $Var2
Was geben denn die Logs her? Sonst das Loglevel mal hochsetzen. Die ssh muss auf alle Fälle anzeigen, ob der Tunnel zustande kommt.

[claus]

Geht auf Solaris auch so mit den ENV Variablen, zur Sicherheit kannst Du diese ja im SSH Aufruf cascadieren, bevor das ssh cmd ausgeführt wird.

Die rsync Fehlermeldung kenne ich allerdings nicht. Kann es sein, dass in dem Aufruf noch was escaped werden muss?

--log-file=/var/log/rsync.log --ignore-times . /

sticht mir da so ins Auge.

Claus

[avalox]

"Geht auf Solaris auch so mit den ENV Variablen, zur Sicherheit kannst Du diese ja im SSH Aufruf cascadieren, bevor das ssh cmd ausgeführt wird"

eine kurze Erklärung wie das geht wäre super.

Dankeschön

[avalox]

ich denk ich bin ein stück weiter.

auf einem komplett ungepatchten System funktioniert rsync ohne Probleme.

Lasse ich smpatch update komplett drüberlaufen, kommt die schon genannte Fehlermeldung.

Jetzt bleibt nur die Frage, welcher der PAtches das PRoblem auslöst.

Hat jemand von euch da vielleicht eine Ahnung, oder muss ich wirklich jeden PAtch einzeln installieren und testen