"FTP-Server"

[Christoph Schnauß]

hallo Forum ;-)

Ich habe vor wenigen Tagen verblüfft festgestellt, daß ich zwar einen HTTP-Server inzwischen ganz manierlich einrichten und betreuen kann, aber irgendwie mit FTP nicht klarkomme. Ich meine jetzt _nicht_, daß ich nicht wüßte, wie ich mir Software von einem der großen FTP-Server ziehen kann, das weiß ich schon ganz gut *g*

Ich wollte einfach mal in einem LAN auf dem Server nicht nur einen Apache haben, sondern eine "FTP-Site" einrichten, auf die dann die anderen Rechner mit ihren FTP-Client-Programmen zugreifen können. Als Beispiel: ich habe auf meinem "Server" eine SUSE 8.1 installiert. DHCP und DNS sowie der Apache funktionieren prima, auch WINDOWS-Clients können mitspielen. Prinzipiell ist es kein Problem, freigegebene Verzeichnisse der SUSE auf anderen Rechnern zu mounten, so daß man an sämtliche eventuell zur Verteilung vorgesehene Dateien zugreifen kann. Aber genau das will ich nicht.
Die SUSE 8.1 bringt eine "Beispiel-FTP-Umgebung" mit und legt im Verzeichnis /srv ein Unterverzeichnis /srv/ftp an  -  aber das wars dann auch schon. Im Handbuch stehen drei Zeilen, daß so ein Verzeichnis existiert. Und nun finde ich nix, was ich denn mit diesem Verzeichnis anfangen kann. Der Apache ist, denke ich, dafür schlicht unzuständig.

Ähnliches gilt übrigens auch für den IIS. Der legt bereits ein "Standard-FTP-Verzeichnis" an, aber auch an dieses Verzeichnis komme ich nicht heran, und in der MSDN hab ich nix gefunden.

Hat jemand nen Hinweis (auc Literaturhinweis), wie ich einen "FTP-Server" einrichten kann?

Einer der Hintergründe: ich habe im lokalen Netz mehrere "leere" Rechner, also noch ohne Betriebssystem. Auf dem Server liegt der Inhalt der SUSE-DVD, und ich möchte nun über eine "Remote-Installation" (weil die Clients keine CD-ROM-Laufwerke haben) die SUSE auf die anderen Rechner bringen. Mit ein paar Disketten kriege ich zwar den Zugriff hin, aber nun möchten meine Clients ie Sourcen von einer lokalen FTP-Adresse ziehen, und da hängt es. Wenn ich die Sourcen über eine "Webfreigabe" und über den Apache zugänglich mache, geht es bis zu den ersten YAST-Anzeigen auch noch ganz gut, aber dann hängen sich die Clients regelmäßig auf oder werden unendlich langsam und die Installation wird nicht zuende geführt. Ich nehme an, daß der Transport über HTTP einfach nicht das korrekte Mittel ist

Grüße aus Berlin

Christoph S.

[Christian Seiler]

Hallo Christoph,

Ich habe vor wenigen Tagen verblüfft festgestellt, daß ich zwar einen HTTP-Server inzwischen ganz manierlich einrichten und betreuen kann, aber irgendwie mit FTP nicht klarkomme.

Wenn Du mit dem "Standard"-FTP-Server nicht klarkommst, dann solltset Du vielleicht mal einen Blick auf http://pureftpd.sourceforge.net/ werfen.

Grüße,

Christian

[Christoph Schnauß]

hi Christian,

Wenn Du mit dem "Standard"-FTP-Server nicht klarkommst, dann solltset Du vielleicht mal einen Blick auf http://pureftpd.sourceforge.net/ werfen.

Das Teil wird von der SUSE sogar mit ausgeliefert, ist auf den CD's drauf, und ich habe es installiert. Das heißt, wenn ich mich bei meiner SUSE an den "Standard" halte (also noch keine Veränderungen an den Startscripten, am runlevel usw. vorgenommen habe), kann ich was auf /srv/ftp ablegen, und auf meinem "Server" wirds mir auch brav mit "ftp://localhost" gezeigt.
Nur nutzt mir das auf dem Rechner selber sehr wenig, auch wenns hübsch aussieht.Offenbar "sendet" mein Server nix.

