Reverse-Check beim FTP-Server

Autor	Nachricht
Verfasst am: 26.10.2005 [16:29]
sonnen-blume Themenersteller Dabei seit: 03.12.2004 Beiträge: 19	Weiß nicht, ob das Thema hier hin gehört. Da der Verbindungsaufbau zum Server per FTP lange (8 - 10 sec.) dauert, habe ich eine Anfrage beim Server Support gestellt und diese Antwort erhalten: Ist der Reverse-Check beim FTP-Server deaktiviert - wenn dieser aktiv wird, wird jede eingehende Verbindung auf Reverse-Lookups angetestet. Führt dies zu keinem Ergebnis, dauert die Anmeldung länger. Wo kann geprüft werden ob aktiv oder deaktiviert? Für die Antworten bedanke ich mich vorab!
	Profil
Verfasst am: 26.10.2005 [21:35]
joe Dabei seit: 07.04.2002 Beiträge: 1225	Welcher FTP-Server unter welchem Betriebsystem? Als allgemeine Aussage kann ich Dir nur sagen: einen Blick ins (meist gut dokumentierte) Config-File zu werfen und im Manual nachzuschlagen, kann zur Lösung solcher Probleme beitragen. Schau auch mal ins Logfile. Wenn dort ausschließlich die IP-Adressen der Clients stehen, dann wird ziemlich sicher kein Reverse Lookup ausgeführt (oder die von Dir verwendeten Nameserver taugen nichts). Findest Du dort auch Hostnamen von Clients, dann wird definitiv ein Reverse Lookup ausgeführt. Der Reverse Lookup sollte aber in keinem Fall 8-10 Sekunden dauern. Normalerweise ist sowas in deutlich weniger als 500ms erledigt und geht nur in Ausnahmefällen mal über 1 Sekunde raus (und das auch nur dann, wenn der zuständige Nameserver einer von der langsamen Sorte ist). BTW: nur rein interessehalber... Welcher Support war das? cu Joe while(!asleep()) sheep++;
	Profil
