Subject: Virtual Hosting Support in WU-FTPD

From: Kent Landfield <[email-masked]>
Date: Mon, 23 Jun 1997 17:31:04 -0500 (CDT)

----------------

NOTE: PLEASE READ THIS IF YOU ARE INTERESTED IN VIRTUAL HOSTING SUPPORT.

    This is a bit long but it is an important issue that may affect you...

----------------

There are now 15+ sites running my new way of supporting Virtual Hosts in 
WU-FTPD.  It has also been running here for the last two months with no 
problems.  While it still needs some more portability testing, the time has 
come to ask a question or two.

First off, the background.

     There are quite a few things that would be nice to have supported
     in virtual servers. In the current baselined version, virtual servers
     are only partially supported. The current implementation of virtual
     servers only supports setting 

         the root ftp directory, 
         the log file and 
         the banner. 

     All other directives in the ftpaccess file MUST be shared globally
     across all virtual servers. A real limitation if you wanted to have
     different features supported by different servers... 

     In reviewing how virtual servers were implemented, I reread the
     virtual server setup FAQ. There were two different methods
     documented. First is the VIRTUAL support that is a part of the
     current beta-13 baseline. It only supports the three ftpaccess file
     directives listed above. The other method is the alternative
     method which requires tcpwrappers. It then dawned on me that
     the answer to completely supporting virtual servers was right in
     front of me. 

     Why couldn't I simply specify which ftpaccess file to use ? If I
     could do that then maybe it wouldn't be a major task to add
     support for all access file directives.

     Here's what I did... First I created a new file called "ftpservers"
     defined by the path _PATH_FTPSERVERS. Presently, the file is optional 
     so if it's missing, the original ftpaccess (_PATH_FTPACCESS) file
     is used. In access_init() I included a call to a new function
     "getaccessfilename()" that looks up the access file based on the
     socket address the user is coming in on. The "found" file is then
     passed to readacl() as the hard-coded _PATH_FTPACCESS was before. 
     Other than a minor tweak, that was all that was needed. COMPLETE 
     virtual ftpaccess support... 

     I made the associated changes to ftpshut, ckconfig and my new
     ftprestart and ftpck utilities. The only program in the wu-ftpd 
     suite that does not have the new virtual access file support is 
     ftpcount. 

     All changes were made to the latest beta-13. (When Stan brings out
     beta-14 I'll be re-incorporating them into that.) I plan on sending 
     these to Stan for inclusion in a upcoming version. 

Second, the concern...

    We cannot ask Stan to support both methods of virtual hosting. There is 
    the limited version that is currently a part of the baseline and then 
    there is my version that completely supports all ftpaccess file directives.
    We need to decide what to do here.  

    First off, what we are discussing here is down the road and won't be 
    happening tomorrow so we have time to discuss this as needed.

    I PROPOSE that we drop the current method of supporting virtual hosting 
    from the baseline in favor of complete ftpaccess virtual hosting support.
    This will affect all but the 15 or so that are currently running that 
    version. 

    I know I'm asking some of you to do some work...  How much of a change 
    will it be ?  Well it will require creating a new file, ftpservers, that 
    looks like the following...

    #
    # ftpservers file
    #
    # Format:
    # ip-address associated-ftpaccess-file
    #
    # ftpaccess file for the some.domain
    #
    10.196.145.2 /etc/ftpd/ftpaccess
    #
    # ftpaccess file for the some.domain1
    #
    10.196.145.20 /etc/ftpd/ftpaccess.some.domain1
    #
    # ftpaccess file for the some.domain2
    #
    10.196.145.200 /etc/ftpd/ftpaccess.some.domain2
    
    Then it will require creating an ftpaccess file tailored to the individual
    virtual host/customer needs.
    
    Initially, a little cloning and editing of the existing ftpaccess file
    and you're ready to go.  If you then have customers that need more 
    specific changes, you can go back in and make those changes. (You 
    couldn't before.)
    
    It should not take long to do but only you know how many virtual domains
    you have to support.

Third, the benefit...

    In order to better support your virtual domains you need the granularity
    that the complete ftpaccess support provides.  Besides allowing ANY 
    virtual server to be able to set and use ANY ftpaccess file directive, 
    an additional benefit is that any future extensions Stan adds to the 
    ftpaccess file will be automatically supported for virtual servers as 
    well. Free. 
   
Finally....
    
    I have my flame retardant shorts on so have at it... ;)  I'd prefer
    that this discussion took place on the mailing list for all to see.
    This is an important decision.  Please take some time and think about
    it before responding.  If you simply want to call me a crazy #$!&*@
    fool, please do that in direct email to me. ;)

