The FTP server program Serv-U and its documentation are copyright Cat Soft. 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 Block Users That are "Hammering" Your Server

2.18 How to Allow Users to Resume Uploading a File

2.19 How to Improve Server Performance

2.20 How to Print via FTP

2.21 How to Execute Programs via FTP with Serv-U

2.22 How to Use Serv-U with 'SLIP/PPP Emulators'

2.23 How to Use Netscape to Access Serv-U

2.24 How to Let the Whole World into Your Server (and Delete All Your Files)

2.25 How to Use Multi-Homed IP Support

2.26 How to Make 'Passive' Mode Data Transfers Work Behind a Firewall

2.27 How to Have Serv-U Start Automatically as a System Service

2.28 What's All This 'OTP S/KEY' Mumbo Jumbo?

2.29 How to Extend Serv-U with New Commands and Capabilities

2.30 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 Discussion 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 client's 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 didn't 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 couldn't 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.5, was made four years later, and consists of over 30000 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 15000 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 don't want the whole world knocking at your door (that is to say: they can knock, but they won't 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'.

Support for S/KEY 'one time passwords'.

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-U's 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 and automatic log file rotation! 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 you'll get will be v 17217c216r ery 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 commercial implementations, Serv-U is dirt cheap: around 0.1 per line of code!

If you didn't register this program, then you're looking at the try-out version of Serv-U. When started for the first time, it'll 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. Let's continue with the actual documentation. First thing will be how to install Serv-U to get you into business.

1. Making It Work - Installation

You're eager to get things going, but a little afraid of what lies ahead. Never fear, it couldn't be simpler. So let's 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.HLP - The on-line help file

SERV-U.CNT - The on-line help contents file

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 file:

SERV-U.INI - File containing all settings and user information

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 Microsoft's 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 Window's '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 the 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 a 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] [/s] [ini-file]

Here is what they will do:

/ h = Hide the server after startup.

/ i = Start the server as an icon.

/ u = Stop 'unconditionally'.

/ s = Only start if there is no other instance of Serv-U.

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. The other way to hide the server is by adding a line to the SERV-U.INI file, see section 3.3 for the details on that. All you can do to stop the server when it is started invisible 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. The '/s' option is for those that automatically start Serv-U from some script and are not sure if another instance of Serv-U is already running. When the '/s' option is specified Serv-U will immediately exit if it finds another active instance, insuring there will be only one copy of Serv-U running on the system.

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 heart's 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! Let's 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 'Setup - 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's setup does not have anything specific. Serv-U creates it to set up a default user time-out value so people cannot stay logged in forever, but you'll hear all about that in chapter 2. Now I'll 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. Let's 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 we'll 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 let's also set a time-out. Fill in a reasonable value, say ' ' minutes for the time-out value and hit the 'OK' button.

That's 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 than '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 don't 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.

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: 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 2.9 which explains the details on Serv-U's logging.

Also check out the add-on section on the Serv-U Web site at https://www.ftpserv-u.com and the FTP section at ftp://ftp.cat-soft.com/Add-Ons/. 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 there are no known bugs left in the program. 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 (https://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, this goes especially for the 16-bit versions of Windows. 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 can store the current IP address in a file which is updated periodically. The logging setup later in this manual has the details. 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 https://www.ftpserv-u.com/. There are more sophisticated programs for this at the various program repositories, check out for example https://www.tucows.com. There are also Web sites offering a fixed symbolic IP name which is linked to your changing IP address. Take a look at https://www.dynip.com/ for one of those.

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 don't know and you can never be sure!

I know this is not much of a deal, so I'll 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 30000+ lines of it) and we'll 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 you'd 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 hasn't been present for a few hours, or if it's 4 in the morning, starts sending over the whole hard disk to unknown destinations. This kind of thing is not easy to detect, don't 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 don't 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". J

That is all I have to say about installing Serv-U. Next let's 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 shouldn't 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-U's 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, let's 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 you're 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 that's 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 ease.

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! Strangely Windows 98 seems to be a step backwards in stability and usefulness. Many have reported the system runs out of sockets even though only few FTP users are logged in. There have also been reports of crashes which only affect Windows 98, the same would work fine under Windows 95 or NT. 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: Let's just say that even on your grandmother's 486 you don't 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 any FTP client program on the same PC as where the server is running and transfer some large 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/98 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 don't 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-U's 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 server's 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 this 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, also named 'FXP'. These actually work by specifying the other server's IP address for data transfers rather than the client's 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 you'll 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, let's 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 let's take a closer look at the various fields in the 'Setup Users' dialog box. I've 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 won't 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. Don't 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 you'd 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 user's 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 don't 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 user's 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 latter's 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 let's 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 user's 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 he'd 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 don't 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 'Allow only XX login(s) 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, and specifying a maximum, you force your users to a maximum number of concurrent sessions. When using this keep in mind that some FTP clients (Internet Explorer being one) log in multiple times by default. They will fail to work with Serv-U if too few sessions are allowed.

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 user's 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 (see https://www.ftpvoyager.com/). 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 [email protected] 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 won't 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. Only those users that have 'Always allow login' checked can bypass the server-wide user limit. Useful if you are the system administrator and want FTP access.

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 user's settings at all times in the 'Setup Users' dialog box. This includes the user's 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: Let's 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, let's 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 (I'm a nice guy, so you'll get warned first when attempting this)!

If you're 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 user's 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-U's 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 rule, no access! So, there is one path you might always want to put in the list: The user's 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 won't get in.

Let's 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 downloaded from the PC.

'Write' access, allows files to be uploaded to the PC, but not changed, deleted, or renamed.

'Append' access, allows a user to append to an existing file. Having 'Append' access automatically includes write access.

'Delete' access, allows the user to change files, rename, or delete them. Having 'Delete' access automatically includes write and append access (although it does no harm to specify those as well).

'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.

'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 let's 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 that 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.

'Append' access is mostly to allow users to resume uploading a partially uploaded file. Sometimes users can resume uploading without append access, having write access, but only if certain conditions are met: The user must connect from the same sub-net as where the original upload took place from, the user has to resume exactly at the end of the file, and the user has to resume the upload within 12 hours of the initial attempt.

'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 that's when unchecking it can come in handy.

When a user executes an FTP command concerning files or directories, the user's 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, let's 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 don't 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 won't 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, append, delete, list, make, remove, inherit

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. Let's 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 don't 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.

You thought you know it all by now, but there is one more way to define access in Serv-U's access rules. You can use single names, without a path, and it will be applied to every file and directory name, on every drive. Moreover, the names can contain wildcards. This is typically very useful to block access to certain files for all the dirs the user has access to. Say we don't want them to upload (or rename) .EXE files. Also, we're using files named LINKS.TXT for link info and don't want them to show to the user. A realistic setup for a user with homedir C:\USERS\JOE would be (again, the order here is important!):

*.EXE - no access

LINK.TXT - no access

C:\USERS\JOE - read, write, delete, list, makedir, removedir, inherit access

Now you know it all! Hopefully this was not too confusing. Best is to experiment a bit and you'll soon get the hang of it.

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/98 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:'.

Let's 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.

We're 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 don't 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 won't be able to log in.

While we are in the miscellaneous options dialog box let's also set up a few other things. We don't 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 don't 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, let's create a file named LOGANON.TXT with the following contents:

Welcome %name from %IP!

For the latest in nature's feline beauty see directory IMAGES

You can hear them in the directory MEOW

Please keep uploads smaller than 100 Kb and place them 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 user's 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 let's 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 anonymous 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 user's 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: It's 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: Let's 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 you're all set: The only thing left is entering the user names, you don't have to provide any other information per user. A 10 minute job.

Now there's this occasional guest user, 'BillyC'. You don't 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 you're 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 user's settings, then looks if the user is part of a group and if so uses this group's 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 you'll 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 on 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 don't 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 you're 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 user's IP address. The first is 'Refuse IP access in future'. If you check this and then press 'OK' the user's 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 user's 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. To make life a bit easier and avoid carpal tunnel syndrome from editing all those IP addresses there is the 'Calculate subnet' button. This will do the editing for you, and take the proper sub-net class into account. 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 user's 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.

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 the last five: The 'Log IP names' option will try to find the user's 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. Tthe 'Log WinSock activity' option 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. Finally there is 'Log access DLL activity'. This option will log any events dispatched to an external access verification DLL, and the results coming back from that DLL. This would only be of interest if were developing such a DLL and needed to see the dialog between Serv-U and the DLL. These last four 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 usually 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.

The options section also has a field labeled "Do not log clients from these IPs", and that's exactly what it does. You can specify one or more IP addresses, separated by commas, and any user from these IP addresses will not show up in the log. A convenient way to get rid of repeating log entries from programs which periodically check if the server is still running (like "WhatsUp"). The IP address can contain wildcards and ranges. In other words, you could enter an address like 192.*.23-56.6??.

The log file options allow you to specify information for logging to a file. 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. Next are a set of radio buttons to select automatic log file rotation. The latter means Serv-U will automatically start a new log file at certain time intervals. Supported are daily, weekly, monthly, and yearly log file rotation. Most of this will be self-evident. The 'Weekly' rotation option will always start a new log file on each Sunday.

'IP address logging' deserves a bit of explanation. The options in there control period logging of the server's IP address(es) to a file. This may be handy in case you have a dynamic IP address and some utility which can automatically update a static Web page with your current IP address by reading it from a file. With this explanation the options in there should be fairly clear now. They let you turn server IP logging on or off, select the interval between logging, and the file to which the IP address(es) are written. If you do not need this information it is better to leave server IP logging switched off, since it takes up system resources.

Before going into the details of log messages there is one final item in the logging setup dialog box. 'Log screen font' lets you choose the font to use for logging. In case you mess it up badly and want The Original font back there is always the 'Default font' button.

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 log file 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 - file downloads

4 - file uploads

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)