Verfasst am: 27.10.2005 [11:39]
sonnen-blume Themenersteller Dabei seit: 03.12.2004 Beiträge: 19	Der Server steht bei star hosting. Das Problem: - Verbindungsaufbau zum Server per FTP dauert ca. 8 - 10 sec. - Bevor ein Kopiervorgang beginnt, dauert das ca. 6 sec. Egal welche Richtung. - Der Upload über einen Browser funktioniert meistens nicht. Es werden Dateien mit 0 kb angelegt. Auf anderen Servern ist beides ohne Probleme möglich! Egal ob strato, 1&1, server4you.de und hostnet.de, keine Probleme mit der Verbindung! Wir benutzen immer den WS-FTP-Pro und haben den FTP Zugang aus verschiedenen Städten Deutschlands getestet. Ebenfalls mit verschiedeneren Provider (alice, t-online, tiscali und nefkom) und schneller Leitung (6000 DSL). Wo kann das Problem liegen? Welche Möglichkeiten gibt es diese Problematik ausgiebig zu testen? So sieht ein Protokol "einer" Datenübertragung von "einer" Datei mit dem WS_FTP Pro aus: Anforderung wird abgearbeitet Weitere Verbindung zum FTP-Server konnte nicht hergestellt werden. Bestehende Verbindung wird für Übertragung genutzt. PASV Die Verbindung scheint abgebrochen zu sein. Es wird versucht, sie wiederherzustellen... Verbinden mit XXX.XXXX.XXXX.XXX:21 Verbunden mit XXX.XXXX.XXXX.XXX:21 in 0.010014 s, Warten auf Server-Antwort 220 ProFTPD 1.2.10 Server (Proftpd FTP Server (Webspace)) [XXX.XXXX.XXXX.XXX] Host type (1): Automatic detect USER web0 331 Password required for web0. PASS (hidden) Fehler beim Lesen der Antwort vom Server. Erneute Verbindung fehlgeschlagen. Die Verbindung ist abgebrochen. Die Verbindung ist abgebrochen. Es wird versucht, sie wiederherzustellen... Verbinden mit XXX.XXXX.XXXX.XXX:21 Verbunden mit XXX.XXXX.XXXX.XXX:21 in 0.010014 s, Warten auf Server-Antwort 220 ProFTPD 1.2.10 Server (Proftpd FTP Server (Webspace)) [XXX.XXXX.XXXX.XXX] Host type (1): Automatic detect USER web0 331 Password required for web0. PASS (hidden) 230 User web0 logged in. SYST 215 UNIX Type: L8 Host type (2): UNIX (standard) PWD 257 "/" is current directory. CWD html 250 CWD command successful CWD templates 250 CWD command successful Neue Verbindung ist in Ordnung. Vorgang wird fortgesetzt. TYPE A 200 Type set to A PASV 227 Entering Passive Mode (XXX,XXXX,XXXX,XXX,222,117). Verbinden des Datenkanals mit XXX.XXXX.XXXX.XXX:222,117(56949) Datenkanal verbunden mit XXX.XXXX.XXXX.XXX:222,117(56949) STOR index.html 150 Opening ASCII mode data connection for index.html 226 Transfer complete. - 31924 Bytes in 3.215 Sekunden übertragen, 77.585 Kbit/s ( 9.698 Kbit/s), Übertragung erfolgreich. Fertig: Beendet PWD 257 "/html/templates" is current directory. PASV 227 Entering Passive Mode (XXX,XXXX,XXXX,XXX,222,11. Verbinden des Datenkanals mit XXX.XXXX.XXXX.XXX:222,118(56950) Datenkanal verbunden mit XXX.XXXX.XXXX.XXX:222,118(56950) LIST 150 Opening ASCII mode data connection for file list - 2320 Bytes in 0.100 Sekunden übertragen, 180.989 Kbit/s ( 22.624 Kbit/s), Übertragung erfolgreich. 226 Transfer complete. lg Kristin [Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 27.10.2005 um 14:20.]
	Profil
Verfasst am: 27.10.2005 [23:15]
joe Dabei seit: 07.04.2002 Beiträge: 1225	Mal ein paar Gegenfragen, um Licht in die Sache zu bringen: 1.) Welcher Teil des Verbindungsaufbaus dauert denn genau so lang? Der Connect selbst geht ja schnell über die Bühne (0,01s). Aber dauert's dann lange, bis die Abfrage des Usernamens kommt, oder dauert's zwischen Username und Passwort lange oder erst nach Eingabe des Passworts? Du solltest auch mal testweise mit einem Kommandozeilen-FTP-Client testen. Diese komischen GUI-Clients machen meistens noch einen Haufen unnötigen Mist nach dem Login und bevor sie dann endlich den Verzeichnisinhalt anzeigen (z.B. die absolut unnötige automatische Erkennung des "host type" - Du weißt, daß es eine Linux-Kiste ist, also stell's in der Verbindungs-Definition einfach manuell auf Unix ein). Du kannst mir auch mal einen Test-FTP-Zugang freischalten (z.B. zusätzlicher FTP-User mit Zugriff auf ein leeres Dummy-Verzeichnis - geht mit Confixx ja schnell). Dann kann ich mir das morgen abend nach der Arbeit mal live anschauen. 2.) Kannst Du Probleme mit dem System an sich definitiv ausschließen (z.B. knappes bis überfülltes RAM bzw. Probleme mit der Festplatte [was sagt smartctl -a /dev/hda])? 3.) Wenn Du Files per SCP kopierst, dauert's dann auch so lange? Und wie sieht's bei Downloads per SCP aus? 4.) Wie ist Proftpd konfiguriert? Lauft er als Daemon oder wird er über (x)inetd gestartet? Wenn's über (x)inetd läuft, dann kann bei knappem RAM und hoher Last der Start des Programms schon mal eine Weile dauern. Also was sagt top (RAM, Swap und Load Average). <!--quoteo--><div class='quotetop'>ZITAT</div><div class='quotemain'><!--quotec-->Welche Möglichkeiten gibt es diese Problematik ausgiebig zu testen?<!--QuoteEnd--></div><!--QuoteEEnd--> Bei solchen Dingen versuche ich andere Ursachen erst mal vollständig auszuschließen (wie bereits erwähnt: Hardware-Probleme, überfülltes RAM). Wenn damit soweit alles OK ist, dann setz ich mich vor die Kiste und laß einen "tail -f" auf das entsprechende Logfile los und schau mal ein Weile zu, was so abgeht (das können auch mehrere Stunden sein!). Das kannst Du Dir aber auch etwas einfacher machen, indem Du eine ruhige Zeit aussuchst (oder vorübergehend Verbindungen zum entsprechenden Dienst nur noch von Deiner IP erlaubst). Du stellst dann selbst Verbindungen her und verfolgst dann im Endeffekt nur die Logs Deiner eigenen Versuche. Das hat den Vorteil, daß Du Client und Server gleichzeitig beobachten kannst, ohne daß ständig "fremde" Log-Einträge dazwischenfunken. cu Joe while(!asleep()) sheep++;
	Profil
Verfasst am: 28.10.2005 [01:01]
sonnen-blume Themenersteller Dabei seit: 03.12.2004 Beiträge: 19	zu 1.) a) FTP-Zugang - Verbindungs-Definition auf UNIX Standard eingestellt. b) Den Testuser wird morgen Thomas einrichten, dazu hat er gerade eine Email erhalten Erreiche ihn nicht mehr, wahrscheinlich am schlafen! c) neues Verbidungsprotokoll: WINSOCK.DLL: WinSock 2.0 WS_FTP Pro, Version 8.03, 2003.12.16 Verbinden mit 217.20.122.14:21 Verbunden mit 217.20.122.14:21 in 0.000000 s, Warten auf Server-Antwort 220 ProFTPD 1.2.10 Server (Proftpd FTP Server (Webspace)) [217.20.122.14] Host type (1): UNIX (standard) USER web0 331 Password required for web0. PASS (hidden) 230 User web0 logged in. Host type (I): UNIX (standard) Befehl FEAT wird gesendet, um zu ermitteln, welche Funktionen der Server unterstützt. FEAT 211-Features: MDTM REST STREAM SIZE 211 End Antwort auf Befehl FEAT fertig interpretiert. Der Befehl FEAT braucht nicht unbedingt gesendet zu werden. Er kann in den Einstellungen des Server-Profils deaktiviert werden. PWD 257 "/" is current directory. TYPE A 200 Type set to A PASV 227 Entering Passive Mode (217,20,122,14,140,79). Verbinden des Datenkanals mit 217.20.122.14:140,79(35919) Datenkanal verbunden mit 217.20.122.14:140,79(35919) LIST 150 Opening ASCII mode data connection for file list - 433 Bytes in 0.040 Sekunden übertragen, 84.449 Kbit/s ( 10.556 Kbit/s), Übertragung erfolgreich. 226 Transfer complete. zu 2.) smartctl -a /dev/hda --> bash: smartctl: command not found Wo ist der Befehl zu finden? Die ich fragen könnte, schlafen alle! Toll! Daher kann ich das Ergebnis erst morgen nachreichen zu 3.) Sehr guter TIPP! Mit SCP (WinSCP) ist die Verbindung und Übertragung sehr schnell! Daher muss das problem am FTP liegen! zu 4.) TOP Ergebnis: top - 03:03:11 up 15 days, 19:05, 1 user, load average: 0.96, 0.35, 0.23 Tasks: 65 total, 2 running, 63 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7% us, 0.7% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 483808k total, 454056k used, 29752k free, 148248k buffers Swap: 2096472k total, 0k used, 2096472k free, 83088k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11238 www-data 16 0 22204 10m 17m S 1.0 2.3 0:00.19 apache2 1 root 16 0 1504 512 1352 S 0.0 0.1 0:03.32 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/0 4 root 5 -10 0 0 0 S 0.0 0.0 0:03.04 events/0 5 root 11 -10 0 0 0 S 0.0 0.0 0:00.00 khelper 6 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid Gute Nacht!
	Profil
