Subject: WHY?

From: "Robert Johnstone" <[email-masked]>
Date: Fri, 07 May 1999 08:55:54 -0400

I've installed the latest (vr17) as a successful login banner implies
  foo FTP server (Version wu-2.4.2-VR17(1) Fri Mar 26 10:39:01 PST 1999) ready.

  and it functions well pertaining to file transfers, logging to xferlog, errors to syslog, etc

  but why doesn't it read any of the banner messages  as before.  If all the config files are located in /usr/local/etc/  and the banner, 'too many' etc in /usr/local/etc/msgs, is there a command line switch to invoke these.   At the end of a session, all that comes up is  this:

221-Thank you for using the FTP service on foo

  Thanks   rj

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 7 May 1999 09:39:47 -0400 (EDT)

On Fri, 7 May 1999, Robert Johnstone wrote:

> but why doesn't it read any of the banner messages as before.  If all
> the config files are located in /usr/local/etc/ and the banner, 'too
> many' etc in /usr/local/etc/msgs, is there a command line switch to
> invoke these.  At the end of a session, all that comes up is this:

The rules for where messages are located haven't changed so I'm guessing
you've changed something along the way (like switched real users over to
be guests).

Here's the rules as I understand them.  All I can say is they pretty well
show how odd things can get after a decade of hodge-pudge development.

deny
----
<message_file> is system-root based; it is accessed before classification
of the user (when the chroot occurs).

limit
-----
<message_file> needs to be in each chroot-area for the classes being
limited.  Obviously it is accessed after classification of the user, so
the daemon will have already chroot'd.

banner
------
<path> is system-root based; it is accessed before classification of the
user.

message
-------
<path> needs to be in each chroot-area for the classes receiving the
message.  If no classes are specified, it needs to be EVERYWHERE.  I avoid
the problem by considering 'message' a per-user message and not a
broadcast to all users.

readme
------
<path> needs to be in each chroot-area for the classes receiving the
notification.  If no classes are specified, it needs to be EVERYWHERE.  I
avoid the problem by considering 'readme' a per-directory notification and
not a broadcast to all users across all directories.

alias
-----
<dir> is always relative to the chroot-area; rendering this feature
virtually useless for guest users.

cdpath
------
<dir> is always relative to the chroot-area; rendering this feature
virtually useless for guest users.

shutdown
--------
<path> needs to be in _every_ chroot'd area.  The <path> most people use
is in the system-root (/) and only works for real users.  Kent says he's
got a replacement for ftpshut at the resource center which handles putting
the <path> into each chroot'd area that you might find .. never tried it;
I consider ftpshut unusable.

virtual
-------
banner <path> is relative to root <path>.

path-filter
-----------
<mesg> needs to be in *EVERY* chroot-area.  I usually ignore that and
specify <mesg> as /dev/null or some file I know won't exist.

> 221-Thank you for using the FTP service on foo

If it just chopps off after this point, I'd look for system problems.  My
first guess would be a TCP problem where the system failes to send the
remaining buffered text when the socket is closed.  What system are you
using?  Go to the vendor's site and see if there's a more-current version
or patches for the version you're running.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195