Guten Abend, ich habe einmal mehr ein Problem mit proftpd. Und zwar folgendes: Das Speichern von Dateien auf dem ftp-Server funktioniert eigentlich gut, mit der Ausnahme von gepackten Dateien. z.B. *.gz Dateien. Bei Dateien in diesem Format passiert es meistens, dass diese auf dem ftp-Server fehlerhaft abgespeichert werden. d.h. wenn ich die original-Datei mit der Datei auf dem ftp-Server vergleiche, ist jene auf dem ftp-Server 2 Bytes kleiner als das Original und dadurch nicht mehr benutzbar. Entpacke ich die *.gz Datei jedoch und übertrage sie ungepackt auf den ftp-Server wird alles korrekt abgespeichert. An was könnte das liegen? Ich benutze die proftpd-Version 1.2.5rc2. Das Problem trat bei mir jedoch auch bei Version 1.2.5rc1 und 1.2.2 auf. Ich habe proftpd ohne sendfile() kompiliert. In /var/log/xferlog wird die übertragene Datei als komplett übertragen angezeigt. Ich hoffe ihr könnt mir weiterhelfen. Gruss, Nicolas Rüegg
Hallo, The world received Nicolas R?eggs words at Sat, May 18, 2002 at 08:32:44PM +0200 this is what was written'
Guten Abend,
ich habe einmal mehr ein Problem mit proftpd. Und zwar folgendes: Das Speichern von Dateien auf dem ftp-Server funktioniert eigentlich gut, mit der Ausnahme von gepackten Dateien. z.B. *.gz Dateien. Bei Dateien in diesem Format passiert es meistens, dass diese auf dem ftp-Server fehlerhaft abgespeichert werden. d.h. wenn ich die original-Datei mit der Datei auf dem ftp-Server vergleiche, ist jene auf dem ftp-Server 2 Bytes kleiner als das Original und dadurch nicht mehr benutzbar. Entpacke ich die *.gz Datei jedoch und übertrage sie ungepackt auf den ftp-Server wird alles korrekt abgespeichert. An was könnte das liegen? Ich benutze die proftpd-Version 1.2.5rc2. Das Problem trat bei mir jedoch auch bei Version 1.2.5rc1 und 1.2.2 auf. Ich habe proftpd ohne sendfile() kompiliert. In /var/log/xferlog wird die übertragene Datei als komplett übertragen angezeigt.
Ich hoffe ihr könnt mir weiterhelfen.
Gruss,
Nicolas Rüegg
Ich weiss nicht, ob du das nicht schon sowieso gemacht hast, aber probiers mal mit der Uebertragung im Binaermodus. Im Kommandozeilenclient mit "bin" zu aktivieren. Dann werden die Dateien Bytegenau uebertragen. Die normale Uebertragung findet in manchen Clients im ASCII-Modus statt. Es gibt auch FTP-Server, die lassen nur die Binaeruebertragung zu. Bis dann, Oscar -- Oscar Knapp # key: http://www.soly.de/oscar_knapp.asc oknapp@soly.de # key ID: 0xAF733114 http://www.soly.de # registered Linuxuser nr. 183000 key fingerprint: D9A1 2BD1 6D05 9B95 87bF 9058 AE0C 191A AF73 3114 --------------------------------------------------------------------- Please understand that the quotes below are totally random and meant to give you something to laugh or think about. --------------------------------------------------------------------- "My advice to you, my violent friend, is to seek out gold and sit on it." -- "Grendel", by John Gardner
Am Sonntag, 19. Mai 2002 10:39 schrieben Sie:
ich habe einmal mehr ein Problem mit proftpd. Und zwar folgendes: Das Speichern von Dateien auf dem ftp-Server funktioniert eigentlich gut, mit der Ausnahme von gepackten Dateien. z.B. *.gz Dateien. Bei Dateien in diesem Format passiert es meistens, dass diese auf dem ftp-Server fehlerhaft abgespeichert werden. d.h. wenn ich die original-Datei mit der Datei auf dem ftp-Server vergleiche, ist jene auf dem ftp-Server 2 Bytes kleiner als das Original und dadurch nicht mehr benutzbar. Entpacke ich die *.gz Datei jedoch und übertrage sie ungepackt auf den ftp-Server wird alles korrekt abgespeichert. An was könnte das liegen? Ich benutze die proftpd-Version 1.2.5rc2. Das Problem trat bei mir jedoch auch bei Version 1.2.5rc1 und 1.2.2 auf. Ich habe proftpd ohne sendfile() kompiliert. In /var/log/xferlog wird die übertragene Datei als komplett übertragen angezeigt.
Ich weiss nicht, ob du das nicht schon sowieso gemacht hast, aber probiers mal mit der Uebertragung im Binaermodus. Im Kommandozeilenclient mit "bin" zu aktivieren.
Hab ich gemacht, ist auch per default eingeschaltet. Das Resultat ist aber dasselbe :-( Grüsse, Nicolas Rüegg
Am Sonntag, 19. Mai 2002 14:30 schrieb Nicolas Rüegg:
Hab ich gemacht, ist auch per default eingeschaltet. Das Resultat ist aber dasselbe :-(
dann fällt mir noch nur noch, einmal ProFTPD im Debug Mode starten (-n -d5) und mal die Ausgabe posten. Eventuell kann man denn was sehen. cu stonki -- Deutsche ProFTPD Dokumentation: http://www.stonki.de EFNET: #proftpd
Am Donnerstag, 23. Mai 2002 20:32 schrieb Nicolas Rüegg:
Hinzu kommt des weiteren, dass seit dem Update auf die proftpd-Version 1.2.5rc2 die "Timeout" Anweisungen in proftpd.conf nicht mehr berücksichtigt werden. User, deren Upload abgebrochen wurde bleiben nun unendlich lange auf dem System, obwohl diese wohl die Verbindung schon längst wieder getrennt haben. :-(
ja. Dieses ist inwischen im CVS gefixt. cu stonki -- Deutsche ProFTPD Dokumentation: http://www.stonki.de EFNET: #proftpd
dann fällt mir noch nur noch, einmal ProFTPD im Debug Mode starten (-n -d5) und mal die Ausgabe posten. Eventuell kann man denn was sehen.
Werde ich am Wochenende mal machen. Das Problem hat sich jedoch ausgeweitet. Nun kommt es auch ab und zu vor, dass der Upload aus ungeklärten Gründen einfach abbricht, oder eine Datei von 0 Bytes Grösse erstellt wird (unabhängig vom Typ der Datei). Hinzu kommt des weiteren, dass seit dem Update auf die proftpd-Version 1.2.5rc2 die "Timeout" Anweisungen in proftpd.conf nicht mehr berücksichtigt werden. User, deren Upload abgebrochen wurde bleiben nun unendlich lange auf dem System, obwohl diese wohl die Verbindung schon längst wieder getrennt haben. :-( verzweifelte Grüsse :-( Nicolas Rüegg
Hallo, Am Donnerstag, 23. Mai 2002 20:27 schrieben Sie:
Am Donnerstag, 23. Mai 2002 20:32 schrieb Nicolas Rüegg:
Hinzu kommt des weiteren, dass seit dem Update auf die proftpd-Version 1.2.5rc2 die "Timeout" Anweisungen in proftpd.conf nicht mehr berücksichtigt werden. User, deren Upload abgebrochen wurde bleiben nun unendlich lange auf dem System, obwohl diese wohl die Verbindung schon längst wieder getrennt haben. :-(
ja. Dieses ist inwischen im CVS gefixt.
Wie lange geht es denn, bis sowas auch in der " *tar.gz-Version " gefixt ist, die von ftp-mirrors downgeloadet werden kann? Muss man da auf proftpd-1.2.5rc3 warten? Ich habe den Verdacht, das das Problem mit den 0 Byte grossen Dateien an der Firewall des Clients liegt, die im Active-Mode von FTP ev. den Kanal für die Befehle durchlässt, die Datenkanal-Verbindung vom Server zum Client jedoch verwirft. Konkret stelle ich mir das so vor: Der ftp-Server erstellt auf einen put-Befehl eine Datei, wartet dann aber vergeblich auf den Inhalt der Datei, da der Datenkanal vom Server zum Client garnicht zustande kommt. Wäre das eine mögliche Erklärung für das Phänomen der 0 Byte grossen Dateien? Ich werde mal den Loglevel von proftpd ein wenig höher stellen und mich nach verdächtigen Inhalten der Logdateien umsehen... Grüsse, Nicolas Rüegg
Am Samstag, 25. Mai 2002 22:54 schrieb Nicolas Rüegg: > Wie lange geht es denn, bis sowas auch in der " *tar.gz-Version " > gefixt ist, die von ftp-mirrors downgeloadet werden kann? > Muss man da auf proftpd-1.2.5rc3 warten? RC3 sollte diese Woche kommen. Wie gesagt, ich würde mir die CVS Version saugen, eine Anleitung dazu findest Du auf www.proftpd.org - ist nicht schwierig. > Wäre das eine mögliche Erklärung für das Phänomen der 0 Byte > grossen Dateien? Auf jeden Fall ! cu stonki -- Deutsche ProFTPD Dokumentation: http://www.stonki.de EFNET: #proftpd
Am Sonntag, 26. Mai 2002 10:41 schrieben Sie:
RC3 sollte diese Woche kommen. Wie gesagt, ich würde mir die CVS Version saugen, eine Anleitung dazu findest Du auf www.proftpd.org - ist nicht schwierig.
Sind die CVS-Versionen nicht teilweise instabil oder mit Sicherheitslöchern gespickt? Oder was spricht gegen die *.tar.gz-Versionen?
Wäre das eine mögliche Erklärung für das Phänomen der 0 Byte grossen Dateien?
Auf jeden Fall !
Dann ist ja gut. So ist zumindest mal die Hälfte meines Problemes gelöst. Wenn die Timeouts in proftpd.conf ab Version 1.2.5rc3 auch wieder funktionieren hab ich ja nur noch ein Problem :-) Nämlich jenes mit den *.gz Dateien, die teilweise nicht richtig übertragen oder abgespeichert werden. Dieses Problem ist jedoch schon seit längerem nicht mehr aufgetaucht. Die letzten paar Übertragungen solcher Dateien verliefen immer erfolgreich... Grüsse, Nicolas Rüegg
Am Sonntag, 26. Mai 2002 14:12 schrieb Nicolas Rüegg:
Sind die CVS-Versionen nicht teilweise instabil oder mit Sicherheitslöchern gespickt? Oder was spricht gegen die *.tar.gz-Versionen?
In den letzten Monaten gab es einen kleinen Entwicklungsstillstand, da der alte CVS Maintainer irgendwie verschwunden ist. Nun wurde der Code auf einen anderen CVS Server gepackt und seit ca. 2 Wochen werden systematisch die ganzen Bugs gefixt. Daher ist im Moment der CVS Code der aktuellste und sicherste. Nach dem Release von 1.2.5 (Sollte so diese Woche, nächste passieren) würde ich dann für produktive Systeme auch die Release vorschlagen, aber im Moment eben nicht....
übertragen oder abgespeichert werden. Dieses Problem ist jedoch schon seit längerem nicht mehr aufgetaucht. Die letzten paar Übertragungen solcher Dateien verliefen immer erfolgreich...
Ich hoffe, daß denn alles klappt. Halte mich auf dem laufenden ! cu stonki -- Deutsche ProFTPD Dokumentation: http://www.stonki.de EFNET: #proftpd
Hallo,
Ich hoffe, daß denn alles klappt. Halte mich auf dem laufenden !
Ach, ich habe mich leider zu Früh gefreut... das Problem mit den 0 Byte grossen Dateien und den anhaltenden Uploads ist doch noch nicht gelöst... Es scheint weder an der Firewall des Clients, noch an unserer Firewall zu liegen, da laut Security-Chef in den Logfiles der Firewall nichts geblocktes zu sehen sei. Ich habe dann Testweise proftpd mit den Optionen -n -d 5 gestartet, doch auch dies bringt mich nicht weiter, da auch hier keine Fehlermeldungen zu sehen sind (obwohl der Fehler während dieser Zeit ca. 4 mal auftrat!). Das einzige, was ich in den Ausgaben von "proftpd -n -d 5" beobachten kann ist, wie der Befehl "STOR Dateiname" an der Server übermittelt wird, dieser den Befehl an die Module weitergibt und danach warte ich vergebens auf die Bestätigung "x bytes transfered" in den Ausgaben. Ich sniffte dann noch nach allen Paketen die auf den ftp-Server kommen um herauszufinden, ob der Inhalt der Dateien überhaupt auf dem Server ankommt, oder ob Sie tatsächlich irgendwo auf der Strecke verloren gehen. Doch zu meinem Erstaunen kam der Dateiinhalt zumindest in zwei Fällen auf dem Server an, obwohl wieder ein 0 Byte grosse Datei erstellt wurde. Sorry für das lange Mail, aber ich dachte es wäre besser wenn ich gleich alles auftische, das mir bisher aufgefallen ist... Ratlose Grüsse :-( , Nicolas Rüegg
Hallo zusammen Das ganze Problem mit den 0 Byte grossen Dateien, die ab und zu beim uploaden auf den proftpd-Server entstehen (siehe frühere Mails), scheint schwerwiegender zu sein, als ich vorerst angenommen hatte. Aus diesem Grund wäre die Diskussion auf der Mailingliste von proftpd wohl eher angebracht. Falls eine Lösung gefunden wird, werde ich diese natürlich hier auf der Linux-Liste posten. Vielen Dank für eure Hilfe und Grüsse, Nicolas Rüegg
Hallo zusammen! Wie bereits vor ca. einem Monat versprochen hier nun die Lösung zu meinen proftpd-Problemen. Nun gut, Lösung ist ev. übertrieben. Entdeckung der Ursache währe wohl treffender ;-) Am Samstag, 18. Mai 2002 20:32 schrieb Nicolas Rüegg:
ich habe einmal mehr ein Problem mit proftpd. Und zwar folgendes: Das Speichern von Dateien auf dem ftp-Server funktioniert eigentlich gut, mit der Ausnahme von gepackten Dateien. z.B. *.gz Dateien. Bei Dateien in diesem Format passiert es meistens, dass diese auf dem ftp-Server fehlerhaft abgespeichert werden. d.h. wenn ich die original-Datei mit der Datei auf dem ftp-Server vergleiche, ist jene auf dem ftp-Server 2 Bytes kleiner als das Original und dadurch nicht mehr benutzbar. Entpacke ich die *.gz Datei jedoch und übertrage sie ungepackt auf den ftp-Server wird alles korrekt abgespeichert. An was könnte das liegen? Ich benutze die proftpd-Version 1.2.5rc2. Das Problem trat bei mir jedoch auch bei Version 1.2.5rc1 und 1.2.2 auf. Ich habe proftpd ohne sendfile() kompiliert. In /var/log/xferlog wird die übertragene Datei als komplett übertragen angezeigt.
Seitdem ich proftpd-1.2.5rc3 am laufen habe trat dieses Problem nie mehr auf. Soviel ich weiss gab es jedoch nie einen offiziellen Bug in dieser Richtung. Nun gut, hauptsache jetzt läufts richtig. Am Donnerstag, 23. Mai 2002 20:32 schrieb Nicolas Rüegg:
Das Problem hat sich jedoch ausgeweitet. Nun kommt es auch ab und zu vor, dass der Upload aus ungeklärten Gründen einfach abbricht, oder eine Datei von 0 Bytes Grösse erstellt wird (unabhängig vom Typ der Datei).
Hier war das Problem an der Firewall des Clients die allem Anschein nach Mühe mit active-ftp hatte. Des weiteren kam auch noch ein Problem bei unserer Firewall hinzu, die manchmal bestimmte Ports zurückwies, die jedoch für passive-ftp gebraucht worden wären. Die Datei wurde dadurch auf dem ftp-Server erstellt, doch auf den Inhalt wurde vergebens gewartet, da die Datenverbindung nicht geöffnet werden konnte. Leider hatte ich dem Firewall-Admin des Clients geglaubt, dass es nicht an seiner Firewall läge. Konnte ihm das Gegenteil erst durch sniffit beweisen :-) Grüsse, Nicolas Rüegg
participants (3)
-
Nicolas Rüegg -
Oscar Knapp - soly -
Stefan Onken