FTP Connect nicht möglich

[trace-1310]

Hallo zusammen,

ich habe nach einer (bzw. zwei) Neuinstallationen das Problem das ich mich nicht mit FTP connecten kann. Weder von der lokalen Konsole noch remote mit einem FTP Proggi ist es möglich sich zu verbinden. Die Logs sowie der Debug modus brachte auch keine weitere Erleuchtung über die Hintergründe.

Hier einige Infos:
System: Debian Lenny auf Xen-VHost
ispCP 1.0.5 OMEGA - build: 20100331

Connect auf localhost:
admin:~# ftp localhost
Connected to admin.my-domain.de.local.
421 Service not available, remote server has closed connection

Eintrag im Syslog:
proftpd[22087]: admin.my-domain.de (127.0.0.1[127.0.0.1]) - FTP session closed.

Wie schon geschrieben, ich habe das System mittlerweile 2 mal neu aufgesetzt, jeweils mit dem gleichen Ergebniss. Hat jemand noch eine Idee woran es liegen könnte.

Gruß, Trace

Update: Die Datenbank läuft auf einem Externen System. Die Abfragen kommen bei einem Connectversucht auch am MySQL-Server an und werden auch beantwortet.

[BeNe]

Ab in den DebugModus und das Output hier posten:

Code:

/etc/init.d/proftpd stop
proftpd -n -d5

--> http://isp-control.net/documentation/sol...tpd_issues

Greez BeNe

[trace-1310]

Jo, kein Problem.

admin.my-domain.net - mod_lang/0.8: binding to text domain 'proftpd' using locale path '/usr/share/locale'
admin.my-domain.net - ProFTPD 1.3.1 (stable) (built Tue Oct 27 10:09:08 UTC 2009) standalone mode STARTUP
admin.my-domain.net (127.0.0.1[127.0.0.1]) - FTP session requested from unknown class
admin.my-domain.net (127.0.0.1[127.0.0.1]) - FTP session closed.

Den gesamten Auszug habe ich angehängt.

[BeNe]

Code:

(127.0.0.1[127.0.0.1]) - FTP session requested from unknown class

Poste bitte noch deine modules.conf von ProFTPd.
Habe so das Gefühl das was am MySQL Module ist bzw. das es fehlt.

Greez BeNe

[trace-1310]

#
# This file is used to manage DSO modules and features.
#

# This is the directory where DSO modules reside

ModulePath /usr/lib/proftpd

# Allow only user root to load and unload modules, but allow everyone
# to see which modules have been loaded

ModuleControlsACLs insmod,rmmod allow user root
ModuleControlsACLs lsmod allow user *

LoadModule mod_ctrls_admin.c
LoadModule mod_tls.c

# Install proftpd-mod-mysql or proftpd-mod-pgsql to use this
#LoadModule mod_sql.c

# Install proftpd-mod-ldap to use this
#LoadModule mod_ldap.c

#
# 'SQLBackend mysql' or 'SQLBackend postgres' directives are required
# to have SQL authorization working. You can also comment out the
# unused module here, in alternative.
#

# Install proftpd-mod-mysql to use this
#LoadModule mod_sql_mysql.c

# Install proftpd-mod-pgsql to use this
#LoadModule mod_sql_postgres.c

LoadModule mod_radius.c
LoadModule mod_quotatab.c
LoadModule mod_quotatab_file.c

# Install proftpd-mod-ldap to use this
#LoadModule mod_quotatab_ldap.c

# Install proftpd-mod-pgsql or proftpd-mod-mysql to use this
#LoadModule mod_quotatab_sql.c
LoadModule mod_quotatab_radius.c
LoadModule mod_wrap.c
LoadModule mod_rewrite.c
LoadModule mod_load.c
LoadModule mod_ban.c
LoadModule mod_wrap2.c
LoadModule mod_wrap2_file.c
# Install proftpd-mod-pgsql or proftpd-mod-mysql to use this
#LoadModule mod_wrap2_sql.c
LoadModule mod_dynmasq.c


# keep this module the last one
LoadModule mod_ifsession.c

---

Wenn es bei dem MySQL aufruf klemmen würde, sollte der Server doch aber zumindest den Connect zulassen oder nicht. Zumindest sehe ich an der Datenbank das die requests von ispCP ankommen.

[BeNe]

Ja bei Dir ist kein MySQL-Module aktiv.
Aktiviere mal bitte:

Code:

LoadModule mod_sql.c
LoadModule mod_sql_mysql.c

Und versuche es dann nochmals.

Greez BeNe

[trace-1310]

Hi,

hat keine Auswirkungen. Die folgenden Zeilen in der proftpd.conf sollten doch die nicht geladenen Module nachladen sofern sie noch nicht vorhanden sind:

# Loading required modules
<IfModule !mod_sql.c>
LoadModule mod_sql.c
AuthOrder mod_sql.c
</IfModule>
<IfModule !mod_sql_mysql.c>
LoadModule mod_sql_mysql.c
</IfModule>
<IfModule !mod_quotatab.c>
LoadModule mod_quotatab.c
</IfModule>
<IfModule !mod_quotatab_sql.c>
LoadModule mod_quotatab_sql.c
</IfModule>

Die Anfragen vom proftpd kommen ja bei der Datenbank an und werden dort auch beantwortet. Somit dürfte es doch kein SQL Problem sein. Selbst wenn die Benutzer auf der Datenbank nicht abgefragt werden, sollte doch der proftpd ersteinmal nach einem Benutzernamen fragen. Das passiert ja schon nicht. Sowie ich einen connect auf den FTP versuche, wird der connect sofort wieder unterbrochen. Siehe:

