Genau: mit "useradd ..." usw.

ich möchte auch, dass die alten User FTP zugänge haben!

Welche alten Zugänge meinst Du???
Die, die jetzt schon da waren (User im System) wurden ja nicht geändert -
es bleibt alles wie gehabt. Zur Sicherheit könntest Du aber noch eines machen:
nicht alle eingetragenen Systemuser sollten automatisch auch einen FTP-Account
haben, sondern nur diejenigen, die einer bestimmten Gruppe (z.B. "ftpuser")
angehörig sind - denn so mancher Systemuser ist eigentlich gar kein User,
sondern nur ein Dienst oder Daemon: fatal, wenn damit jemand einloggen könnte.

Das ereicht man mit folgenden Zeilen in der proftpd.conf:

  <Limit LOGIN>
      DenyGroup !ftpuser
  </Limit>

Falls Deine Unix-Kenntnisse nicht ganz reichen sollten: mit "usermod -G ftpuser -a"
kann man nachträglich oder zusätzlich einem User eine weitere Gruppe zuweisen.
Siehe auch "man usermod"...

mfg.
  VolGas

@ rafel:

Danke für Deine wertvolle Info.
Würdest Du bitte noch posten, welche Version des ProFTPD und welches System Du benutzt?
Danke!

Noch ein kleiner Tipp: wenn in der proftpd.conf

   UseReverseDNS      off
   IdentLookups      off

steht, wird das Einloggen deutlich schneller als ohne.

mfg.
  VolGas

Schreibe mal zu Deiner proftpd.conf noch folgendes dazu:

   DefaultRoot      ~
   RequireValidShell   off
   UseReverseDNS      off
   IdentLookups      off

Ersteres ist sehr wichtig: es "beamt" den User in sein Verzeichnis und "sperrt"
ihn dort auch gleich ein. (chroot)
Die zweite Direktive ist ein altes Überbleibsel, sollte man ausschalten.
Die beiden nachfolgenden Direktiven braucht man nicht wirklich,
aber sie beschleunigen den Login.

Bei Deiner Konfiguration bezieht der ProFTPD die Userdaten aus dem System.
Einfach neuen System-User anlegen und dieser hat dann auch gleich einen FTP-Account.

mfg.
  VolGas

Hallo!

Na Du machst es Dir aber sehr einfach.
Je nach verwendetem Unix gibt es meistens aber auch einen noch einfacheren Weg
als von Stonki betrieben. Sehr oft haben die Maintainers eines Systems eine Möglichkeit
eingerichtet, wie man fertige Programmpakete automatisch installieren und "pflegen"
lassen kann. In z.B. Debian geht das ganz so: "atp-get install proftpd" - fertig!

Poste doch einmal, welches Linux Du einsetzt, vielleicht können wir dann damit weiterhelfen.

Um Dir die nötigen Linux-Grundkenntnisse anzueigen, kann ich Dir nur wärmstens
z.B. das Standardwerk, den "Kofler" empfehlen - kann nix schaden...

mfg.
  VolGas

Hallo,

die Meldung ist so abstrus, irreführend und nichtssagend, daß man damit nichts anfangen kann.
Du solltest in dem Logfile vom ProFTPD nachsehen, was dieser dazu "meint".

Ich tippe ja darauf, daß entweder Dein WS-FTP oder -noch viel eher!- Dein
M$-Pseudobetriebs- und Arbeitsbeschaffungssytem den Fehler verursacht hat.
(Nix für ungut!)

Wie schon geschrieben: es bleibt nur das Logfile des ProFTPD.
Wenn der Fehler hartnäckig immer wieder auftaucht, kann Dir eventuell die Direktive
"AllowStoreRestart on" in Deiner proftpd.conf weiterhelfen. Damit kann man
abgebrochene Transfers wieder aufnehmen - sofern der Client dies auch unterstützt.
Nach dem Upload würde ich aber unbedingt die Integrität der Datei überprüfen!

mfg.
  VolGas

