From owner-wu-ftpd@wugate.wustl.edu Tue Dec 1 00:33:50 1998

From [email protected] Tue Dec 1 00:33:50 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id AAA09579;
Tue, 1 Dec 1998 00:33:48 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id AAA29544;
Tue, 1 Dec 1998 00:25:55 -0600 (CST)
Received: from dagobert.piro.net (dagobert.piro.net [194.64.31.2])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id AAA29575
for <[email protected]>; Tue, 1 Dec 1998 00:20:36 -0600 (CST)
Received: from ITS.DE (gwmail.its.de [194.195.99.74])
by dagobert.piro.net (8.8.8/8.8.8/PN-980513) with SMTP id HAA18354
for <[email protected]>; Tue, 1 Dec 1998 07:20:31 +0100 (MET)
Received: from ITS#u#Reisen-Message_Server by ITS.DE
with Novell_GroupWise; Tue, 01 Dec 1998 07:20:01 +0100
Message-Id: <[email protected]>
Date: Tue, 01 Dec 1998 07:19:29 +0100
Reply-To: [email protected]
Sender: [email protected]
From: "Peter Bechara" <[email protected]>
To: [email protected]
Subject: unsuscribe
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Mailer: Novell GroupWise 5.2
X-MIME-Autoconverted: from quoted-printable to 8bit by wugate.wustl.edu id AAA23160
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

unsuscribe

From [email protected] Tue Dec 1 08:19:22 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id IAA13493;
Tue, 1 Dec 1998 08:19:21 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id IAA01172;
Tue, 1 Dec 1998 08:14:31 -0600 (CST)
Received: from gis-mail.gis-online.de (gis.gis-online.de [195.88.182.250])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id IAA16160
for <[email protected]>; Tue, 1 Dec 1998 08:06:47 -0600 (CST)
Received: from produktion.gis-online.de (dfsbvr1x1 [10.224.10.11])
by gis-mail.gis-online.de (8.8.5/8.8.5) with ESMTP id OAA10289
for <[email protected]>; Tue, 1 Dec 1998 14:51:31 +0100 (MET)
Received: from produktion.gis-online.de ([5.10.6.142])
by produktion.gis-online.de (8.8.5/8.8.5) with ESMTP id PAA13499
for <[email protected]>; Tue, 1 Dec 1998 15:05:52 +0100 (MET)
Message-Id: <[email protected]>
Date: Tue, 01 Dec 1998 15:06:07 +0100
Reply-To: [email protected]
Sender: [email protected]
From: Robin Breyl <[email protected]>
To: [email protected]
Subject: Download progress bar in Netscape
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [email protected]
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

Hello,

I'm using Wu-ftp 2.4.2 (Beta17) on a Solrais 2.5.1 machine without
any problems so far.

But recently I got a call, that users who are downloading files
with Netscape Navigator from my site don't get a download-progress
bar, as they do get from many other sites.

I figured, that netscape might do a "ls -l" or a "dir" to get
the actual filesize and checked both comands. Both work fine,
ls is static linked and I cann't imagine any problem here.

Does anyone know what causes Netscape Navigator to the get the
filesize as "unknown"?

Robin
--
_________________________________________________________________
/ \
| Robin Breyl Geno RZ |
| ------------- |
| Saonestrasse 3a |
| 60528 Frankfurt am Main |
| |
| E-Mail (Office): [email protected] |
| E-Mail (Home): [email protected] |
| |
| Tel.: +49 69 / 75690-369 Fax.: +49 69 / 75690-925 |
\_________________________________________________________________/

From [email protected] Tue Dec 1 10:38:09 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id KAA15197;
Tue, 1 Dec 1998 10:38:08 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id KAA18856;
Tue, 1 Dec 1998 10:33:31 -0600 (CST)
Received: from mail.vr.net ([email protected] [205.133.13.8])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id KAA17543
for <[email protected]>; Tue, 1 Dec 1998 10:28:24 -0600 (CST)
Received: (from lundberg@localhost)
by mail.vr.net (8.9.1a/8.9.1) id LAA22834
for [email protected]; Tue, 1 Dec 1998 11:28:17 -0500
Message-Id: <[email protected]>
Date: Tue, 1 Dec 1998 12:00:00 -0500 (EST)
Reply-To: [email protected]
Sender: [email protected]
From: Gregory A Lundberg <[email protected]>
To: WU-FTPD Discussion List <[email protected]>
Subject: [VR11] More enhancements and bug fixes for beta-18
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

The VR11 patch set for WU-FTPD 2.4.2 (beta-18) is now available.

This set includes additional features requested over the years by the user
community and includes a number of bug fixes for both the base (beta-18)
release and earlier VR patch sets.

These are available as both patches and pre-patched tarballs at my ftp
site:

ftp://ftp.vr.net/pub/wu-ftpd/

If you take just the patch files, please remember: they are cumulative.
you cannot apply fixes from one set without earlier sets already having
been applied. The first set for BETA-18 is VR3; VR1 and VR2 were for
BETA-17 only.

Several pre-compiled binaries for VR11 are also available. These include:

Sun/SunOS
---------
sunos41x-ftpbin.tar.gz (FTP support executables, ls etc.)
wu-ftpd-2.4.2-beta-18-vr11-SunOS-4.1.3-U1.tar.gz

Sun/Solaris
-----------
FTP242b18.wu-ftpd.2.4.2-beta18-VR11.SPARC.ULTRASparc.2.5.1.2.5.pkg.tar.Z
FTP242b18.wu-ftpd.2.4.2-beta18-VR11.SPARC.ULTRASparc.2.5.1.2.5.pkg.tar.gz
wu-ftpd-2.4.2-beta-18-vr11-Solaris-2.6.tar.gz

Sun/NetBSD
----------
wu-ftpd-2.4.2-beta-18-vr11-NetBSD-1.3I.tar.gz

Sun/Linux
---------
wu-ftpd-2.4.2-beta-18-vr11-linux-sparc.tar.gz

SGI/IRIX
--------
irix62-ftpbin.tar.gz (FTP support executables, ls etc.)
wu-ftpd-2.4.2-beta-18-vr11-IRIX-6.2.tar.gz

IBM/AIX
-------
wu-ftpd-2.4.2-beta-18-vr11-AIX.3.2.5.tar.gz

