Hallo Leute, wir migrieren gerade im Rahmen eines HW-Wechsels einen FTP-Server von solaris zu SuSE (m. W. nach vsftpd). Dabei ist uns aufgefallen, dass sich beide Server bzgl. des ls-Output unterschiedlich verhalten: Solaris gibt lediglich eine Liste der Datei- und Dirnamen aus, während vsftpd scheinbar "ls -l" zurückgibt. In der manpage des vsftpd habe ich nichts zur Konfiguration des ls-output gefunden, hat eventuell jemand eine andere Idee, wo wir hier ansetzen könnten? Viele Grüße & danke im voraus, Uwe
In der manpage des vsftpd habe ich nichts zur Konfiguration des ls-output gefunden, hat eventuell jemand eine andere Idee, wo wir hier ansetzen könnten?
Wie es speziell beim vsftpd aussieht weiß ich nicht, aber du kannst ihm bestimmt eine chroot-Umegbung einrichten und dort ein (Standard-) ls deiner Wahl reinkopieren. Ansatzpunkt zum lesen: http://www.faqs.org/docs/securing/chap29sec296.html Grüße, Thomas -- Enlarge your Manhood! Free GPG now... Energy for your EMail, just try it. Be a brandnew man.
Am 28. September 2011 12:49 schrieb Uwe Schuerkamp <uwe.schuerkamp@gmail.com>:
Hallo Leute,
wir migrieren gerade im Rahmen eines HW-Wechsels einen FTP-Server von solaris zu SuSE (m. W. nach vsftpd). Dabei ist uns aufgefallen, dass sich beide Server bzgl. des ls-Output unterschiedlich verhalten: Solaris gibt lediglich eine Liste der Datei- und Dirnamen aus, während vsftpd scheinbar "ls -l" zurückgibt.
In der manpage des vsftpd habe ich nichts zur Konfiguration des ls-output gefunden, hat eventuell jemand eine andere Idee, wo wir hier ansetzen könnten?
Wenn es vsftpd ist: Nur im source code. Der Befehl "LIST" ist -l, der Befehl NLST ist ohne -l (in der Datei postlogin.c nach "handle_list" suchen und beim aufruf handle_dir_common die 1 durch eine 0 ersetzen) Die frage ist aber: Was ist verkert an dem Output?
Viele Grüße & danke im voraus,
Uwe
Gruss Jan -- Murphy's Law of Combat Rule #3: "Never forget that your weapon was manufactured by the lowest bidder"
Am 28.09.2011 19:56, schrieb Jan Seiffert:
Am 28. September 2011 12:49 schrieb Uwe Schuerkamp <uwe.schuerkamp@gmail.com>: Die frage ist aber: Was ist verkert an dem Output? Habe gerade mal in die RFC 959 geschaut. Da steht jedenfalls nicht, dass es "verboten" wäre mehr als nur die Namen zu senden, ganz im Gegensatz zu NLST, wo nur die Namen erlaubt sind.
Es spricht auch in meinen Augen nichts dagegen es so zu belassen und den Befehl positiv zu verkaufen: das kann sogar jetzt Zeitstempel ausgeben usw. und bei Problemen auf NLST zu verweisen. Wenn dann jemand aus dem Busch gehüpft kommt, das das vorher ja auch funktioniert hat und das ja z.B. als Standard erwartet war dann Verweis auf die RFC die es wohl noch nicht lange genug gibt (von 1985, hihi.) MfG... Pierre
Am 29. September 2011 08:07 schrieb Pierre Bernhardt <pierre@starcumulus.owl.de>:
Am 28.09.2011 19:56, schrieb Jan Seiffert:
Am 28. September 2011 12:49 schrieb Uwe Schuerkamp <uwe.schuerkamp@gmail.com>: Die frage ist aber: Was ist verkert an dem Output? Habe gerade mal in die RFC 959 geschaut. Da steht jedenfalls nicht, dass es "verboten" wäre mehr als nur die Namen zu senden, ganz im Gegensatz zu NLST, wo nur die Namen erlaubt sind.
Es spricht auch in meinen Augen nichts dagegen es so zu belassen und den Befehl positiv zu verkaufen: das kann sogar jetzt Zeitstempel ausgeben usw. und bei Problemen auf NLST zu verweisen. Wenn dann jemand aus dem Busch gehüpft kommt, das das vorher ja auch funktioniert hat und das ja z.B. als Standard erwartet war dann Verweis auf die RFC die es wohl noch nicht lange genug gibt (von 1985, hihi.)
Das Problem vom Standard aus gesehen ist: Der Standard sagt zu LIST nur, das es das gibt und ein listing auspuckt, aber nicht wie es aussieht. Der C Programmierer kennt das als "implementation defined behaivior", was eben nicht immer schoen ist, da man sich ja nicht "drauf verlassen" kann. Darum wurde wohl NLST nachgeschoben. Was jetzt die Frage aufwirft was genau Uwes Problem mit LIST ist: hat er a) ein Programm was nur den einfachen Output annimmt oder b) sorgen um die Daten die mit -l offen gelegt werden. (vielleicht noch c) erhoehter Datentransfer, aber bei FTP...)
MfG... Pierre
Gruss Jan -- Murphy's Law of Combat Rule #3: "Never forget that your weapon was manufactured by the lowest bidder"
Am 29.09.2011 09:13, schrieb Jan Seiffert:
Am 29. September 2011 08:07 schrieb Pierre Bernhardt <pierre@starcumulus.owl.de>:
Am 28.09.2011 19:56, schrieb Jan Seiffert:
Am 28. September 2011 12:49 schrieb Uwe Schuerkamp <uwe.schuerkamp@gmail.com>: Die frage ist aber: Was ist verkert an dem Output? Habe gerade mal in die RFC 959 geschaut. Da steht jedenfalls nicht, dass
Der Standard sagt zu LIST nur, das es das gibt und ein listing auspuckt, aber nicht wie es aussieht. Der C Programmierer kennt das als "implementation defined behaivior", was eben nicht immer schoen ist, da man sich ja nicht "drauf verlassen" kann. Sehe ich genau so. Man kann es halt nur als text ausgeben. Wenn der Server geändert wird, dann hat man ein Problem damit. Darum wurde wohl NLST nachgeschoben. Naja, wenn man diese RFC als erste des Protokolls betrachten möchte, dann würde ich sagen, es war schon immer drin ;-) Immerhin ist die RFC von 1985.
Was jetzt die Frage aufwirft was genau Uwes Problem mit LIST ist: hat er a) ein Programm was nur den einfachen Output annimmt oder b) sorgen um die Daten die mit -l offen gelegt werden. Ich denke, das da irgendwas wieder mal mit einem Programm geparst wird (Stichwort Screen Capture) und nun das da nicht mehr so steht, wie es erwartet wird. Wenn nur die Dateinamen erwartet werden, dann würde ich versuchen bei einem Programm statt LIST NLST zu verwenden und das LIST so zu lassen. Alternativ biegt Er einfach das LIST auf ohne -l um oder was auch immer vorher ausgegeben wurde.
Ich wollte aber mit meiner Mail nur eine Begründung liefern, dass bei Problemen mit Schnittstellenprogrammierer das entsprechend anzupassen. Die Anpassung von LIST auf NLST ist hier sogar noch recht einfach. Im Moment sehe ich das sogar so, dass solche Programme entsprechend konfiguriert werden können sollten ;-) Aber aus eigener Erfahrung weiss ich, dass vieles nicht nachgelesen wird, sondern dem Motto, was funktioniert wird eingeführt, vorgegangen wird. Ich bin da manchmal auch nicht besser, aber solche Tools werden dann auch nur von mir selber verwendet und dienen einfach nur dazu 20 Manuelle Handgriffe zu vereinfachen. Aber diese Tools brechen dann auch eigentlich immer ab, wenn plötzlich was unerwartetes passiert, z.B. statt einem Datum in einem definierten Format eine Größenangabe oder so zurück kommt ;-) MfG... Pierre
Hallo Leute, vielen Dank für eure Antworten. Ich habe gerade Antwort aus dem irc-Channel bekommen, es sieht wohl so aus, als verhielte sich vsftpd RFC-konform und der Solaris-ftpd eben nicht, daher stammt die Diskrepanz in den Ausgaben von "ls". Ich meinte mich zu erinnern, dass proftpd eine Konfiguration von "ls" zulässt. Da wir die Systeme nicht selber hosten, ist ein "Eigenbau" von vsftpd leider nicht möglich... da müssen wir dann wohl ein paar Scripte anpassen. Viele Grüße & danke nochmal für die Kommentare, Uwe
Teilnehmer (4)
-
Jan Seiffert
-
Pierre Bernhardt
-
Thomas Findeisen
-
Uwe Schuerkamp