                              
                              
                              
                         FTP Serv-U
                              
                              
                 Published by Deerfield.com
                              
                              
                FTP-Server Daemon for WinSock
                              
                              
                         Version 2.4
                              










The Serv-U Web site: All you ever wanted to know about Serv-U
                and always the latest version
                              
                  http://www.ftpserv-u.com/



                              
                              
                          July 1998
                1995-1998 All rights reserved
                         Rob Beckers
           Cat Soft, an affiliate of Deerfield.com
                              



                         Disclaimer
                         ==========     
I  know, its not the nicest way to start off. So lets  just
get this part over with, OK?!

The  FTP  server  program Serv-U and  its  documentation  are
copyright Rob Beckers. It is distributed as shareware, giving
you  the  right  to try it for a period of 45  days.  If  you
intend  to  use Serv-U after the initial try-out period,  you
are obliged to pay the registration fee.

The next paragraph is a beautiful piece of prose. In just two
sentences it says it all. Alas, with all the sue-happy people
in  this world it is unfortunately necessary, so please  bear
with me.

This software is provided by the regents and contributors as
is and any express or implied warranties, including, but not
limited  to,  the  implied warranties of merchantability  and
fitness for a particular purpose are disclaimed.  In no event
shall  the regents or contributors be liable for any  direct,
indirect,  incidental, special, exemplary,  or  consequential
damages  (including,  but  not  limited  to,  procurement  of
substitute goods or services; loss of use, data, or  profits;
or business interruption) however caused and on any theory of
liability,  whether  in contract, strict liability,  or  tort
(including negligence or otherwise) arising in any way out of
the  use of this software, even if advised of the possibility
of such damage.


Contents
========

Introduction                                               

1. Making It Work - Installation                    
  1.1 Installation                                      
  1.2 Try-Out                                           
  1.3 Important Information for Try-Out via ISDN         
  1.4 Network  Installation                              
  1.5 Command Line Options                             
  1.6 Quick Setup                                        
  1.7 De-installation                                   
  1.8 Upgrading                                           
  1.9 Notes for System Administrators and ISPs        
  1.10 Known Bugs, Problems & Support                    
  1.11 A Word to the Wise (but paranoid)                

2. Using Serv-U - How To ...                           
  2.1 How to Setup Your Server                     
  2.2 How to Add a User                            
  2.3 How to Change a User                              
  2.4 How to Use Access Rules                         
  2.5 How to Setup Anonymous Access                  
  2.6 How to Use Groups                               
  2.7 How to See Who is Logged In                    
  2.8 How to Kick a User Off the Server               
  2.9 How to Setup Logging                             
  2.10 How to Use Sign-on and/or Sign-off Messages   
  2.11 How to Setup User Specific Login Messages        
  2.12 How to Use Directory Change Messages           
  2.13 How to Use Links  la UNIX                      
  2.14 How to Set Up Upload/Download Ratios            
  2.15 How to Limit Disk Usage of Users                 
  2.16 How to Limit Access by IP-Name or Number         
  2.17 How To Improve Server Performance              
  2.18 How to Print via FTP                            
  2.19 How to Execute Programs via FTP with Serv-U     
  2.20 How to Use Serv-U with SLIP/PPP Emulators     
  2.21 How to Use Netscape to Access Serv-U             
  2.22 How to Let the Whole World into Your Server (and
       Delete All Your Files)                           
  2.23 How to Use Multi-Homed IP Support                
  2.24 How to Have Serv-U Start Automatically as a System
       Service                                          
  2.25 How to Extend Serv-U with New Commands and
       Capabilities                                     
  2.26 What FTP Command Extensions Does Serv-U Support? 

3. The Inner Workings                                  
  3.1 Serv-U Internals                                 
  3.2 The SERV-U.INI File                              
  3.3 Using External User Access Verification DLLs     
  3.4 Using Event Notification and Hook DLLs           

4. Getting In Touch - Bugs & Registration             
  4.1 Serv-U Mailing List                             
  4.2 Reporting Bugs                                   
  4.3 Registering Serv-U                              


Introduction
============
Thank you for giving this program a try!

With  Serv-U, your PC will be turned into a FTP server.  This
means  that  others  on  the computer network  that  you  are
connected to (Internet for most people) can access your PC to
copy, move, make, and delete files and directories, using the
FTP  protocol  (FTP = File Transfer Protocol). This  protocol
dictates standard ways of communication between computers, so
that  many  different  types  of computers,  using  different
operating systems and file formats, can exchange files.

Serv-U  is  a  server program, also called a daemon.  The
term  daemon comes from ancient Greek mythology.  There,  the
Daemons  were  half-gods, acting as  messengers  between  the
people on earth and the gods. This FTP server acts, likewise,
as a messenger for file transfer between FTP clients and your
computer. Once started it sits in the background waiting  for
a   client  to  contact  it  and  after  communications   are
established, acting out the clients commands.

There  are  FTP  servers  (and clients)  for  many  different
systems. This particular program is meant for PCs running MS-
Windows  that  have  a WinSock version 1.1 compatible  TCP/IP
stack installed. If you can access the Internet with your  PC
it  means  you have WinSock installed and chances are  Serv-U
will work fine.

Why  use  this  program and not one of  the  many  other  FTP
servers that are available? For this I have to take you  back
in  time a little, just about four years ago. I needed a  FTP
server to make some files available to others and tried out a
number  of  server programs. One simply didnt work.  Another
would  work,  but as soon as someone started  transferring  a
file from my PC it would lock up the whole machine until  the
transfer  was  complete. And then there was one  that  worked
fine,  but lacked all but the most basic security. So,  after
endless  frustration I decided to write my own,  figuring  it
couldnt be that hard. As usual things got a bit out of hand,
but  after  a  year and 11000 lines of C++ there was  version
1.0.  The current version, v2.4, was made three years  later,
and  consists of  over 29000 lines of code. I hope  you  like
the result!

So what has this FTP server to offer?
     
     * Available  in 16- and 32-bit versions for  Win3.1,
       WFW3.11, Win95, and NT.
     * A windows standard: At the time of this writing there
       are over 9000 registered users of Serv-U, with many of those
       for multiple copies!
     * Access for multiple clients at the same time. Access for
       Anonymous users. With the possibility to limit the number
       of clients at any given time, so your PC remains workable.
     * Lots of security! On a directory and even file basis.
       Allowing different settings for each user, and by putting
       users into groups permitting easy maintenance for large
       numbers of users. There is also an option to allow  or
       prohibit clients on the basis of their IP-number or even IP-
       name. Ideal if you want to let certain people roam around
       your computer, but you dont want the whole world knocking at
       your door (that is to say: they can knock, but they wont get
       in).
     * Supports  the resume command, both for  resuming
       uploading and downloading of files.
     * Support for multi-homed IP sites that need a single
       server for servicing several IP numbers.
     * Supports upload/download ratios, disk quota limitations,
       and network bandwidth limiting so you modem or T1 connection
       will not be filled up by FTP users only.
     * Runs as a system service in Windows 95, and uses a tray-
       icon in Win95 & NT4. Can be used as a system service on NT
       with the help of the SRVANY utility.
     * Lots of other features, like configurable sign-on and
       sign-off messages, per user configurable login messages,
       directory change messages, support for UNIX ls options, and
       UNIX-style links.
     * Serv-U lets you execute programs remotely though your
       FTP client.
     * It allows transfer to or from ports, like PRN:, LPT1:,
       COM1:, and AUX:. This makes remote printing via FTP possible.
       All under the control of Serv-Us security of course.
     * A quite complete implementation of, and very strict
       adherence to the FTP standard (found in documents RFC 959 and
       RFC 1123). Supports the passive command PASV, and thus
       works well with both FTP clients and WWW browsers.
     * Can be set up to make users see the root directory (/)
       as their login directory, regardless of what their real login
       directory is. This enhances security and makes working with
       WWW browsers easier.
     * An open architecture which makes monitoring, changing
       and extending the server behavior possible through external
       DLLs.
     * Easy to setup and maintain. Everything is accessible
       through menus, and for automated maintenance the settings are
       stored in an .INI file of simple format.
     * There is lots of logging! You can select how much to log
       and where (to screen and/or file). The logfile is of a
       standard format to make machine reading easy, in case you
       need to do that for accounting purposes.
     * It is fast! The file transfer speed youll get will be
       very close to the maximum your TCP/IP stack is capable of
       (well, assuming your FTP client is at least as fast of
       course).
     * Compared to the commercial implementations, Serv-U is
       dirt cheap: around 0.1 per line of code!

If  you didnt register this program, then youre looking  at
the  try-out  version of Serv-U. When started for  the  first
time, itll let you choose between a fully functional program
or  a  somewhat  crippled one. The text during  startup  will
explain  these  options  clearly. If  you  choose  the  fully
functional  version  then there is absolutely  no  difference
with  the  registered program. But (yes, there had  to  be  a
but),  after  a little over 45 days it will switch  to  the
crippled version. Counting starts the first time you run  the
program.  I  warn you beforehand: re-installing it  will  not
help you!

And finally: A big Thanks! to all the beta testers of Serv-
U.  The  list  is  now  so long it is no longer  possible  to
mention each one individually, but you guys definitely helped
to  make Serv-U a better product! Any bugs that remain are of
course my own fault. Thanks too, to all the Serv-U users that
gave valuable feedback which helped turn Serv-U into what  it
is now.

OK,  enough  sales  talk.  Lets  continue  with  the  actual
documentation. First thing will be how to install  Serv-U  to
get you into business.


1. Making It Work - Installation
================================
Youre eager to get things going, but a little afraid of what
lies ahead. Never fear, it couldnt be simpler. So lets  get
started!

1.1 Installation
----------------
Serv-U  comes  in a zip-file which in turn contains  a  self-
extracting  executable  which is  a  deluxe  install  program
guiding you through the installation. Just unzip the zip-file
in a temporary directory and run the setup program. The same,
single,  setup  program  contains both  the  16-  and  32-bit
version of Serv-U and depending on your operating system  the
right one will be installed. After starting the setup program
follow  the interactive dialog and it will do the  hard  work
for  you. The setup program also installs a start menu  group
and  un-installer program. Once you are done you  can  delete
the  temporary directory with the original zip-file  and  the
extracted files.

The Serv-U zip-file comes with the following files:

     SETUP.EXE     - Self extracting setup utility for Serv-U
                     (both 16- and 32-bit)
     FILE_ID.DIZ   - Short description file for use by
                     bulletin boards
     README.TXT    - Last minute notes and instructions

After installation the Serv-U directory contains these files:
(some  may be missing, depending on the version you have  and
the setup options you used):

     SERV-U16.EXE  - The 16-bit version of the  FTP-server
                     executable itself
        - or -
     SERV-U32.EXE  - The 32-bit version of the  FTP-server
                     executable
     SERV-U.DOC    - The  documentation  in  MS-Word
                     version 6.0 format
     SERV-U.TXT    - The documentation in ASCII format
     VERSION.TXT   - A list of changes between the  various
                     versions
     README.TXT    - Something you have to read
     UNWISE.EXE    - The un-install program
     INSTALL.LOG   - Un-install information used by the
                     un-install program

When  Serv-U  is started for the first time, it  creates  the
files:

     SERV-U.INI    - File containing all settings  and
                     user information
     IPSERVU.TXT   - Contains  the   servers   IP
                     address(es), updated every 5 minutes

After registering Serv-U and adding the registration key:

     KEY.OLD       - Text file containing a copy  of  your
                     registration key

The 16-bit version of Serv-U uses Microsofts 3D-controls  to
make the dialog boxes look better. If for some reason you get
flat-looking dialog boxes it means that the file  CTL3DV2.DLL
is  missing.  This  file should be in your Windows  system
directory.  It  is rare if this file is missing,  since  just
about  anything these days uses it. However, if  you  need  a
copy then drop me a line. The 32-bit version uses Windows  95
style  controls. This means things will work  fine  but  look
flat on NT 3.51, this is normal. In NT 4.0 and Win95 you will
automagically get the 3D-look.

1.2 Try-Out
-----------
Serv-U offers two very distinct ways to try it out. Each with
its  own  advantages and disadvantages. When started for  the
first time (or in absence of a SERV-U.INI file), it will show
you  a screen explaining the two try-out options and allowing
you  to  choose  one  of them. The first choice  is  a  fully
functional  try-out version exactly equal to the real  thing,
but  it  will stop working after 45 and some days, or rather,
it will switch over to the crippled version. The full try-out
version  limits  your time by contacting a permission  server
over   the  Internet  every  time  Serv-U  is  started.   The
permission server keeps track of when the program was started
for the first time and uses that information to determine  if
it should be allowed to run again, or not. It then sends this
answer back to Serv-U and the program will consequently  work
or  stop.  To  this effect, a network packet is sent  to  the
permission server containing a version code, the IP number of
your  PC, ID, and a run/stop flag. It receives back the  same
packet with the flag set to run or stop. This is all that  is
communicated between the systems, nothing more, nothing less!

The  second  choice  is a try-out version  that  is  somewhat
crippled. It will only allow a total of 10 file transfers  (5
uploads and 5 downloads), it will show a message saying it is
not  registered  to  anyone who logs  into  the  server,  and
finally, it will only stay on-line for one hour. You have  to
restart  it  again  after  that  to  get  another  hour.  The
advantage  is  that it will not contact my permission  server
over the network.

Just to make sure this is clear: Once Serv-U is registered it
will NEVER send anything over the network other than what  is
needed  for  regular  FTP traffic! In short:  The  registered
program will NOT contact my permission server!

1.3 Important Information for Try-Out via ISDN
----------------------------------------------
If   your  Internet  connection  is  through  ISDN  and   the
connection  is  billed 'per minute' instead of  a  flat  rate
please  take note of the following: In case you have  set  up
your  system in such a way that it automatically connects  to
the  Internet when a program wants to send/receive packets  a
little care is needed with Serv-U.

In case you are trying Serv-U in its fully functional try-out
mode,  it  will  contact  my permission  server  when  it  is
started. This normally results in only a single packet  being
sent  out,  and  one packet coming back from  the  permission
server.  But, if you are behind a firewall, or the permission
server is down, Serv-U will not receive an answer and it will
keep retrying every 5 minutes. Meanwhile the server will work
just fine.

