Hallo!

Das Sternchen bei "SQLAuthenticate" wurde als "depricated" zu gunsten eines universelleren Handlings
eingestuft. Benutze statt dessen nun die Direktive ->AuthOrder, in Deinem Fall also: "AuthOrder mod_sql.c".
(Bitte nicht "AuthOrder mod_sql_mysql.c" nutzen - dies ist nur ein Kommunikations-Sub-Modul!)

Zwei Dinge, die mir bei Deinem Konfigurationsschnipsel aufgefallen sind:

• Benutze "SQLDefaultUID" & "SQLDefaultGID" jeweils nur dann, wenn "uid" bzw "gid" aus der Datenbank
  nicht genutzt werden sollen, denn diese beiden Direktiven überschreiben bzw ersetzen diese.
• Du kannst bei "SQLUserInfo" statt der Angabe des Feldes für "shell" auch "NULL" einsetzen. Damit kannst
  Du das Feld "shell" in der Tabelle und die damit notwendige "Pflege" sparen. Solch ein altes, nutzloses
  Relikt muß man nicht auch noch mitschleifen. Wichtig dabei: "RequireValidShell off"

mfg.
  VolGas

Bitteschön!

Die Beschreibung der Parameter von "SQLUserInfo" ist auf Stonki's Website ist leider nicht ganz mit
der Syntax indentisch. Das liegt wohl daran, daß auf der "offiziellen" ProFTPD-Website die Doku arg
zusammengestückelt ist und noch jenseits von gut und böse ist. Erst auf der Entwicklersite ist eine
brauchbare Doku für die Direktive zu finden - und tatsächlich: es gibt für "SQLUserInfo" einen Default-
Wert: "users userid passwd uid gid homedir shell"

Der erste Parameter gibt den Namen der Tabelle an, in dem sich die FTP-Userdaten befinden. Den
kann man natürlich nicht einfach weglassen oder ändern, sondern er muß schon den richtigen Namen
der SQL-Tabelle haben - auf Deinem Server heißt die Tabelle also wirklich "users". Wie das Tabellen-
layout tatsächlich aussieht, spielt für "mod_sql" eigentlich keine Rolle, dafür bekommt es ja via
"SQLUserInfo" die Feldnamen mitgeteilt, die es abfragen soll. Der "Rest" der Tabelle sowie die
"NULL"-Felder sind für "mod_sql" irrelevant und werden nicht weiter beachtet.

Ich würde vorschlagen, daß Du "SQLUserInfo" wieder aktivierst - ist sicherer und sauberer.
Daß der ProFTPD im Debugmodus ein bischen meckert, ist nicht weiter schlimm. Das liegt daran,
daß keine Gruppen via "SQLAuthenticate" aktiviert und mit "SQLGroupInfo" definiert wurden.
Das braucht man in der Regel auch nicht und kann es getrost weglassen. Eigentlich kann man auch
nicht von Meckern reden, es ist nur eine Feststellung, eine Bemerkung.

Die Werte von "SQLMinUserUID" & "SQLMinUserGID" auf solch niedrige Werte zu setzen, ist, mit
Verlaub, eine blöde Idee - auch wenn dies durch die nachfolgenden Direktiven eigentlich egal wäre.
Oft ändert man später etwas und dann sind solch vergessene "Sünden" echte Sicherheitslöcher.

Tipp: ein klein wenig kann man das SQL-Handling mit "SQLNegativeCache on" optimieren...

Zum Thema Konfiguration kann ich nur das Credo eines jeden erfahrenen System-Admins rezitieren:

• If it's not broken - don't fix it!
• Never touch a running system!
• One backup a day keeps trouble away...

Bestimmt fällt Dir für die Feiertage doch etwas viel besseres ein, als Server zu konfigurieren -
hoff' ich doch...!

mfg.
  VolGas

Normalerweise gibt es mehrere Verzeichnisse, in denen gesucht wird.
Aber Dein System scheint da anders zu sein.

Wenn du eine Lösung gefunden hast, wäre es nett, wenn Du sie hier posten würdest,
damit alle daran teilhaben können. Danke!

mfg.
  VolGas

Ich kenne Dein System nicht und bezweifle stark, daß das Anlegen dieser Datei überhaupt
irgend etwas bringen könnte - scheinbar wird dies in diesem System anders gehandhabt.