Beispiel: wenn ich meinen Client mit den netzwerkfähigen Disketten starte, kriege ich (wenn es sich um einen WINDOWS-Client handelt) mit "net use x: \ServerIP\Sharename" das beim Server freigegebene Verzeichnis auf ein Laufwerk X gemountet und kann zugreifen  -  das heißt, die TCP/IP-Anbindung ist korrekt, und über UDP kann ich die Freigaben erreichen. Aber auf den SUSE-CD's gibt es kein "setup"-Programm mehr, das ich so aufrufen könnte ... Zugleich kann ich, weil meine Disketten natürlich auch FTP enthalten, mit "ftp" auf das FTP-Prompt gelangen. Tippe ich dann ein: "open ftp.suse.com" kriege ich sogar die Verbindung zum öffentlichen SUSE-FTP-Server (weil mein LAN vom Server ins Internet durchgeroutet wird).
Da will ich aber gar nicht hin. Ich will auf meinen Server. Also tippe ich (am Client) am FTP-Prompt: "open ServerIP" - das ist in diesem Fall eine 10.0.20.100. Es erscheint ein Hinweis "connect 10061" und das wars. %:(

Eigentümlich finde ich dieses "10061". Wenn das ein port sein soll, so gibts den zwar, aber es ist nicht der Standard-port für FTP. Und ich habe keine Ahnung, ob ich für mein Verzeichnis /srv/ftp auf dem Server noch irgendeine "Startdatei" (wie eine "index.htm" für meinen Apache) brauche.

Aufgabenstellung: ich will auf meinen Clients, die noch "leere" Platten haben, eine SUSE installieren (Remote-Installation). Die Clients starten von netzwerkfähigen Disketten. Auf meinem Server liegt in einem FTP-Ordner alles, was für die Installation benötigt wird. Am Client kriege ich YAST über HTTP so weit zum Laufen, daß ich nach der Installationsquelle gefragt werde. Ich muß also eine "FTP-Adresse", die für meinen Server gilt (10.0.20.100 ?) angeben. Dann würde wahrscheinlich YAST mit der Installation weitermachen, oder ich könnte mir mit "get" irgendwas auf die lokale Platte runterziehen ...

Grüße aus Berlin

Christoph S.

[Axel Richter]

Hallo,

kann ich was auf /srv/ftp ablegen, und auf meinem "Server" wirds mir auch brav mit "ftp://localhost" gezeigt.
Da will ich aber gar nicht hin. Ich will auf meinen Server. Also tippe ich (am Client) am FTP-Prompt: "open ServerIP" - das ist in diesem Fall eine 10.0.20.100. Es erscheint ein Hinweis "connect 10061" und das wars. %:(

Eigentümlich finde ich dieses "10061". Wenn das ein port sein soll,

Das ist ein socket error #10061 connection refused.

Läuft eine Firewall?

Gruß

Axel

[Christoph Schnauß]

hi Axel,

Eigentümlich finde ich dieses "10061". Wenn das ein port sein soll,
Das ist ein socket error #10061 connection refused.

habe ich eben gerade auch rausgefunden, war mir aber nicht sicher. danke für den Hinweis

Läuft eine Firewall?

Nö. Ist mit Gewalt rausgeschmissen worden, deprecated, deinstalliert ... bis das "Problem" bewältigt ist. Das Teil hinterher wieder aufzusetzen, ist kein Problem. Aber ich habe natürlich alle möglichen mir bekannten Störquellen erstmal deaktiviert.

Grüße aus Berlin

Christoph S.

[Axel Richter]

Hallo Christoph,

Versuch erst mal mit ps rauszubekommen, was überhaupt läuft.

Läuft wirklich pure-ftpd?
http://pureftpd.sourceforge.net/README

Auf SuSE 8.x ist, sweit ich weiß, vsftpd jetzt Standard.
Läuft vsftpd?
ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-1.1.3/INSTALL/

Gruß

Axel

[Christoph Schnauß]

hi Axel,

Versuch erst mal mit ps rauszubekommen, was überhaupt läuft.

guter Rat ... aber du willst doch nicht wirklich, daß ich jeweils die "Gesamtausgaben" von 'ps aux' und 'netstat -a' hier poste, gelle *g* ?

Läuft wirklich pure-ftpd?
http://pureftpd.sourceforge.net/README

ja, tut er.

Auf SuSE 8.x ist, sweit ich weiß, vsftpd jetzt Standard.

Naja, nur dann, wenn man keine Ahnung davon hat, daß man auch eine "manuelle Installation" durchführen kann. Ich hab das Ding gar nicht erst installiert, weil ich es bereits ne Weile kenne und nix davon halte. Das Teil wird zwar als "FTP-Dämon" beschrieben, hat sich bei mir aber bisher auch nur zu "Client-Funktionen" einsetzen lassen

Läuft vsftpd?
ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-1.1.3/INSTALL/

nein, läuft also nicht ... allerdings ist der Hinweis sehr berechtigt. Es mag möglich sein, mehrere FTP-Dämonen bzw. -Programme gleichzeitig laufen zu lassen, aber es könnte sich dadurch eine Konkurrenz um port 21 ergeben.

Grüße aus Berlin

Christoph S.

[Axel Richter]

Hallo Christoph,

Läuft wirklich pure-ftpd?
ja, tut er.

Und kommst Du nun von Clients aus drauf?

Rekapitulieren wir noch mal:
pure-ftpd wird von inetd bei Anfragen am ftp-tcp-Port (21) bedient. Das lese ich zumindest aus Deiner Korrespondenz mit Christoph Zurnieden heraus. In der /etc/inetd.conf steht also sowas wie:
ftp   stream   tcp   nowait   root   /usr/sbin/tcpd   /usr/local/sbin/pure-ftpd

Lokal, über ftp://localhost, läuft es auch.

Von Außen, also von einem Client, kommt aber der Socket Error 10061: No connection could be made because the target machine actively refused it. This usually results from trying to connect to a service that is inactive on the foreign hostthat is, one with no server application running.
Das ist noch _vor_ allen Berechtigungsprüfungen. Es heißt einfach: Dieser Dienst läuft nicht auf diesem Host.

Was kann das sein?
1. Eine Firewall-Regel. Das ist es allerdings, nach Deinen Aussagen, nicht.
2. Dein Client kann keine Verbindung herstellen.
 2.a ping [ServerIP] hast Du sicherlich probiert?
 2.b Der Client will nicht auf Port 21, sondern auf einen anderen Port zugreifen, der Server horcht aber nur an Port 21?

Gruß

Axel

[Christoph Zurnieden]

Hallo,

Ich wollte einfach mal in einem LAN auf dem Server nicht nur einen Apache haben, sondern eine "FTP-Site" einrichten, auf die dann die anderen Rechner mit ihren FTP-Client-Programmen zugreifen können. Als Beispiel: ich habe auf meinem "Server" eine SUSE 8.1 installiert. DHCP und DNS sowie der Apache funktionieren prima, auch WINDOWS-Clients können mitspielen. Prinzipiell ist es kein Problem, freigegebene Verzeichnisse der SUSE auf anderen Rechnern zu mounten, so daß man an sämtliche eventuell zur Verteilung vorgesehene Dateien zugreifen kann. Aber genau das will ich nicht.

Schade, denn das CDROM/DVD-Laufwerk zu mounten wäre das einfachste gewesen ;-)

Die SUSE 8.1 bringt eine "Beispiel-FTP-Umgebung" mit und legt im Verzeichnis /srv ein Unterverzeichnis /srv/ftp an  -  aber das wars dann auch schon. Im Handbuch stehen drei Zeilen, daß so ein Verzeichnis existiert. Und nun finde ich nix, was ich denn mit diesem Verzeichnis anfangen kann. Der Apache ist, denke ich, dafür schlicht unzuständig.

Es ginge, wäre aber nicht gar so gut. Das es gar nich funktioniert wundert mich, scheint aber wohl an Yast zu liegen, das einen FTP-Server erwartet.

Hat jemand nen Hinweis (auc Literaturhinweis), wie ich einen "FTP-Server" einrichten kann?

Was hast Du denn laufen? Was sagt die Manpage? Stimmen die Rechte der Dateien? Läuft der Server überhaupt? Sind die entsprechenden Programme (ls, gzip, tar, et cetera) statisch gelinkt (das Verzeichniss für FTP sollte chroot'ed sein) im entsprechendem Verzeichnis ($FTPROOT/bin oder $FTPROOT/usr/bin)? Ist der Port durch die Firewall gesperrt? Ist die Empfänger IP gesperrt/freigegeben? Läuft evt ein SFTP Protokol (probieren mit sftp, ist auf der Suse mit drauf)?

Zu den Literaturhinweisen: am besten die Dokumentation auf der Webseite des entspr Programmes (FAQ o.ä.). Es gibt aber IMHO auch ein FTP-HOWTO.

Nicht doch einfach nur die DVD mounten? ;-)

so short

Christoph Zurnieden

[Christoph Schnauß]

n'abends ;-)

Schade, denn das CDROM/DVD-Laufwerk zu mounten wäre das einfachste gewesen ;-)

