[gelöst] Bandbreitenbegrenzung mit vsftpd (nur mit proFTPd)

[psiko]

hallo,

ich möchte gerne mehrere User an meinen FTP-Server lassen, aber von den 48kb Upload des DSL-Anschlusses max. 40KB/s für FTP reservieren lassen.

Dazu habe ich erstmal in der vsftpd.conf den Parameter
local_max_rate=40000
gesetzt.

Als zweites habe ich festgestellt, dass bei xinetd der multi-thread Modus aktiviert war ("Warten=nein") mit beliebig vielen Instances.

Das bedeutet, dass pro Instance 40KB zur Verfügung stand, was natürlich meine 48KB/s überschritten hat.

Daraufhin habe ich in der /etc/xinetd.d/vsftpd die
instances = 1
gesetzt.

nun wurde endlich die 40KB/s Bandbreite nicht mehr überschritten.
Nachteil: es kann sich nur *ein* User anmelden! :-(

mit
per_source = 1
instances = 2
würde ich die Bandbreite pro User auf 40 KB/s beschränken, aber sobald zwei User (zwei IP-Adressen) sich anmelden wäre man bei 80KB/s. :-(



Frage: Wie kann man vsftpd einrichten, damit mehrere User mehrere Verbindungen aufbauen können, aber niemals zusammen eine festgelegte Bandbreite überschreiten?

PS: die parameter in der /etc/vsftpd.conf
max_per_ip=4
max_clients=4
haben keine Auswirkungen bei mir gehabt. :-(

 

[panamajo]

vsftpd als eigenständigen Service/deamon konfigurieren, nicht als xinetd client.

 

[psiko]

vsftpd als eigenständigen Service/deamon konfigurieren, nicht als xinetd client.

das heißt, als "standalone", richtig?

 

[oc2pus]

oder du verwendest jftpgw

http://packman.links2linux.de/package/jftpgw

jftpgw is a proxy server for the FTP protocol. It is highly configurable, you
may use the XML-like configuration file for your options to control jftpgw
where you can define almost any combination of the client's IP, the server's
IP, the user name, the destination port and so on. Furthermore jftpgw supports inetd/daemon mode, transparent proxying, forwards, caching, logging, data IP and port specification (port ranges), limitations as to the number of simultaeous sessions and several proxy login styles for clients that support FTP proxies.

 

[psiko]

Als Standalone nützt es auch nicht.

Es werden auch mehrere vsftpd Instanzen gestartet (pro Anmeldung) und es läuft sogar unzuverlässiger als vorher. Das hießt, nach ein paar KB Download bleibts stehen...

Noch eine Frage bei Standalone:
- es gibt einen Prozess als root. Der läuft immer.
- dann noch einen als NOBODY und dem User (laut FTP-Anmeldung)

Wieso nicht ein Prozess für alle Anmeldungen? Wo liegt der Hund begraben?

psiko

 

[psiko]

oder du verwendest jftpgw

nein, auch jftpgw kann das nicht. Ich habe sogar extra beim Autor nachgefragt.

>>> Gibt es den keinen FTP-Server oder einen Trick, um die Bandbreite zu begrenzen? <<<

Grüße
psiko

 

[oc2pus]

oder du verwendest jftpgw

nein, auch jftpgw kann das nicht. Ich habe sogar extra beim Autor nachgefragt.

>>> Gibt es den keinen FTP-Server oder einen Trick, um die Bandbreite zu begrenzen? <<<

klar kann es das, ich nutze das so:

<from 192.168.42.0/24 exclude 192.168.42.12 192.168.42.13>
        access allow
        throughput 150
</from>

siehe auch die Doku
http://www.mcknight.de/jftpgw/config.html#throughput

Limit the throughput of an ftp connection. The unit of rate is kbyte per second.
Syntax:

througput <rate>


Example:

<user anonymous>
throughput 7.5
</user>


This setting limits every client to 10.00 kBytes/second. It does not mean that all hosts from this network share 10.00 kBytes/second.
Example:

<from 123.123.0.0/16>
throughput 10.00
</from>

 

[psiko]

Bist du dir da sicher?

heißt es doch wörtlich:
This setting limits every client to 10.00 kBytes/second

"every client" heißt nicht für den ganzen Damon.
Wenn sieben User sich gleichzeitig anmelden, ist die gesamte Bandbreite bei 70 kBytes/s ! :-(

Außerdem sagt der Autor des Programms auch, dass es nur *pro Verbindung *geht.

Grüße
psiko

 

[oc2pus]

Bist du dir da sicher?

heißt es doch wörtlich:
This setting limits every client to 10.00 kBytes/second

"every client" heißt nicht für den ganzen Damon.
Wenn sieben User sich gleichzeitig anmelden, ist die gesamte Bandbreite bei 70 kBytes/s ! :-(

Außerdem sagt der Autor des Programms auch, dass es nur *pro Verbindung *geht.

ja, aber wenn man zusätzlich das limit der Verbindungen pro Client auf eine kleine Zahl setzt kann man da schon was bewirken
in der /etc/xinet.d/vsftp:

service ftp
{
#       server_args     =
        log_on_success += DURATION USERID HOST
        log_on_failure += USERID HOST
#       nice            = 10
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/vsftpd
        per_source      = 4   <==== WICHTIG!
}

wird hier erfolgreich angewandt um Powerdonloader zu limitieren...

und zusätzlich noch einen Traffic-Shaper um den ftp-Traffic zu regeln gegenüber den "Surfern", und schon herrscht Gerechtigkeit :mrgreen:

 

[psiko]

genau mit diesem Kompromiss arbeite ich immoment.
Aber ideal ist es nicht.

Evtl. kommt noch pure-FTPd in Frage, sobald klar ist, was mit

"-T bandwidth oder -T upload bandwidth:download bandwidth Aktiviert die Möglichkeit, die Bandbreite für ALLE Benutzer zu drosseln."

gemeint ist. (http://x-fish.org/tux_pureftpd01.html#switches)

Oder aber mit proftpd, denn laut http://www.proftpd.de/FAQ.15.0.html soll es mit dem Modul "mod_shaper" gehen.

Tja, erst mit viel Mühe vsftp eingerichtet und dann doch nicht für meine Belange nutzbar. Mist :-(

 

[psiko]

OK, pure-ftpd kanns auch nicht. :-(

jetzt bleibt noch proftp übrig...

 

[psiko]

gelöst.
mit proftpd und dem module mod_shaper geht es.

moduleinstallation:
http://www.castaglia.org/proftpd/modules/mod_shaper.html#Installation

mod_shaper Beschreibung:
http://www.castaglia.org/proftpd/modules/mod_shaper.html

Die Datei proftpd.conf editieren und zufügen (Beispiel!!!):
<IfModule mod_shaper.c>
ShaperEngine on
# ShaperLog /var/log/ftpd/shaper.log
ShaperTable /var/log/ftpd/shaper.tab

# An overall rate (in KB/s) must be set. This line explicitly
# sets both the download and upload rates to be the same.
ShaperAll downrate 40 uprate 240

# Allow all system users to see shaper info
ShaperControlsACLs info allow user *

# Allow the ftpadm group to shape current sessions
ShaperControlsACLs sess allow group users

# Allow FTP admins to alter settings both overall and per-session
ShaperControlsACLs all,sess allow group ftpadm
</IfModule>


und nicht vergessen die Datei /var/log/ftpd/shaper.tab mauell anlegen...

 

[psiko]

naja, der mod_shaper ist nicht ganz das Beste.
Dieser kann zwar die Bandbreite für NEUE Verbindungen dynamisch regeln, aber kann die Bandbreite bei BESTEHENEDEN Verbindungen nicht reduzieren.
Beispiel:
erste Verbindung 40KB/s
zweite Verbindung 20KB/s
wenn erste Verbindung beendet wird, dann wird die zweite nicht automatisch erhöht. :-(

egal.

mit taffic shaper (tc) geht es:
1. in der /usr/local/etc/proftpd.conf die Ports festlegen
PassivePorts 50000 50100

2.
neue, ausführbare Datei anlegen: (z.B. /home/<user>/bin/shap)
-------
#!/bin/bash

if [ "$*" = "-d" ]; then
tc qdisc del dev eth0 root
iptables -t mangle -F POSTROUTING
exit
fi

# root-qdisk mit default auf class 11
tc qdisc add dev eth0 root handle 1:0 htb default 11

# root-class mit 1GBit Bandbreite
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1000mbit ceil 1000mbit

# class 10: hier wird der ftp Verkehr begrenzt auf 40KB/s
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 320kbit ceil 320kbit prio 0
# class 11: unbegrenzter, sonstiger Verkehr
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 1000mbit ceil 1000mbit prio 1

# alle Pakete, die über die passiven FTP-ports 50000-50100 laufen, werden mit "10" markiert
iptables -A POSTROUTING -t mangle -o eth0 -p tcp --sport 50000:50100 -j MARK --set-mark 10

# alle Pakete, die mit "10" markiert sind, werden der class 10 zugewiesen
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10
------

3. den traffic shaper reboot fest machen
Datei: /etc/init.d/boot.local
-----
/home/<user>/bin/shap
-----

info: mit "/home/<user>/bin/shap -d" wird das Traffic shaping deaktiviert

grüße
psiko

 

[psiko]

naja, das mit dem reboot-fest machen mit der Datei etc/init.d/boot.local klappt nicht ganz. :-(

hat jemand eine bessere Idee?