Verfasst am: 28.10.2005 [08:07]
joe Dabei seit: 07.04.2002 Beiträge: 1225	Nachdem SCP (und wahrscheinlich auch alles andere) schnell funktioniert, kannst Du Hardwareprobleme ausschließen. RAM und CPU-Last kann anhand von top auch ausgeschlossen werden (zumindest dann, wenn die Werte repräsentativ sind). Interessant wäre jetzt also noch, welcher Teil des Verbindungsausbaus lange dauert. Der TCP-Connect geht schnell und der User-Prompt kommt sofort (soweit konnte ich das schon testen ). Jetzt stellt sich die Frage, ob die Wartezeit nach der Eingabe des Usernamen oder erst nach Eingabe des Passworts auftritt. cu Joe while(!asleep()) sheep++;
	Profil
Verfasst am: 28.10.2005 [10:41]
sonnen-blume Themenersteller Dabei seit: 03.12.2004 Beiträge: 19	Aha, wie hast Du das getestet? Der TCP-Connect geht schnell und der User-Prompt kommt sofort. Zu: stellt sich die Frage, ob die Wartezeit nach der Eingabe des Usernamen oder erst nach Eingabe des Passworts auftritt. Dazu meine Frage: Was muss ich dafür tun? Den FTP-Zugang hast Du wahrscheinlich schon erhalten. Ich werde nachfragen. Lg Kristin
	Profil
