Hallo!

Folgender Anweisungsblock sollte funktionieren:

Code:

    TLSEngine               on
    TLSProtocol             SSLv23
    TLSRequired             off
    TLSVerifyClient         off
   
    TLSOptions              NoCertRequest
    TLSLog                  /var/log/proftpd/tls.log
   
    # CA-Cert optional
#   TLSCACertificateFile        /etc/ssl/certs/CA.cert
    TLSRSACertificateFile       /etc/ssl/certs/meinserver.tld.cert
    TLSRSACertificateKeyFile    /etc/ssl/certs/meinserver.tld.key

Wenn es damit immer noch nicht funktionieren sollte, dann im TLSLog nachsehen.
Eine Beispiel-Konfiguration für einen Default- und beliebig viele virtuelle Server findet man ->hier.

Ich hoffe, du kommst damit weiter.

mfg.
  VolGas


Nachtrag:
Achtung: aufpassen bei Virtual-Hosts!
Fast alle Direktiven beziehen sich, sofern sie nicht in einem "<Global>...</Global>"-Block befinden,
nur auf den Default-Server! Der/die VHost-Server laufen dann mit ihren eigenen (Default-)Settings!
Deshalb nach Möglichkeit alles als Gobal definieren wie in dem Konfigurations-Beispiel gezeigt wird.

Das ist eindeutig: "ProFTPD terminating (signal 11)"  der ProFTPD ist Dir abgestürzt.
Das ist definitiv kein Konfigurationsfehler, sondern ein Installationsfehler - soviel zum Thema "stable"...
Ein Studium ist gut: damit kann man theoretisch erklären, warum es praktisch nicht funktioniert hat.

Wie ich mit Debian anfing, hatten mich die alten Klamotten darin damals genervt und ich habe mir dann
die Software, die ich haben wollte, aus dem "testing"-Branch installiert. Und jedes mal, wenn ich dachte
ich hätte jetzt die Maschine fertig, ist mir das System gänzlich (und für immer) zusammengebrochen -
aber jedesmal an einer anderen Stelle!

Im Rechenzentrum kennt man mich daher seit jener Zeit alleine schon an der Telefonnummer: bitte
Reset und Systemimage neu aufspielen...

Irgendwann hatte der Leiter des Rechenzentrums scheinbar Mitleid mit mir (oder einfach nur die
Schnautze voll) und hat mir verraten, wie sie intern das Ganze selbst handhaben: Debian als Plattform
ist ganz ok, aber die Software, mit der man arbeitet, kann man selbst compilieren und installieren.

Das habe ich ausprobiert: die Software wird in der Version und in der Art und an den Ort compiliert und
installiert, wie ich es brauche und möchte. Damit habe ich nicht irgend etwas universell funktionierendes,
altes, sondern ein maßgeschneidertes, aktuelles System, das seit Jahren stabil läuft, ganz ohne Versions-
konflikte mit dem System. Dafür muß ich eben aber auch selbst aufpassen, daß Sicherheitsupdates
rechtzeitig installiert werden, aber das ist nicht weiter aufwendig und schwierig.

Installationsbeispiele siehe ->hier und ->hier, Erklärungen dazu ->da.

An einem fertigen Softwarepaket, das abstürzt, sollte man IMHO nicht anfangen rumzufrickeln, es ist
einfach nicht zu gebrauchen. Ich kann Dir nur empfehlen, wie in den o.g. Beispielen den ProFTPD selbst
zu compilieren. Als stabile Plattform würde ich aber doch lieber "sarge" benutzen oder zumindest noch
die paar Tage warten, bis "etch" als "final" (bzw. "stable") freigegeben wird...

Fazit: tut mir leid, ich kann Dir speziell bei Deinem Problem nicht weiterhelfen.
Das Dingens ist kaputt!

Trotzdem noch schöne Feiertage!

mfg.
  VolGas

Hallo!

Zunächst möchte ich anmerken, daß ich es für sehr mutig finde, wenn jemand ein noch nicht
freigegebenes Betriebssystem in der Testphase benutzt...

Daß Du schon einmal ein Debug-Listing gepostet hast, ist ja ganz "nett", aber so vollkommen nutzlos.
Bitte noch einmal, dann aber den Output von einem Login-Versuch hier posten. Alles was vorher aus-
gegeben wird, bitte hier nicht noch einmal posten.

Aber SQL-Fehler werden damit nicht angezeigt: überprüfe also bitte zunächst einmal mittels "SQLLogFile",
ob nicht ein SQL-Fehler vorhanden ist. Die Datenmenge, die "SQLLogFile" erzeugt, ist immens und damit
nur zu Testzwecken sinnvoll.

Mit der Möglichkeit mit dem ProFTPD DSO-Module zu benutzen, habe ich keine Erfahrung.
Aber ich kann mich erinnern, daß wir hier im Forum schon einmal jemanden hatten, der sich auch
damit herumschlug. Scheint wohl doch noch nicht so ganz ausgereift zu sein!?