8 - Access DLL 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 downloads and uploads then Serv-U will also tell you the average transfer speed. For downloads 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, let's 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 into a file and making Serv-U use that file for a sign-on or sign-off message. The dialog box to set this up pops up when you choose the 'Setup - Messages' menu choice.

It is possible to have multiple server IP addresses, and user accounts specific to those server IPs. This is called "multi-homed IP", and for that reason Serv-U allows for different sign-on and sign-off messages for different server IPs. This means that a user will see a different message depending on the IP address they connect to. The 'Server home IP' drop-down list lets you select for which server IP you want to set up a message. If you do not have any particular home IPs set up it will only show one entry, named '<< All IP homes >>'. Any sign-on or sign-off message files you set up under this entry will be used whenever there is no specific file for the server IP the user is connected to. Or to say the same thing in less words, unless you need multi-homing just set up your sign-on and sign-off message files under '<< All IP homes >>'.

Any file names you enter should be full path names. You can use the little browse buttons ('. . .') to select a file or create a new one (just type a new name in the directory of your choice). Using these buttons will also open the file of your choice in your favorite text editor.

While the server is doing its job it stores all the sign-on and sign-off messages in memory to increase performance. Only once every 15 minutes will it check for changes in the messages or file names. If you use the browse buttons to select and edit the message files the server will immediately update its information, but if you change a message file outside of Serv-U it can take up to 15 minutes before the server starts using those changes.

