ProFTPD FAQ Deutsch

Deutsch: mailto:support@stonki.de

letztes Update: Freitag, Januar 4, 2002
Fehler, Anmerkungen, Tips & Tricks bitte an support@stonki.de

0. Einführung in diese FAQ

1. Einführung zu ProFTPD

2. Wie starten ? Kompilieren und installieren

3. Fragen zur Konfiguration

4. Übliche Start Probleme

5. Wie kann ich ?

0. Einführung in diese FAQ

Diese FAQ basiert zu grossen Teilen auf die original ProFTPD FAQ, stellt jedoch nur einen kleinen Teil der originalen FAQ da. Anregungen, Ergänzungen, Korrekturen nehme ich gerne auf.

Außerdem beinhaltet diese Dokument Teile der FAQ von Sven Höxter.

1. Einführung zu ProFTPD

1.1 Was ist ProFTPD ?

ProFTPD ist ein FTP Server für (hautpsächlich) diverse Unix Varianten, neuerdings auch für Windows. Das Konzept und Design lehnt sich stark an Apache an (Konfiguration, Modularer Aufbau).

1.2 Was die aktuelleste Version ?

Stabil: 1.2.5 RC1

1.3 Wer pflegt den Code ?

Wie bei allen Open Source Projekten, kann man keiner einzelnen Person das Paket zuordnen. Das ProFTPD Projekt wurde von Floody gestartet, der bis etwa Version 1.2.0pre2/3 hierfür verantwortlich war, bis seine Zeit jedoch nicht mehr ausreichte. Ab dem Zeitpunkt (Mitte 1999) ist MacGyver für das Projekt verantwortlich. Ab 2001 ist Floody zurück im Team.

1.4 Webseite & Dokumentation

http://www.proftpd.org/ stellt die Hauptseite für das ProFTPD Projekt da und hier findet man die komplette Dokumentation, FAQ und Beispiel Konfigurationen.
Unter http://www.proftpd.de/ pflegt Stonki eine eigene -nicht offizielle- Seite, die Teile der Dokumentation in Deutsch zur Verfügung stellt. Diese Dokumentation ist jedoch gekürtzt und bei weitem nicht so umfangreich wie die originale !!

1.5 Ich habe einen Fehler gefunden, was soll ich tun ?

Fehler sollten sofort über http://bugs.proftpd.org/gemeldet werden. Patches sollen am besten in die ProFTPD Development Mailingliste geschickt werden.

1.6 Ich habe ein Sicherheitsloch gefunden, was soll ich tun ?

Bitte melde alle Sicherheitsproblem an security@proftpd.org bevor die Öffentlichkeit informiert wird. Es wäre nett, dem Entwicklerteam einige Tage zu geben, damit sie einen Patch bereit stellen können.

1.7 Mailing Listen

Es gibt drei Mailinglisten für ProFTPD. Alle sind auschliesslich in Englisch. Support für SuSE und ProFTPD kann man auch in der SuSE Mailingliste bekommen.

Announce

proftpd-announce@proftpd.org

Sehr wenig Traffic. Hier werden nur Ankündigungen und Änderungen veröffentlicht.
Anmeldung per Mail an mailto:proftpd-announce-request@proftpd@subject=subscribe mit "subscribe" als Subjekt.

Users

proftpd@proftpd.org

Diese Liste ist der eigentlich Support Channel für ProFTPD und hat relativ hohen Traffic (nichts gegen die SuSE Mailingliste, höchstens mal 20 Mails am Tag). Bitte lies die FAQ, die Dokumentation und ggf. das Archiv, bevor Du eine Frage stellst.

Anmeldung per Mail an mailto:proftpd-request@proftpd.org@subject=subscribe mit "subscribe" als Subjekt.

Development

proftpd-devel@proftpd.org

Disese Liste befasst sich mit der Entwicklung von ProFTPD , and feature design. It is NOT intended to be a 'user help' group.

