Hallo "NifNaV",

das war durchaus nicht persönlich gemeint.
Aber Du mußt schon mitdenken und mithelfen und kannst nicht erwarten, daß wir das für Dich tun.
Der ProFTPD ist bei Dir zumindest nicht mehr im Suchpfad und wenn Du nun den PureFTPd installiert
hast, dann bist Du hier damit an völlig falscher Stelle. Wir können Dir damit nicht weiterhelfen, denn
das ist eine ganz andere Softwarelösung als der ProFTPD.

mfg.
  VolGas

Nein, daran kann es nicht liegen.
Außerdem ist der pureFTPd und der ProFTPD zwei gänzlich unterschiedliche FTP-Server.
Und was wird wohl "command not found" heißen?

Wenn Du nicht einmal weißt, welchen Server Du im Einsatz hast, scheinbar absolut keine
Linux-Grundkenntnisse hast und wohl auch nicht gewillt bist, dies zu ändern und auch nur
drei Gehirnzellen gleichzeitig dafür zu nutzen, dann sehe ich absolut keinen Sinn, diesen
Thread hier weiter zu führen.

Das kann ja wohl alles nicht wahr sein!
Du verschwendest Stonki's, meine, und die Zeit aller, die dies hier lesen.

Aus diesem Grund schließe ich hiermit diesen Thread eigenmächtig.
(Stonki, ich hoffe, Du bist mit der Aktion einverstanden!)

Das heißt aber nicht, daß wir Dir hier nicht hefen wollen:
Wenn Dir irgendwann klar ist, was Du da auf Deiner Maschine hast und dann eine konkrete
Frage zum ProFTPD hast, die nicht schon in der FAQ beantwortet ist, kannst Du ja hier wieder
einen neuen Thread eröffen.

mfg.
  VolGas

Meine Güte!
Hast Du die FAQ in diesem Punkt nicht richtig gelesen?
Dann ist Dir sicher aufgefallen, das der "d"-Parameter alleine nicht reicht!
Um es abzukürzen: mit z.B. "proftpd -nd5" klappt es!

mfg.
  VolGas

Hallo,

wie kommst Du nur auf "./configure --with-modules=quotatab-modules" ?
Solch ein Modul gibt es nicht. Die mitgelieferten Module findest Du in Source-Verzeichnis "contrib"
und nur diese Dateinamen (ohne die Endung) können als Modulname bei "configure" angegeben
werden. In Deinem Fall wohl also: ./configure --with-modules="mod_quotatab:mod_quotatab_file"

Siehe auch: "README.modules"...

mfg.
  VolGas

RequireValidShell           off

ist bereits in der Config so geschrieben  aber dthx
Daran liegt es nicht ...

Steht zwar drin, ist aber auskommentiert!
Entferne das "#" davor!
Daran leigt es wohl.

mfg.
  VolGas

Hallo!

Keine Sorge, mit dem Problem bist Du hier richtig.
Wenn Du den ProFTPD des Debian-Systems hast, dann wird dieser automatisch mit allem
anderen auch aktualisiert. ("apt-get update", dann "apt-get upgrade")

Den Fehler, den du beschreibst, ist typisch dafür, daß kein Datenkanal aufgebaut werden kann.
Hast Du eine Firewall bzw. regelt IPTables den Zugang oder hast Du eine NAT (Router) auf
der Servermaschine oder irgendwo zwischendrin?

mfg.
  VolGas

Hallo,

ich habe nur mal kurz darübergesehen - versuche es einmal mit "RequireValidShell off".

mfg.
  VolGas

Das hattest Du schon geschrieben.
Mir war nur nicht klar, welche Userdaten gemeint sein konnten: Userdaten aus XAMPP oder
Logindaten...

Ich habe mir die Website von XAMPP angesehen und auch das Paket heruntergeladen und
ausgepackt. Nun weiß ich, was Du meinst.

So wie der ProFTPD konfiguriert ist, läßt er jeden User zu, der im System registriert ist.
Da brauchst Du nichts weiter zu tun.

Aber: der ProFTPD ist nur sehr oberflächlich und -Verzeihung!- mies konfiguriert.
Als aller erstes solltest Du unbedingt (!!!) in der Konfigurations-Datei (wenn ich mich nicht irre:
/opt/lampp/etc/proftpd.conf) die Zeile "UserPassword nobody wRPBu8u4YP0CY" deaktivieren -
oder besser gleich endgültig löschen.

Zur weiteren Sicherheit würde ich Dir empfehlen, eine User-Gruppe (z.B. ftpuser) einzurichten
und nur User dieser Gruppe den FTP-Zugang erlauben.

Das läßt sich relativ einfach einrichten, füge der proftpd.conf nur folgende drei Zeilen hinzu:

  <Limit LOGIN>
    DenyGroup !ftpuser
  </Limit>

Anschließend ändere noch die Zeile "DefaultRoot /opt/lampp/htdocs" zu: "DefaultRoot ~".
Fertig ist eine minimale, aber funktionsfähige Konfiguration.

mfg.
  VolGas

Ich habe nach FXP gegoogelt und bin -was für (gar k)ein Wunder!- bei Wikipedia
auf eine gute und einfache Antwort gestoßen: http://de.wikipedia.org/wiki/File_Exchange_Protocol
Ich liebe Wikipedia!

Vielleicht hilft Dir das bei der Fehlersuche weiter...
...hoffentlich!

mfg.
  VolGas

Hi,

ich hatte noch nie etwas mit FXP zu tun, aber wenn ich die Debug-Logs ansehe,
dann sieht es so aus, als wären beide FTP-Server auf ein und der selben IP?

Der passive mode wird auch nur zu Deinem Client gesetzt, nicht zu einem anderen Server:

  Entering Passive Mode (84,16,224,142,238,7).
  ...
  passive data connection opened - local  : 84.16.224.142:60935
  passive data connection opened - remote : 172.158.63.166:64380
  ...
  Entering Passive Mode (84,16,224,142,195,66).

Ein "STOR" oder "RTFR"/"RNTO" konnte ich auch nicht sehen...
Ich will Dir ja nicht zu nahe treten, aber hast Du da nicht etwas durcheinander gebracht?

mfg.
  VolGas

Hallo!

Eigentlich gar nicht.
Poste doch hier einmal ein Verzeichnislisting aus der Shell mit "ls -al".

Deine proftpd.conf würde ich noch wie folgt ändern:

• "DefaultRoot ~" alleine ist ok, eine weitere Beschränkung auf "ftpuser" unsinnig, da sowieso
  kein User einer anderen Gruppe einloggen kann. Zur Sicherheit würde ich "ftpuser" entfernen.
• "RequireValidShell" prinzipiell auf "off"
• das Einkapseln der zwei Anweisungen in einen "<Global>"-Block ist hier sinnlos - kann entfernt werden
• "GroupOwner ftpuser" - hmm, warum das denn?
  Sind nicht alle User primär in dieser Gruppe?
  Wenn ja, kannst Du den ganzen Block entfernen - der könnte nämlich Grund Deines Problems sein.

Das war eigentlich nichts gravierendes, Deine proftpd.conf sieht bis auf diese "Schönheitsfehler"
unauffällig und recht gut aus. Mein erster Verdacht war eine falsch gesetze "umask", aber die ist so ok.

Wie bereits erwähnt: sieh' Dir mal so ein Verzeichnis an, welche Rechte und welchem User / welcher Gruppe
das neue Verzeichnis wirklich zugeordnet wurden.

mfg.
  VolGas

Hallo!

Wenn Du hier fragst, was in XAMPP möglich ist (oder auch nicht), dann bist Du im falschen Forum.
Vielleicht war die Frage aber nur flasch gestellt und bevor aber das Ganze gleich abgewürgt wird:
um welche Daten geht es denn überhaupt?

mfg.
  VolGas

Die User können den Unterschied gar nicht bemerken - das Login ist -soweit ich weiß-
immer gleich, egal welches Verfahren verwendet wird...

mfg.
  VolGas

Hallo!

Gleich die Gegenfrage: warum eigentlich PAM?

Per Default holt sich der ProFTPD alles was er braucht aus dem System, sprich: /etc/passwd.
PAM ("Pluggable Authentication Modules") ist gar nicht in der Lage, alle benötigten Daten zu
liefern, sondern überprüft nur, ob ein Passwort zu einem Usernamen passt - es kann dem
ProFTPD weder UID/GID, noch die Gruppenzugehörigkeit(en) und auch keine HomeDir-Info
liefern. Das ist auch der Grund, weshalb die Beschränkung via "AuthOrder" alleine auf das
PAM-Modul des ProFTPD nicht funktionieren kann.

Durch die Benutzung von PAM wird IMHO nichts besser oder sicherer - nur komplizierter.
Wenn Du FTP-Accounts nur bestimmten Usern erlauben möchtest, so kannst Du das z.B.
durch die Zugehörigkeit zu einer bestimmten Gruppe erzwingen.

Oder Du arbeitest mit virtuellen Usern - der elegantere Weg.
Mit dem Modul "mod_auth_file" geht das sogar so, wie Du das bislang lösen wolltest: mit
einer eigenen, vom System unabhängigen passwd-Datei. Siehe dazu ->AuthUserFile
oder: ->Mini-HOWTO discussing use of AuthUserFiles

Nochmal zu PAM: die Doku dazu findest Du ->hier

mfg.
  VolGas

Hallo nadine,

ich antworte erst jetzt, da ich hoffte, daß jemand anderes eine Antwort darauf hat, denn ich
habe dazu nur eine Vermutung:

"NLIST" alleine gibt das Listing so aus, wie es die "ListOptions" vorgeben.
Mit "NLIST *" startet man vermutlich eine "regular expression" (RegEx), die nach dem
passenden Muster sucht. Die beiden Verzeichnisse "." und ".." passen nie, denn sie sind nur
unsichtbare Pseudo-Einträge.

Vergleicht man das FTP-Commando "NLIST" mit dem Shell-Kommando "ls" mit Sternchen,
ergibt sich wieder etwas ganz anderes: die Shell versucht zuerst das Jockerzeichen mit den
passenden Datei- und Verzeichnisnamen zu ersetzen. Als Ergebnis erhält man damit sogar ein
rekursives Listing einer Dateiebene.

Auf "NLIST *" sollte man vielleicht sogar ganz verzichten, bei unserer Serverkonfiguration
erhalte ich nur ein: 450 *: Not a regular file

Ich erlaube mir die Frage: was hast Du für ein Problem, daß Du sogar nach Um- und Auswegen
suchst, nur um weiterhin die beiden Pseudoeinträge zu erhalten, die eigentlich immer vorhanden
sind?

mfg.
  VolGas