-- 
Kent Landfield                        Phone: 1-817-545-2502             
The Landfield Group                   FAX:   1-817-545-7650             
Email: [email-masked]             http://www.landfield.com/
Please send comp.sources.misc related mail to [email-masked].
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/

---

From: Aaron Holtz <[email-masked]>
Date: Mon, 23 Jun 1997 21:10:52 -0400 (EDT)

I'd have to agree with Kent.  I love his method of attacking the virtuals.
It does get to be easier in that you have a finer control over the virtual
sites and in how they are configured.  Yes, you have to keep several
different config files (one for each virtual), but if most of them are
configured the same way I don't see the real trouble in keeping a template
and just making the appropriate edits for the newest server.  We run this
new code on a server with about 10 virtuals, each one (of course) wanting
something different in how their ftp server operates.  This method of
having a separate ftpaccess file for each virtual has let me fine tune
their servers to their needs (because inevitably their needs change on a
daily basis....).  I didn't quite have this luxury under the standard ftpd
code.    Just a vote in favor of the newest code.  We are running this on
a Solaris 2.5.1 UltraSparc platform for the record.   

							--Aaron

---------------------------------------------------------------------
Aaron Holtz
First Network Group    "The First Name in Internetworking"
Manager, UNIX Systems Admin
Email:  [email-masked]
"...perhaps because it is very difficult, even with sensitive laboratory
 instruments, to distinguish one rap song from another."  -DB
---------------------------------------------------------------------

On Mon, 23 Jun 1997, Kent Landfield wrote:

