Subject: slow startup on solaris

From: Kris Boulez <[email-masked]>
Date: Tue, 11 Aug 1998 14:47:27 +0200

Hello,

I'm experiencing slow startup (~20 sec) for wu-ftpd on a solaris
2.6 machine (both with beta15 and 18). The only thing 'special' is
the fact that there are ~1500 guest accounts with each a seperate upload
line in /etc/ftpaccess (when I use this ftpaccess file on Linux PC,
I get no noticable delay). With slow startup I mean the time between 
entering the password and getting the 'ftp>' prompt.
Anyone who can shed a light on this ?

Kris,
-- 
Kris Boulez				[email-masked]

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 11 Aug 1998 09:13:24 -0400 (EDT)

On Tue, 11 Aug 1998, Kris Boulez wrote:

> I'm experiencing slow startup (~20 sec) for wu-ftpd on a solaris 2.6
> machine (both with beta15 and 18). The only thing 'special' is the fact
> that there are ~1500 guest accounts with each a seperate upload line in
> /etc/ftpaccess (when I use this ftpaccess file on Linux PC, I get no
> noticable delay). With slow startup I mean the time between entering the
> password and getting the 'ftp>' prompt.  Anyone who can shed a light on
> this ? 

It's most likely the time it takes to parse the ftpaccess file and check
all the upload lines.  If you're using networked authentication (say,
NIS+) it'll take even longer.  There's patches in the mailing list
archives to aleviate some of this, and I've included those patches in my
VR3 and VR4 patches.  My stuff can be found at
ftp://ftp.vr.net/pub/wu-ftpd/

The location of the latest version of wu-ftpd can be found in the 
directory
 
      ftp://ftp.academ.com/pub/wu-ftpd/private/
 
You can't see the directory contents, so read the message informing you
of the actual filename to retrieve. It's there.
 
wu-ftpd Resource Center:  http://www.landfield.com/wu-ftpd/
wu-ftpd FAQ:              http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
wu-ftpd list archive:     http://www.landfield.com/wu-ftpd/mail-archive/

----

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

---

From: Kris Boulez <[email-masked]>
Date: Wed, 12 Aug 1998 10:10:06 +0200

Quoting Gregory A Lundberg ([email-masked]):
> NIS+) it'll take even longer.  

I looked at this problem somewhat more closely and it (using 'truss') and it
turns out that wu-ftpd does ~1900 opens and reads of /etc/passwd and /etc/group
and ~3800 times open64(/etc/.name_service_door). Given the fact that /etc/ftpaccess
contains ~1900 upload lines I think the conclusion is pretty clear. I've had a 
short look at the sources (beta-15) and everything appears to be happening 
in expand_id() in extensions.c . I don't really understand (at the moment) how the
code is working, but I wonder if the content of /etc/passwd (and group) couldn't be cached
somehow.

                  There's patches in the mailing list
> ftp://ftp.vr.net/pub/wu-ftpd/
Anyone has any experience with the use of these patches ?

Kris,

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 12 Aug 1998 07:49:23 -0400 (EDT)

On Wed, 12 Aug 1998, Kris Boulez wrote:

> I looked at this problem somewhat more closely and it (using 'truss')
> and it turns out that wu-ftpd does ~1900 opens and reads of /etc/passwd
> and /etc/group and ~3800 times open64(/etc/.name_service_door). Given
> the fact that /etc/ftpaccess contains ~1900 upload lines I think the
> conclusion is pretty clear. I've had a short look at the sources
> (beta-15) and everything appears to be happening in expand_id() in
> extensions.c . I don't really understand (at the moment) how the code is
> working, but I wonder if the content of /etc/passwd (and group) couldn't
> be cached somehow. 

Here's how I solve the problem here:  put all the users in a common
directory (/home/users/~<name>).  Special users, such as 'ftp' are in
another area (/home/ftp here).  Each user has his own group (GID just
happens to be same value as UID).  All users are in a group 'users' which
is what I use on my single 'guestgroup' statement.  Users are chroot'd to
the common point (/home/users) and are kept out of each others files by
permissions .. their homes are UID/GID owned by the individual user and
are only world-execute (no world-read or world-write).  I set the default
umask for login to 006 so, by default, files created by users are not
world-read/world-write and initially chmod'd all files in their homes to
remove these world permissions.  Users are, therefore, kept apart unless
_they_ choose to make a file world-read or world-write. 

----