Ehrlich gesagt: keine Ahnung.
Dazu müßte man die aktuelle Konfiguration(en) schon genauer kennen und testen.

Unsere Server würden -wenn wir sie nur ließen- die volle Netzwerkbandbreite verbrauchen.
Damit uns aber nicht jemand den ganzen Server per FTP wegziehen kann, haben wir
das mit "TransferRate" limitiert. Der ProFTPD wäre also schnell genug, vielleicht
muß man wirklich in die Optimierung...

mfg.
  VolGas

Du müßtest noch das entsprechende development-Paket (-dev) zu Deinem
mysqlClient installieren. Dazu mußt Du zuerst einmal wissen, welcher mysqlClient
in Deinem System installiert ist.

Versuche einmal das: ll | grep mysql
Damit kannst Du herausfinden, welche Libraries dazu installiert wurden.

Wenn Du herausgefunden hast, welche Version Dein Client hat, kannst Du per
"apt-get" das entsprechende Development-Paket nachladen lassen.
Es gibt z.Zt. "libmysqlclient10-dev", "libmysqlclient12-dev" und "libmysqlclient14-dev"

Wenn Du das richtige Paket nachinstalliert hast, kannst Du in der "./configure"-Anweisung
die beiden letzten Zeilen mit "with-..." weglassen - die entsprechenden Sourcen & Libraries
sollten dann im Suchpfad des Systems vorhanden sein.

mfg.
  VolGas

Mir ist noch etwas eingefallen: wenn der ProFTPD sich via Netzwerk an einen mySQL-Server
anmeldet, so könnte man evtl. den Servernamen mittels "SUBSTRING_INDEX(USER(),'@',-1)"
herausbaldobern. Das kann man bequem in sein SQL-Query einbauen und wäre allgemein
anwendbar.

mfg.
  VolGas

Es gibt noch die Möglichkeit den ProFTPD etwas zu tunen.
Dazu muß man ihn allerdings neu compilieren - ob sich das allerdings im
Up/Download so deutlich bemerkbar macht, muß man ausprobieren.

Da währen die configure-Optionen "--enable-sendfile" und "--enable-buffer-size=8092"
Siehe z.B. ->hier (vorletzter Absatz) oder auf der Original-ProFTPD-Site.

mfg.
  VolGas

win32.

...

Nein, (böser) Scherz beiseite: dies läßt darauf schließen, daß Deine Netzwerkkonfiguration
nicht 100%ig ist. Aber Du kannst eines versuchen: füge Deiner proftpd.conf folgendes hinzu:

UseReverseDNS off
IdentLookups off

Vielleicht bringt das den erwünschten Erfolg.

mfg.
  VolGas

Da muß ich wiedersprechen: wir haben das im Logformat und dort steht brav der Servername.
Aber lange Rede, kurzer Sinn: ich habe es bei uns auf die Gefahr von bösen Anrufen hin probiert
und so wie es aussieht, wird keine Variabelsubstitution vorgenommen. "%v" kommt beim
SQL-Server genau so an.

Ich sehe daher also nur den Weg, daß Du die jeweiligen proftpd.conf anpasst.
Ist ja nur minimal.
Sorry.

mfg.
  VolGas

[--disable-auth-pam --disable-auth-file:]

--disable-auth-pam --disable-auth-file:
Da wir ausschließlich SQL zur Authentifizierung benutzen, benötigen wir die beiden
Standard- Authentifikationsmodule nicht mehr. "auth-pam" ist die Standardmethode
des Unix-Systems via "/etc/passwd" und "auth-file" ist eine alternative Methode dazu,
welche eine andere Datei benutzt.

Beide Module werden von uns nicht mehr genutzt und damit der ProFPTD ein wenig
"schlanker" wird und damit auch keine zusätzlichen Schlupflöcher existieren, wurden
diese Module deaktiviert. Man könnte sie aber auch genauso gut drinnen lassen...

--disable-sendfile:
Da wir mit "TransferRate" die Übertragungsrate künstlich beschränken, kann die
"sendfile"-Methode des Systems nicht benutzt werden. (System endet autark Dateiblocke
unter Umgehung des ProFTPD. Sonst liest dieser die Datei kontrolliert über einen Buffer
und sendet die Daten selbst)

Im Prinzip wie oben: was nicht gebraucht wird fliegt raus!

--enable-buffer-size=8092:
Wenn man schon nicht "sendfile" benutzt, so erhöht man zumindest den Datenbuffer,
damit nicht unnötig viele Dateioperationen das System verlangsamen. (Man liest
einmal einen größeren Datenblock in den Speicher anstatt mehrmals kleinere. Das
spart Plattenzugriffe und damit auch Performance und Zeit)

mfg.
  VolGas