Hier müssen Dir andere Leute weiterhelfen - ich kenne mich da nicht aus.
In diesem Forum wirst Du wahrscheinlich auch keine Antwort finden - hier kommt nur her,
wer etwas zum ProFTPD wissen will und ich scheine z.Zt. der einzige zu sein, der Fragen
beantwortet.

Dein Problem ist zwar jetzt mit dem ProFTPD aufgetaucht, ist aber eher genereller Natur
und hat nur indirekt damit zu tun. Ich kann Dir daher leider nur raten, Dir ein Forum zu
suchen, wo sich die entsprechenden Leute aufhalten, die dieses System und dessen
Problematik kennen.

mfg.
  VolGas

Hi!

Das ist eigentlich ein Unix-Problem, aber es geht hier ja auch um den ProFTPD...

Ich kann nur eines vermuten: daß auf Deiner Maschine die Such-Pfade für die Libs nicht (richtig)
gesetzt wurden. Probiere einmal, ob bei Deinem System der Shell-Befehl "ldconfig -p" funktioniert.
Wenn ja, bekommst Du nun eine Ausgabe der Pfade zu allen Libraries. Sollte dabei der Pfad "/opt/lib"
fehlen, dann siehe nach, ob es in Deinem System ein File "/etc/ld.so.conf" gibt und füge dann dort den
Pfad hinzu. Dann noch einmal "ldconfig" (jetzt ohne Parameter "-p") ausführen, damit die Änderung
übernommen wird.

Ich hoffe, das war wirklich die Ursache - viel Erfolg!

mfg.
  VolGas

Hallo!

Mache Dir keine Gedanken, von "stören" kann man hier nicht reden: es wird ja niemand gezwungen...
Schön, daß ich Dir bei Deinem vorherigen Problem helfen konnte und es nun funktioniert.

Prinzipiell ist zu sagen, daß in der Regel die proftpd.conf (außer bei Major-Releases) immer belassen
werden kann, wie sie ist und auch immer das selbe Verhalten des ProFTPD definieren. Die Zugriffsrechte
werden nicht vom ProFTPD definiert, sondern vom System. Der ProFTPD hat gar keine Möglichkeit, diese
zu umgehen oder abzuändern, da er wie eine Usershell zu sehen ist:

Vor dem Einloggen hat der für den einloggenden User individuell neu gestartete Prozess aus Sicherheits-
gründen die in der proftpd.conf mit den Direktiven "User" und "Group" definierten Rechte - genauso wie
der "Parent". Nach dem Einloggen wird der Prozess ganz kurz zum "root", nur um damit endgültig die
vordefinierten User- und Group-ID des eingeloggten Users anzunehmen und damit alle Root-Rechte zu
verlieren. Daraus folgt aber auch: der ProFTPD muß immer mit Root-Rechten gestartet werden, da nur
der Root-User User- und Group-ID wechseln kann!

Die User- und Group-ID, die Du mit dem Shell-Befehl "ps" siehst, sind in der Regel die, die für diesen
User definiert wurden. Das hat sich auch nicht durch das neu Compilieren des ProFTPD geändert: wenn
es jetzt nicht richtig funktionieren sollte, kann es vorher auch schon nicht richtig funktioniert haben.

Das Sternchen bei "SQLAuthenticate users*" hat seine Bedeutung verloren und benötigt nun statt dessen
die Direktive "AuthOrder mod_sql.c", um das selbe zu erreichen. Das ist wichtig, damit man nicht plötzlich
auch Systemuser mit anderen Settings für das FTP zulässt. Diese Direktive also bitte setzen, nicht aus-
kommentieren!

Deiner hier geposteten Konfiguration fehlt die Direktive ->SQLUserInfo - deshalb wundert es mich, daß
Deine Konfiguration überhaupt funktioniert. Für alle Daten, die immer gleich bleiben und die nicht aus der
Datenbank geholt werden sollen, kann man bei dieser Direktive immer "NULL" setzen und dafür eine
"SQLDefaultxxx"-Direktive als Ersatz benutzen. Beispiel dafür wäre ->SQLDefaultGID, wenn alle User
der selben Gruppe angehören sollen. Den Parameter "shell" von "SQLUserInfo" kann man übrigens immer
als "NULL" definieren - dieses nutzlose Relikt muß man nicht auch noch pflegen...