There are several special words that you can enter in your sign-on and sign-off message 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

%LoggedInAll - displays total no. of logged in users since server start

%ServerAvg - displays the average server throughput since server start

%ServerKBps - displays current server bandwidth use

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 user's login name

%IP - displays the user's IP number or name if available

%Dir - displays the user's current directory

%Disk - displays the user's current disk drive

%DFree - displays the amount of free space on the user's 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 sign-on and sign-off message text: There is little point in putting '%disk' in the sign-on 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 what's left after the number of days is subtracted, and the same goes for the number of minutes and seconds.

All the above may sound a bit theoretical, so let's get practical and set up a simple sign-on message. Press the little button next to the 'Signon message file' part, so the file selection dialog box pops up. Say we want to store our sign-on message in a file named C:\SERV-U\SIGNON.TXT, so that is what we put in. Hit the 'Open' button and your text editor will pop up with that file loaded. Now it is time to enter the sign-on text itself:

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

Save the file, and you're in business! I'm sure you'll 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 sign-on 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 user's 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 user's 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 administrator's 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 you'd 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 it's 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 won't 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.

There are two ways you can set up links in Serv-U. There's the easy way using Windows 95/98/NT 'shortcuts' (only for 32-bit Serv-U), and the almost-as-easy way using text files. About as easy as things can get is by using Windows 'shortcuts'. Just create a shortcut where you want a link to show up, using Explorer's 'File - New - Shortcut' menu choice. Give the shortcut the name you want Serv-U to show as a link, and set the shortcut's target to the directory or file you want the link to point to. You're done! Whenever the user lists the directory with the shortcut they will see a link instead. Now that was easy, wasn't it?! The rest of this section deals with setting up links through text files, and if shortcuts work for you it is possible you want to skip this very interesting if not entertaining part. Do take a look at the notes at the end of this section though! They contain some very important information which also applies to shortcut links, and may help you figure out why a link is not showing even though you set it up right!

The other way to specify links in Serv-U is by using one or more text files. 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 doesn't 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 user's 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 you'd expect the result will be that the same links are shown in each and every directory. If you don't 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. Wasn't 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 file's attribute 'hidden' and enable the 'Hide hidden files' feature in the miscellaneous section of the user or group setup then users won't see the file itself appear in their directory listings while they still get to see the links.

In a typical situation you'd 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. You'd 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, let's say C:\SERV-U\ABSLINKS.TXT. A good candidate for the secondary link file would be a link to the user's 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 it's 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 I'm 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 don't 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 user's 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 user's 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 list access of the link's destination. 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.