:----------------
:
:NOTE: PLEASE READ THIS IF YOU ARE INTERESTED IN VIRTUAL HOSTING SUPPORT.
:
:    This is a bit long but it is an important issue that may affect you...
:
:----------------
:
:There are now 15+ sites running my new way of supporting Virtual Hosts in 
:WU-FTPD.  It has also been running here for the last two months with no 
:problems.  While it still needs some more portability testing, the time has 
:come to ask a question or two.
:
:First off, the background.
:
:     There are quite a few things that would be nice to have supported
:     in virtual servers. In the current baselined version, virtual servers
:     are only partially supported. The current implementation of virtual
:     servers only supports setting 
:
:         the root ftp directory, 
:         the log file and 
:         the banner. 
:
:     All other directives in the ftpaccess file MUST be shared globally
:     across all virtual servers. A real limitation if you wanted to have
:     different features supported by different servers... 
:
:     In reviewing how virtual servers were implemented, I reread the
:     virtual server setup FAQ. There were two different methods
:     documented. First is the VIRTUAL support that is a part of the
:     current beta-13 baseline. It only supports the three ftpaccess file
:     directives listed above. The other method is the alternative
:     method which requires tcpwrappers. It then dawned on me that
:     the answer to completely supporting virtual servers was right in
:     front of me. 
:
:     Why couldn't I simply specify which ftpaccess file to use ? If I
:     could do that then maybe it wouldn't be a major task to add
:     support for all access file directives.
:
:     Here's what I did... First I created a new file called "ftpservers"
:     defined by the path _PATH_FTPSERVERS. Presently, the file is optional 
:     so if it's missing, the original ftpaccess (_PATH_FTPACCESS) file
:     is used. In access_init() I included a call to a new function
:     "getaccessfilename()" that looks up the access file based on the
:     socket address the user is coming in on. The "found" file is then
:     passed to readacl() as the hard-coded _PATH_FTPACCESS was before. 
:     Other than a minor tweak, that was all that was needed. COMPLETE 
:     virtual ftpaccess support... 
:
:     I made the associated changes to ftpshut, ckconfig and my new
:     ftprestart and ftpck utilities. The only program in the wu-ftpd 
:     suite that does not have the new virtual access file support is 
:     ftpcount. 
:
:     All changes were made to the latest beta-13. (When Stan brings out
:     beta-14 I'll be re-incorporating them into that.) I plan on sending 
:     these to Stan for inclusion in a upcoming version. 
:
:Second, the concern...
:
:    We cannot ask Stan to support both methods of virtual hosting. There is 
:    the limited version that is currently a part of the baseline and then 
:    there is my version that completely supports all ftpaccess file directives.
:    We need to decide what to do here.  
:
:    First off, what we are discussing here is down the road and won't be 
:    happening tomorrow so we have time to discuss this as needed.
:
:    I PROPOSE that we drop the current method of supporting virtual hosting 
:    from the baseline in favor of complete ftpaccess virtual hosting support.
:    This will affect all but the 15 or so that are currently running that 
:    version. 
:
:    I know I'm asking some of you to do some work...  How much of a change 
:    will it be ?  Well it will require creating a new file, ftpservers, that 
:    looks like the following...
:
:    #
:    # ftpservers file
:    #
:    # Format:
:    # ip-address associated-ftpaccess-file
:    #
:    # ftpaccess file for the some.domain
:    #
:    10.196.145.2 /etc/ftpd/ftpaccess
:    #
:    # ftpaccess file for the some.domain1
:    #
:    10.196.145.20 /etc/ftpd/ftpaccess.some.domain1
:    #
:    # ftpaccess file for the some.domain2
:    #
:    10.196.145.200 /etc/ftpd/ftpaccess.some.domain2
:    
:    Then it will require creating an ftpaccess file tailored to the individual
:    virtual host/customer needs.
:    
:    Initially, a little cloning and editing of the existing ftpaccess file
:    and you're ready to go.  If you then have customers that need more 
:    specific changes, you can go back in and make those changes. (You 
:    couldn't before.)
:    
:    It should not take long to do but only you know how many virtual domains
:    you have to support.
:
:Third, the benefit...
:
:    In order to better support your virtual domains you need the granularity
:    that the complete ftpaccess support provides.  Besides allowing ANY 
:    virtual server to be able to set and use ANY ftpaccess file directive, 
:    an additional benefit is that any future extensions Stan adds to the 
:    ftpaccess file will be automatically supported for virtual servers as 
:    well. Free. 
:   
:Finally....
:    
:    I have my flame retardant shorts on so have at it... ;)  I'd prefer
:    that this discussion took place on the mailing list for all to see.
:    This is an important decision.  Please take some time and think about
:    it before responding.  If you simply want to call me a crazy #$!&*@
:    fool, please do that in direct email to me. ;)
:
:-- 
:Kent Landfield                        Phone: 1-817-545-2502             
:The Landfield Group                   FAX:   1-817-545-7650             
:Email: [email-masked]             http://www.landfield.com/
:Please send comp.sources.misc related mail to [email-masked].
:Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/
:

---

From: Michael Brennen <[email-masked]>
Date: Mon, 23 Jun 1997 20:35:13 -0500 (CDT)

>     This will affect all but the 15 or so that are currently running that 

yes++;

I like this latest layout.  I run three virtual FTPs now, and I wish I
could allocate a certain number of connections to each of them.  With the
present scheme, I just have to make the total number of connections high
enough that the smaller clients are not squeezed out.  With the new scheme
I can regulate bandwidth much more effectively as well as insuring a
certain level of service.

The price of fine granularity is maintaining multiple ftpaccess files; 
that's okay with me, as I like what I get for it.  Well done.

   -- Michael

---

From: Jon Lewis <[email-masked]>
Date: Tue, 24 Jun 1997 00:56:02 -0400 (EDT)

>     10.196.145.2 /etc/ftpd/ftpaccess