ja klar, aber ich dachte mir, ich machs mir mal nicht ganz so einfach ;-)

Der Apache ist, denke ich, dafür schlicht unzuständig.
Es ginge, wäre aber nicht gar so gut. Das es gar nich funktioniert wundert mich, scheint aber wohl an Yast zu liegen, das einen FTP-Server erwartet.

scheint so. Wie beschrieben, läuft YAST zwar an, aber meine beabsichtigte Remote-Installation bleibt dann hängen.

Was sagt die Manpage?

ähm, welche?

Stimmen die Rechte der Dateien?

ja

Läuft der Server überhaupt?

jaein ... weiß nicht genau. Auf dem Server-Rechner selbst ist mit "ftp:// ..." im Konqueror was zu sehen

Sind die entsprechenden Programme (ls, gzip, tar, et cetera) statisch gelinkt (das Verzeichniss für FTP sollte chroot'ed sein) im entsprechendem Verzeichnis ($FTPROOT/bin oder $FTPROOT/usr/bin)?

tststs, also _das_ ist korrekt ;-)

Ist der Port durch die Firewall gesperrt?

nö. Firewall ist ganz und gar aus, deaktiviert, rausgeschmissen, verbannt ... bis das "Problem" geklärt ist.

Ist die Empfänger IP gesperrt/freigegeben? Läuft evt ein SFTP Protokol (probieren mit sftp, ist auf der Suse mit drauf)?

Empfänger-IP ist freigegeben, mein Server ist offen wie ein Scheunentor, SFTP läuft nicht.

Es gibt aber IMHO auch ein FTP-HOWTO.

ja, lese ich grade, werde aber noch nicht recht schlau draus

Nicht doch einfach nur die DVD mounten? ;-)

Nö. Warum denn einfach, wenns auch kompliziert gehen muß?
Außerdem hilft das nicht viel weiter. Ich habs an einem Client mal durchprobiert. Mounten geht prima, aber vom gemounteten "Laufwerk" kriege ich dann YAST nicht zum Laufen, bin zu dumm dafür. Wenn ich die DVD gemountet habe, ist ja schließlich der Bootvorgang bereits abgeschlossen, das heißt, die in den (BIOS)-Bootvorgang integrierten Startprozesse sind vorbei  -  ich habe keine initrd mehr usw.

so short

so long

Christoph S.

[Christoph Zurnieden]

Hallo,

Der Apache ist, denke ich, dafür schlicht unzuständig.
Es ginge, wäre aber nicht gar so gut. Das es gar nich funktioniert wundert mich, scheint aber wohl an Yast zu liegen, das einen FTP-Server erwartet.
scheint so. Wie beschrieben, läuft YAST zwar an, aber meine beabsichtigte Remote-Installation bleibt dann hängen.

Würde ich als Bug bezeichnen. Hilft Dir aber im Augenblick natürlich nix.

Was sagt die Manpage?
ähm, welche?

Die des Servers, der da läuft, wenn da denn einer läuft.

Stimmen die Rechte der Dateien?
ja

Auch nicht zuviele?
BTW: was sagt denn das Logfile des FTP-Servers? (Irgendwo unter /var/log sollte was zu finden sein)

Läuft der Server überhaupt?
jaein ... weiß nicht genau. Auf dem Server-Rechner selbst ist mit "ftp:// ..." im Konqueror was zu sehen