Verfasst am: 29.10.2005 [00:18]
joe Dabei seit: 07.04.2002 Beiträge: 1225	Im Log oben steht die IP. Damit war's erst mal recht einfach, ne Verbindung aufzubauen. Zu mehr bin ich bisher aus Zeitmangel aber noch nicht gekommen. Um rauszufinden, welcher Teil lange dauert, mußt Du einfach Deinen FTP-Client beobachten. Der grafische Schnick-Schnack erschwert sowas natürlich, weil die eigentlichen Aktivitäten hinter einer GUI versteckt und meistens asynchron angezzeigt werden. Deswegen auch der Tip mit dem Kommandozeilen-FTP-Client in meiner ersten Antwort. Ich hab jetzt gerade gesehen, daß ich ne PM mit Zugangsdaten habe. Hab also gleich mal getestet... Auf dem Server scheint abends deutlich mehr los zu sein, als morgens um 07:00. Allein der Verbindungsaufbau dauert jetzt gut 7-10 Sekunden. Nach Eingabe des Benutzernamens dauert's nochmal min. 2-3 Sekunden, bis der Passwort-Prompt kommt. Nach Eingabe des Passworts dauert's nochmal etwa so lange, bis der Login abgeschlossen ist. Der File-Transfer in beide Richtungen klappt dann aber ohne Verzögerung und mit normaler Geschwindigkeit. Das läßt also auf eine hohe Last schließen. Und zwar min. eins von diesen: * Hohe CPU-Last (im top wenige Idle Time bei der CPU übrig) * Start vieler Prozesse in kurzer Zeit (im top hoher Load Average) * Deutlich überfülltes RAM Du solltest also mal zu den Zeiten, in denen FTP so langsam ist, die Kiste ein bisschen mit top beobachten. Interessant sind wie üblich: * freies RAM und Belegung des Swap-Space * Load Average * durchschnittliche CPU-Last * Anzahl aktiver Prozesse Darf man fragen, was das für eine Kiste ist (die wichtigsten Daten wie RAM, CPU usw.), was darauf alles läuft bzw. für was sie eingesetzt wird? Verbessern könntest Du die Situation z.B. dadurch, daß Du Proftpd nicht über inetd startest, sondern als Daemon laufen läßt und ihn -wenn möglich- schon mal einen kleinen Pool von Child-Prozessen spawnen läßt (also genau so, wie es Apache auch macht). Damit wird auf jeden Fall mal der Verbindungsaufbau beschleunigt, weil nicht für jede neue Verbindung erst mal ein neuer proftpd-Prozess angeworfen werden muß. Den Login wird das aber nicht beschleunigen. Und es stellt sich auch die Frage, ob Confixx damit nicht evtl. Probleme hat. cu Joe while(!asleep()) sheep++;
	Profil