Noooo....  If you're going to bother changing this, do it right.  In
Apache's httpd.conf, I use hostnames entirely rather than IP's so if I
change a host's IP, I don't have to go change it in bunches of config
files.  I should be able to have:

ftp.foo.com	/etc/ftpd/ftpaccess, etc.

As of beta11, hostnames in ftpaccess virtual FTP options don't work.

Also, rather than lots of hacking in wu-ftpd, it might make more sense to
use an inetd that handles virtual servers, and just run wu-ftpd with a
different ftpaccess file.  Then all you have to do is add a command line
switch that allows you to say 
/usr/sbin/wu-ftpd -a /home/virtual/domain1/ftpd/ftpaccess -lio

------------------------------------------------------------------
 Jon Lewis <[email-masked]>  |  Unsolicited commercial e-mail will
 Network Administrator       |  be proof-read for $199/message.
 Florida Digital Turnpike    |  
________Finger [email-masked] for PGP public key_______

---

From: Mitch Wright <[email-masked]>
Date: Mon, 23 Jun 1997 22:26:07 -0700

/* Kent Landfield [[email-masked]] writes: */

>    This is a bit long but it is an important issue that may affect you...
I would like to voice my support for Kent's proposal.

However, I would recommend a slight change to the behavior Kent briefly
described which would provide a certain degree of backwards compatability.
It has been a while since I've had my nose deep into the WU-FTPd code so
please excuse me if I'm a bit off track with this...

I would like to see the daemon first load the "main" ftpaccess file and
then read (if it exists) the ftpaccess file that is specific to that
virtual host.  The first ftpaccess read would prime the defaults of the
server and the second read would tune them to that accounts liking.

Good job Kent on working through that one... I've nearly completed
something similar for providing true virtual E-mail hosting using
[gasp!] sendmail.

-- 
do svidaniya,

  ~mitch

---

From: Michael Bracewell <[email-masked]>
Date: Tue, 24 Jun 1997 08:47:49 -0400 (EDT)

Kent Landfield sez:
| 
|     I PROPOSE that we drop the current method of supporting virtual hosting 
|     from the baseline in favor of complete ftpaccess virtual hosting support.
|     This will affect all but the 15 or so that are currently running that 
|     version. 

First of all, great work Kent!  I prefer your method over the existing virtual
support.  I would suggest that if possible there be some way to set defaults
for directives so that maybe an entire access file would not have to be
maintained for every virtual host, but this could certainly be handled by a
macro preprocessor or such if it adds to much overhead or complexity...

Thanks again for all the hard work on this and ftpck!

-- 
Michael Bracewell <[email-masked]>
Office of Information and Instructional Technology
Technology Support Services
Board of Regents of the University System of Georgia

---

From: Kent Landfield <[email-masked]>
Date: Tue, 24 Jun 1997 12:46:05 -0500 (CDT)

# >     # Format:
# >     # ip-address associated-ftpaccess-file
# >     #
# >     # ftpaccess file for the some.domain
# >     #
# >     10.196.145.2 /etc/ftpd/ftpaccess
# 
# Noooo....  If you're going to bother changing this, do it right.  In
# Apache's httpd.conf, I use hostnames entirely rather than IP's so if I
# change a host's IP, I don't have to go change it in bunches of config
# files.  I should be able to have:
# 
# ftp.foo.com	/etc/ftpd/ftpaccess, etc.

Ok. I took 10 minutes and added the ability to use either hostnames or
IP addresses.  I'm running it now. I'll be putting up a newer copy later
today after playing with it some more to assure there aren't problems.

Thanks for the push. ;)

---

From: [email-masked]
Date: 24 Jun 1997 18:07:02 GMT

Pink elephants with an attitude inspired Kent Landfield <[email-masked]> to tell garfield.mail.wu-ftpd:
:     I PROPOSE that we drop the current method of supporting virtual hosting 
:     from the baseline in favor of complete ftpaccess virtual hosting support.

Couple of comments on this and on the responses:
- I'd rather see something like
  virtual ftp.foo.com /etc/ftp/ftp.foo.com in the main ftpaccess
  that loads settings that override stuff set in the main ftpaccess file
  for that particular hostname
  Oh, and no ip-addresses, but you already mentioned that. ;-)