Ach, die Dateien werden ordungsgemäß gelistet? Kannst Du nur nicht runterladen?
Dann stimmt 'was mit den Rechten nicht. (Denk auch an die Rechte der Verzeichnisse!)

Sind die entsprechenden Programme (ls, gzip, tar, et cetera) statisch gelinkt (das Verzeichniss für FTP sollte chroot'ed sein) im entsprechendem Verzeichnis ($FTPROOT/bin oder $FTPROOT/usr/bin)?
tststs, also _das_ ist korrekt ;-)

Man übersieht manchmal die offensichtlichsten Sachen, sowas nennt man dann Betriebsblindheit und kann jedem passieren. Deshalb auch alle meine Fragen. Hast Du das kontrolliert? Nein? Tu's trotzdem mal.

Glaub's mir, ich kenn das ;-)

Es gibt aber IMHO auch ein FTP-HOWTO.
ja, lese ich grade, werde aber noch nicht recht schlau draus

Wenn Du mir den Link gibst und ein paar Fragen stellst, kann ich Dir sicherlich helfen.
Zumindest versuchen kann ich es ;-)
Sollte auch hier öffentlich sein, denn ich nehme an, sowas kommt öfters mal vor.
Wenn dann die Archivsuche wieder funktioniert (Kein Vorwurf, reine Feststellung der Tatsachen)  ...

Nicht doch einfach nur die DVD mounten? ;-)
Nö. Warum denn einfach, wenns auch kompliziert gehen muß?
Außerdem hilft das nicht viel weiter. Ich habs an einem Client mal durchprobiert. Mounten geht prima, aber vom gemounteten "Laufwerk" kriege ich dann YAST nicht zum Laufen, bin zu dumm dafür. Wenn ich die DVD gemountet habe, ist ja schließlich der Bootvorgang bereits abgeschlossen, das heißt, die in den (BIOS)-Bootvorgang integrierten Startprozesse sind vorbei  -  ich habe keine initrd mehr usw.

Das liegt dann an der Startdiskette. Aber das würde wohl zu weit führen, das hier zu klären.
War aber auch gottseidank nicht Deine Frage ;-)

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo Christoph,

ups, wenn ich sowas schreibe, kommts mir wie die Einleitung zu nem Selbstgespräch vor ...

Stimmen die Rechte der Dateien?
ja
Auch nicht zuviele?

huch ... da bin ich nicht sicher. Ich gehe normalerweise so vor: wenn ich ein Problem behandeln bzw. diagnostizieren will (und ich hab ja eins), setze ich alle Rechte normalerweise erstmal so niedrig wie möglich, also 777, und wenns dann geklappt hat, schränke ich sie Schritt für Schritt wieder ein

BTW: was sagt denn das Logfile des FTP-Servers? (Irgendwo unter /var/log sollte was zu finden sein)

Nix Verwertbares. Da schau ich eh immer zuerst nach

Läuft der Server überhaupt?
jaein ... weiß nicht genau. Auf dem Server-Rechner selbst ist mit "ftp:// ..." im Konqueror was zu sehen|
Ach, die Dateien werden ordungsgemäß gelistet? Kannst Du nur nicht runterladen?
Dann stimmt 'was mit den Rechten nicht. (Denk auch an die Rechte der Verzeichnisse!)

mit 777 sollte das alles erstmal "offen" sein. Gilt übrigens für den gesamten Tree.
Das "listing" kriege ich so aber nur auf meinem Server-Rechner, beim Client krieg ich das nicht

Man übersieht manchmal die offensichtlichsten Sachen, sowas nennt man dann Betriebsblindheit und kann jedem passieren. Deshalb auch alle meine Fragen. Hast Du das kontrolliert? Nein? Tu's trotzdem mal.

du hast völlig recht. Vom Apache bzw. vom HTTP-Browser kenne ich das  -  da ist es bereits vorgekommen, daß ich einfach vergessen habe, den Cache auszukehren und mich wunderte, wieso Aktualisierungen an HTML-Dokumenten nicht im Browser zu sehen waren *g*. Nein, es ist keineswegs verkehrt, die scheinbar "einfachsten" Fragen nochmal und nochmal zu stellen.

Glaub's mir, ich kenn das ;-)

Ich auch ;-)

Wenn Du mir den Link gibst und ein paar Fragen stellst, kann ich Dir sicherlich helfen.
Zumindest versuchen kann ich es ;-)

ja, danke, aber das verwirrt mich jetzt etwas. Du glaubst doch nicht, daß ich mein Problem mit einem Server und einem nachgeordneten LAN bei offener Internet-Connection zu lösen versuche? Ich hab den Server derzeit absolut ohne Sicherheitsmechanismen laufen, wenn ich den ins "Netz" hängen wollte, hättest du derzeit über die IP vollständigen Zugriff ... nö, das Ganze spiele ich momentan natürlich ohne Internetanbindung durch, und funktionieren soll es ja auch im LAN

Der Rechner, von dem aus ich grade schreibe, hat zwar Zugriff auf mein LAN, befindet sich aber in einem anderen Subnet und wird _nicht_ geroutet, solange er online ist ;-)

Sollte auch hier öffentlich sein, denn ich nehme an, sowas kommt öfters mal vor.

Es ist relativ selten, daß jemand "so eine Frage" stellt. Ich denke aber, mit dem Forums-Generalthema hats schon was zu tun.

Das liegt dann an der Startdiskette. Aber das würde wohl zu weit führen, das hier zu klären.
War aber auch gottseidank nicht Deine Frage ;-)

Meine Startdiskette(n) soll(en) nix andres tun, als ein Netzwerkinterface erkennen und die gewünschten Protokolle (TCP/IP, HTTP, FTP ...) zu aktivieren. Und das macht/machen sie auch.

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hallo,