Das hin und her bringt nix.
Jetzt probiere es doch einfach einmal aus - im "schlimmsten" Fall mit "chmod -R 0777 /var/www"
Wenn dann alles funktioniert, weißt Du ja, was falsch war.
Es kommt immer wieder einmal vor, daß man mal etwas übersieht.
Passiert in der "besten" Familie...

mfg.
  VolGas

Hallo!

Wenn (Betonung auf: Wenn!) Variabeln bei "SQLUserWhereClause" erlaubt sind, dann
sind es wahrscheinlich nur die der Direktive "LogFormat" (siehe ->hier)

Ein "%L" ist dort nicht definiert, aber "%v" wäre eine Alternative: %v : Local server name
Du müßtest Deine SQL-Tabelle anpassen, probiere aber vorher vielleicht erst aus, ob
überhaupt eine Variabelnsubstitution bei "SQLUserWhereClause" vorgenommen wird.

Auf unseren Servern haben wir jeweils die proftpd.conf angepasst, aber wenn das wie
spekuliert funktionieren sollte...

Ich bitte um Rückmeldung.
Danke!

mfg.
  VolGas

Hallo,

hier im Forum hatte ich schon mehrfach eine Anleitung zum Compilieren gegeben.
Dieses Posting scheint mir für Deinen Fall am besten zu passen: ->ProFTPD - Deutsch > Mod_Sql

Du loggst Dich als "root" ein.
Dann z.B.:

cd /usr/src
wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.0.tar.bz2
tar -xjf proftpd-1.3.0.tar.bz2
cd /usr/src/proftpd-1.3.0

Dann geht's wie in dem erwähnten Posting weiter.
Du mußt nur noch die "configure"-Anweisung anpassen.
Wie man mod_shaper installiert, bitte selbst nachsehen.
Achtung: Zeilen, die mit einem "\" enden, werden mit der nächsten Zeile fortgesetzt.

Ich hoffe, Du kommst damit weiter.

mfg.
  VolGas

@Stonki:

Herzliches Beileid!

@bp158:

Das scheint noch einmal ein anderer Fehler zu sein (HomeDir ok?), denn ein Verzeichnis
mit dem Zugriffsrecht "-wx" ist ein sog. "drop-in directory", was es erlaubt, daß Dateien
geschrieben werden können, aber sonst nichts "raus" kommt - also auch kein Listing des
Verzeichnisses. Wenn Du dennoch eines angezeigt bekommst... siehe oben.

mfg.
  VolGas

Hi,

die User der Gruppe "ftpuser" haben keinen Zugang zu "/var/www/"...

mfg.
  VolGas

Siehe mod_quotatab.

mfg.
  VolGas

Aua, aua - nun ist wohl einiges mißverstanden.

Ein "<Global>"-Block ist nicht verkehrt, jedoch hatte ich mit "RequireValidShell verschieben"
gemeint, daß Du dieses nur außerhalb des "<Anonymous..."-Blocks verwenden solltest.

Ebenso gibt es keine Parameter für "<Global>" und auch keine unterschiedliche "Globals".
Mich wundert doch sehr, daß z.B. "<Global ~duc>" vom ProFTPD überhaupt akzeptiert wird.

Bevor wir aber weitermachen: für mich ist nun nicht ganz klar, was Du mit "grp" vorhast.

Ich möchte hier auch öffentlich auf Deine private Nachricht antworten:
Ich besuche dieses Forum sporadisch nach Zeit, Lust und Laune und bitte um Verständnis,
wenn ich keine weiteren Kontaktmöglichkeiten außerhalb dieses Forums anbiete. Würde ich
dieses tun, so wäre ich quasi immer erreichbar und "in der Pflicht". Das möchte ich nicht -
meine Privatsphäre ist mir wichtig.

mfg.
  VolGas

Hi,

ich sehe mehrere Fehler in Deiner .conf:
ändere "UserAlias anonymous ftp" zu "UserAlias anonymous duc"
Wenn Du einen anonymen FTP Zugang einrichtest, dann kann sich der Zugang
nicht auf ein Homedir "~" beziehen, also ist <Anonymous ~ftp> falsch - hier
muß der absolute Pfad zu Deinen Daten hin.

Sollte sich der Pfad jedoch innerhalb von "home/duc/" befinden, verhindert Dein
"<Limit ..."-Block wohl so ziemlich alles. Es stellt sich generell die Frage,
ob Du wirklich einen anonymen FTP Zugang brauchst/möchtest, wenn Du sowieso
nur eingetragene Systemuser einloggen lassen möchtest.

Weiterhin solltest Du "RequireValidShell off" in den globalen Bereich verschieben.
Zur Optimierung des Logins kannst Du noch "UseReverseDNS off" und
"IdentLookups off" Deiner proftpd.conf hinzufügen.

Dir sollte bewußt sein, daß "DirFakeUser" und "DirFakeGroup" nicht
die Rechte des Filesystems "aushebeln" können und daß alle Zugriffsrechte
"ordentlich" gesetzt sein müssen.

mfg.
  VolGas