- I'd rather *not* muck with extra inetd's. If this can be done without
  that kind of stuff ... please. It shouldn't be necessary for this and
  I feel it complicates things. That's MHO of course.
- I'd also like to see the incorporation of other configfiles.
  ftpusers in particular, so I can turn off anon-ftp for a
  virtual server. I can already do this with limiting anonymous
  to 0 or guestserver directives in the proposed config, but I
  bet someone's going to need this kind of stuff later on for
  guestgroups or something like that so it might be useful to
  think about it now.

-- 
Perry Rovers ([email-masked])

---

From: Jim Dennis <[email-masked]>
Date: Tue, 24 Jun 1997 14:31:42 -0700

> Kent Landfield                        Phone: 1-817-545-2502             

	How about address/host "globbing" a la tcpd's hosts.allow
	and hosts.deny files.  So I could say

	192.168.44.*		/etc/ftpaccess.private-rfc1918
	*.private.mylan.org	/etc/ftpaccess.private-rfc1918
	172.17.*.*		/etc/ftpaccess.big-intralan
	*.wan.myorg.org		/etc/ftpaccess.big-intralan

		(note: I'm not sure my syntax here is correct --
		 it's just for example).

	... etc.

	You might just lift the code right out of tcpd's parser
	(with Wietse's permission, of course).

	I've read about places that are hosting hundreds of virtual
	web servers on their machines -- this would be handy for them.

--
Jim Dennis,                                [email-masked]
Proprietor,                          [email-masked]
Starshine Technical Services              http://www.starshine.org

        PGP  1024/2ABF03B1 Jim Dennis <[email-masked]>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A

---

From: Kent Landfield <[email-masked]>
Date: Tue, 24 Jun 1997 19:08:58 -0500 (CDT)

# Pink elephants with an attitude inspired Kent Landfield <[email-masked]> 
# to tell garfield.mail.wu-ftpd:
 
:) Take a nice simple proposal and blow it wide open... With an attitude... ;)

# Couple of comments on this and on the responses:
# - I'd rather see something like
#   virtual ftp.foo.com /etc/ftp/ftp.foo.com in the main ftpaccess
#   that loads settings that override stuff set in the main ftpaccess file
#   for that particular hostname

I have received 5+ private email messages and there has been a couple on the
list about enhancing the way I currently do complete virtual hosting. All have
suggested incorporating some sort of master template ftpaccess file.  If we are
serious about getting it right then I have a deal for those interested. Let's 
talk about it here, figure out what it is that we want to have and I'll 
prototype it.  Then, those that want to can help test it.  Once we feel 
comfortable with it's functionality and implementation, I ship it to Stan so
that he can put it in when its convenient in his the release cycle. Fair 
enough ? And I thought I was done... ;)
 
First premise: This can only affect the Virtual hosting sites. Standard,
               non-virtual sites will not be affected. 

Here is what I have gathered from the various messages:

  - When a site connects to a virtual ftp server, the server will get the
    IP address of the inbound socket to determine which virtual domain is
    to be served.

  - It will then reads the Master ftpaccess file setting the default values
    for the directives listed.  These values are inherited by all virtual
    domains initially.

  - The server then looks to see if there is an ftpaccess file for that 
    specific virtual domain that overrides the default settings.  If so, 
    the server will read that file resetting only the values listed. 

  - The server then begins a normal session.

This would make it possible to have one ftpaccess file for the entire site
or let a site customize an ftpaccess file just for that site.  With this
model, the site could create ftpaccess files with only the differences from
the master template or have complete ftpaccess files for each virtual site. 

Is this what people had in mind ?