Stimmen die Rechte der Dateien?
ja
Auch nicht zuviele?
huch ... da bin ich nicht sicher. Ich gehe normalerweise so vor: wenn ich ein Problem behandeln bzw. diagnostizieren will (und ich hab ja eins), setze ich alle Rechte normalerweise erstmal so niedrig wie möglich, also 777, und wenns dann geklappt hat, schränke ich sie Schritt für Schritt wieder ein

Das kann in's Auge gehen, siehe z.B. ~/.fetchmailrc, da tut es fetchmail nicht, wenn diese Datei zuviele Rechte hat.
(Zumindest _sollte_ fetchmail es dann nicht tun ;-)

BTW: was sagt denn das Logfile des FTP-Servers? (Irgendwo unter /var/log sollte was zu finden sein)
Nix Verwertbares. Da schau ich eh immer zuerst nach

Logging vom FTP-Server _völlig_ ausgeschaltet? Wenig wahrscheinlich, aber möglich.
BTW: welcher FTP-Server läuft denn nun?

(Entweder mittels 'ps auxwww | less' von Hand rausfummeln, oder z.B. mittels 'lsof | grep /srv/ftp' schauen, wer auf das Verzeichniss zugreift)

Läuft der Server überhaupt?
jaein ... weiß nicht genau. Auf dem Server-Rechner selbst ist mit "ftp:// ..." im Konqueror was zu sehen|
Ach, die Dateien werden ordungsgemäß gelistet? Kannst Du nur nicht runterladen?
Dann stimmt 'was mit den Rechten nicht. (Denk auch an die Rechte der Verzeichnisse!)
mit 777 sollte das alles erstmal "offen" sein. Gilt übrigens für den gesamten Tree.
Das "listing" kriege ich so aber nur auf meinem Server-Rechner, beim Client krieg ich das nicht

Aha, dann fehlt also irgendwo noch die Erlaubniss für andere Rechner. Schau in die Manpage des FTP-Serverprogrammes, welche Datei (evt eine eigene) dafür zuständig ist. Meistens liegt sowas unter /etc, könntest Dich evt da mal durchfummeln.

find /etc -type f -exec grep ftp {} ; -print | less

Der beis SuSE als Default eingerichtete FTP-Server ist vsftp, die zuständigen Dateien liegen unter /etc/vsftpd.conf.
Da ist übrigens, wie ich gerade sehe, auch das Logging auskommentiert. (Da ich keinen FTP-Server laufen habe, sollte diese Datei unberührt sein, kann mich zumindest nicht entsinnen ... ;-)

Eingeschaltet wird der übrigens per default (SuSE) über /etc/inetd.conf
Nach Änderungen in der Datei den inetd seine Conf neu einlesen lassen mittels (als root):

killall -HUP inetd

(Und wenn's nicht allzuviel Mühe macht: alles bei Gelegenheit mal auf xinetd umstellen ;-)

Manpage für vsftpd ist 'man vsftpd', bringt aber nix, sinnvoller ist da 'man vsftpd.conf'

Alles natürlich unter der Vorraussetzung, das vsftpd auch läuft.
Könnte übrigens auch daran liegen, das mehrere FTP-Server laufen. Dann dürfte zwar auch local keine Erfolg da sein, aber man weiß ja nie.

Wenn Du mir den Link gibst und ein paar Fragen stellst, kann ich Dir sicherlich helfen.
Zumindest versuchen kann ich es ;-)
ja, danke, aber das verwirrt mich jetzt etwas. Du glaubst doch nicht, daß ich mein Problem mit einem Server und einem nachgeordneten LAN bei offener Internet-Connection zu lösen versuche? Ich hab den Server derzeit absolut ohne Sicherheitsmechanismen laufen, wenn ich den ins "Netz" hängen wollte, hättest du derzeit über die IP vollständigen Zugriff ... nö, das Ganze spiele ich momentan natürlich ohne Internetanbindung durch, und funktionieren soll es ja auch im LAN

Äh ...?
Aaaah! ;-)
Nein, ich wollte nur den Link zu dem HOWTO, mit dem Du Schwierigkeiten hast.

Tststs, also, was denkst Du von mir? ;-)

Nein, einen Remot-Zugriff nehme ich nur an, wenn man es mir sehr teuer bezahlt. Den Ärger ist es sonst nicht wert.
Das geht alles schön über EMail bzw in diesem Fall dem Forum und "Machmal das, versuch mal dieses, schau mal dort.".
Ansonsten ist die Gefahr, das "ich es kaputtgemacht habe" zu groß. (Für 125 EUR/Std + MwSt mach ich hingegen gerne "etwas kaputt" ;-)

Der Rechner, von dem aus ich grade schreibe, hat zwar Zugriff auf mein LAN, befindet sich aber in einem anderen Subnet und wird _nicht_ geroutet, solange er online ist ;-)

Ja, das nennt man paranoid, das gefällt mir! ;-)
Aber nicht so schlimm, wie klien Schwester, die das (externe!) Modem ausstöpselt, bevor sie Windows bootet! ;-)

Sollte auch hier öffentlich sein, denn ich nehme an, sowas kommt öfters mal vor.
Es ist relativ selten, daß jemand "so eine Frage" stellt. Ich denke aber, mit dem Forums-Generalthema hats schon was zu tun.

Da das FTP-Protokol trotz aller Unzulänglichkeiten immer noch sehr weite Verbreitung hat, kommt da so manch einer in die Verlegenheit, sowas auch einrichten zu müssen.