Was noch zu beachten wäre: sind Deine User- und Gruppen-ID's (UID & GID) kleiner als 1000, so ist dies
mit SQLMinUserUID und/oder SQLMinUserGID unbedingt zu "legalisieren", sonst bleibt der Prozess
Eigentümer des vordefinierten Users und der Gruppe.

Jetzt habe ich fast schon eine ganze Abhandlung geschrieben, setzte das erst einmal um - dann sehen wir
evtl. weiter. Es sollte eigentlich zur Lösung des Problems (dicke!) reichen. Emfehlenswert sind auch die
SQL-Dokumentationen auf Stonki's Website unter dem Menüpunkt ->Docs; hilfreich vielleicht auch diese
->Beispielkonfiguration.

Viel Erfolg!

mfg.
  VolGas

Hallo!

Meines Wissens werden standardmäßig keine Files gelöscht und ich wundere mich ein wenig,
daß dies bei Dir der Fall sein soll. Vielleicht erledigt das ja Dein FTP-Client bei einem Abbruch
für Dich und löscht das File.

Aber völlig egal: wenn Du ein vorhersehbares Verhalten und/oder eine verlässliche Sicherheit
haben möchtest, dann setze explizit "DeleteAbortedStores on" und "AllowStoreRestart off".

Die Kombination dieser beiden Direktiven sorgt dafür, daß ein File nicht schon während des
Uploads fälschlicherweise geöffnet wird und daß bei einem Abbruch keine unvollständigen
(und damit falsche) Daten auf dem Server liegen bleiben. Auf jeden Fall ist es sicherer, ein
teilweise hochgeladenes File automatisch wieder löschen zu lassen, als sich auf ein nach-
trägliches und damit unzuverlässiges "Herumgefrickel", um den ordungsgemäßen Zustand
einer Datei wieder herzustellen, zu verlassen.

mfg.
  VolGas

Hallo!

Die Antwort ist in diesem Fall wohl am ehesten ein "jein".

Normalerweise würde der "<Limit...>"-Block alleine reichen - wenn dem User ein Homeverzeichnis
zugewiesen worden wäre. Mit "<Anonymous...>" würde eigentlich jeder in das Verzeichnis "/ftp/User1"
kommen - wäre da nicht schon das "<Limit...>". Hiermit ergänzen sich die beiden Anweisungen.
Allerdings: ein Passwort ist damit auch irrelevant - es wird als "Anonymous" alles als Passwort
akzeptiert.

Ich würde folgende Änderungen vorschlagen:

• im System eine Usergruppe anlegen, die einen User als FTP-User auszeichnet (z.B. "ftpuser")
• dem User diese Gruppe und ein Homeverzeichnis zuweisen - das kann auch "/ftp/User1" sein.
• den ganzen "<Anonymous...>" und "<Limit...>"-Block aus der proftpd.conf entfernen
• dafür wie folgt einfügen:
  

  <Limit LOGIN>
      DenyGroup !ftpuser
  </Limit>
  
  RequireValidShell off
  DefaultRoot ~

Damit erreicht man folgendes: alle User müssen sich mit Ihrem individuellen Usernamen und Passwort
anmelden und werden dann sofort in Ihr Homeverzeichnis "gebeamt" und dort eingesperrt. (chroot)
User, die nicht der Gruppe "ftpuser" angehören, werden prinzipiell abgewiesen.

Ein gut funktionierendes Beispiel einer proftpd.conf, die die wichtigsten und meist benötigten Anforderungen
abdeckt, kann man bei den ->Beispiel Konfigurationen finden: die ->proftpd.conf Standard Deluxe...

mfg.
  VolGas

Zu eins: Genau, jetzt hast Du es verstanden!
Zu zwei: meines Wissens nicht.
Aber was würde das auch für einen Unterschied (für den Server) machen?
Keinen!

Wenn Du Bandbreite beschränken willst: dafür git es die Direktive ->TransferRate...

mfg.
  VolGas

