proftpd 1.210 bleibt mit 100% cpu bei PASS (hidden) hängen.

[ddeml]

Hallo,

folgende Situation:
Ich habe einen Dedicated Server loadster.org bei Hetzner (Debian Sarge 3.1), auf dem ich mit SysCP installiert habe, dass u.a. proftpd als ftp nutzt. Authentifizierung und logging für quota geschieht über MySQL (siehe proftpd.conf).
Jetzt habe ich noch zusätzlich einen anonymen Zugang eingerichtet, der als Mirror einer round robin url (ftp.untergrund.net) angehört. Der funktioniert auch prinzipiell. Der Server ist recht belebt (4GB traffic und 800 connects pro tag). Dabei brechen laut log ca 100 sessions mit nem Signal 11 ab:

Code:

Mar 30 06:23:49 loadster proftpd[20706]: loadster (xbeliebigerleecher.com[xxx.xxx.xxx.xxx]) - FTP session opened.
Mar 30 06:23:49 loadster proftpd[20706]: loadster (xbeliebigerleecher.com[xxx.xxx.xxx.xxx]) - mod_delay/0.4: delaying for 29 usecs
Mar 30 06:23:49 loadster proftpd[20706]: loadster (xbeliebigerleecher.com[xxx.xxx.xxx.xxx]) - ProFTPD terminating (signal 11)
Mar 30 06:23:49 loadster proftpd[20706]: loadster (xbeliebigerleecher.com[xxx.xxx.xxx.xxx]) - FTP session closed.

Zudem bleiben über den Tag verteilt ca 50 proftpd prozesse mit 100% cpu mit z.B.:"pid:11519 user:nobody cpu:28.2% command: "proftpd: xxx.xxx.xxx.xxx:yyyyy: PASS (hidden)" hängen. Zur Zeit KILLe ich die regelmäßg per Hand, damit mir die MaxConnections nicht voll laufen und die cpu nicht ständig unter vollast läuft.

Welche Logs/Infos sind noch interessant? Hat da jemand eine Idee woran das liegen könnte?

Danke für jede Hilfe - Richie

Code:

ServerName                      "loadster.net FTP Server"
ServerType standalone
DeferWelcome                    off

MultilineRFC2228 on
DefaultServer                   on
ShowSymlinks                    on
AllowOverwrite                  on
AllowStoreRestart               on

TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200
TimeoutLogin 60

DisplayLogin                    welcome.msg
DisplayFirstChdir               .message
ListOptions                     "-l"

DenyFilter                      \*.*/

Port                            21
MaxInstances 50

# Set the user and group that the server normally runs at.
User                            nobody
Group                           nogroup

