I downloaded pure-ftpd with YAST from the Suse repository and activate xinetd to run with pure-ftpd (service set "on"). From that point of view everything seems OK. But when I try
ping 192.168.0.189
on my LAN I get no reply and command
ftp 192.168.0.189
results in
"Connected to 192.168.0.189"
and after some time
"Connection closed by remote host"

About a year ago I installed in the same way pure-ftpd on another computer and initially had the same problems. But then I saw from a post that the pure-ftpd binary in the Suse repository was corrupted. When I a bit later downloaded a new copy of pure-ftpd it then worked fine and I had a working ftp server program.

Is the corrupted version put back in the repository?

The file
/var/log/xinetd.log
is empty

a file with options in ASCII
/etc/xinetd.d/pure-ftpd
exists what must be a confirmation that YAST did its job to link xinetd to pure-ftpd.

An ELF 32-bit LSB executable
/usr/sbin/pure-ftpd
is there!

Did you try to run some ftp commands to see what happens?
AFAIK pure-ftpd is better to run standalone, as it can accept options from command line.
Did you restart xinetd after adding pure-ftpd to it?
Could you post /etc/xinetd.d/pure-ftpd?

Regards

I wanted to be as standard/mainstream as possible in order to avoid problems by doing it exactly as the SUSE/YAST designers intended.

The ftp server could run standalone or with xinetd, I do not care, it should just work!

The standard /etc/xinetd.d/pureftp as generated by YAST:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++==

# default: off
# description: The ftpd server serves FTP connections. It uses normal, \
# unencrypted usernames and passwords for authentication. This ftpd is \
# the pure-ftpd.
# ** NOTE ** when using pure-ftpd from xinetd the arguments to control
# it's behaviour should be added here in this file in the
# "server_args" line since the configuration file
# /etc/pure-ftpd.conf is only for standalone pure-ftpd.
# The command "/usr/sbin/pure-config-args /etc/pure-ftpd.conf"
# will print the arguments needed for behaviour like standalone
# pure-ftpd.
service ftp
{
# server_args =
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/pure-ftpd
}
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As my SUSE linux was just set up from live CD (full standard) and pure-ftpd was implemented with YAST it should be clear that the present setup is faulty. This failure must be fully reproducable by anybody!

Is it impossible to make SUSE interested in such a problem? No feedback to developers possible? Make a bug report that is taken seriously!

You should add
(anywhere before the closing "}") to enable it.

Quote:

Did you try to run some ftp commands to see what happens?

Well, after

ftp 192.168.0.189

the server should prompt for user ID. Before having logged in not commands can be issued!

I tried as /etc/xinetd.d/pure-ftpd:

service ftp
{
# server_args =
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/pure-ftpd
disable = no
}
i.e "disable = no" added

and re-booted:

Now I got:
"ftp connect unknown fault number"

First you don't need to reboot. Restarting xinetd should be enough.
Now regarding the error take a look at /var/log/xinetd, /var/log/messages etc to see if you find anything useful.
You can try to run it from command line to see what happens. To do so, make "disable = yes" and restart xinetd:

find / -name '*xinetd*' | grep log

gave:

/usr/share/man/man8/xinetd.log.8.gz
/var/log/xinetd.log
/etc/logrotate.d/xinetd




/var/log/xinetd.log is empty

/etc/logrotate.d/xinetd has the following contents:

/var/log/xinetd.log {
compress
dateext
maxage 365
rotate 99
size=+2048k
notifempty
missingok
copytruncate
postrotate
/etc/init.d/xinetd reload
endscript
}

Seems to define "/var/log/xinetd.log", the empty file, as log file with some parameters!

Is there a way to directly see if xinetd (i.e. a daemon) really is running?

Similar to "ps" for normal processes!

"service xinetd restart"

echos:

Shutting down xinetd: done
Starting INET services. (xinetd) done

but this is just how the shell script is programmed (I guess), no real confirmation that the start really took place without a "hang-up"