Das liegt dann an der Startdiskette. Aber das würde wohl zu weit führen, das hier zu klären.
War aber auch gottseidank nicht Deine Frage ;-)
Meine Startdiskette(n) soll(en) nix andres tun, als ein Netzwerkinterface erkennen und die gewünschten Protokolle (TCP/IP, HTTP, FTP ...) zu aktivieren. Und das macht/machen sie auch.

Ja, ist ja auch in Ordnung. Das zu Ändern erfordert ein Neubasteln der Startdiskette und _das_ ist verdammt nicht einfach und sprengt wirklich den Rahmen.

so short

Christoph Zurnieden

[Christoph Schnauß]

hi,

huch ... Ich [...] setze ich alle Rechte normalerweise erstmal so niedrig wie möglich, also 777|
Das kann in's Auge gehen, siehe z.B. ~/.fetchmailrc, da tut es fetchmail nicht, wenn diese Datei zuviele Rechte hat. (Zumindest _sollte_ fetchmail es dann nicht tun ;-)

schon richtig, aber ich glaub, an der Rechtvergabe liegts nicht. Und fetchmail bzw. sendmail oder postfix (ersetzt bei SUSE 8.1 sendmail) ist ein gänzlich anderes Thema

BTW: was sagt denn das Logfile des FTP-Servers?
Nix Verwertbares
Logging vom FTP-Server _völlig_ ausgeschaltet? Wenig wahrscheinlich, aber möglich.

Nö, keineswegs ausgeschaltet, aber keine Fehlermeldung auf meinem Server. Der Client hat ja noch kein System, also auch kein log

BTW: welcher FTP-Server läuft denn nun?

dieses pure-ftp-Dingens. das schien mir nach allen Beschreibungen am vertrauenswürdigsten

(Entweder mittels 'ps auxwww | less' von Hand rausfummeln, oder z.B. mittels 'lsof | grep /srv/ftp' schauen, wer auf das Verzeichniss zugreift)

Das "listing" kriege ich so aber nur auf meinem Server-Rechner, beim Client krieg ich das nicht
Aha, dann fehlt also irgendwo noch die Erlaubniss für andere Rechner.

Da bin ich nicht sicher. Vergiß nicht, daß mein "Ausgangszustand" so ist, daß "andere Rechner" noch gar kein Betriebssystem haben, also auch gar nix mitloggen können.

Schau in die Manpage des FTP-Serverprogrammes, welche Datei (evt eine eigene) dafür zuständig ist. Meistens liegt sowas unter /etc

Nein. Unter /etc liegen die Konfigurationsdateien, wenn ich ne Doku bei der SUSE nachlesen möchte, muß ich nach /usr/share/doc/packages gehen und dort auswählen

Der beis SuSE als Default eingerichtete FTP-Server ist vsftp, die zuständigen Dateien liegen unter /etc/vsftpd.conf. Da ist übrigens, wie ich gerade sehe, auch das Logging auskommentiert

Ich hab vsftp gar nicht installiert. Wenn ich mir  -  egal ob mit SUSE oder RedHat oder Debian oder FreeBSD  -  einen Rechner neu einspiele, mache ich immer zuerst eine "Minimalinstallation" ohne alles Drumherum (vor allem ohne grafische Oberfläche), kontrolliere insbesondere die Netzwerkkonfiguration (bisher eben immer ohne FTP) und installiere dann den Rest, den ich eventuell für nötig halte, Schritt für Schritt nach. Auf einem Einzelplatzrechner übrigens auch grundsätzlich über FTP  -  wenn ein "Minimalsystem" vorhanden ist, funktioniert ja der Client-Zugriff auch auf die online stehenden großen FTP-Server gut.

Eingeschaltet wird der übrigens per default (SuSE) über /etc/inetd.conf

ja, der inetd ist so ein nicht leicht beherrschbarer Dämon ;-) Aber auf diese Art von Geisterbeschwörung verstehe ich mich inzwischen. Wenn da was verkehrt wäre, würde ich es mit dmesg schon angezeigt bekommen, spätestens mit dem Hinweis "unused". Sowas gibts aber nicht im syslog

Nach Änderungen in der Datei den inetd seine Conf neu einlesen lassen mittels (als root):

killall -HUP inetd

ich bevorzuge radikalere Mittel. Ich fahre erst ein 'init S', dann deinen killal-Befehl, dann fahre ich mit init 3 (oder init 5) das Netzwerk wieder an.

(Und wenn's nicht allzuviel Mühe macht: alles bei Gelegenheit mal auf xinetd umstellen ;-)

geht nicht, weil (noch) kein X-Server läuft. Der soll auf meinen "Server" eigentlich auch gar nicht drauf. Die Konsole reicht doch, oder ?

Der Rechner, von dem aus ich grade schreibe, hat zwar Zugriff auf mein LAN, befindet sich aber in einem anderen Subnet und wird _nicht_ geroutet, solange er online ist ;-)|
Ja, das nennt man paranoid, das gefällt mir! ;-) Aber nicht so schlimm, wie klien Schwester, die das (externe!) Modem ausstöpselt, bevor sie Windows bootet! ;-)

no comment *g*

Da das FTP-Protokol trotz aller Unzulänglichkeiten immer noch sehr weite Verbreitung hat, kommt da so manch einer in die Verlegenheit, sowas auch einrichten zu müssen.

eben. Und ich sehe auf absehbare Zeit keine wirklich mächtige Alternative dazu. Es gibt eine Vielzahl von Protokollen, die auf TCP/IP aufsetzen, und manche "Dinosuarier" darunter  -  wie FTP  -  sind irgendwie unverzichtbar

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hallo,

