Es ist schon ein wenig her das ich einen FTP-Server unter Linux neu einrichten musste. Meine alte Anleitung zum pure-ftpd (sie stammt aus dem Jahr 2002) hat mir stets gute Dienste erwiesen.
Per Zufall bin ich heute auf das grafische Tool für den pure-ftpd gestoßen: PureAdmin und wenige Minuten später auch auf ein häufig beschriebenes Problem: Es funktioniert nicht. 
Halt, Stopp! Bevor sich jemand schon nach dem Lesen dieser paar ersten Zeilen abschrecken lässt: Es geht noch weiter auf dieser Seite und ich habe für all jene, welche eine Suchmaschine auf der Suche nach einer Lösung für ihr Problem mit PureAdmin hierher geführt hat, eventuell auch eine Lösung parat.
Zunächst jedoch als ersten Eindruck die grafische Oberfläche von PureAdmin in der Version 0.4:
Herausragendes Merkmal von PureAdmin ist meiner Meinung nach die wirklich gut gelungene grafische Administration der virtuellen Benutzer, welche sich einfach ohne großen Aufwand mit der von pure-ftpd selbst verwalteten Userdatenbank für virtuelle Benutzer realisieren lässt.
PureAdmin setzt dort an, wo es vielen an der Konsole zu mühsam wurde: Einfach und intuitiv zu bedienen und obendrein auch noch zuverlässig (das Bild anklicken um es in voller Größe betrachten zu können):
Nun jedoch zum Problem, welches ich nach den anfänglich positiven Eindrücken von PureAdmin entdecken musste.
Was noch funktioniert ist das bequeme (und fehlerfreie) Anlegen von neuen virtuellen Benutzern per GUI. Man kann auch per Mausklick einfach den Server beenden und neu starten.
Jedoch erhält man (unter Ubuntu und Linux Mint) stets die selbe Fehlermeldung im Log von pure-ftpd beim Versuch sich einzuloggen:
[INFO] PAM_RHOST enabled. Getting the peer address
[WARNING] Authentication failed for user [USERNAME]
Das Fazit vorneweg
Normalerweise schreibt man sein Fazit nachdem man etwas bewiesen oder widerlegt hat. Ich ziehe jedoch das Fazit vor, denn den (Leidens)Weg, welchen ich mit PureAdmin hatte, sollte man sich eigentlich nur noch durchlesen um zu verstehen wie ich zu meinem Fazit gelangt bin.
Für mich stellt PureAdmin lediglich ein nützliches Tool in Form einer GUI für die virtuellen Benutzer dar. Die Administration der Benutzer ist einfach, intuitiv und vor allem für Neulinge, welche einfach nur einen FTP-Server unter Linux aufsetzen wollen hervorragend gestaltet.
Aber das war's dann auch schon.
Was PureAdmin meiner Meinung nach fehlt ist eine ausführliche Dokumentation wo und wie pure-ftpd durch PureAdmin angesprochen wird. Es fehlt sowohl auf der Website wie auch direkt in der Hilfe des Programms (welche lediglich aus zwei Links zur nicht wirklich informativen Website besteht) meiner Meinung nach von vorne bis hinten an Informationen. Kein Wunder also das Benutzer, welche eine einfach zu bedienende GUI erwarten, bitter enttäuscht und schnell frustriert sind.
Insbesondere dann, wenn das Programm nicht unter dem sonst einfach zu bedienenden Ubuntu (oder in meinem Fall Linux Mint) so funktioniert, wie man es sich wünscht.
Wie pure-ftpd funktioniert (Konfiguration über eine Zeile beziehungsweise den Programmaufruf) bekommt der Neuling für den Server leider nicht erklärt und selbst mir als »alten Hasen« was es pure-ftpd anbelangt bleibt die Hilfe die Antwort auf die Frage schuldig »Wo zur Hölle findet eigentlich die Konfiguration statt und wie kann ich sie meinen Wünschen nach anpassen?«
Meine Empfehlung/die Problemlösung
Wer sich mit einem einfachen FTP-Server mit eigentlich hervorragender Verwaltung der virtuellen Benutzer beschäftigen möchte, kann mit PureAdmin einfach und bequem diese Benutzer anlegen.
Die weitere Konfiguration samt Programmaufruf sollte zunächst »klassisch« vorgenommen werden. Wer die Schalter versteht, wird auch die beiden eigentlich simplen und leider sehr fatalen Fehler der Standardkonfiguration schnell gefunden haben.
Zunächst einmal fehlt im Standardpaket für Ubuntu der Aufruf für die Authentifizierung der virtuellen Benutzer. Diese kann mittels dieses Einzeilers eingefügt werden:
sudo ln -s /etc/pure-ftpd/conf/PureDB /etc/pure-ftpd/auth/45puredb
Weiterhin ein Fehler in der Konfiguration: Der verwendete Wert für MinUID steht auf 1000 statt auf 100.
Dies ist einfach durch eine Korrektur in der Datei /etc/pure-ftpd/conf/MinUID zu beheben:
sudo su -
echo "100" > /etc/pure-ftpd/conf/MinUID
exit
Mit dem Hintergrundwissen, wie die Konfiguration des Servers abläuft, konnte ich die Probleme relativ schnell finden und lösen.
Durch die vermeindliche »Hilfestellung« in Form von Postings im Internet wurde ich erst einmal völlig in die Irre geführt. Daher an dieser Stelle wie ich letztenendes zur Lösung gekommen bin (und dem Lesen vom »Leidensweg« ein letztes Mal vorweg greife):
Mit pureadmin wird die GUI gestartet, welche ihrerseits wieder auf das Script /etc/init.d/pure-ftpd zurückgreift. Natürlich kann man auch ohne pureadmin direkt das Script aufrufen. Man erhält in diesem Fall eine kurze Statusmeldung in Form des Aufrufs von pure-ftpd samt der Switches. Als Beispiel (mit dem fehlerhaften Wert für die UID-Sperre):
/etc/init.d/pure-ftpd restart
Restarting ftp server: Running: /usr/sbin/pure-ftpd
-l puredb:/etc/pure-ftpd/pureftpd.pdb -O clf:/var/log/pure-ftpd/transfer.log -B
-8 UTF-8 -A -u 1000
Anhand der in der manpage dokumentierten Switches kann man nun den Aufruf überprüfen und durch entsprechende Kommentare im Konfigurationsverzeichnis Einfluss nehmen. Mehr dazu am Ende des »Leidenswegs«... Sofern das alles jemand überhaupt lesen möchte. 
Der Leidensweg
Irritierend war für mich, dass ich lediglich eine einzige Fehlermeldung im Log als Ausgangsbasis zur Problemlösung hatte:
[INFO] PAM_RHOST enabled. Getting the peer address
Wieso eine PAM-Authentifizierung, wenn es eigentlich schlicht und ergreifend in die Datenbank mit den virtuellen Benutzern gehen soll? Genau diese wird doch von PureAdmin angelegt?
Mein erster Versuch führte prompt zum Erfolg: Ich habe per PureAdmin den Server beendet und per Hand von der Konsole aus neu gestartet – ohne PAM:
sudo pure-ftpd -j -l puredb:/etc/pure-ftpd/pureftpd.pdb
Verwendet wurde somit die von PureAdmin angelegte Datenbank für die virtuellen Benutzer. Der erste Test verlief erfolgreich. Ohne PAM war sofort das Einloggen mit dem unter PureAdmin gerade erst frisch erstellten virtuellen Benutzer möglich.
Mein erster Verdacht fiel also darauf, dass ich irgendwie den Aufruf der PAM-Authentifizierung eliminieren muss. Die Konfiguration vom pure-ftpd wird normalerweise mit einem einzeiligen Aufruf erledigt. Durch die Übergabe von Optionen in Form von »Switches« wird der Server konfiguriert. Bei der Verwendung von PureAdmin wird auf eine Art Konfigurationsverzeichnis mit Textdateien zurückgegriffen. Unter /etc/pure-ftpd/conf befinden sich mehrere Dateien:
-rw-r--r-- 1 root root 36 2009-05-07 00:04 AltLog
-rw-r--r-- 1 root root 6 2009-05-07 00:04 FSCharset
-rw-r--r-- 1 root root 5 2009-05-07 00:04 MinUID
-rw-r--r-- 1 root root 4 2009-05-07 00:04 NoAnonymous
-rw-r--r-- 1 root root 3 2010-01-28 21:35 PAMAuthentication
-rw-r--r-- 1 root root 28 2009-05-07 00:04 PureDB
-rw-r--r-- 1 root root 3 2009-05-07 00:04 UnixAuthentication
In der Datei PAMAuthentication ist der Wert yes hinterlegt. Eigentlich sollte man davon ausgehen, das ein Ändern dieses Wertes in no nach einem Neustart des Servers zur Folge hat, dass dieser ohne PAM-Authentifizierung gestartet wird.
Insbesondere dann, wenn sich in der Datei PureDB der korrekte Pfad zur eigenen Datenbank für virtuelle Benutzer des pureftpd befindet.
Ein Blick in die Logdatei gibt aber klar zu erkennen, dass die PAM-Abfrage weiterhin stattfindet. Warum nur?
Die Suche nach Problemlösungen im Internet lockte mich wie bereits erwähnt zunächst in eine völlig falsche Richtung. Ich bin auf ein paar Anleitungen gestoßen, welche das Problem beheben wollten. Jedoch war es eher ein herumprobieren von ein paar Beteiligten ohne zu erwähnen, welche Distribution bei ihnen überhaupt zum Einsatz kommt.
Die Antwort weshalb die PAM-Fehlermeldung erscheint ist sehr simpel: Die Authentifizierung über die Datenbank von Systembenutzern ist von Haus aus deaktiviert. Übergibt man pure-ftpd beim Start keine andere Möglichkeit, so versucht er es mit der PAM-Authentifizierung. Diese schlägt natürlich dann fehl wenn überhaupt nichts dementsprechend konfiguriert wurde.
Selbst nach dem (in einigen Threads vorgegebenen) Löschen der Datei wird pure-ftpd von beim Starten von PureAdmin mit der Option PAM-Authentifizierung gestartet.
Aufgrund meiner geringfügigen Erfahrung mit einem SuSE-System und der dort verwendeten Konfigurationsdatei hatte ich fälschlicherweise angenommen, in /etc/pure-ftpd/conf würden sich alle relevanten Dateien befinden und der Reihe nach abgearbeitet werden. Dies ist jedoch nicht der Fall. Der Aufruf der Authentifizierungsmethode erfolgt über das Verzeichnis /etc/pure-ftpd/auth beziehungsweise der sich darin befindenden Symlinks.
Nachdem ich dies entdeckt hatte (wirklich entdeckt, denn dokumentiert ist nichts), habe ich mittels dem Aufruf ls -la mir die Symlinks an der Konsole ausgeben lassen:
70pam -> ../conf/PAMAuthentication
Nach kurzem Nachdenken fiel mir auf, dass im Verzeichnis gar kein Symlink für den Aufruf der Informationen zur Datenbank in der Datei ../conf/PureDb existiert. Durch das Hinzufügen eines entsprechenden Symlinks war der erste Fehler in der Konfiguration behoben:
sudo ln -s /etc/pure-ftpd/conf/PureDB /etc/pure-ftpd/auth/45puredb
Und siehe da, schon ist die Fehlermeldung bezüglich der PAM-Authentifizierung verschwunden. Ich konnte mich mit dem zuvor angelegten virtuellen Benutzer schon ein wenig weiter anmelden. Jedoch erhielt ich nun die nächste Fehlermeldung im Fenster meines FTP-Clients:
530 Sorry, but I can't trust you
Die Logdatei vom pure-ftpd vermerkte:
[WARNING] Can't login as [USERNAME]: account disabled
Mir war klar, dass die Fehlermeldung damit zu tun hat, dass der Benutzer durch pure-ftpd aufgrund seiner UID nicht zugelassen wird. Beim ersten Blick in die /etc/pure-ftpd/conf/MinUID konnte ich jedoch keinen Fehler entdecken. Mit einer UID über 1000 ist doch eigentlich alles in Ordnung?
Eigentlich ja – würde PureAdmin nicht einfach die nächstliegenden UID und GID für ftpuser und ftpgroup ab 100 verwenden. So hatte ich die Werte 112 (ftpuser) und 116 (ftpgroup) auf meinem System – dank PureAdmin. Das beide Werte offensichtlich unter 1000 liegen, brauche ich wohl nicht extra zu betonen.
Daher habe ich umgehend den entsprechenden Wert angepasst:
sudo su -
echo "100" > /etc/pure-ftpd/conf/MinUID
exit
Erst nachdem ich diese Änderung vorgenommen habe und mittels Google nach »PureAdmin MinUID« gesucht habe, wurde ich darauf aufmerksam gemacht, dass ich zum Debuggen auch »einfach« den von PureAdmin verwenden Aufruf eines Skripts hätte verwenden können – /etc/init.d/pure-ftpd:
Usage: /etc/init.d/pure-ftpd {start|stop|restart|force-reload|status}
Anschließend konnte ich recht zügig die Konfiguration meinen Wünschen nach anpassen und hatte sowohl funktionierende virtuelle Benutzer wie auch einen begrenzten maximalen Upload – eben meine gewünschte Standardkonfiguration.
Wer es dennoch wagen möchte
In einem Forum bin ich auf eine mutmaßlich vollständige Liste der zu interpretierenden Einträge im Konfigurationsverzeichnis gestoßen:
'AllowAnonymousFXP' => ['-W'],
'AllowDotFiles' => ['-z'],
'AllowUserFXP' => ['-w'],
'AltLog' => ['-O %s', \&parse_string],
'AnonymousBandwidth' => ['-t %s', \&parse_number_1_2],
'AnonymousCanCreateDirs' => ['-M'],
'AnonymousCantUpload' => ['-i'],
'AnonymousOnly', => ['-e'],
'AnonymousRatio' => ['-q %d:%d', \&parse_number_2],
'AntiWarez' => ['-s'],
'AutoRename' => ['-r'],
'Bind' => ['-S %s', \&parse_string],
'BrokenClientsCompatibility' => ['-b'],
'CallUploadScript' => ['-o'],
'ChrootEveryone' => ['-A'],
'CreateHomeDir' => ['-j'],
'CustomerProof' => ['-Z'],
'Daemonize' => ['-B'],
'DisplayDotFiles' => ['-D'],
'DontResolve' => ['-H'],
'ForcePassiveIP' => ['-P %s', \&parse_string],
'FortunesFile' => ['-F %s', \&parse_filename],
'IPV4Only' => ['-4'],
'IPV6Only' => ['-6'],
'KeepAllFiles' => ['-K'],
'LimitRecursion' => ['-L %d:%d', \&parse_number_2],
'LogPID' => ['-1'],
'MaxClientsNumber' => ['-c %d', \&parse_number_1],
'MaxClientsPerIP' => ['-C %d', \&parse_number_1],
'MaxDiskUsage' => ['-k %d', \&parse_number_1],
'MaxIdleTime' => ['-I %d', \&parse_number_1],
'MaxLoad' => ['-m %d', \&parse_number_1],
'MinUID' => ['-u %d', \&parse_number_1],
'NATmode' => ['-N'],
'NoAnonymous' => ['-E'],
'NoChmod' => ['-R'],
'NoRename' => ['-G'],
'PassivePortRange' => ['-p %d:%d', \&parse_number_2],
'PerUserLimits' => ['-y %d:%d', \&parse_number_2],
'ProhibitDotFilesRead' => ['-X'],
'ProhibitDotFilesWrite' => ['-x'],
'Quota' => ['-n %d:%d', \&parse_number_2],
'SyslogFacility' => ['-f %s', \&parse_word, 99],
'TLS' => ['-Y %d', \&parse_number_1],
'TrustedGID' => ['-a %d', \&parse_number_1],
'TrustedIP' => ['-V %s', \&parse_ip],
'Umask' => ['-U %s:%s', \&parse_umask],
'UserBandwidth' => ['-T %s', \&parse_number_1_2],
'UserRatio' => ['-Q %d:%d', \&parse_number_2],
'VerboseLog' => ['-d'],
'FsCharset' => ['-8 %s', \&parse_string],
'ClientCharset' => ['-9 %s', \&parse_string],
);
my %authconf = ('ExtAuth' => ['extauth:%s', \&parse_sockname],
'LDAPConfigFile' => ['ldap:%s', \&parse_filename, 0,
'ldap'],
'MySQLConfigFile' => ['mysql:%s', \&parse_filename, 0,
'mysql'],
'PGSQLConfigFile' => ['pgsql:%s', \&parse_filename, 0,
'postgresql'],
'PAMAuthentication' => ['pam'],
'PureDB' => ['puredb:%s', \&parse_filename],
'UnixAuthentication' => ['unix'],
);
Mein bereits aus meiner alten Dokumentation von 2002 bekannter Aufruf sieht wie folgt aus:
pure-ftpd -B -A -E -j -k 80 -l puredb:/etc/pureftpd.pdb
Wenn die Angaben stimmen, müsste ich folgende Werte verwenden:
/etc/pure-ftpd/conf/Daemonize yes
/etc/pure-ftpd/conf/ChrootEveryone yes
/etc/pure-ftpd/conf/NoAnonymous yes
/etc/pure-ftpd/conf/CreateHomeDir yes
/etc/pure-ftpd/conf/MaxDiskUsage 80
Der Aufruf der Authentifizierungsvariante ist seltsamerweise nicht über -l gelöst worden, sondern separat. Dafür wurde der Switch -l für LogPID verwendet, welches nicht der Dokumentation gemäß der manpage von pure-ftpd entspricht. Dies sei jedoch nur sicherheitshalber am Rande erwähnt.
Der erste (von mir herausgesuchte) Eintrag ist prompt überflüssig gewesen, denn »Daemonize« ist immer schon im Aufruf durch das Script enthalten. Überprüft werden kann die selbst angepasste Konfiguration über den bereits erwähnten Skriptaufruf von /etc/init.d/pure-ftpd.
Das Script gibt auch Fehlermeldungen im Falle eines falschen beziehungsweise nicht kompatiblen Wertes in den Textdateien aus.
Fallstrick Windows Explorer
Abschließend zum heitigen Tage ein weiteres Problem, über welches mancher stolpern könnte: Wenn der Nutzer vom FTP-Service keinen vernünftigen FTP-Client sondern den (unsäglichen) Windows Explorer aus Faulheit verwenden möchte, wird er unter Umständen niemals eine Verbindung erhalten.
Nachdem der mit PureAdmin nun endlich funktionierende pure-ftpd von mir lokal getestet und für gut befunden wurde, sollte ein Bekannter Bilder auf eine Freigabe hochladen. Jedoch meldete er mir über ICQ zurück, der Server sei nicht erreichbar.
Dies passiert nicht nur beim Einsatz vom Windows Explorer, sondern auch bei manchen Browsern. Lediglich Opera meldete mir beim Test über localhost artig zurück, was ihm der FTP-Server meldet:
530 Login authentication failed
Beziehungsweise was Opera ausgibt:
421 Unable to set up secure anonymous FTP
Die Browser haben die unangenehme Eigenart, nicht nach Benutzername und Passwort zu fragen bevor sie eine Verbindung mit dem Server aufnehmen wollen. Sie ergänzen für die bequemen Nutzer einfach anonymous:WERT und versuchen sich anonym einzuloggen. Dies mag es bei den meisten FTP-Servern vereinfachen, da diese für einen Zugang per Anonymous konfiguriert sind.
Ist der Zugriff per Anonymous untersagt (so wie bei meinem pure-ftpd), so wird die Fehlermeldung 421 zurückgegeben. Der werte Explorer meldet jedoch nicht die Rückgabe dem Benutzer weiter, sondern behauptet lediglich, es könne keine FTP-Verbindung erstellt werden.
Die Fehlermeldung ist sicherlich nicht verkehrt, aber eben nicht ausführlich genug. Anstatt zu erfahren, dass kein Zugriff per Anonymous möglich ist, schließt der Anwender aus dem Verhalten des Browsers, dass gar keine Verbindung hergestellt werden konnte.
Wie oben schon erwähnt, gibt Opera (in meinem Fall Version 10.10) die Meldung des FTP-Servers aus. Firefox (Version 3.6) meldet sich übrigens mit der Eingabemaske für Benutzername und Kennwort.
Erfolgt der Aufruf im Explorer über ftp://username@hostname, schließt sich die Aufforderung das Passwort einzugeben an.
X_FISH