Actually, in "/var/log/messages" there are some traces. A large number of configuration files read. I guess xinetd is running, it is the activation of the ftp server program that does not take place properly:

Dec 1 16:46:45 linux-vl1l xinetd[3049]: Exiting...
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.conf] [line=26]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/chargen-udp [file=/etc/xinetd.d/chargen-udp] [line=14]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/cups-lpd [file=/etc/xinetd.d/cups-lpd] [line=15]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime] [line=11]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/daytime-udp [file=/etc/xinetd.d/daytime-udp] [line=14]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard] [line=15]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/discard-udp [file=/etc/xinetd.d/discard-udp] [line=14]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=15]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/echo-udp [file=/etc/xinetd.d/echo-udp] [line=14]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/netstat [file=/etc/xinetd.d/netstat] [line=15]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/pure-ftpd [file=/etc/xinetd.d/pure-ftpd] [line=16]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/servers [file=/etc/xinetd.d/servers] [line=21]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=14]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/systat [file=/etc/xinetd.d/systat] [line=14]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=17]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=15]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Reading included configuration file: /etc/xinetd.d/vnc [file=/etc/xinetd.d/vnc] [line=15]
Dec 1 16:46:45 linux-vl1l xinetd[3147]: xinetd Version 2.3.14 started with libwrap loadavg options compiled in.
Dec 1 16:46:45 linux-vl1l xinetd[3147]: Started working: 1 available service

With

"disable = yes"

xinetd does not start:

linux-vl1l:/home/mats # service xinetd restart
Shutting down xinetd: done
Starting INET services. (xinetd) failed

changing back to "disable = no"
linux-vl1l:/home/mats # service xinetd start
Starting INET services. (xinetd) done

To see if xinetd is running, use:
Put "disable=yes", stop xinetd and run pure-ftpd in debug mode from CLI to see if it spits any errors

In the attachment messages from /var/log/messages from a reboot followed by an ftp attempt. Of interest:

Dec 3 07:54:13 linux-vl1l xinetd[2352]: xinetd Version 2.3.14 started with libwrap loadavg options compiled in.
Dec 3 07:54:13 linux-vl1l xinetd[2352]: Started working: 1 available service

followed by:

Dec 3 07:54:14 linux-vl1l nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/autofs' exited with error status 1.

followed by:

Dec 3 07:54:16 linux-vl1l nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/nfs' exited with error status 2.
Dec 3 07:54:17 linux-vl1l kernel: eth0: no IPv6 routers present



The script

/etc/NetworkManager/dispatcher.d/nfs

that reports troubles:

#! /bin/sh
#
# nfs - start NFS in response to interface change
#
# Robert Love

RL=$(/sbin/runlevel); RL=${RL#* }
test -z "$RL" && RL=`sed -n 's=^id:\(.\):initdefault.*$=\1=p' /etc/inittab`

case "$2" in
up)
ls /etc/init.d/rc${RL}.d/S*nfs &>/dev/null || exit 2
/etc/init.d/nfs restart
;;
down)
# It is too late to stop NFS. Better to do nothing, in
# case we come back up
exit 0
;;
*)
exit 0
;;
esac

Attached Files

messages.txt (9.4 KB, 2 views)

and this is the first of the scripts with troubles:

"error status 1"

#! /bin/sh
#
# autofs dispatcher script for NetworkManager
#
# Matthias Koenig <mkoenig@suse.de>
#
case "$2" in
up)
/sbin/chkconfig --check autofs && /etc/init.d/autofs restart
;;
down)
/sbin/chkconfig --check autofs && /etc/init.d/autofs restart
;;
*)
exit 0
;;
esac

Why don't you do what I've asked you?
What you have posted has nothing to do with pure-ftpd. The logs and the scripts you've posted are related to the nfs/automounter services.
So, do what I've told you on post #12 and post here the results.

Regards