Ok, dann gehen wir ans "Eingemachte": stoppe den ProFTPD und starte ihn mit den
Parametern "-nd5" neu. Verwerfe die Ausgabe bis dahin, logge Dich ein und beginne
sofort mit einem Upload. Sobald der Fehler aufgetreten ist, kopiere die Ausgabe bis
dahin und poste sie hier. Den ProFTPD kannst Du mit Ctrl-C dann wieder beenden.

In dem Debug-Output werden wir dann (hoffentlich) den Fehler finden.
Ebenso könntest Du auch noch Deine gerade aktuelle Konfiguration hier posten -
für alle Fälle.

mfg.
  VolGas

Hallo!

Zugegeben, das Ganze kann schon ein bischen verwirrend sein - aber es scheint mir gut durchdacht:
"Max...PerUser" bezieht sich auf einen einzelnen Account
"Max...PerHost" bezieht sich auf eine einzelne IP-Adresse

Gesetzt der Fall Du hast z.B. "MaxClientsPerUser" auf 3 gesetzt, so daß kein User sich übermäßig
oft einloggen und damit begrenzte Resourcen nutzen kann. Wenn sich die User aber selbst weitere
Accounts einrichten können, so könnten sie mit der Nutzung eines weiteren Accounts die Begrenzung
von "MaxClientsPerUser" einfach aushebeln.

Mit "MaxClientsPerHost" kann dies eben nicht passieren, denn hiermit wird die Anzahl der maximal
gleichzeitig möglichen Verbindungen pro IP angegeben. Dann ist es egal, mit wieviel unterschiedlichen
Accounts ein User versuchen kann, sich einzuloggen.

Aber man muß bei "MaxClientsPerHost" auch eines ganz klar erkennen: User hinter einem Proxy wie
z.B. AOL oder eines NAT-Netzwerks haben dann damit natürlich das Nachsehen...

Nun klar?

mfg.
  VolGas

Hallo,

natürlich brauchst Du den mySQL-Client bzw. die sog. Header-Dateien dazu und evtl. die
Library selbst, da geht gar kein Weg daran vorbei - außer ein vorcompiliertes Paket, das
alles notwenige in seinem Binary (statisch) schon beinhaltet. Mit Backports und ähnlichem
habe ich keine Erfahrungen, alleine schon weil ich solchen Dingen aus Sicherheitsgründen
nicht trauen kann und darf! Ohne jemandem schlechte Absichten unterstellen zu wollen -
man kann nie wirklich wissen, was jemand in ein Paket hineingebastelt hat.

Versuche es doch selbst noch einmal, dann aber damit vorweg:

    apt-get install libmysqlclient14 libmysqlclient14-dev

Nun noch einmal den ProFTPD neu compilieren - damit sollte es dann klappen...

Erklärung: die "...-dev" Pakete beinhalten immer die notwendigen Headerdateien zu einer
entsprechenden Library oder zu einem Programm bzw. Daemon. ("dev" wie Developer)
Diese Entwicklerpakete braucht man dann, wenn Sourcen fehlen, man aber trotzdem etwas
mit dem fertigen Paket verlinken möchte.

Ein Posting mit Beispiel zum Compilieren des ProFTPD: ->hier,
Erklärungen zu den dort genutzten Optionen: ->hier.

Ich hoffe, Du kommst damit weiter.

mfg.
  VolGas

Hallo!

Zuerst einmal, entschuldige, wenn das hart und arrogant klingen mag, würde ich vorschlagen,
daß Du Dir zuerst einmal ein paar der wichtigsten Linux-Grundkenntnisse aneignest.

Man sollte zumindest die absolut notwendigsten Grundkenntnisse von einem Linux-System haben,
bevor man dort anfängt, etwas zu ändern oder einrichten zu wollen. Dazu kann ich Dir nur
wärmstens z.B. das Standardwerk, den ->"Kofler" empfehlen, es gibt aber auch sehr viel
weiterführende Literatur im Internet...

Nun zum Thema: zuerst solltest Du eine entsprechend an Deine Anforderungen & Gegebenheiten
angepasste proftpd.conf in Dein System einrichten. Eine gut funktionierende, die die wichtigsten und
meist benötigten Anforderungen abdeckt, kann man bei den ->Beispiel Konfigurationen finden:
die ->proftpd.conf Standard Deluxe...

