Hallo,

Stonki antwortet nicht mehr? Urlaub?
Ok...

Poste auch einmal Deine proftpd.conf.

mfg.
  VolGas

Hallo!

Stelle Deinen ProFTPD von "inetd" auf "standalone" um und starte ihn im Debug-Modus.
Verwerfe diese Ausgabe bis dahin und logge Dich als Systemuser ein. Die Ausgabe ab
diesem Zeitpunkt poste bitte wieder hier.

mfg.
  VolGas

Hi,

siehe doch einmal bei der Doku zu "HideFiles" nach...

mfg.
  VolGas

Hallo.

1.)
Deine proftpd.conf ist extrem minimalistisch, aber ok.
Füge nur noch "RequireValidShell off" und zur Optimierung vielleicht
auch noch: "UseReverseDNS off" und "IdentLookups off" hinzu.

2.)
Die "VirtualHost"-Direktive gibt es zwar bei Apache und ProFTPD gleichzeitig, aber sie
unterscheiden sich ganz wesentlich, denn das FTP-Protokoll hat im Gegensatz zum HTTP
keine Möglichkeit, zwischen unterschiedlichen Hosts auf der selben IP/Port zu unterscheiden.
Du müßtest also Deinen Domains unterschiedliche IP's oder Ports zuweisen und entsprechend
Deine proftpd.conf anpassen.

Um jemanden einfach nur in ein anderes Verzeichnis "beamen" zu lassen, sollte man
entsprechende Useraccounts mit unterschiedlichen Homedir's anlegen.

mfg.
  VolGas

Hi,

ich verstehe Deine Frage nicht ganz, denn man kann/muß doch mit virtuellen Auth-Moduln,
zu denen auch mod_mysql zählt, jedem User eine User- und Gruppen-ID (UID/GID) angeben.

Vielleicht hast Du das System nicht ganz verstanden: die UID/GID des Filesystems haben
mit der Möglichkeit der Gruppen im ProFTPD nichts zu tun. Außerdem müssen die UID/GID's,
die man im ProFTPD benutzt, keine zugehörigen Systemuser haben, denn für das Filesystem
ist dies letztendlich egal.

Wenn Du nun jedem User entsprechend in der mySQL-Datenbank die UID/GID für "www-data"
bzw. "www-group" zuweist, dann hast Du schon das, was Du möchtest.

mfg.
  VolGas

Aua, aua - absolutes Grundwissen!

Das Binary von ProFTPD ruft man direkt über die Befehlszeile auf, indem man
einfach dessen Pfad oder Namen in der Shell eingibt.

Soll der ProFTPD als Server nach jedem Hochfahren des Systems gestartet werden,
muß man dazu ein Startscript (siehe auch bei ->Download) installieren.
Doch solche Dinge sind nicht Gegenstand dieses Forums und würden dessen Rahmen
bei weitem sprengen und gibt es schon -zigtausend mal anderswo zu finden.

Ich kann Dir für Deine fehlenden Grundkenntnisse nur wärmstens z.B. das Standardwerk,
den "Kofler" wärmstens empfehlen, es gibt aber auch sehr viel weiterführende Literatur im Internet...

mfg.
  VolGas

Hallo,

bitte starte den ProFTPD im Debug-Modus, versuche Dich einzuloggen und poste dann
die Debug-Ausgabe ab dem Loginversuch dann wieder hier.

@ d4n1el:
Dein Tipp war nicht schlecht, aber man sollte dennoch Abstand davon nehmen.
Einem User eine Shell zuzuweisen, heißt auch ihm einen Shell-Account einzurichten.
Das ist nicht immer erwünscht (eigentlich eher selten) und stellt ein hohes Sicherheits-
risiko dar. Der ProFTPD gibt per default nur Systemuser mit valider Shell einen Zugang -
es sei denn, man hat "RequireValidShell" auf "off" -wie hier- gesetzt.
Die bessere Alternative.

mfg.
  VolGas

Es freut mich, daß es nun funktioniert - das war ja auch die Fehlermeldung.
Aber dennoch kann bei einer dynamischen IP nicht (ohne weiteres) internes
und externes Netzwerk gleichzeitig funktionieren. Überprüfe das noch einmal
mit einem FTP-Client, der sich von außen, also nicht netzintern(!), einloggt...

mfg.
  VolGas

1.) das ist nicht der Debug, auf den ich gewartet hatte.
2.) es fehlt immer noch "AuthOrder mod_ldap.c"
3.) Ähem: Failed binding to 0.0.0.0, port 21: Address already in use ???
4.) Das kann es unmöglich gewesen sein: "<Limit SITE_CHMOD>AllowAll</Limit>"
5.) Funktioniert ??? Wieso das denn jetzt?

Ok, hauptsache es funktioniert nun endlich.
Noch viel Spaß damit!

mfg.
  VolGas

Alle "xxxHomedirOnDenmand"-Direktiven scheinen entfernt und durch die allgemein
gültige "CreateHome" ersetzt geworden sein. Wie wir aber letzlich feststellen mußten,
funktioniert diese noch nicht vollumfänglich wie erwartet. Sicherer ist es allemal, dies nicht
automatisch anlegen zu lassen.

Aber zurück zum Problem: egal ob "LDAPHomedirOnDemand" oder "CreateHome" -
das hat letztendlich nichts damit zu tun, daß "DefaultRoot ~" bei Dir scheinbar nicht
funktioniert.

Daher biite immer noch die Debug-Ausgabe nach dem Login bis zum Fehler hier posten.

mfg.
  VolGas

Hallo,

ich hatte gehofft, daß Dir jemand anderes antworten würde, der sich damit
(besser) auskennt als ich. Nun ja...

Hier scheint es ein generelles Problem mit dem Kernel zu geben, denn
"mod_cap" versucht, die "Capabilities" des Systems zu nutzen - und scheitert.

Ich kenne mich damit zwar noch so gut wie gar nicht aus, aber wenn's stört,
dann schalte es einfach einmal aus: "CapabilitiesEngine off" und versuche
es einfach einmal ohne...

Das ist zwar eine recht plumbe Vorgehensweise, aber vielleicht klappt es ja.
Viel Erfolg!

mfg.
  VolGas

Hallo,

zuerst einmal ein Tipp von mir: wenn man so wie Du den ProFTPD auf mehreren IP's
mit unterschiedlichen Konfigurationen laufen lässt, empfiehlt es sich, Gemeinsamkeiten
in der Konfiguration soweit wie möglich in einem "<Global>...</Global>"-Block
zusammenzufassen. Das macht die Konfiguration nicht nur übersichtlicher, sondern
auch sicherer. Aber Du hast in beiden Servern jeweils ein "DefaultRoot ~" stehen -
und das ist, was momentan zählt.

Mit einer LDAP-Konfiguration kenne ich mich zwar nicht aus, aber es gelten auch hier
die allgemeinen Regeln.

Bei Deinem DefaultServer hast Du keine Authentifizierungs-Anweisung gegeben, hier
greift dann die Default-Authentifizierung über das System. Hier wird das eingetragene
Home-Verzeichnis des jeweiligen Systemusers zum "DefaultRoot".

Für den virtuellen Server ist zwar ein definiert, daß LDAP zur Authentifizierung genutzt
werden soll, jedoch ist nicht festgelegt, in welcher Reihenfolge die Auth-Module
durchlaufen werden sollen.

Hier empfiehlt sich dringend der Einsatz der Anweisung "AuthOrder mod_ldap.c" -
damit ist gewährleistet, daß ausschließlich LDAP zur Authentifizierung verwendet wird.
Eine mögliche Fehlerquelle weniger.

Ich vermute, daß ein falscher oder gar kein Pfad für "DefaultRoot" definiert wird.
Am besten, Du startest den ProFTPD im Debug-Modus, versuchst Dich einzuloggen
und analysierst den Output ab diesem Zeitpunkt. Wenn Du damit nicht weiterkommst,
dann poste ihn hier - mal sehen, ob wir damit weiterkommen.

mfg.
  VolGas

Guten Morgen!

Ist das die proftpd.conf, die von Debian installiert wird???
Ein wenig arm, aber ausreichend - spielt jetzt aber auch keine Rolle.

Mit einer dynamischen DNS hinter einem Router ist es sehr schwer (wenn nicht gar
unmöglich) einen zuverlässigen Serverbetrieb zu gewährleisten. Das liegt jedoch nicht
am ProFTPD, sondern an der Natur der Sache.

Dennoch hat ProFTPD auch hier eine Lösung anzubieten. ->MasqueradeAddress
Deine FTP-Clients müssen (sollten sie sowieso immer) den "passive mode" nutzen.
Es werden sogenannte "high ports" benötigt: Dein Router muß diese zusätzlich zu Port 21
ebenfalls an den ProFTPD weiterleiten und eine evtl. vorhandene Firewall muß diese Ports
ebenfalls durchlassen. Dem ProFTPD teilst Du über die Direktive ->PassivePorts mit,
welche Ports es benutzen kann.

Wenn "MasqueradeAddress" eingesetzt wird, funktioniert der ProFTPD nicht mehr im
lokalen Netz. Eine Verbindung muß dann "von außen" über den Router hereinkommen.

Die Lösung ist IMHO nicht sehr "glücklich": zu einem Server gehört nunmal eine feste IP-Adresse.

Aber probiere es mal damit - viel Erfolg!

mfg.
  VolGas

War es auch.
Aber da alles rings herum auskommentiert wurde,
und nur noch das übrig geblieben ist, steht es nun
im globalen Kontext.

mfg.
  VolGas

Na so eilig war Dein Anliegen wohl nicht.

Deine proftpd.conf ist ja sehr "sparsam" - wenn erst einmal die ganzen unnötigen
auskommentierten Bereiche weg sind. Aber das wichtigste ist da. Und die Lösung
des Problems ist auch gleich ganz offensichlich: der Limit-Block ganz am Ende
verbietet ein Schreiben jedlicher Art...

Entferne diesen und füge Deiner proftpd.conf (zur Optimierung) noch folgende
Zeilen hinzu:

UseReverseDNS off
IdentLookups off
RequireValidShell off

Damit sollte es funktionieren.

mfg.
  VolGas