DEC/Unix
--------
wu-ftpd-2.4.2-beta-18-vr11-OSF1-3.2-C2.tar.gz

Intel/BSDI
----------
wu-ftpd-2.4.2-beta-18-vr11-BSDI-2.1.tar.gz
wu-ftpd-2.4.2-beta-18-vr11-BSDI-3.1.tar.gz

Intel/Linux
-----------
ftp.bin.linux.i386.tar.gz (FTP support executables, ls etc.)
wu-ftpd-2.4.2-beta-18-vr11.linux.i386.tar.gz

Thanks to all those who helped with debugging and built the pre-compiled
binaries.

This is a list of fixes to BETA 18 with VR10 applied from [email protected]
---------------------------------------------------------------------------
Add -r option to chroot the daemon during startup. From a discussion on
the mailing list with <[email protected]> on 12 Nov 1998.

Linux library includes no longer #define MAXMNTENT so if it's not there
#define it in extensions.c until someone has the time to fix this right.
Probably RedHat 5.1-ism.

Linux libraries now define some paths already in src/pathnames.h so we
need to #include <paths.h> first. Did this in config/config.lnx. Probably
RedHat 5.1-ism.

Added syslog message if started as a standalone daemon and there is no
ftpaccess file being used.

Add an option to completely disable PASV mode and/or PORT mode. Another
old request I found again. Don't remember who first requested it. This
was originally rants trying to block web clients. I've put it in since it
seems blocking PORT is a good idea and blocking PASV is orthagonal to that
feature.

initsetproctitle was once again causing signal 11 crashes. Moved the call
further up yet again and they're not happening. Discovered in testing. I
believe there have been some reports of this but could never get enough
info to track it down.

A bad extern in ftpcmd.y caused garbage to be logged for the remoteident.
Discovered in testing. I believe I had a vague report of this.

[email protected] noted on 20 Nov 1998 the byte count for ASCII mode
file reception is off by a few characters. This bug has been there for a
very long time.

[email protected] suggested on 1 Nov 1998 a change to the
lslong and lsshort ftpaccess clauses to support more complex command lines
as well as the addition of lsplain to modify the default 'ls' behaviour.

[email protected] reported problems with the new realpath.c on
SunOS. He sent a patch on 23 Nov 1998 which fixes the problem.
Basically, the getcwd() function on SunOS is too buggy to use so we had to
switch to getwd instead. SunOS has joined AIX as systems which do not
provide the runtime support needed to avoid all buffer overruns in
realpath(). *sigh*

[email protected] on 25 Nov 1998 reported a problem with CWD when no
parameter is given and the user is anonymous or guest. The command should
work but returns an error instead; the error reveals the underlying file
system. CWD should work like CWD ~.

--

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

From [email protected] Tue Dec 1 12:14:58 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id MAA16283;
Tue, 1 Dec 1998 12:14:58 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id MAA12956;
Tue, 1 Dec 1998 12:10:39 -0600 (CST)
Received: from mail.vr.net ([email protected] [205.133.13.8])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id MAA24896
for <[email protected]>; Tue, 1 Dec 1998 12:07:54 -0600 (CST)
Received: from localhost (lundberg@localhost)
by mail.vr.net (8.9.1a/8.9.1) with ESMTP id NAA23851;
Tue, 1 Dec 1998 13:07:51 -0500
Message-Id: <[email protected]>
Date: Tue, 1 Dec 1998 13:07:50 -0500 (EST)
Reply-To: [email protected]
Sender: [email protected]
From: Gregory A Lundberg <[email protected]>
To: WU-FTPD Discussion List <[email protected]>
Cc: "Denis N. Antonioli" <[email protected]>
Subject: NFS fix for realpath in VR11
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

I have updated this patch for VR11 and commited it to my CVS tree. It came
in too late to make it into VR11, so it will appear in VR12 (due out
January 1, 1999).

This patch is available at:

ftp://ftp.vr.net/pub/wu-ftpd/unsupported/vr11.1.patch

You only need it if you NFS mount parts of your FTP area.

---- Original Message ----

>From [email protected] Tue Dec 1 11:54:05 1998
Date: Sun, 29 Nov 1998 15:23:52 +0100 (MET)
From: Denis N. Antonioli <[email protected]>
To: WU-FTPD Discussion List <[email protected]>
Subject: Re: realpath in 2.4.2-beta-18-vr10

On Fri, 27 Nov 1998, Gregory A Lundberg wrote:

> On Fri, 27 Nov 1998, Denis N. Antonioli wrote:
>
> > Maybe ftpd could seteuid(0) only if a normal access failed?
>
> Sounds fine. The seteuid(0) stuff is there mainly to support people
> who've revoked read access on the common directory containing the users'
> home directories as in:
>
> d--x--x--x root root /home
> drwx------ greg greg /home/greg
>
> Where 'greg' is a guest user chroot'd to /home/./greg and we want him to
> be able to cd, pwd, etc., but not see the other users in /home

Ok. Here then is a patch for realpath.c.

Happy programming,
Denis N. Antonioli

---- Updated patch ----

Index: realpath.c
===================================================================
RCS file: /cvsroot/wu-ftpd/src/realpath.c,v
retrieving revision 1.1.1.1.2.6.2.6
retrieving revision 1.1.1.1.2.6.2.7
diff -c -w -r1.1.1.1.2.6.2.6 -r1.1.1.1.2.6.2.7
*** realpath.c 1998/11/23 17:42:37 1.1.1.1.2.6.2.6
--- realpath.c 1998/12/01 17:30:50 1.1.1.1.2.6.2.7
***************
*** 108,114 ****
int fd, n, rootd, serrno;
char *p, *q, wbuf[MAXPATHLEN];
int symlinks = 0;
- uid_t userid;
int resultcode;
#ifdef HAS_NO_FCHDIR
/* AIX Has no fchdir() so we hope the getcwd() call doesn't overrun the buffer! */
--- 108,113 ----
***************
*** 117,123 ****
#endif

/* Save the starting point. */
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAS_NO_FCHDIR
--- 116,128 ----
#endif