Ach ja: "...use of * in SQLAuthenticate has been deprecated.  Use AuthOrder..." - das hast Du mit
meiner Beispielkonfiguration nun ja schon gemacht, nur die Sternchen bei "SQLAuthenticate" müssten
noch entfernt werden...

mfg.
  VolGas

Ich habe schon verstanden, was Du haben möchtest.

Die einzige Möglichkeiten, die ich sonst noch sehe: mit "mod_exec" ein Script oder Programm starten
lassen oder ein Script/Programm, das via FIFO ein laufendes Log des ProFTPD analysiert und entsprechend
reagiert. Beides wird in der Doku zu "mod_exec" (Doku ->hier) kurz erläutert und demonstriert.

Der Aufwand und die Fehleranfälligkeit wären mir aber bei weitem zu hoch.
Meine Meinung: entweder eine Filestruktur entwickeln, die so etwas nicht nötig macht oder wenn das
nicht geht, dann sollten sich lieber die User daran gewöhnen, mehrere FTP-Accounts zu benutzen -
das ist ganz normal.

mfg.
  VolGas

Hi!

Das Ganze ist zuerst einmal widersprüchlich: mit der ersten Fehlermeldung würde der ProFTPD abbrechen
und gar nicht laufen. Scheinbar tut er es aber doch.

Leider hast Du es versäumt, Deine ganze proftpd.conf hier zu posten - vielleicht holst Du das noch nach...

Mit Deinem "SQLAuthTypes" wirst Du vermutlich den Hasen im Pfeffer haben: ich würde zunächst das Ganze
zuerst einmal mit Passworten im Klartext testen. Mal davon abgesehen, daß ich verschlüsselte Passworte
in einem schon geschützten Medium schlicht für Unsinn halte, passieren hier die allermeisten Fehler.

Deinem Debug-Output kann man nur entnehmen, daß der ProFTPD "unglücklich" mit dem Passwort ist.
SQL-Fehler bekommst Du übrigens nicht im Debug-Modus angezeigt, dazu braucht es die Direktive
"SQLLogFile". Aber Vorsicht, die Datenmenge ist immens und damit nur für Testzwecke geeignet!

mfg.
  VolGas

Hallo!

Ich habe nicht ganz verstanden, was Du wirklich möchtest.
Normalerweise befindet sich auf nahezu jeder Linux-Distribution ein FTP-Client "ftp". (welche Überraschung!)
Falls man nur Dateien "ziehen" möchte, so geht dies z.B. auch mit "wget ftp://user:pass@server.tld/pfad/datei"
oder so ähnlich auch mit "lynx ...". (siehe man-Pages: man lynx)

Falls der Suchpfad in der Shell-Variabeln "PATH" nicht so gesetzt sein sollte, daß Deine Binaries automatisch
gefunden werden, so mußt Du diesen entweder anpassen oder den vollständigen Pfad zu Deinem jeweiligen
Binary eingeben.

Man kann in jedem System normalerweise auch seine Programme suchen lassen: "whereis ftp" oder
"locate ftp", oder auch nachträglich über ein Paketmanagement (z.B. apt-get, yum, yast, ...) ein
Programm nachinstallieren.

Doch all dies hat eigentlich nicht spezielles mit dem ProFTPD und diesem Forum zu tun, sondern gehört zum
elementarsten Linux/Unix-Grundwissen. Dieses sollte man haben, bevor man 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...

Dennoch hoffe ich, daß Du mit meinen kurzen Infos weiterkommst.

mfg.
  VolGas

...es lag daran das für meine Benutzer kein Homeverzeichnis gab...

Scherzkeks! 

...funktioniert jetzt, obwohl die Fehlermeldungen noch da sind...

Welche Fehlermeldungen - wann, wo?
Ein bischen mehr Mühe (und Verstand) bitte - ich mag nicht hellsehen müssen! 

Thema beendet.

mfg.
  VolGas

Hi!

Zur ersten Frage: diese Frage hatte ich gerade einen Tag zuvor schon einmal beantwortet.
Siehe ->hier...

Bei "DisplayConnect" greift "DefaultRoot" noch nicht - der User ist ja noch nicht eingeloggt.
Der Pfad ist daher absolut anzugeben. Anführungszeichen sind eigentlich nicht notwendig.

Zu Zwei: siehe ->FAQ, langsame Logins.

mfg.
  VolGas

Der ProFTPD ist wie eine Usershell zu betrachten: nach dem Einloggen hat der neu gestartete,
individuelle Prozess die selbe User- und Group-ID wie der eingeloggte User - alle Root-Rechte
wurden aufgegeben. Damit hat der ProFTPD nur noch die selben Zugriffsrechte wie der User.

Entsprechend sind User & Gruppe des Files völlig egal, nur die Leserechte für dieses File müssen
passen, egal ob als User, Gruppe oder jedermann.

Ich habe das Ganze eben einmal an einem unserer Server ausprobiert: der Pfad zu dieser Datei
muß absolut von "DefaultRoot", und nicht vom root-Verzeichnis ausgehen, da das chroot von
"DefaultRoot" schon greift. Siehe dazu auch die Doku von ->DisplayLogin.