Verfasst am: 29.10.2005 [11:02]
tom Dabei seit: 26.11.2004 Beiträge: 283	Hi Joe, ich blende mich mal mit ein. Da der Verbindungsaufbau wieder gedauert hat, habe ich soeben ein TOP gestartet: top - 12:53:59 up 17 days, 4:56, 1 user, load average: 0.10, 0.12, 0.09 Tasks: 64 total, 2 running, 62 sleeping, 0 stopped, 0 zombie Cpu(s): 7.3% us, 1.7% sy, 0.0% ni, 91.1% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 483808k total, 460436k used, 23372k free, 138008k buffers Swap: 2096472k total, 0k used, 2096472k free, 136100k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4119 www-data 16 0 22312 11m 17m S 4.0 2.3 0:01.42 apache2 4118 www-data 15 0 22756 11m 17m S 2.7 2.4 0:01.65 apache2 4172 www-data 17 0 22476 11m 17m S 1.0 2.4 0:00.62 apache2 1 root 16 0 1504 512 1352 S 0.0 0.1 0:03.49 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 3 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0 4 root 5 -10 0 0 0 S 0.0 0.0 0:03.04 events/0 5 root 11 -10 0 0 0 S 0.0 0.0 0:00.00 khelper 6 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid 33 root 5 -10 0 0 0 S 0.0 0.0 0:06.08 kblockd/0 43 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush 44 root 15 0 0 0 0 S 0.0 0.0 1:06.07 pdflush 45 root 15 0 0 0 0 S 0.0 0.0 1:15.86 kswapd0 46 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0 182 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kseriod 310 root 15 0 0 0 0 S 0.0 0.0 2:00.38 kjournald 759 root 15 0 0 0 0 S 0.0 0.0 0:00.00 khubd 963 root 22 0 0 0 0 S 0.0 0.0 0:00.00 pciehpd_event 983 root 25 0 0 0 0 S 0.0 0.0 0:00.00 shpchpd_event 1537 daemon 16 0 1612 556 1440 S 0.0 0.1 0:00.00 portmap 1880 root 16 0 2260 840 2092 S 0.0 0.2 0:27.11 syslogd 1883 root 16 0 2380 1492 1344 S 0.0 0.3 0:00.10 klogd 1903 root 16 0 2240 728 2084 S 0.0 0.2 0:00.00 inetd 1922 root 24 0 2508 1236 2380 S 0.0 0.3 0:00.02 mysqld_safe 1959 mysql 15 0 48592 19m 8920 S 0.0 4.1 3:05.75 mysqld 1960 root 15 0 1488 500 1332 S 0.0 0.1 0:00.00 logger 2108 root 16 0 6344 4068 3480 S 0.0 0.8 1:19.81 master 2144 root 18 0 6552 1580 6164 S 0.0 0.3 0:00.00 saslauthd 2146 root 18 0 6552 1580 6164 S 0.0 0.3 0:00.00 saslauthd 2147 root 18 0 6552 1580 6164 S 0.0 0.3 0:00.00 saslauthd 2148 root 18 0 6552 1580 6164 S 0.0 0.3 0:00.00 saslauthd 2149 root 18 0 6552 1580 6164 S 0.0 0.3 0:00.00 saslauthd 2155 root 16 0 3468 1508 3092 S 0.0 0.3 0:07.14 sshd 2159 root 18 0 2376 924 2204 S 0.0 0.2 0:00.00 rpc.statd 2166 root 16 0 5292 2468 4588 S 0.0 0.5 0:00.68 proftpd 2169 daemon 16 0 1684 628 1520 S 0.0 0.1 0:00.00 atd 2172 root 16 0 1764 816 1576 S 0.0 0.2 0:02.22 cron 2195 root 17 0 1500 484 1336 S 0.0 0.1 0:00.00 getty 2201 root 16 0 1500 484 1336 S 0.0 0.1 0:00.00 getty 2202 root 16 0 1500 484 1336 S 0.0 0.1 0:00.00 getty 2203 root 16 0 1500 484 1336 S 0.0 0.1 0:00.00 getty 2229 root 16 0 1500 484 1336 S 0.0 0.1 0:00.00 getty 2235 root 16 0 1500 484 1336 S 0.0 0.1 0:00.00 getty 13993 lp 18 0 2464 884 2272 S 0.0 0.2 0:00.00 lpd 3433 root 16 0 14452 2140 5824 S 0.0 0.4 0:00.01 sshd 3440 user 16 0 14620 2212 5824 R 0.0 0.5 0:00.34 sshd 3441 user 15 0 3012 1620 2708 S 0.0 0.3 0:00.00 bash 3446 root 15 0 3040 1644 2708 S 0.0 0.3 0:00.02 bash 3449 root 16 0 2064 1056 1852 R 0.0 0.2 0:02.09 top 4087 root 16 0 21332 9684 17m S 0.0 2.0 0:00.18 apache2 4089 root 16 0 3044 1364 2576 S 0.0 0.3 0:00.07 pipelog.pl 4090 www-data 15 0 22476 11m 17m S 0.0 2.4 0:00.79 apache2 4091 www-data 16 0 22756 11m 17m S 0.0 2.4 0:00.56 apache2 4093 www-data 16 0 22560 11m 17m S 0.0 2.4 0:00.79 apache2 4094 www-data 15 0 22744 11m 17m S 0.0 2.5 0:00.65 apache2 4100 postfix 17 0 2976 1168 2788 S 0.0 0.2 0:00.00 pickup 4101 postfix 16 0 3008 1196 2820 S 0.0 0.2 0:00.00 qmgr Wie kann der Proftpd als Daemon gestartet werden und nicht über inetd? Macht das Sinn, da der Server für ein Free Webspacescript genutzt wird und einige Mitglieder per FTP Zugang auf den zugewiesenen Mitgliederbereich sich einloggen. Wichtig ist, dass der Dateiupload über den Browser weiterhin funktioniert. Daher weiß ich nicht, ob der proftpd Dienst zwingend über indetd laufen muss. Oder ist das egal, hauptsache der Dienst läuft?
	Profil