<Directory /*>
# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
  Umask                         022  022
# Normally, we want files to be overwriteable.
  AllowOverwrite                on
</Directory>

<Anonymous ~ftp>
  User                          ftp
  Group                         nogroup
  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias                     anonymous ftp
  # Cosmetic changes, all files belongs to ftp user
  DirFakeUser   on ftp
  DirFakeGroup on ftp
  RequireValidShell             off
  # Limit the maximum number of anonymous logins
  MaxClients                    50
  # We want 'welcome.msg' displayed at login, and '.message' displayed
  # in each newly chdired directory.
  DisplayLogin                  welcome.msg
  DisplayFirstChdir             .message
  # Limit WRITE everywhere in the anonymous chroot
  <Directory *>
    <Limit WRITE>
      DenyAll
    </Limit>
  </Directory>
</Anonymous>

DefaultRoot ~
RequireValidShell off

SQLAuthTypes Crypt Plaintext
SQLAuthenticate users* groups*
SQLConnectInfo syscp@localhost syscp geheimespasswort
SQLUserInfo ftp_users username password uid gid homedir shell
SQLGroupInfo ftp_groups groupname gid members
SQLUserWhereClause "login_enabled = 'y'"

SQLLog PASS login
SQLNamedQuery login UPDATE "last_login=now(), login_count=login_count+1 WHERE username='%u'" ftp_users

SQLLog RETR download
SQLNamedQuery download UPDATE "down_count=down_count+1, down_bytes=down_bytes+%b WHERE username='%u'" ftp_users

SQLLog STOR upload
SQLNamedQuery upload UPDATE "up_count=up_count+1, up_bytes=up_bytes+%b WHERE username='%u'" ftp_users

[VolGas]

Hallo!

ich habe Deine .conf nur überflogen, sie funktioniert ja und scheint auch soweit in Ordnung.

Ich meine in den Postings in letzter Zeit ein Muster zu erkennen:
alle ProFTPD, die mit eine, hohen CPU-Load stehen bleiben, scheinen mit
dem Modul "mod_delay" compiliert zu sein.

Zudem scheint auch der Maintainer des Debian-Pakets es für eine gute
Idee gehalten zu haben, das nicht standardmäßig in der (noch) aktuellen
Stable-Version beinhaltete Modul mit in sein Package einzubauen.

Daher empfehle ich hiermit zum ersten mal (gerade für Debabian-User!)
sich den ProFPTD selbst zu compilieren - ohne "mod_delay"...

Mich würde interessieren, ob damit das Problem wirklich gelöst werden konnte,
daher bitte ich -auch für alle anderen- um Rückmeldung. Danke!

mfg.
  VolGas

[ddeml]

Hallo VolGas,

danke für den Tipp.

Obwohl in von Beruf Softwareentwickler bin (C++, Java, .NET, X86-ASM - alles unter Windows), habe ich noch nie was unter linux selbst compiliert.

Gibt es da eine kleine HOWTO, die da einem das Leben leichter machen kann? Oder gar einen Dreizeiler?

Danke - Richie

[VolGas]

Noch nie etwas mit "make" zu tun gehabt?
Na dann ist Dir aber etwas "entgangen"...
Das mit dem Dreizeiler ignoriere ich einfach einmal als nicht geschrieben...

Es gibt garantiert massenhaft Anleitungen im Internet zum Compilieren u.a. auch
von ProFTPD, so mache ich es hier ganz kurz, indem ich Dir einen Auszug aus unserer
Serverdoku poste. Ich glaube, es gibt auch auf Stonki's Site irgendwo ein HowTo dazu.

Code:

## Debian-Installation entfernen, Startscripte erhalten
apt-get remove proftpd


## Sourcen holen und auspacken
cd /usr/src
wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.10.tar.bz2
tar -xjf proftpd-1.2.10.tar.bz2


## Compilieren und Installieren
# auf --disable-auth-unix verzichten - wird gebraucht
# zur Auflösung von Usernamen - auch in der .conf-Datei...

cd /usr/src/proftpd-1.2.10

./configure \
--with-modules="mod_sql:mod_sql_mysql:mod_tls:mod_ifsession" \
--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-1.2.10 \
--sysconfdir=/etc --localstatedir=/var/run --mandir=/usr/local/man

make
make install

...

Optionen und Pfade sind entsprechend anzupassen.
Wie hier zu sehen ist, können sehr lange Befehlszeilen mit "\" am Zeilenende
in eine neue Zeile umbrochen werden. Zu dem Compiliervorgang an sich werde ich
mich aber nicht auslassen. Dazu gibt es Doku's genug.

BTW: Solltest Du ernsthaft Interesse an Linux haben, so kann ich Dir
nur wärmstens z.B. das Standardwerk, den "Kofler" empfehlen...

mfg.
  VolGas

[Claif]

Hi,
was diesen Thread angeht:
http://www.proftpd.de/forum/viewtopic.php?t=2144
hätte ich erwähnen sollen das man in den logs sehr
viel über mod_delay findet und in der woody Version,
gab es noch keine Probleme (und kein mod_delay).

Hier eine ganz knappe Anleitung wie man sich unter
Debian die Sourcen zieht und wieder zu einem .deb File macht:

(Ich übernehme keine Haftung! Verwendung nur auf eigene
Gefahr. Anfängern empfehle ich da lieber nichts zu machen.)

# apt-get install dpkg-dev
# apt-get source proftpd  (werden in das aktuelle Verzeichnis geladen)
# mcedit proftpd-1.2.10/debian/rules  (mod_delay entfernen...)
# cd proftpd-1.2.10
# dpkg-buildpackage

Beim "dpkg-buildpackage" erscheinen mit Sicherheit noch einige
Pakete die benötigt werden, die alle mit aptitude install PAKETNAME
einrichten. Danach findet sich der neue proftpd ohne mod_delay in
dem Verzeichnis, wo zuvor auch das Source Verzeichnis zu finden war.

Evtl.
# aptitude remove proftpd
ausführen um den bisherigen proftpd zu entfernen.
Klappt die Install der eigenen Pakete nicht, ist der proftpd
schon weg. Klappt es doch, ist es nur drüber installiert.

Installiert die 2 neuen Pakete:
# dpkg -i proftpd-common_1.2.10-15sarge1_i386.deb proftpd_1.2.10-15sarge1_i386.deb

Die fertigen Pakete sind auch hier zu finden:
http://www.confident-hosting.de/proftpd/

So läuft die proftpd sarge Version ohne mod_delay,
also mal sehen ob es das Problem löst!

[VolGas]

@ Claif:

meine Güte - findest Du es einfacher, das Ganze wieder in (undurchsichtige) Päckchen
packen zu lassen, Schleifchen darum zu machen um dann damit im System herum zu jonglieren?
Sehr umständlich und fehleranfällig!

Ich finde das Triplett "configure/make/make install" direkter und wesentlich "ehrlicher"... ;-)

Aber nett von Dir, daß Du das fertige Paket zum Download zur Verfügung stellst.
Dann kann man nur noch hoffen, daß auf der anderen Maschine auch
alles an der richtigen Stelle ist...

mfg.
  VolGas

[Claif]

Hi,
nein in diesem Fall und Debian bedingt, ist das die schnellste
und beste Methode. So weiß man das nichts wichtiges fehlt - das
ändern und neu erstellen dauert tatsächlich nur eine Minute und danach
hat man exakt den gleichen proftpd wie vorher, nur ohne das
Modul was man nicht will.

Das klingt vielleicht kompliziert, aber mit dieser Methode kann
man jedes Debian Paket ändern und man muss sich nicht erst
in die compilier-Anleitungen der jeweiligen Software einlesen.
Das ist unter Debian universell und geht enorm schnell.
Vom Paket-Managment ist das eine sehr saubere Sache.
Ich kann festlegen ob beim nächsten offiziellen proftpd Update,
meiner mit der neuen Version ausgetauscht werden soll
oder ob meiner dauerhaft bleiben soll. Das ganze läuft auch
völlig fehlerfrei.

Jetzt kann ich diese 2 erstellten Dateien, auf allen Servern
verwenden und muss es nicht überall compilieren.

[VolGas]

Rein aus Interesse habe ich das von Dir beschriebene Zusammenstellen eines
Debian-Packages einmal probiert.

In dem mönströs zu nennenden makefile "rules" scheinen alle möglichen Versionen
(LDAP, mySQL, pgSQL, ...) vorgesehen zu sein. Wie kann ich nun dem dpkg-buildpackage
angeben, welches ProFTPD ich haben möchte? Das Teil wollte zum compilieren
nämlich tatsächlich alles gleichzeitig zusammen im System haben.

Das ging mir dann echt zu weit, hier hat mein Interesse aufgehört, denn die Integrität
und Sicherheit des Servers war mir wichtiger als monstermäßig unnötige Pakete
installieren zu lassen.

Ich finde das alles sehr umständlich und kompliziert.
Die Paketverwaltung von Debian ist sehr bequem, aber für unsere Serversoftware
möchte ich aktuellere Versionen als normalerweise angeboten haben und mit
nur genau den Features, die wir brauchen - keinen generellen Rundumschlag,
bei dem doch wieder irgendwelche Hintertürchen möglich und offen sind.

Ich habe recht böse Erfahrungen mit den Debian-Paketen gemacht, insbesondere,
wenn man von "testing" mehrere aktuellere Pakete installiert hat.

Auf unseren Maschinen ist Debian und über "apt" lassen wir alles auch von Debian
installieren und aktualisieren, aber Serversoftware wird von uns selbst compiliert
und verwaltet. Damit haben wir genau das, was wir wollen (nicht mehr und
nicht weniger!): optimierte Software und ein bislang super-stabiles System,
ganz ohne Überraschungen.

mfg.
  VolGas

[Claif]

Mach Debian bitte nicht schlecht nur weil es dir an
Erfahrung mangelt. Glücklicherweise denken nicht alle
so wie du, nicht umsonst ist es eines der beliebtesten und
sichersten Linux Distributionen. Wer aber zuvor den
proftpd unter Debian per apt-get bzw. aptitude installiert
hat, für den macht es nun mal mehr Sinn auch die sourcen
zu ändern und ein neues .deb File zu erstellen.
Deine unbegründete Debian Abneigung schadet nur dem
Forum und jetzt zurück zum Thema.

[VolGas]

Mir fehlt es weder an Erfahrung(!), noch möchte ich Debian schlecht machen.
Hätte ich eine Abneigung dagegen, dann wäre auf unseren Servern schon längst
ein anderes Betriebssystem. Ich habe ja geschrieben: wir haben bislang ein super-stabiles
System.

Es bleibt letztendlich jedem selbst überlassen, wie er seinen Server aufbaut.
Aber für eine Fehlersuche suche ich nun mal die kleinst mögliche Lösung, um
unerwartete oder "störende" Einflüsse (Module) zuerst einmal auszuschalten.

Mich hätte bei einer Antwort von Dir viel mehr interessiert, wie man es hinbekommt,
daß nur z.B. ein proftpd-mysql zusammengebaut wird. Ich bin ganz bestimmt
nicht unflexibel und auch gar zu gerne bereit, etwas neues zu lernen.

mfg.
  VolGas

[Claif]

Mir fehlt es weder an Erfahrung(!)...
daß nur z.B. ein proftpd-mysql zusammengebaut wird.

a) apt-cache search proftpd
b) apt-get source proftpd-mysql

Warum gleich so aggressiv? Es kann so einfach sein!
Möge die Macht mit dir sein   :mrgreen:

[VolGas]

Hmpf - genau so hätte ich es auch gemacht. ;-)
Danke.

Dann darfst Du dem "armen" ddeml aber eben nur diese Version als
Paket zum Download anbieten, nicht das Universal-Monster...

Kam ich aggresiv rüber?
Sorry, war nicht so gemeint.

Die Macht ist schon mit mir, danke.
Und möge Dir Dein Server immer online und ein Byte übrig sein.  :top)

Gruß
  VolGas

[Claif]

In den zwei Dateien die ich online gestellt habe,
ist irgendeine MySQL Unterstützung eingebaut. Wo
bei den beiden der Unterschied liegt, weiß ich nicht.
Ich nutze es ja nicht. Vielleicht schafft er es ja mit der
Anleitung.

[ddeml]

Ich hatte, bevor Claif dden alternativen weg geschildert hat, schon VolGas' lösung angefangen - bin noch nicht durch - Zeitmangel und so.

Ich hab mir übrigens den Kofler gleich bestellt, nachdem ich ihn nun zum dritten mal empfohlen bekommen hab.

Für mich ganz persönlich ist der "Fußweg" eine willkommene Möglichkeit, um mich etwas mehr in Linux reinzuarbeiten. Langfristig will ich - als Softwareentwickler - auch mal da hinkommen, solche bugs auch mal selbst fixen zu können.

Ich werde euch informieren, ob und wie ich das Problem gelöst habe - falls ich mich nicht sowieso hier nochmal hier melde...

Grüsse - Richie

[VolGas]

Wäre schön zu erfahren, ob es auch bei Dir dann ohne "mod_delay" klappt.
Das würde meine Theorie bestätigen. Hoffen wir, daß in der neuen Version
des ProFTPD dieser Fehler nicht wieder auftreten wird - das Modul ist dann
nämlich ein Standard-Modul...

Noch viel "Sapß" und viel Erfolg beim compilieren! ;-)

mfg.
  VolGas