Before we get on with the next subject there is one more thing you need to know about links. Say you have a link file C:\LINKS.TXT set up as the primary link file, so it shows its links in every directory. Well, almost, if there is a link (for example) "Fun Stuff | g:\public\games" in there it will not show up when the user is actually in G:\PUBLIC\GAMES. Just so you know.

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.

Let's 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 user's 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. Let's 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. Don't 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 user's 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 user's 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 doesn't 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 that's 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 what's 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 user's 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 (They'd 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.*

That's simple, isn't 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 PC's 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 '-' don't need to be at the end of the IP-numbers, any place will do. The rule 221.*.76-154.89 is perfectly OK. I wouldn't know when you'd need this, but, hey, the world is a strange place! Remember, the order of the rules is important. Experiment a bit, and you'll 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: *.*.*.*

Let's 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 user's 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 Block Users That are "Hammering" Your Server

If you have a popular FTP site and limit users there will always be those that do not want to wait and lack the 'netiquette' to try once in a while. Instead, they continuously connect, get rejected, and connect again, often every few seconds. This is also a popular tactic by malicious users to make your server unbearably slow (A 'denial of service' attack). Never fear, now you can strike back, and you can even do it in your sleep.

The 'Setup - Server' menu has an entry named "Block users who connect more than XX times within YY seconds for ZZ minutes". What this does when enabled is exactly as advertised: Serv-U keeps track of how many times a user connected in the past YY seconds, and if that is more than XX times it will automatically place that user on a list of temporarily blocked users. For the next ZZ minutes that user will immediately get disconnected as soon as this person tries to connect. There is no warning, no message, just disconnection (Which means you may want to tell your customers about this in a sign-on message so they know what to expect).

The mechanism used by Serv-U is very efficient. It can easily reject dozens of connections a second without missing a beat. An effective and low-overhead way to treat misbehaving users.

2.18 How to Allow Users to Resume Uploading a File

Serv-U supports resuming of partially uploaded files. This mechanism is always enabled and there is virtually nothing to set up for you. The only issue is that partially uploaded files should not be deleted, you can find this in the 'Setup - Server' menu and this is the default. Still, there are a number of issues related to uploading which you need to be aware off.

The first is that Serv-U locks files during an upload. This means that if a connection breaks during an upload it might take a while for Serv-U to recognize the connection is gone, and during all that time the file-being-uploaded stays locked, even for Serv-U itself. If the user would try to resume uploading to that file, even if he has sufficient access rights to do so, it will fail. The maximum time it can take for Serv-U to realize an upload is broken is 5 minutes. However, if the user had a good quality connection during most of the upload sequence this time will be lowered slowly to 1 minute and 30 seconds, which means that with a little luck the file will be free for resuming by the time the user tries again.

Now to the access rights required for resuming an upload. Normally a user needs at least 'Append' access to the file to resume an upload. Only 'Write' access will not usually do since that doesn't allow the user to change any existing file (including the partially uploaded file). There is an exception to this rule though, if a number of conditions are met: The user has to connect from the same sub-net as where the original upload took place from, and log into the same user account. The user has to resume within 12 hours after the upload attempt failed. The user must resume at the end of the partially uploaded file (the resume mechanism in FTP actually allows users to resume anywhere). The previous will work for many situations, but not all. Some ISPs have multiple sub-nets and a user may get assigned an IP address from another sub-net and thus be unable to resume. Still, it is a useful mechanism in case you can not grant append access to a directory.

If you really want allow resuming under all circumstances the conclusion from the above is that you will need to give the user at least append access.

2.19 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 don't need switched off. Things like IP access rules, speed limits, ratios, and disk quotas all eat up CPU cycles. Also don't 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 21^st 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 computer's 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.20 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 don't 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.21 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 doesn't 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 /C 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 doesn't 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. Another point to note is the '/C' option to COMMAND.COM. This makes the command interpreter run the subsequent command and terminate. Same option also works for NT's CMD.EXE command interpreter (there is no COMMAND.COM in NT, there you need to use CMD.EXE instead).

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-U's 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 program's 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.22 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 I'll 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.

If you are stuck with a SLIP emulator you may want to take a look at the section later on in this manual describing how to make "passive" mode data transfers work from behind a firewall. The same thing applies to SLIP emulators and it may be a way to make things work.

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

2.23 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:[email protected]/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 4's 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.24 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' I'll 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 don't tell me I didn't warn you (don't try to sue me either).

2.25 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. You can add a descriptive text to the IP addresses you enter, just ignore the entry for passive mode transfers (more about that later). 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. That's all there is to using multi-homed IP, it could not be easier!