Subscribe by sending a message to mailto:proftpd-devel-request@proftpd.org@subject=subscribe with 'subscribe' in the subject.

Archive

Die Archive der Mailingliste können hier gefunden werden:

User: http://www.proftpd.org/proftpd-l-archive/
Development: http://www.proftpd.org/proftpd-devel-archive/

2. Wie starten ? Download, kompilieren und Installieren

2.1 Welche Plattformen werden unterstützt ?

ProFTPD wurde bereits auf folgende Platformen portiert.

• Linux 2.0.x & 2.2.x (glibc 2.x only) & 2.4.x
• BSDI 3.1 & 4.0
• IRIX 6.2, 6.3, 6.4, 6.5
• Solaris 2.3.1, 2.6, 2.7, 8 (Sparc)
• AIX 3.2 & 4.2
• OpenBSD 2.2/2.3
• FreeBSD 2.2.7
• Digital UNIX 4.0A
• DEC OFS/1

2.2 Wo finde ich ProFTPD ?

2.2.1 direkt vom ProFTPD-Server: ftp://ftp.proftpd.org/distrib/ (als Quellcode). Die dort angebotenen RPM Pakete hängen immer ein wenig hinterher.

2.2.2 direkt vom ProFTPD-Server als CVS (very hot stuff :-) )

CVS

CVS erlaubt mehreren Entwicklern eine gemeinsame Codebasis zu bearbeiten. Falls man an dem neusten Code interesssiert ist, kann man sich auch das aktuelle CVS downloaden. Aber Vorsicht: Dieser Code ist unter Umständen mit neuen Fehlern verseucht, weigert sich zu kompilieren oder enthält schwere Sicherheitslöcher...

CVS: cvs -d :pserver:anonymous@proftpd.org:/var/proftpd login (password is proftpd)
cvs -d :pserver:anonymous@proftpd.org:/var/proftpd checkout proftpd-1.2
Dann in das proftpd-1.2 Verzeichnis wechseln und "cvs update" tippen.

2.2.3 CVS als download

Ein Benutzer von ProFTPD stellt täglich das aktuelle Tar Archiv vom CVS Code zum download bereit. Dieses kann unter ftp://ftp.stikman.com/pub/proftpd/bezogen werden. Aber auch hier bitte an die eventuellen Nachteile denken

2.2.4. SuSE

Jeder SuSE Version liegt das Paket proftpd bei (in der Serie n2). Der Vorteil liegt darin, daß die Version bereits angepasst ist, an die Verzeichnisstruktur von SuSE. Siehe dazu auch Punkt 2.3

2.3 ProFTPD auf SuSE Systemen installieren

SuSE verwendet eine andere Verzeichnisstruktur als ProFTPD. Die Konfigurationsdateien liegen z.B. bei SuSE in /etc, bei ProFTPD defaultmäßig in /usr/local/etc. Deshalb sich entweder die ProFTPD Pakete von SuSE direkt runterladen oder daran denken, daß die Verzeichnisstruktur bei ProFTPD eine andere ist. Alternativ kann man natürlich das Makefile von Hand anpassen. Aber auch, wenn man die Standard Verzeichnisse von ProFTPD nimmt, funktioniert ProFTPD unter Suse ohne Probleme. Die RPM Pakete von SuSE sind jedoch an die Verzeichnisstruktur von SuSE angepasst.

2.4 Nicht Standard Module:

ProFTPD liegen einige Module bei, die bein einfachen Kompilieren nicht eingebunden werden. Diese liegen im Verzeichnis /contrib im ProFTPD Quellcode. Unter anderem stellen diese Module Quota oder andere Anmeldungsverfahren zur Verfügung. Die benötigten Module müssen beim Configure mit angegeben werden.

./configure --with-modules=mod_module1:mod_module2:mod_module3
make
make install

2.4 Wie kompiliere ich nun ?

Der kurze Weg für alle Standard Installationen:
wechsel in das Verzeichnis mit dem ProFTP Quellcode,

./configure
make
su   (dann ROOT Passwort)
make install