Verfasst am: 29.10.2005 [22:16]
joe Dabei seit: 07.04.2002 Beiträge: 1225	Laut der Prozessliste im top scheint der proftpd sowieso als Daemon zu laufen. Zumindest ist da ein proftpd-Prozess, der als root läuft. Nachdem sich wohl niemand freiwillig per FTP als root anmeldet, dürfte das der Daemon sein. Die Last ist laut top mehr als im grünen Bereich. Da ist ja sogar noch massenweise Speicher frei und der Load Average liegt so weit im Keller, daß sich die Kiste zu diesem Zeitpunkt wohl doch ziemlich gelangweilt hat. So, nun aber wieder zum eigentlichen Problem: Es ist ja nicht nur der Login, der Zeit in Anspruch nimmt, sondern schon der Verbindungsaufbau bis zur Anzeige des Login-Prompts. Wenn man das mal per telnet etwas ausführlicher anschaut, dann sieht man, daß der TCP-Verbindungsaufbau schnell geht (nur ein paar ms), die Begrüßung von proftpd aber erst nach knapp 10 Sekunden kommt (und erst danach zeigt ein FTP-Client den Login-Prompt an). Da bedeutet also, daß proftpd nach den TCP-Connect knapp 10 Sekunden lang irgendwelches Zeug treibt, das unnötig lange dauert. Kurzer Blick in /etc/proftpd.conf. Dort sollten diese beiden Settings drinstehen: [code:1:c6aec97838]UseReverseDNS off IdentLookups off[/code:1:c6aec97838] Das schaltet Reverse Lookups (Hostname statt IP des Clients im Logfile) und Ident-Lookups (rausfinden des Usernamen auf der Client-Maschine) aus. Ident-Lookups kannst Du Dir sowieso komplett sparen. Eine Antwort wirst Du dabei nur von falsch konfigurierten Clients bekommen (sprich: User ohne NAT-Router und ohne Firewall). Reverse Lookups sind Geschmacksache. Normalerweise dauert sowas nicht besonders lange (<1s). Es macht aber auch keinen Sinn, wenn Du mit den Logs des FTP-Servers sowieso nichts anstellst. Je nach Konfiguration und Auslastung der in /etc/resolv.conf eingetragenen Nameserver, kann's Dir aber passieren, daß Du dabei regelmäßig in Timeouts läufst und das sorgt dann für Verzögerungen. Das kannst Du recht einfach testen, indem Du an der Shell des Servers selbst mal einen Reverse Lookup z.B. auf die öffentliche IP Deines Internet-Zugangs ausführst: "dig -x <IP-Adresse>". BTW: Auf der Kiste laufen ein paar Prozesse, die nicht wirklich nötig sind: * lpd * rpc.statd (nfslock) * portmap (wird benötigt für NFS und andere Dienste, die RPC benutzen) cu Joe while(!asleep()) sheep++;
	Profil