Well,  you  get the picture. Worst case this means your  ISDN
modem will dial up to the network every
couple  of minutes and if that goes on for a week or so  your
phone charges could get a bit out-of-hand
to  put  it mildly. The solution is to either make sure  that
you see the response message from the permission server (Serv-
U   puts  this  on  the  screen  with  the  message  "Try-out
permission obtained ..."), or use the crippled try-out version.

1.4 Network  Installation
-------------------------
To  find  the  setup information, Serv-U first  checks  if  a
settings file was specified on the command line. If  not,  it
looks  in  the program directory (i.e. where SERV-U16.EXE  or
SERV-U32.EXE is located) for the file SERV-U.INI. If no  .INI
file  is  found,  the program looks for the existence  of  an
environment  variable with the name SERV-U. If this  variable
exists,  it  should  be set to the path for  SERV-U.INI.  The
program will then use the .INI file this path points to.  For
network  use  with  a single executable shared  between  many
users  that need their own settings this is a convenient  way
to  set  things  up.  If this environment variable  does  not
exist,  the whole DOS path is searched including the  Windows
directories. If a file SERV-U.INI is found somewhere it  will
be  used,  this way also allowing for a single  copy  of  the
executable  on  a  network  server  while  having  individual
settings for each user. Finally, if SERV-U.INI was still  not
found, it will be created in the default program directory.

If  a  SERV-U.INI file is available it does not  have  to  be
writable per se. The program will work fine when it is  read-
only,  but setup changes, the current position of the  Serv-U
window,  global UL/DL ratio credit, and current disk  quota
will not be saved.

1.5 Command Line Options
------------------------
Serv-U  recognizes a number of command line options that  may
be  convenient  to  tailor  it to your  particular  use.  The
command  line looks like this (showing the 32-bit version  of
Serv-U but the same works for the 16-bit version as well:

     SERV-U32.EXE [/h] [/i] [/u] [ini-file]

Here is what they will do:

     / h      = Hide the server after startup.
     / i      = Start the server as an icon.
     / u      = Stop unconditionally.
     ini-file = path and file name of an alternative  setup
                file like SERV-U.INI

Hiding  the server makes it disappear, there will be no  icon
nor window and no way to interact with it. All you can do  to
stop  the  server after that is either kill the task  in  the
task  manager,  or  reset the computer.  The  unconditional
option  means  that  if the server is stopped  it  will  quit
without any warning, even if there are still users logged in.
This  can  be convenient if you want to be able to  stop  the
server from a script. You also need to use the /u option in
case  you are running Serv-U as a NT system service  via  the
SRVANY utility.

1.6 Quick Setup
---------------
When you run Serv-U for the first time there will be no users
and  access  will be restricted.  This section will  describe
the bare necessities to allow anonymous access. In addition
you  can  also go through the Setup menu items and  put  in
your  hearts  desires.  The next chapter  will  explain  the
various options and how to use them in more detail. You might
want to take a look at it, since the setup is simple but  not
totally intuitive (Sorry for that, I tried hard but . . .).

Now, to quickly get Serv-U up & running, just start it. Leave
all  the settings at their defaults, since in most cases this
will be OK. By design Serv-U was made to be safe out of the
box:  Unless you specify otherwise your PC is well  protected
by  the  default settings and nobody has access to it, giving
you one thing less to worry about. Right! Lets have a go  at
it.

At  this  point you have a functioning server but no  defined
users,  so  no  one can log in. To define users,  go  to  the
QSetup  -  Users section  in the menu and you will  see  the
user  setup screen with one name, ** Default **. This is  a
special name, with the default settings which are used  if  a
user  setup does not have anything. Serv-U creates it to  set
up a default user time-out value so people cannot stay logged
in  forever, but youll hear all about that in chapter 2. Now
Ill  assume  you  want  to setup your server  for  anonymous
access. To make that work, do the following:

     * Press the New button, at Name type the name we want
       to add: anonymous and press OK.
     * At Home directory, type the directory where you want
       anonymous  users to be. Lets assume we want  them  on
       d:\anonftp, so enter this (or press Browse and choose
       your favorite home directory for anonymous users).
     * Press the Add button of the File/Directory access
       rules section.
     * Anonymous users need access to their home directory, so
       enter d:\anonftp in the dialog box and press OK.
     * To hide the rest of the PC from anonymous users well
       make them see / as their home directory. To do this select
       the Miscellaneous button. In the dialog box that pops up
       check the Show path relative to homedir box.
     * While we are in this dialog box lets also set a time-
       out. Fill in a reasonable value, say 15 minutes for the
       time-out value and hit the OK button.
     * Thats all, just leave the other settings at their
       default values and press Store to save your setup.

You  now have a user with name Anonymous that can log  into
the  server.  Of  course, if you want anonymous  users  in  a
different  directory then d:\anonftp, please feel  free  to
change  this. Just make sure that the directory  you  specify
actually exist and that it is part of the access rules.

1.7 De-installation
-------------------
It  is  hard to imagine why, but if for some reason some  day
you  want to get rid of Serv-U then that is just as  easy  as
was  installing it. You have an icon in the Serv-U menu group
to  automatically remove Serv-U. Also, you can remove it  via
the  Add/Remove  Programs item of the  Control  Panel  (for
Windows 95 and NT).

1.8 Upgrading
-------------
Upgrading  from an earlier version of Serv-U is childs  play,
well, almost, there are a few things to keep an eye on.  Here
are the steps to follow:
     * If you are running Serv-U: Exit the program.
     * Make a backup of the old Serv-U files. Just in case...
     * Just follow the regular installation instructions as
       mentioned above. Make sure to install it to  the  same
       directory as where the old version was located so the old
       files get overwritten.
     
Your  old SERV-U.INI file will be used by the new program  so
you  dont  have to re-install any users. All your  settings,
and your registration key (which also resides in SERV-U.INI -
in case you registered), stay intact.

The 16-bit version of Serv-U uses Microsofts 3D-controls  to
create  a  3D-look. This is done by a file named  CTL3DV2.DLL
which should be in your WINDOWS\SYSTEM directory. Most likely
you  already have this file, and therefore it is not part  of
the  Serv-U zip-file. But if the dialog boxes look flat  then
drop  me a line and I will make the DLL available. Note  that
this is only meant for the 16-bit version of Serv-U. The  32-
bit  version will always look flat on NT 3.51! On Windows  95
and  NT  4  the  32-bit  version will use  the  built-in  3D-
controls, and thus have a 3D-look.

1.9 Notes for System Administrators and ISPs
--------------------------------------------
The self-extracting installation executable is a zip-file  in
itself  which  can be unpacked using any unzip utility.  This
lets you scan the executables in there for viruses if needed.
Also,  instead  of  the  interactive  setup  Serv-U  can   be
installed  by simply copying the executable (SERV-U16.EXE  or
SERV-U32.EXE) into its destination directory. No other system
changes are needed.

To de-install Serv-U just delete the entire Serv-U directory.
Serv-U  does  not  make any changes to the system,  with  the
exception  of Windows 95 (in some cases). In case Serv-U  was
installed  as a system service in Windows 95 it  has  added
one              registry              entry               at
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
RunServices  with the value Serv-U set to the Serv-U  path.
The  automatic de-install program removes this key if needed.
In  case Serv-U is removed by hand it is no problem to  leave
this key in place.

There  are  several ways to specify which file Serv-U  should
use  for  its  setup instead of the default SERV-U.INI  file.
Section 1.4 has the details.

There  is  a  poorly  documented feature which  might  be  of
interest to you: By adding a line to the SERV-U.INI file  you
can make Serv-U skip logging of certain IP addresses. This is
particularly  handy  in  case you are  using  software  which
periodically  checks  if the server is  still  running  (like
"WhatsUp"). More about this can be found in section  3.2  but
to  give you a quick idea about setting this up, you have  to
add  a line directly under the line with [Global] with (for
example):

     LogIPDontLog=152.3.87.16,148.78.18.1??,231.89.23-45.*

This would skip the logging of anything from 152.3.87.16, any
IP  starting with 148.78.18.1 and with two more digits at the
end,  and  all IPs between 231.89.23 and 231.89.45 which  can
have anything in their last section. Well, you get the idea.

Also  check out the add-on section on the Serv-U Web site  at
http://www.ftpserv-u.com. There are  a  number  of  utilities
which  can be very useful for system administration,  like  a
command  line  utility  to  add/change  users,  a  Web  based
maintenance utility and more.

1.10 Known Bugs, Problems & Support
-----------------------------------
At  the  time  this documentation is being written  the  only
known  bug  left in the program is the lack of on-line  help.
Everything that was found in earlier versions has been fixed.
If  you  have  any problems, please check out the Frequently
Asked Questions and discussion groups on the Serv-U Web site
(http://www.ftpserv-u.com/support.htm).

Unfortunately  there  are still a number  of  WinSock  socket
stacks that are not 100% compliant with the WinSock standard.
Since  Serv-U uses the stack to its fullest, this can  result
in  a  number  of symptoms. The following has been  observed:
directory listings and file transfers do not work; after  the
first  client  the  server seems blocked; WWW  browsers  seem
unable to work with Serv-U; the PC is blocked when Serv-U  is
transferring  a file. Take a look at the Serv-U  support  Web
site, it has a list of problem stacks.

Dynamic IP
If  you  use a modem and telephone to connect to the Internet
via a service provider, then chances are that you will get  a
different IP number each time you connect to the network. You
can  see  what  your current IP number is by looking  at  the
startup  messages  of  Serv-U: one of the  lines  is  the  IP
number. Serv-U does not have a problem with dynamic IP.  Just
make  sure  you  start the server after  connecting  to  your
service  provider,  so  Serv-U will  report  the  current  IP
number.  However, if you want to run a steady FTP site,  then
dynamic  IP  is a pain in the lower rear end! You users  will
have  to  know  which IP number to contact and  if  yours  is
changing all the time it does not help...

Your  IP number is entirely up to your provider and there  is
absolutely nothing Serv-U can do about it! It merely uses the
number  available.  So,  if you want a  fixed  (static)  IP
number  the  only person to talk to is your Internet  service
provider. Sometimes it is possible to get a fixed symbolic IP
name, even though the number varies each time (An IP name  is
something like www.cat-soft.com, you can use it instead  of
an IP number). Again, talk to your provider.

To  make life somewhat easier for those with an ever changing
IP  address Serv-U stores the current IP address  in  a  file
named  IPSERVU.TXT  in  the Serv-U directory.  This  file  is
updated  every  5  minutes  to reflect  the  most  recent  IP
address.  There  are various utilities that  will  take  your
current  IP address and update a (static) Web page  with  the
information.  This allows you to always have a  correct  link
pointing to your FTP site on a Web page. Two simple and  free
utilities  that  will do this can be found  at  the  add-on
pages  of  the Serv-U Web site, check out http://www.ftpserv-
u.com/. There are more sophisticated programs for this at the
various   program   repositories,  check  out   for   example
http://www.tucows.com.
   
1.11 A Word to the Wise (but paranoid)
--------------------------------------
Many a word has been written in the alt.winsock newsgroup  on
the  try-out enforcement practice of Serv-U, and in a broader
sense on the security of network programs. If you choose  for
the fully functional try-out version then this program will
communicate with a remote system to determine if it should be
allowed  to work or not. That is the way the 45 days of  try-
out  are  enforced. To that effect, information is  exchanged
between  your  PC and a permission server over the  Internet,
and  as people asked: How do I know that my password file  is
not  being sent over? Another, but similar question  is:  How
can  I  be  sure  there are no back doors  in  the  server,
allowing access to the author at any time? The short and hard
(but  true)  answer is: You dont know and you can  never  be
sure!

I  know this is not much of a deal, so Ill at least give you
one option to establish my good intentions. To anyone who  is
interested,  I  offer to personally go over the  source  code
with you (all 29000+ lines of it) and well compile it on the
spot. You will understand that I am not going to hand out any
source code. If you want to take that home youd better bring
along a whole lot of $$$s!

It  is worthwhile to realize that security is a problem  with
any  type  of  network  program. It  is  fairly  easy  for  a
programmer to put code into, for example, a Web browser which
will  wait  for  5  months, until the  full  moon  and  Venus
coincide, then monitor PC activity and if a user hasnt  been
present for a few hours, or if its 4 in the morning,  starts
sending  over  the  whole hard disk to unknown  destinations.
This  kind  of thing is not easy to detect, dont let  anyone
tell  you  otherwise, and I still have  to  meet  the  system
manager that keeps a network monitor running 24 hours a  day,
year  after year and actually reads the log files. The bottom
line  is  that you will have to trust the author of a program
at some point, there is no other choice!

Now dont write to me that conversely I should trust you that
"the check is in the mail and please send me the registration
key in advance"...

That is all I have to say about installing Serv-U. Next lets
look  into how we can use it to get some real work done.  The
next chapter will take you through all its features.


2. Using Serv-U - How To ...
============================
Rather than describing every menu and dialog box to its  last
boring detail, I though it would be more useful to present  a
task-driven approach. This chapter is therefore divided  into
sections that each describe how a specific task can be  done,
in the form of How to questions and answers. There is a bit
of overlap between the sections, so you might come across the
same  thing more than once. If you read this manual cover-to-
cover  then you will also have learned about every  menu  and
dialog  box  detail  in  the process.  Makes  great  bed-time
reading!

2.1 How to Setup Your Server
----------------------------
You  shouldnt believe all I say: This first section is going
to  go  over  the Setup - FTP Server menu choice  in  every
grueling  detail! No, seriously, this dialog  box  stands  so
much  at  the  basis of Serv-Us operation and the  items  in
there  do not fit very well in other sections, that it  is  a
good  idea  to cover it first, and I will only discuss  those
items that are not covered by other sections. So, lets  pull
up the Setup FTP-Server dialog box.

The first item is FTP port number. This is the (you guessed
it!)  port number that the server will listen on for incoming
FTP  clients.  The default is number 21, but youre  free  to
fill in anything you want, provided it does not conflict with
other  network programs. Filling in a number that is  already
in  use will make Serv-U complain bitterly, so thats easy to
catch.  Of course, the rest of the world expects a FTP server
to  listen  on port 21, but changing it to another number  is
one  great  way  of insuring that only you and some  selected
friends  will  know about your server. In short,  if  you  do
change  the port number to something other than 21  you  will
also  have  to tell the FTP client software to use  that  new
port number.

Second  in  line is the Maximum speed setting.  By  default
this  is  left blank which means the server will use whatever
network bandwidth it finds available. In case you do not have
a T3 network connection and want to keep part of your network
connection  available for other purposes you  can  limit  the
bandwidth  Serv-U  uses by specifying a maximum  value  here.
Keep  in  mind that even on a measly 486 Serv-U  will  easily
fill up a T1 connection to the max, so you might want to  use
this feature. Just to let you know: Instead of using a server-
wide  maximum speed setting you can also specify the  maximum
speed for specific user accounts via the user setup.

The  next  item is the Maximum no. of users. With this  you
set  the  maximum number of simultaneous users at  any  given
moment.  Setting  it  to 0 will not allow  anyone  to  enter,
leaving  it  blank will allow an unlimited number,  or,  more
precisely, until the PC runs out of network sockets or  other
resources  like memory. If you need your PC for regular  work
as  well as being a FTP server, it is probably wise to set  a
maximum so normal operations will not be slowed down too much
by  clients. You can also set up a maximum for specific  user
accounts via the user setup. More about that later.  Keep  in
mind  that the server setting for the maximum number of users
limits  the  total  of  all users regardless  of  their  user
account.

Some people have asked what would be reasonable settings  for
the  maximum number of users that would still keep the system
workable. The answer is: It depends. It depends very much  on
whether these users are local and thus capable of using up  a
large  bandwidth in data transfer, or alternatively, if these
users  are  further  away  on the  Internet  and  cannot  get
transfer  speeds  of  more than about 10 Kbytes  per  second.
Another  concern  is  the socket stack. Some  WinSock  socket
stacks  start behaving erratically when they have to  service
large  numbers  of sockets. Most notoriously is  or  was  the
first  version  of  the Microsoft 32-bit  Wolverine  stack,
which  had  the  tendency to kick the system back  to  MS-DOS
without any warning when heavily loaded. One way to find  out
how  many  users  your system can handle,  in  case  you  run
Windows 95 or NT, is to start the system monitor and keep  an
eye  on the CPU usage percentage. This will give you a pretty
good idea very fast. My experience is that even a old 486 can
handle 20 or so concurrent users with easy.

This  brings  me  to another topic which is  related  to  the
above:  Server stability is going to depend very much on  the
operating  system you are using. MS-Windows 3.1  and  WFW3.11
are  inherently so unstable that you should not expect Serv-U
to  run for more than a few days at a time before a reboot is
needed. Very much better is Windows 95, especially when  used
with  the  build-in socket stack. Having used  it  since  the
early  betas  it seems to work fine for several  weeks  at  a
time.  Definitely recommended for serious, but not-too-heavy-
duty (less than 20 concurrent users) server work! At the  top
of  the  stability list stands NT. I have been running Serv-U
on  NT for quite a while now, and it has been very stable  so
far!

Another often asked question concerns maximum transfer speeds
that can be obtained with Serv-U: Lets just say that even on
your  grandmothers 486 you dont have to  worry  about  this
unless you have at least a T3 network connection, Serv-U  can
easily saturate a T1 line (= about 1.5 Mbits per second). You
can  try  out raw speed by yourself: Just start a FTP client,
like WS_FTP on the same PC as where the server is running and
transfer some files through it. This bypasses the network, so
what  you are seeing is Serv-U plus hard disk access and part
of  the  socket stack. The conclusion from this will probably
be  that your biggest performance bottle neck is going to  be
your network connection.

For  Windows 95 users there is a checkbox which lets you  use
Serv-U as a system service. This means the server will  start
immediately  after  starting your PC, and  it  will  continue
running even when Win95 users log out and back in again.

If  you would like to leave your PC wide open for the rest of
the world you can uncheck the Enable security checkbox. But
beware:  DISABLING SECURITY WILL ALLOW ANYBODY ON THE NETWORK
TO  DELETE/CHANGE/COPY  EVERYTHING ON  YOUR  PC!!!  The  only
reason  I  put this option in is to make it easy  for  people
that have their own local network and dont want to mess with
users  and  passwords. By default this option is, of  course,
checked.  DO  NOT  EVER  LEAVE THE Enable  Security  OPTION
UNCHECKED IF YOUR PC IS CONNECTED TO THE INTERNET!!!

Next  item  is  the  Encrypt passwords  checkbox.  This  is
checked  by  default, which means Serv-U uses the exact  same
encryption  mechanism  as UNIX to store passwords  encrypted.
There  is no known way to retrieve the clear text version  of
passwords once they are encrypted. To make life for automated
addition/deletion  of  users  easier  you  can  uncheck  this
checkbox  which  means Serv-U will store passwords  as  clear
text  in the SERV-U.INI file. Please note that changing  this
option will not change Serv-Us existing passwords, only  the
way  they  are  interpreted by the server.  This  means  that
changing this option will leave existing users unable to  log
in,  unless you re-enter their passwords in the server setup.
In  other words, it is better to make up your mind about  how
you  want  Serv-U  to store passwords before  entering  large
numbers of users.

Another  on  the  list  of  checkboxes  is  Check  anonymous
passwords,  which by default is not checked. If  you  enable
this  Serv-U will check the password which anonymous  users
enter  to  log into the server. These checks are very  basic,
all  it  does is make sure the password resembles an E-mail
address  (which is the custom for anonymous passwords).  No
checks  are  done  to make sure the E-mail  address  actually
exists, only its format is checked. In case it is obvious the
password  can not be an E-mail address Serv-U  will  refuse
access  to  the  user.  Some Web browsers  (most  notably  MS
Internet Explorer) will not send a regular E-mail address  as
their  anonymous  password. To allow access for  those  using
such  a  Web  browser  you will have  to  leave  this  option
unchecked.

Next  is Block anti time-out schemes, by default it is  not
checked. Enabling this means Serv-U will use a different  way
to  count  how long a user has been idle so those FTP  client
programs  that periodically send some command to prevent  the
server from logging them out are out of luck.

This  brings  us  to  the Delete partially  uploaded  files
checkbox. By default this is not checked, which means that if
a  file  upload  goes wrong Serv-U will leave  the  partially
uploaded file on the servers hard disk. This can be good: If
the  client  support  resuming of  file  uploading  they  can
continue  where the last transfer left off. By checking  this
option  the server will delete all file fragments  which  are
the result of upload attempts ending in error.

We  now  get  to  an  item with the intriguing  label  Block
FTP_bounce attacks. To understand what this does  you  first
have  to  know  what FTP_bounce attacks are,  which  actually
delves   pretty  deep  in  to  the  mechanics   of   FTP   so
unfortunately  the story gets a bit technical.  For  any  FTP
data  transfer,  which  can be file  transfers  or  directory
listings, the server opens up a new network connection to the
client  to send that data over. There are two ways  in  which
this  can  happen,  one is called "active"  mode,  the  other
"passive"  mode.  Passive mode is used by Web  browsers  when
they  do  FTP  and  does not concern  us  when  it  comes  to
FTP_bounce  attacks. For active mode the FTP client  sends  a
PORT command to the server, and part of that command is the
IP  address  and port number the server should  use  for  the
upcoming data transfer. Normally the server does not question
this  and  dutifully connects to that address,  and  in  most
cases  this is fine. But what if the client is malicious  and
tells the server to connect to an address to which the client
would normally not have any access while the server does have
access?  This  can happen if the server is  either  behind  a
firewall  or  a  trusted  source for a  shielded  network.  A
committee  which keeps track of computer security named  CERT
termed  this  FTP_bounce attacks (CERT advisory  CA-97.27).
When  the Block FTP_bounce attacks option is checked Serv-U
does  check  the  address a client specifies via  the  PORT
command and refuses to comply unless that address points back
to the client. For regular FTP data transfers that is all the
client  will ever need to specify, so it will have no  impact
on  normal users. There is one situation where checking  this
option  may  cause problems for an otherwise legal operation:
FTP  allows direct server-to-server transfers. These actually
work  by  specifying the other servers IP address  for  data
transfers rather than the clients address. One server is put
into  passive  mode,  the  other  in  active  mode.  Now,  if
FTP_bounce attacks are blocked by Serv-U and the client tries
to  set the Serv-U end of the two servers up for active  mode
direct  server-to-server transfers will not work. As long  as
the client uses passive mode for the Serv-U side there should
be  no  problem though and server-to-server transfers  should
work (if the other side does not have some option in place to
block FTP_bounce attacks that is).

The  last  of  the  checkboxes is Use  all  lower  case  for
files/dirs, but this will only show up in the 32-bit version
of  Serv-U. The default is to preserve the case of  file  and
directory  names.  Earlier versions of Serv-U  converted  all
names  to lower case, and by checking this option you can  go
back to that. For some operating systems it is easier to have
to  deal  with only lower case, in particular if  the  OS  is
cases sensitive (like UNIX).

The  rest  of  the items in the server setup dialog  box  are
covered  in other sections of this chapter. So, just read  on
and youll eventually get to know them all.

2.2 How to Add a User
---------------------
One of the most fundamental tasks you are going to have to do
is  adding  new users. Unless you switched off all  security,
you are going to have to deal with this.

Upon choosing the Setup - Users menu option a dialog box is
presented  to you. It contains a list of all known  users  on
the  left and by clicking on one of those users you  can  see
the  settings for that user on the right side.  Now,  if  you
just  started  this server for the first time there  will  be
only  one user name in the list, named ** Default **.  This
is  a  special name with default settings used in case  other
users you set up do not have a specific setting. Go ahead and
double  click  on  the name. You will see the miscellaneous
setup menu, and the only thing in there is a default time-out
of  45  minutes. More about that later. If you are  about  to
setup  your first user press the New button and fill  in  a
user  name. Then just go ahead and type in the various fields
(password, home directory etc.).

The  next  thing can come in handy in case you  already  have
users  set up, so pay attention: You can click on an existing
user  and change the name in the User name field.  If  this
new  name  does  not exist it will be added to  the  list  of
users.  If this name exists, the settings for this user  will
be  changed to the ones in the dialog box. In short, this  is
another  way  to  add new users. So, if you clicked  on  user
James and then go on to set his password to lightbulb and
you  change  the user name to something that does  not  exist
yet,  lets  say Tanya, then you just created  a  new  user
Tanya with all the settings of James except for his password.
This  way  of dealing with users might strike you as somewhat
strange. The advantage of it is that you can take an existing
user and, by making only the few needed changes, turn it into
a new user.

Now  lets  take a closer look at the various fields  in  the
Setup  Users  dialog box. Ive dealt with the  User  name
field,  so this brings us to Group name. Every user can  be
part  of a group. The convenience in making users part  of  a
group is that you can leave common settings for all users  of
a particular group blank and just fill them out in the Setup
Group  dialog box, about which you can find more information
later  on  in the How to use groups section. This goes  for
all  settings,  including password, home directory  and  path
access  rules.  To overrule a certain group  setting,  simply
provide  one for the user. Only exception for groups  is  the
user  with  special  name Anonymous.  For  Anonymous  the
system ignores any group setting you might have. In fact,  if
you  try to enter a group for a user with that name it  wont
even  get  stored and is gone the next time you look  at  the
settings for Anonymous. This was done for security reasons.

We  did  get  ahead  of ourselves in the  discussion  of  the
various fields, so let me back up a bit. The Password field
is  of course for adding a password for a user. The passwords
are  normally stored encrypted using UNIX crypt, unless you
unchecked  the  box Encrypt passwords in the  server  setup
menu. As is normal for the crypt function, only the first 8
characters  of the password are used. Dont loose  any  sleep
over this though, it is still very safe. This algorithm works
like  a sausage machine: you put in a pig on one end and turn
the  crank,  out  comes the sausage. But,  pushing  back  the
sausage while turning the crank backwards will not get you  a
pig! It is quite secure, so far there is no known way to  get
the plain text password back (the NSA might have one though).
Once  a  password  is  stored you  will  only  see  the  word
<<Encrypted>> in the password field. This  is  to  indicate
there  is  a  password. You cannot edit  existing  passwords,
since the original is truly lost and only the encrypted  form
is  kept.  The  only  way to change it  is  by  typing  in  a
completely new one.

If you leave the password field empty this does not mean that
the  user has no password. Serv-U assumes that all users need
a  password and will try if there is a group setting and look
at  that  for the password. If no password can be found  then
access  will be denied to the user. If you truly want a  user
not  to have a password (i.e. the user name is enough to  log
in)  you can do this by filling in <<None>> in the password
field.

There  is  one  more  exception  with  passwords  that  youd
probably already know: The user name Anonymous never has  a
password. Instead, Serv-U will ask for an E-mail address.

The  Home  directory field is for the users home directory
(To  kick in an open door). This is the place where he or she
is  put immediately after logging in. Each user needs a  home
directory, without one the server will not permit logging in!
Of course, if a user is part of a group, and this group has a
home  directory you dont have to specify one here. You might
want to, if this user needs a different one from the rest  of
the  group.  Home  directories always need to  be  full  path
names, including a drive letter!

The  final field Notes is entirely for your enjoyment.  You
can  fill in whatever you like here. It is intended  to  keep
notes  about  specific users so you can later find  back  who
this is and what this person is doing in Serv-U. But, if  you
want to keep your shopping list in here please be my guest. .
.

A large portion of the Setup Users dialog box is devoted to
access   rules.   These  determine  to  which   files   and
directories a user has access. In general, you will  have  to
make  sure that the user has at least read access to  his  or
her  home directory. The quick-and-dirty way to setup  access
for a user is therefore to press Add and enter the path  of
the  users home directory. Then check the appropriate access
rights, which in this case should be at least read, list,
and  inherit,  and you have a functional account.  Although
their use is pretty straight forward in most cases there  are
still  some  ins and outs to access rules. So please  take  a
look at the section How to use access rules which discusses
them in more detail.

Obviously, clicking the Store button will store  the  newly
created user settings. But this is not the only way: You  can
also  leave  the setup screen by pressing OK,  any  unsaved
changes  will  be stored as well. Also, if you  already  have
other  users set up, clicking the mouse on another user  name
will save changes.

We  already came across the special user name Anonymous  to
allow  access  without a password. The  user  name  FTP  is
understood  by  Serv-U as a synonym for Anonymous.  When  a
user  enters  FTP it will be translated to Anonymous,  so
the  latters settings apply to FTP as well. There  is  one
more  user  name with special meaning to Serv-U,  we  already
came  across it a few times previously: ** Default **.  Now
where does this tie in? Well, every action requiring security
clearance   (checking  a  password  during  login,   reading,
writing, etc.) is first checked against the settings for that
particular  user. If no appropriate setting is  found  there,
and  the  user belongs to some group, the group settings  are
checked. If still no corresponding setting is found, the user
**  Default ** is consulted (if it exists). So **  Default
**  works  as  a blanket for all users, providing  the  most
common  settings. Of course, this also provides a potentially
big security hole, so be careful what you put in there!

Most  of  the other buttons and items are explained in  other
sections,   but   lets   go  over   the   details   of   the
Miscellaneous dialog box here. If all you want is to set up
simple FTP access you probably can ignore almost anything  in
there. The miscellaneous items let you fine-tune some details
that  might be useful.  Just press the Misc button  to  get
into it.

If you want to disable the account of a user so he cannot log
in without deleting it, this is done by checking the Disable
account checkbox. A tip: This also works in a group, so  you
can  disable  an  entire group of users with a  single  mouse
click!

The  next item, Show path relative to homedir can  be  very
useful  and powerful, but there are some snags to it  so  pay
close attention: When this is enabled Serv-U will try to show
all the directories a user deals with as if they are relative
to  the  users home directory (Hence the name). For example,
if  a  user has home directory c:\users\anonymous, this would
show   up   as   /   to  the  user.  If   he   changed   to
c:\users\anonymous\uploads all hed  see  is  /uploads.  It
completely hides the real path with drive, and makes the  FTP
client believe it is in the root of the file system. This can
be great in many cases, but there are also potential problems
to it. Serv-U can only do this trick for directories that are
either  at  or  below the home directory  of  the  user.  For
example, if the homedir is c:\users\anonymous again, there is
no  way  that Serv-U can represent e:\pictures\furry relative
to  that.  In short, with relative paths enabled  the  user
will  not  be able to go outside of his or her home directory
(and the directories below the homedir).

By  checking  Hide hidden files Serv-U will  not  show  any
files  that  have  the file attribute hidden  in  directory
listings. This is useful for hiding directory change  message
files  and  link  files.  By  the  way,  you  can  also  hide
directories  with this same mechanism, just set the  hidden
attribute for the directories you dont want to show.

The next checkbox, Always allow login, lets you control  if
a  user  should be allowed to log in even after  the  maximum
number  of  users  has been reached. This  is  good  for  you
yourself, as the system administrator. It would let  you  log
into your own server at all times.

The  checkbox Only allow one login from same IP address  is
for  those with a popular FTP site. So popular that users log
in multiple times to keep the downloads of those JPEGs going.
By  checking it you force your users to a single login  at  a
time.

The  last one in the list is Allow user to change password.
By  enabling  this  option Serv-U will allow  the  client  to
change  the  password.  Serv-U has an extension  to  the  FTP
commands  which lets the FTP client program change  a  users
password  (if it knows the old password), but this will  only
work  if  the client supports this command. This is a  Serv-U
invention  and not part of the standard, so at  the  time  of
this writing the only client with native support for password
changes  is  FTP Voyager from Rhino Software. With  a  little
luck  other  clients will pick this up soon though  (ask  the
maker  of  your favorite client to get in touch  with  me  at
Rob@cat-soft.com if you want them to support it)!

Now,  if  you want to keep your PC available for  other  work
while  those  JPEGs are flowing you can use the  Max  speed
setting to limit the bandwidth the user can use. Leaving this
field  blank  will  allow users to use as much  bandwidth  as
available  (or until the server-wide speed limit is  reached,
set  up in the Setup - FTP-server menu). The value you  put
here  is the maximum each user will get. So, say you fill  in
10  for user Anonymous. This means that each user logging
in  as  Anonymous will get a maximum speed for  uploads  or
downloads of 10 Kbytes per second.

Idle time-out is the time in minutes Serv-U will let a user
twiddle  their thumbs. If no activity occurs for this  amount
of time the user is logged out. Be reasonable, and try not to
go  below 5 minutes or you run the risk that clients  with  a
poor Internet connection wont be able to transfer any files.

Then  we have Max. no. of users which lets you specify  how
many  users  should  be allowed to log in concurrently  using
this  account name. So, to keep the number of anonymous users
down  to  25  at a time you would put 25 in here  (for  the
Anonymous  account).  There are two  other  settings  which
affect  the  number  of concurrent users:  If  Always  allow
login  is checked the user limit is ignored. Then  there  is
the  server-wide  user  limit in the setup  -  server  menu
choice  which  has the final say over the maximum  number  of
users regardless of what you put in the user setup.

This brings us to the Login message file field. You can put
a  file  name of a text file in there. The contents  of  this
file  will  be displayed to the user just after  logging  in.
More  about  this  in  How  to  setup  user  specific  login
messages.

Worth  mentioning at this point might be that you can control
who is allowed to log in for each user name by IP-name or IP-
number via the IP-access button. The details on how to  use
this can be found in the section about how to limit access by
IP-name or number.

This  should  get you started in creating user  account.  The
next  section  gives  you  a few details  on  how  to  change
existing user accounts.

2.3 How to Change a User
------------------------
For  the  most  part  the things mentioned  in  the  previous
section,  How  to add a user, also apply to  changing  user
settings. However, there are a few peculiarities that deserve
extra attention.

First  of  all,  keep in mind that you can  change  a  users
settings  at all times in the Setup Users dialog box.  This
includes  the users name, but care should be taken in  doing
this,  since there might be side effects: If you  change  the
name  to a non-existent one and store the settings this  will
in  effect  create a new user with that name.  Also,  if  you
change  the  name  to one that already exists  then  you  are
changing the settings for the user with that name! To  parade
our  favorite example once more: Lets say you want to change
the  password of user James. So you clicked on James  and
then  go on to set his password to lightbulb and you change
the  user  name to that of another user, lets  say  Tanya.
Then  Tanya  is going to be mighty upset when  she  tries  to
enter  your FTP server! James will of course have to remember
his old password, since nothing changed for him.

Another peculiarity that can come in handy is when changes to
user  settings get stored. There are several ways to do this.
Obviously clicking on Store will do the trick. Another  way
is to press OK and leave the user setup. This will save any
changes  too. The third and last way to store changes  is  by
simply  selecting another user from the list on the  left  of
the  Setup Users dialog box. Up until you store changes you
can  recover  the  original  settings  by  the  pressing  the
Restore button. This does not hold for the Delete button.
Pressing  this  will erase the selected user  completely  and
there is no way to get it back (Im a nice guy, so youll get
warned first when attempting this)!

If  youre  editing an existing user who has a password,  the
word  <<Encrypted>> will be shown in  the  password  field.
This  indicates there is a password, as opposed to not having
a password in which case this can be supplied by the group or
default  settings.  There is no way to recover  the  original
password,  once  entered  it  is  lost!  So,  there   is   no
possibility to edit the existing password, you can only enter
a   completely   new  one.  To  do  this,  erase   the   word
<<Encrypted>> completely and type in the new password.

Something that might be of interest to you if you edit  users
by  directly changing the SERV-U.INI file using your favorite
text editor (for example, Notepad will do): Any changes you
make  to  users take immediate effect. No restarting  of  the
server is needed. This means that you could keep a local copy
of  your  INI file and use a local version of Serv-U to  edit
it.  Then  just use Serv-U itself for uploading  the  changed
SERV-U.INI file to the production site and you are all set.

That  concludes all you need to know for keeping your  users
settings  up-to-date, but it is time to fill in a  big  blank
that is of the essence to using Serv-U: The access rules.

2.4 How to Use Access Rules
---------------------------
The Access rules part in the Setup Users dialog box forms
the  corner stone of Serv-Us security. This is also the part
that  makes  Serv-U unique: It allows very fine control  over
what   a  user  can or cannot do. It allows  you  to  specify
access per directory and even per file for each user!

How  does  all  this work? Take a look at the File/Directory
access rules list in the Setup Users dialog box. This list
should  contain  a  number of paths with  access  information
coupled  to  each  path. Access to the  PC  is  only  allowed
according  to  these paths and their access  information.  No
access  path,  no  access! So, there is one  path  you  might
always  want  to put in the list: The users home  directory.
The  check boxes at the right of the path list show what kind
of access the user has to the path in the list. Again, unless
the type of access is specified in these check boxes the user
wont get in.

Lets  take  a  look at the different type of access  we  can
specify  per  directory or file. There  are  eight  different
types  of access information that can be set, four that apply
to  files,  three for directories, and the final  one  has  a
special meaning. To start with file access:

     * Read  access, allows files to be copied from  the  PC
       using the FTP get command.
     * Write  access, allows files to be copied  to  the  PC
       using put, but not changed, deleted, or renamed.
     * Delete access, allows the user to change  files,
       rename, or delete them. Having Delete access automatically
       includes write access (although it does no harm to specify
       both).
     * Execute access, is meant for executing files through
       FTP, i.e. for running DOS and Windows programs remotely.

Then there are three items that deal with directories:

     * List access, allows the user to retrieve a directory
       listing using the FTP dir command.
     * Make access lets the user create new directories at
       this path, i.e. the user can make subdirectories.
     * Remove allows the user to delete directories.

The final item is somewhat special:

     * Inherit means that the access rule automatically
       applies to all subdirectories of the path, i.e. the rule is
       inherited by subdirectories.

Most  of  the above should be no surprise to you,  but  lets
take  a  closer look at a few of the less clear items. First,
to  allow a user to use the change directory FTP command to
get  into a directory any of the rights is sufficient. So,  a
user  that has read, write, delete, execute,  list,
make, or remove can change to the directory in the access
path.  Conversely, if a path is specified without any  access
rights  (except  maybe for Inherit) then the  user  has  no
access what-so-ever to this path.

A  user has write access to a file or path, but no delete
access, can upload files to the server as long as they do not
exist  already. This is good for an upload directory, because
it  allows  uploads without the chance of changing previously
uploaded files.

Execute access is meant for remotely starting programs  and
usually  applies  to specific files. Be careful  in  granting
this right: For example, allowing a user to start COMMAND.COM
also  means that this user can delete anything on  your  hard
disk! More on using this in the How to execute programs  via
FTP with Serv-U section.

If  you want a user to be able to see a directory listing you
need  to specify list access. This can also be used in  the
opposite  way: For example for an upload directory you  would
want  a  user  to be able to upload files, but  not  see  and
certainly  not download anything that is already there.  This
could  be  done  by  only specifying the write  right,  and
leaving list access unchecked.

A  somewhat strange attribute in the list is inherit.  This
does  not  so much say anything about access for a path,  but
how that access rule works for subdirectories. When inherit
is  checked  the  rule will automatically be  valid  for  all
subdirectories  of  the  path  in  the  rule,  as  if   these
subdirectories  inherit  the access  rule.  This  is  usually
convenient, it means that with a single access rule  you  can
control access to a whole branch in the directory tree. Also,
if a user is allowed to create subdirectories, they will have
the same access rights as the parent if inherit is checked.
In short, you are going to want to leave inherit checked in
most  cases,  but sometimes it can be convenient  to  specify
access  for  a  single directory in a tree without  affecting
subdirectories  and thats when unchecking  it  can  come  in
handy.

When  a  user  executes an FTP command  concerning  files  or
directories, the users access path list is checked to see if
the  command should be allowed to proceed. Now pay very close
attention,  this  is  the part of Serv-U  that  seems  to  be
causing  most confusion: The list is evaluated  from  top  to
bottom, and evaluation stops as soon as an applicable rule is
found. Applicable means that if it is a file the user wants
to  do something with, then the file name must appear in  the
access path list, or the directory of the file must be in the
list,  or finally, a parent directory of the file must be  in
the path list with inherit checked. Directory access uses a
similar mechanism. It follows from this, in big bold letters,
that  THE  ORDER  OF  THE PATH ACCESS RULES  IS  IMPORTANT!!!
Unless  the access rules are in the right order you will  not
get the result you want!

Since  one  example  can say more than a thousand  words,  or
something  along  that  line, lets work  through  a  typical
situation. Assume you want to setup an Anonymous FTP  site.
This  needs a directory tree with all the goodies  the  users
might want to download, for which they need read access.  You
also  need  an  upload directory where users can  upload  new
goodies,  but you dont want others to be able to immediately
get  their greedy fingers on it, since you want to check  for
viruses first. So, this upload directory needs write  but  no
read  access. We decide to put everything on the big  network
drive,  Y:, under the ANONFTP directory. We  also  create
the  UPLOAD directory here for uploads. In Serv-U we  would
create  the  user Anonymous with the following access  path
rules (and in this order):

     Y:\ANONFTP\UPLOAD   - write, inherit rights
     Y:\ANONFTP          - read, list, inherit rights

Reversing the rules will not work: If a user tries  to  write
to  the  upload directory, the security mechanism will  check
against   Y:\ANONFTP   and  conclude   that   UPLOAD   is   a
subdirectory,  so  the  rule  applies  because  inherit  is
checked,  and  the  rule grants only read  and  list  access.
Please  take note that write access does not allow a user  to
get  a directory listing of the UPLOAD directory, so not only
wont  a  user be able to download anything from  there,  the
user cannot even see what files are uploaded.

If  the drive letter is left out of a path, it applies to all
drives. So, a fast way to get full access to all files on all
drives is:

      \                  - read, write, delete, list, make,
                           remove, and inherit rights

Now, the same mechanism that determines access to directories
also  applies  to  files. It is possible to grant  access  to
specific  files on a per-file basis. Lets take the  previous
example about the anonymous FTP server. We want to put a file
SECRET.TXT in the ANONFTP directory, but nobody is  allowed
to  read  it of course. So, our access paths list would  look
like this:

     Y:\ANONFTP\SECRET.TXT - no rights
     Y:\ANONFTP\UPLOAD     - write, inherit rights
     Y:\ANONFTP            - read, list, inherit rights

Again,  the  order of the paths is important!  The  directory
access   rights   do   not  have  any  meaning   for   files.
Alternatively,  if SECRET.TXT was a directory  instead  of  a
file,  the above settings would keep users completely out  of
this directory. Serv-U will hide all files and directories  a
user  does  not have list access to. They dont  show  up  in
directory  listings, so in the above example  the  SECRET.TXT
file  would  be  truly secret. Not a trace in  the  directory
listing.

So  far  we  have only looked at regular paths in the  access
rules  list  (except maybe for the special case of  \).  To
make it even more flexible, Serv-U also supports wildcards in
access   rules.  An  example  to  illustrate  some   of   the
possibilities:

     Y:\ANONFTP \SECRET.TXT   - no access
     Y:\ANONFTP \*.TXT        - read, list, inherit
     Y:\ANONFTP \??BRA        - read, list, inherit

The  second  rules  makes sure the user only  sees  file  and
directory  names ending on .TXT, nothing else.  Access  (read
access)  is also restricted to these files. On top  of  that,
the  file SECRET.TXT is not shown and the user has no  access
to  it.  Finally, the last rule will show and give access  to
anything  ending on BRA with no extension and two  characters
in  front of it. So, if there is a directory named ZEBRA  the
user  will  see it and have access to it. Note that  just  as
before  the  order of access rules is very important.  Serv-U
looks  at  them from top to bottom and stops as  soon  as  an
applicable rule is found.

2.5 How to Setup Anonymous Access
---------------------------------
Since setting up anonymous access is such a common task  when
running a FTP server, I want to present a separate section on
this  subject. It is not much different from setting  up  any
other user, so this is going to be a follow the recipe kind
of instruction, with the specifics for anonymous thrown in.

First,  a  tip:  If you are running Windows 95  it  might  be
worthwhile to create a new DriveSpace 3 volume with all the
files  you  want to make available for anonymous FTP  access.
This  not only provides you with a lot more space due to  the
compression  (which at regular FTP speeds has  no  impact  on
performance),  but also effectively isolates the  users  from
more sensitive areas like your C: drive. So, for the rest  of
this story I will assume you just created a DriveSpace volume
named F:.

Lets say all the good stuff for our users is going to be  in
subdirectories of F:\ANONFTP, and we want to allow uploads of
new files to the F:\ANONFTP\UPLOAD area.

The  first task in setting up anonymous access is creating  a
user  with  this name. Thus, go ahead, pull up the  Setup  -
Users menu and its dialog box. Fill in the Username  field
with Anonymous. The Group name and Password fields stay
blank, since they are ignored for anonymous anyway. Now,  the
Home  directory  field needs to be set to F:\ANONFTP  since
that  is  the point we want the users to start when they  log
in.

Were  almost there, but the users still need access to those
directories.  So click the Add button and  enter  the  path
F:\ANONFTP.  When this is done the access rights are  already
set,  since the default of read, list, and inherit  are
exactly  what  we  want. Now for the upload directory:  Click
Add  again and fill in F:\ANONFTP\UPLOAD. Serv-U will place
this above the previously entered access rule, which is good.
However,  the access rights are not exactly what we want,  so
uncheck read, check write and uncheck list. You  should
now  have the following two access rules in the list (In this
order!):

     F:\ANONFTP\UPLOAD   - write, inherit rights
     F:\ANONFTP          - read, list, inherit rights

This  is  all we have to do in the Setup Users  dialog  box
itself,  but  there  are  some things  in  the  miscellaneous
section that are useful, so press the Misc button. Once  in
there, check  the Show path relative to homedir button. It
causes anonymous users to see all directories and path  names
relative to their home directory. So, if your anonymous users
have  F:\ANONFTP as their home directory, they will receive
back  /  when  they  inquire with the PWD  (=Print  Working
Directory) command. Similarly, every reference they make to a
file or a change of directory is taken relative to this path.
The  main  reason it is in there is because most WWW browsers
need  change directory access to the / (=root)  directory
to  make them work. This way they believe they have access to
the  root and are happy, while on a PC you dont always  want
to  give  users  access  to  your real  root  directory.  The
disadvantage of having this mechanism is that anonymous users
are restricted to their home directory and below, nor do they
have  access to other drives. Sometimes you want them  to  be
able  to  have access outside their home directory  tree  and
unchecking this option will allow that. Anonymous users  will
then be treated like any other user as far as path names  are
concerned  and they will be able to change to parallel  paths
and  other  drives  if their access rights permit  this.  The
price  you pay is that unless you provide some form of access
to  the  root  of  their home directory, i.e.  F:\  in  our
example, WWW browsers wont be able to log in.

While  we  are in the miscellaneous options dialog box  lets
also   set  up  a  few  other  things.  We  dont  want  hung
connections  to remain in the server forever.  To  make  sure
they  get the boot we need to add a value for the Idle time-
out  field. 15 minutes should do fine for most cases,  still
allowing  slow  transfers and bad connections to  work  while
keeping  the  server reasonably clean of all  those  Netscape
users  that stay logged in after their transfer is long done.
We  also  dont  want our server to be overrun  by  anonymous
users,  which means there needs to be a user limit. To  stick
with  our example of a small FTP server on Windows 95 with  a
modem  connection we set the Max. no. of users limit to  10
users.  Of  course,  if you have a better network  connection
feel free to put in whatever you think is reasonable.

When they log in we want to let them know the especially good
things and give them instructions on how to upload, and to do
that we need a login message file. Netscape will show such  a
message  in  a  very nice way, at the top  of  the  directory
listing.  So, lets create a file named LOGANON.TXT with  the
following contents:

     Welcome %name from %IP!
     For the latest in natures feline beauty see directory IMAGES
     You can hear them in the directory MEOW
     Please keep uploads smaller than 100 Kb and place the in UPLOADS

Since  I  can imagine that not everyone envisions  cats  when
hearing  about pretty pictures please feel free  to  change
the  text  according to your wishes! The words starting  with
%  are directives to Serv-U which will be replaced by  real
text  when the user logs in. %name becomes the users name,
and  %IP  either the IP number or the IP name of  the  user
(whichever  is available). There are many more % directives
and you can find more information about these in the How  to
use sign-on and/or sign-off messages section.

Now  lets  place the file LOGANON.TXT in F:\ and thus  enter
F:\LOGANON.TXT in the Message file field.

To  store  our  settings press OK, and in  the  user  setup
dialog box press Store.

The last item we need to concern ourselves with for anonymous
users  is the Check anon. passwords option in the setup  -
server menu. By default this is unchecked, which means  that
anonymous users can type anything as a password to get into
the server. If this option is checked, then Serv-U makes sure
that  the  password entered by anonymous users is something
that looks like an E-mail address. Netiquette prescribes that
anonymous users send their E-mail address as a password, alas
this  good custom is disappearing fast and some WWW  browsers
do  not  even have the ability to do this anymore. So, unless
you  want  to severely restrict access and teach people  good
manners it is probably best to leave this unchecked.

Just  so  you  know: As is customary for FTP servers,  Serv-U
also  looks for a - (hyphen) as the first character of  the
anonymous  or regular users password. If present, all  login
and directory change messages are suppressed.

Well,  you made it through and now know just about everything
there  is to know about setting up anonymous access  at  your
server. You can enhance things further with sign-on and sign-
off  messages, directory change messages and links, which are
covered in the following sections.

2.6 How to Use Groups
---------------------
To ease the burden of maintaining a large site somewhat, Serv-
U  uses  the  concept of groups. This allows you  to  group
together  users  with similar settings. All the  similarities
are  stored  in  the  group  information,  leaving  only  the
differences per user for you to set up.

To  edit groups select the Setup - Groups menu choice.  The
dialog box you see should look familiar by now: Its the same
one  as  for the user setup. So, if you know how  to  set  up
users, you also know how to set up groups! The only item that
is not applicable for groups is the Username field, so this
is  grayed  out,  instead you use the Group name  field  to
specify the name of the group you are editing.

To  show  the power of groups a quick example: Lets say  you
are  the Pentagon system administrator and want to create FTP
access for everybody in case they are on field trips. So, you
hook  up  this old PC to the net, install Serv-U and register
it  (Hypothetical situation). Then you proceed  to  create  a
group StarWars. Now you go on to set the password for  this
group to RonaldR, and their home directory (all their files
are shared anyway) to y:\super\secret\starwars. You fill in
some  access path rules as well, and youre all set: The only
thing  left  is  entering the user names, you dont  have  to
provide any other information per user. A 10 minute job.

Now  theres this occasional guest user, BillyC. You  dont
want  him to get into certain directories, so you make him  a
member  of the group but specify those secret directories  in
his access path rules with no access, and youre all done.

As  you  already  saw  from  the previous  example  the  user
settings have precedence over the group settings. This allows
you  to  selectively  override certain  parts  of  the  group
settings,  making groups a very flexible mechanism  for  user
maintenance.  To  summarize: Serv-U first checks  the  users
settings, then looks if the user is part of a group and if so
uses  this groups settings, and finally, if nothing is found
yet  the settings of ** Default ** are used if they  exist.
The  only  user that cannot be used together with a group  is
Anonymous.  For  security reasons only  the  user  settings
themselves are looked at for anonymous access.

In  case you use group settings to specify matters like  disk
quota and upload/download ratios, those will still be counted
for  each user name individually. For disk quota for example,
all  users that are members of that group will inherit  the
group  settings,  but each user of the group  will  have  its
individual  counts for the current value. I know, not  really
what you would expect from group settings, but the result  of
the  internals of Serv-U. The plan is to make a better  group
mechanism in a future version.

Well, by now you know most of what there is to know to run  a
smooth Serv-U FTP server. The next sections are mostly  about
goodies  that make life easier or more colorful. Next  youll
learn how to find out what users are doing on your server and
if they are nasty, how you can boot them off.

2.7 How to See Who is Logged In
-------------------------------
Even  though Big Brother might not be watching you,  you  can
certainly  watch your users! Select the File  -  User  Info
menu  choice  and  up pops the user information  window.  The
upper  part shows a list of all users currently connected  to
your  server. By clicking with the mouse on one of the  users
you  can  get extra information about that user in the  lower
part  of the window. While helpful the user info window  also
gobbles up CPU time and will degrade server performance. This
does not really matter if all you have is a dozen users on  a
modem line, but it does matter with a T1 connection.

There  are  a  few  things  to keep in  mind  concerning  the
displayed  statistics: The IP name is found by  initiating  a
reverse DNS lookup of the IP number. It can take time  before
an answer comes back from the DNS server, and there are quite
a  few IP numbers that do not have an IP name. So, it is  not
at all unusual for a user not to have an IP name.

The   transfer  speed  displayed  should  not  be  taken  too
absolute.  Since the socket stack buffers any  send  activity
(Serv-U can write lots of bytes to the stack in a very  short
time, after which the stack sends it off at its leisure)  the
indicated speed can be much higher than it actually is. Also,
if  there are local transfers going on with a very high speed
then Serv-U and the socket stack can get into a tight loop of
sending or receiving, and the user information might not  get
updated  for  some time. This is normal ("Not a  bug,  but  a
feature!"). Last but not least, you can resize the height  of
the  user  info window to show more or less users by dragging
the  upper  or lower edge of the window with the mouse  using
the left mouse button.

This  brings  us to the Spy on User button.  Pressing  this
will  pop up another window which will show you all  the  FTP
commands  the  user  sends and the replies  from  Serv-U.  It
tracks  the commands of the in User Info selected user  and
by clicking on another user you can switch.

The  last  button of interest in this window has the  prosaic
name  Kill  User. This is the place where, if so  inclined,
you  can  alleviate all your frustration after a particularly
bad  day  at the job. For that reason the entire next section
is devoted to it.

2.8 How to Kick a User Off the Server
-------------------------------------
If  someone is doing things you dont like, or you just  want
to be mean, Serv-U offers you the option of kicking that user
off your server and keeping him or her off.

This is done by selecting the File - User Info menu choice.
In the window that pops up as a result you select the user-to-
be-killed,  and proceed by pressing the Kill  User  button.
This  will  pop up a little dialog box asking you  if  youre
really sure about this, and offering several options to  keep
the user in question off on a more permanent basis.

You  will  see two checkboxes and a line with the  users  IP
address.  The first is Refuse IP access in future.  If  you
check this and then press OK the users IP address will  be
added to the list of IP numbers that are refused access. This
will prevent that user from logging in again, or at least not
from  the same IP number. You are free to edit the users  IP
address. For example, for users with a dynamic IP address you
might  want  to  change the last number to *  to  keep  out
future attempts. We will talk about access and IP numbers  in
greater  detail  later, in the How to  limit  access  by  IP
number section.

The  second  checkbox is Disable account and checking  this
does  exactly  that: The Disable account  checkbox  in  the
Setup  -  Users - Miscellaneous dialog box will be  checked
for  this users name. Nobody will be able to use that  login
name until the account has been enabled again.

2.9 How to Setup Logging
------------------------
When  you  select the Setup - Logging menu choice you  will
see  a dialog box that lets you specify what events you  want
to  log and where to log them to: either to screen only or to
both the screen and a logfile.

The first two items deal with logging to a logfile. The first
one,  Enable logging to file switches writing to a  logfile
on  or  off. The second item, Logfile is meant for entering
the  path  and  file  name into which all  the  messages  are
written.  Of  course, logging will only  work  when  a  valid
logfile  name  is  entered, it has to be  a  full  path  name
including a drive letter.

Serv-U  gives you a wide choice in what should be  logged  or
not, and you can specify different logging options for screen
and  file.  In all there are seven different categories  that
can  be individually enabled or disabled. The items are  self
descriptive except maybe for four: The Log IP names  option
will  try  to find the users IP name by doing a reverse  DNS
lookup of the IP number. As soon as the name is available  it
will be logged (not all IP numbers have names associated with
them).  Log  FTP  commands logs  every  command  as  it  is
received by the server and Log FTP replies logs the command
replies  that  are  sent back by the server  to  the  client.
Finally there is the Log WinSock activity option. This will
log every WinSock socket stack function call and some related
items like socket stack messages. If you really want to  know
what  is  going on deep down below it will tell you,  but  be
prepared  for  a  huge amount of log info. These  last  three
options  are mainly intended for diagnostic purposes and  are
switched  off  by  default. Since logging at  that  level  of
detail  slows things down more than a little it  is  probably
best to leave them off.

You  can  select which type of messages should be  logged  to
screen and which to the logfile. There are a number of system
messages  which  will always be written to  the  log  window,
regardless  of  your  selection.  These  are  mainly   status
messages  to  tell you if the server is working properly  (or
not), mostly at server startup.

Log  messages  always have the same layout.  The  reason  for
using such a strict format is to make it easier to search for
specific  messages  or certain types of messages.  This  also
makes  it  possible  to  do automatic accounting  by  machine
reading  the logfile if you need it. The format is  as  shown
below, in stylized form:

     [n] DATE TIME - (xxxx) MESSAGE

The first number, n, indicates the type of message that  is
being logged. Currently there are seven different categories:

     1    - system messages (problems etc.)
     2    - FTP commands (from client to server, mainly for
            diagnostics)
     3    - GET file transfers
     4    - PUT file transfers
     5    - security related events (users logging in etc.)
     6    - FTP replies (from server to client, mainly  for
            diagnostics)
     7    - WinSock socket stack activity (only  used  for
            diagnostics)

The  second  number, xxxx, is a unique  ID  assigned  to  a
client  the  moment  the  connection  is  made.  All  further
messages  concerning that client will use  the  same  number.
Again,  this  was  done  to  make it  easy  to  do  automated
accounting,  or,  to  find  back events  using  the  search
facilities of every editor.

The  logfile  can be read, renamed or copied at  any  moment,
even  when Serv-U is running (It is also possible to download
the  file  via FTP using Serv-U itself. There is no  need  to
stop  the server. If you want to temporarily stop logging  to
file  and see it on screen only, you can uncheck the File  -
Logging option in the main menu. Needless to say this has to
be checked to enable logging to file again.

One more note: If you log GETs and PUTs (i.e. downloading and
uploading  of  files)  then Serv-U will  also  tell  you  the
average  transfer speed. For GETs the value Serv-U shows  can
be  a bit optimistic, especially for small files, as a result
of  the  socket stack buffering the bytes that are sent  over
the  network.  Serv-U can very quickly transfer 10-20  Kbytes
into  the socket stack, which then proceeds to send  it  over
the network at its own leisure. However, Serv-U has no way of
finding out when the actual transfer is complete, and assumes
that  when  it has sent the block to the socket stack  it  is
done.

Enough boring talk, lets get back to the fun part! Next will
be  explained how you can pour your heart out to  your  users
through all kinds of messages.

2.10 How to Use Sign-on and/or Sign-off Messages
------------------------------------------------
Your  FTP-server can display a welcome message every  time  a
user connects to it. This can be very useful to provide users
with  information about your FTP server, like where  to  find
games, or Serious Software. Likewise, you might want to say
good-bye to them when they leave, or remind them to send that
check  . . . The way to do this is by entering a text in  the
Sign-on/Sign-off dialog box which pops up when  you  choose
the Setup - Signon/off menu choice.

There  are several special words that you can enter  in  your
sign-on and sign-off text which get expanded while being sent
to  a  client. They all begin with %. Here is the  complete
list:

     Time/date:
     %Time          - displays the current time on your PC
     %Date          - displays the current date on your PC

     Server statistics:
     %ServerDays    - displays the number of days  the  server
                      has been running
     %ServerHours   - displays the number of hours the  server
                      has been running
     %ServerMins    - displays the number of minutes the server
                      has been up
     %ServerSecs    - displays the number of seconds the server
                      has been up
     %ServerKbUp    - displays the no. Kbytes uploaded to  the
                      server since server start
     %ServerKbDown  - displays the no. Kb downloaded from the
                      server since server start
     %ServerFilesUp - displays the no. of files uploaded  to
                      the server since server start
     %ServerFilesDown - displays  the  no.  of   files
                      downloaded from the server since server start
     %ServerAvg     - displays the average server  throughput
                      since server start

     Server settings:
     %MaxUsers      - displays the maximum no. of users, as set
                      in Setup - Server
     %MaxAnonymous  - the maximum no. of anonymous users, as
                      set in Setup - Server

     User info:
     %Name          - displays the users login name
     %IP            - displays the users IP number or name if
                      available
     %Dir           - displays the users current directory
     %Disk          - displays the users current disk drive
     %DFree         - displays the amount of free space on the
                      users current disk in Kb
     %FUp           - displays the number of files uploaded by
                      the current user
     %FDown         - displays the number of files downloaded
     %FTot          - displays  the total  number  of  files
                      transferred
     %BUp           - displays the number of Kbytes uploaded by
                      the user
     %BDown         - displays the number of Kbytes downloaded
                      by the user
     %BTot          - displays the total  number  of  Kbytes
                      transferred
     %TConM         - displays  the total  connect  time  in
                      minutes
     %TConS         - displays the connect time in seconds - to
                      be used with %tconm
     %RatioUp       - displays the upload ratio  part  for
                      UL/DL ratios
     %RatioDown     - displays the download ratio  part  for
                      UL/DL ratios
     %RatioCredit   - displays the current download credit for
                      UL/DL ratios (Kb or files)
     %QuotaUsed     - displays how much disk quota is used in Kb
     %QuotaLeft     - displays how much disk quota is left in Kb
     %QuotaMax      - displays the maximum amount of disk space
                      that can be used in Kb

     Number of users:
     %UNow          - displays the current number of  Serv-U
                      users connected
     %UAll          - displays the number of users since  the
                      server was started
     %U24h          - displays the number of users in the last
                      24 hours
     %UAnonAll      - all currently logged in anonymous users
     %UAnonThisIP   - all anonymous users logged into this IP
                      home
     %UNonAnonAll   - all  non-anonymous  users  currently
                      logged in
     %UNonAnonThisIP - all non-anonymous  users  logged
                      into this IP home
     %UThisName     - all current users with the current  user
                      name logged into this IP home

The  file upload and download message directives are for  the
current  session  only (i.e. They do not show  the  aggregate
over  multiple  sessions). Not all of these  directives  make
sense  for both the signon and signoff text: There is  little
point  in  putting %disk in the signon message,  since  the
user   is  not  yet  logged  in.  Likewise  for  some   other
directives. However, these same directives can also  be  used
in  directory change messages and login messages,  which  are
covered  in  the following sections. There they can  be  very
useful.

The   %ServerDays,   %ServerHours,   %ServerMins,   and
%ServerSecs  directives are meant  for  use  together.  The
number  of hours is whats left after the number of  days  is
subtracted,  and the same goes for the number of minutes  and
seconds.

You could make the following signon text:

     Welcome, it is %time on %date, and you are user number %unow of %maxusers
     Over the last 24 hours, %u24h people have visited this site
     
Im  sure  youll figure out by yourself what this will  look
like to the user . . .
Please  keep  in  mind that the average client  has  only  80
characters per line, and the first four are taken up  by  the
reply code. So keep your lines short if you want the users to
actually  see  your prose (70 characters should generally  be
considered a safe maximum).

2.11 How to Setup User Specific Login Messages
----------------------------------------------
After blowing away the user with your signon message you  can
go  for  the  kill  by also providing a user  specific  login
message.  These messages should be put in one  or  more  text
files  and  the file name can be filled out in the  users  or
groups  setup dialog box, in the Message file field of  the
miscellaneous part, i.e. press the Misc button in the  user
or group box to get there.

The  file name you enter in the Message file field can have
several forms: You can use an absolute path with a drive, for
example  C:\FTP\LOGMES.TXT. This will of course  make  Serv-U
use  this  file. You can also specify only the name,  and  no
path, for example LOGMES.TXT. This will cause Serv-U to  look
in the users home directory for this file and if it is there
it will be displayed to the user. Finally, you can specify  a
path  but no drive letter, for example \FTP\LOGMES.TXT.  This
means  that  Serv-U  will add the drive of  the  users  home
directory  to  make  a  full path. The  latter  two  ways  of
specifying the file can be very useful for groups, i.e.  with
just  a single file name set up you can provide all the users
that are part of that group with a separate login message.

Of  course,  you can use all the % directives mentioned  in
the previous section in login messages. Try for example:

     Hello %name from %IP!

With a little luck Serv-U will have found the IP name of  the
user  by the time he or she logs in. So you can impress  them
by   showing  you  know  where  they  are  (Big  Brother   IS
Watching!).  By the way, Netscape displays the login  message
in  a  nice looking way at the top of the screen (The sign-on
message does not get displayed by Netscape).

As  a  final  example  for  your own  system  administrators
account  in  Serv-U  you  might  want  to  get  some   server
statistics. So here is a login message file you will like:

     This server has been up for %ServerDays days,
     %ServerHours hours, %ServerMins min. and %ServerSecs sec.
     A total of %uall users have been served and
     %ServerKbDown Kb downloaded in %ServerFilesDown files.
     Uploaded was %ServerKbUp Kb in %ServerFilesUp files.
     There are %unow user(s) logged in and %u24h users
     visited during the last 24 hours.

2.12 How to Use Directory Change Messages
-----------------------------------------
It  can be very useful to tell a user some specifics when  he
enters  a  directory. For this purpose Serv-U  has  directory
change  messages. There can be a different message  for  each
directory.

As with the login messages, the directory change message text
should be stored in a file. In the Setup - FTP Server  menu
choice you can specify which file name Serv-U should look for
when  the  user changes directory. You can specify  the  file
name  in two different ways: First is an absolute file  name,
for  example  C:\FTP\CDMES.TXT. As  youd  expect  this  will
display  that  file  for each directory change.  Then  it  is
possible  to  use  a  file name only without  the  path,  for
example CDMES.TXT. This will make Serv-U look for and display
the file with that name, in the directory into which the user
is changing. The latter one is the usual way to use directory
change  message files, since this enables you  to  specify  a
different message for each directory.

The  server  setup dialog box has room for  a  primary  and
secondary directory change message file. When looking for a
message file, Serv-U will first try the primary file name. If
there  is no file name specified in there, or the file cannot
be  found,  the  server will try to find the  secondary  file
name.  This  is  very useful in case you  have  specific  dir
change  message files for some directories, using a  relative
file  name as the primary directory change message file.  You
can  then  set  up  an absolute file name  as  the  secondary
directory  change message file. This will show the users  the
primary file message when available, and the secondary one if
there is no primary (For example because its a CD-ROM so you
cannot   place   directory  change  message  files   in   its
directories).

If  you are in the Setup - FTP Server menu choice you  will
see  a  little button behind each of the places to enter  the
directory  change message files. These are for  browsing,  to
select  a  file,  and  they will call up your  favorite  text
editor  with the selected file (creating the file if  it  did
not  exist  yet). Give it a try, it should make life  easier.
Keep  in  mind  though that there is one thing these  buttons
will not do for you: They will copy the entire path including
drive  and directories. If you wanted a different message  in
different directories you have to manually remove the path so
only the file name itself is left.

Like sign-on and sign-off messages you can use any of the %
directives in directory change messages. Take a look  at  the
previous sections for a list of all directives.

Netscape will display those directory change messages at  the
top  of  the page. One more trick: If you enabled  the  Hide
hidden  files feature in the miscellaneous user  setup,  you
can  hide  the directory change message file itself from  the
user  by making it hidden. Hidden files are files with  the
DOS/Windows  hidden  attribute set, something  you  can  do
using   the   DOS  program  Attrib  or  by   changing   the
properties  of  a  file  in Win95 (using  the  right  mouse
button). So, if you make your directory change message  files
hidden  they  wont show up in the directory  listings  while
users still get to see the messages.

2.13 How to Use Links  la UNIX
-------------------------------
If  you know UNIX then you know what I am talking about  when
links  are  mentioned. If not, then try the following:  Links
are  names  of  files and/or directories that appear  in  the
directory listing but they are not in the directory that  the
user  is  listing. Rather, they point to the actual directory
or  file and can be used by the user as if they were the real
thing  itself. A little like the Windows 95 shortcuts,  but
more  real: When you delete a link through Serv-U  (i.e.  via
FTP) the actual file or directory is gone! The great value of
links  is in showing users that you have all kinds of goodies
available  on  other disk drives. The user  can  then  simply
change  directory to a link and thus change to  a  completely
different drive and directory.

The  way  Serv-U works with links is by reading them  from  a
text  file.  You can have different files and thus  different
links  for  each  directory, much in  the  same  way  as  the
directory  change messages work in the previous section.  The
file  name  is  entered via the Setup  -  FTP  Server  menu
selection  (Guess  where!). The server  setup  will  let  you
specify  a  primary and secondary link file. During  use  the
server  will first try to find the primary link file, and  if
that one doesnt exit it will try the secondary file name. As
with  message  files there are several ways to specify  which
file  Serv-U should use for links: You can enter a file  name
by  itself, for example LINKS.TXT. This makes the server look
in the users current directory for a file with this name and
if found it is merged into the directory listing. This is the
way  to  set up different link files for each directory.  The
second  method is by specifying a full path name, for example
C:\FTP\LINKS.TXT. As youd expect the result will be that the
same  links  are  shown in each and every directory.  If  you
dont  want links to show in every directory use a file  name
only  for  the  link file, not a full path.  Now,  that  just
answered one of the most asked questions I receive by E-mail.
Wasnt so hard, was it?! Finally, you can leave out the drive
letter,  for example \FTP\LINKS.TXT, which means Serv-U  adds
the  current drive to the name and then looks for  the  file.
Useful  for setting up links that change per drive,  but  not
per directory. If you make the link files attribute hidden
and   enable   the  Hide  hidden  files  feature   in   the
miscellaneous section of the user or group setup  then  users
wont  see the file itself appear in their directory listings
while they still get to see the links.

In a typical situation youd specify a relative path name for
the  primary  link file, and an absolute path  name  for  the
secondary link file. For example, if you enter the file  name
LINKS.TXT as the primary file name Serv-U will look for  this
file  in  the  users  current directory. This  lets  you  use
different  LINKS.TXT files for different directory, typically
with links specific to that directory. Youd then put all the
links you want to always show the user, even when they are on
a  CD-ROM,  in  a secondary link file with an  absolute  path
name, lets say C:\SERV-U\ABSLINKS.TXT. A good candidate  for
the  secondary link file would be a link to the  users  home
directory.

Just as with directory change messages mentioned before there
are browse buttons to make file selection and editing easier.
Also  just  as mentioned before remember to remove  the  path
information manually if you use the browse button  to  select
the  file  name and want to show different links in different
directories.

Now, what should a link file look like? Each line of the file
describes a different link. First comes the link name,  which
is  what  the user is going to see in the directory  listing,
then a | which acts as a separator, and finally the file or
path  that the link should point to. Here is an example  link
file that should make all this a little clearer:

     D-Drive         | d:\
     CD-ROM          | f:\
     Home            | ~
     Fun Stuff       | g:\public\games
     One up          | ..
     Pointless       | \junk\..\more\..
     Poem            | c:\culture\poem.txt

As  far  as the user is concerned links behave like the  real
thing:  They can be used for change directory   if  its  a
directory, download for a file etc. Only difference is that
if  you  delete a link via FTP using some FTP client  program
the  file or directory it points to will get deleted but  the
link  will  continue  to  show up in the  directory  listing.
Needless to say that it is your responsibility that the links
in a link file point to something that makes sense.

IMPORTANT  NOTES: A point that seems to cause much  confusion
and  is the source of much of the E-mail Im receiving is the
effect of links and using the Show path relative to homedir
feature in the miscellaneous dialog box of the user and group
setup.  People will make all these beautiful links  to  other
drives, CD-ROMs and the like, then switch on relative paths
and  act surprised their links dont work. Once again,  while
using relative paths Serv-U will try to show the users path
relative to the home directory for that user. This only works
for paths at or below the users home directory. For example,
if   the   homedir   is  C:\USERS\JIM,   then   a   link   to
C:\USERS\JIM\UPLOAD will work fine, but a link to E:\PICTURES
will  not.  Links to drives and directories  outside  of  the
users  home  directory will not work  with  the  Show  path
relative to homedir option enabled! Another point to note is
that  Serv-U will only show links in a directory  listing  to
which  the user has some form of access. This lets  you  make
general link files with lots of links to be used with several
user  accounts.  Each user will only sees those  links  which
have a destination to which the user has some type of access.
The  others simply will not show and the user will never know
about them.

So  much  for the fun part, back to more serious matter  with
more  about how to select whom you want to let on your server
and whom to bounce...

2.14 How to Set Up Upload/Download Ratios
-----------------------------------------
Sometimes  you  want to force your users  to  upload  a  file
first, before they can download anything. Serv-U can do  this
for you, and more!

The setup for UL/DL ratios can be found in the user and group
setup  dialog boxes, by pressing the 'U/D Ratios' button.  In
general,  UL/DL ratios will let you specify how much  a  user
can  download for each upload. For example, if for a user the
ratio  is  set to 1 / 3 this means that for each  upload  the
user  can  download 3. So, after uploading  2  the  user  has
credit for 6.

Serv-U  can handle two types of ratios: Either it  will  keep
track  of  the uploads and downloads for each time  the  user
logs  in separately (the 'per session' settings), or  it  can
keep  track  of  file transfers over multiple  sessions  even
while several clients are logged in using the same user  name
(the  'overall' settings). For each of the 'per session'  and
'overall' choices Serv-U can count files (each file  uploaded
or downloaded counts as '1'), or it can count the actual file
sizes  in  bytes. Depending on which of the two is  used  the
ratio and credit setting will either mean 'files' or 'bytes'.

For  the  UL/DL  ratio  setting the actual  numbers  are  not
important. What counts is of course their ratio. For example,
setting  a upload/download ratio of 1 / 2 means (for 'files')
that each uploaded file gives the user two files 'credit' for
downloading.  Likewise, if bytes are  counted  each  uploaded
byte gives two bytes 'credit' for downloads.

Every  upload is converted into 'credit', and every  download
is  taken  from that credit. In a 'per session'  setting  the
credit  entry in the dialog box is intended for  entering  an
initial credit value that the user gets when logging in.  For
an  'overall' setting this is the actual current  credit  for
that particular user, which can be edited in the ratio setup.

Lets  walk  through a couple examples to  show  you  how  it
works. Say we have enabled ratios for the Anonymous account
with  settings  Count  files per  session,  the  ratio  for
Uploads is 2 Downloads is 3, and their Credit value  is
set  to  2. Just after we entered it all someone logs  in  as
Anonymous and the fun begins. That user will get the preset
value  as  his starting credit, so right now he has  download
credit for 2 files. The user downloads two files, no problem,
then  tries  the  third  one  and  Serv-U  complains  he  has
insufficient credit (Of course we already told our users that
ratios were in effect via their login message, right?!).  The
user figures he has to upload, and uploads a file. This gives
him  3/2 = 1.5 files download credit. OK, on with downloading
another  file, which brings the current credit value down  to
0.5, and that is not enough for any more downloads. Uploading
another  file  adds another 1.5 credit, bringing  the  users
current  credit to 2 which is exactly what we wanted (he  has
so  far  uploaded 2 files, downloaded 3 files (2 from initial
credit  and one after the upload), and has credit to download
2  more). Now the user logs out, and what does that mean? The
credit  is gone! We set the account up to count per session
so  Serv-U  does  not  keep track of credit  gained  or  lost
between  sessions. Next time the user logs in he  will  again
start off with the 2 files initial credit and after that  the
2  /  3 ratio. This should teach us another lesson: There  is
not  much  point in giving initial credit for  per  session
settings since this would make it very easy for the  user  to
simply log out when credit runs out and back in again to  get
more. There is another important point to keep in mind:  Most
WWW browsers when used as a FTP client will log in with a new
session for each file upload/download. So, ratios do not work
well  with  WWW browsers, people need to use real FTP  client
programs.

The  second  example I want to show you is using  the  "Count
bytes  all  sessions"  setting. Say we  set  the  ratios  for
Uploads to 1 and Downloads to 2. The Credit setting  is
left  at  0.  When the user logs in for the first time  there
will  be  no  download credit so he needs to  upload  a  file
first. Lets assume the user uploads 2 files, one 14987 bytes
and  the  other  348922 bytes. This means  he  now  has  2  *
(14987+348922)  = 727818 bytes credit for downloading  files.
Since  the  ratio  setup shows Kbytes this will  show  up  as
710.76  Kb.  Dont worry, internally Serv-U  keeps  track  of
credit  up  to  the byte accurate. Back to our user,  he  now
downloads  a  file with size 34878 bytes and logs  off.  This
means his credit will show 727818 - 34878 = 692940 bytes,  or
676.70 Kb. Next time he logs in again that will be the amount
of credit he will start with, in short, Serv-U keeps track of
the users credit between sessions. In fact, even if multiple
users  log  in using the same user name Serv-U will correctly
track the credit for that user account.

There  is an important item which is closely related to UL/DL
ratios,  which  is named "free files". These are  files  that
will  not  be  counted for the upload/download  ratio  count,
something very useful for README.TXT files and the like.

"Free files" can be set up in the 'Setup Server dialog  box,
by  pressing  the U/D Ratios' menu item. Just fill  out  the
file  name in the text edit box and press the 'Add' key. This
will  put  it  in the list which shows all the current  "free
files". The file name can be a name only, i.e. without  path.
That  way  any file with that name in any directory  will  be
free. For example, adding INDEX.TXT will make any file on the
system  with  that  name freely downloadable.  You  can  also
specify  a  full path in case only a specific file should  be
free.  For example C:\FTP\INDEX.TXT will make INDEX.TXT  free
only if it's in the C:\FTP directory. You can also leave  out
the  drive  letter,  which is taken to  mean  'for  all  disk
drives'.

The  free file names can contain wildcard characters: '*' and
'?'.  For example adding *.TXT will make all files ending  on
.TXT  free  on your system, or A???.TXT will make  all  files
starting with A followed by 3 other characters and ending  on
.TXT  free. Wildcard characters can also be used in  a  path.
For  example,  \*\*.TXT would make all files  on  all  drives
ending on .TXT free if they are in a sub-directory one  level
deep (like C:\FTP\INDEX.TXT would be).

2.15 How to Limit Disk Usage of Users
-------------------------------------
Unless  you  have  deep pockets and consequently  large  hard
disks you are going to want to limit the amount of disk space
that  your  FTP users can occupy. Again Serv-U comes  to  the
rescue  by  letting you specify exactly how much a  user  can
use.

For  this  purpose the user and group setup  boxes  have  the
Quota button which brings you to the disk quota dialog box.
In  there  you  have  two items: One to specify  the  maximum
amount  of  disk space a user can use, the other  to  specify
what  the  current amount is. Even though  the  setup  is  in
Kbytes,  internally Serv-U is accurate up to  the  byte.  The
current  amount lets you set up an initial value,  in  case
you are filling out the users details for the first time. It
also  keeps track of the disk usage as time goes by, and  you
can thus change it whenever you feel like it.

Since a small example may go a long way here, let us look  at
a  practical  situation: Say you were not  using  disk  quota
limitations so far and your user Jimmy has been  thoroughly
piging-out and now uses about 8700 Kbytes in the subdirectory
assigned to him. You want to make sure he doesnt go over  10
Mbytes  and decide to let him stick to that the hard way.  In
the  disk quota dialog box you check the Enable disk  quota
box,  and fill out 10000 for the maximum value (which after
all  is  10  Mb). Since Jimmy is already using 8700  Kb,  the
number  8700  goes into the current value. And  thats  all
there is to it! From now on Serv-U watches every upload, file
deletion  and  so  on to keep the current  disk  quota  value
accurate, and it will not allow Jimmy to get past  10  Mb  of
space.

A helpful hint: Did you know you can easily find out how much
is  stored in a directory and all its subdirectories via  the
Win95/NT4  Explorer?  Just  select  the  directory  you   are
interested  in  and right-click the mouse  on  it.  From  the
little  list  that pops up select Properties and  note  the
Size  entry, it will tell you up to the byte whats  there.
Want  to enter this in Serv-U? Just divide the size in  bytes
by  1024 and enter the result as the Current amount in  the
quota setup.

Before  abandoning  this  topic I want  to  stress  what  was
written above: Serv-U does not actually calculate the  amount
of  disk  space  in use by looking at a users directory  and
adding  up  all the files and subdirectories in  there.  This
would  not be feasible since a user may have access  to  many
directories  and multiple users may even have access  to  the
same directory. Windows does not keep track of who created  a
file,  so  it  is  impossible to  later  attribute  files  to
specific  FTP  users. Instead, Serv-U starts with  a  known
disk  usage  value  for a user and adapts  that  by  watching
uploads  and file deletions. For a setup where only a  single
user  can add/delete files from a directory this works  well.
If  others  users can delete files uploaded by  someone  else
this  system  does not work. In short, it is  not  a  perfect
solution, but for most situations it does the job.

2.16 How to Limit Access by IP-Name or Number
---------------------------------------------
The  Setup - IP Access menu choice will pop up a dialog box
which  provides  the  means to restrict access  to  your  FTP
server  to  certain IP-numbers or IP-names. If  for  example,
you  work at a university and only want your faculty  members
to  be able to access the server, then this is a great way to
do it. The exact same IP access rule mechanism also exists on
a  per  user  basis,  allowing  you  to  specify  for  each
individual  user  name  what IP names or  numbers  should  be
allowed  access to your server. This setup menu  is  accessed
via  the  Setup  - Users - IP-access menu choice  (it  also
works for groups, in exactly the same way).

By  default  the  server comes without any IP  access  rules,
which  allows access to everyone (Theyd still need  a  valid
user name and password, and access to a directory of course).
As  soon  as  there  is  even a single IP  access  rule  this
changes. Each FTP user connecting to your server now  has  to
pass  the  access rules before access is granted.  IP  access
rules come in two types: There are allow rules which let  a
user  in  if they pass the rule, then there are deny  rules
which kick a user off if they qualify for that rule. In order
to  log  into your server the user has to pass at  least  one
allow rule!

In  the  upper left corner of the dialog box you  can  choose
which  type  of rule you want to specify: Deny  or  Allow
rules.  The  deny rules decide who should be  kept  out,  the
allow rules indicate who should be welcomed. THE ORDER OF THE
RULES  IS  IMPORTANT! When a client contacts the server,  the
rules  are  looked at FROM TOP TO BOTTOM. The first  matching
rule applies, and evaluation is stopped.

You  can  type in a new rule in the Rule edit and then  use
the  Add  button to add the rule to the list. The  Remove
button will remove the currently selected rule from the list.
To  change the order of the rules you have to select  one  by
clicking  the mouse on it, and then use the Up  and  Down
buttons to move it around.

Rules  are nothing more than IP-names, IP-numbers, or  ranges
of  them.  There are three special characters: the star  *,
question mark ?, and the hyphen -. A star functions as  a
wildcard for checking the IP-address. Any name or number will
match  that section of the rule if it is a star. The question
mark is for IP-names only, to match any single character. The
hyphen is used to denote a range of numbers, so that can only
be  used  for  IP-numbers. Simply separate the  starting  and
ending values by a hyphen. For example, say all IP-numbers in
your  company  look like 134.56.34.xxx with xxx  being  any
number.  Now, you want to restrict access to your FTP  server
to other members of your company only. The way to do it is to
create an allow rule that looks like this:

     Allow:    134.56.34.*

Thats  simple,  isnt it!? Likewise, if you  know  that  the
competition  has IP-numbers in the range 168.76.xxx.xxx,  you
can keep them out of your server with the deny rule:

     Deny:     168.76.*.*
     Allow:    *.*.*.*

The  allow  rule at the end is to allow all people  in  who
passed  the  first deny rule. Without it no  one  would  be
allowed  access to your server. Remember, whenever  there  is
even  a  single access rule users will only be  allowed  into
your server if they qualify for an allow rule.

Now,  you  need  to  share some of  your  files  with  a  few
colleagues,  and management in your company is too  cheap  to
install a local network. You find out that their PCs have IP-
numbers  134.56.34.128, 134.56.34.129 and 134.56.34.130.  You
could  of course make three allow rules, each with  one  of
these  numbers. A faster way to do this is to make  a  single
allow rule like this:

     Allow:    134.56.34.128-130

The  special characters * and - dont need to be  at  the
end  of the IP-numbers, any place will do. The rule 221.*.76-
154.89 is perfectly OK. I wouldnt know when youd need this,
but,  hey, the world is a strange place! Remember, the  order
of  the rules is important. Experiment a bit, and youll  get
the hang of it.

Now  to an option unique to Serv-U: You can not only use  IP-
numbers  but  also IP-names. They work pretty much  the  same
way.  For  example, say you want to keep all users from  Duke
University  out  of your server. This can be  done  with  the
following two rules:

     Deny:     *.duke.edu
     Allow:    *.*.*.*

Lets say you like me (purely hypothetical case), and know  I
have the IP name catsoft.dorm.duke.edu, you decide to let  me
have  access.  This needs one more rule, and watch  out,  the
order here really is important!

     Allow:    catsoft.dorm.duke.edu
     Deny:     *.duke.edu
     Allow:    *.*.*.*

By  now  you should be seeing the limitless opportunities  of
this  mechanism. With a single rule you can limit  access  to
your server to a single country, to give you one example! You
can mix rules with IP-names and IP-numbers as you see fit  in
any  combination.  For  IP-names you can  also  use  the  ?
character,  which  will  match any single  character  of  the
users  IP-name. As illustrated above, the way  IP-names  are
matched  to  the rule is different from the usual,  but  very
much  the way you would expect it intuitively: IP-name  rules
are  matched from the last to the first character. This means
that if you have the rules:

     Deny:     *.uk
     Allow:    *.*.*.*

This  will  block  access to anyone from the United  Kingdom.
Jimmy.deamon.co.uk  will  not  be  allowed   in,   but   also
oxfort.ac.uk will be blocked, as well as anything else ending
on  uk. There is one more side-effect of IP-name rules that
you  should  be aware of. When you start Serv-U it  does  not
know  if  there are any IP access rules that need an  IP-name
lookup,  and  searching  all possible rules  is  prohibitive.
Doing  a  reverse IP-name lookup is computationally slow  and
can take any amount of time (Serv-U has a hard-coded limit of
one  minute for this), while the FTP client has to wait until
the lookup is done. So, by default it does not do reverse-DNS
lookups  to  determine the IP-name of the  FTP  clients  that
connect to the server. This means the first time an IP access
rule  is encountered that needs an IP-name, the user will  be
bounced  (since no name is available at that point). However,
once this happens the server switches strategies and does  an
IP-name lookup every time a user connects.

Since  people  keep  asking me this: A few  words  about  the
security of IP-access rules. The check on IP name and  number
stands  pretty  much  at  the  top  of  the  Serv-U  security
mechanism  and  all  connections have to  pass  through  this
rather narrow bottle neck. The code that does the checking is
quite  simple (In contrast to the code that does  the  access
rule  checking for paths), so it is unlikely that  there  are
any  loopholes or bugs left in there. Thus, in my humble  and
honest  opinion  this is one feature that makes  for  a  very
secure FTP server if that is what you need!

2.17 How To Improve Server Performance
--------------------------------------
There  are many factors which affect the performance of  your
FTP  server.  Serv-U has a great number of options  and  they
come  with  lots  of overhead. That is the price  for  having
those  options.  Still, Serv-U was designed  so  that  unused
options  have  as little effect on performance  as  possible.
This  means you should leave options you dont need  switched
off.  Things like IP access rules, speed limits, ratios,  and
disk  quotas  all  eat up CPU cycles. Also  dont  leave  FTP
commands/replies or WinSock activity logging on, and the User
Info  screen  is  especially  notorious  when  it  comes   to
overhead.

One  option I would like to get into a little deeper  is  the
directory listing cache. Serv-U can cache directory listings,
so  the  next time the same listing is requested  the  server
does not have to retrieve it again from disk, which is a slow
and  lengthy process. By default this is switched off for the
16-bit version of Serv-U, and enabled for the 32-bit version.
The reason that the 16-bit version does not use the cache  is
because Serv-U can not detect file and directory changes  and
thus  would not know when a particular listing it is  caching
is  outdated. Apart from this the directory cache works  fine
on Windows 3.1 and WFW3.11, and if you wish you can switch it
on. Just keep the aforementioned limitation in mind.

Under  Windows  95  and  NT the directory  listing  cache  is
switched on by default and it is set up to store a maximum of
20  different dir listings, for 600 seconds (that would be 10
minutes).  This means that when the cache is  full,  and  the
21st  listing is requested, it will search for the least used
listing and remove that to make room. The time determines how
long  the  cache should keep a listing (if it  does  not  get
thrown out to make room for another one). When the time is up
the listing is discarded and when the next user requests that
directory  listing it has to be created again from disk.  The
32-bit  version  of Serv-U is smart enough  to  automatically
detect  any  changes to files and directories and remove  any
listings from the cache that would be affected by this.

The  default values, 20 listings and 600 seconds, should work
well  for most servers. You can change these values  via  the
Setup - Server - Dir cache menu choice. The fields in there
should speak for themselves. The right values for your server
will  depend very much on how your server is typically  used.
If  you  have 10000 users a day who all log in as "Anonymous"
and  stay  within the same few directories there is not  much
point  in changing the default values, except maybe  for  the
time-out which you might like to set a little larger. On  the
other  hand, if your server usually has around 75  concurrent
users  on-line,  who all have a different home  directory  so
they   list   different  dirs,  it  might   greatly   improve
performance when the cache size is enlarged to 90.  A  larger
cache size comes at a price: It will use more memory and Serv-
U will spend more time on cache house keeping tasks.

The  emphasis  in  this section was on the directory  listing
cache, but there are of course many other factors that affect
performance. If all you have is a modem or ISDN connection to
the  Internet then Serv-U is not likely to be the bottleneck.
For  a  T1 or better connection server performance starts  to
become  an  issue.  One  of  the most  important  factors  in
performance  of just about any program is the amount  of  RAM
you have. This is not absolute, as long as there is more than
all your programs need at any given moment it will work fine.
It  is when memory gets in short supply that things slow down
considerably. The system will start using the hard disk as an
extension to the computers main memory by swapping parts out
to  disk, and back in again when needed by the CPU. Access to
memory   from  disk  is  a  very  slow  process,  literally
thousands of times slower than access to RAM, so keep an  eye
on  this. The Performance Monitor in NT can tell you how much
paging  to disk there is going on, in Windows 95 there  is  a
similar  program named System Monitor, but it is a  bit  less
informative. Still, both are useful tools to find out what is
going on in your system.

2.18 How to Print via FTP
-------------------------
Serv-U  also  allows  access to all PC  ports:  PRN:,  LPT1:,
LPT2:,  LPT3:, LPT4:, AUX:, COM1:, COM2:, COM3:,  and  COM4:.
This  can  be  a  convenient way of setting  up  a  network
printer by transferring files directly to PRN: or LPT1: using
FTP. These ports are treated like any regular path name, so a
user needs access rights to use them. Thus, to make a printer
on  PRN:  accessible and a modem on COM2: the user needs  the
following  access  rights in the Setup Users/Groups  dialog
box:

     PRN:                - write and delete rights
     COM2:               - read, write and delete rights

There seems to be much confusion on how to actually use  this
feature,  therefore a short explanation. These  ports  behave
very  much like files that always exist and can be  found  in
every  directory  although they dont show  up  in  directory
listings. So, no change directory commands are needed, just
transfer your file-to-print to the port with the printer. For
a  command line FTP client this would look like put FILE.TXT
PRN:  to print file FILE.TXT on a printer attached  to  port
PRN:.  For  point-and-click type  FTP  clients  you  have  to
specify that it should ask you for the destination file name.
Then,  when prompted for the destination file name you  enter
PRN:  or another port of your choice. For example, for  the
popular  client  WS_FTP  you have to check  the  Prompt  for
destinations  file  names option in  the  Session  Options
section.  After doing that you can simply upload the file-to-
print and it will ask you for the destination, for which  you
fill in the printer port name.

The  above procedure should work well to print ASCII text and
text-based   protocols  like  PostScript  (If  your   printer
supports  it).  However, with binary files your  mileage  may
vary:  It seems that the port closes when a ^D is encountered
in the stream that is being printed.

2.19 How to Execute Programs via FTP with Serv-U
------------------------------------------------
Serv-U  allows you to start DOS or Windows programs  remotely
using a FTP client. Keep in mind though that Serv-U is not  a
Telnet  server,  and any program output or  windows  will  be
displayed  at  the PC where Serv-U is running.  However,  for
many  applications the ability to start a program is  enough,
or  you might be able to redirect input and output, i.e. like
MYPROG.EXE < INPUT.TXT > OUTPUT.TXT.

The  first  requirement to using remote program execution  is
that  the  user needs sufficient access rights to  start  the
desired programs. This is controlled by the execute  access
right  in the Setup Users/Groups dialog box. You can either
give a user execute access to the directory where the program
can  be found, or you can specify the exact program name. For
example,  if  we  want  to  be able  to  execute  COMMAND.COM
remotely,  and  this  program can  be  found  in  the  C:\DOS
directory, then the following access rule would do the trick:

     C:\DOS\COMMAND.COM  - execute access

Now, to actually start a program remotely you need to use the
FTP  command  SITE  EXEC from the FTP client.  Usually  you
cannot  do that directly, since the client doesnt understand
this command, and you need to tell the client to send it as a
literal string to the server. for example the UNIX FTP client
(and  others like it, as the command line client which  comes
with  Windows  95 and NT) uses the QUOTE command  for  this
purpose. So the full command line to let COMMAND.COM  copy  a
file from A.TXT to B.TXT would become:

     QUOTE SITE EXEC C:/DOS/COMMAND.COM COPY /B A.TXT B.TXT

You  might notice the use of / instead of \ in the  path.
This  is  because most command line FTP clients do  not  take
kindly to backslashes. For Serv-U it doesnt  matter and  you
can  use  /  and \ alike. You can also  see  that  it  is
possible  to  specify  arguments to a program  as  you  would
usually do, Serv-U passes them on to the program.

The  example above will likely only work for command line FTP
clients  that  are  based  on the  UNIX  client.  The  latest
versions of the Windows client WS_FTP also supports Serv-Us
remote  execution. To execute a program in WS_FTP just change
to  the  directory where the file you want to run is,  right-
click  and  select FTP commands, SITE. A dialog  window  will
open and all you need to do is to type the file name you want
to  run.  For other point-and-click type clients you  are  on
your  own.  They  may  or may not have the  ability  to  send
literal  commands to the server but the way to get that  done
will vary from client to client.

Starting programs remotely may not be as straight forward  as
it  seems,  and  can  have varies side  effects.  Also,  some
programs  need  to  be  started via the command  interpreter,
COMMAND.COM,  others not, and this can  even  depend  on  the
Windows  version  Serv-U  is  running  on.  In  short:   Some
experimentation is recommended!

One  more  important thing about execute  access:  Although
Serv-U checks the programs path for access, the program  you
start  this way is free to access and delete any file in  any
directory  on  your  computer! Also, if  you  give  execute
access to a directory then any program in the DOS path can be
started! In short: Be very careful with execute access,  as
this can be a very big security hole!

2.20 How to Use Serv-U with SLIP/PPP Emulators
------------------------------------------------
Some   Internet   Access  Providers  are  offering   Internet
connections that are not real. Instead of having their  own
IP  address these connections run on top of the IP address of
a  UNIX  host  system. The general name for this category  of
connections is SLIP/PPP emulators and a few of the  popular
programs that will do that are TIA (=The Internet Adapter),
TWinsock,  and  Pipeline. The reason  ISPs  use  them  is
because  they offer a cheap way to get many people  connected
to  the  net.  They  usually  work  fine  for  programs  like
Netscape,  mail, and FTP clients. However, for  servers  they
come with a number of build-in disadvantages.

Because  of  the way they have to do their work they  have  a
number  of  peculiarities. Since the PC has to share  the  IP
number with the host system you will generally not be able to
use  the default port 21 for Serv-U. Instead, you either have
to  use  a high port number (generally above 8000) or set  up
'port  redirection'. Ask your Internet provider  for  details
about  the  latter. A related problem is that the  IP  number
displayed by Serv-U is, in this case, not the IP number  that
clients  should use to contact your server. It  is  merely  a
dummy  to  keep  the socket stack of the PC  happy.  For  the
outside  world the IP number of your server is  the  same  as
that  of the emulator host system, i.e. that of your Internet
provider. Another special effect is that clients will not  be
able  to  use 'passive' mode for data transfers.  This  means
that  regular FTP clients will work OK, but WWW browsers like
Netscape and Mosaic will not work when Serv-U runs via a SLIP
emulator.  For  the same reason it won't be possible  to  use
clients that are also connected via a SLIP emulator either.

Just  in  case you are interested Ill give you the technical
details  behind all this. Since Serv-U has to  share  the  IP
number  with the Internet connection host system  (Usually  a
UNIX system), the usual FTP port (number 21) will most likely
be  already in use by the host system. Because at a single IP
address there is only a single port 21 this means either Serv-
U  or  the host has to move to another port. The second  side
effect has to do with the socket stack: They usually need  to
know  their  own IP address to do the work, and to  keep  the
stack  happy  it is installed with a non-existent  IP  number
like  192.0.2.1  (Seems  to  be a popular  choice).  The  FTP
protocol  does  not use the server side IP number  much,  the
only  exception is the FTP PASV command, which is used  for
passive mode data transfers (Which all WWW browsers use).  In
essence, what the PASV command does is ask the server for  an
IP  address and port number where it will listen for the next
data connection. Since the FTP server does not know that  its
address  is bogus, it will trustfully report this  back.  The
client will then try to connect to this dummy address,  which
of course will never work.

Luckily the use of these SLIP emulators is disappearing these
days. Most ISPs nowadays offer real Internet connections that
dont have the problems described above.

2.21 How to Use Netscape to Access Serv-U
-----------------------------------------
You  might  not  be aware of it, but Netscape and  other  WWW
browsers  can  do  a whole lot more than just  anonymous  FTP
access. The general syntax for FTP is the following:

     FTP://<user>:<password>@<IP address>:<port>/<path/file>

Very  little of this is needed and in its simplest  form  you
only  use  the  <IP  address>  which  results  in  the  usual
anonymous  access. If you add a <user> section  (leaving  out
the password) then Netscape will prompt you for a password if
needed.  Of  course,  you can also specify  the  password  by
yourself by adding the <password> section. So far we did  not
use  the <path/file> section and this means the user will end
up  in his or her home directory. If you want to go somewhere
else  you  can tell Netscape to do this with the  <path/file>
section.  The  <port> section should only  be  used  if  your
server is on a non-standard port number. Normally FTP servers
listen on port 21, if yours is on a different port number you
need to indicate it in <port>.

In the <path/file> section you should use / instead of \,
and  you can add a drive letter as part of the path.  So,  to
finish up with an example that uses all of the above:

     FTP://john:secret@ftp.cat-soft.com/f/john

This  would log John into the Cat Soft server. Note that this
will  change to the f:\john directory, even though the  colon
is  missing.  Serv-U understands a single  character  at  the
start  of  a  path  to  mean the drive  letter  so  no  colon
required.

While  this works fine for Netscape in all its versions  this
will only work with MS Internet Explorer version 4 and later.
Microsoft, in its infinite wisdom, initially decided that  no
one  will  need  FTP access other than using  the  user  name
Anonymous. Anyway, if you are not scared away by  MSIE  4s
sheer   size  and  the  impossibility  to  uninstall  without
trashing your system then just give it a try!

By  the  way, did you know that the version 2.0 or  later  of
Netscape  can also upload files to a FTP server?  To  do  so,
simply  drag  the file-to-upload from Explorer  (the  Win95
file  manager), or from the File Manager (in NT or  Windows
3.1)  to the Netscape window and drop it there. Experiment  &
Enjoy!

2.22  How to Let the Whole World into Your Server (and Delete
All Your Files)
-------------------------------------------------------------
Even  for  those with a PC-oriented exhibitionist inclination
Serv-U  has  something to offer. You can let the whole  world
into your server and have them delete all your files. To  top
it off, if set up correctly they will reformat your hard disk
along the way too!

The  easiest  way to all that fun is to uncheck  the  Enable
security  checkbox in the Setup Server  dialog  box.  This
utterly  and completely disables all security in  the  server
and  thus offers the most comfort to your FTP users. Not only
can they freely copy and delete each and every file, they can
also  use  that unique Serv-U feature which lets  them  start
programs  remotely.  Of course, the fun  is  over  once  they
remotely  start FORMAT.COM, but what the heck,  it  was  nice
while it lasted!

Now,  for those that are a bit sarcasm inhibited Ill spell
it  out:  NEVER,  NEVER,  NEVER LEAVE THE  ENABLE  SECURITY
OPTION  SWITCHED  OFF  IF YOUR SERVER  IS  CONNECTED  TO  THE
INTERNET!!!  This might all seem a bit overkill, but  believe
it or not, I quite regularly get E-mail from people that tell
me  they are running Serv-U exactly like that on the Net. Now
dont tell me I didnt warn you (dont try to sue me either)...

2.23 How to Use Multi-Homed IP Support
--------------------------------------
If  your  operating system supports it, and you have multiple
IP  addresses installed in your computer (Typically  this  is
done  in  NT),  you  can let Serv-U respond  differently  for
different IP addresses to which the users connects.  To  make
this  a  little clearer a small example: Say you have two  IP
addresses   assigned   to   your   PC,   152.3.110.167    and
152.3.110.168,  which  correspond  to  IP  names   "ftp1.cat-
soft.com" and "ftp2.cat-soft.com" respectively. Now you  want
anonymous  users logging into the "ftp1" IP address  to  have
access  to different files and directories from those logging
into  "ftp2".  This  is  called multi-homed  IP,  and  it  is
supported by Serv-U.

The  first step to using this is in the Setup Server dialog
box.  Press the button labeled IP Homes in there. Then  use
the  screen that pops up to enter all the IP numbers of  your
PC.  When this is done you can go to the Setup Users dialog
box,  which will now show a new selection list with all  your
IP  numbers.  Just set up the users as you  did  before,  and
select  the  appropriate IP number that should be  associated
with  that  user name.  This will allow you, for example,  to
make  several  users  named Anonymous, each  responding  to
different  IP addresses. Thats all there is to using  multi-
homed IP, it could not be easier!

2.24  How  to  Have Serv-U Start Automatically  as  a  System
Service
-------------------------------------------------------------
In case your PC uses Windows 95 you are in luck. You can have
Serv-U  start automatically even before a user logs into  the
PC, and keep it going while Windows 95 users log out and back
in again. All you need to do to use it as a system service is
check the Auto-start as system service option in the Setup
- Server menu choice.

NT users can also run Serv-U as a system service, but this is
a  little more involved. For this you need the SRVANY program
which  is part of the NT resource kit. Please check  out  the
Serv-U Web site, the FAQ section has detailed instructions on
how to set things up.

2.25 How to Extend Serv-U with New Commands and Capabilities
------------------------------------------------------------
Serv-U  has an open architecture. This means you can extend
the  server with new functionality. Normally this  will  take
some  programming on your part, so this is not for  everyone.
But,  there are a number of Serv-U add-ons that have  already
been made and they are generally available through the Serv-U
Web site at http://www.ftpserv-u.com. Some are freeware, some
are  shareware, some come with source code so they  are  good
examples to start with for your own exploits. Right now there
are  add-ons  for WU_FTPd format logging, a module  to  block
uploading  or renaming of files with certain names  (of  your
choosing), and an upload/download & duplicate checker.

There are also a number of utility programs available to make
work  with Serv-U easier for you. The same add-on section  on
the  Web  site  has  a WWW based user setup  and  maintenance
program,  a  utility to encrypt passwords (for  automatically
adding accounts), a log file parser for extracting server and
user statistics, and a command line utility to create or edit
user accounts. As more becomes available it will be published
on  the Web site, so check back there once in a while.  Also,
if  you write your own add-ons and think they might be of use
to others please drop me a line at Rob@cat-soft.com.

As mentioned before you can write your own add-on modules for
Serv-U  which tie directly into the server itself.  All  user
access  and  a  large number of events can be  caught  by  an
external  DLL,  and you can change server responses  with  it
(deny  access for example). The event notification  mechanism
also  lets you add your own SITE command extensions (via  the
FTP  command SITE). In short, the possibilities are  pretty
much endless. Section 3 of this manual explains in detail how
such DLLs can be written, so please take a look there for the
details.

2.26 What FTP Command Extensions Does Serv-U Support?
-----------------------------------------------------
Im glad you asked! Serv-U supports just about everything  an
FTP  server  should support according to the FTP standard  in
RFC959.  On  top of that it also has a number of non-standard
extensions  to  the FTP command set. They are  listed  below,
with  their FTP command as it is sent from the FTP client  to
the server at the top:

REST
First  one  worth  mentioning  is  the  "resume"  option  for
uploading  and downloading of files. In FTP terms  this  uses
the REST command in a non-standard way. It means that partial
file  transfers can be resumed at a later time, handy if  you
have  to  transfer  large  files and  the  connection  breaks
halfway.  No  setup  of  Serv-U needed,  if  the  FTP  client
supports  it you can use it. Most client programs these  days
support  resuming of file downloads, but very few can  resume
file uploads. For resuming uploads take a look at FTP Voyager
from Rhino Software, it supports this.

NLST, LIST
These  are  the  two  FTP commands that deal  with  directory
listings.  Normally they do not have options, or rather,  the
only  option according to RFC959 is a directory path or  file
which  should be listed. Serv-Us version of the dir  listing
commands  supports most of the UNIX ls options,  just  like
the  UNIX  FTP  servers  do.  These  can  be  convenient  for
retrieving  custom  tailored  directory  listings.  Supported
options are:

     -a   = list all entries including those starting with '.'
     -b   = force printing of non-printable characters in octal
     -c   = use modification time for listing sorting
     -d   = if argument is a dir list only name, not contents
     -f   = enable -a, -U, disable -l, -s
     -i   = print i-node number in first column
     -k   = use 1024 bytes for block size (default is 512 bytes)
     -l   = list in long format (default for LIST)
     -m   = stream output, list accross page separated by commas
     -n   = like -l, but use UID and GID numbers instead of names
     -o   = like -l, but without the group info
     -p   = put '/' after directory names
     -q   = print non-printable characters as '?'
     -r   = reverse sort order
     -s   = give size of each entry in blocks
     -t   = sort by modification time instead of name
     -u   = use time of last access for sorting
     -w:NN = set line length to NN characters (default is 80)
     -x   = multi-column output with entries sorted accross
     -A   = list all entries, except for '.' and '..'
     -B   = ignore names ending on '~' for dir listing
     -C   = multi-column output with entries sorted down
     -F   = put '/' after dir names, '@' after links
     -G   = do not display group info
     -I:"XX" = add pattern XX to the list of patterns to ignore
     -L   = if  argument is a link, list file or dir it references
     -N   = force printing of non-printable characters
     -Q   = quote names as C-syntax strings
     -R   = recursively list sub directories
     -S   = sort by size (default is date)
     -T   = show  extended date/time info for long format listings
     -U   = do not sort dir listing
     -X   = sort by extension of the name (default is date)
     -1   = print one entry per line of output

Most  client FTP programs do not let you specify  options  to
the  dir listing command, which means these options will  not
help  you  much.  The command line client  which  comes  with
Windows 95 and NT does let you specify options, just add them
to the command. For example dir -lR will make a long format
recursive  listing of all files and directories at  or  below
your current directory.

MDTM
Like the previous commands this is from the UNIX world and it
lets  you query the server for the modification date and time
of  a  file  or directory. Unlike UNIX Serv-U also  lets  the
client  set  the modification date and time of files  on  the
server, if the user has sufficient access rights to do  this.
Its  use is in synchronizing uploaded files with those on the
client. Normally FTP has no way to explicitly set the date of
uploaded files, they simply get the date they were created on
the  server. MDTM lets the client change that so they get the
date   of  the  original  file  on  the  server.  Works   for
directories too. The syntax to set the date and time is:

     MDTM yyyymmddhhmmss[+-xxx] <path/file>

Where  yyyymmddhhmmss  is a line of  text  with  the  year,
month,  day, hour, minutes, and seconds the file  should  get
set  to.  The  next  part, "[+-xxx]", is optional  time  zone
information of the FTP client in minutes relative to UTC.  If
the  client  provides  this info Serv-U  will  take  care  to
convert  the  date and time to the proper local time  at  the
server,  so  dates  and  times are kept  consistent  (a  file
created  at  4  in  the morning in the Eastern  US  would  be
created  at  10 in Central Europe). If no time zone  info  is
given  Serv-U assumes you are specifying local  time  at  the
server. The extended format, with time zone information, only
works  in  the  32-bit version of Serv-U. The 16-bit  version
ignores  time zone information and always assumes the  client
is  specifying local time at the server. An example,  showing
how to set the time if the client is in the Eastern US during
summer  time: "MDTM 19980719103029-240". This would  set  the
date  and  time  to  19 July 1998, 10:30am  29  seconds,  and
indicates the client is 240 behind UTC. At the time  of  this
writing not many FTP client programs support the command. FTP
Voyager is one, and CuteFTP lets you define it by hand. The
command  line  FTP client lets you send this  by  adding  the
quote   command,  so  an  example  would  be  quote   mdtm
19980525162603 file.txt.

SITE EXEC
This  has  been mentioned before in the section  on  remotely
starting programs via FTP so I will keep it brief. The syntax
is:

     SITE EXEC <command line>

If  the user has sufficient privileges this will execute  the
specified command line on the server.

SITE INDEX
This  command  from the Macintosh world was added  to  better
support the Mac FTP client Fetch. It lets the client retrieve
a recursive directory listing via the command connection. The
syntax is:

     SITE INDEX <path>

The path may contain wildcard characters in its last part, to
allow selective retrieval of for example all text files.  The
command line FTP client would do this (for example) by  using
quote site index *.txt.

SITE PSWD
This extension is for changing the users password via a  FTP
client  program.  Normally FTP does not  allow  the  user  to
change  their password. If the user has sufficient privileges
this  will  make life easier for the system administrator  by
leaving password changes up to the user. The syntax is:

     SITE PSWD <oldpassword> <newpassword>

The  passwords may alternatively be enclosed by quotes.  This
can  be  useful in case one of the passwords contains spaces.
Few  FTP  clients  support this command at  the  moment.  FTP
Voyager is one of the few, and in CuteFTP you can add it  by
hand.  Of course, the command line FTP client also lets  you
use this command by using it via quote.

SITE ZONE
Sometimes a FTP client program needs to know the time zone of
the  server, for example to adapt the dates and  times  in  a
directory listing to the local time. This option reveals  the
servers time zone relative to UTC. The syntax is:

     SITE ZONE

A typical reply would look like this:

     210 UTC-240

This would indicate the server is 240 minutes behind UTC. The
time  shown already takes summer time into account  (daylight
savings  time  as it is called in some parts of  the  world).
Only works in the 32-bit version of Serv-U.




3. The Inner Workings
=====================
Before  I  go  on to describe the settings of the  SERV-U.INI
file  I  want to spend a few words describing how Serv-U  was
made and how it goes about its job.

3.1 Serv-U Internals
--------------------
The  program was written using Borland C++ version  5.02.  To
check  for shaky pointers and catch all those resource  leaks
the  program  Bounds Checker version 3.01  from  Nu-Mega  was
used. I think no serious Windows programmer should be without
the latter, very highly recommended!
This  whole  project started a little over  three  years  ago
after  much disappointment with the existing FTP servers  for
WinSock.  In its current version it consists of  a  bit  over
30000  lines  of C++ code, divided into over 60 C++  classes.
The whole program was constructed from scratch, not using any
existing  FTP server code, and is tailored to MS-Windows  and
WinSock.

Internally, everything is very much compartmentalized,  using
a  different class for different partial tasks.  There  is  a
WinSock  class library, providing hi-level access to  Windows
Sockets and hiding all the nasty parts of dealing with  them.
It   uses   100%   asynchronous  WinSock   functions   (which
unfortunately  do not always work correctly on  a  number  of
WinSock  stacks) thus avoiding problems with multiple  active
sockets  for  a  single task and re-entry. There  is  a  FTP-
manager  class,  taking care of listening  for  clients,  and
setting  up  instances of the FTP-command  interpreter  class
when  this happens. The latter does the actual interpretation
of  the  FTP  commands,  talking to the  security  class  for
clearance  and  the  WinSock class for  communications.  Then
there are some utility-like classes, like those dealing  with
setup  and  logging.  By having all these  compartments  that
handle well defined tasks, I hope to be able to easily extend
this  FTP server and fix those (hopefully few) remaining bugs
quickly!

3.2 The SERV-U.INI File
-----------------------
All the settings for the server, users, and groups are stored
in  a  single file in text format. This file is always  named
SERV-U.INI.  When the program is started it  looks  for  this
file in a number of different places: First Serv-U checks the
command line in case an alternative setup file was specified.
Then  the  directory with SERV-U.EXE is checked. If  no  .INI
file  is found an environment variable SERV-U is checked.  If
this variable exists it should be set to the path where SERV-
U.INI is found. Finally, if this variable does not exist, the
whole DOS path is scanned, including the Windows directories.
The  first SERV-U.INI file found on the way is used. If after
all  the above no .INI file has been found, the program  will
create  one in the directory of  the Serv-U program.  Use  of
the  SERV-U  environment variable and the DOS path  makes  it
easy  to  set things up for network users where  there  is  a
single copy of the program but all the users needs their  own
settings. Serv-U uses the Windows built-in functions to  read
and  write  from/to the .INI file. A consequence of  this  is
that  the total size of SERV-U.INI can never exceed 64 Kbytes
on  Windows 3.1, 3.11 and Win95, thus limiting the number  of
users that can be set up. On NT there seems to be no limit to
the .INI file.

Well  now  go  over all the items that can appear  in  SERV-
U.INI.  I  will show you an invented setup file  which  helps
illustrating their use:

     [GLOBAL]
     Security=TRUE
     PortNr=21
     MaxNrUsers=15
     Invisible=TRUE
     Logfile=c:\serv-u\logfile.txt
     Logging=YES
     TryOut=Crippled
     LogGETs=ON
     LogPUTs=ON
     LogSystemMes=ON
     LogSecurityMes=ON
     LogFTPCommands=OFF
     LogFTPReplies=OFF
     LogIPNames=ON
     LogDirtyDetails=OFF
     LogFileGETs=ON
     LogFilePUTs=ON
     LogFileSystemMes=ON
     LogFileSecurityMes=ON
     LogFileFTPCommands=OFF
     LogFileFTPReplies=OFF
     LogFileIPNames=ON
     LogFileDirtyDetails=OFF
     LogIPDontLog=152.3.87.16,148.78.18.1??,231.89.23-45.*
     RegistrationKey=SqFgdfsdEvG,Rob Beckers,Cat Soft,1
     Window=100,100,400,300
     UserInfoWin=409,300
     DirChangeMesFile=index.txt
     DirChangeMesFile2=c:\serv-u\index.txt
     LinkFile=link.txt
     LinkFile2=c:\serv-u\link.txt
     CheckAnonPass=OFF
     Version=2.3.0.0
     StartIconic=NO
     AutoStart=YES
     LowerCaseFileDir=NO
     IPLog=15,ip.log
     SpeedLimit=102400
     DeletePartialUploads=YES
     EncryptPasswords=YES
     BlockFTPBounceAttack=YES
     BlockAntiTimeOut=YES
     ShowToolBar=Yes
     DirCacheEnable=YES
     DirCacheSize=20
     DirCacheTime=300
     
     [SIGNONOFF]
     SignOn1="Welcome to Robby's FTP-Server!"
     SignOn2="It  is  %time on %date and  you  are  user  no.
     %unow"
     SignOff1="Thanks for logging in!"
     SignOff2="Hope to see you again soon . . ."
     
     [IP-ACCESS]
     IP1=A,132.68.175.201
     IP2=A,101.43.23.30-40
     IP3=D,*.edu
     IP4=D,ftp.cat-soft.com
     IP5=A,*.*.*.*
     
     [USER=Anonymous@2]
     SpeedLimit=2048
     HomeDir=d:\anonftp2
     Access1=d:\anonftp2\upload,WP
     Access2=d:\anonftp2,RLP
     LoginMesFile=logmes.txt
     HideHidden=YES
     RelPaths=YES
     RatiosEnable=YES
     Ratios=BytesPerSession
     RatioUp=1
     RatioDown=7
     RatiosCredit=19968.000000
     
     [USER=Anonymous@1]
     HomeDir=d:\anonftp1
     Access1=d:\anonftp1\upload,WP
     Access2=d:\anonftp1,RLP
     LoginMesFile=logmes.txt
     OneLoginPerIP=YES
     IP1=D,*.se
     IP2=A,*.*.*.*
     
     [USER=Rob]
     Group=system
     Password=WdRx.Jlk0kemm
     HomeDir=c:\
     AlwaysAllowLogin=YES
     QuotaEnable=YES
     QuotaMaxCurrent=10240000,89739
     Access1=\,RWMCDLPE
     Access2=lpt1:,WM
     Access3=prn:,WM
     Access4=aux:,WM
     Access5=lpt2:,WM
     Access6=lpt3:,WM
     Access7=lpt4:,WM
     Access8=com1:,RWM
     Access9=com2:,RWM
     Enable=YES
     Note1=This is the sysadmin account
     Note2=Set up with unlimited privs.
     ChangePassword=YES
     TimeOut=20
     MaxNrUsers=5
     
     [USER=** Default **]
     HomeDir=y:\
     Access1=y:\,RL
     Enable=NO
     TimeOut=45
     
     [GROUP=SYSTEM]
     Access1=c:\system,RWDCMLEP
     Access2=d:\,RWDCMLEP
     Access3=y:\novell,RWDLP
     
     [RATIOS]
     Free1=*.txt
     Free2=\*\*.bat
     Free3=d:\gifs\sample.gif
     
     [IP-HOMES]
     IP1=152.3.110.168
     IP2=152.3.110.169
     
     [EXTERNAL]
     ClientCheckDLL1=CHKNOVELL.DLL
     ClientCheckDLL2=CHKNT.DLL
     EventHookDLL1=EVENT.DLL
     
     
Most  of  these settings can be changed and set interactively
through the Setup menus. The exceptions are the entries for
LogIPDontLog,   IPLog,  Invisible,   RegistrationKey,
QWindow,     UserInfoWin,    Version,     StartIconic,
ShowToolBar, ClientCheckDLL, and EventHookDLL.

The following paragraphs will describe each section and entry
in more detail.

[GLOBAL]
All  the settings related to the Serv-U program itself,  i.e.
the  functioning of the FTP server and system functions,  are
found  in  the  [Global] section. For the file  formats  of
directory change message files and  link files please see the
appropriate How to ... section.

If  security should not be enforced, the Security entry can
be set to FALSE or 0. Doing so will leave the FTP server wide
open to everybody!!! Default value for Security is TRUE.  A
related  entry is EncryptPasswords which is TRUE by default
and  controls if passwords should be encrypted or  saved  and
used as cleartext.

The  PortNr  entry determines the IP port that  the  server
will listen on. Default value is 21.

To  limit  the  maximum  number  of  simultaneous  users  the
MaxNrUsers  entry should be set to the desired  number.  No
entry  or  a negative number results in no maximum, only  the
number of available sockets will limit the number of users in
that case.

For  system  managers  that dont want their  users  to  mess
around with the server settings, it is possible to make Serv-
U  invisible by setting the Invisible entry to TRUE, or YES
and  put the Serv-U program in the startup group. When this
is done the server will not show up in the task manager list.
One  consequence is that there is no way to stop the  program
short of exiting Windows. Default is NO for this entry.

The LogFile entry should specify a full path and name for a
logfile  if logging is desired. There is no default  logfile.
To actually switch logging on and off the Logging entry can
be  set to ON or TRUE, or OFF or FALSE. Switching logging  ON
will  only  work  if  a  logfile  is  specified.  By  default
Logging is set to ON.

All  the LogXXXX entries switch logging options on  or  off
for  logging to the screen. The LogFileXXXX entries do  the
same for logging to file. Their names say it all, so Ill let
you  figure  them  out.  There is another  entry  related  to
logging,  LogIPDontLog, it specifies a list of  IP  numbers
which should not get logged. Using this entry makes those  IP
addresses  invisible to you. It is useful for keeping  server
check utilities like "WhatsUp" out of the log. The values  to
this  entry should be comma separated IP addresses which  may
contain wildcards and ranges.

The  next one deals with the way the program can be tried out
(when  there  is  no  registration  code).  TryOut  can  be
Crippled or Full. The first allows a user to do a maximum
of  5  GETs and 5 PUTs per session, switches the server  off-
line after 1 hour, and notifies clients that they are looking
at  an  unregistered try-out version. However,  it  does  not
contact my permission server. The Full option gives you  no
limitations while trying the program, it is exactly equal  to
the  registered version. The downside is that it does  access
my  permission server to ask for permission to run each  time
Serv-U  is  started. This is how the 30 days of  try-out  are
enforced.

The   RegistrationKey  entry  is  used  for  entering   the
registration  code. You get this code after registration.  By
default it has no value and for evaluation of the program  it
should be left blank or out of the .INI file.

The  next  entry is Window and this is set by Serv-U  every
time  the  program is stopped. It contains the last  position
and   size   of   the   program   window,   in   the   format
top,left,width,height. Likewise,  UserInfoWin  saves  the
window position of the user information window, in the format
top,left and ShowToolBar specifies if the toolbar  should
be shown or not.

Related  to this is StartIconic which stores if the program
should  start  as an icon. This happens when the  server  was
stopped while being iconized. Another option that affects the
way the server is started is AutoStart which for Windows 95
starts Serv-U as a system service if enabled.

To  enable  directory change messages you  have  to  set  the
DirChangeMesFile entry to a valid file name. This can be  a
complete  path  name, in which case the  same  file  will  be
displayed  for  all path changes, or it can be  a  file  name
only, which means Serv-U will look for that file in the  path
the  user  is  changing to. Likewise, DirChangeMesFile2  is
used  in case the file specified in DirChangeMesFile cannot
be found.

If  links  should be available and displayed  in  the  users
directory listings then LinkFile should be
set to the file name to use. The file name format is the same
as for DirChangeMesFile. In case LinkFile cannot be found
the server looks for LinkFile2.

To  check if anonymous passwords resemble an E-mail address
you can set CheckAnonPass to YES, ON or TRUE. Likewise, you
can  switch checks off by setting it to FALSE, NO or OFF, and
this  is  also  the default. In that case Serv-U  will  allow
anything as an anonymous password.

If  LowerCaseFileDir is TRUE all file and  directory  names
are  converted to lower case for directory listings and  file
uploads.  The  server  itself remains  case  insensitive.  By
default the case of names is preserved.

The IPLog entry is for controlling the automatic logging of
Serv-Us  IP address(es) to file. By default Serv-U logs  its
own  IP  address(es) once every 5 minutes  to  a  file  named
IPSERVU.TXT. The values for this entry are a time in  minutes
and  file name, separated by a comma. Specifying 0 for  the
time will disable IP address logging.

To   limit  the  total  bandwidth  used  by  the  server  the
SpeedLimit  entry is used. Its value is the maximum  speed
in  bytes/sec.  Setting  it to 0 or  a  negative  value  will
disable speed limiting, and this is the default.

Some FTP clients have the nasty habit of periodically sending
NOOP  commands  to keep the connection from timing-out.  This
can  be blocked by the BlockAntiTimeOut entry. Setting this
to  TRUE  will make Serv-U apply stricter rules to  determine
what constitutes idle time. By default this is disabled.

DeletePartialUploads determines if partially uploaded files
from  transfers  ending in an error should  be  automatically
deleted  by  the  server  or not. By  default  they  are  not
deleted.

To block FTP_bounce attacks the BlockFTPBounceAttack should
be set to TRUE. By default this is disabled.

Directory  listing caching is controlled by several  entries:
To  enable or disable it DirCacheEnable is used. By default
it  is enabled for the 32-bit version of Serv-U, disabled for
the  16-bit  version. The number of directory listings  which
are  cached is determined by the DirCacheSize entry.  Legal
values  are  0  through 150, default is 25  listings.  Cached
listings  are  discarded  after a  certain  amount  of  time,
regardless of use. This is set by DirCacheTime which is  in
seconds. Default time is 300 seconds.

Finally,  Version keeps track of the Serv-U version  number
and   is   automatically  updated  by   Serv-U.   Format   is
major,minor,revision,build no. and it is used for automatic
.ini file conversion.

[SIGNONOFF]
This section contains the messages that are displayed after a
user  contacts the FTP server and just before he disconnects.
Every  line  has a separate entry with a number at  the  end,
denoting  the order. The sign-on message is put in SignOnxx
entries  (with xx the line number), and the sign-off  message
is put in SignOffxx.

There  are  several special character combinations recognized
by Serv-U and they are expanded to their actual values when a
user logs on or off. They all begin with % and you can find
a  complete  list in the How to use sign-on and/or  sign-off
messages section.

A tip: Keep the number of lines and the their length limited.
Most  FTP clients will mess up lines over 80 characters,  and
since  a  FTP reply code is tagged to the beginning of  these
lines  before they are sent, it is wise to keep them to  less
then 75 characters.

[IP-ACCESS]
This  section determines which client IP-numbers or  IP-names
will  be  allowed access to Serv-U. There are  two  kinds  of
rules:  Those  that  refuse access  in  the  form  of  deny
entries,  and those that grant access using allow  entries.
If  this section doesnt exist, or no entries are found, then
all clients are allowed to contact the server. The reverse is
also  true,  if there is even a single entry then only  those
clients  will be allowed to contact the server that pass  the
rule.  All  entries are numbered sequentially  (IP1,  IP2
etc.)  and they are evaluated according to their number  from
first  to last. Numbers should be consecutive. As soon  as  a
rule  is  found that applies to the users IP name or  number
evaluation  is  stopped. For deny rules the  syntax  is  as
follows:  IP<number>=D,<rule>,  for  allow  rules  it  is
IP<number>=A,<rule>.  The  <rule>  section  can   contain
information about the IP-number(s) or IP-name(s) to which  it
applies.

The  IP-number  or name of the client is matched  section  by
section  to each rule until a match is found. If the matching
rule  is one of the deny rules, the client is disconnected.
If  the IP-name or number matches an allow rule then he can
proceed.  The  rules  can  be exact  IP-numbers,  or  contain
special characters. There are three of those:

     *    = wildcard, match any name/number section
     -    = denotes a range (for IP-numbers only)
     ?    = match any single character (for IP-names only)

Some  examples: The allow rule 132.*.76.48-89 will  allow
entry  to  clients with an IP-address starting with 132,  the
second section can be anything (0..255), the third must be 76
and  the  last  section should be between 48 and  89  (limits
included). Likewise, the deny rule *.se will bounce every
user  from  Sweden (for IP-names evaluation is done  starting
with  the last section and working towards the first  section
of  the rule). Keep in mind that if there are IP-access rules
there  must  be at least one applicable allow rule  or  the
client will not be allowed into the server.

[USER=Name]
The  information  about  a user is stored  in  this  section,
Name  stands for the users name. Each user has a  separate
section.  It  contains information needed to  authenticate  a
user  during login, and rules determining what this  user  is
allowed  to access. The Serv-U program will first check  this
section  for a regular user. If no applicable information  is
found  and  the  user is a member of a group,  the  group  is
addressed for the same information. If the result of this  is
still undetermined, the special user name ** Default **  is
searched.

Now  to  the  entries that can be found in this section.  The
identity  of  a  user is verified by comparing his  password,
after  encryption, with the one in the Password entry.  The
UNIX  crypt() command is used to encode the passwords. This
makes  it possible to extract users with their password  from
the  PASSWD file of a UNIX system, the same passwords  should
work  on  both systems. Unfortunately, there is not a  single
standard for password encryption on UNIX systems these  days.
Serv-U  uses the most common scheme, but this might not  work
for your system.

If  the  password matches, the home directory of the user  is
taken from the HomeDir entry. This should always be a  full
path name, including drive letter!

To make a user a member of a certain group, the Group entry
can  be  used.  All information needed and not found  in  the
users section; password, home dir and file/directory access,
are then  looked for in the groups section.

Information  about file and directory access for  a  user  is
stored  in  the Access entries. Each of these is  numbered,
and  access information is checked in order: first  comparing
it  to  the  first rule, then the second, etc. The  numbering
must  be consecutive. Access rules start with a path or  file
name.  These  paths are usually full names,  including  drive
letter.  If  the drive letter is missing, they apply  to  all
drives.  If different settings are needed for a subdirectory,
then  a  rule  with that directory should appear  before  its
parent,  i.e. with a lesser number (As a consequence  of  the
order in which Serv-U evaluates access rules). The path in an
access rule is followed by a comma and the access information
itself.  This  can be a combination of up to eight  different
characters:

     R    = read access to files
     W    = write access to files
     M    = modify access to files (implies write access)
     E    = execute access, for remotely starting programs
     C    = right to create subdirectories
     D    = right to delete subdirectories
     L    = directory list access
     P    = the rule propagates to sub directories as well

It  is entirely possible to have no access information at all
(only  a  path). This means that the user will not  have  any
access  to  that  path. One thing to realize  is  that  write
access  to a file does not imply read access! As you can  see
it is also possible to specify access rights for the parallel
and  serial  ports.  They are part of  the  regular  security
scheme  and to transfer to or from a port a user needs access
rights.  Then  finally, the path in an access rule  does  not
have  to point to a directory. It is also possible to specify
a filename. Of course, the C, D, L, and P rights will
not have any meaning then.

There are two special user names: Anonymous and ** Default
**. If there is an user Anonymous, it will be possible  to
log  into the server without a password. Instead, Serv-U will
ask  for the users E-mail address and log this. Most of  the
regular  entries  apply  for  Anonymous  as  well,   except
Password  and  Group, these are  ignored.  In  fact,  for
anonymous  users the sections for groups and ** Default  **
are never searched.

The  user ** Default ** is searched if no appropriate  rule
is  found  in  a users or the users groups entry.  It  can
contain  any  of  the regular entries and  in  essence  these
constitute  the default settings for user accounts  which  do
not have their own specific settings.

The  user account can be disabled by setting Enable to  NO.
By default accounts are enabled.

The  entry TimeOutUser specifies a time-out in minutes  for
the  user. If a FTP connection is left idle for the indicated
amount  of  time  it is automatically closed.  Filling  in  0
results in no time-out.

RelPaths  determines if users should be  treated  with  all
path  names  relative  to  their  home  directory.  This   is
desirable  for  use with WWW browsers that insist  on  having
access  to the root directory (/). Switching this on limits
users  to  the sub-tree of their home directory, they  cannot
switch to other drives. If you switch it off then users  will
see their full path. Default is switched off.

The  LoginMesFile  entry is used for pointing  to  a  login
message file that should be displayed to the user upon login.
The  same file name rules apply as for the DirChangeMesFile
entry,  and you can find more details about its usage in  the
How to setup user specific long messages section.

The  user  heading  can contain an added @  followed  by  a
number,  like [USER=Anonymous1@1]. This indicates that  the
user name is associated with a particular IP number for multi-
homed IP support. A list with IP numbers and their index  can
be found in the [IP-HOMES] section.

To  limit  the  maximum number of simultaneous  users  for  a
specific user account the MaxNrUsers entry should be set to
the desired number. No entry or a negative number results  in
no maximum for that account.

In  case  HideHidden is YES or TRUE all the files with  the
hidden  attribute  will not show up in directory  listings.
Default  this is NO. In case a user should always be  allowed
to  log  in,  even  when  the  user  limit  is  reached,  the
AlwaysAllowLogin setting should be TRUE or YES. Default for
AlwaysAllowLogin is NO. An option which  has  the  (almost)
opposite  functionality  is  OneLoginPerIP.  When  this  is
enabled  users are only allowed to log in once from the  same
IP address.

The  UL/DL  ratio settings are also part of  the  user  setup
info.   To   enable  the  use  of  ratios  for  a  user   the
RatioEnable setting should be set. The type of ratios Serv-
U  will  use is controlled by Ratios: The four options  are
FilesPerSession  which  counts  files  for  each   session,
BytesPerSession  which  counts  bytes  for  each   session,
FilesOverall  to  count  files  over  all   sessions,   and
BytesOverall which is for counting bytes over all sessions.
The  RatioUp  setting  specifies the  upload  part  of  the
upload/download equation, and RatioDown is for the download
part.  The  credit is stored in RatiosCredit, depending  on
the  type  of ratios used this can be in files or  bytes,
and  it can be a preset value for each session or the current
credit in case ratios are counted over all sessions.

In  case the users disk usage should be limited, disk  quota
limitations can be switched on by enabling QuotaEnable. The
QuotaMaxCurrent  value  keeps  track  of  the  maximum  and
current disk usage values in bytes.

To  make  life for system administrators easier you  can  add
notes to a user by using the Notexx (where xx is the line
number).  This is purely intended as a memory  aid,  and  not
used by Serv-U internally.

Just  like  the [Global] section each users setup  can  also
contain  a  SpeedLimit setting. This  limits  the  transfer
speed  for  each  logged-in user to the  limit  you  set  (in
bytes/second). Setting this to 0 or less means  there  is  no
speed limit, which is the default.

Finally,  user  settings  can also contain  IP  access  rules
similar  to  those  in the [IP-Access] section,  which  use
IPxx  entries (where xx is the line number).  Please  see
the notes on that section for details about the syntax.

[GROUP=Name]
These  sections contain the group info. The entries here  are
exactly the same as those for a user, except that the Group
entry has no meaning of course.

[IP-HOMES]
This section lists all the IP numbers that Serv-U should  use
for multi-homed IP support. Each line couples an index number
with    a    corresponding   IP   number    of    the    form
IPxx=yyy.yyy.yyy.yyy. In this xx is the index number (any
positive  number between 1 and 30000), and yyy... is  the  IP
number that should be associated with it.

When  a user name should be coupled to a particular IP  home,
the  index  number for that IP home is appended to  the  user
name, preceded by a @ character.

[RATIOS]
This is an auxiliary section for the use of UL/DL ratios.  It
allows  for  specifying a list of files which should  not  be
counted  by  the  ratio system. Each line use entry  Freexx
where xx is a sequential line number. The information after
the  equal  sign  is  the path or file name  that  should  be
discounted. File and path names may contain wildcards.

[EXTERNAL]
This  heading denotes a list of dynamic link libraries  which
Serv-U   should  use  to  very  user  access  or   do   event
notification.

For external user access entries of the form ClientCheckDLL
are  used. These are followed by an order number and  specify
the  file  name  of the DLL to use. In case the  Serv-U  user
database  does not provide an answer to access  requests  the
inquiry  is passed on to the first DLL in the list,  if  this
DLL does not have an answer it is send to the second DLL, and
so  on.  The DLL file should be either in the Serv-U  program
directory,  somewhere  in the DOS path,  or  in  the  Windows
directory for Serv-U to find it. External access verification
DLLs  are  discussed  in  greater detail  later  on  in  this
chapter.

The  second  type of DLL which Serv-U supports is  for  event
notification  and hooking into FTP events. This uses  entries
of   the   form  EventHookDLL,  and  as  with  the   access
verification DLLs there can be several of those.  Please  see
the appropriate section later in this manual for more details
on usage.

3.3 Using External User Access Verification DLLs
------------------------------------------------
Serv-U  can  use an external DLL to verify client access  and
retrieve information like a client's home directory  etc.  If
one  of  more  external DLLs are specified and Serv-U  cannot
find  the appropriate information internally it will question
each  of  the  external DLL's in turn. This can  be  used  to
create  an  interface to external user databases,  which  can
then  control FTP access. If the appropriate DLL exists,  for
example  the NT build-in user database could be  used,  or  a
Novell user database.

Setup
-----
To   make   Serv-U  use  external  DLLs  for  client   access
verification you need to add the DLL names to the  SERV-U.INI
file. At the moment there is no interactive user setup to  do
this, so the ini file has to be edited directly. There can be
more  than  one DLL, and Serv-U will query them in the  order
specified  until  one of the DLLs signals  that  it  had  the
required information.

The   DLL  names  need  to  be  added  to  a  section   named
'[EXTERNAL]'. The format is as follows (for example):

     [EXTERNAL]
     ClientCheckDLL1=CHKNOVELL.DLL
     ClientCheckDLL2=CHKNT.DLL
            .
            .

The  file names can be either full path names, or file  names
only.  If  the full path is specified then Serv-U  will  only
look at that path. If only the file name is given Serv-U will
first  look  in  the  program  directory,  then  the  current
directory,  the  entire  PATH, and  finally  in  the  Windows
directories.

DLL Specifications
------------------
The  DLL  entry  point for Serv-U needs to be  the  following
function:

     int HandleClientEvent(RClientEventStr* pEventStruc)

Please note that the function name is case sensitive!
The  function should return TRUE (=1) if it handled the event
and  does  not  want it to be passed on to the next  DLL.  It
should return FALSE (=0) in case it didn't handle the event.

The RClientEventStr structure is defined as follows:

     struct RClientEventStr {
       int Event;        // event code
       int  Flag;        // flag, meaning depends on event
       char User[40];    // user name
       char  Aux[512];   // auxiliary area, usage depends on event
       char HostIP[16];  // server IP home
     }

The 'Event' code determines the nature of the request and can
have the following values:

#define SRVU_LoginMesFile     1    // get login message file
#define SRVU_HomeDir          2    // get home dir
#define SRVU_Password         3    // verify password
#define SRVU_IPAccess         4    // verify IP access
#define SRVU_WriteFile        5    // verify write access
#define SRVU_ReadFile         6    // verify read access
#define SRVU_ModifyFile       7    // verify mod./del. file access
#define SRVU_ExecProg         8    // verify execute access
#define SRVU_ListDir          9    // verify dir listing access
#define SRVU_ChangeDir        10   // verify dir change access
#define SRVU_DeleteDir        11   // verify dir delete access
#define SRVU_CreateDir        12   // verify dir create access
#define SRVU_HideHidden       13   // get setting for 'hide hidden files'
#define SRVU_RelPaths         14   // get setting for 'relative paths'
#define SRVU_RatioType        15   // get setting for type of ratios
#define SRVU_RatioDown        16   // get setting for download ratio
#define SRVU_RatioUp          17   // get setting for upload ratio
#define SRVU_RatioCredit      18   // get/ajust ratio credit setting
#define SRVU_RatioFree        19   // verify if file is free for ratios
#define SRVU_QuotaEnable      20   // verify if disk quota is enabled
#define SRVU_QuotaChange      21   // change in disk quota
#define SRVU_QuotaMax         22   // maximum disk quota
#define SRVU_AlwaysLogin      23   // allways allow login
#define SRVU_OneLoginPerIP    24   // allow one login per user/IP pair
#define SRVU_LogClientIP      25   // log client from this IP address
#define SRVU_SpeedLimit       26   // maximum transfer speed
#define SRVU_PassChange       27   // change user's password
#define SRVU_TimeOut          28   // get user time-out value
#define SRVU_MaxUsers         29   // max. no. of users for account

Important  implementation notes: If your DLL does not  handle
an  event do not change anything in the event structure!  The
same  event  structure is passed on to other  DLLs,  and  any
changes  you  make to it while not handling  the  event  will
cause  the wrong information to be passed on. Also,  even  if
you  handle an event only change those items in the structure
as are indicated in the event details on the following pages!
For  example, if an event like SRVU_ListDir states that  only
the  Flag should be changed on return this means it has  to
return with the path in Aux[], just as it found it when the
DLL was called. Serv-Us code relies on this behavior in many
places  to save unnecessary copying of strings. For the  same
reason  you  should  never pretend  to  handle  an  event  by
indicating  this in the return value unless you  comply  with
all  the  event requirements. If, for example, SRVU_RatioType
requires a string indicating ratio type in Aux[] on  return
then  you must set this to one of those strings if you handle
the  event.  Telling Serv-U you handled the event  while  not
putting  a  value  in Aux[] on return  will  at  best  have
unpredictable  results  and at worst  cause  random  crashes!
Finally,  some  events  require you  to  set  the  Flag  to
indicate   if  the  DLL  handled  an  event  or   not,   like
SRVU_RelPaths  for example. This is in addition  to  the  DLL
function  return  value, which should also  indicate  if  the
event  was  handled or not. If the DLL is  not  handling  the
event it should not change the Flag value! I know this is a
rather convoluted way of working. In fact, thats exactly how
it  got  to  be:  The DLL mechanism closely follows  Serv-Us
internal  events  and  copies  rather  directly  between  its
internal  structures  and  the DLL structure.  To  keep  this
working for new types of events when Serv-U evolved it got to
be the way it is. Probably not the best way, but we are stuck
with it.

Event Details
-------------
SRVU_LoginMesFile
Retrieve the file name for the login message.
  On entry:
     User = user name
  On return:
     Flag = TRUE  (=1) if file name was found,  FALSE  (=0)
             otherwise
     Aux = file name of login message file, if one was found

SRVU_HomeDir
Retrieve the users home directory. The returned path  should
be a full path name including drive.
  On entry:
     User = user name
  On return:
     Flag = TRUE if home dir was found, FALSE otherwise
     Aux = home dir (full path), if one was found

  Note:
    In  case a user account is disabled 'no home dir'  should
    be returned.

SRVU_Password
Verify  if the users password is correct and the user should
be logged in.
  On entry:
    User = user name
    Aux  = password the user entered, after the \0 of  the
           password the original user name
           is passed, in original case and not truncated
  On return:
    Flag = TRUE if password was correct, FALSE otherwise

SRVU_IPAccess
Verify access of the client based on IP address/name.
  On entry:
    User = user name if available
    Aux  = IP address of client, in text format
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

  Note1:
    If  no  user  name  is present it means the  client  just
    connected  and a check should be made for server-wide  IP
    access.  If  a  user  name is present  access  should  be
    checked for that particular user only.
  Note2:
    If  a  symbolic IP name is available it is tagged  on  to
    the  IP address in Aux[] (ie. behind the first '\0').  If
    there's no IP name the IP number ends with a double  '\0'
    character.

SRVU_WriteFile
Verify  if  write access should be allowed for a file.  Write
access  does  not  include access  to  modify  or  delete  an
existing  file, only new files can be created and written  by
it.
  On entry:
    User = user name
    Aux  = full path of file
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_ReadFile
Verify if read access should be allowed for a file.
  On entry:
    User = user name
    Aux  = full path of file
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_ModifyFile
Verify  if modify access should be allowed for a file. Modify
access  allows the user to modify and delete existing  files,
this also automatically includes write access to the file.
  On entry:
    User = user name
    Aux  = full path of file
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_ExecProg
Verify if the user has the right to execute a program on  the
server.  Be  aware  that  allowing  execute  access  forms  a
potential  security hole since there is no control over  what
the program might do on the server. Also note that the actual
execution  is done via the FTP command SITE EXEC which  is  a
Serv-U specific extension and not part of the standard FTP.
  On entry:
    User = user name
    Aux  = full path of program name to be executed
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_ListDir
Verify if file list access should be allowed for a directory.
  On entry:
    User = user name
    Aux  = full path of directory
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_ChangeDir
Verify  if  change directory access should be  allowed  to  a
(target) directory.
  On entry:
    User = user name
    Aux  = full path of directory
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_DeleteDir
Verify  if  the user should be allowed to delete a directory.
Note  that this does not mean the user can delete directories
containing files, even if access is granted.
  On entry:
    User = user name
    Aux  = full path of directory
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_CreateDir
Verify if the user should be allowed to create a directory.
  On entry:
    User = user name
    Aux  = full path of directory
  On return:
    Flag = TRUE if access is allowed, FALSE otherwise

SRVU_HideHidden
Determine  if  files/dirs with the hidden attribute  should
not be shown on directory listings. By default all files/dirs
are shown on listings.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = Aux[0]=1 if server should hide 'hidden' files
           Aux[0]=0 if server should show 'hidden' files

SRVU_RelPaths
Inform the server if all paths reported to the user should be
shown relative to the users home directory. In essence  this
cuts  off  the home directory from all paths, i.e.  the  home
directory itself is shown as / when enabled.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = Aux[0]=1 if server should use 'relative paths'
           Aux[0]=0 for using full path names

SRVU_RatioType
Inform the server if upload/download ratios should be enabled
and if so, what  type of ratios should be used.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
           if  U/D  ratios  should be disabled  FALSE  is  also
           returned
    Aux  = set to the textual ratio type, as used in the  INI
           file, possible entries are
           "FilesPerSession" = count files for each session
           "BytesPerSession" = count bytes for each session
           "BytesOverall" = count bytes over all sessions
           "FilesOverall" = count files over all sessions

SRVU_RatioDown
Inform  the  server of the numerical value for  the  download
part in UL/DL ratios.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = set to the textual representation of the download
           ratio (an unsigned 32-bit number)

SRVU_RatioUp
Inform the server of the numerical value for the upload  part
in UL/DL ratios.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
    otherwise
    Aux  = set  to the textual representation of the  upload
           ratio (an unsigned 32-bit number)

SRVU_RatioCredit
Used  to either retrieve a users current UL/DL ratios credit
value,  or  to modify the existing value in case a "over  all
session" setting is used.
  On entry:
    User = user name
    Aux  = set to the textual representation of the value  to
           add  to  the  credit  (a floating point  number,  can  be
           negative)  set  to "0" if the request is  to  obtain  the
           current value
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = set  to the textual representation of  the  (new)
           credit  value  (a  floating point  number  which  can  be
           negative)

  Note:
    All  'credit' calculations should be done with sufficient
    precision. In C a double is recommended.

SRVU_RatioFree
Verify  if  a  file  should  not  count  towards  the  users
upload/download ratio credit.
  On entry:
    User = user name
    Aux  = set to the path/file name of the file to check  if
           it should be downloadable for free
  On return:
    Flag = TRUE if file is free, otherwise FALSE

SRVU_QuotaEnable
Verify  if  disk quota limitations should be  enabled  for  a
user.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = Aux[0]=1 if disk quota limitations are enabled
           Aux[0]=0 if no disk quota limitations

SRVU_QuotaChange
Used  to  either  retrieve a users current used  disk  quota
value or to ask for permission to change the quota value. The
DLL  should  actually change its notion of the current  quota
value  in  the  latter  case  to  correctly  handle  multiple
simultaneous users using the same account.
  On entry:
    User = user name
    Aux  = set to the textual representation of the value  to
           change   the   current  quota  with  (can  be   negative,
           decreasing available quota) set to "0" if the request  is
           to obtain the current value
  On return:
    Flag = TRUE  if request was granted by the  DLL,  FALSE
           otherwise
    Aux  = set  to the textual representation of  the  (new)
           credit  value (a number which should always be positive).
           Quota is counted in bytes.

SRVU_QuotaMax
Retrieve the maximum disk quota value for a user.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = set to the textual representation of the  maximum
           disk quota amount in bytes

SRVU_AlwaysLogin
Verify  if  the  user  should always be allowed  to  log  in,
regardless of the maximum no. of users set up in the  server.
If  this request is granted the user will also no longer have
an idle time-out value.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise
    Aux  = Aux[0]=1 if user should always be allowed to log in
           Aux[0]=0  if user should bounce if max. no.  of   is
           reached

SRVU_OneLoginPerIP
Verify if the user should only be allowed to log in once from
a specific IP address.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
    otherwise
    Aux  = Aux[0]=1 only one login allowed from same  IP
           number
           Aux[0]=0 multiple logins allowed from same IP number
    
SRVU_LogClientIP
Verify  if  an  IP  address  should  appear  in  logging   to
file/screen.
  On entry:
    Aux  = IP address of client, in text format
  On return:
    Flag = TRUE if client should be logged, FALSE otherwise

SRVU_SpeedLimit
Determine if a user should have a maximum network bandwidth.
  On entry:
    User = user name
  On return:
    Flag = TRUE  if  request  was  handled  by  DLL,  FALSE
           otherwise. In case no speed limit should be used  by  the
           server the DLL should also return FALSE.
    Aux  = set to the textual representation of the  maximum
           transfer speed in bytes/second
    
SRVU_PassChange
Attempt  to  change the users password. Note  that  this  is
preceded  by a SRVU_Password event to determine  if  the  old
password supplied by the user was correct.
  On entry:
    User = user name
    Aux  = the new password
  On return:
    Flag = TRUE  if the password was changed OK.  FALSE  if
           user is not allowed to change passwords.

SRVU_TimeOut
       On entry:
    User = user name
       On return:
    Flag = TRUE  if  request was  handled  by  DLL,  FALSE
           otherwise.
    Aux  = set to the textual representation of the time-out
           value in seconds, a value of "-1" means there is no time-
           out.
    
SRVU_MaxUsers
       On entry:
    User = user name

       On return:
    Flag = TRUE  if  request was  handled  by  DLL,  FALSE
           otherwise.
    Aux  = set to the textual representation of the  maximum
           number of concurrent users for this account a value of 
           "-1" means there is no limit.

3.4 Using Event Notification and Hook DLLs
------------------------------------------
Serv-U  can notify external DLL's of server events and  these
DLLs  can  block  certain  server events  (like  uploads  and
downloads).  This opens the way for add-ons  to  Serv-U  like
alternative  log file formats and filters for  uploads  and
downloads  as  well  as  all forms of automated  monitor  and
statistics  software. Because the SITE command  can  also  be
hooked  it is possible to extend the server with any  command
one would want to add! If you create an add-on which might be
useful  for other Serv-U users please let me know at Rob@cat-
soft.com.  The plan is to maintain a list of all  add-ons  at
the Serv-U Web site (http://www.ftpserv-u.com).

Setup
-----
To  make Serv-U use external DLLs for event notification  and
hooking you need to add the DLL names to the SERV-U.INI file.
There can be more than one DLL, and Serv-U will query them in
the  order  specified until one of the DLLs signals  that  it
wants  to  block an event (in other words, in  case  of  only
event notification Serv-U will call all available DLL's).

The   DLL  names  need  to  be  added  to  a  section   named
'[EXTERNAL]'.  There  is no interactive setup  interface  for
now, this will be made in a future version. The format is  as
follows:

      [EXTERNAL]
      EventHookDLL1=WULOG.DLL
      EventHookDLL2=SRVUHOOK.DLL
            .
            .

The  file names can be either full path names, or file  names
only.  If  the full path is specified then Serv-U  will  only
look at that path. If only the file name is given Serv-U will
first  look  in  the  program  directory,  then  the  current
directory,  the  entire  PATH, and  finally  in  the  Windows
directories.

DLL Specifications
------------------
The  DLL  entry  point for Serv-U needs to be  the  following
function:

     WORD CALLBACK HandleEventHook(RFTPEventStr* pEventStruc)

The following return values are possible:

#define REVNT_None      0     // nothing
#define REVNT_Proceed   1     // let event pass
#define REVNT_Abort     2     // stop event
#define REVNT_Suspend   3     // suspend event until decision is made

For  event  notification  only, the return  value  REVNT_None
should be used. All the other values are intended for hooking
of server events that can be passed or broken off by the DLL.
The  value REVNT_Proceed should be returned in case the event
can  proceed  as normal. REVNT_Abort is used to  make  Serv-U
abort  an  event in progress. The final value, REVNT_Suspend,
should  be used if the DLL cannot make an immediate  decision
and  wants the server to suspend the user for which the event
occurred until a decision is made at a later time. The latter
is  an  outflow  of  the way Serv-U is  made:  It  is  single
threaded using asynchronous sockets, so during processing  by
the  DLL  all server operations are halted. This is generally
not  a problem (the socket stack still continues sending  and
receiving  packets until its buffers are exhausted),  but  if
the DLL needs more than a second or so to process the request
it  should  spawn a separate thread and return REVNT_Suspend.
It  can then signal via a message at a later time that it has
an answer ready. More on this mechanism later.

Important  implementation notes: Do not  change  any  of  the
fields  in the event notification structure unless explicitly
instructed  to  in the event details! Serv-U  relies  on  the
constancy of a number of event notification structure  fields
internally,  to save the overhead of copying the same  values
into  this structure again and again. Changing anything which
was supposed to be constant is inviting disaster!

The event notification structure is as follows:

     struct RFTPEventStr {

       // event info
       DWORD  Event;          // event code
       DWORD  SubEvent;       // sub-event code

       // user info
       DWORD SessionID;       // unique ID of the FTP session
       char User[40];         // user name
       char ClientIP[16];     // IP number of client
       char  LocalIP[16];     // IP number the client connected to

       // event attributes
       DWORD Duration;        // duration of events (in seconds)
       DWORD Size;            // size of object (i.e. file)

       // hook info
       HWND hWindow;          // window handle to post decision to
       UINT Message;          // message to post
       char* pReplyText;      // pointer to text to send to user

       // scratch pad area
       char AuxOne[512];      // auxiliary area one
       char AuxTwo[512];      // auxiliary area two
     };

Not  all fields are used for every type of event. Which  ones
are used for specific events will be discussed later. Most of
the  fields  do  have a specific meaning  which  is  constant
throughout  their usage. Several fields are  always  present,
for  every event notification call, and the handler  DLL  can
assume  they  are valid at all times. These are: 'SessionID',
'ClientIP',   'LocalIP',  'hWindow',   and   'Message'.   Not
explicitly mentioned, but also always available as soon as  a
user name is known by the server is the User field.

The events codes used for notification are:

#define EVNT_None       0     // none
#define EVNT_IPName     1     // symbolic IP name available
#define EVNT_Connect    2     // connection was made
#define EVNT_Close      3     // closed connection
#define EVNT_BouncedIP  4     // bounced client because of IP address
#define EVNT_TooMany    5     // bounced user because there are too many
#define EVNT_WrongPass  6     // too many times wrong password
#define EVNT_TimeOut    7     // connection timed out
#define EVNT_Login      8     // use logged in
#define EVNT_StartUp    9     // start upload of file
#define EVNT_EndUp     10     // successful upload of file
#define EVNT_StartDown 11     // start of download of file
#define EVNT_EndDown   12     // successful download of file
#define EVNT_AbortUp   13     // aborted upload
#define EVNT_AbortDown 14     // aborted download
#define EVNT_Rename    15     // renamed file/dir
#define EVNT_DelFile   16     // deleted file
#define EVNT_DelDir    17     // deleted dir
#define EVNT_ChgDir    18     // changed working directory
#define EVNT_MakeDir   19     // created directory

Sub-event codes are:

#define SEVNT_None       0     // no sub-event
#define SEVNT_ErrWrite   1     // problem writing to disk
#define SEVNT_ErrRead    2     // problem  reading  from disk
#define SEVNT_ErrQuota   3     // insufficient disk quota
#define SEVNT_ErrTOut    4     // packet timed out
#define SEVNT_ErrAbort   5     // user aborted transfer
#define SENVT_ErrUnknown 6     // unknown error
#define SEVNT_ErrClose   7     // data connection closed unexpectedly

Notifcation Events
------------------
The following is a description of all events of which the DLL
is  notified.  The  handler  function  should  always  return
REVNT_None  (Actually the return value is  ignored,  but  for
future extensions it's a good idea to stick to REVNT_None).

Symbolic IP name available
Is sent as soon as a symbolic IP name becomes available. This
only happens if IP name logging for that user is switched on,
or if the IP access rules require a symbolic IP name.

     Event = EVNT_IPName
     SubEvent = SEVNT_None
     AuxOne = symbolic IP name

Client connected to server
Is  sent  when a FTP client connects to the server.  This  is
normally the first event to occur for a client.

     Event = EVNT_Connect
     SubEvent = SEVNT_None

Client disconnects from server
Just  before the client is disconnected from the server  this
event is sent. This is normally the last event to occur.

     Event = EVNT_Close
     SubEvent = SEVNT_None
     Duration = connection time in seconds

Client bounces because of IP name/address
In  case the client's IP address or symbolic IP name  do  not
pass the IP access rules of Serv-U this event is posted.

     Event = EVNT_BouncedIP
     SubEvent = SEVNT_None
     AuxOne = set  to symbolic IP name if available,  empty
              string otherwise
     User = set to user name in case the IP  access
            rules were user specific

Client bounces because of no. of users
Event used when the limit of concurrently logged in users  is
reached.

     Event = EVNT_TooMany
     SubEvent = SEVNT_None

Wrong password
In  case the user tried too many times to log in and did  not
have a correct password.

     Event = EVNT_WrongPass
     SubEvent = SEVNT_None

Client has been inactive too long
Is  sent  when the inactivity counter times out. This  occurs
just before the connection is closed.

     Event = EVNT_TimeOut
     SubEvent = SEVNT_None

Client logs in
Gets posted immediately after a client logs in successfully.

     Event = EVNT_Login
     SubEvent = SEVNT_None
     AuxOne = password (for anonymous users only)

Start of file upload
Is  sent when an upload is started, i.e. transferring a  file
from client to server.

     Event = EVNT_StartUp
     SubEvent = SEVNT_None
     AuxOne = file name (complete path)

End of file upload
Posted when a file has been uploaded successfully.

     Event = EVNT_EndUp
     SubEvent = SEVNT_None
     AuxOne = file name (complete path)
     AuxTwo = transfer mode (as text)
     Duration = duration of upload in milliseconds
     Size = file size in bytes

Start of file download
Is  sent when a download is started, transferring a file from
server to client

     Event = EVNT_StartDown
     SubEvent = SEVNT_None
     AuxOne = file name (complete path)

End of file download
Is sent when a file has been downloaded successfully.

     Event = EVNT_EndDown
     SubEvent = SEVNT_None
     AuxOne = file name (complete path)
     AuxTwo = transfer mode (as text)
     Duration = duration of download in milliseconds
     Size = file size in bytes

Aborted file upload
Occurs in case of an error during a file upload.

     Event = EVNT_AbortUp
     SubEvent = One of the sub-event codes
     AuxOne = file name (complete path)
     AuxTwo = transfer mode (as text)
     Duration = duration of upload in milliseconds until the error
     Size = bytes uploaded when the error occured

Valid    SubEvent's   are   SEVNT_ErrWrite,   SEVNT_ErrQuota,
SEVNT_ErrAbort,        SEVNT_ErrClose,         SEVNT_ErrTOut,
SEVNT_ErrUnknown, and SEVNT_None.

Aborted file download
Gets posted in case of an error during a file download.

     Event = EVNT_AbortDown
     SubEvent = One of the sub-event codes
     AuxOne = file name (complete path)
     AuxTwo = transfer mode (as text)
     Duration = duration of download in milliseconds  until the error
     Size = bytes downloaded when the error occured

Valid    SubEvent's   are   SEVNT_ErrRead,    SEVNT_ErrAbort,
SEVNT_ErrClose,    SEVNT_ErrTOut,    SEVNT_ErrUnknown,    and
SEVNT_None.

Renamed file or directory
Is sent when a file or directory is renamed successfully.

     Event = EVNT_Rename
     SubEvent = SEVNT_None
     AuxOne = original file/dir name (complete path)
     AuxTwo = new file/dir name (complete path)

Deleted file
Is posted when a file is deleted successfully.

     Event = EVNT_DelFile
     SubEvent = SEVNT_None
     AuxOne = name of deleted file (complete path)

Deleted directory
Is posted when a directory is deleted successfully.

     Event = EVNT_DelDir
     SubEvent = SEVNT_None
     AuxOne = name of deleted directory (complete path)

Changed directory
Is sent when user changed to a new directory.

     Event = EVNT_ChgDir
     SubEvent = SEVNT_None
     AuxOne = new working directory (complete path)

Created directory
Gets posted when user created a new directory successfully.

     Event = EVNT_MakeDir
     SubEvent = SEVNT_None
     AuxOne = newly created directory (complete path)

FTP Command Hooks
-----------------
So  far  the event notification was 'passive'. The DLL  would
get  informed  of   events but was not able to  intervene  in
them.  There are a number of 'hook events' that let  the  DLL
actively  participate in FTP commands. The DLL can decide  to
abort the command, or let it proceed. The hooking events are:

#define EVNT_HookDown    100      // hook for file downloads
#define EVNT_HookUp      101      // hook for file uploads
#define EVNT_HookAppend  102      // hook for append file upload
#define EVNT_HookUnique  103      // hook for unique name upload
#define EVNT_HookRename  104      // hook for rename file/dir
#define EVNT_HookDelFile 105      // hook for delete file
#define EVNT_HookDelDir  106      // hook for delete dir
#define EVNT_HookMkd     107      // hook for make directory
#define EVNT_HookSite    108      // hook for the SITE command
#define EVNT_HookChgDir  109      // hook for change dir command

The procedure is as follows: A hooking event is passed on  to
the  DLL  after the initial tests for that command have  been
passed.  For  example,  for a file download  the  user  needs
access to that file, and the file has to exist. When the  DLL
receives  a hooking event it can decide between three  return
codes,  REVNT_Proceed  is  used to  let  the  event  proceed,
REVNT_Abort  stops the event from proceeding and  aborts  the
FTP command initiating it, and REVNT_Suspend is a return code
that  puts  the command interpreter for the client  on  whose
behalf the event was posted in suspended mode. This means  no
commands are accepted during that time (all other clients can
proceed  normally), and the server waits for a  message  from
the  DLL telling it to call back to get the decision  if  the
event can proceed or not.

The  REVNT_Suspend  code  and  the  reason  Serv-U  needs  it
warrants  a  little more explanation. Serv-U  was  originally
made  in the good old Windows 3.1 days when there was no pre-
emptive  multi-tasking. To make a server that  really  works,
'asynchronous' sockets were needed which resulted in a server
that  is  single-threaded and hard  to  change  in  a  multi-
threaded  design. In this particular case of catching  events
and deciding if they should proceed or not this is important.
Because Serv-U is single-threaded the server is blocked  from
serving  other clients while it is in the event  notification
DLL!  This  is not a problem if the DLL decides fast  whether
events can proceed or not (i.e. within a second or so).  But,
if  the  DLL needs to do a lot of processing, or if it starts
an  external program which will take an indeterminate  amount
of  time,  it would be a bad idea indeed to block the  entire
server meanwhile.

In case the DLL needs time to process the event the procedure
is  therefore to let the DLL spawn another thread to  do  the
processing  and  return  REVNT_Suspend  immediately  to   the
server.  This  will make the server go on with other  clients
while  it  waits for a reply from the DLL. When  the  DLL  is
ready  with  a  reply  it should post  a  message  using  the
hWindow  and Message fields of the event structure,  with
the  client  ID  in  the message WPARAM  field.  When  Serv-U
receives the message it notifies the DLL with the exact  same
event that resulted in the suspension, and the DLL should now
return either REVNT_Proceed or REVNT_Abort. In case it aborts
the  event  the  DLL should also supply a pointer  to  a  FTP
command  reply message in the 'pReplyText' field,  indicating
to the client why the command was aborted. This reply message
should  have the correct FTP reply code (generally  550)  and
syntax (see RFC959)!

Command  replies can consist of multiple lines. If so,  those
lines  need  to follow the correct FTP reply code and  syntax
(i.e.  each line starts with a reply code and all except  the
last  line have a hyphen after the reply code). Keep in  mind
though  that  many  FTP  clients do  not  support  multi-line
command  replies for the commands being hooked, and they  may
get  confused or lock up (the command line client which comes
with Windows 95 is an example of one of those, older versions
of WS_FTP are others). Reply messages may also contain any of
the % message directives, they get expanded just before the
reply is sent.

To  summarize,  a step-by-step overview of the event  hooking
procedure:

1) Server sends a event hook notification to the DLL

2) DLL  can  decide immediately to either let the  command
   proceed  or abort using the return values REVNT_Proceed  or
   REVNT_Abort.

3) If  DLL  needs  time to decide it should spawn  another
   thread to do the processing and return REVNT_Suspend.

4) When processing is completed after suspending the client
   the DLL should post a message using the parameters:

       RFTPEventStr.hWindow     = window to post message to
       RFTPEventStr.Message     = message to post

   The  WPARAM field of the message should contain the  client
   ID from 'RFTPEventStr.SessionID'.

5) Serv-U will send the exact same hooking event to the DLL
   after receiving the message and the DLL should now reply with
   either REVNT_Proceed or REVNT_Abort.

6) In  case REVNT_Abort is used (regardless if the command
   was    suspended    or   not)   the    DLL    should    set
   RFTPEventStr.pReplyText to point to a FTP  command  reply
   message. The reply can be multiple lines and may contain any
   of the '%' directives. The command reply text MUST follow the
   correct FTP syntax (see RFC959) including reply codes!! Serv-
   U  doesn't  check the syntax, but not complying would  very
   likely confuse the  FTP client.

In  case  there are multiple DLLs for event notification  and
hooking  Serv-U will send hooking events to the DLLs  in  the
order  in which the DLLs are entered in the SERV-U.INI  file.
Serv-U   stops   passing  events  on  when  a   DLL   returns
REVNT_Suspend or REVNT_Abort, i.e. the remainder of the  DLLs
in the list will not receive the hooking event.

Hooking Events
--------------
The  following  is a description of all events  that  can  be
hooked.  The  default fields mentioned for event notification
are   the   same   for  hooking  events  (i.e.   'SessionID',
'ClientIP', 'LocalIP', 'hWindow', and 'Message', while User
is available as soon as a name is known).

File download
Is sent in case the client wants to download a file.

     Event = EVNT_HookDown
     SubEvent = SEVNT_None
     AuxOne = name of file to download (complete path)

File upload, append, or upload using a unique file name
Is  sent in case the client wants to upload a file, append to
a file, or create a unique file.

     Event = EVNT_HookUp, EVNT_HookAppend, or EVNT_HookUnique
     SubEvent = SEVNT_None
     AuxOne = file to upload (complete path)

Rename file or directory
Occurs when client wants to rename a file or directory.

     Event = EVNT_HookRename
     SubEvent = SEVNT_None
     AuxOne = original file/dir name (complete path)
     AuxTwo = new file/dir name (complete path)

Delete file
Posted when client wants to delete a file.

     Event = EVNT_HookDelFile
     SubEvent = SEVNT_None
     AuxOne = name of file to delete (complete path)

Delete a directory
Is sent in case the client wants to delete a directory.

     Event = EVNT_HookDelDir
     SubEvent = SEVNT_None
     AuxOne = directory to delete (complete path)

Create a directory
Is sent in case the client wants to create a directory.

     Event = EVNT_HookMkd
     SubEvent = SEVNT_None
     AuxOne = directory to create (complete path)
     
Site command
Hooks  the SITE command, thus allowing for *any* FTP  command
extension. The FTP command SITE is intended for site-specific
command extensions. Serv-U uses it for executing programs  at
the  server  side,  via SITE EXEC. The FTP  specs  in  RFC959
recommend   all  site-specific  command  extensions   to   be
implemented via the SITE command.

     Event = EVNT_HookSite
     SubEvent = SEVNT_None
     AuxOne = command argument

Change working directory
Sent in case the client wants to change to another directory.

     Event = EVNT_HookChgDir
     SubEvent = SEVNT_None
     AuxOne = directory to change to (complete path)


4. Getting In Touch - Bugs & Registration
=========================================
Serv-U  is  made  by  Cat  Soft and  published  by  Deerfield
Communications  Inc.  For  all sales  and  support  questions
Deerfield.com is the place to ask. There are several ways  to
get in touch:

     Deerfield Communications Inc.
     4241 U.S. 27 South
     P.O. Box 851
     Gaylord, MI  49735
     (517)732-8856 Voice
     (517)731-2642 Fax
     
     Serv-U Web site URL: http://www.ftpserv-u.com/

     Discussion Forum and Pre-Sales Tech Support: http://forum1.deerfield.com/~ftpserv-u
     
     Tech Support Request Form: http://www.ftpserv-u.com/support.htm
     
     Tech Support Email: support@ftpserv-u.com
     
     General information Email: info@ftpserv-u.com
     
     Sales information Email: sales@ftpserv-u.com

For  bug reports, of if you want to offer suggestions you are
most welcome to drop me a line. The address is:

     Rob@cat-soft.com

The Cat Soft Web site can be found at:

     http://www.cat-soft.com/


4.1 Serv-U Discussion List
--------------------------
There  is  a  discussion  list  for Serv-U  where  you  can  ask
questions and discuss Serv-U related topics. To subscribe  to
the Serv-U mailing list, send an E-mail message to:

     serv-u-request@cat-soft.com

with  only  a  single line in the message body, which  should
read:

     subscribe

This  will  return a message from the list manager  within  a
minute  or  so, explaining in detail how to post messages  to
the  list and related matters. I am also subscribed  to  this
list,  so each message you post will reach my E-mail  box  as
well.  When needed Ill respond to your message, but my  hope
is  that others will reply to, thus cutting down a bit on the
flood of messages I have to answer each day.

There  is  also a digest version of the discussion  list.  By
subscribing  to this list you will receive one  message  each
week  with  all the messages posted to the list  during  that
past  week. To subscribe to the digest list, send  an  E-mail
message to:

     serv-u-digest-request@cat-soft.com

with a single line in the message body, reading:

     subscribe

If  you want to look through previous postings to the mailing
list   (an  invaluable  source  of  information  for  solving
problems), please take a look at the Serv-U list archive at:

     http://www.pacemail.com/hyper/

4.2 Reporting Bugs
------------------
Nothing  in  this world is perfect, least of  all  me!  Alas,
chances are that despite careful testing youll still find  a
bug. Please dont think others will report it, let me know at
Rob@cat-soft.com! There are a few things I need  to  know  in
order to improve chances of fixing the beastie, so take  note
of the following:

     * Most important: Can you get the same bug to appear by
       repeating certain actions? Please try hard; without a recipe
       for repeating a bug, its going to be very hard to track it
       down.
     * Which version of Serv-U are you using? And is this the
       16- or 32-bit program? You can find this information in the
       help - about menu choice of Serv-U.
     * What TCP/IP and WinSock stack are you using? Brand/type
       and version number please. What operating system (DOS version
       and Windows or Windows-For-Workgroups, Windows 95/98, NT
       version x.xx)? Any memory manager (QEMM etc.), what version?
     * Please indicate also if this bug is merely cosmetic or
       of vital importance for using Serv-U. Somewhere in between is
       possible as well of course. By the way, I consider security
       related bugs very important!
     * Finally, please give me a chance to fix a bug, before
       you start to shout all over the Internet how bad this program
       is . . .
     
4.3 Registering Serv-U
----------------------
If  youre happy with the performance of Serv-U, then  please
make  me  happy and register this program! Your  registration
fee  is  going  to motivate me to continue improving  Serv-U.
Registration  will also give you the nice,  warm  feeling  of
having directly contributed to improving my earthly wealth!

For   on-line   registration,  registration  questions,   and
everything else related to registration please see the Serv-U
Web site at:

     http://www.ftpserv-u.com/purchase.htm

There are steep discounts for multi-copy licenses, so if  you
need lots of Serv-U be sure to check out the price list. Serv-
U  is  also  available for OEM use and embedded  applications
(bundled with other software). If you have special FTP server
needs  do not hesitate to tell us about them. To get in touch
with a Deerfield.com sales representative send E-mail to:

     sales@ftpserv-u.com
