Subject: So...

From: Kent Landfield <[email-masked]>
Date: Fri, 27 Jun 1997 17:04:50 -0500 (CDT)

In thinking about the merge code for the ftpaccess files I thought it
it would be easy, seemed so at first. Then came the questions phase.
Here's a couple...

When you are merging directives, what do you do with the old directives ?
Consider the 'message' directive ? When I encounter one in the virtual domain, 
does it automatically invalidate all message directives in the master ftpaccess
file ? There can be more than one message directive so do I just add it to the 
list ? That might be reasonable, but is it what you would want ? What about 
upload directives ? Does the existance in the virtual domain specific ftpaccess
file invalidate all upload directives in the master ?  Probably should but...
What would be the proper semantics for merging aliases, cdpaths, limits, 
classes, etc.

The merge code is going to be tricky.   I'm starting to wonder if its worth 
it to merge the files.  The administration of merging could get problematic 
in that it would be easy to be confused about what overrides what unless we
can make it simple.  At present it doesn't look simple.

Currently what I have is the ability to manage virtual domains totally
independent of each other with complete control over the ftpaccess, 
ftpgroups, ftpusers, ftphosts and ftpconversions files.  (Sure beats the 
root, banner and logfile support in beta-13... :))

Comments are really needed here...  At present I'm planning on cleanning up 
what I have and seriously testing it.  I'm going to put the merge code on 
hold until we can come up with some simple and understandable rules to manage
merging.  Like I said, comments, ideas, suggestions, etc are really needed.

-- 
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: [email-masked]
Date: 28 Jun 1997 19:50:51 GMT

Pink elephants with an attitude inspired Kent Landfield <[email-masked]> to tell garfield.mail.wu-ftpd:
: The merge code is going to be tricky.   I'm starting to wonder if its worth 
: it to merge the files.  The administration of merging could get problematic 
: in that it would be easy to be confused about what overrides what unless we
: can make it simple.  At present it doesn't look simple.

To make it simple we can start with the premise of:
we override anything that can be overridden!
[since I don't like the opposite: yes master, we'll use your settings].
and start finetuning from there.

Basically, if you're going to host a number of sites you can keep a couple
of things the same and some things will be different. The easiest way to
implement this is to use the master ftpaccess file and override statements
in that file with the ones from the slave ftpaccess files if those statements 
are present. 

I.e. if you have statements in the master, they apply to the slave unless you
set a different setting in the slave config. If there's a setting in the slave
that's not present in the master, then that setting gets added to the
'current setting list' or something like that.

Now for a nice decision table (Ha!):

master			slave		active config
========================================================
setting1(master)	none		setting1(master)
setting2(master)	setting2(slave)	setting2(slave)
none			setting3(slave)	setting3(slave)
none			none		chaos!^Wnone

and for the logically inclined the much shorter but not quite correct:
1 0 1
1 1 1
0 1 1
0 0 0

: Currently what I have is the ability to manage virtual domains totally
: independent of each other with complete control over the ftpaccess, 
WU-FTPD, now with Complete Control! (tm).
OUT NOW!! Don't just sit there!! Run to your favourite computer,
and surf to.. eehhmm_pssshh_kent_what's_the_url_again_?.. 
http://www.landfield.com/wu-ftpd/newvirt !!
Get it now, before you're out of fashion!
Expected for the next version: Generic Complete Control with Java-Enhanced
cookiejars! Coming soon to an ftp site near *YOU*! [1]

: ftpgroups, ftpusers, ftphosts and ftpconversions files.  (Sure beats the 
: root, banner and logfile support in beta-13... :))
Definitely.

[1] <FONT=-20>
    Standard disclaimers apply. Not fit for anything. Do not inhale.
    External use only. Keep away from kids and crackers. Could harm
    pets and the environment. Not MS certified. Rinse before drying.
    </FONT>

-- 
Perry Rovers ([email-masked])

---

From: Michael Bracewell <[email-masked]>
Date: Mon, 30 Jun 1997 10:20:56 -0400 (EDT)

Kent Landfield sez:
| 
| In thinking about the merge code for the ftpaccess files I thought it
| it would be easy, seemed so at first. Then came the questions phase.
| Here's a couple...

Just a thought -- how about some sorta file include directive?  Wouldn't
that let ya keep base (common) directives in a file that could be included
into each virtual config that wanted to use those "defaults"?

