Was Du da beschreibst, ist genau das, was in dem Punkt der FAQ steht, auf die ich verwiesen hatte.
Da frage ich mich doch, weshalb ich mir hier eigentlich die Finger wund schreibe und meine Zeit
verschwende.

Wohin Du das einbastelst, ist Dir überlassen - ich würde es in das Start-Script des ProFTPD einbinden.

Alternativ zu "mount --bind ..." gibt es noch das Modul der ->VRootEngine, ->mod_vroot, welches
das restriktive "DefaultRoot" ein wenig entschärft und erlaubt, mit Symlinks aus dem chroot-Gefängnis
auszubrechen.

mfg.
  VolGas

Hallo!

Nur um ganz sicher zu gehen: siehe mit "netstat -tap" oder "ps auxf | grep proftpd" nach,
ob der ProFTPD läuft. Der Server ist auch nicht hinter einer Firewall/IPTables oder wird
durch die NAT eines Routers beeinflußt. Wenn dem alles so ist, dann beende und starte
den ProFTPD im Debugmodus (siehe ->FAQ) neu.

Wenn Du bei der ersten Ausgabe keinen Fehler entdeckst, dann versuche noch einmal
Dich einzuloggen. Die zweite Debug-Ausgabe, also ab dem Einloggen, poste hier mit
Deiner proftpd.conf. Dann schaun wir mal...

mfg.
  VolGas

obwohl ich den befehl so eingetragen habe (in der obigen conf) und natürlich dann noch die alten directory anweisungen entfernt wurden, hatten die ordner, die ich vorher einzeln limitiert habe, leider nicht das gleiche verhalten wie zuvor (wobei ich dachte, das dies durch diesen befehl eben abgedeckt ist)...

Dachte ich eigentlich auch.
Absolute Pfade sind halt doch besser.
Wenn Deine proftpd.conf funktioniert, dann laß es einfach so.

Aber ich würde die Limit-Anweisung noch detailierter schreiben und zusätzlich verhindern,
daß Uploads -ob beabsichtigt oder unbeabsichtigt- nachträglich "sabotiert" werden können:

<Directory /Pfad_zu_Homedirs/*/Upload/>
  DeleteAbortedStores on
  AllowStoreRestart off

  <Limit READ DIRS MKD RTFR DELE>
    DenyAll
  </Limit>
</Directory>

Das trifft es genauer und sollte funktionieren, siehe ->hier.
(ich bin nun ein wenig vorsichtiger, mit dem was ich schreibe)

habe ich da noch nen fehler drin oder hab ich es einfach doch noch nicht verstanden ??

Vielleicht ich ja auch noch nicht...

Es freut mich dennoch, wenn ich Dir irgendwie weiterhelfen konnte.

mfg.
  VolGas

also, hier füge ich nur die gruppe ein, die ich für den server angelegt habe, richtig ? mal angenommen die
gruppe heisst "halloftpusers" würde der befehl: DenyGroup !halloftpusers lauten, richtig ?

Genau.
Wichtig ist das Ausrufezeichen vor dem Gruppennamen, das die Bedeutung umkehrt:
statt die speziell diese Gruppe zu verbieten, wird diese eben freigegeben und dafür allen
anderen der Zugang verwehrt.

<Limit RETR DELE>
AllowUser xxx
DenyAll
</Limit>

Hier ist das selbe Spiel wie gerade eben: statt "Allow..." schreibe den Block so:

  <Limit RETR DELE>
    DenyUser !xxx
  </Limit>

Wichtig ist auch hier wieder das Ausrufezeichen, das alles umdreht.

Aber eine andere Sache, die Dir vermutlich noch nicht bewußt ist: nach dem Einloggen
ist der ProFTPD wie eine Usershell zu verstehen: der Prozess läuft unter der UID/GID des
eingeloggten Users, hat also die selben Einschränkungen und Rechte wie dieser.

Setzt ein User z.B. die Rechte eines Verzeichnisses oder einer Datei auf chmod 600 (rw-------),
so kann nur er alleine darauf zugreifen. Das ist nicht zu umgehen oder auszutricksen -
es sei denn, man ist "root"! Der hat aber aus Sicherhheitsgründen keinen FTP-Zugang!

Damit ist ein "allmächtiger" Admin, der auf alles zugreifen und regeln kann, nicht wirklich
möglich und die ganzen Limitierungs-Konstruktionen dahingehend sinnlos. Da bleibt Dir
weiterhin nur der Shellzugriff als "root" zum administrieren. Schade, ist aber so.

bei so einem befehl, wenn wir annehmen, die user verzeichnisse würden in /usr/halloserver/ liegen,
dachte ich das durch diesen befehl eben alle ordner namens "upload", die in den unterverzeichnissen von
/usr/halloserver/ liegen, mit limitiert werden... was mir dabei aber noch nicht klar ist, ob dann in diesem fall
z.b. auch der ordner /usr/halloserver/user/userprojekt/upload mit limitiert wird, da er ja 2 verzeichnisse
weiter "unten" liegt ??

Um es ganz deutlich zu machen: mit "<Directory /xxx/xxx/*/Upload/>" wird dies nicht
gelingen, sondern nur mit "<Directory /usr/halloserver/*/Upload/>" oder, nach Linux-Art:
"<Directory ~/*/Upload/>" - sofern das Homeverzeichnis des Users "/usr/halloserver" ist.