The same dialog box also has a check box labeled 'Server listens on home IP addresses only'. Normally Serv-U will set up a single listening socket which responds to all incoming connections, regardless of the home IP they connect to. By checking this box Serv-U will set up a separate listening socket for each of the home IPs, and only respond to connections to those specific IPs. This makes it possible for you to have Serv-U use a few of many IP addresses on your PC, while another FTP server uses the others. The features works fine if you have a few dozen home IP addresses. If you have hundreds of them it is not recommended since the overhead of managing hundreds of sockets will affect performance.

Before leaving the subject of multi-homed IP let me also point out you can have home IP specific sign-on and sign-off messages. The section about setting up those messages has the details. There's nothing to it though. As soon as you have multiple IP homes set up you will see them in the 'Setup - Messages' dialog box and all will become clear.

2.26 How to Make 'Passive' Mode Data Transfers Work Behind a Firewall

If Serv-U is running behind a firewall with address translation you will notice that passive mode data transfers (as used by all Web browsers) do not work. The reason is that the IP address of the server is not the same as the IP address outside users should use to connect to the server. Serv-U does not know this, and when the FTP client program asks for its passive IP address it will give the wrong (internal) address.

What is needed is some way to tell Serv-U what IP address it should hand out to FTP clients when they want to do a passive mode data transfer, the right address is the IP address the outside world should use to connect to the server. This can be done via the 'Setup - IP homes' menu choice. In that dialog box you will find an entry for 'IP for passive mode', that is where the IP address to report to FTP clients goes.

Its actual use is very much like the multi-homed IP setup. Say your server is behind a firewall and has IP address 192.168.0.10. Now, the outside world accesses your server by using address 243.56.78.1. To make passive mode work you enter '192.168.0.10' for 'Home IP number', some description of your choice at 'Descriptive name' and '243.56.78.1' at 'IP for passive mode', then hit 'Add'. You just created a special IP home, which does passive mode address translation. To make the passive IP address work for FTP users make sure to select it in the 'Setup - Users' dialog box as the user's IP home.

The above assumes the firewall is set up to pass all the needed packets on to the server. In particular, this means the firewall has to allow incoming TCP connections to port 21 on the server, allow outgoing TCP connections from port 20 (for regular mode data transfers), and allow incoming TCP connections to any random port over 1023 on the server (for passive mode transfers).

2.27 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 either the 'FireDeamon' utility, available through https://www.ftpserv-u.com/addons.htm#ntutil, or 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.28 What's All This 'OTP S/KEY' Mumbo Jumbo?

These cryptic terms stand for "One-Time Password", and S/KEY is a form of one-time password originally invented by the Naval Research Laboratories.

Normally FTP sends all passwords via the network in clear-text. Anyone with a packet sniffer at the right place can see them. OTP changes this, it never sends a password over the network. Instead, it sends a one-way encrypted version of the password called 'hash' over the net. There is no way known to man to retrieve the original password from this hash, so it is pretty safe. To make things even better it never use the same hash value twice. So even if someone intercepts it, replaying will not work (That is where the term "one-time password" comes from).

Serv-U supports a popular form of OTP, called S/KEY, which in turn comes in two variants, MD4 and MD5, which is about the hash function it uses and both are supported in Serv-U. You can enable S/KEY for individual user accounts via the 'Setup - Users - Miscellaneous' menu choice. Don't forget to type in a new password for that user in case you are storing passwords in encrypted form since Serv-U needs to know the password when using S/KEY and the encrypted password stored in the user setup cannot be decrypted.