# - I'd also like to see the incorporation of other configfiles.
#   ftpusers in particular, so I can turn off anon-ftp for a
#   virtual server. I can already do this with limiting anonymous
#   to 0 or guestserver directives in the proposed config, but I
#   bet someone's going to need this kind of stuff later on for
#   guestgroups or something like that so it might be useful to
#   think about it now.

      ftpaccess - been there, discussed that, just need to see if the
                  a concensus can be reached about semantics.
      xferlog   - Will be specifiable on a virtual domain basis.

 ftpconversions - Does this need to be different ??? Probably not.
       ftphosts - Does this need to be different ???
      ftpgroups - Does this need to be different ??? Or just support an
                  extended record format  for virtual servers only ?
       ftpusers - Does this need to be different ??? Or just support an
                  extended the record format for virtual servers only ?

   Man, those pink elephants are getting bigger and bigger... ;)

---

From: [email-masked]
Date: 25 Jun 1997 16:55:04 GMT

A flock of rogue penguins inspired Kent Landfield <[email-masked]> to tell garfield.mail.wu-ftpd:
: # Pink elephants with an attitude inspired Kent Landfield <[email-masked]> 
: # to tell garfield.mail.wu-ftpd:
:  
: :) Take a nice simple proposal and blow it wide open... With an attitude... ;)
Of course.. you know me .. ;-)

[snippage]

: Is this what people had in mind ?
In my case.. yes. I thought of an alternative/extension this afternoon where
you just specify something like:
virtual ftp.foo.com /etc/ftp/ftp.foo.com/
where the /etc/ftp.foo.com/ directory will contain 'local' ftpaccess,
ftpusers etc. files.

:  ftpconversions - Does this need to be different ??? Probably not.
Can't image why unless you have people with specific requirements
here. I've never seen them though. I don't use ftphosts/ftpgroups so I
can't comment on that.

:        ftpusers - Does this need to be different ??? Or just support an
:                   extended the record format for virtual servers only ?
Unable to parse sentence .. s/the //g.. continuing.. [ObInternalJoke:
English is your first language n'est ce pas? ;-)] if you adopt the idea of
separate configdirectories you could just 'add in' the extra ftpusers. Or
subtract 'm.. hmm.. could that be useful?

:    Man, those pink elephants are getting bigger and bigger... ;)
I intend to drink 'em away tonight.. always works for me. Sometimes they
turn into penguins though.

---

From: Kent Landfield <[email-masked]>
Date: Thu, 26 Jun 1997 12:46:41 -0500 (CDT)

# In my case.. yes. I thought of an alternative/extension this afternoon where
# you just specify something like:

# virtual ftp.foo.com /etc/ftp/ftp.foo.com/

# where the /etc/ftp.foo.com/ directory will contain 'local' ftpaccess,
# ftpusers etc. files.

This might make sense to keep virtual domain config files separated...
In reviewing mail and list traffic there seems there might be other needs 
in order to support virtual domains completely.  What do others think ?

---

From: Mathieu Guillaume <[email-masked]>
Date: Thu, 26 Jun 1997 23:55:19 +0200 (MET DST)

> in order to support virtual domains completely.  What do others think ?  

It would be nice to be able to use alternate password files too, on for 
each site. The problem with this, at the moment, is the /etc/passwd is 
hardcoded is the libc. A possibility would be a Apache-like system, where 
you specify the authentication file and method. You would then have the 
default in /etc/ftpaccess, which you could override in the virtual domain 
specific file. At the moment, different virtual hosts are not different 
enough to my taste (if a user has an account on domain1.com and logs on 
domain2.com, it is the same as if he logged on domain1.com, I'd like to 
be able to change that).
Hmmm... perhaps we could rip off Apache's code, it seems to work nicely :)

					Mat

---

From: Kent Landfield <[email-masked]>
Date: Thu, 26 Jun 1997 17:20:57 -0500 (CDT)

# # In my case.. yes. I thought of an alternative/extension this afternoon where
# # you just specify something like:
# 
# # virtual ftp.foo.com /etc/ftp/ftp.foo.com/
# 
# # where the /etc/ftp.foo.com/ directory will contain 'local' ftpaccess,
# # ftpusers etc. files.
# 
# This might make sense to keep virtual domain config files separated...
# In reviewing mail and list traffic there seems there might be other needs 
# in order to support virtual domains completely.  What do others think ?  