Die beiden Zeichen "~" und "*" sind etwas Unix-spezielles: beginnt ein Pfadnamen mit "~", so
ist damit ein Pfad, beginnend ab einem Homeverzeichnis eines Users, gemeint. Solch ein Pfad
ist also kein absoluter Pfad, sondern geht immer vom Home-Verzeichnis des jeweiligen Users
aus - egal wo es liegt.

Das Sternchen ist ein "Joker"-Zeichen und dient als variabler Platzhalter für Pfade.
Das kann ein einzelnes Zeichen sein oder ein ganzer Teil eines riesigen Pfades - auch über
mehrere Verzeichnisse hinweg.

Jetzt, wo Du das alles weist, haben sich damit wohl alle weiteren Fragen erledigt, oder? 
Wenn nicht, melde Dich einfach wieder hier.
Aber denke bitte daran: das hier ist ein ProFTPD-Forum...

Noch ein Tipp: Solltest Du ernsthaft Interesse an Linux haben, so kann ich Dir nur wärmstens
z.B. das Standardwerk, den "Kofler" empfehlen...

mfg.
  VolGas

Hallo!

Zuerst zu den Fehlermeldungen: die Fehlermeldungen der FTP-Clients sind i.d.R. überhaupt
nicht zu gebrauchen, denn sie bringen meist nur generalisierte Fehlermeldungen - jeder
seine eigene.

Die Clients nutzen heutzutage standardmäßig den passive mode, das dürfte kein Problem
darstellen. Was aber zum Problem werden kann, ist eine dazwischengeschaltete Firewall
(oder IPTables), die bestimme Ports nicht durchlässt. Das solltest Du überprüfen.
Ansonsten: laß' Dich nicht verrückt machen, oder sind falsch konfigurierte Clients Dein
Problem? Dann wirst Du immer eines haben.

Zur proftpd.conf: da Du das Muster von Stonki's Site genommen hast, ist Deine proftpd.conf
schon recht gut optimiert. Nun zu den Details: Teile (wie TLS oder SQL), die Du nicht brauchst,
kannst Du einfach mitsamt Kommentar entfernen.

• "UseFtpUsers" kannst Du ruhig auf "off" setzen: der Zugriff wird durch Gruppenzu-
  gehörigkeit geregelt. Ist sonst nur zusätzlicher Aufwand.
• bei der Authentifikation werden alle User, die NICHT zur Gruppe "ftpuser" gehören,
  abgewiesen. Ob dann die (doppelte) Anweisung "AllowGroup xxx" noch etwas daran
  ändert (und Sinn macht), weiß ich nicht.
• wirklich notwendig ist das "RETR" in <Limit RETR LOGIN> auch nicht.
• die ganzen "...store..."-Direktiven sind schon einmal zentral definiert müssen dies
  nicht immer wieder in jedem "<Directory..."-Block neu definiert werden -
  es sei denn, es soll sich wirklich etwas ändern.