For FTP clients to use S/KEY you either need a client which has build-in support for it (The only one I know is FTP Voyager, see https://www.ftpvoyager.com/), or a client which lets you intercept the USER response and manually enter your password each time you log in (The command line FTP client will allow this). In the latter case you need the S/KEY 'calculator'. This is a nifty little program which helps you calculate a response to Serv-U's challenge. It is named "WinKey" and you can find it at ftp://ftp.cat-soft.com/add-ons/winkey/

2.29 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 https://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 [email protected].

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.30 What FTP Command Extensions Does Serv-U Support?

I'm 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-U's 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 user's 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 server's 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 65 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.

We'll 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

LogAccessDLL=OFF

LogFileGETs=ON

LogFilePUTs=ON

LogFileSystemMes=ON

LogFileSecurityMes=ON

LogFileFTPCommands=OFF

LogFileFTPReplies=OFF

LogFileIPNames=ON

LogFileDirtyDetails=OFF

LogFileAccessDLL=OFF

LogFileRotation=Dayly

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

StartMaximized=YES

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

LogFont=-11,500,0,0,0,0,Arial

ListenToIPHomesOnly=YES

OpenFilesUploadMode=Any

DirListMask=rwx------

ReloadSettings=YES

AntiHammer=YES

AntiHammerWindow=30

AntiHammerTries=4

AntiHammerBlock=300

ShowBmpMenus=YES

[SIGNONOFF]

MessageFiles1=-1|c:\serv-u\signon.txt|c:\serv-u\signoff.txt

MessageFiles2=2|c:\serv-u\signon-152.3.110.169.txt|

MessageFiles3=1||c:\serv-u\signoff-152.3.110.168.txt

[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

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

PasswordType=OTP S/KEY MD5

Password=6A255464521848

SKEYValues=0 0 197DC44DFE091F4E 998 gawk259

[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', 'Window', '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 don't 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. Automatic log file rotation is supported through 'LogFileRotation'. There are four possible values for this entry: 'none', 'dayly', 'weekly', 'yearly'. Enabling log file rotation appends a date to the log file name and will automatically open a new log file at the appropriate time (depending on the rotation choice). Weekly logging always rotates on Sundays. By default log file rotation is disabled.

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 I'll 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. In a similar fashion there is 'StartMaximized' which keeps track of the maximized state of the window. 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 user's 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-U's 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. It's 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.

Normally Serv-U creates a single listening socket that responds to incoming connections on all IP addresses bound to the server PC. It is possible to tell Serv-U exactly what IP addresses it should listen to by creating them as IP homes and setting 'ListenToIPHomesOnly' to YES. Default is NO.

The format of the directory listing access mask can be changed through the 'DirListMask' entry. Any UNIX style mask is acceptable, default is 'rwx------'.

For those programs that directly change settings in the SERV-U.INI file there is the 'ReloadSettings' entry. Setting this to YES will force the server to reload most of the .ini file settings within about 15 seconds. Not all server settings are reloaded; anything related to users, groups, security, access and IP homes should be OK, for other settings some experimentation may be required. Always use the "WritePrivateProfileString()" function to update the .ini file, or Windows may not notice the changes.

To control the way the server opens files for uploading the 'OpenFilesUploadMode' directive is available in the 32-bit version. Possible options for this are:

'Any' = (default) First try opening with exclusive access, try sharing in case that fails

'Exclusive' = Always open files exclusively, denying all others access

'Shared' = Always open files shared, others can access the file during upload

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.

Users trying to log in by creating connections in rapid succession are said to be "hammering" the server. Serv-U has anti-hammer measures that prevent such users from tying up server resources and penalize them. The 'AntiHammer' entry controls if anti-hammer measures are enabled or not (default is not enabled). The 'AntiHammerWindow' controls the time in which Serv-U counts a client's connections, in seconds (default is 30 seconds), and 'AntiHammerTries' is the number of connections a client is allowed during the anti-hammer time window before the server determines the client is hammering. If hammering occurs the client's IP address is blocked for the time set with 'AntiHammerBlock', in seconds (default is 300 seconds).

The 32-bit version of Serv-U shows bitmap images next to the menu items by default. This can be switched on or off using the 'ShowBmpMenus' entry. The main reason for switching this off is to make screen readers for the blind work. Those are not able to read the bitmap menus.

The font used for the Serv-U log window is stored in 'LogFont'. The information stored closely follows that from a Windows LOGFONT structure, and is character height, weight, italic, underline, strikeout, character set, and type name (in this order). For more information on what all this means please see the MS Windows API info for LOGFONT.

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 information about the message files, containing sign-on and sign-off messages for various home-IPs. The sign-on message is displayed after a user contacts the FTP server, the sign-off message just before he disconnects. Every line contains information for one specific server home-IP. Each line is consecutively numbered, and has entry 'MessageFiles' The syntax for each line is 'MessageFilesX=<no>|<signon message file>|<signoff message file>'. Here 'X' is the line sequence number, '<no>' is the home-IP number similar to that in the '[IP-HOMES]' section and with the special number of '-1' to use for all connections that have no specific home-IP message file assigned, '<signon message file>' is the full path and file name of the file containing the sign-on message, '<signoff message file>' is the full path and file name of the file containing the sign-off message. Entries can have only a sign-on message file, or only a sign-off message file, as long as the '|' separators are all present.

There are several special character combinations recognized by Serv-U in sign-on or sign-off messages 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 message 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 doesn't 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 user's 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 user's 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. There are three different ways in which passwords can get stored in Serv-U. They all end up in the 'Password' entry. If passwords should not be encrypted they are stored as simple clear text. If they should be encrypted there are two possibilities for their form in the .ini file. For S/KEY passwords they are lightly encrypted (don't count on that for serious security) and stored. The encryption is reversible, since S/KEY needs to get back at the original. For regular passwords (i.e. not S/KEY) The UNIX 'crypt' command is used to encode the passwords. This is not reversible, once encrypted there is no way known to man to decrypt the passwords back to clear text. The use of 'crypt' 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.

There are two more user sections which deal with passwords. The first is 'PasswordType'. It stores the type of password for the user, and the choices are "Regular password", "OTP S/KEY MD4", or "OTP S/KEY MD5". The default is "Regular Password", in case no password type is supplied. The other two types mean Serv-U should use S/KEY, either with MD4 or MD5 as the hash function. Which brings us to the second section, 'SKEYValues'. This is only used in case of a S/KEY password type and stores intermediate S/KEY values to speed up the login process and handle concurrency. The first number is 0 if no user is in the middle of a login, or 1 otherwise. Only a single user can be in the login process. The second number is the session ID of the user in login, or 0 if no one is logging in. Next is the hash of the password using last login's iteration count, then the iteration count to use for the next login. The last value is the seed used in the S/KEY calculations.

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 user's section; password, home dir and file/directory access, are then looked for in the group's 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 nine different characters:

R = read access to files

W = write access to files

A = append access to files (implies write access)

M = modify access to files (implies write and append 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 user's 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 user's or the user's group's 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 user's 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 user's 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 and uses the "C" calling convention!

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

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/adjust 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 // always 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

#define SRVU_PassChallenge 30 // get password challenge if needed

#define SRVU_Connect 31 // information only: client connected

#define SRVU_Close 32 // information only: client disconnected

#define SRVU_MaxLoginPerIP 33 // max. no. of logins from same IP for user

#define SRVU_VerifyPasswd 34 // verify old password before changing it

#define SRVU_AppendFile 35 // verify append file access

#define SRVU_SignOnMes 36 // get signon message file

#define SRVU_SignOffMes 37 // get signoff message file

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-U's 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, that's exactly how it got to be: The DLL mechanism closely follows Serv-U's 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.

Another bit of weirdness in the DLL mechanism which comes from Serv-U's internal way of working is for those events that require a 0 or 1 to be set in 'Aux[0]' to indicate the result (SRVU_HideHidden is an example). These events require a binary 0 or 1 to be set, not the ASCII value for 0 or 1. In other words, what is needed is hex 0x00 or 0x01 in 'Aux[0]'.

Event Details

A number of the fields of the RClientEventStr structure are not always explicitly mentioned. They can be assumed to be set to their respective values whenever these are available (i.e. use common sense). These are: The 'User' field, which is set to the client's user name when this is available (during and after the USER command). The 'HostIP' field which is set to the server's home IP to which the client connected. The 'SessionID' field contains a unique session ID number for a client. This can be used to keep track of client state when needed. Note that some events can get called without a session ID (it is then set to 0) in case security info is needed which is not session specific, for example for a directory listing a 'SRVU_ListDir' event is issued with the 'SessionID' set to 0 since the result is cached for re-use by other sessions. There are two events, 'SRVU_Connect' and 'SRVU_Close', which might seem out-of-place since they are only for information to the DLL and do not require any decision. Their function is to allow the DLL to keep track of state of the connected users.

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 user's 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 user's 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 user's 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 user's 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 user's 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 user's current used disk quota value (in case Aux="0") 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, set to "0" if the request is to obtain the currently used quota value, in case the user wants to write a block to disk a negative value is passed, in case space is freed up a positive value is used.

On return:

Flag = TRUE if request was granted by the DLL, FALSE otherwise

Aux = in case currently used quota was requested this is set to the textual representation of the (new) used quota value (a number which should always be positive), in case of a quota change no return value for Aux is required. 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 user's 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 minutes, 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.

SRVU_PassChallenge

In case the required password is part of a challenge-response type mechanism this even should be used to tell Serv-U what challenge should be sent to the user (The S/KEY mechanism would use this).

On entry:

User = user name

On return:

Flag = TRUE if request was handled by DLL, FALSE otherwise.

Aux = set to the challenge reply, including the return code, for example "331 Response to otp-md4 998 scan723 required for skey.", it is also possible to return 4xx and 5xx replies to block the user from logging in.

SRVU_Connect

Connection information event, for DLLs that need to maintain state.

On entry:

Aux = IP address of client, in text format

Note: This event is the first one to be sent to the DLL when a user connects. It is for information only, do not change anything in the event structure.

SRVU_Close

Connection closure information event, for DLLs that need to maintain state.

On entry:

User = user name of client, if available

Note: This event is the last one to be sent to the DLL when a user disconnects. It is for information only, do not change anything in the event structure.

SRVU_MaxLoginPerIP

Specify the maximum number of concurrent logins from the same client IP address into the same user account.

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 logins for the same IP. A value of "-1" means there is no limit.

SRVU_VerifyPasswd

Verify if the user's password is correct before a possible password change. This is different from SRVU_Password so the system has a chance to check actual passwords even in a challenge-response type password system (As is used for S/KEY).

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_AppendFile

Verify if append access should be allowed for a file. Append access includes write access, but not modify or delete access to an existing file. The main purpose of append access is to facilitate resuming of file uploads.

On entry:

User = user name

Aux = full path of file

On return:

Flag = TRUE if access is allowed, FALSE otherwise

SRVU_ SignOnMesFile

Retrieve the file name with the sign-on message.

On entry:

IP = server home-IP to retrieve sign-on message for

On return:

Flag = TRUE (=1) if file name was found, FALSE (=0) otherwise

Aux = full path and file name of sign-on message file, if one was found

Note: This event does not have a user name or session ID since sign-on message files should be only related to the server home-IP to which the client connected. In case there is no IP specific message this event should be returned with 'Flag' set FALSE. The special IP of "0.0.0.0" is used to request the message file which should be used for all those server IPs without a specific message file. Messages are cached by the server, and any changes to the file name or file contents can take up to 15 minutes to propagate through.

SRVU_ SignOffMesFile

Retrieve the file name with the sign-off message.

On entry:

IP = server home-IP to retrieve sign-off message for

On return:

Flag = TRUE (=1) if file name was found, FALSE (=0) otherwise

Aux = full path and file name of sign-off message file, if one was found

Note: This event does not have a user name or session ID since sign-off message files should be only related to the server home-IP to which the client connected. In case there is no IP specific message this event should be returned with 'Flag' set FALSE. The special IP of "0.0.0.0" is used to request the message file which should be used for all those server IPs without a specific message file. Messages are cached by the server, and any changes to the file name or file contents can take up to 15 minutes to propagate through.

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 [email protected]. The plan is to maintain a list of all add-ons at the Serv-U Web site (https://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

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 ;

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

#define EVNT_ProgUp 20 // progress of upload

#define EVNT_ProgDown 21 // progress of download

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)

Progress of file upload

Posted every few seconds to inform about file upload progress.

Event = EVNT_ProgUp

SubEvent = SEVNT_None

AuxOne = file name (complete path)

AuxTwo = transfer mode (as text)

Duration = duration so far of upload in milliseconds

Size = file size uploaded so far in bytes

Progress of file download

Posted every few seconds to inform about file download progress.

Event = EVNT_ProgDown

SubEvent = SEVNT_None

AuxOne = file name (complete path)

AuxTwo = transfer mode (as text)

Duration = duration so far of download in milliseconds

Size = file size downloaded so far in bytes

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:

Server sends a event hook notification to the DLL

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

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

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'.

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.

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

PO Box 851

Gaylord, MI 49735

(517)732-8856 Voice

(517)731-2642 Fax

Serv-U Web site URL: https://www.ftpserv-u.com/

Discussion Forum and Pre-Sales Tech Support: https://forum1.deerfield.com/~ftpserv-u

Tech Support Request Form: https://www.ftpserv-u.com/support.htm

Tech Support Email: [email protected]

General information Email: [email protected]

Sales information Email: [email protected]

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

[email protected]

The Cat Soft Web site can be found at:

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

4.1 Serv-U Discussion List

There is a discussion list by E-mail for Serv-U where you can ask questions and discuss Serv-U related topics. At the moment of this writing the list is a thriving community of over 450 subscribers. Many of these are very knowledgeable Internet professionals. An excellent place for your questions! To subscribe to the Serv-U mailing list, send an E-mail message to:

[email protected]

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.

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:

[email protected]

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:

https://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 you'll still find a bug. Please don't think others will report it, send a message to [email protected]! There are a few things that help improve chances of fixing the critter, 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, it's 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)?

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!

4.3 Registering Serv-U

If you're happy with the performance of Serv-U, then please make us happy and register this program! Your registration fee is going to motivate the continuous improvement of Serv-U. Not to mention the warm fuzzy feeling you will get from knowing you directly contributed to Cat Soft's earthly wealth.

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

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

There are steep discounts for multi-copy licenses, so if you need lots of Serv-Us 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:

[email protected]

Document Info

Accesari: 4741
Apreciat:

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta

Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site

Copiaza codul:
in pagina web a site-ului tau.

eCoduri.com - coduri postale, contabile, CAEN sau bancare

Politica de confidentialitate | Termenii si conditii de utilizare