Hallo!

Au weia...

Zuerst einmal: Deine proftpd.conf konfiguriert Deinen ProFTPD so, daß eigentlich
nur ein anonymer Zugang realisiert sein dürfte - ein regulärer Zugang ist nicht
definiert.

Füge daher Deiner proftpd.conf noch folgende Zeilen hinzu:

   UseReverseDNS      off
   IdentLookups      off
   RequireValidShell   off
   DefaultRoot      ~

   <Limit LOGIN>
      DenyGroup !ftpuser
   </Limit>

Neben ein paar Optimierungen sorgt das dafür, daß nur noch Systemuser, die
der Gruppe "ftpuser" angehören, sich einloggen können und dann in Ihr Heimat-
verzeichnis (Homedir) "gebeamt" und dort "eingesperrt" werden.

Neue User definiert man mit dieser Konfiguration im System, der ProFTPD entnimmt
diesem dann alles notwendige. Jetzt kommt die Stelle, an der ich Dir leider sagen muß,
daß man zumindest die absolut notwendigsten Grundkenntnisse von einem Linux-System
haben sollte, bevor man dort anfängt, etwas ändern oder einrichten zu wollen.
Ich kann Dir dazu nur wärmstens z.B. das Standardwerk, den ->"Kofler" empfehlen,
es gibt aber auch sehr viel weiterführende Literatur im Internet...

So nachdem ich das getan habe: mit z.B. "groupadd gruppe" (in der Unix-Shell) legt
man eine neue Benutzergruppe an, mit z.B. "useradd -d /pfad/zum/homedir -g gruppe username"
legt man einen neuen User an und mit "passwd username" erstellt oder ändert man
ein Userpasswort. Das ist z.T. systembedingt und Du solltest diese Befehle nicht einfach
blind übernehmen. Hilfe zu jedem Befehl gibt es normalerweise via "man ...",
also z.B. "man useradd".

Wie man einen "Daemon", also hier den ProFTPD, zum Beenden oder (Re)Starten bekommt,
ist von System zu System oft ein wenig unterschiedlich. Außer der direkten und etwas
unbequemen Methode via "kill" einem Prozess etwas "mitzuteilen", gibt es oft Scripte,
die eigentlich zum Starten eines Serverdienstes angelegt wurden, die dann aber auch die
wichtigsten Steuerungen übernehmen. So läßt man z.B. bei Debian den ProFTPD die
Konfigurationsdatei neu einlesen: "/etc/init.d/proftpd restart"

Komme zuerst einmal mit diesen Informationen zurecht, vielleicht findet sich ja der
Rest von alleine. Wenn nicht, melde Dich einfach wieder hier.
Aber bitte denke auch daran, daß dies eigentlich ein Forum für den ProFTPD ist, nicht für
Linuxfragen - dafür gibt es massig andere Foren und sonstige Quellen.

mfg.
  VolGas

Dies ist eine datenbankspezifische Lösung.
Mag funktionieren, aber beim Update von mySQL < 4.1 oder bei sich
vom Server unterschiedlichen Clientversionen passt dann gar nichts mehr.

IMHO ist die Option "Plaintext" -zumindest für eine Testphase- die Beste.

Näheres sie bei den ->Direktiven auf Stonki's Website -
diese Seite kann zur wahren "Offenbarung" werden...  

mfg.
  VolGas

Hi!

an welcher Stelle bekommst Du jeweils Dein "Connection Lost"?

Deine proftpd.conf sieht auf den ersten Blick eigentlich ganz ordentlich aus,
doch mit "SQLAuthTypes Backend" wäre ich allerdings sehr vorsichtig.

Ein Tipp kann ich dir gleich geben: der ProFTPD verabschiedet sich kang-
und sanglos bei einem SQL-Fehler, also überprüfe zuerst Deine SQL-Queries.
Du hast ja schon "SQLLogFile" in Deiner .conf eingesetzt, siehe einmal in
diesem Logfile, ob alles mit rechten Dingen vor sich geht. (das Logfile am
besten vorher einmal leeren!)