huch ... Ich [...] setze ich alle Rechte normalerweise erstmal so niedrig wie möglich, also 777|
Das kann in's Auge gehen, siehe z.B. ~/.fetchmailrc, da tut es fetchmail nicht, wenn diese Datei zuviele Rechte hat. (Zumindest _sollte_ fetchmail es dann nicht tun ;-)
schon richtig, aber ich glaub, an der Rechtvergabe liegts nicht. Und fetchmail bzw. sendmail oder postfix (ersetzt bei SUSE 8.1 sendmail) ist ein gänzlich anderes Thema

Es ging auch nur um Sicherheitseinstellungen, die teilweise eine zu großzügige Rechtevergabe mit Arbeitsverweigerung strafen.
(Das Sendmail ausgerechnet durch Postfix ersetzt wurde hat wahrscheinlich damit zu tun das Suse etwas mit IBM verbandelt ist, ebenso wie Postfix)

BTW: was sagt denn das Logfile des FTP-Servers?
Nix Verwertbares
Logging vom FTP-Server _völlig_ ausgeschaltet? Wenig wahrscheinlich, aber möglich.
Nö, keineswegs ausgeschaltet, aber keine Fehlermeldung auf meinem Server. Der Client hat ja noch kein System, also auch kein log

Dann evt das Logging hochsetzen, falls möglich oder *from source* mit eingeschaltetem Debugging bauen und Ausgaben beobachten.

BTW: welcher FTP-Server läuft denn nun?
dieses pure-ftp-Dingens. das schien mir nach allen Beschreibungen am vertrauenswürdigsten

Aha, na, dann kann man ja mal schauen.
BTW: vsftp soll die Abkürzung für "very secure FTP" sein, hört sich für mich vertrauenserweckender an, aber ich komm ja auch nicht von Windows >;->

Das "listing" kriege ich so aber nur auf meinem Server-Rechner, beim Client krieg ich das nicht
Aha, dann fehlt also irgendwo noch die Erlaubniss für andere Rechner.
Da bin ich nicht sicher. Vergiß nicht, daß mein "Ausgangszustand" so ist, daß "andere Rechner" noch gar kein Betriebssystem haben, also auch gar nix mitloggen können.

Sobald der andere Rechner gebootet hat, läuft da der Kernel, also ein vollständiges Betriebssystem. Da kann also alles geloggt werden, nur einrichten müßtest Du es noch.

Schau in die Manpage des FTP-Serverprogrammes, welche Datei (evt eine eigene) dafür zuständig ist. Meistens liegt sowas unter /etc
Nein. Unter /etc liegen die Konfigurationsdateien, wenn ich ne Doku bei der SUSE nachlesen möchte, muß ich nach /usr/share/doc/packages gehen und dort auswählen

Nein, ich meinte die Config-Dateien.
Die sind meist reichlich kommentiert.
Ob gut ist natürlich 'ne andere Frage ;-)

Der beis SuSE als Default eingerichtete FTP-Server ist vsftp, die zuständigen Dateien liegen unter /etc/vsftpd.conf. Da ist übrigens, wie ich gerade sehe, auch das Logging auskommentiert
Ich hab vsftp gar nicht installiert. Wenn ich mir  -  egal ob mit SUSE oder RedHat oder Debian oder FreeBSD  -  einen Rechner neu einspiele, mache ich immer zuerst eine "Minimalinstallation" ohne alles Drumherum (vor allem ohne grafische Oberfläche), kontrolliere insbesondere die Netzwerkkonfiguration (bisher eben immer ohne FTP) und installiere dann den Rest, den ich eventuell für nötig halte, Schritt für Schritt nach. Auf einem Einzelplatzrechner übrigens auch grundsätzlich über FTP  -  wenn ein "Minimalsystem" vorhanden ist, funktioniert ja der Client-Zugriff auch auf die online stehenden großen FTP-Server gut.

FTP zu saugen oder zu servieren ist ein gewaltiger Unterschied ;-)

Was mich die ganze Zeit aber stutzig macht: warum hast Du Dir nicht einen FTP-Server direkt von der Suse-Ditribution eingerichtet? Da das ganze eh intern ablaufen sollte, ist Sicherheit ja erstmal nur sekundär, solange Du, wie meine kleine Schwester, "den Stecker rausgezogen" hast.

Auha, "Sicherheit nur sekundär", und das ausgerechnet von mir, das tut weh! ;-)

Eingeschaltet wird der übrigens per default (SuSE) über /etc/inetd.conf
ja, der inetd ist so ein nicht leicht beherrschbarer Dämon ;-)

Ach, so schlimm ist es nicht.

Aber auf diese Art von Geisterbeschwörung verstehe ich mich inzwischen. Wenn da was verkehrt wäre, würde ich es mit dmesg schon angezeigt bekommen, spätestens mit dem Hinweis "unused". Sowas gibts aber nicht im syslog

Wieviel wird geloggt? (Suse unterscheidet 4 Stufen, in der 4. wird _alles_ mitgeloggt, mußt mal schauen, wo die die Einstellung dafür wieder hingepackt haben, steht aber meist in der zentralen Config: SuSE-Config o.ä.)

Nach Änderungen in der Datei den inetd seine Conf neu einlesen lassen mittels (als root):

killall -HUP inetd

ich bevorzuge radikalere Mittel. Ich fahre erst ein 'init S', dann deinen killal-Befehl, dann fahre ich mit init 3 (oder init 5) das Netzwerk wieder an.

Die modernen Versionen vertragen das Signal problemlos. Runlevel ändern ist nicht mehr nötig.

