Ja und wie soll ich das dann interpretieren ??????

AllowGroup Gruppe1
AllowGroup Gruppe2

aber nun zu meiner frage:
wo oder wie kann ich einem benutzer eine bestimmte verzeichnissgröße zuweisen. oder anders gefragt wo holt proftpd denn diese infos her.

mod_quotatab
siehe auch: http://www.castaglia.org

cu
stonki

kann ich einfach über die alten version rüber installieren?

jupp

Für die Leute, die meinen tollen News nicht lesen und immer gleich ins Forum gehen  :lol:

http://www.proftpd.de/15.0.html
http://www.proftpd.de/files/proftpd-1.2.9.tar.gz
http://www.proftpd.de/files/proftpd-1.2.9.tar.bz2

cu
stonki

seit kurzem spammed der proftpd mir meine logfiles mit folgender meldung voll:

proftpd[1670]: [<hostname> - Fatal] unable to open incoming connection: Bad file descriptor

dabei steigt die zahl hinter proftpd (die pid ist es nicht, die bleibt laut 'ps ax' immer gleich...) einloggen kann ich mich problemlos auf den server... auch downloads sind kein problem soweit ich das testen konnte... kann mir vielleicht einer helfen die lösung zu finden?

gruß arno

also von der meldung habe ich heute das erste mal gelesen und einmal den Entwickler direkt im IRC Chat gefragt:

<Stonki> http://www.proftpd.de/forum2/viewtopic.php?t=485
<castaglia> that sort of message can happen if something connects to proftpd, then disconnects very rapidly, while proftpd is still determining information about that connection

also im Endeffekt würde ich sagen, dass da einer Dein System scannt oder zumindest Deinen FTP, ob er eine Verbindung akzeptiert. Schaue mal nach, von welchen IP's das ausgeht....

cu
stonki

P.S. Er meinte noch, das wenn man hinter Load Balancer ist, diese ähnliche Meldungen provozieren können

ganz dumme Frage: wieso legst Du nicht für jeden Kumpel einen Useraccount an und sagst dann einfach, dass bei ALLEN das HomeDir /srv/ftp/stuff ist ??

Dieser ganze Alias kram ist doch wie nen schlechter LSD Trip....

cu
stonki

Das hab ich auch schon ueberlegt, nur habe ich dann das Problem dass die Master (sehr viele Leute) jeweils root-equviv Rechte benoetigen wuerden um die quotas dann festzulegen, einen Login brauchen etc. und ich dann zus. noch eine Reihe von Skripten, welche die Quotas auslesen/setzen koennten. Kurz: extrem viel Vor- und Nacharbeit/Support erforderlich. Dazu kommt noch, dass es aus einem webbrowser per interface funken soll, sowohl als auch mit einem FTP client und das ganze transparent fuer die clients...

ok
<Übler Hack Modus an>
Kunde A (oder wie auch immer) uppt etwas, löscht = normale Quota Regelung
Mitarbeiter Stonki (für Kunde A und Kunde B verantwortlich) löscht nun via FTP einige Files.....
Mod_exec wird gestartet. perl Abfrage ob Mitarbeiter was gelöscht hat, wenn ja, Abfrage bei welchem Kunden (kann man über das Verzeichnis machen), direktes editieren der quota_tally tabelle mit perl
<Übler Hack Modus aus>

<nicht ganz so Übler Hack Modus an>
Mitarbeiter müssen sich mti Usernamen und Passwort vom Kunden einloggen, um Sachen zu löschen
<nicht ganz so Übler Hack Modus aus>

<mal kurz richtig nachgedacht Modus an>
Die Quota Verwaltung von ProFTPD unterstützt auch Gruppen und Klassen. Ich habe aber dazu in der Dokumentation wenig gefunden. Das wäre doch eigentlich der richtige Weg.... Lese Dir einmal http://www.castaglia.org/proftpd/modules/mod_quotatab_sql.html noch einmal richtig durch... das führt zum richtigen Weg ;)

<mal kurz richtig nachgedacht Modus aus>

cu
stonki

Hallo,

hab die mod_quotatab doku noch durchgeforstet und gelesen dass das mod sich nicht auf die dateien user/gruppe bezieht sondern wirklich auf den jeweilig angemeldeten Benutzer. Damit ist wohl meine Frage unten im Thread beantwortet: es wird so nicht gehen.

Kennt jemand ein mod der die quotas anhand der Benutzer/Gruppen ID der Files kontrolliert? Das waer dann wohl die Loesung...

MfG
-Tristan-777

wie wäre es denn mit RICHTIGEM Quota ? Auf FileSystem Ebene ?

cu
stonki

Was spricht dagegen, die bestehende zu sichern und dann mit der neuen Server-Version zu verwenden?


Jedenfalls schon mal vielen Dank für deine Antworten!

nichts, aber dann haste noch immer keinen Mod_sql am laufen.

cu
stonki

Gibt es nicht irgendwie eine Möglichkeit, schnell ein RPM-Paket einzuspielen, dass mit einem FTP-Server-Neustart gegessen ist?

also, das mit dem fehlenden Devel Werkzeugen ist ein problem, aber ansonsten ist die ausfallzeit gering. (ca. 20sekunden)

wieso ?

Du compilierst ProFTPD mit mod_sql. Alles liegt ja noch in Deinem "Spiel" Verzeichnis (~/000 oder was auch immer). hier kannst Du ja ProFTPD mit mod_sql schon testen !!!! (proftpd -vv, proftpd -l) etc. Nun schnell die alte Version killen, make install machen, neue version starten. Dauert selbst wenn Du langsam tippst nur 20sekunden :) Gut, damit hast DU noch keine neue config, aber der Grundstein ist gelegt. Und wenn Du wirklich Angst hast (kann ich gut verstehen, ich traue ich mich auch nicht, beim Firmenwebserver von Apache 1.3.x auf 2.0.x zu wechseln), dann gebe mir root access und ich stehe als Standby zur Verfügung..

cu
stonki

ach ja... auf dem besagten ftp-server läuft iptables und NAT für ein lokales Heim-Netzwerk.... iptables v1.2.6a... kernel 2.4.22

der FTP Server ist also NICHT direkt am Netz (also keine externe IP ?) ?

cu
stonki

Kannst es z.B. mit mod_ifsession realisieren, indem du die TransferRate in IfGroup-Blöcke packst.
Details zu mod_ifsession gibt es da: http://castaglia.proftpd.de/#Modules

nenene
http://www.proftpd.de/28.0.html#219

TransferRate FTP-Kommandos Kilobytes-pro-Sekunde:Freie Bytes ["user"|"group"|"class" expression]

cu
stonki

Ich danke Euch für die schnelle Erstellung eines Bugreports! Ist es nun eigentlich ein Problem von ProFTPD, oder ein Problem des verwendeten FTP-Clienten, der eventuell den "ABORT" - Befehl nicht ordnungsgemäß an ProFTPD übergibt, dies ist für mich aus den beiden erstellten und weiter dokumentierten Bugreports nicht richtig ersichtlich?

also so wie ich das verstanden habe, ein Problem des Clients und nicht vom Server...

cu
stonki

LuZiFeR"]Ich hab eine relativ alte Version (1.2)...

Kann es daran liegen ?

ja ! Large File Support kam erst relativ spät in den Code.

cu
stonki

Na toll. Nun haben wir 2 Bugreports :roll:  :arrow: 2253 und 2254

http://bugs.proftpd.org/show_bug.cgi?id=1541

das ist der richtige und es gibt wenig Hoffnung :(

cu
stonki