Am besten "im Griff" hat man den ProFTPD mit "ServerType standalone" - damit kann man das
Prozess- und Netzwerkverhalten am besten kontrollieren. Allerdings benötigt man noch ein Start/Stop-
Script, um den Serverdienst automatisch starten und beenden zu lassen. (Beispiele ->hier)

Mit "ServerType inetd" benötigt man solch ein Script nicht - hier regelt der inetd alles weitere.
Dazu muß man den Server nur beim inetd in der "/etc/inetd.conf" entsprechend eintragen und dem
Internet-Deamon eines "auf's Haupt" geben (Sig HUB oder System neu starten) und schon läuft der
ProFTPD als (Unter-)Daemon des inetd. Ein Eintrag in der proftpd.conf alleine reicht eben nicht.

Wenn schon "ServerType inetd", dann sollte man den inetd durch den "xinetd" ersetzen: er ist
wesentlich moderner und erlaubt deutlich bessere Konfigurations- und Kontrollmöglichkeiten wie
der alte inetd.

Weiterhin möchte ich noch die Lektüre des ->Howto: Server Config und vielleicht noch der:
->Best Common Practices empfehlen...

Die Fehlermeldung wird sehr wahrscheinlich durch die Tatsache verursacht sein, daß der ProFTPD
nicht vom inetd selbst gestartet wurde.

Wie Du siehst, wollte ich Dich nicht mit ein paar Zeilen runterputzen und abspeisen, sondern habe
mir schon Mühe gegeben, Dir zumindest ein paar Eckpunkte zu zeigen. Manchmal kommt man eben
mit einer schönen GUI und den mitgelieferten Helferlein alleine nicht zurecht und muß sich dann doch
über die "alte" Konsole mit dem Linux-System und den ganzen Thema drum herum auseinandersetzen.

Ich hoffe, Du kommst mit dieser Handvoll Informationen ein Stück weiter.

mfg.
  VolGas

User werden mit "DefaultRoot ~" in ihr Verzeichnis gebeamt und dor eingesperrt (chroot).
Siehe dazu auch die Doku zu ->DefaultRoot

Nutzt man SFTP, so ist der ProFTPD von der Verschlüsselung "ahnunglos", da alles extern
in einem vorgeschalteten Prozess stattfindet. Irgendwelche Konfigurationen sind daher
auch nicht beim ProFTPD vorzunehmen.

Mit FTPS sieht die Sache anders aus, da geschehen alle Dinge ausschließlich im ProFTPD.
So könnte man über eine Gruppenzuweisung und mit Hilfe des Modul "mod_ifsession" und
der Direktive "TLSRequired" definieren, auf welche Art ein User sich einloggen kann/muß.

Den Rest Deines Postings habe ich nicht verstanden - was ist angelegt und was (warum) nicht?

Eine gut funktionierende proftpd.conf, die die wichtigsten und meist benötigten Anforderungen
abdeckt, kann man bei den ->Beispiel Konfigurationen finden: die ->proftpd.conf Standard Deluxe.
Darin ist auch der Einsatz von TLS (=FTPS) vorgesehen...

mfg.
  VolGas

Hi!

1.) Versuche zuerst einmal Dich mit diesem neuen User per normalem FTP einzuloggen -
nur um zu sehen, ob alles richtig ist.

2.) SFTP ist eine schlechte (Halb)Lösung, denn es wird nur der Datenkanal durch SSH getunnelt,
der Befehlskanal bleibt unverschlüsselt. Außerdem ist ein entsprechender SSH-Tunnel einzurichten,
was nicht gerade trivial ist und einem -Entschuldigung- Anfänger doch recht schwer fallen dürfte.

Lösung: nutze FTPS!
Dies ist eine direkte Lösung, ohne Tunnel, volle Verschlüsselung beider Kanäle, volle Prozesskontrolle.
Siehe auch Artikel ->HowTo: SFTP (TLS, verschlüsseltes FTP) auf Stonki's (dieser) Website...

3.) Ich möchte Dir wärmstens empfehlen, z.B. das Standardwerk, den "Kofler", zu lesen.
Klar, einfach und verständlich wird einem damit Linux nähergebracht...

mfg.
  VolGas