"Umask" ist auch das Komplimentär zu "chmod", d.h. "Umask 777" nimmt alle Zugriffsrechte
während ""Umask 000" alle Rechte (bis auf x) freigibt. Am besten liest Du Dir mal die Doku
zu dieser Direktive durch!

mfg.
  VolGas

Da hilft nur eines: Lesen, Lernen und Lesen und Lernen.
Am besten fängst Du mit den Support-Seiten und den FAQs von Stonki
(dem Betreiber dieses Forums) durch, da steht eigentlich schon alles.

Dann empfehle ich Dir noch wärmstens, das Standardwerk, den "Kofler" zu lesen...

Du machst es Dir mit -ich-bin-neu-hilf-und-mach-mal- zu einfach, wenn Du nicht zuvor
die vorhanden Quellen ausschöpfst, die schon alle Fragen beantworten. Da ist unfair den
Leuten gegenüber, die hier in ihrer Freizeit versuchen, Fragen zu beantworten. Die müssen
dann nämlich bei Pontius und Pilatus anfangen und quasi das Rad neu erfinden.

Sorry, wenn das hart und arrogant 'rüberkommt, so ist es durchaus nicht gemeint.

mfg.
  VolGas

Wenn Du in der Datenbank für den User UID/GID auf 40/49 setzt,
kollidiert dies mit "SQLMinUserGID 100" / "SQLMinUserUID 500"

Ein "chown ftp.ftp /home/ftp" ist dann auch Banane, denn das müßte -
nur nach Deinem DB-Eintrag schon "chown 40:49 /home/ftp" lauten...

Ein bischen aufpassen und mitdenken mußt Du schon.

Wenn "DefaultRoot ~" gesetzt ist, dann landest Du in dem zugewiesenen
Home-Directory und wenn Dein FTP-Browser dies als "/" anzeigt, ist dies richtig.

Teste zuerst einmal den regulären Zugang und wenn das passt, kannst Du Dich
immer noch um FXP kümmern.

mfg.
  VolGas

Ehrlich gesagt: keine Ahnung.

Ich finde die Idee sowieso schlecht, (my)SQL mit der Erfassung von Statistiken oder Logs zu belasten.
Jede FTP-Session bedingt dann gleichzeitig eine SQL-Sesson - das ist ein unnötiger Resourcenfresser.
Zumal sind Log-Einträge fortlaufende Daten, also hervorragend geeignet, um in Dateien weggeschrieben
zu werden.

Programme zur Logfile-Analyse lesen ihre Daten i.d.R. ja auch aus Logfiles, so z.B. "awstats", das auch
Statistiken aus FTP-Logs erstellen kann.

mfg.
  VolGas