2.5 Genaue Anleitung:

1. nach dem Download:
   tar -zxf proftpd.tar.gz
   cd
   ./configure
   (ggf. ./configure --enable-shadow
   --prefix=/wo/du/moechtest/normalerweise/usr/local/
   --sysconfdir=/wie/du/moechtest/etc/oder/prefix/etc)
2. make && make install
3. cp proftpd.conf nach sysconfdir
   (Beispiel fuer eine Basis config liegt im Source Directory unter
   sample-configurations)
4. Setze folgende Zeile in die inetd.conf und deaktiviere alles andere mit ftp am
   Anfang durch das Vorranstellen eines "#".
   ftp stream tcp nowait root /dein/pfad/zum /proftpd/sbin/proftpd proftpd
5. Restarte den inetd. Meistens /etc/init.d/inetd restart
6. Freue dich ueber einen funktionierenden proftpd! (Wenn das nicht geht stimmen irgendwelche Pfade nicht.
   Alternativ kannst Du in der proftpd.conf auch als ServerType standalone
   angeben und mal ein proftpd --help machen (also /dein/pfad/zum/proftpd/sbin/proftpd --help)
   Dann siehst Du die moeglichen Parameter und kannst dir zusammen suchen was Du brauchst. Da kannst Du auch das Debuglevel hoeher stellen. (-d 5 ist am hoechsten, in dem Zusammenhang ist ein -n auch ganz sinvoll damit man den
   Output direkt auf die Konsole bekommt)

3. Konfiguration

ProFTPD stellt einige Standard Config-Files zur Verfügung. Die einzelnen Configs sind (solange nichts spezielles verlangt wird) selbsterklärend und ausreichend gut dokumentiert. Bei SuSE findet sich die Config in /etc/proftpd.conf, bei einer Installation des Quellcodes von ProFTPD direkt in /usr/local/etc/proftpd.conf

3.1 Wie kann ich einen weiteren anonymen oder Gast Zugang einrichten ?

You should look in the sample-configurations/ directory from your distribution tarball. Basically, you'll need to create another user on your system for the guest/anonymous ftp login. For security reasons, it's very important that you make sure the user account either has a password or has an "unmatchable" password. The root directory of the guest/anonymous account doesn't have to be the user's directory, but it makes sense to do so. After you have created the account, put something like the following in your /etc/proftpd.conf file (assuming the new user/group name is private/private):

---

<Anonymous ~private>
AnonRequirePassword off
User private
Group private
RequireValidShell off
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>

---

This will allow ftp clients to login to your site with the username "private" and their e-mail address as a password. You can change the AnonRequirePassword directive to "on" if you want clients to be forced to transmit the correct password for the 'private' account. This sample configuration allows clients to change into, list and read all directories, but denies write access of any kind.

3.2 Wie kann ich FTP Zugang als root bekommen ?

Zuerst: Das ist eine SCHEISS Idee, da bei FTP das Passwort unverschlüsselt übertragen wird. Ich empfehle entweder FTP über SSH (selber noch nie probiert), oder als User die Files uploaden und dann mittels SSH Connect die Dateien da hinschieben, so sie hin sollen.

Um es dennoch zu tun (Sie wurden gewarnt *g*) einfach die Direktive "RootLogin on" in die Config einfügen.

3.3 Wie schaffe ich eine sichere Upload Umgebung ?

Der folgende Ausschnitt aus einer Konfiguration zeigt, wie man ein spezielles Upload Verzeichnis erstellt, aus dem man nicht Downloaden kann. Dieses verhindert, daß öffentliche Server als Warez, DivX oder MP3 Server mißbraucht werden.

---

<Anonymous /home/ftp>
  # alle geuppten Files bekommen als Benutzer usernamer.usergroup
  User username					# user namen
  Group usergroup				# Gruppen namen
  UserAlias ftp username		
  AuthAliasOnly on
  RequireValidShell off

  <Directory pub/incoming/>		
	<Limit STOR CWD>			# Schreiben und Verzeichnis wechseln
        AllowAll				# wird erlaubt
     </Limit>
     <Limit READ RMD DELE MKD>  # alles andere
        DenyAll					# wird verboten
	</Limit>
  </Directory>
</Anonymous>

---

Dieses verhindert alle schreibenen Operationen zu dem anonymen Root Verzeichnis und allen Unterverzeichnissen, außer in "incoming", wo schreiben erlaubt ist, jedoch nicht lesen. Wenn man statt "<Limit STOR>" "<Limit WRITE>" benutzt, dann erlaubt man außerdem noch das erstellen von Verzeichnis, das Unbennen und das Löschen von Dateien !

3.6 How can I hide a directory from anonymous clients.

Use the HideUser or HideGroup directive in combination with the proper user/group ownership on the directive. For example, if you have the follow directory in your anonymous ftp directory tree:

        drwxrwxr-x 3 ftp staff 6144 Apr 21 16:40 private

You can use a directive such as "HideGroup staff" to hide the private directory from a directory listing. For example:

---

<Anonymous ~ftp>
...
<Directory Private>
HideGroup staff
</Directory>
...
</Anonymous>

---

3.7 Das verstecken von Files/Verzeichnissen klappt nicht !

You need to make sure that the group you are hiding isn't the anonymous ftp user's primary group, or HideGroup won't apply.

3.8 I want to prevent users from accessing a hidden directory

You can either change the permissions on the directory to prevent the anonymous FTP user from accessing it, or if you want to make it appear completely invisible (as though there is no such directory), use the IgnoreHidden directive inside a <Limit> block for one or more commands that you want to completely ignore the hidden directory entries (ignore = act as if the directory entry does not exist).

3.9 How do I setup a virtual FTP server?

You'll need to configure your host to be able to handle multiple IP addresses. This is often called "aliasing", and can generally be configured through an IP alias or dummy interface. You need to read your operating system documentation to figure out how to do this. Once your have the host configured to accept the additional IP address that you wish to offer a virtual FTP server on, use the <VirtualHost> configuration directive to create the virtual server:

---

<VirtualHost 10.0.0.1>
ServerName "My virtual FTP server"
</VirtualHost>

---

You can add additional directive blocks into the <VirtualHost> block in order to create anonymous/guest logins and the like which are only available on the virtual host.

3.10 I only want to allow anonymous access to a virtual server

Use a <Limit LOGIN> block to deny access at the top-level of the virtual host, then use <Limit LOGIN> again in your <Anonymous> block to allow access to the anonymous login. This permits logins to a virtual anonymous server, but denies to everything else. Example:

---

<VirtualHost 10.0.0.1>
ServerName "My virtual FTP server"
<Limit LOGIN>
DenyAll
</Limit>
<Anonymous /usr/local/private>
User private
Group private
<Limit LOGIN>
AllowAll
</Limit>
...
</Anonymous>
</VirtualHost>

---

3.11 How does <Limit LOGIN> work, and where should I use it?

The <LOGIN> directive is used to control connection or login access to a particular context (the directive block which contains it). When a client initially connects to ProFTPD, the daemon searches the configuration tree for <Limit LOGIN> directives, and attached parameters (such as Allow, Deny, etc). If it determines that there is no possible way for the client to ever be allowed to login, such as a "Deny from" matching the client's source address, without an overriding "Allow from" at a lower level, the client is disconnected without being offered the opportunity to transmit a user and password.

However, if it is possible for the client to be allowed a login, ProFTPD continues as per normal, allowing the client to login only if the proper <Limit LOGIN> applies. Normally, <Limit> directive blocks are allowed in the server config, <VirtualHost>, <Anonymous> and <Directory> contexts. However, <Limit LOGIN> should not be used in a <Directory> context, as clients do not connect/login to a directory (and thus it is meaningless).

By way of example, the following configuration snippet illustrates a <Limit LOGIN> deny which will cause any incoming connections from the 10.1.1.x subnet to be immediately disconnected, without a welcome message:

---

...
<Limit LOGIN>
Order deny,allow
Deny from 10.1.1.
Allow from all
</Limit>
...

---

Next, an example of a configuration using <Limit LOGIN> that will not immediately disconnect an incoming client, but will return "Login invalid" for all login attempts except anonymous.

---

...
<Limit LOGIN>
DenyAll
</Limit>
<Anonymous ~ftp>
...
<Limit LOGIN>
AllowAll
</Limit>
...

---

3.12 How can I limit users to a particular directory tree?

For general open access you can use an <Anonymous> directive context block, possibly in combination with a UserPassword/AnonRequirePassword directive.

However if you wish to jail an entire group (or groups) of users, you can use the DefaultRoot directive. DefaultRoot lets you specify a root jailed directory (or ' ' for the user's home directory), and an optional group-expression argument which can be used to control which groups of users the jail will be applied to. For example:

---

...
<VirtualHost myhost.mynet.foo>
DefaultRoot ~
...
</VirtualHost>
This creates a configuration where all users who log into
myhost.mynet.foo are jailed into their home directories (cannot chdir
into a higher level directory). Alternatively, you could:
...
<VirtualHost myhost.mynet.foo>
DefaultRoot /u2/public users,!staff
...
</VirtualHost>

---

In this example, all users who are members of group 'users', but not members of group "staff" are jailed into /u2/public. If a user does not meet the group-expression requirements, they login as per normal (not jailed, default directory is their home). You can use multiple DefaultRoot directives to create multiple jails inside the same directive context. If two DefaultRoot directives apply to the same user, ProFTPD arbitrarily chooses one (based on how the configuration file was parsed).

Security Implications

The DefaultRoot directive is implemented using the chroot(2) system call. This moves the "/" (or root) directory to a specified point within the file system and jails the user into this sub-tree. However this is not the holy grail of security, a chroot jail can be broken, it is not a trivial matter but it's nowhere near impossible. DefaultRoot should be used as part of a general system of security not the only security measure.

A more detailed discussion on this subject and on the breaking of chroot jails has been written by Simon Burr

Non-root server issues

The chroot() system call will not work under a non-root ftp server process, the call requires root privaliges. Without them it simply doesn't work, there doesn't appear to be any checking in the code of the uid/gid before calling chroot so using DefaultRoot in such a setup will cause the server to fail.

Symlinks

Symlinks will not work from within a chrooted area. The reason should be clear from a casual inspection of the nature of the chroot command. It is not possible to have a symbolic link to a directory which can't be reached beacuse it's outside of the current chroot. Work arounds to allow access to other parts of the file system include exporting the part of the filesystem to be accessed from inside the chroot and mounting via NFS, using hard file links or (on Solaris) using lofs to mount the directory via the loopback.

mount -Flofs /home/data1 /ftp/data1
mount -Flofs /home/data2 /ftp/data2

As of the 2.4.x Linux kernel tree it is possible to mount filesystems multiple times and to mount subdirectories of filesystems elsewhere on the filesystem.

3.13 How do I create individual anonymous FTP sites for my users?

There are two methods of accomplishing this (possibly more). First, you can create a directory structure inside your anonymous FTP root directory, creating a single directory for each user and setting ownership/permissions as appropriate. Then, either create a symlink from each user's home directory into the FTP site, or instruct your users on how to access their directory.

The alternate method (and more versatile) of accomplishing per-user anonymous FTP is to use AnonymousGroup in combination with the DefaultRoot directory. You'll probably want to do this inside a <VirtualHost>, otherwise none of your users will be able to access your system without being stuck inside their per-user FTP site. Additionally, you'll want to use a deferred <Directory> block to carefully limit outside access to each user's site.

1. Create a new unix group on your system named `anonftp'. Please each user who will have per-user anonymous FTP in this group.
2. Create an `anon-ftp' and `anon-ftp/incoming' directory in each user's home directory.
3. Modify your /etc/proftpd.conf file to look something like this (you'll probably want to customize this to your needs):

---

 <VirtualHost my.per-user.virtual.host.address>
 
 # the next line limits all logins to this virtual host, so that only
 anonftp users can connect
 
 <Limit LOGIN>
 DenyGroup !anonftp
 </Limit>
 
 # limit access to each user's anon-ftp directory, we want read-only
 except on incoming
 
 <Directory ~/anon-ftp>
 
 <Limit WRITE>
 DenyAll
 </Limit>
 
 </Directory>
 
 # permit stor access to each user's anon-ftp/incoming directory,
 but deny everything else
 
 <Directory ~/anon-ftp/incoming>
 
 <Limit STOR>
 AllowAll
 </Limit>
 <Limit READ WRITE>
 DenyAll
 </Limit>
 
 </Directory>
 
 # provide a default root for all logins to this virtual host.
 DefaultRoot ~/anon-ftp
 # Finally, force all logins to be anonymous for the anonftp group
 AnonymousGroup anonftp
 
 </VirtualHost>

---

3.14 I want to support normal login and Anonymous under a particular user

You can use the AuthAliasOnly directive to control how and where real usernames get authenticated (as opposed to aliased names, via the UserAlias directive). Note that it is still impossible to have two identical aliased names login to different anonymous sites; for that you would need <VirtualHost>.

Example:

---

...
<Anonymous ~jrluser>

 User jrluser
 Group jrluser
 UserAlias ftp jrluser
 UserAlias anonymous jrluser
 AuthAliasOnly on
 ...
 
</Anonymous>

---

Here, the <Anonymous> configuration for  jrluser is set to allow alias authentication only. Thus, if a client attempts to authenticate as 'jrluser', the anonymous config will be ignored and the client will be authenticated as if they were a normal user (typically resulting in `jrluser' logging in normally). However, if the client uses the aliased username `ftp' or `anonymous', the anonymous block is applied.

3.16 Bandbreiten Kontrolle

Zuerst eine Einschränkung: Es ist leider nicht möglich die Bandbreite für den FTP Server komplett zu beschränken. Hierfür muß man auf andere Tools zurückgreifen. Ich wäre um Tips zu diesem Thema sehr dankbar !!

Zur Zeit bietet ProFTPD "nur" eine Möglichkeit pro Verbindung an. Die Direktiven lauten: RateReadBPS, RateReadFreeBytes und RateReadHardBPS.

RateReadBPS                     81920
RateReadFreeBytes               5120
RateReadHardBPS                 on

Um die gesamte Bandbreite zu beschränken, ist ein Mix aus RateReadBPS und MaxClients notwending. (RateReadBPS x MaxClients = Totale Bandbreite)

3.19 Kann ich anonymen Zugang ganz abstellen ?

Ja, entferne einfach den gesamten Anonymen Bereich (von <Anonymous> bis einschliesslich </Anonymous>) in der Konfig und starte den Server neu (bzw. bei inetd geschiet dies automatisch beim nächsten Connect).

4. Übliche Start Probleme

4.1 Wie kann ich mehr Details erfahren ?

Wenn man Proftpd im Standalone Modus betreibt, empfiehlt sich die Ausgabe mit den Parameter "-n -d5". Jetzt erhält man die komplette Debugausgabe in die Console. Hier kann man genau erkennen, wieso etwas nicht läuft etc. Bei Aufruf durch Inetd einfach das Parameter -d5 der Zeile in der inetd.conf zufügen. Es gibt aber noch mehr Möglichkeiten:;

4.1.1 Welche Version des Proftpd benutzen Sie?

Oft treten Probleme nur in bestimmten Versionen auf deswegen ist es sehr hilfreich zu wissen welche Version des Proftpd Sie benutzen. Die Versionsnummer des proftpd finden Sie heraus indem Sie den Proftpd mit dem Parameter -vv starten:

sven@srv01:/mnt/home/sven > /usr/local/sbin/proftpd -vv
- Version: 1.2.1 (release)
- Internal Version: 01020001
Build Stamp: Die Mär 13 20:29:36 CET 2001

4.1.2 Welche module sind mit installiert?

Wenn Sie den Proftpd selber uebersetzt haben werden Sie wahrscheinlich noch wissen welche Module Sie mit uebersetzt haben, falls Sie aber ein binaer Packet installiert haben koennen Sie nicht sicher sagen welche Module mit uebersetzt wurden. Um sich die installierten Module anzeigen zu lassen muessen Sie den Proftpd mit dem Parameter -l starten:

sven@srv01:/mnt/home/sven > /usr/local/sbin/proftpd -l
Compiled-in modules:
mod_core.c
mod_auth.c
mod_xfer.c
mod_site.c
mod_ls.c
mod_unixpw.c
mod_log.c
mod_pam.c

 

4.1.3 Ueberprüfung des Syntax der Konfigurationsdatei?

Wenn Sie Aenderungen in ihrer Konfigurationsdatei machen ist es durchaus praktisch zuerst ueberpruefen zu koennen ob der Syntax richtig ist bevor Sie die neue Datei laden. Die einfachste Moeglichkeit fuer eine Syntax Ueberpruefung ist es den Proftpd mit den Parametern -td5 zu starten:

sven@srv01:/mnt/home/sven > /usr/local/sbin/proftpd -td5
Checking syntax of configuration file
srv01.home.hoaxter.de -
srv01.home.hoaxter.de - Config for Proftpd auf srv01:
srv01.home.hoaxter.de - Limit
srv01.home.hoaxter.de - Allow
srv01.home.hoaxter.de - /*
srv01.home.hoaxter.de - HideNoAccess
srv01.home.hoaxter.de - AllowOverwrite
srv01.home.hoaxter.de - Umask
srv01.home.hoaxter.de - AllowStoreRestart
srv01.home.hoaxter.de - MaxClients
srv01.home.hoaxter.de - Umask
srv01.home.hoaxter.de - MaxLoginAttempts
srv01.home.hoaxter.de - DefaultServer
srv01.home.hoaxter.de - AllowStoreRestart
srv01.home.hoaxter.de - DefaultRoot
srv01.home.hoaxter.de - User
srv01.home.hoaxter.de - UserName
srv01.home.hoaxter.de - Group
srv01.home.hoaxter.de - GroupName
srv01.home.hoaxter.de - MaxClients
srv01.home.hoaxter.de - TransferLog
Syntax check complete.

Das -t Parameter weist den Proftpd an die Konfiguration einzulesen und vor dem eigentlichen Start des Servers abzubrechen. Der -d5 Parameter weist den Proftpd an besonders ausfuehrliche Meldungen waehrend des Tests auszugeben. Ein anderer sehr nuetzlicher Befehl ist dieser hier: proftpd -c /pfad/zu/einer/neuen/konfigurationsdatei -td5. Damit koennen Sie z.B. eine zweite alternative Konfigurationsdatei testen.

4.1.4 Wo finde ich Log Dateien

Ein auf den Mailinglisten uebliche Antwort auf eine Frage ist 'Was sagen deine Logfiles?' Um Fehlermeldungen in Logfiles zu finden muss man erstmal die Logfiles selber finden. So witzig es sich auch anhoert so etwas muss nicht immer leicht sein. Einfach ist es wenn in der Konfiguration die Option 'SystemLog' gesetzt ist, der Parameter ist der Pfad zu dem Logfile. Anders sieht es aber aus wenn diese Option nicht gesetzt ist dann wird alles ueber den syslog gelogt. Wo der syslog die Daten hinschreibt geht aus der Datei /etc/syslog.conf hervor. Falls Sie sich noch nicht mit dem syslog beschaeftigt haben muessen Sie evtl. die manpages lesen bevor Sie verstehen wohin der syslog bei Ihnen was logt. Bitte beachten Sie das der Server waehrend der Authentifizierung die besondere Funktion authpriv des syslog nutzt. Unter SuSE wird meist in die Datei /var/log/messages geloggt

4.1.5 Sammeln von weiteren Informationen

Im Proftpd sind bereits Funktionen enthalten die ihnen sehr gute Informationen zum Debuggen zur Verfuegung stellen, Sie muessen diese Informationen nur aktivieren und sammeln :) Der einfachste Weg zu diesen Ziel ist es den proftpd im standalone mode auf der Kommandozeile mit den Parametern -nd5 zu starten. (alternativ kann man dem Aufruf in /etc/inetd.conf ein -d5 anhängen

voyager:/tmp/proftpd-cvs # sbin/proftpd -nd 5
- quota = 1
- QuotaBlockSize = 1024
- QuotaBlockName = kb
- quotacalc = 1
- Exempting: [2] 0
- QuotaType = hard
- default quota = 2000
- Compiling deny regex '.quota$'.
- Allocated deny regex at location 0x808a810.
voyager.telelev.de -
voyager.telelev.de - Config for ProFTPD Default Installation:
[Einlesen der kompletten Konfigurationsdatei]
voyager.telelev.de - ProFTPD 1.2.5rc1 (CVS) (built Fri Dec 28 13:23:40 CET 2001) standalone mode STARTUP
voyager.telelev.de (localhost[127.0.0.1]) - connected - local : 127.0.0.1:2221
voyager.telelev.de (localhost[127.0.0.1]) - connected - remote :127.0.0.1:48807
voyager.telelev.de (localhost[127.0.0.1]) - FTP session opened.
voyager.telelev.de (localhost[127.0.0.1]) - dispatching PRE_CMD command 'USER testuser' to mod_core
voyager.telelev.de (localhost[127.0.0.1]) - dispatching PRE_CMD command 'USER testuser' to mod_auth
....

Wie Sie hier auszugsweise sehen bekommen Sie so sehr viele Informationen zum Start des Servers und zu den ausgefuehrten Befehlen der User. In diesen Informationen finden Sie oftmals schnell die Loesung von User Problemen da hier wesentlich mehr Information ausgegeben werden als auf der Client Seite. Wenn Sie den relevanten Teil in diesen Informationen gefunden haben koennen Sie in eine Mail einfuegen um ihn fuer weitere Hilfestellungen an eine Mailingliste zu schicken.
Sollten Sie selbst nicht herrausfinden koennen welche Teile relavant sind und welche nicht koennen Sie auch einfach alles in eine Datei umleiten um diese komprimiert als Anhang an einer Mail mit zu schicken:

proftpd -nd5 2>&1 >/Pfad/zu/ihrem/debug/logfile
bzip2 -9 /Pfad/zu/ihrem/debug/logfile

Die letzte Zeile komprimiert die Datei z.B. mit bzip2. Bitte senden Sie keine unkomprimierten Dateien an eine Mailingliste! Wenn Sie den Server im inetd mode laufen haben und den mode zum debuggen nicht aendern wollen sollten Sie ueber die SystemLog Option loggen und die Paramter -nd 5 in ihrer inetd.conf hinzufuegen. Beachten Sie das Sie den inetd bei einer Aenderung der Konfiguration mit einem kill -HUP neu starten muessen. Beachten Sie ausserdem das die SystemLog Option nicht auf den inetd mode beschraenkt is. Falls Sie ihren Server lieber im Hintergrund laufen lassen wollen koennen Sie dies tuen, Sie sollten dann die Parameter -d5 (oder eine andere Debug Stufe) in ihrem init Script das den proftpd startet eintragen.
Wenn Sie erstmal die Debug Informationen gesammelt haben und in den verschiedenen FAQs, Userguides, Mailinglist Archiven, Suchmaschinen (www.google.de) etc. keine Loesung fuer ihr Problem finden konnten werden Sie sich wahrscheinlich an eine Mailingliste wenden. Bei einer Frage die Sie an eine Mailingliste schicken geben Sie bitte unbedingt folgende Dinge mit an: