FTP Login dauert 20 Sekunden

  • Thread starter Thread starter gummel
  • Start date Start date
Hotgun said:
Stimmt, garantieren wirds Dir keiner, aber Micisoft würde eben nur schreiben: geht nicht. ;)

Stimmt.

Aber die Zeit, die ich mich schon mit Linux "vergnügt" habe, ist immens. Und immerwieder das gleiche: Irgendetwas geht nicht und wirklich NIEMAND hat darauf eine Antwort. Na klar, ist immer etwas besonderes und niemand kann alles wissen, aber da muß ich sagen: Gut das es Windows gibt.

Bei Windows ist sicherlich vieles sehr schlecht, aber ich habe in Null-Komma-Nix einen Fax-Server eingerichtet, einen FTP-Server aufgesetzt und mit Mercury einen Mailserver installiert, an den so schnell keine Linux-Progrämmchen herankommen. Noch dazu wartungsfreunlich und mit Funktionen, die man zwar bei Linux ebenfalls alle hat, aber ausnahmnlos alles per "Hand" zu programmieren ist.

Aber Schwamm drüber. Jedes System hat Macken.

Das FTP-Problem scheint eher eine Router-Problem zu sein. Vielleicht auch ein Problem zwischen bestimmten Routern und ProFTP. Aber ehrlich gesagt traue ich mich nicht, ProFTP einfach zu deinstallieren und WuFTP zu installieren... Der Ausgang ist mir einfach nicht vorhersehbar genug, obwohl der Erfolg ja eigentlich da sein könnte... Funktionierte ja alles mit RH7.3...

Nun denn, viele Grüße

Lars
 
Hi zusammen,

ich habe das bei mir folgendermaßen gelöst:

proftpd im xinetd deaktiviert, xinetd neu gestartet,
proftpd auf standalone umgestellt und die beiden Einstellungen
identlookups und reverse-dns abgeschaltet.

...läuft!

Gruß
Tim
 
Guten Morgen,

hier nochmal das Ganze ausführlich für server4downs :D.
Vorab: Die Verzeichnisangaben können natürlich von System zu System anders aussehen. Ich beziehe mich hier auf eine vServer-Installation bei S4F mit RedHat 9.0

In der Datei /etc/xinetd.d/proftpd setzt man den Wert disabled auf yes. Die Datei sieht dann so aus:

service ftp
{
disable = yes
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10​
}


Jetzt startet man den xinetd neu, damit dieser mitbekommt, dass sich die Konfiguration geändert hat. Das geht z.B. so:

service xinetd restart

oder so:

/etc/init.d/xinetd restart

Zur Info: Durch Deaktivieren des proftpd im xinetd, wird der FTP-Port frei, auf dem bisher der xinetd gelauscht hat.
Damit proftpd nun alleine laufen kann muss dieser als eigenständiger Dämon eingerichtet werden.

In der Datei /etc/proftpd.conf setzt man den Wert ServerType auf standalone. Dadurch weiss proftpd schonmal, dass er nicht von inetd/xinetd aufgerufen wird, sondern alleine auf dem FTP-Port lauschen muss.
Damit der FTP-Login schneller funktioniert, setzt man UseReverseDNS und IdentLookups auf off. Die Datei sieht dann so aus:


ServerName ??????.vserver.de
ServerType standalone
DefaultServer on
ServerAdmin technik@??????.vserver.de
ServerIdent on "FTP Server ready."

# Port 21 is the standard FTP port.
Port 21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30

# Set the user and group that the server normally runs at.
User nobody
Group nobody

TransferLog /var/log/xferlog

# Normally, we want files to be overwriteable.
AllowOverwrite on

#
# Do a chroot for web-users (i.e. public or www group), but
# do not change root if the user is also in the users group...
#
#DefaultRoot ~/public_html public,!users
#
DefaultRoot ~

# Groups that are not allowed to login
<Limit LOGIN>
DenyGroup poponly
</Limit>

UseReverseDNS off
IdentLookups off

### ENDE ####


Jetzt kann man durch den Aufruf von proftpd den Dämon starten. Beim nächsten Reboot wird man allerdings vergeblich versuchen, sich über FTP einzuloggen, denn der Dämon läuft dann nicht mehr. Dazu müssen wir ein Skript basteln, mit dem man den Dämon beim Booten starten kann.
Als erstes legt man die Datei /etc/init.d/proftpd an, die dann so aussieht:

#!/bin/sh
#
# chkconfig: 345 92 33
# description: Starts and stops the proftpd
# thx to the samba-team for the script ;)

PROFTP=/usr/sbin/proftpd

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

# Check that smb.conf exists.
[ -f /etc/proftpd.conf ] || exit 0