Connected to localhost.local.
421 Service not available, remote server has closed connection

Auch ein connect mit telnet auf Port 21 bringt das gleiche Ergebniss.

[BeNe]

Ja der Teil mit den Module aus der Config hast Du ja vorher gar nicht gepostet
Das Problem ist aufjedenfall ein Module. Wenn ProFTPd nicht weis wohin er die Anfragen schicken soll bricht er ab. In deinem Fall wundert es mich das extern Anfragen an die DB gestellt werden. Local hast Du gar keinen MySQL am laufen ?

Greez BeNe

[trace-1310]

(07-06-2010 03:35 AM)BeNe Wrote:  Das Problem ist aufjedenfall ein Module. Wenn ProFTPd nicht weis wohin er die Anfragen schicken soll bricht er ab. In deinem Fall wundert es mich das extern Anfragen an die DB gestellt werden. Local hast Du gar keinen MySQL am laufen ?

Doch, am laufen schon aber unkonfiguriert. Beim Setup wurden alle Einstellungen für die Remote Datenbank gemacht. Die Einstellungen dazu finden sich auch in der proftpd.conf und sind soweit auch alle richtig. Ich habe vorsichtshalber dem vftp User auf der Datenbank zusätzlich auch schon die Rechte für den Netzwerkzugriff gegeben. Normalwerweise würde ich erwarten das ispCP einen Fehler ausgibt wenn der die DB nicht erreichen kann, zumindest war diese Fehlermeldung einmal implementiert. Vorsichtshalber werde ich aber nochmal den lokalen traffic sniffen ob die DB Anfrage nicht auf das lokale System gehen, dann ist aber unklar woher die Anfragen der Remote-DB kommen.

Gruß, Trace

Update:
Ich habe nochmal mit debuglevel 10 geschaut. MySQL greift zumindest laut debugauszug auf die richtige DB zu.

admin.my-domain.net (127.0.0.1[127.0.0.1]) - RELINQUISH PRIVS at mod_quotatab.c:2705
admin.my-domain.net (127.0.0.1[127.0.0.1]) - mod_sql/4.2.2: defaulting to 'mysql' backend
admin.my-domain.net (127.0.0.1[127.0.0.1]) - ROOT PRIVS at mod_delay.c:1102
admin.my-domain.net (127.0.0.1[127.0.0.1]) - RELINQUISH PRIVS at mod_delay.c:1104
admin.my-domain.net (127.0.0.1[127.0.0.1]) - FTP session closed.

[trace-1310]

Gefunden!

Letztendlich habe ich den Fehler nun gefunden. Der User "vftp" hat keine Rechte auf der Datenbank Folgender Eintrag in der proftpd.conf hat den Entscheidenden Hinweis gebracht:

SQLLogFile /var/log/proftpd/proftpd_mysql.log

Dort habe ich dan folgendes gefunden:

Code:

Jul 05 20:51:10 mod_sql/4.2.2[876]: >>> sql_sess_init
Jul 05 20:51:10 mod_sql/4.2.2[876]: entering    mysql cmd_defineconnection
Jul 05 20:51:10 mod_sql/4.2.2[876]:   name: 'default'
Jul 05 20:51:10 mod_sql/4.2.2[876]:   user: 'vftp'
Jul 05 20:51:10 mod_sql/4.2.2[876]:   host: '172.20.20.100'
Jul 05 20:51:10 mod_sql/4.2.2[876]:     db: 'ispcp'
Jul 05 20:51:10 mod_sql/4.2.2[876]:   port: '3306'
Jul 05 20:51:10 mod_sql/4.2.2[876]:    ttl: '0'
Jul 05 20:51:10 mod_sql/4.2.2[876]: exiting     mysql cmd_defineconnection
Jul 05 20:51:10 mod_sql/4.2.2[876]: entering    mysql cmd_open
Jul 05 20:51:10 mod_sql/4.2.2[876]: exiting     mysql cmd_open
Jul 05 20:51:10 mod_sql/4.2.2[876]: unrecoverable backend error
Jul 05 20:51:10 mod_sql/4.2.2[876]: error: '1044'
Jul 05 20:51:10 mod_sql/4.2.2[876]: message: 'Access denied for user 'vftp'@'172.20.20.%' to database 'ispcp''
Jul 05 20:55:19 mod_sql/4.2.2[1089]: defaulting to 'mysql' backend
Jul 05 20:55:19 mod_sql/4.2.2[1089]: backend module 'mod_sql_mysql/4.0.8'
Jul 05 20:55:19 mod_sql/4.2.2[1089]: backend api    'mod_sql_api_v1'

Ich habe also dem User "vftp" erst einmal die Rechte auf die Datenbank "ispcp" gegeben. Jedoch weiss ich nicht genau welche Rechte dieser User auf der DB braucht. Kann mir jemand noch die notwendigen Rechte für den vftp User geben. Ich möchte dem Benutzer auch nur die Rechte geben die er braucht.

Vielen Dank für die HILFE. Wenn ispCP hier ein wenig mehr loggen würde hätte ich das Problem auch schon früher finden können. Das ist evtl. auch ein guter Tipp für die nächsten Releases, zumindest das die Voreinstellung enthalten ist (kann im default ja auskommentiert sein).

Viele Grüße, Trace