-- 
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: Mon, 30 Jun 1997 11:11:12 -0500 (CDT)

# : The merge code is going to be tricky.   I'm starting to wonder if its worth 
# : it to merge the files.  The administration of merging could get problematic 
# : in that it would be easy to be confused about what overrides what unless we
# : can make it simple.  At present it doesn't look simple.
# 
# To make it simple we can start with the premise of:
# we override anything that can be overridden!
# [since I don't like the opposite: yes master, we'll use your settings].
# and start finetuning from there.
# 
# Basically, if you're going to host a number of sites you can keep a couple
# of things the same and some things will be different. The easiest way to
# implement this is to use the master ftpaccess file and override statements
# in that file with the ones from the slave ftpaccess files if those statements 
# are present. 
# 
# I.e. if you have statements in the master, they apply to the slave unless you
# set a different setting in the slave config. If there's a setting in the slave
# that's not present in the master, then that setting gets added to the
# 'current setting list' or something like that.
# 
# Now for a nice decision table (Ha!):
# 
# master               slave             active config
# ========================================================
# setting1(master)    none               setting1(master)
# setting2(master)    setting2(slave)    setting2(slave)
# none                setting3(slave)    setting3(slave)
# none                none               chaos!^Wnone

In theory, that part I've got but now to specifics please... ;-)  Those 
directives that can be immediately overridden are listed below.  I generated 
a list of all the directives (I think) that shows whether or not those 
directive can have multiple valid entries. (I was not aware that multiple 
banners were possible... kewl)

#                   Access Capabilities
#
# Directive     Single/Multiple          Active config
# =========================================================================
autogroup         Multiple          Add too ? / Delete master list
class             Multiple          Add too ? / Delete master list
deny              Multiple          Add too ? / Delete master list
guestgroup        Multiple          Add too ? / Delete master list
guestserver       Single            Override
limit             Multiple          Add too ? / Delete master list
noretrieve        Multiple          Add too ? / Delete master list
loginfails        Single            Override
private           Single            Override

#                   Informational Capabilities
#
# Directive     Single/Multiple          Active config
# =========================================================================
banner            Multiple          Add too ? / Delete master list
email             Single            Override
message           Multiple          Add too ? / Delete master list
readme            Multiple          Add too ? / Delete master list

#                   Logging Capabilities
#
# Directive     Single/Multiple          Active config
# =========================================================================
log commands      Multiple          Add too ? / Delete master list
log transfers     Multiple          Add too ? / Delete master list

#                   Miscellaneous Capabilities
#
# Directive     Single/Multiple          Active config
# =========================================================================
alias             Multiple          Add too ? / Delete master list
cdpath            Multiple          Add too ? / Delete master list
compress          Multiple          Add too ? / Delete master list
tar               Multiple          Add too ? / Delete master list
shutdown          Single            Override
lslong            Single            Override
lsshort           Single            Override

#                   Permission Capabilities
#
# Directive     Single/Multiple          Active config
# =========================================================================
chmod             Multiple          Add too ? / Delete master list
delete            Multiple          Add too ? / Delete master list
overwrite         Multiple          Add too ? / Delete master list
rename            Multiple          Add too ? / Delete master list
umask             Multiple          Add too ? / Delete master list
passwd-check      Single            Override
path-filter       Multiple          Add too ? / Delete master list
upload            Multiple          Add too ? / Delete master list

#                   Virtual Specific Capabilities
#
# Directive     Single/Multiple          Active config
# =========================================================================
logfile            Single           Override
root               Single           Override

The questions I have are pretty basic ones. If I see a directive in a 
virtual-specific ftpaccess file, do I discard ALL previous directives 
of that type seen in the master file ? Or do I merge the new entry into 
the existing directive's list ? Or are they handled with independent 
rules based on the specific directive types ?

If we are talking about replacing all directives of the same type on first
encounter in a virtual domain's specific ftpaccess file then wouldn't it be
easier to simply have a complete copy of what we want and then simply edit 
that ?

Maybe I'm making this too complicated...

# : Currently what I have is the ability to manage virtual domains totally
# : independent of each other with complete control over the ftpaccess, 
#
# WU-FTPD, now with Complete Control! (tm).
# OUT NOW!! Don't just sit there!! Run to your favourite computer,
# and surf to.. eehhmm_pssshh_kent_what's_the_url_again_?.. 
# http://www.landfield.com/wu-ftpd/newvirt !!
# Get it now, before you're out of fashion!
# Expected for the next version: Generic Complete Control with Java-Enhanced
# cookiejars! Coming soon to an ftp site near *YOU*! [1]