• die "<Directory"-Blöcke werden nicht funktionieren, wenn Du nicht wirklich die
  "/xxx"-Verzeichnisse hast. Es gibt nur ein Alias-Zeichen, nämlich das Sternchen: "*"
  Ich vermute einmal, Du wolltest so etwas wie: "<Directory ~/*/Upload/">.
  Aufgeschlüsselt: vom Homedir ausgehend irgend etwas, das in einem Verzeichnis
  mit dem Namen "Upload" endet. Lies' Dir einmal ->"Configuring a <Directory>" durch...
• man kann mehrere FTP-Befehle gleichzeitig einschränken: "<Limit RETR DELE ...>".
  Die Direktive wird ->hier beschrieben. Hast Du wirklich einen User und eine
  Gruppe "xxx", die Du gesondert behandeln möchtest?
• Ein freigegebenes Upload-Verzeichnis hat man für Gewöhnlich nur in "Anonymous"
  Installationen - und dann auch nur eines. Bist Du Dir mit Deiner Installation sicher?

Es bleibt Dir wohl nichts übrig, aber Du wirst noch einmal Deine proftpd.conf überarbeiten
müssen, denn die "<Directory...>"-Blöcke sind wohl wirklungslos und für die Katz'...

mfg.
  VolGas

Hallo!

Die Konfiguration sichern ist auf jeden Fall eine gute Sache.

Deinstallation - dazu müßte man genau wissen, wie der ProFTPD installiert wurde.
Und: wenn sich nichts geändert hat - was soll eine Neuinstallation bringen? (Ist doch kein Windoof!)
Falls doch installieren: das Binary des ProFTPD einfach löschen und noch einmal installieren - das reicht.

Da Du Dir sicher bist, daß der ProFPTD auf normalem Weg nicht mehr läuft und sich auch nicht mehr starten läßt,
starte ihn im Debug-Modus (siehe ->FAQ) und sieh' Dir an, warum und wo der Server schlapp macht.

Ansonsten hätte ich noch nachgesehen, ob eine Firewall bzw. IP-Tables die Ports dicht gemacht hat.

mfg.
  VolGas

Mal ein "Schnellschuß", ohne groß nachzudenken:

    UPDATE ["tabelle" SET] log_out=NOW() WHERE username='%u' AND log_out='0000-00-00'

Nicht perfekt und ohne Gewähr!

In Kursivschrift und eckigen Klammern ist der Teil, der zu einem vollständigen
SQL-Query gehört, in der Syntax für "mod_sql" aber wegbleiben muß.
Unterabfragen mit einem zweiten "SELECT" gehen in mySQL leider (noch?) nicht.

mfg.
  VolGas

Das ist eigentlich kein ProFTPD-Problem und meiner Meinung nach wäre eine
Auswertung von einem Logfile wesentlich resourcenfreundlicher.

Aber es gibt natürlich auch mit SQL eine Lösung: da das Feld "log_out" noch leer
ist, wenn sich jemand eingeloggt hat, kann man natürlich beim Ausloggen mit
einer entsprechenden "WHERE"-Klausel den Update gezielt auf diesen Datensatz
begrenzen. Zusätzlich könnte man das Update noch mit "LIMIT 1" auf einen
einzelnen Datensatz beschränken, das wird aber wohl nicht notwendig sein.

Alles nur eine Sache einer mehr oder weniger geschickten SQL-Abfrage...

mfg.
  VolGas

Ich verstehe nicht ganz - ist das Feld "username" nicht als "primary index" angelegt
und jeder Username einmalig? Kannst Du bitte ein wenig konkreter werden?

mfg.
  VolGas

Hallo!

Ich fürchte, daß dies ein hoffnungsloses Unterfangen ist.
Wenn der FTP-Client "höflich" ist, dann wird er sich tatsächlich mit "QUIT" verabschieden,
aber meist sind sie es eben nicht und trennen einfach die Verbindung. Oder der ProFTPD
trennt von sich aus die Verbindung wegen eines Timeouts. Oder...
Es ist wie im Leben: Trennungsgründe gibt es einige.