# See how we were called.
case "$1" in
start)
echo -n "Starting proFTPd: "
daemon $PROFTP
echo
touch /var/lock/subsys/proftpd
;;
stop)
echo -n "Shutting down proFTPd: "
killproc $PROFTP
rm -f /var/lock/subsys/proftpd
echo ""
;;
status)
status $PROFTP
;;
restart)
echo -n "Restarting proFTPd: "
$0 stop
$0 start
echo "done."
;;
*)
echo "Usage: proftpd {start|stop|restart|status}"
exit 1
esac


Ein kleines chmod 755 /etc/init.d/proftpd macht das Skript ausführbar.

Damit haben wir ersteinmal den Grundstein zum Starten/Stoppen/Neustarten des proftpds geschaffen. Jetzt müssen wir ihn nur noch über symbolische Links in die einzelnen Runlevel, vorzugsweise 3 und 5, eintragen. Z.B. folgendermaßen:

Starten von proftpd im Runlevel 3 (Voller Mulituserbetrieb mit Netzwerk):

cd /etc/rc3.d
ln -s /etc/init.d/proftpd S77proftpd


Stoppen von proftpd beim Wechseln in einen anderen Runlevel:

cd /etc/rc3.d
ln -s /etc/init.d/proftpd K10proftpd


Starten von proftpd im Runlevel 5 (Voller Multiuserbetrieb mit Netzwerk und KDM, GDM oder XDM):

cd /etc/rc5.d
ln -s /etc/init.d/proftpd S77proftpd


Stoppen von proftpd beim Wechseln in einen anderen Runlevel:

cd /etc/rc5.d
ln -s /etc/init.d/proftpd K10proftpd



Beim Booten des Systems sollte proftpd nun auch gleich mitgestartet werden.
Viel Spaß mit einem schnellen FTP-Login.

Gruß
Tim
 
Thanx man!!!
Funktioniert ausgezeichnet. Der Login rast wieder wie er es einst vor der Neuinstallation gemacht hat!
Das einzige was irgendwie nicht ganz will:
nach dem Reboot wird der FTP nicht automatisch gestartet, trotz des Scripts. Habe ich etwas falsch gemacht?
Ich habs mehrmals probiert.
Aber trotzdem vielen Dank erstmals!

Wäre es ansonsten auch möglich das irgendwie mit einem direkten Cronjob nach einem reboot hinzukriegen? Tut mir leid für diese lächerlichen Fragen. Bin wirklich noch ein Anfänger in Linux.
 
Versuch mal über /etc/init.d/proftpd start den Dämon zu starten.
Da wird dann entweder FAILED oder OK ausgegeben.

Danach sehen wir weiter.

Gruß
Tim
 
Vielen Dank Tim,

das hat super funktioniert!
Jetzt rennt die FTP Anmeldung nur so.


------------
Das glaub ich nicht Tim!


ich konnts mir nicht verkneifen :D :D
 
tim said:
Versuch mal über /etc/init.d/proftpd start den Dämon zu starten.
Da wird dann entweder FAILED oder OK ausgegeben.

Danach sehen wir weiter.

Gruß
Tim

So.. so...
nun wende ich mich auch mal wieder diesem "Problem" zu, aber Schule und Freunde gehen leider vor :)
Ich habe da glaub irgendwo nen kleinen Fehler gemacht im Script... nichts Weltbewegendes...
Aber danke für diese tolle Hilfe hier. Der FTP rast wie der Schumi.... und jetzt noch schneller, da ich DSL seit heute habe :-)
 
Und??? Hast Du den Fehler jetzt gefunden, oder start der proftpd immer noch nicht nach einem Reboot?
Lass uns den Fehler doch gemeinsam beheben, dann hast Du endlich Ruhe damit. :)

Gruß
tim
 
tim said:
Und??? Hast Du den Fehler jetzt gefunden, oder start der proftpd immer noch nicht nach einem Reboot?
Lass uns den Fehler doch gemeinsam beheben, dann hast Du endlich Ruhe damit. :)

Gruß
tim
Sag mal, bin ich eigentlich total dumb?
Ich hab alles brav nach Anleitung gemacht und so... aber erzählt mir was von:
: bad interpreter: No such file or directory
Echt komisch...
er findet die Datei /etc/init.d/proftpd net, aber ich kann sie öffnen und bearbeiten mit vi.
Wär cool, wenn mir einer helfen könntet.
Juchu... Ferien!!! Jetzt hab ich endlich Zeit für´s vServing, lol (und da braucht man ne Menge :) )
 
server4downs said:
er findet die Datei /etc/init.d/proftpd net, aber ich kann sie öffnen und bearbeiten mit vi.
Entweder fehlen der Datei die Ausführungsrechte oder Du hast einen Fehler in der Shebang-Zeile. ('bad interpreter' läßt letzteres vermuten.)