In Deine "/etc/proftpd.conf" gehört auf jeden Fall "AuthOrder mod_sql.c" (ohne Anführungszeichen.
Das darf (kann!) gar keine Fehlermeldung geben.
Und nach jeder Änderung der proftpd.conf ist der Server neu zu starten.

Das Verzeichnis, auf das der User zugreifen soll, muß vorhanden sein und sollte die selbe UID/GID
haben, wie die, die Du dem User in Deiner DB zugeteilt hast. Zum Testen ob alles funktioniert kannst Du
das Verzeichnis vorerst einmal mit chmod 777 für jeden freigeben.
Ändern kannst Du das hinterher immer noch.

Zugriffsrechte sind nur abhängig von einer User/Gruppen-ID - dabei ist es egal,
ob diese ID's einem User und/oder einer Gruppe zugewiesen wurden.

mfg.
  VolGas

Die Datei heißt "passwd", aber so geht das nicht.
Wenn Du uid/gid bei "SQLUserInfo" auf NULL setzt, dann solltest Du
dies zumindest mit SQLDefaultUID/SQLDefaultGID definieren.

Die proftpd.conf hast Du hier noch nicht gepostet,
aber als Minimum sollte auf jeden Fall hinein (Beispiel):

   User nobody
   Group nogroup
   DefaultRoot ~
   RequireValidShell off

Empfehlenswert (für Tempo):

   UseReverseDNS off
   IdentLookups off
   SQLNegativeCache on

mfg.
  VolGas

Sehr merkwürdig, das Ganze.
AuthOrder ist doch genau dazu da, um die Reihenfolge der Auth-Module zu definieren.

Was Du da gebastelt hast, ist übrigens nicht ganz ungefährlich: wenn der Maintainer des
Debianpaketes ein Update auf die Menschheit "losläßt", wird Deine Konfigoration überschrieben.
Du kannst aber mit "apt-get remove" den ProFTPD deinstallieren, ohne daß die Startscripte
(und alles was dazugehört) gelöscht werden. Dazu fehlt noch der Parameter "--purge".
Oder Du installierst einfach nur das Paket "proftpd-common"...

Ich habe unseren ProFTPD übrigens so compiliert:

./configure -q \
--with-modules="mod_sql:mod_sql_mysql:mod_tls" \
--disable-auth-pam --disable-auth-file \
--disable-sendfile --enable-buffer-size=8092 \
--with-includes=/usr/local/mysql/include/mysql \
--with-libraries=/usr/local/mysql/lib/mysql \
\
--prefix=/usr/local/proftpd \
--sysconfdir=/etc --localstatedir=/var/run --mandir=/usr/local/man

make
make install

Damit fehlen dem ProFTPD die entsprechenden Module, die er überhaupt benutzen könnte,
um Systemuser zuzulassen und zusätzlich werden noch ein paar Dinge (für unsere Zwecke) optimiert.

mfg.
  VolGas

Hallo!

Man kann dem ProFTPD angeben, in welcher Reihenfolge die Authentifikationsmodule durchlaufen werden sollen.
Mit "AuthOrder mod_sql.c" wird dies ausschließlich auf SQL gelegt - das ist das, was Du gesucht hast.

Sehr merkwürdig ist aber, daß in Deinem Logfile auf einmal der PostgreSQL-Server steht!?!
Ist der überhaupt auf Deinem System installiert?

Starte einmal den ProFTPD mit dem Parameter "-l" - das gibt die eincompilierten Module aus.

mfg.
  VolGas

Die meisten User-Accounts auf einem Server waren damals reine Mail-Accounts.
Nur Administratoren und besonders privilegierte User hatten direkten Zugriff auf eine Shell
und damit auch auf das Dateisystem.

Um zu gewährleisten, daß wirklich nur die User per FTP Zugriff auf den Rechner hatten, mußte dem
Benutzer eine "valide" Shell zugewiesen sein. Konnte die dem User zugewiesene Shell nicht gestartet
werden oder erlaubte keinen Zugriff, dann scheiterte auch der Login per FTP.

Daher kann/sollte man "RequireValidShell" prinzipiell auf "off" setzen, da die angelegten User oftmals gar
keine Shell eingetragen haben. Leider ist "RequireValidShell" per default auf "on" und damit eine riesige
Stolperfalle, da man gerne vergisst die Option auszuschalten oder es schlicht und einfach nicht weiß...

mfg.
  VolGas

Hmm,

füge doch noch "RequireValidShell off" im "<Global>"-Block hinzu und starte den ProFTPD neu.
Die Verzeichnisrechte stimmen?

Wenn beides nicht hilft, bitte Debug-Ausgabe (siehe FAQs) von einem Log-Versuch hier posten.

mfg.
  VolGas

Hallo!

Es gibt hier unterschiedliche Methoden:

• Normalerweise ordnet man berechtigten Systemusern zusätzlich der Gruppe "ftp" zu
  und beschränkt den Zugang alleine auf diese Gruppe.
• Man kann den FTP-Zugang (teilweise oder gänzlich) nur für "virtuelle" User definieren.
  Damit kann man -unabhängig vom System!- eigene User mit eigenen Passworten definieren.
  Siehe: AuthUserFile, LDAP, SQL, etc...
• Ursprünglich prüfen FTP Server ein spezielles File (normalerweise /etc/ftpusers),
  wenn ein Client sich anmeldet. Ist der Username in diesem File aufgeführt, wird der Zugang verneint.
  Siehe Direktive: UseFtpUsers
• Der ProFTPD liefert umfangreiche Möglichkeiten, weitere Einschränkungen vorzunehmen.
  Am besten, Du schaust Dir einfach einmal die Tabelle mit den Konfigurations-Direktiven an.

Ich hoffe, ich konnte Dir damit weiterhelfen...

mfg.
  VolGas

[nicht]

Ändere einfach einmal folgendes:

• "DefaultRoot ~" nicht auskommentieren!
• Wenn sich nur User aus der SQL-Tabelle authentifizieren können sollen,
  (keine Systemuser!) dann fehlt: "AuthOrder mod_sql.c"
• Wenn in der SQL-Tabelle die User- & Gruppen-ID definiert werden, dann
  verbietet sich der Einsatz von "SQLDefaultUID" und "SQLDefaultGID"
• Bei "SQLUserInfo" gibt statt "shell" einfach "NULL" an -
  damit ist in der SQL-Tabelle das Feld auch überflüssig geworden
• Setze noch: "RequireValidShell off"
• Überprüfe, ob die Zugriffsrechte für das jeweilige Home-Verzeichnis stimmen
• Starte den ProFTPD neu...

Damit sollte es dann funktionieren...

mfg.
  VolGas

Hallo,

zur ersten Frage: das ist eim FTP-Protokoll so definiert, aber erzwingen/kontrollieren
kann man eine korrekte Eingabe nicht. Dher ist die Mailadresse nur "erwünscht"...

zweite Frage: wenn schon inetd, dann xinetd - besser konfigurierbar und sicherer.
Noch besser ist IMHO "standalone" - hiermit verwaltet sich der ProFTPD selbst am besten.
Es wird immer für jeden eingeloggten User ein neuer Prozess gestartet - egal wie.

mfg.
  VolGas

Hallo,

"<Anonymous ~ftp>" ist falsch, da gehört ein kompletter Pfad hin, kein Userverzeichnis.
(siehe: http://www.proftpd.de/Direktiven.54.0.html#1)

mfg.
  VolGas

Hi,

ich kann es nicht mit Gewissheit sagen, aber die Meldung scheint mir sehr erst zu sein.

Hast Du den ProFTPD als Binärpaket installiert, das mit einer anderen "glibc" compiliert wurde?
Das wäre am einfachsten, Du müßt dann nur einen ProFTPD installieren, der mit der selben Version
der "glibc" wie in Deinem System vorhanden compiliert wurde.

Eventuell hilft es, wenn Du zum Abgleich der Symboltabellen einfach einmal "ldconfig" ausführen
lässt, aber ich gebe diesem auch keine große Chance: die "glibc" ist ein zentraler Bestandteil des Systems
und wenn diese defekt ist, sollte man ernsthaft in Erwägung ziehen, sein System neu zu installieren.
Sorry.

Vielleicht kann jemand meine Vermutung bestätigen oder widerlegen - das würde mich auch interessieren.

mfg.
  VolGas