Den Inhalt der Datei findest Du dann im Logfile oder im sog. Transcript, im Trace bzw. Deinem
FTP-Client gemäß sonst irgendwo.

mfg.
  VolGas

Hi!

Ich sehe da eigentlich keine Möglichkeit, nur eine Alternative: die "VRootEngine".
Diese weicht die Direktive "DefaultRoot" auf und erlaubt es, mittels Symlink aus dem
chroot-Gefängnis herauszukommen. Wenn die User allerdings selbst Symlinks via
shell-Zugang oder ausführbare Scripte (Perl, PHP, etc...) anlegen können, ist dies
dann auch keine akzeptable Lösung mehr.

Kurzdoku zu ->VRootOptions, ausführlich: ->ProFTPD module mod_vroot

Ich hoffe, das konnte Dir weiterhelfen.

mfg.
  VolGas

Versuche es einmal mit dem vollständigen Pfad zu Deiner Datei, also "/srv/ftp/welcome.msg".
Klappt das?

mfg.
  VolGas

Hallo!

Die Fehlermeldung sagt doch alles: "Address already in use" bedeutet ganz einfach,
daß der Port belegt ist, also sehr wahrscheinlich ein anderer FTP-Server schon am
laufen ist. Daß dabei die IP-Adresse 0.0.0.0 versucht wird zu belegen, ist weiterhin
ein Zeichen, daß die Netzwerkkonfiguration scheinbar nicht in Ordnung ist.
(/etc/hosts korrekt?)

Beende den Prozess auf Port 21 und versuche noch einmal den ProFTPD zu starten.

Die proftpd.conf von Stonki ist zwar minimal(st), aber in Ordnung. Füge nur noch
"RequireValidShell off" hinzu.

mfg.
  VolGas

Die Konfiguration ist "klein, aber fein" und scheint ganz gut zu sein, nur "AuthOrder mod_sql.c"
würde ich noch hinzufügen. Ich hoffe nur , die Parameter von "SQLConnectInfo" sind nicht genau
so, wie von Dir hier gepostet...

Um SQL-Fehler herauszufinden, benutze die Direktive ->SQLLogFile und beobachte das SQL-Log.
Achtung: die Datenmengen sind immens, diese Logfile sollte man nur zur Fehleranalyse aktivieren!

mfg.
  VolGas

Hallo!

Ich kann es fast nicht glauben: bei dem "geschwätzigen" Debug-Mode kommen nur diese paar
nichtssagenden Zeilen raus?

Poste doch hier einmal Deine proftpd.conf, vielleicht kann man ja an der Konfiguration schon etwas
erkennen. Oder Du benutzt von vornherein gleich eine universell nutzbare Konfiguration - siehe z.B.
->proftpd.conf Standard Deluxe

Ehrlich gesagt: wer solch eine Anleitung ins Netz stellt, sollte sich dann auch um dessen Fehler und
Support kümmern. Außerdem scheint das SRPM wohl nicht offiziell und wird damit auch nicht gewartet
und ist somit zwischenzeitlich veraltet: version 1.3.0a des ProFTPD ist die derzeit aktuelle.

Ich würde mir daher den ProFTPD nicht aus dem SRPM-Paket bauen lassen, sondern die aktuellen
Sourcen "ziehen" und sie selbst compilieren.

Noch ein gut gemeinter Tipp:
Um Linux besser kennen und verstehen zu lernen, kann ich Dir allerwärmstens z.B. das Standardwerk,
den ->"Kofler" empfehlen, es gibt aber auch sehr viel weiterführende Literatur im Internet...

mfg.
  VolGas

Hallo!

Sensor am Fußgelenk: Kunden? 

Ok, der Fall scheint eindeutig so zu sein, wie Du schon vermutet hattest: die sog. "high ports"
könnten blockiert sein. Allerdings scheint der "Client", die Docking Station, die Daten nicht im
passive mode, sondern im aktive mode zu versenden - übel!

Wenn man Glück hat, dann gibt der Client einen passenden (erlaubten) Port an - der Transfer klappt.
Andernfalls kommt der Client in einen Portbereich, der durch die Firewall geschlossen wurde.

Normalerweise macht man das so: in die Firewall wird eine definierte "Bresche geschlagen",
die für den Datenverkehr offen ist, z.B. von Port 50000 bis 52000. Da dieser Bereich als frei definiert
ist und dort i.d.R. keine Server laufen, kann man dies als sicher einstufen. Dem ProFTPD wird dann
mittels Direktive "PassivePorts 50000 52000" mitgeteilt, welche Ports verwendet werden können.
Der Client, im passive mode!, fragt vor jeder Datenübertragung (via FTP-Kommando "pasv") beim
Server (ProFTPD) nach einem gültigen Port an - und schon funktioniert's...
Siehe auch ->Active-Passive Dokumentation

Leider bedeutet dies, daß die ganzen Docking-Stations umgestellt werden müssen -
da geht leider kein Weg daran vorbei. (egal ob mit oder ohne "Sensor")

mfg.
  VolGas