huschi.
 
Huschi said:
Entweder fehlen der Datei die Ausführungsrechte oder Du hast einen Fehler in der Shebang-Zeile. ('bad interpreter' läßt letzteres vermuten.)

huschi.
What mach ich denn da verkehrt?
Könnest du mir da bitte helfen. Was kann denn da an der ersten Zeile net stimmen? Muss ich da was anders angeben?
Ich denke auch das es sich um Letzteres handelt. Da ich aber alles korrekt kopiert hatte, konnte ich mir kaum vorstellen, dass da was falsch ist.
 
server4downs said:
Könnest du mir da bitte helfen. Was kann denn da an der ersten Zeile net stimmen?
Gerne, sobald Du schreibst, wie Deine erste Zeile aussieht... ;)

Da ich aber alles korrekt kopiert hatte
Hast Du darauf geachtet, daß Du es als Unix-Datei speicherst?
Das macht sich in den Zeilenumbrüchen bemerkbar:
WinDOS: CR-LF (==\r\n ==0x0D 0x0A)
Unix: LF (==\n ==0x0A)
MacOS: LF-CR (==\n\r ==0x0A 0x0D)

Die Shebang-Zeile mussssss im Unix-Format sein. Der Rest der Datei ist egal.

huschi.
 
O YES dude!!! It IS WORKING!! --> i can´t believe it!

Cool, man, danke!
Ich als Linux-Retard raff´s ja noch nicht so wahnsinnig.. lol...
gerade habe ich erstmal rausgekriegt, dass ich mir ja gar keinen Stress mehr für das Kopieren des Codes mehr geben muss... (-->rechte Maustaste in Putty). Und dann gings ohne Probleme!
Man... man... manchmal denk ich echt... warum einfach, wenn´s auch umständlich geht? :D
Naja, trotzdem THANX TO HUSCHI und vor allem aber auch TOM!
Dieses Board ist wirklich cool. Danke!
 
Hallo Tim,

danke für die Info. Ich sitze gerade bei meinem vServer ebenso vor diesem Problem.

tim said:
proftpd im xinetd deaktiviert, xinetd neu gestartet,
proftpd auf standalone umgestellt und die beiden Einstellungen
identlookups und reverse-dns abgeschaltet.

...läuft!

Gruß
Tim

Was ich nicht kapiere ist wieso der proftpd die beiden Kommandos nur wenn er "standalone" gestartet wird nutzt. Bei dem notorischen Speichermangel in einem vServer möchte ich nicht unbedingt neben dem xinetd noch einen weiteren Daemon rumlungern lassen. Das ist doch der Sinn der Sache das der xinetd die anderen bei Bedarf startet.

mfG
namtscho
 
namtscho said:
Hallo Tim,

danke für die Info. Ich sitze gerade bei meinem vServer ebenso vor diesem Problem.



Was ich nicht kapiere ist wieso der proftpd die beiden Kommandos nur wenn er "standalone" gestartet wird nutzt. Bei dem notorischen Speichermangel in einem vServer möchte ich nicht unbedingt neben dem xinetd noch einen weiteren Daemon rumlungern lassen. Das ist doch der Sinn der Sache das der xinetd die anderen bei Bedarf startet.

mfG
namtscho

Da wirst du wohl lange auf eine "xinetd-"Lösung warten müssen ;)
Ich glaube da gibt es leider keine Lösung für. Einen Tod muss man halt sterben.

uuuuuuuuuups.. srry, schau da mal. Vielleicht hilft das ja:
 
Last edited by a moderator:
Danke für den Hinweis.
server4downs said:
uuuuuuuuuups.. srry, schau da mal. Vielleicht hilft das ja:

Ich werde nun doch vorerst am Router den Port 113 freischalten. Ist dieser offene Port ein großes Sicherheitsrisiko?

mfG namtscho
 
Jeder offene Port ist ein 'risiko'. Allerdings ist das Problem: man kann den Port immer nur für eine IP / einen Clienten im LAN freischalten. Wenn du FTP von mehreren Rechnern aus nutzen willst, funktioniert die Sache mit dem Portfreischalten also nicht mehr.
Eine serverseitige Alternative findest du hier:
 
Das war der Link den auch server4downs empfohlen hat. Hab ich nun doch mal getestet. Funktioniert auch prima. Vermutlich für mein Office-LAN sicherer als den Port zu öffnen. Vielen Dank.

mfG namtscho
 
muss ich einfach nochmal sagen

auch wenn es ein alter Thread ist.
Nirgendwo im Netz diese Lösung gefunden!
Danke - ein halbes Jahr Suche hat ein Ende!

magelan2k
 
Back
Top