Bug 55389

Summary: xinetd banner does not print with multiple ftpd
Product: [Retired] Red Hat Linux Reporter: dyhancoc
Component: xinetdAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: bbraun
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-12-04 17:51:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description dyhancoc 2001-10-30 18:08:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u)

Description of problem:
I use xinetd to run vsftpd.  I run vsftpd on 3 different ports, 21, 2021,
and 3021, with 3 different scripts in /etc/xinetd.d/ vsftpd, vsftpd-iu, and
vsftpd-peers each with their own function definition.  Each program calls a
different version of the vsftpd binary, specially compiled for its class
(bug is the same if you use the same binary).

If I just have 1 of the vsftpds enabled the banner or banner_success
command works fine but once I enable another one of the services it stops
working.
  
e.g.  vsftpd-iu is enabled for users at Indiana University and the banner
prints fine, I then enable the vsftpd-peers script and the banner stops
printing for IU and it's peers, the banners I'm using are 644.  I'm doing
this to use xinetd to make a pseudo class system like wu-ftpd has.

My work around has been to modify the ftpd source and use a one line banner
then call seperate binaries in each script.

Note: All connections initially come in to port 21 and get redirected with
IPCHAINS rules to the appropriate port.  Even if I connect directly to that
port the banner will not print.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start one ftpd (through xinetd) listening on any port printing a banner.
2. Connect to that ftpd, you'll see the banner being displayed
3. Start another ftpd that prints a different banner
4. Connect to that first ftpd, the banner is no longer displayed.
	

Actual Results:   Only 1 vsftpd, here's the connection...

[dyhancoc@chia dyhancoc]$ ftp chuck     
Connected to chuck.ucs.indiana.edu.
220-Member of IU-Unlimited 
220-Please report problems and concerns to uwsg
220 ready (Version wu-2.6.1(1): IU Class)
Name (chuck:dyhancoc): 

Now I enable the 2nd vsftpd...

[dyhancoc@chia dyhancoc]$ ftp chuck 
Connected to chuck.ucs.indiana.edu.
220 ready (Version wu-2.6.1(1): IU Class)
Name (chuck:dyhancoc): 

Expected Results:  The 2nd connection should look exactly the same as the
first.

Additional info:

Note the banner listed above says wu-2.6.1 but that's a lie it's actually
vsftpd-0.9.3.   It should not be related to the daemon that's running but I
guess it's possible.

Here's the vsftpd-iu script

service ftp-iu
{
        instances               = UNLIMITED
        socket_type             = stream
        banner                  = /usr/local/etc/ftp_iu_banner
        protocol                = tcp
        port                    = 2021
        wait                    = no
        user                    = root
        server                  = /usr/sbin/vsftpd-iu
        log_on_success          += USERID DURATION 
        log_on_failure          += HOST PID
        nice                    = 1
        disable                 = no
}

Here's the vsftpd-peers script

service ftp-peers
{
        instances     = 30 
        socket_type             = stream
        banner			= /usr/local/etc/ftp_peers_banner
	protocol                = tcp
        banner_fail             = /usr/local/etc/ftp_limit
        port                    = 3021
        wait                    = no
        user                    = root
        server                  = /usr/sbin/vsftpd-peers
        log_on_success          += DURATION USERID
        log_on_failure          += RECORD USERID
        nice                    = 5
        disable                 = no
}

Comment 1 Trond Eivind Glomsrxd 2001-11-21 00:02:56 UTC
It actually works for me, using wu-ftpd.

Comment 2 Trond Eivind Glomsrxd 2001-12-04 17:23:08 UTC
Can you give the xinetd rpm at http://people.redhat.com/teg/xinetd/ and see if
you still have a problem?

Comment 3 dyhancoc 2001-12-04 17:51:46 UTC
I upgraded to the binary rpm you suggested and it resolves the problem.  Thanks.