Vermutlich ist es sogar so, daß der "QUIT"-Befehl ProFTPD-intern vom Core-Module gleich
umgesetzt wird und den jeweiligen Prozess beendet, also gar nicht mehr an die anderen
Module (und damit auch nicht an das SQL-Modul) weitergeleitet wird.

Sorry...

mfg.
  Volgas

Hallo!

Das wird daran leigen, daß das FTP mit jeweils einem Daten- und einem Befehlskanal arbeitet.
Im "passive mode" wird vor jeder Übertragung von Daten ausgehandelt, welcher Port genutzt
werden soll. Scheinbar scheint das über die Verbindung nicht zu klappen, die Ports werden
nicht frei gegeben. Du kannst eines noch versuchen, nämlich den "aktive mode", den Du bei
Deinem FTP-Client einstellen kannst. Der verwendet per Definition immer Port 20 als Datenkanal.

mfg.
  VolGas

Nachtrag: wir mußten letztens feststellen, daß "SQLHomedirOnDemand" nicht mehr funktioniert.
Der neue Befehl dafür leider auch nicht, siehe ->hier

mfg.
  VolGas

Verflix noch mal - ich brauch' ne Brille: ich find den Fehler nicht!
Jetzt habe ich sogar mittels regular expressions die "<IfModule"-Blöcke prüfen lassen: ok!

So: bitte entferne (oder kommentiere aus) jetzt wirklich einmal alle "<IfModule"-Blöcke -
nur den Kern der aktuellen Authentifikation und "DelayEngine off" läßt Du davon übrig.

Mal sehen, wo und ob dann noch ein Fehler angemeckert wird.
Echt eine harte Geburt!

mfg.
  VolGas

Hah, auch einer mit Mac OS X! 

Mir ist an Deinem Posting oben mit der Fehlermeldung gerade noch etwas aufgefallen:
TLS ist aktiv und du hast höchst wahrscheinlich gar keine entsprechenden Zertifikate.
Lösche den TLS-Block oder setze "TLSEngine" auf "off".

Solltest Du später TLS nutzen wollen, ist es sowieso besser, zunächst einmal den Regelbetrieb
zuverlässig am funktionieren zu haben und dann erst TLS zuzuschalten.

Noch eine Frage: mit Parallels Virtualsoftware kann man sogar eine Linux-Installation
installieren und betreiben? Ohne Probleme? Und wie machst Du das mit den Partitionen -
ganz "normal" während der Linux-Installation?

Gut, das war mehr als eine Frage und das ist auch definitiv off-topic, aber eine kurze Antwort
sei mir hier bitte erlaubt...

Noch viel Spaß bei Deinem Messebesuch und mit dem Buch und einen schönen Urlaub!

mfg.
  VolGas

Hallo!

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 1:1 durchlassen. Dem ProFTPD teilst Du über die Direktive ->PassivePorts mit,
welche Ports es benutzen kann.

Damit Deine Maschine mit der dynamischen IP im Internet (WAN) überhaupt mit Namen
gefunden werden kann, mußt Du diesen z.B. bei "dyndns.org" registrieren. Aktuelle Router
bieten heutzutage meist die Option diese Dienste automatisch mit der jeweils aktuellen IP
zu aktualisieren.

Wenn "MasqueradeAddress" eingesetzt wird, funktioniert der ProFTPD allerdings dann
nicht mehr im lokalen Netz (LAN). Eine Verbindung muß dann "von außen" über den Router
hereinkommen. Die haben aber ein Problem, Anfragen vom LAN über das WAN zu bedienen.

Aber auch dafür gibt es eine Lösung: gib Deiner Servermaschine eine zweite IP nur für das
LAN und definiere dann dafür im ProFTPD einen zusätzlichen, virtuellen Server.
Eine Beispiel-Konfigurationsdatei für den ProFTPD gibt es ->hier.

Trotz allem: die Lösung ist IMHO nicht sehr "glücklich": zu einem Server gehört nunmal eine
feste IP-Adresse. Denn wenn Deinem Anschluß eine neue IP zugewiesen wird, werden alle
Verbindungen getrennt und der Server ist neu zu starten, damit er die neue IP auch
registrieren kann.

Ich hoffe, ich konnte Dir damit weiterhelfen.

mfg.
  VolGas