(Und wenn's nicht allzuviel Mühe macht: alles bei Gelegenheit mal auf xinetd umstellen ;-)
geht nicht, weil (noch) kein X-Server läuft. Der soll auf meinen "Server" eigentlich auch gar nicht drauf. Die Konsole reicht doch, oder ?

Der xinetd hat nichts mit X zu tun. Das 'x' von xinetd soll IMHO "extended" heißen. Macht das Gleiche, wie der inetd, aber besser und vor allem sicherer.

Da das FTP-Protokol trotz aller Unzulänglichkeiten immer noch sehr weite Verbreitung hat, kommt da so manch einer in die Verlegenheit, sowas auch einrichten zu müssen.
eben. Und ich sehe auf absehbare Zeit keine wirklich mächtige Alternative dazu. Es gibt eine Vielzahl von Protokollen, die auf TCP/IP aufsetzen, und manche "Dinosuarier" darunter  -  wie FTP  -  sind irgendwie unverzichtbar

Das größte Manko am FTP ist der Mangel an Sicherheit. S-FTP findet zwar immer weiter Verbreitung, aber viele Clients kommen noch nicht damit klar.

so short

Christoph Zurnieden

[Christian Kruse]

Hallo Christoph,

find /etc -type f -exec grep ftp {} ; -print | less

Uh.

grep -r ftp /etc (fuer das GNU-grep)

bzw.

grep -R ftp /etc (fuer das BSD-grep)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

find /etc -type f -exec grep ftp {} ; -print | less

Uh.

Oh?

grep -r ftp /etc (fuer das GNU-grep)

bzw.

grep -R ftp /etc (fuer das BSD-grep)

Zwei verschiedene? Mit Klammern zur Erklärung?
Nä, Danke, da nimm ich doch lieber meinen, der funktioniert überall und auch auf alten Systemen ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Hallo Christoph,

find /etc -type f -exec grep ftp {} ; -print |

less

Uh.
[...]
grep -r ftp /etc (fuer das GNU-grep)

bzw.

grep -R ftp /etc (fuer das BSD-grep)

Zwei verschiedene? Mit Klammern zur Erklärung?

Japs :)

Nä, Danke, da nimm ich doch lieber meinen, der
funktioniert überall und auch auf alten Systemen ;-)

Echt?

ckruse@sunshine:~ $ find /etc -type f -exec grep ftp {} ; -print | less
bash: less: command not found
ckruse@sunshine:~ $

Jaaa, ok, war jetzt gemein und fies, aber ich konnte mich
nicht beherrschen *g*

Uarhgs, da faellt mir ein, ich habe ja noch Mails im Outgoing
fuer dich liegen. Da setz ich mich heut abend gleich mal
dran.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Nä, Danke, da nimm ich doch lieber meinen, der
funktioniert überall und auch auf alten Systemen ;-)

Echt?

ckruse@sunshine:~ $ find /etc -type f -exec grep ftp {} ; -print | less
bash: less: command not found
ckruse@sunshine:~ $
Jaaa, ok, war jetzt gemein und fies, aber ich konnte mich
nicht beherrschen *g*

Nein, hast ja Recht. Das find und grep auf einem Unixsystem nicht vorhanden sind, ist recht unwahrscheinlich, aber das evt less nicht da ist, ist dagegen nicht so unwahrscheinlich. Es gibt bessere Pager, w3m z.B. (ja, das ist ein Pager, kein Textbrowser, mit dem ursprünglichem besonderem Feature, das es Japanische Schriften beherscht. Ist dadurch IMHO der einzige Textbrowser, der Japanische Fonts problemlos(!) anzeigen kann) und bei Platzmangel ist es durchaus möglich, das less rausgeschmissen wurde.

so short

Christoph Zurnieden

PS: "mehr als 25% zitierte Zeilen in ihrem Posting".
Ja isses denn?
Immer noch nicht die Zählweise repariert? ;-)
Hoffe, es sind jetzt genügend Zeilen ;-)
Übrigens: erstaunlich flott geworden!
CZ

[Christian Kruse]

Hallo Christoph,

Nein, hast ja Recht. Das find und grep auf einem
Unixsystem nicht vorhanden sind, ist recht
unwahrscheinlich,

Nicht so unwahrscheinlich ist leider eine unterschiedliche
Parameter-Belegung (wie man hier z. B. sieht, -R und -r).
Auch -print0 gab es zeitweise im BSD-find nicht (wurde
nachgeruestet).

aber das evt less nicht da ist, ist dagegen nicht so
unwahrscheinlich.

Jupp.

Es gibt bessere Pager, w3m z.B. (ja, das ist ein Pager,
kein Textbrowser,

Ja, darauf wird auf der Seite explizit drauf hingewiesen ;)

Ueberigens gibt es auch fuer less Input-Filter. Ich glaube,
es waere kein groesseres Problem, ein entsprechendes Plugin
fuer less zu schreiben.

mit dem ursprünglichem besonderem Feature, das es
Japanische Schriften beherscht. Ist dadurch IMHO der
einzige Textbrowser, der Japanische Fonts problemlos(!)
anzeigen kann) und bei Platzmangel ist es durchaus
möglich, das less rausgeschmissen wurde.

Auf Debian-Systemen z. B. ist es standardmaessig gar nicht
erst installiert.

PS: "mehr als 25% zitierte Zeilen in ihrem Posting".
Ja isses denn?
Immer noch nicht die Zählweise repariert? ;-)

Wie bereits gesagt :) Das ist volle Absicht :)

Übrigens: erstaunlich flott geworden!

Danke :) Ich habe das Konzept auch umgestellt, doch dazu
per Mail mehr.

Gruesse,
 CK