Alright... Since we are all so talkative today ;-) I decided to see how hard 
it might be to be able to use Perry's idea.  So over lunch I took a fresh copy
of beta-13 and added the ability for a site specify config files as follows.

Comments from ftpd.c:

/*
** Virtual Host Brainstorming:
** 
** Need to support on a virtual host basis:
** ----------------------------------------
**  _PATH_FTPACCESS  
**  _PATH_FTPUSERS   
**  _PATH_PRIVATE    
**  _PATH_FTPHOSTS   
**  _PATH_CVT        
**
** Set in a virtual site's ftpaccess file
** --------------------------------------
**  _PATH_XFERLOG  
**
** Need to support on a site basis:
** --------------------------------
**  _PATH_FTPSERVERS
**  _PATH_EXECPATH
**  _PATH_PIDNAMES
**  _PATH_UTMP 
**  _PATH_WTMP
**  _PATH_LASTLOG
**  _PATH_BSHELL 
**  _PATH_DEVNULL
*/

The ftpaccess, ftpusers, ftpgroups, ftphosts and ftpconversions files    
can all be specified on a per-domain basis.  What I have now is the
ability to override the Master WU-FTPD config files with a local copy 
specific to that domain. If you do not wish to place a copy in the 
virtual host directory for that specific host then the master copy is 
used. This was amazingly simple and I got expanded capabilities with 
less code than I had before. (Don't ask).  

The overlay/merge mechanism is not there yet. That will take more than a 
lunch to get right.  I need to clean it up before I put it up for others 
to look at it.  I'll play with it a bit more tonight.

---

From: Kent Landfield <[email-masked]>
Date: Thu, 26 Jun 1997 18:33:16 -0500 (CDT)

# > This might make sense to keep virtual domain config files separated...
# > In reviewing mail and list traffic there seems there might be other needs 
# > in order to support virtual domains completely.  What do others think ?  
# 
# It would be nice to be able to use alternate password files too, on for 
# each site. The problem with this, at the moment, is the /etc/passwd is 
# hardcoded is the libc. A possibility would be a Apache-like system, where 
# you specify the authentication file and method. You would then have the 
# default in /etc/ftpaccess, which you could override in the virtual domain 
# specific file. At the moment, different virtual hosts are not different 
# enough to my taste (if a user has an account on domain1.com and logs on 
# domain2.com, it is the same as if he logged on domain1.com, I'd like to 
# be able to change that).
# Hmmm... perhaps we could rip off Apache's code, it seems to work nicely :)

Hmmm... Ok, I'll lay the foundation and you can mortar in the stonework. ;-)

This is probably something that should come in a subsequent release.  There
seems to be enough to deal with at present. ;)  Authentication can be tricky
and I'd rather we get that right... ;-) Replacing the privilege core needs 
a focused review to do it in the proper manner.  The Apache code is not a
simple drop-in.  There are other concerns such as not affecting the non-virtual
sites, integration with Kerberos, Ultrix authentication, Skey support, shadow
password access, pam, ...

I did however add your suggestion to the suggestions page on the resource 
center so that we don't loose track of it.  I actually think it's a good 
idea, just not the right time.

---

From: Lucio de Re <[email-masked]>
Date: Fri, 27 Jun 1997 07:50:47 +0200

Mathieu Guillaume <[email-masked]> says,
> [ ... ]
My preference would be to use the "chroot"ed directory structure to
provide this functionality.  If the password file, with the configuration
files, could be accessed, on a virtual host basis, in a separate /etc
directory (delay the chroot till after the global configuration files
have been read), then the entire management becomes more feasible.

-- 
Lucio de Re ([email-masked])
Disclaimer: I'm working at getting my opinions to agree with me.

---

From: Subu Rama <[email-masked]>
Date: Fri, 27 Jun 1997 08:37:04 -0400 (EDT)

Is there an easy way to prevent the same ftp client connecting again
to the ftp server while another session is in progress ?

I am running wu-ftpd-2.4.2-beta-12

Thank you

Subu Rama
[email-masked]