mfg.
  VolGas

hiho!

Für dynamische IP's gibt es für den ProFTPD eine Direktive: ->MasqueradeAddress.
Diese ist jedoch nur als Teillösung zu betrachten - generell ist FTP mit
dynamischen IP's ein recht komplexes Thema.

Dein geschildertes Problem liegt allerdings nicht beim ProFTPD -
und ist damit in diesem Forum völlig fehl am Platz.
Versuche es noch einmal in entsprechenden Foren.

mfg.
  VolGas

Hallo!

Was meinst Du mit "werden aber nicht akzeptiert"?

Wir haben auf einem unserer Server auch mehrere IP's, die wir z.T. auch als
virtuelle Server für den ProFTPD konfiguriert haben - ohne Probleme.

Poste doch einmal Deine ganze proftpd.conf hierher, dann sehen wir weiter...

mfg.
  VolGas

Hier haben wir das Szenario, wie es leider immer wieder vorkommt.
Wenn Du die Postings der letzten Wochen durchsiehst, wirst Du mehrfach darauf stoßen.
Siehe z.B. auch mein letztes Posting ->proftp TLS und die Firewall,
dort habe ich mich ein klein wenig ausführlicher auf das Thema eingelassen.

Sorry, aber hier enden meine Hilfsmöglichkeiten,
da das Thema an sich nahezu keine Lösung zuläßt.

mfg.
  VolGas

Es gibt drei verschiedene Modi für "TLSProtocol".
Hier ein Auszug der Original-Website des Entwicklers:

The allowed protocols are:

SSLv23   Compatibility mode, used to allow both SSLv3 and TLSv1
SSLv3   Allow only SSLv3
TLSv1   Allow only TLSv1

All use of SSLv2 is disabled. SSLv2 should not be used.

Die "beste" Einstellung, also die erfolgversprechendste, ist "SSLv23".

Den FTP-Client im passive mode ist ok und soweit sieht eigentlich alles gut aus.
Versuche einmal eine Verbindung ohne TLS (also nur "TLSEngine" auf "off") -
es sieht mämlich so aus, als ob bei Dir die sog. "high ports" nicht erreichbar wären.

Ist Deine Servermaschine hinter einem Router (Stichwort: NAT) oder hast Du eine
Firewall (bzw. IPtables) zwischen den beiden Maschinen?

mfg.
  VolGas

JA!
JA!
NEIN - nur eines, das sehr alt werden kann,
z.B. -days=3652 für etwa 10 Jahre oder
-days=5479 für etwa 15 Jahre oder
-days=7305 für etwa 20 Jahre...

Angekommen?

Das Thema dieses Forums ist der ProFTPD, alles andere ist off-topic und im
"restlichen" Internet in Massen zu finden. Aus dem Grund werde ich hier keine
weiteren Fragen bzgl. TLS, Zertifikaten usw. beantworten - es sei denn, es hat
wieder etwas speziell mit dem ProFTPD zu tun.

mfg.
  VolGas

Ich kenne diese Programme nicht, aber ich kann mir vorstellen, daß der KDE Konqueror
eine "perfekte" Kopie macht: er überprüft die Zugriffsrechte und definiert bei der neuen
Datei die selben Rechte explizit wieder.

Wenn Du den FTP-Befehl "site chmod" blockierst:

  <Limit SITE_CHMOD>
    DenyAll
  </Limit>

dann ist auch dies nicht mehr möglich und Deine Umask ist absolut.

mfg.
  VolGas

Nein, das ist alles andere als normal.

• versuche es einmal von einem anderen Rechner
• ist das dort genau so, dann füge in Deine proftpd.conf folgende Zeilen ein
  und starte anschließend den ProFTPD neu:

  <IfModule mod_delay.c>
    DelayEngine off
  </IfModule>

Jetzt bin ich ja mal gespannt...

mfg.
  VolGas