/* Save the starting point. */
! #ifdef HAS_NO_FCHDIR
! pcwd = getcwd(cwd, sizeof (cwd));
! #else
! fd = open(".", O_RDONLY);
! #endif
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAS_NO_FCHDIR
***************
*** 131,141 ****
#endif
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
#ifdef HAS_NO_FCHDIR
! if (pcwd == NULL) {
#else
! if (fd < 0) {
#endif
(void)strcpy(resolved, ".");
return (NULL);
}
--- 136,148 ----
#endif
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
#ifdef HAS_NO_FCHDIR
! if (pcwd == NULL)
#else
! if (fd < 0)
#endif
+ {
(void)strcpy(resolved, ".");
return (NULL);
}
***************
*** 163,174 ****
q[1] = '\0';
q = resolved;
}
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
resultcode = chdir(q);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
if (resultcode < 0)
goto err1;
} else
--- 170,184 ----
q[1] = '\0';
q = resolved;
}
! resultcode = chdir(q);
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
resultcode = chdir(q);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
if (resultcode < 0)
goto err1;
} else
***************
*** 176,211 ****

/* Deal with the last component. */
if (*p != '\0') {
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
resultcode = lstat(p, &sb);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
if (resultcode == 0) {
if (S_ISLNK(sb.st_mode)) {
if (++symlinks > MAXSYMLINKS) {
errno = ELOOP;
goto err1;
}
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
n = readlink(p, resolved, MAXPATHLEN);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
if (n < 0)
goto err1;
resolved[n] = '\0';
goto loop;
}
if (S_ISDIR(sb.st_mode)) {
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
resultcode = chdir(p);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
if (resultcode < 0)
goto err1;
p = "";
--- 186,230 ----

/* Deal with the last component. */
if (*p != '\0') {
! resultcode = lstat(p, &sb);
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
resultcode = lstat(p, &sb);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
if (resultcode == 0) {
if (S_ISLNK(sb.st_mode)) {
if (++symlinks > MAXSYMLINKS) {
errno = ELOOP;
goto err1;
}
! n = readlink(p, resolved, MAXPATHLEN);
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
n = readlink(p, resolved, MAXPATHLEN);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
if (n < 0)
goto err1;
resolved[n] = '\0';
goto loop;
}
if (S_ISDIR(sb.st_mode)) {
! resultcode = chdir(p);
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
resultcode = chdir(p);
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
if (resultcode < 0)
goto err1;
p = "";
***************
*** 218,224 ****
* the current directory.
*/
(void)strcpy(wbuf, p);
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAVE_GETCWD
--- 237,253 ----
* the current directory.
*/
(void)strcpy(wbuf, p);
! #ifdef HAVE_GETCWD
! resultcode = getcwd(resolved, MAXPATHLEN) == NULL ? 0 : 1;
! #else
! resultcode = getwd(resolved) == NULL ? 0 : 1;
! if (resolved[MAXPATHLEN -1 ] != '\0') {
! resultcode = 0;
! errno = ERANGE;
! }
! #endif
! if (EACCES == errno) {
! udt_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAVE_GETCWD
***************
*** 232,237 ****
--- 261,267 ----
#endif
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
if (resultcode == 0)
goto err1;

***************
*** 255,261 ****
}

/* Go back to where we came from. */
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAS_NO_FCHDIR
--- 285,297 ----
}

/* Go back to where we came from. */
! #ifdef HAS_NO_FCHDIR
! resultcode = chdir(cwd);
! #else
! resultcode = fchdir(fd);
! #endif
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAS_NO_FCHDIR
***************
*** 265,270 ****
--- 301,307 ----
#endif
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
if (resultcode < 0) {
serrno = errno;
goto err2;
***************
*** 277,283 ****
return (resolved);

err1: serrno = errno;
! userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAS_NO_FCHDIR
--- 314,326 ----
return (resolved);

err1: serrno = errno;
! #ifdef HAS_NO_FCHDIR
! (void)chdir(cwd);
! #else
! (void)fchdir(fd);
! #endif
! if (EACCES == errno) {
! uid_t userid = geteuid();
delay_signaling(); /* we can't allow any signals while euid==0: kinch */
seteuid(0);
#ifdef HAS_NO_FCHDIR
***************
*** 287,292 ****
--- 330,336 ----
#endif
seteuid(userid);
enable_signaling(); /* we can allow signals once again: kinch */
+ }
#ifdef HAS_NO_FCHDIR
err2: errno = serrno;
#else

--

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

From [email protected] Tue Dec 1 17:50:51 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id RAA20036;
Tue, 1 Dec 1998 17:50:50 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id RAA21866;
Tue, 1 Dec 1998 17:45:14 -0600 (CST)
Received: from expresscopy.com ([email protected] [206.163.205.68])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id RAA30397
for <[email protected]>; Tue, 1 Dec 1998 17:43:37 -0600 (CST)
Received: from admin.expresscopy.com (admin.expresscopy.com [206.163.205.70])
by expresscopy.com (8.8.8/8.8.8) with ESMTP id PAA12865
for <[email protected]>; Tue, 1 Dec 1998 15:41:36 -0800 (PST)
(envelope-from [email protected])
Message-Id: <[email protected]>
Date: Tue, 1 Dec 1998 15:44:25 -0800 (PST)
Reply-To: [email protected]
Sender: [email protected]
From: Dan <[email protected]>
To: [email protected]
Subject: Not overwrite, but rename...
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

Currently, my company is using the default FreeBSD ftpd to
receive printable postscript files over the internet for color
copying. I like the flexibility and control that wu-ftpd
offers, as well as it's logging facilities, and therefore
I would like to switch.

By default, the FreeBSD ftpd does not overwrite an existing
file in the incoming dir, but instead appends a .1 to the
end of the file, and allows the user to upload without
overwriting the older file.

Because of the skill level of our customers, this is a requirement
for us. Is this possible with wu-ftpd?

Thanks,

Dan

-- Dan Herrera ([email protected])
------------------------------------

From [email protected] Wed Dec 2 09:07:49 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id JAA27790;
Wed, 2 Dec 1998 09:07:48 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id JAA14325;
Wed, 2 Dec 1998 09:01:36 -0600 (CST)
Received: from mail.vr.net ([email protected] [205.133.13.8])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id IAA25715
for <[email protected]>; Wed, 2 Dec 1998 08:57:05 -0600 (CST)
Received: from localhost (lundberg@localhost)
by mail.vr.net (8.9.1a/8.9.1) with ESMTP id JAA30442;
Wed, 2 Dec 1998 09:56:59 -0500
Message-Id: <[email protected]>
Date: Wed, 2 Dec 1998 09:56:59 -0500 (EST)
Reply-To: [email protected]
Sender: [email protected]
From: Gregory A Lundberg <[email protected]>
To: Dan <[email protected]>
Cc: [email protected]
Subject: Re: Not overwrite, but rename...
In-Reply-To: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Tue, 1 Dec 1998, Dan wrote:

> Currently, my company is using the default FreeBSD ftpd to receive
> printable postscript files over the internet for color copying. I
> like the flexibility and control that wu-ftpd offers, as well as it's
> logging facilities, and therefore I would like to switch.
>
> By default, the FreeBSD ftpd does not overwrite an existing file in
> the incoming dir, but instead appends a .1 to the end of the file, and
> allows the user to upload without overwriting the older file.
>
> Because of the skill level of our customers, this is a requirement for
> us. Is this possible with wu-ftpd?

No, but it's an interesting idea. I've put it in my pile of such things
for the VR extensions. Does anyone else have any comments or suggestions?

--

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

From [email protected] Wed Dec 2 11:39:42 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id LAA29731;
Wed, 2 Dec 1998 11:39:40 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id LAA15052;
Wed, 2 Dec 1998 11:33:51 -0600 (CST)
Received: from cyhpr142.ug.eds.com (cyhpr142.ug.eds.com [134.244.99.93])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id LAA17976
for <[email protected]>; Wed, 2 Dec 1998 11:30:06 -0600 (CST)
Received: (from jung@localhost) by cyhpr142.ug.eds.com (8.7.1/8.7.1) id JAA21315 for [email protected]; Wed, 2 Dec 1998 09:32:58 -0800 (PST)
Message-Id: <[email protected]>
Date: Wed, 02 Dec 1998 9:32:57 PST
Reply-To: [email protected]
Sender: [email protected]
From: John Jung <[email protected]>
To: [email protected]
Subject: Directory-Level Password Protection?
X-Mailer: Elm [revision: 212.2]
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

Hi All,

We've got WU-FTPD 2.4 (yeah, I know it's old, but management is skittish on
the "beta" tag for the other releases) running fine here. However, management
now has a new requirement and wants to know if it can be done. I don't think
it can, but I want to double check with everybody else:

Can WU-FTPD handle directory-level access restrictions?

Management is looking for something similar to ".htaccess" for Apache, but
for WU-FTPD. I don't think it's do-able because I think WU-FTPD only does
authentication once, and that's at login.

Am I wrong? Is it possible to do directory-level access restrictions? If
so, how would this be done?

Thanks for your help.

John

+-------------------------------------+-------------------------------------+
| John Jung ([email protected]) | Unigraphics Solutions |
| Global Technical Access Center | 10824 Hope Street, 1S-241 |
| Operating Systems Group | Cypress, California 90630 |
+---------------------------(800) 955-0000x3-586----------------------------+

From [email protected] Wed Dec 2 12:04:54 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id MAA00122;
Wed, 2 Dec 1998 12:04:53 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id LAA03719;
Wed, 2 Dec 1998 11:59:43 -0600 (CST)
Received: from tower.ti.com (tower.ti.com [192.94.94.5])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id LAA23478
for <[email protected]>; Wed, 2 Dec 1998 11:59:15 -0600 (CST)
Received: from dadd.ti.com ([172.24.154.51]) by tower.ti.com (8.8.8) with ESMTP id LAA10290; Wed, 2 Dec 1998 11:58:08 -0600 (CST)
Received: from pavis.asic.sc.ti.com by dadd.ti.com (8.8.4/)
id LAA11995; Wed, 2 Dec 1998 11:58:07 -0600 (CST)
Received: by pavis.asic.sc.ti.com id <[email protected]>; Wed, 2 Dec 1998 11:58:06 -0600
Message-Id: <[email protected]>
Date: Wed, 2 Dec 98 11:58:06 CST
Reply-To: [email protected] (Bob Luckin)
Sender: [email protected]
From: Bob Luckin <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Directory-Level Password Protection?
In-Reply-To: <[email protected]>; from "John Jung" at Dec 02, 98 9:32 am
X-Mimi-Options: HEADERS TI2
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

John,

> We've got WU-FTPD 2.4 (yeah, I know it's old, but management is skittish on
> the "beta" tag for the other releases) running fine here. However, management
> now has a new requirement and wants to know if it can be done. I don't think
> it can, but I want to double check with everybody else:
>
> Can WU-FTPD handle directory-level access restrictions?
>
> Management is looking for something similar to ".htaccess" for Apache, but
> for WU-FTPD. I don't think it's do-able because I think WU-FTPD only does
> authentication once, and that's at login.
>
> Am I wrong? Is it possible to do directory-level access restrictions? If
> so, how would this be done?

I'm not aware of a such a feature. However, you may be able to use UNIX
group permissions to restrict access to specific directories via the
SITE GROUP and SITE GPASS commands. (You'd have to issue the relevant
password to the folks you want to have access to the protected directory.)
For more detail, see the "private yes" command in the ftpaccess man page.

I use this method and it seems to work fine. Of course, it may be that
this solution is not suitable for your particular problem...

Cheers, Bob

From [email protected] Wed Dec 2 12:46:28 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id MAA00705;
Wed, 2 Dec 1998 12:46:27 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id MAA21992;
Wed, 2 Dec 1998 12:38:32 -0600 (CST)
Received: from quartz.nbnet.nb.ca (quartz.nbnet.nb.ca [198.164.200.18])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id MAA09521
for <[email protected]>; Wed, 2 Dec 1998 12:34:14 -0600 (CST)
Received: from asgtechnologies.com ([198.164.220.73]) by quartz.nbnet.nb.ca
(Post.Office MTA v3.1.2 release (PO203-101c)
ID# 607-54382U75000L75000S0V35) with ESMTP id AAA10013
for <[email protected]>; Wed, 2 Dec 1998 14:34:13 -0400
Message-Id: <[email protected]>
Date: Wed, 02 Dec 1998 14:42:29 -0400
Reply-To: [email protected]
Sender: [email protected]
From: Cameron Lemon <[email protected]>
To: [email protected]
Subject: Adding FTP module to Apache HTTPD, or reverse engineer Wu-FTPD
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="------------8254B1010305B5991EC1310B"
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

This is a multi-part message in MIME format.
--------------8254B1010305B5991EC1310B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have submitted an idea to the Apache development group wondering if
they would be
able to add an FTPD module to the Apache HTTPD. As Apache provides the
framework,
adding an FTP module that could utilise access control, connection
throttling,
daemon routines, stability and such, it would be great if a module
where available.
Also, Apache could branch off and reuse alot of the Apache HTTPD code,
and insert
the FTPD code for one kick-ass FTP Daemon.

Any thoughts on this?

Cameron Lemon

> Bob Luckin wrote:
>
> > John,
> >
> > > We've got WU-FTPD 2.4 (yeah, I know it's old, but management is
skittish on
> > > the "beta" tag for the other releases) running fine here.
However, management
> > > now has a new requirement and wants to know if it can be done. I
don't think
> > > it can, but I want to double check with everybody else:
> > >
> > > Can WU-FTPD handle directory-level access restrictions?
> > >
> > > Management is looking for something similar to ".htaccess" for
Apache, but
> > > for WU-FTPD. I don't think it's do-able because I think WU-FTPD
only does
> > > authentication once, and that's at login.
> > >
> > > Am I wrong? Is it possible to do directory-level access
restrictions? If
> > > so, how would this be done?
> >
> > I'm not aware of a such a feature. However, you may be able to use
UNIX
> > group permissions to restrict access to specific directories via the

> > SITE GROUP and SITE GPASS commands. (You'd have to issue the
relevant
> > password to the folks you want to have access to the protected
directory.)
> > For more detail, see the "private yes" command in the ftpaccess man
page.
> >
> > I use this method and it seems to work fine. Of course, it may be
that
> > this solution is not suitable for your particular problem...
> >
> > Cheers, Bob

--------------8254B1010305B5991EC1310B
Content-Type: text/x-vcard; charset=us-ascii;
name="Cameron.Lemon.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cameron Lemon
Content-Disposition: attachment;
filename="Cameron.Lemon.vcf"

begin:vcard
n:Lemon;Cameron
tel;fax:506.460.5411
tel;work:506.460.5400
x-mozilla-html:FALSE
url:www.asgtechnologies.com
org:Atlantic Systems Group;Professional Services
version:2.1
email;internet:[email protected]
title:Systems & Network Architect
adr;quoted-printable:;;Garland Court=0D=0AIncuTech Centre;Fredericton;New Brunswick;E3B 6C2;Canada
fn:Cameron Lemon
end:vcard

--------------8254B1010305B5991EC1310B--

From [email protected] Wed Dec 2 14:26:35 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id OAA01955;
Wed, 2 Dec 1998 14:26:33 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id OAA02426;
Wed, 2 Dec 1998 14:21:52 -0600 (CST)
Received: from mail.vr.net ([email protected] [205.133.13.8])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id OAA05060
for <[email protected]>; Wed, 2 Dec 1998 14:19:40 -0600 (CST)
Received: from localhost (lundberg@localhost)
by mail.vr.net (8.9.1a/8.9.1) with ESMTP id PAA02268;
Wed, 2 Dec 1998 15:19:22 -0500
Message-Id: <[email protected]>
Date: Wed, 2 Dec 1998 15:19:21 -0500 (EST)
Reply-To: [email protected]
Sender: [email protected]
From: Gregory A Lundberg <[email protected]>
To: Cameron Lemon <[email protected]>
Cc: [email protected]
Subject: Re: Adding FTP module to Apache HTTPD, or reverse engineer Wu-FTPD
In-Reply-To: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Wed, 2 Dec 1998, Cameron Lemon wrote:

> I have submitted an idea to the Apache development group wondering if
> they would be able to add an FTPD module to the Apache HTTPD. As
> Apache provides the framework, adding an FTP module that could utilise
> access control, connection throttling, daemon routines, stability and
> such, it would be great if a module where available. Also, Apache
> could branch off and reuse alot of the Apache HTTPD code, and insert
> the FTPD code for one kick-ass FTP Daemon.

I've heard from some of the Apache folk in the past, and they've asked
along the same lines, so the idea isn't new. In fact, I've thought about
it quite often over the past two years or so.

As I read your message, I see 'they would be able to add' .. I think the
answer to that is probably going to be: You write it, and submit it to the
module registry, and they'll be happy. I seriously doubt they'll write it
for you.

Personally, merging FTP and HTTP into a single daemon seems like feature
bloat. Sure there's a lot of similarity, but it would be better to grab
what works from the Apache source kit and dump the rubbish (from FTP's
point of view). Really, do you need content negotiation for FTP? I'm
sure there's a lot of other features of Apache which have nothing to do
with FTP but content negotiation is what they're talking about today, so
it's in my mind.

As for access control, the new FTP specifications will make it imperitive
the daemon upgrade the view of the file system. Along with that will come
access control. From what I've seen, the Apache model will not lend
itself to the full virtual file system envisioned by the new FTP so the
entire file access and file access control system in Apache is probably a
write-off.

If you mean user-level access control, the FTP protocol does not lend
itself to much more than a simple login, do whatever, logout model. While
some daemons allow multiple logins in a single session, with wuftpd it's
not possible since upon login the daemon chroot's and the authentication
subsystem is no longer fully available. This is one of the most
significant strengths to wu-ftpd and I'd be loath to see it go away.

What we're left with from Apache is a base of code which accepts and
manages connections, spawning and managing processes (threads, maybe
someday) to serve those connections, and a few support functions.

All in all, I'd estimate that less than 20 percent of the Apache core code
would survive. At that rate, it's easier to lump Apache in with Bind and
Sendmail .. it's a good place from which to yank specific working
functions, but it's not a good place to leap off from for a new project.

Alright? I've got my flame-retardant suit on ...

--

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

From [email protected] Wed Dec 2 16:03:25 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id QAA03171;
Wed, 2 Dec 1998 16:03:24 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id PAA03170;
Wed, 2 Dec 1998 15:58:53 -0600 (CST)
Received: from quartz.nbnet.nb.ca (quartz.nbnet.nb.ca [198.164.200.18])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id PAA07707
for <[email protected]>; Wed, 2 Dec 1998 15:58:21 -0600 (CST)
Received: from asgtechnologies.com ([198.164.220.73]) by quartz.nbnet.nb.ca
(Post.Office MTA v3.1.2 release (PO203-101c)
ID# 607-54382U75000L75000S0V35) with ESMTP id AAA26861
for <[email protected]>; Wed, 2 Dec 1998 17:58:18 -0400
Message-Id: <[email protected]>
Date: Wed, 02 Dec 1998 18:06:35 -0400
Reply-To: [email protected]
Sender: [email protected]
From: Cameron Lemon <[email protected]>
To: [email protected]
Subject: Re: Adding FTP module to Apache HTTPD, or reverse engineer Wu-FTPD
References: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="------------7914510C6EEF13EA225B9D0C"
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

This is a multi-part message in MIME format.
--------------7914510C6EEF13EA225B9D0C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gregory A Lundberg wrote:

> On Wed, 2 Dec 1998, Cameron Lemon wrote:
>
> > I have submitted an idea to the Apache development group wondering if
> > they would be able to add an FTPD module to the Apache HTTPD. As
> > Apache provides the framework, adding an FTP module that could utilise
> > access control, connection throttling, daemon routines, stability and
> > such, it would be great if a module where available. Also, Apache
> > could branch off and reuse alot of the Apache HTTPD code, and insert
> > the FTPD code for one kick-ass FTP Daemon.
>
> I've heard from some of the Apache folk in the past, and they've asked
> along the same lines, so the idea isn't new. In fact, I've thought about
> it quite often over the past two years or so.

There are very few new ideas these days. Somebody usually beats you to it
whether you know it or not.

>
>
> As I read your message, I see 'they would be able to add' .. I think the
> answer to that is probably going to be: You write it, and submit it to the
> module registry, and they'll be happy. I seriously doubt they'll write it
> for you.

Should have caught "they would be able to add" before I clicked on 'send'.

> Personally, merging FTP and HTTP into a single daemon seems like feature
> bloat. Sure there's a lot of similarity, but it would be better to grab
> what works from the Apache source kit and dump the rubbish (from FTP's
> point of view). Really, do you need content negotiation for FTP? I'm
> sure there's a lot of other features of Apache which have nothing to do
> with FTP but content negotiation is what they're talking about today, so
> it's in my mind.

Not necessarily enclose both daemons within the same daemon, but base FTPD
upon the model of Apache HTTPD.

>
> As for access control, the new FTP specifications will make it imperitive
> the daemon upgrade the view of the file system. Along with that will come
> access control. From what I've seen, the Apache model will not lend
> itself to the full virtual file system envisioned by the new FTP so the
> entire file access and file access control system in Apache is probably a
> write-off.

Oh.

>
>
> If you mean user-level access control, the FTP protocol does not lend
> itself to much more than a simple login, do whatever, logout model. While
> some daemons allow multiple logins in a single session, with wuftpd it's
> not possible since upon login the daemon chroot's and the authentication
> subsystem is no longer fully available. This is one of the most
> significant strengths to wu-ftpd and I'd be loath to see it go away.

I agree.

>
>
> What we're left with from Apache is a base of code which accepts and
> manages connections, spawning and managing processes (threads, maybe
> someday) to serve those connections, and a few support functions.
>
> All in all, I'd estimate that less than 20 percent of the Apache core code
> would survive. At that rate, it's easier to lump Apache in with Bind and
> Sendmail .. it's a good place from which to yank specific working
> functions, but it's not a good place to leap off from for a new project.
>
> Alright? I've got my flame-retardant suit on ...

You won't need your suit for this one as there are more than enough flammers
giving hell to anyone that'll listen, plus you didn't hurt my feelings by
airing your concerns in a logical fashion. The idea utilising some of the
Apache code/functionality was just a brain-fart myself and a collegue had
while chowing down at a local Italian restaurant, and was far from
investigated thoroughly. Maybe the garlic affected our power of reasoning.
;-)

<brain-fart close>

Cameron Lemon

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

--------------7914510C6EEF13EA225B9D0C
Content-Type: text/x-vcard; charset=us-ascii;
name="Cameron.Lemon.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Cameron Lemon
Content-Disposition: attachment;
filename="Cameron.Lemon.vcf"

begin:vcard
n:Lemon;Cameron
tel;fax:506.460.5411
tel;work:506.460.5400
x-mozilla-html:FALSE
url:www.asgtechnologies.com
org:Atlantic Systems Group;Professional Services
version:2.1
email;internet:[email protected]
title:Systems & Network Architect
adr;quoted-printable:;;Garland Court=0D=0AIncuTech Centre;Fredericton;New Brunswick;E3B 6C2;Canada
fn:Cameron Lemon
end:vcard

--------------7914510C6EEF13EA225B9D0C--

From [email protected] Wed Dec 2 16:35:35 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id QAA03538;
Wed, 2 Dec 1998 16:35:34 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id QAA14802;
Wed, 2 Dec 1998 16:31:02 -0600 (CST)
Received: from mail.vr.net ([email protected] [205.133.13.8])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id QAA28180
for <[email protected]>; Wed, 2 Dec 1998 16:30:01 -0600 (CST)
Received: from localhost (lundberg@localhost)
by mail.vr.net (8.9.1a/8.9.1) with ESMTP id RAA01335;
Wed, 2 Dec 1998 17:29:54 -0500
Message-Id: <[email protected]>
Date: Wed, 2 Dec 1998 17:29:54 -0500 (EST)
Reply-To: [email protected]
Sender: [email protected]
From: Gregory A Lundberg <[email protected]>
To: Cameron Lemon <[email protected]>
Cc: [email protected]
Subject: Re: Adding FTP module to Apache HTTPD, or reverse engineer Wu-FTPD
In-Reply-To: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Wed, 2 Dec 1998, Cameron Lemon wrote:

> The idea utilising some of the Apache code/functionality was just a
> brain-fart myself and a collegue had while chowing down at a local
> Italian restaurant, and was far from investigated thoroughly. Maybe
> the garlic affected our power of reasoning. ;-)

Garlic? For me it's usually the .. er .. 'oregano' I smo .. um ..
consume when I get a brilliant flash like that.

Seriously .. while I personally am opposed to the idea of merging WU-FTPD
and Apache it's not because I've been working on the code or have any love
for the code. Let's face it, the code for both sucks but the code for
Wu-FTPD sucks far harder. I work with it because it's there and I'm not
(yet) inclined to toss it all.

I guess my major objection is _this_ is wu-ftpd. Warts and all. It may
not be pretty but it's what we all know. It does one job and does it well
so, except for those few of us who actually _like_ to tinker, it's all
that's needed.

I remember reading (somewhere, don't remember where) on the Information
Superhighway, Apache is the Ferrari (neat, sexy, fast .. what everyone
wants) where WU-FTPD is a Mac truck (it aint pretty, it's sometimes slow,
but it hauls the freight and gets the job done). I like this analogy a
lot. Apache's primary job is shovelling a large number of small files out
the door as quickly as possible. FTP, on the other hand, is meant to push
massive amounts of information. Sure either can do the others job, but
the design goals and implementation choices for each should reflect that
basic difference.

If one were to implement it on the Apache model using Apache's runtime
support as much as possible, I rather doubt it would have any resembalance
to wu-ftpd. In fact, why bother with wu-ftpd at all? All you'd really be
using is the name. It would be better, especially considering the baggage
you'd be picking up with the Apache code base, to lose the baggage of
wu-ftpd and make a fresh start. All it takes is someone with the will,
the time, and the programming abililty.

--

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

From [email protected] Wed Dec 2 20:48:39 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id UAA06428;
Wed, 2 Dec 1998 20:48:39 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id UAA12294;
Wed, 2 Dec 1998 20:43:56 -0600 (CST)
Received: from b5.eng.internex.net (b5.eng.internex.net [207.88.8.14])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id UAA32733
for <[email protected]>; Wed, 2 Dec 1998 20:38:44 -0600 (CST)
Received: from localhost by b5.eng.internex.net (8.9.1/8.9.1) with SMTP id SAA11589
for <[email protected]>; Wed, 2 Dec 1998 18:38:10 -0800 (PST)
Message-Id: <[email protected]>
Date: Wed, 2 Dec 1998 18:38:09 -0800 (PST)
Reply-To: [email protected]
Sender: [email protected]
From: Che Tran <[email protected]>
To: [email protected]
Subject: BeroFTPD 1.2.1 passwd & shadow files
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

After a successful compilation with the --enable passwd switch, I was
able to use the passwd and shadow directives in ftpaccess. However, I
found that in order to log in successfully, I have to log in the 2nd time.
Am I missing something?
Secondly, the internal ls does not seem to function 100%, as I'm still
getting the following complaint when doing 'ls -al':

remote: -al

How do I use an ldd to find its dependencies since it's internal?

On the side note, does anyone know how to use the useradd and passwd
commands to direct it to another file such as /usr/local/etc/wuftpd/passwd
and /usr/local/etc/wuftpd/shadow instead of /etc/passwd and /etc/shadow?

Thanks, you guys are cool!! (and a lot better than apache's mailing
list/news group, just kidding).

-ctran

From [email protected] Thu Dec 3 06:54:18 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id GAA12866;
Thu, 3 Dec 1998 06:54:16 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id GAA13235;
Thu, 3 Dec 1998 06:46:59 -0600 (CST)
Received: from harry.informatik.rwth-aachen.de (harry.Informatik.RWTH-Aachen.DE [137.226.116.28])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id GAA08558
for <[email protected]>; Thu, 3 Dec 1998 06:36:11 -0600 (CST)
Received: from microsoft.sucks.eu.org (IDENT:[email protected] [137.226.8.215])
by harry.informatik.rwth-aachen.de (8.9.1a/8.9.1/1) with SMTP id NAA05579;
Thu, 3 Dec 1998 13:35:38 +0100 (MET)
Message-Id: <Pine.LNX.4.04.9812031242530.3148-100000@k6.microsoft.sucks.eu.org>
Date: Thu, 3 Dec 1998 12:50:14 +0100 (CET)
Reply-To: [email protected]
Sender: [email protected]
From: Bernhard Rosenkraenzer <[email protected]>
To: Che Tran <[email protected]>
Cc: [email protected]
Subject: Re: BeroFTPD 1.2.1 passwd & shadow files
In-Reply-To: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

On Wed, 2 Dec 1998, Che Tran wrote:

> After a successful compilation with the --enable passwd switch, I was
> able to use the passwd and shadow directives in ftpaccess. However, I
> found that in order to log in successfully, I have to log in the 2nd time.
> Am I missing something?

I can't reproduce this - are you getting any odd entries in syslog?

> Secondly, the internal ls does not seem to function 100%, as I'm still
> getting the following complaint when doing 'ls -al':
>
> remote: -al

Another "works for me" thing.
This is almost certainly a matter of your client. If you telnet into port
21 and do things by hand, you'll see...

Some clients think that -l means "output to local file", for example.

> How do I use an ldd to find its dependencies since it's internal?

There's no such thing as an external ls command embedded and called...
The internal ls is just a procedure that does pretty much the same thing
calling ls would do.
It doesn't have any special dependencies.

> On the side note, does anyone know how to use the useradd and passwd
> commands to direct it to another file such as /usr/local/etc/wuftpd/passwd
> and /usr/local/etc/wuftpd/shadow instead of /etc/passwd and /etc/shadow?

At least in the versions I'm using (=whatever is installed by default on
RedHat 5.2 and FreeBSD 3.0-current), it's not possible - you'd have to
patch the source to handle another command line parameter, or create
different binaries (maybe useradd-ftp and passwd-ftp) with hardcoded
different paths for the files.
At least the latter shouldn't be much of a problem.

LLaP
bero

--
Windows 98 supports real multitasking - it can boot and crash simultaneously.
***
Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

From [email protected] Thu Dec 3 07:00:19 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id HAA12934;
Thu, 3 Dec 1998 07:00:18 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id GAA02076;
Thu, 3 Dec 1998 06:54:51 -0600 (CST)
Received: from harry.informatik.rwth-aachen.de (harry.Informatik.RWTH-Aachen.DE [137.226.116.28])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id GAA26082
for <[email protected]>; Thu, 3 Dec 1998 06:36:32 -0600 (CST)
Received: from microsoft.sucks.eu.org (IDENT:[email protected] [137.226.8.215])
by harry.informatik.rwth-aachen.de (8.9.1a/8.9.1/1) with SMTP id NAA05601;
Thu, 3 Dec 1998 13:36:00 +0100 (MET)
Message-Id: <Pine.LNX.4.04.9812031319180.27397-100000@k6.microsoft.sucks.eu.org>
Date: Thu, 3 Dec 1998 13:21:55 +0100 (CET)
Reply-To: [email protected]
Sender: [email protected]
From: Bernhard Rosenkraenzer <[email protected]>
To: [email protected], [email protected],
[email protected]
Cc: [email protected]
Subject: BeroFTPD 1.2.3 released
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

I've just released BeroFTPD 1.2.3.
It can be found at
ftp://beroftpd.unix.eu.org/pub/BeroFTPD/
ftp://ftp.croftj.net/usr/bero/BeroFTPD/
ftp://ftp.sunet.se/pub/nir/ftp/servers/BeroFTPD/
ftp://sunsite.cnlab-switch.ch/mirror/BeroFTPD/

1.3.1 (which will include the most recent VR patches) will follow soon
(probably Monday).

Changes:
+ Add PAM support (adapted from RedHat's patches to wu-ftpd)
(from 1.3.0, which has been tested well enough)
PAM support will possibly work only on Linux, so it is disabled by
default.
* Fix compilation with --disable-virtual
* Fix a bug (not clearing memory after a malloc) that might cause crashes
on some systems

--
Windows 98 supports real multitasking - it can boot and crash simultaneously.
***
Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

From [email protected] Thu Dec 3 14:24:50 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id OAA17765;
Thu, 3 Dec 1998 14:24:36 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id OAA20816;
Thu, 3 Dec 1998 14:13:27 -0600 (CST)
Received: from lexmark.lexmark.com (interlock2.lexmark.com [192.146.101.10])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id OAA08513
for <[email protected]>; Thu, 3 Dec 1998 14:12:11 -0600 (CST)
Received: by interlock2.lexmark.com id AA23216
(InterLock SMTP Gateway 3.0 for [email protected]);
Thu, 3 Dec 1998 15:12:04 -0500
Received: by interlock2.lexmark.com (Protected-side Proxy Mail Agent-1);
Thu, 3 Dec 1998 15:12:04 -0500
Message-Id: <[email protected]>
Date: Thu, 3 Dec 1998 15:11:00 -0500
Reply-To: [email protected]
Sender: [email protected]
From: [email protected]
To: [email protected]
Subject: normal ftp works, browser ftp dont
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Lotus-Fromdomain: LEXMARK@LEXMTA
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

Running beta 15 on an AIX box and getting this problem.. when normal ftp into
box as a user,
all is well. VIA any browser, I get logged on and put in my home directory, but
I can not click on a file and have it ftp'd to me. Get following error:

FTP Transfer Failed
The requested file or directory /C316-B3-981202.trim.gz could not be retrieved
from ftp.lexmark.com

It appears that we are chroot to our home directory and then the browser or
WU_FTP looks in root (/) for file and of course does not find it.

Proper premission are set and owned by right ID.. this has worked in past>
any help out there ? Jim

From [email protected] Thu Dec 3 14:33:02 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id OAA17952;
Thu, 3 Dec 1998 14:33:00 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id OAA02228;
Thu, 3 Dec 1998 14:26:06 -0600 (CST)
Received: from ljcqs016.cnf.com (mailhost.cnf.com [205.185.108.240])
by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id OAA11058
for <[email protected]>; Thu, 3 Dec 1998 14:23:39 -0600 (CST)
Received: from cnfvs008.cnf.com (cnfvs008.cnf.com [10.0.2.114])
by ljcqs016.cnf.com (8.8.7/8.8.7) with ESMTP id MAA17333;
Thu, 3 Dec 1998 12:23:08 -0800 (PST)
Received: by cnfvs008.cnf.com with Internet Mail Service (5.5.2232.9)
id <X8S5Q10Y>; Thu, 3 Dec 1998 12:23:05 -0800
Message-Id: <[email protected]>
Date: Thu, 3 Dec 1998 12:23:16 -0800
Reply-To: [email protected]
Sender: [email protected]
From: "Speier, Guy J - CNF" <[email protected]>
To: [email protected], "'[email protected]'" <[email protected]>
Subject: RE: normal ftp works, browser ftp dont
MIME-Version: 1.0
Content-Type: text/plain
X-Mailer: Internet Mail Service (5.5.2232.9)
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

I believe that this could be a firewall probelm. Are you running
a firewall, and if so, what version?

> ----------
> From: [email protected][SMTP:[email protected]]
> Reply To: [email protected]
> Sent: Thursday, December 03, 1998 12:11 PM
> To: [email protected]
> Subject: normal ftp works, browser ftp dont
>
>
>
> Running beta 15 on an AIX box and getting this problem.. when normal ftp
> into
> box as a user,
> all is well. VIA any browser, I get logged on and put in my home
> directory, but
> I can not click on a file and have it ftp'd to me. Get following error:
>
> FTP Transfer Failed
> The requested file or directory /C316-B3-981202.trim.gz could not be
> retrieved
> from ftp.lexmark.com
>
> It appears that we are chroot to our home directory and then the browser
> or
> WU_FTP looks in root (/) for file and of course does not find it.
>
> Proper premission are set and owned by right ID.. this has worked in past>
> any help out there ? Jim
>
>
>
>
>
>

From [email protected] Thu Dec 3 15:07:16 1998
Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1])
by landfield.com (8.9.0/8.9.0) with ESMTP id PAA18405;
Thu, 3 Dec 1998 15:07:15 -0600 (CST)
Received: from host (wugate.wustl.edu [128.252.120.1])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id OAA21270;
Thu, 3 Dec 1998 14:58:22 -0600 (CST)
Received: from lexmark.lexmark.com (interlock2.lexmark.com [192.146.101.10])
by wugate.wustl.edu (8.8.8/8.8.5) with SMTP id OAA14369
for <[email protected]>; Thu, 3 Dec 1998 14:56:06 -0600 (CST)
Received: by interlock2.lexmark.com id AA27664
(InterLock SMTP Gateway 3.0 for [email protected]);
Thu, 3 Dec 1998 15:56:05 -0500
Received: by interlock2.lexmark.com (Protected-side Proxy Mail Agent-1);
Thu, 3 Dec 1998 15:56:05 -0500
Message-Id: <[email protected]>
Date: Thu, 3 Dec 1998 15:54:31 -0500
Reply-To: [email protected]
Sender: [email protected]
From: [email protected]
To: [email protected]
Subject: RE: normal ftp works, browser ftp dont
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Lotus-Fromdomain: LEXMARK@LEXMTA
X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN

Running ANS firewall version 41M