:) Perry, are you in marketing ?  Can I use that ? ;-)  A visual cookiejar
metaphor could be useful for FTP archive sites. ;) :)

---

From: "Philip Kearney III" <[email-masked]>
Date: Mon, 30 Jun 1997 12:51:36 -0400

On Mon, Jun 30, 1997 at 12:11:12 PM, Kent Landfield <[email-masked]> 
wrote:

> virtual-specific ftpaccess file, do I discard ALL previous directives of 
> that type seen in the master file ? Or do I merge the new entry into the 
> existing directive's list ? Or are they handled with independent rules 
> based on the specific directive types ? 
>  
> If we are talking about replacing all directives of the same type on 
> first encounter in a virtual domain's specific ftpaccess file then 
> wouldn't it be easier to simply have a complete copy of what we want and 
> then simply edit that ? 
>  

I would argue that the master file is exactly that, the master, which is the 
defaults for every virtual domain that is being hosted.  Then, if the virtual 
domain in question has an ftpaccess file, the directives in that file override 
any defaults set by the master file.  The sequence of the daemon would then be 
to load in all directives from the master file and then load in directives 
from the virtual-specific file replacing any directives which are in the 
master file that are of the same type.  This would allow you to override only 
those defaults necessary to accomplish what the customer wants in terms of FTP 
access to his or her virtual domain.

This is at least how I'd personally like it to work.  Your mileage may vary.  
:)

-phil

----------------------------------------------------------------------------
Philip Kearney III                mailto:[email-masked] 
Sr. Software Engineer             mailto:[email-masked]
System Administrator              finger [email-masked] for my PGP key
Ascend Communications, Inc.       
Client Software Engineering Group             
----------------------------------------------------------------------------

---

From: Mitch Wright <[email-masked]>
Date: Mon, 30 Jun 1997 17:04:56 -0700

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

>rules based on the specific directive types ?
How about allowing both?  Either add a flag to toggle the behavior,
add a flag that can clear the directive, or modify the syntax so it
does clear, but if you do a "+banner" it appends.  Just an idea.

>metaphor could be useful for FTP archive sites. ;) :)
Except that the marketing end has "cookies" as being a bad word since
many people associate it with a mythical bad thing that web browsers
will do to you to ruin your life.  Funny thing is, the obvious "bad things"
the browsers do to you is distract you from work.  :-)

-- 
do svidaniya,

  ~mitch

---

From: [email-masked]
Date: 30 Jun 1997 22:05:54 GMT

[snip way too long list of options.. no program needs that many!]

: The questions I have are pretty basic ones. If I see a directive in a 
: virtual-specific ftpaccess file, do I discard ALL previous directives 
: of that type seen in the master file ? Or do I merge the new entry into 
: the existing directive's list ? Or are they handled with independent 
: rules based on the specific directive types ?
Yes. No. Duh? Too complicated dewd. (IMHO of course)

: If we are talking about replacing all directives of the same type on first
: encounter in a virtual domain's specific ftpaccess file then wouldn't it be
: easier to simply have a complete copy of what we want and then simply edit 
: that ?
No, because separate configfiles makes it clear that they really belong to a
different site and I hate extra typing. One might argue that merging is
easier then, but I just thought of another reason why merging in additional
stuff can be confusing. I'd hate to run into an ftpusers file for some site
with just 'ftp' in it. Somehow I wouldn't quite trust it. I'd prefer a
'complete' list for that and for the other files except ftpaccess.

: Maybe I'm making this too complicated...
Yes ;-)

[snip marketingspeak]

: :) Perry, are you in marketing ?  Can I use that ? ;-)  A visual cookiejar
No but I took some courses in it in a past life. :) Sure.

: metaphor could be useful for FTP archive sites. ;) :)
I think I'm going to get a ruler to hit the warez folks with
"Been grabbing in the cookiejar again have you!!??"

Oh, I propose to make the default for the shutdown parameter
the_lid_is_shut and logging erroneous login attempts with
LOG_FAIL, "Slamming down lid. The jar is closed!"

Ah, I can just hear our helpdesk:
"Ehm.. we have a customer complaining that he can't access the cookiejar?"