Subject: Re: CNAMES or Multiple IPs?

From: James McMahon <[email-masked]>
Date: Wed, 18 Aug 1999 09:38:26 +1000

Reinaldo Penno Filho wrote:
> 
> All,
> 
> in the university that i study every departament will have its own
> FTP server. There will be some 200-300 virtual FTP servers. whats the
> best solution ? Unique IP addresses or CNAMES entries in the DNS zone
> file, something like this..
> 
> www3.mydomain.net  IN   A   some.ip.address
> 
> ;
> ; Aliases
> ;
> ftp.otherdomain1.com   IN   CNAME     www3.mydomain.net.
> ftp.otherdomain2.com   IN   CNAME     www3.mydomain.net.
> 
> and so forth..
> 
> whats the pros and cons of the two schemes?
> 

The ftp daemon is unable to differentiate between connections made to
different DNS names (CNAMES), so if you use multiple CNAMES, then whichever
name you use to connect will always get you to the same server.

If you want the different virtual FTP servers to then have different ftp
root directories, then I believe that you have to use unique IP addresses,
and then set up virtual server definitions for each of them.

In either case, you are looking at a lot of fun - 200 or 300 IP addresses
on a single box, with it's associated ftpaccess file, or otherwise trying
to sort out the connections using login names or groups to decide which
part of the ftp tree that the user should be seeing.

Good luck,

James

DISCLAIMER:  I am a little out of date on wu-ftpd right now, so there may
be a better way to do things.  If there is, don't shoot me :)

> thanks in advance
> 
> Reinaldo
> 
> ___________________________________
> Federal University of Rio de Janeiro
> Computer Science Department
> 
> ___________________________________

-- 
**************************************************************************
*     James McMahon                  *     When all else fails ...       *
*     Secure Gateway Environment     *     Read the destructions.        *
*     [email-masked]          *             -- (unknown)          *
**************************************************************************

---

From: Reinaldo Penno Filho <[email-masked]>
Date: Tue, 17 Aug 1999 21:07:57 -0300 (EST)

Great, thanks for the answer.

How about flexibility of the to schemes. I want the department
administrator be able to create, remove directories, etc and an anonymous
area where he can put files to other people download (thesis, docs,
reports, etc). Is it possible for a administrator create other
administrator users? Well, I think this will happen many times, so would
be great if they have this power without having to be "root" or ask me to
do it.

best regards,

Reinaldo

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 18 Aug 1999 00:46:15 -0400

> be great if they have this power without having to be "root" or ask me to

Many of the features you're asking for are attainable using the current
2.5.0 base release.

From the daemon's point of view, however, users are handled externally.  So
there is currently no way to handle the problem in the daemon.  You may
want to take a look at BeroFTPD .. it may offer features I'm unaware of.

The way I've handled the problem is to run the daemon completely chroot'd
(before startup) so it has a completely private /etc/passwd and /etc/group
file.  I then wrote a special SSH (don't like telnet for this) shell for
use in the chroot'd environment.  Users with authorized keys in this
environment are able to run {user,group}{add,del} in this environment.
They can also {up,down}load the local user's
~/.ssh/authorized_keys so they can grant or revoke permissions on the
server.  Non-root users get another version of the SSH shell which allows
them to manage their passwords and perform certain canned operations.

In specific response to the earlier question about CNAME hosts:

There is an IETF Working Group developing a solution to this problem.  This
solution is part of the 'mlst' draft proposal (available through
http://www.wu-ftpd.org/ ).  Basically, the proposal is to add a new FTP
command, HOST, which allows the client to select the host by name after
connecting to the IP address and before authorization.  BeroFTPD supports
the HOST command, as do NcFTPD.  At this time, the only FTP client I know
of which supports HOST is NcFTP (both the Nc client and server are for-pay
packages).

The WU-FTPD Development Group has a number of plans for the daemon.  One of
those is support for the HOST command along with the other 'mlst' features
and the other FTP features described in RFCs which followed 959.  We've not
decided yet whether these features will be put into the current source or
whether they'll have to await a complete rewrite (ie., version 3.x) and
we've not yet discussed a timeline for this development.

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: JUAN ANTONIO GONZALEZ SALINAS <[email-masked]>
Date: Thu, 19 Aug 1999 09:01:57 -0500 (CDT)

Hi,

a nice feature for future releases would be support for CNAMES 
supporting different virtual ftp servers using one ip, just like in the 
http dimension with apache http server :)

what do you think?

yours, antonio

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 19 Aug 1999 10:32:46 -0400

On Thu, Aug 19, 1999 at 09:01:57AM -0500, JUAN ANTONIO GONZALEZ SALINAS wrote:

> a nice feature for future releases would be support for CNAMES supporting
> different virtual ftp servers using one ip, just like in the http
> dimension with apache http server :)
> 
> what do you think?

Yes, but.

The feature won't work since there's no client out there which support it.
IT's not yet an RFC, only an IETF Draft Proposal.  You can view the current
draft at http://www.wuftpd.org/rfc/draft-ietf-ftpext-mlst-07.txt

BeroFTPD supports the HOST command specified in this draft.  That support
is solely in support of the IETF FTPEXT Working Group's efforts.

NcFTPD (the server) and NcFTP (the client) support HOST as well.  These are
for-pay packages.  Their implementation of the HOST feature is also
experimental in support of the FTPEXT effort.

At this point, these are the only two servers and the sole client known to
support the HOST feature.

The WU-FTPD Development Group has merging BeroFTPD's implementation of the
HOST feature as one of its goals.  The feature will not be put into the
base daemon until the Draft becomes an RFC.  Implementation of HOST
requires implementation of a large number of other features which already
_are_ RFCs; obviously our first priority is to add support of the existing,
but unimplemented, features of FTP before we move on to the still-
experimental ones.  At least, this is how I see the development effort as
proceeding; another group member might decide he wants HOST now and put it
in anyway.

--

---

From: Lee Willis <[email-masked]>
Date: 19 Aug 1999 15:47:20 +0100

> http dimension with apache http server :)

Not quite the same, HTTP (At least version 1.1) supports the facility
for the client to tell the server which site it is requesting (It sends
a Host: header saying something like http://www.foo.com).  The FTP
protocol doesn't feature any such thing AFAIK so it would be difficult
for the server to know which site it should serve.

This may change I s'pose ...

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

---

From: Michael Hall <[email-masked]>
Date: Thu, 19 Aug 1999 11:15:03 -0700

> experimental in support of the FTPEXT effort.

  I know NcFTPD is 'for-pay' but I always thought NcFTP was free. Was on
their site not to long ago getting the latest 3.0beta and don't remember
seeing anything about paying for the client, what did I miss ?

--
Purranoia: the fear your cat is up to something.

Mike Hall <[email-masked]>, ICQ: #37292579, http://www.riverside.org
System Administrator (MH993) (*nix, OS/2 certified - C, Perl, CGI hacker)

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 19 Aug 1999 14:46:31 -0400

> seeing anything about paying for the client, what did I miss ?

Prolly my misunderstanding.

--