FTP Serv-U FTP-Server Daemon for WinSock Version 2.0 ******** The Serv-U Web site: All you ever wanted to know about Serv-U and always the latest version HTTP://CatSoft.dorm.duke.edu ******** March 1996 (c) 1995, 1996 Rob Beckers Cat Soft Disclaimer ========== I know, it's not the nicest way to start off. So let's just get this part over with, OK?! The FTP server program Serv-U and its documentation are copyright Rob Beckers. It is distributed as shareware, giving you the right to try it for a period of 30 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 1. Making It Work - Installation 3 1.1 Installation 3 1.2 Network Installation 4 1.3 Quick Setup 4 1.4 De-installation 5 1.5 Upgrading 5 1.6 Known Bugs & Problems 5 1.7 A Word to the Wise (but paranoid) 7 2. Using Serv-U - How To ... 9 2.1 How to Setup Your Server 9 2.2 How to Add a User 10 2.3 How to Change a User 12 2.4 How to Use Access Rules 13 2.5 How to Setup Anonymous Access 16 2.6 How to Use Groups 18 2.7 How to See Who is Logged In 18 2.8 How to Kick a User Off the Server 19 2.9 How to Setup Logging 19 2.10 How to Use Signon/Signoff Messages 21 2.11 How to Setup User Specific Login Messages 22 2.12 How to Use Directory Change Messages 22 2.13 How to Use Links a l  UNIX 23 2.14 How to Limit Access by IP Number 24 2.15 How to Print via FTP 25 2.16 How to Execute Programs via FTP with Serv-U 25 2.17 How to Use Serv-U with `SLIP/PPP Emulators' 26 2.18 How to use Netscape to access Serv-U 27 2.19 How to Let the Whole World into Your Server (and Delete All Your Files) 27 3. The Inner Workings 29 3.1 Serv-U Internals 29 3.2 The SERV-U.INI File 30 4. Getting In Touch - Bugs & Registration 36 4.1 Reporting Bugs 36 4.2 Registering Serv-U 36 4.3 Registration in the US 37 4.4 Registration from Abroad 38 Registration Form Serv-U 40 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 and/or daemon. The term daemon comes from the 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 PC's running MS- Windows that have a WinSock version 1.1 compatible TCP/IP stack installed. 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, to about two 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.0, was made about one year later, and consists of over 18000 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. * At the time of this writing there were over 1400 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's even an option to allow or prohibit clients on the basis of their IP-number. 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). * Lots of features, like configurable sign-on and sign-off messages, per user configurable login messages, directory change messages, and the possibility to use UNIX-style `links'. * Serv-U lets you execute programs remotely though your FTP client. * It allows transfer to or from ports, like PRN:, LPT1:, COM1:, and AUX:. This allows you to setup your PC as a print server by simply transferring the file to be printed to the desired port! Since the ports are part of the regular security system, a user needs permission to transfer to/from a port, allowing you to control who can use it. * A quite complete implementation, and very strict adherence to the FTP standard (found in documents RFC 959 and RFC 1123). Supports the `passive' command PASV. This is needed by WWW browsers and proxy agents (something required when there is a `firewall') for FTP transfer. Another feature is that you can let `Anonymous' users always see the root directory (`/') as their login directory. This, again, is needed by some WWW-browsers to make FTP transfers work. * Easy to setup and maintain. Everything is accessible through menus, and for automated maintenance the settings are stored in an .INI file of simple format. * There is lots of logging! You can select how much to log and where (to screen and/or file). The logfile is of a standard format to make machine reading easy, in case you need to do that for accounting purposes. * It is fast! The file transfer speed you'll get will be very close to the maximum your TCP/IP stack is capable of (well, assuming your FTP client is at least as fast of course). * Life-time free updates when registered (As long as Serv- U exists). * Compared to the commercial implementations, Serv-U is dirt cheap: less than 0.014ct 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 version. But (yes, there had to be a `but'), after a little over 30 days it will stop working. Counting starts the first time you run the program. I warn you beforehand: re-installing it will not help you! Before I forget it: 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. And, Alun, just after recovering from the initial shock of Serv-U's appearance, I hope I didn't shock you again by bringing out a 32-bit version of Serv-U (There goes the monopoly). OK, enough sales talk. Let's continue with the actual documentation. First thing will be how to install Serv-U to get you in 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 ---------------- Nothing is simpler than installing Serv-U: just unzip it in the directory of your choice and run it. There is no need to change your `PATH' or put anything in other directories. The Serv-U zip-file comes with the following files: SERV-U16.EXE - The 16-bit version of the FTP-server executable itself - and/or - SERV-U32.EXE - The 32-bit version of the FTP-server executable SERV-U.DOC - The documentation in MS-Word format SERV-U.TXT - The documentation in ASCII format README.TXT - Something you have to read REGISTER.TXT - A registration form in ASCII format VERSION.TXT - A list of changes between the various versions. FILE_ID.DIZ - Short description file for use by bulletin boards When Serv-U is started for the first time, it creates the file: SERV-U.INI - File containing all settings and user information The 16-bit version of Serv-U uses Microsoft's 3D-controls to make the dialogboxes look better. If for some reason you get flat-looking dialogboxes 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 look flat on NT, this is normal. In Win95 you will automagically get the 3D-look. Serv-U offers two very distinct ways to try it out. Both with their 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 30 and some days. It does this 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, and a run/norun 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 PUTs and 5 GETs), it will show a message saying it is not registered to anyone who logs into the server, and finally, it will only stay on-line for one hour. You have to restart it again after that to get another hour. The advantage is that it will not contact my permission server over the network. Just to make sure this is clear: Once Serv-U is registered it will NEVER send anything over the network other than what is needed for regular FTP traffic! In short: The registered program will NOT contact my permission server! 1.2 Network Installation ------------------------- For network use with a single executable shared between many users that need their own settings, 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 this file. 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 searched for and created if necessary 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 when it is read-only, but setup changes and the current position of the Serv-U window will not be saved. 1.3 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 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. 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 that will be OK. Right! 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'll see a blank user setup screen. Now I'll assume you want to setup your server for anonymous access. To make that work, do the following: * At `User name', type the name we want to add: `anonymous' * 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 dialogbox and press `OK'. * 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 then `d:\anonftp', then feel free to change this. Just make sure that the directory you specify actually exist and that it is part of the access rules. If the zip-file you have came with both the 16- and 32-bit version of Serv-U (SERV-U16.EXE and SERV-U32.EXE respectively), and you only need one of them, then you can of course delete the other to free up disk space. 1.4 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. Just delete the whole directory where you put it, and that's it! Serv-U does not change any system files and does not place any files in other directories. 1.5 Upgrading ------------- Upgrading from an earlier version of Serv-U is not difficult, but 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. * Unzip the new Serv-U zip-file in a temporary directory and copy the contents over the existing files in your Serv-U directory (Watch out that you get the direction of copying right!). * Go to the Serv-U directory and delete the file BWCC.DLL if it exists, version 2 no longer needs this file. Note: Only delete BWCC.DLL if it is in the Serv-U directory, do not delete the one in the Windows\System directory as other programs might use this. * If you are using signon or signoff messages with `%' directives, then you will have to change those. The old directives no longer work. Take a look at the `How to setup signon/signoff messages' section for the new directives. Your old SERV-U.INI file will be used by the new program so you don't have to re-install any users. The 16-bit version of Serv-U now uses Microsoft's 3D-controls to create a 3D-look. This is done by a file named CTL3DV2.DLL which should be in your WINDOWS\SYSTEM directory. Most likely you already have this file, and therefore it is not part of the Serv-U zip-file. But if the dialogboxes look flat than drop me a line and I will make the DLL available. Note that this is only meant for the 16-bit version of Serv-U. The 32- bit version will always look flat on NT (Until NT adopts the Win95 look)! On Windows 95 the 32-bit version will use the build-in 3D-controls, and thus have a 3D-look. 1.6 Known Bugs & Problems ------------------------- At the time this documentation is being written the only known bug left in the program is the lack of on-line help. Everything that was found in earlier versions has been fixed If you have any problems, please first check out the `Frequently Asked Questions' on my Web site (HTTP://CatSoft.dorm.duke.edu). I will do my best to keep an up-to-date list of everything worthwhile there. Unfortunately there are still a number of WinSock socket stacks that are not 100% compliant with the WinSock standard. Since Serv-U uses the stack to its fullest, this can result in a number of symptoms. The following has been observed: Directory listings and file transfers do not work. After the first client the server seems blocked. WWW browsers seem unable to work with Serv-U. The PC is blocked when Serv-U is transferring a file. Problem WinSock socket stacks ----------------------------- Below is the current list of socket stacks that are known to cause problems. If you find any others with problems, or solutions to the ones mentioned below, then please let me know so I can pass the word on to others. * FTP Software Inc's socket stack: Their earlier stacks cause problems. Version 2.2 with WINSOCK.DLL v1.15.1 is rumored to work OK. Check out ftp://ftp.ftp.com/support/ftpsoft/winsock for updates. Their latest version WINSOCK.DLL can be found in WINSOCK.EXE (currently v1.17.1). * Spry's Internet-in-a-box stack: Version 2.0 is rumored to work OK. Check out http://www.spry.com:80/products/upgradingibox.html for updates. * The Air socket stack is rumored to come from the same factory as Spry's. Won't work though. * Core Systems' Internet-Connect stack does not work with Serv-U. * DEC's PathWorks stack does not work either. * Sun's PC-NFS stack version 5.1A and later works, but earlier versions are a problem. * Earlier versions of the Microsoft Wolverine stack had a tendency to bomb back to DOS when the network got busy. This has been fixed in version 3.11b, available from ftp://ftp.microsoft.com/bussys/clients/wfw/tcp32b.exe. A highly recommended stack! * Novell's LanWorkplace stack seems to work for some people, but doesn't for others. In any event, you need version 4.2T3 or later. The 'T3' patch is available from http://netwire.novell.com/servsup/binhtml/1203536.htm. * In case you have Netmanage's Chameleon's Sampler you need at least version 3.11. Reports are that it works fine on version 4.5.1 of Chameleon. * PC/TCP's OnNet stack locks up the PC during file transfers, but it works fine otherwise. * CompuServe's WinSock stack does not work with Serv-U (Wasn't that bought from Spry?!). * The various versions of Trumpet's WinSock stack generally work fine. But, version 2.0b had a tendency to kill the socket Serv-U uses to listen for incoming clients, thus making the server unreachable. This has been fixed in version 2.1f, so better get that one from ftp://jazz.trumpet.com.au/pub/winsock/twsk21f.zip. * Quarterdeck's socket stack does not work with Serv-U. * The Windows 95 built-in 16-bit TCP/IP stack usually works fine, and is very stable. But, it sometimes kills Serv- U's listening socket, resulting in `Connection denied' messages from clients. This is a Win95 bug which MS acknowledges and claims to be the result of programs not freeing their sockets before terminating. The latter is probably BS IMHO, but it lets them pass the buck. Most people will never see this while others seem to have the problem continuously. `SLIP/PPP emulators - TIA, TWinsock, Pipeline' ---------------------------------------------- If you are using a so called 'SLIP emulator' like TIA, TWinsock, or Pipeline, there are also a number of things to keep in mind. These emulators are not real Internet connections, and 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 you Internet provider for details about the latter. A related problem is that the IP number displayed by Serv-U is 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. 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 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 `CatSoft.dorm.duke.edu', you can use it instead of an IP number). Again, talk to your provider. 1.7 A Word to the Wise (but paranoid) ------------------------------------- Many a word has been spent on 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 run or not. That is the way the 30 days of try-out are enforced. To that effect, information is exchanged between your PC and mine, and as people remarked: 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 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 him/her (all 18000+ 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 it 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 in, for example, a WWW browser that will wait for 5 months, until full moon and Venus coincide, then monitors PC activity and if a user hasn't been present for a few hours, or if it's 4 in the morning, will start 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". That was all I had to say about installing Serv-U. Now 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 dialogbox 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 dialogbox 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 dialogbox 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' dialogbox. 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. Of course, the rest of the world expects a FTP server to listen on port 21, but changing to another number is one great way of insuring that only you and some selected friends will know about your server. 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. Likewise, `Maximum no. of anonymous' limits the number of `Anonymous' users at any given moment. If `Maximum no. of users' is specified, then this will limit the total number of users, both regular and anonymous, even if `Maximum number of anonymous' is set to a larger number. 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 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. For my own server (CatSoft.dorm.duke.edu - an ancient 80486-33 with 8Mb. of RAM running Win95) I have set the limit to 15 simultaneous users. Since I mostly get relatively slow long distance traffic this means in practice that I have never noticed any slowdown in system response while using it for other work and the server has remained stable. If you use a dedicated PC as a FTP server it is probably safe to go to about 30 simultaneous users (Conservative estimate). 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 server work! At the top of the stability list stands NT. I don't have any experience with it myself, but people using Serv-U in NT tell me it is very stable. Another often asked question concerns maximum transfer speeds that can be obtained with Serv-U: Let's just say that even on a measly 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 Mbits per second). You can try out raw speed by yourself: Just start a FTP client, like WS_FTP on the same PC as where the server is running and transfer some files through it. This bypasses the network, so what you are seeing is Serv-U plus hard disk access and part of the socket stack. The conclusion from this will probably be that your biggest performance bottle neck is going to be your network connection. Let's get on with the list. To make sure that users cannot log onto your server and keep connections open until eternity it is possible to set `Time-out users' and `Time-out anonymous'. If a connection has been idle for more than the number of minutes you specify here it will be automatically closed. Filling in 0 or leaving it blank switches off the time-out. It is a good idea to fill in some values here, since otherwise the system would slowly fill up with sockets that for some reason got stuck, not to mention users that connect and start a transfer just before they leave the office in the evening and then go home. Default values are 15 minutes for anonymous users and 10 hours (=600 minutes) for regular users. 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!!! 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 dialogbox 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 no names in the list, short of Divine Intervention. If you are at this point and are about to setup your first user, just go ahead and type in the various fields. If there already are users defined you will see the settings of the first one and to get rid of this and create an empty sheet just press `New'. Doing the latter will pop up a little box asking you for the new user's name, which I think speaks for itself. The next thing is important, so pay attention: You can fill in or change any 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 dialogbox. 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' dialogbox. 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' dialogbox, 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'. 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 stored encrypted using UNIX `crypt'. This algorithm works like a sausage machine: you put in a pig on one side and turn the crank, out comes the sausage. But, pushing in the sausage while turning the crank backwards will not get you a pig! It is quite secure, I wouldn't know of a way to get the plain text password back (the NSA might though). Once a password is stored you will only see the word `<>' 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 there for the password. If no password can be found then access will be denied to the user. There is a way to setup a user without a password, but it needs direct editing of the SERV-U.INI file. You can find the details in the chapter on Serv-U internals. 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 a 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! This brings us to the `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'. If you want the user to be able to actually use the newly created account, then the `Enable account' check box should be kept checked. If you want to disable the account without removing the setup information of a user you can uncheck this, which will keep the user from logging in. A large portion of the `Setup Users' dialogbox 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'. There is one more user name with special meaning to Serv-U: `ALL'. 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 the 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 `ALL' is consulted (if it exists). So `ALL' 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! This should have 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' dialogbox. 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 drag our favorite example once more out of the closet: 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' dialogbox. 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 `<>' 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 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 `<>' 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: 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 which 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' dialogbox 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' dialogbox. This list contains a number of paths with access information coupled to each path. Access to the PC is only allowed according to these paths and their access information. No access path, no access! So, there is one path you might always want to be 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 is a special case. To start with file access: * `Read' access, this allows files to be copied from the PC using the FTP `get' command. * `Write' access, allowing files to be copied to the PC using `put', but not changed, deleted, or renamed. * `Delete' access, allowing the user to change files, rename, or delete them. Having `Delete' access automatically includes write access (although it does no harm to specify both). * `Execute' access, which 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, for allowing the user to retrieve a directory listing using the FTP `dir' command. * `Make' access lets the user create new directories at this path. I.e. the user can make subdirectories. * `Remove' allows the user to delete directories. The final item is somewhat special: * `Inherit' means that the access rule automatically applies to all subdirectories of the path. I.e. the rule is inherited by subdirectories. Most of the above should be no surprise to you, but let's take a closer look at a few of the less clear items. First, to allow a user to use the FTP command `cd' to get into a directory any of the rights is sufficient. So, if a user has `read', `write', `delete', `execute', `list', `make', or `remove' access he or she can change to the directory in the access path. Conversely, if a path is specified without any access rights (except for `Inherit') then the user has no access what-so-ever to this path. If a user has `write' access to a file or path, but no `delete' access, then he can upload files to the server as long as they do not exist already. This is good for an upload directory, because it allows uploads without the chance of changing previously uploaded files. `Execute' access is meant for remotely starting programs and usually applies to specific files. Be careful in granting this right: For example, allowing a user to start COMMAND.COM also means that this user can delete anything on your hard disk! More on using this in the `How to execute programs via FTP with Serv-U' section. If you want a user to be able to see a directory listing you need to specify `list' access. This is often 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 then these 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 a 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 the least understood: 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. For directory access a similar mechanism is followed. It follows from this that THE ORDER OF THE PATH ACCESS RULES IS IMPORTANT!!! Unless the access rules are in the right order you might not be getting what 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 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 would write to the upload directory the security mechanism will check against Y:\ANONFTP and conclude that UPLOAD is a subdirectory, so the rule applies, 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 he be able to download anything from there, he cannot even see what files are uploaded. If the drive letter is left out of a path, it applies to all drives. So, a fast way to get full access to all files on all drives is: \ - read, write, delete, list, make, remove, and inherit rights Now, the same mechanism that determines access to directories also applies to files. It is possible to grant access to specific files on a per-file basis. 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. 2.5 How to Setup Anonymous Access --------------------------------- Since setting up anonymous access is such a common task when running a FTP server that I want to present a separate section on this subject. It is not much different from setting up another user, so this is going to be a `follow the recipe' kind of instruction, with the specifics for anonymous thrown in. First a tip: If you are running Windows 95 it might be worthwhile to create a new `DriveSpace 3' volume with all the files you want to make available. 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 dialogbox. 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. 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 files 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 MIOW 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 signon/signoff messages' section. Now let's place the file LOGANON.TXT in F:\ and thus enter F:\LOGANON.TXT in the `Message file' field. 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' dialogbox. Just check if `Enable account' is checked, which is the default. To store it press `Store'. There are a few more things that are important for anonymous access. They can all be found in the `Setup - FTP Server' menu choice. The first field of interest to us is `Max no. anonymous', this determines how many anonymous users can be logged in at the same time. If you leave this blank then Serv- U will allow any number. Use your own judgment what you think your machine can handle. Next is `Time-out anonymous'. This determines how long Serv-U will wait when anonymous users are not doing anything before kicking them off the server. The default of 15 minutes is a good value, 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. Setting the time- out to 0 or leaving it blank means that Serv-U won't check how long a user has been idle. This brings us to the `Relative paths anonymous' checkbox By default this is checked and 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 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. The last item we need to concern ourselves with for anonymous users is the `Check anon. passwords' option. 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 the latest version of Netscape (v2.0) does 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 server Serv-U also looks for a `-` (hyphen) as the first character of the anonymous `password'. If present, then 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 to your server. You can enhance things further with signon/signoff 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 has the concept of `groups'. They allow you to group users with similar settings together. All the similarities are stored in a group, leaving only the differences for you to set up per user. To edit groups select the `Setup - Groups' menu choice. The dialogbox 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. So, 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 a user with name `ALL' 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 used here. 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 dialogbox. The upper part shows a list of all users currently connected to your server. By clicking with the mouse on one of them you can get extra information about that user in the lower part of the dialogbox. 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 number that do not have an IP name. So, it is not at all unusual for a user not to have an IP name. Then, 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 might 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!"). This brings us to the `Show Commands' button. Pressing this will pop up another window which will show you all the FTP commands the user sends and 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 dialogbox has the prosaic name `Kill User'. This is the place where, if so inclined, you can alleviate all your frustration after a bad day at the job. For that reason the entire next section is devoted to it. 2.8 How to Kick a User Off the Server ------------------------------------- If someone is doing things you don't like, or you just want to be mean, then Serv-U offers you the option of kicking that user off your server and keep him or her off. This is done by selecting the `File - User Info' menu choice. In the dialogbox 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 dialogbox 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. The first asks `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 it won't work from the same IP number. We will talk about access and IP numbers in greater detail in the `How to limit access by IP number section'. The second checkbox asks `Disable account' and checking this does exactly that: The `Enable' checkbox in the `Setup Users' dialogbox will be unchecked. That way no one 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 dialogbox that lets you specify what events you want to log and where to log them to: either to screen only or to both the screen and a logfile. The first two items deal with logging to a logfile. The first one, `Enable logging to file' switches writing to a logfile on or off. The second item, `Logfile' is meant for entering the path and file name of a file to write all the log messages to. Of course, logging will only work when a valid logfile name is entered, it has to be a full path name including a drive letter. Serv-U gives you a wide choice in what should be logged or not. In all there are seven different categories that can be individually enabled or disabled. The items are self descriptive except maybe for three: `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. These two options are mainly intended for diagnostic purposes and are switched off by default. The last option is `Log IP names' and when checked Serv-U will try to find the IP name of a user by doing a reverse DNS lookup on the IP number. Keep in mind that DNS lookups can take just about any amount of time, cost a fair amount of overhead, and not all IP numbers have a IP name associated with it. When this option is checked then the IP name of a user will be logged as soon as it becomes available. Messages are always logged to the Serv-U window, regardless of the logfile settings. There is no difference between the messages on screen and the ones in the logfile, although some things are only shown on screen. The latter are server and program related matters, like version number, server going on/off-line etc. Log messages always have the same layout. The reason for using such a strict format is to make it easier to search for specific messages or certain types of messages. This also makes it possible to do automatic accounting by machine reading the logfile if you need it. The logfile can be read or copied at any moment, even when Serv-U is running (It is also possible to get the file via FTP using Serv-U itself!). 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 six different categories: 1 - system messages (problems etc.) 2 - FTP commands (from client to server) 3 - GET file transfers 4 - PUT file transfers 5 - security related events (users logging in etc.) 6 - FTP replies (from server to client) 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. You can rename, move or delete a logfile at any time while the server is running, there is no need to stop the server. You can even copy a logfile to a remote system using Serv-U itself! 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. One more note: If you log GETs and PUTs then Serv-U will also tell you the transfer speed. For GETs the value Serv-U shows can be a bit optimistic, especially for small files. The reason is that the socket stack buffers the bytes that are sent over the network. So, Serv-U can very quickly transfer 10-20 Kbytes to 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 done, 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 Signon/Signoff Messages --------------------------------------- Your FTP-server can display a welcome message every time a user connects to it. This can be very useful to provide users with information about your FTP server, like where to find games, or `Serious Software'. Likewise, you might want to say good-bye to them when they leave, or remind them to send that check . . . The way to do this is by entering a text in the `Signon/Signoff' dialogbox which pops up when you choose the `Setup - Signon/off' menu choice. There are several special words that you can enter in your signon/signoff text which get expanded while being sent to a client. They all begin with `%'. Here is the list: %time - displays the current time on your PC %date - displays the current date on your PC %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 %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 disk space of the user's current disk %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 bytes uploaded by the user %bdown - displays the number of bytes downloaded by the user %btot - displays the total number of bytes transferred %tconm - displays the total connect time in minutes %tcons - displays the connect time in seconds - to be used with `%tconm' Not all of these directives make sense for both the signon and signoff text: There is little point in putting `%disk' in the signon message, since the user is not yet logged in. Likewise for some other directives. However, these same directives can also be used in directory change messages and login messages, which are covered in the following sections. There they can be very useful. So, you could make the following signon text: Welcome, it is %time on %date, and you are user number %unow Over the last 24 hours there %u24h people have visited this site 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. 2.11 How to Setup User Specific Login Messages ---------------------------------------------- After astonishing the user with your signon message you can go for the kill by also providing a user specific login message. These messages should be put in one or more text files and the file name can be filled out in the users or groups setup dialogbox, in the `Message file' field. 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 signon message does not get displayed by Netscape). 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. It is possible to set up a different message for each directory. Like 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 a file with that name in the directory the user is changing to, and if found the file is displayed. 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. Like signon and signoff 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: Anonymous users cannot see `hidden' files. So, if you make your directory change message files hidden they won't show up in the directory listings while anonymous users still get to see the messages. 2.13 How to Use Links a la  UNIX -------------------------------- Now for the piece de resistance (pardon my French) which sets Serv-U miles apart from any other FTP server that I know of for MS-Windows: Links! 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 the actual file or directory is gone! The great value of links is in showing users that you have all kinds goodies available on other disk drives. The user can then simply `cd' to a link and thus change to a completely different drive and directory. The way Serv-U works with links is by reading them from a text file. You can have different files and thus different links for each directory, much in the same way as the directory change messages work in the previous section. The file name is entered via the `Setup - FTP Server' menu selection (Guess where!). 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 directory. 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 `hidden' then anonymous users won't see the file itself appear in their directory listings while they still get to see the links. 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:\ 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 `cd ` if it's a directory, `get' for a file etc. Only difference is that if a link gets deleted 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. So far 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 Limit Access by IP Number ------------------------------------- This `Setup - IP Access' menu choice will pop up a dialogbox which provides the means to restrict access to your FTP server to certain IP-numbers. 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. In the upper left corner of the dialogbox you can choose which type of rules 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 deny rules are looked at FROM TOP TO BOTTOM. If no matching rule is found, the allow rules are evaluated, again from top to bottom. The first matching rule applies, and evaluation is stopped. If there are no IP-access rules everybody can enter the FTP server. As soon as there is one rule, only those clients that pass the rule check are allowed to enter. 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-numbers or ranges of IP- numbers. There are two special characters: the star `*' and the hyphen `-'. A star functions as a wildcard for checking the number. Any number will match that section of the rule if it is a star. The hyphen is used to denote a range of 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: 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: 168.76.*.* 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 rule like this: 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, order is important and deny rules are always evaluated before the allow rules. Experiment a bit, and you'll get the hang of it. Since people keep asking me this: A few words about the security of IP-access rules. The check on IP 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. So, 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.15 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' dialogbox: 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 `cd' commands 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.16 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' dialogbox. 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 one that comes with Windows 95 and NT) uses the `QUOTE' command for this purpose. So the full command line to let COMMAND.COM copy a file from A.TXT to B.TXT would become: QUOTE SITE EXEC C:/DOS/COMMAND.COM COPY /B A.TXT B.TXT You might notice the use of `/' instead of `\' in the path. This is because most command line FTP clients do not take kindly to backslashes. For Serv-U it 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. The example above will likely only work for command line FTP clients that are based on the UNIX client. For point-and-click type clients, like WS_FTP 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. 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 is a very big potential security hole! 2.17 How to Use Serv-U with `SLIP/PPP Emulators' ------------------------------------------------ More and more Internet Access Providers these days 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 ISP's 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 you Internet provider for details about the latter. A related problem is that the IP number displayed by Serv-U is 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 also 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 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. 2.18 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://:@/ Very little of this is needed and in its simplest form you only use the which results in the usual anonymous access. If you add a 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 section. So far we did not use the 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 section. In the section you should use `/' instead of `\', and you can add a drive letter as part of the path. So, to finish up with an example that uses all of the above: FTP://john:secret@CatSoft.dorm.duke.edu/f:/john This would log John into the Cat Soft server. By the way, did you know that the newest version of Netscape, v2.0, can also upload files to a FTP server? To do so, simply drag the file-to-upload from `Explorer' (the Win95 file manager) to the Netscape window and drop it there. Experiment & Enjoy! 2.19 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' dialogbox. 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 the unique Serv-U feature that 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 little `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. 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 4.52. 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 recommended! This whole project started about two years ago after much disappointment with the existing FTP servers for WinSock. In its current version it consists of a bit over 18000 lines of C++ code, divided into 29 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 (also called `non- blocking' functions) 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 very well defined tasks, I hope to be able to easily extend this FTP server and fix those (hopefully few) remaining bugs quickly! The 32-bit version of Serv-U is not multi-threaded, a single tread is used for all clients. `Multi-threading' is one of those buzz words that are poorly understood by most and abused by many. `Threads' are light-weight processes, that can be used to run concurrent tasks without all the overhead of creating real processes. In the mainframe world this has traditionally been used for servers: Each client would start a separate process or thread. However, unless you are running NT on a multi-processor machine (and I wager that now we are talking about much less than 1% of all NT installations), multi-threading is not generally going to gain you anything because thread maintenance and switching brings overhead with it. There are still good reasons for using multiple threads on a single processor machine: For independent background tasks, like a printer spooler, it makes perfect sense. Also, if a process needs to perform multiple concurrent tasks that each would take a long time (and `long' in computer terms could mean anything over a few tens of milliseconds), using multi-threading is a good practice. However, for servers the practice of starting a separate thread for each client is usually to provide an easy way out of programming the thing. That way the programmer can use `blocking' sockets and simply block (i.e. `do nothing') until something happens on the socket stack. Makes for much simpler programs and is used for all the UNIX servers, so anything ported from there will be coded in this fashion. The better way to do things in Windows is to make the program event-driven and let it respond to messages from the socket stack instead of blocking the task. This means `asynchronous' sockets have to be used, and the whole program is much harder to make: Instead of a single easy to follow flow the program now becomes a number of message handler routines that can be called in any order. Serv-U only uses asynchronous sockets, and the response to each socket stack message normally does not take much time. Thus, a single thread can handle this perfectly well, and cutting it up in multiple threads would only slow things down. 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, an environment variable SERV-U is checked. If this variable exists it should be set to the path where SERV-U.INI is found. Next, 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. This makes it easy to set things up for network users where there is a single copy of the program but each user needs its own settings. If after this no .INI file has been found yet the directory of the Serv-U program is searched. If SERV-U.INI is found here it will be used, if not, the program will create one, in the program directory. Serv-U uses the Windows build-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, the Windows limit for .INI file sizes. This limits the number of users you can set up in Serv-U, although the actual number will depend on the amount of information stored per user. We'll now go over all the items that can appear in SERV- U.INI. I will show you an invented setup file: [GLOBAL] Security=TRUE PortNr=21 MaxNrUsers=15 MaxNrAnonymous=10 Invisible=TRUE Logfile=c:\serv-u\logfile.txt Logging=YES TimeoutUser=600 TimeoutAnonymous=15 TryOut=Crippled LogGETs=ON LogPUTs=ON LogSystemMes=ON LogSecurityMes=ON LogFTPCommands=OFF LogFTPReplies=OFF LogIPNames=ON RegistrationKey=S%FgdfsdEvG,Rob Beckers,Cat Soft AnonRelPaths=YES Window=100,100,400,300 UserInfoWin=409,300 DirChangeMesFile=index.txt LinkFile=link.txt CheckAnonPass=OFF Version=2.0.0.8 [SIGNONOFF] SignOn1="Welcome to Robby's FTP-Server!" SignOn2="It is %time on %date and you are user no. %unow" SignOff1="Thanks for logging in!" SignOff2="Hope to see you again soon . . ." [IP-ACCESS] Bounce1=132.68.175.201 Bounce2=223.*.*.* Allow1=132.68.176.53 Allow2=132.68.175.* Allow3=101.43.23.30-40 [USER=Anonymous] HomeDir=d:\anonftp Access1=d:\anonftp\upload,WP Access2=d:\anonftp,RLP LoginMesFile=logmes.txt [USER=Rob] Group=system Password=WdRx.Jlk0kemm% HomeDir=c:\ 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 [USER=ALL] HomeDir=y:\ Access1=y:\,RL Enable=NO [GROUP=SYSTEM] Access1=c:\system,RWDCMLEP Access2=d:\,RWDCMLEP Access3=y:\novell,RWDLP All but four of these settings can be changed and set interactively through the `Setup' menus. The exceptions are the entries for `Invisible', `RegistrationKey', `Window', and `UserInfoWin', and if you desire a user to really have no password the entry `Password=` has to be set manually for that user. 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. 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. Similarly, the `MaxNrAnonymous' entry limits the maximum number of `Anonymous' users. The value put here is only meaningful if it is smaller than that of the `MaxNrUsers' entry. 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. The entries `TimeOutUser' and `TimeOutAnonymous' specify a time-out in minutes for respectively regular users and anonymous users. 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. Default values are 15 minutes for anonymous and 10 hours for regular users. 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. All the `LogXXXX' entries switch logging options on or off. Their names say it all, so I'll let you figure them out. 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. `AnonRelPaths' determines if anonymous 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 anonymous users to the sub-tree of their home directory, they cannot switch to other drives. If you switch it off then anonymous users will be treated like all others. Default it is switched on. 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'. 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. 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'. 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. Finally, `Version' keeps track of the Serv-U version number. Format is `major,minor,revision,beta no.' and it is used for automatic .ini file conversion. [SIGNONOFF] This section contains the messages that are displayed after a user contacts the FTP server and just before he disconnects. Every line has a separate entry with a number at the end, denoting the order. The signon message is put in `SignOnxx' entries (with xx the line number), and the signoff message is put in `SignOffxx'. There are several special character combinations recognized by Serv-U and they are expanded to their actual values when a user logs on or off. They all begin with `%' and you can find a complete list in the `How to use signon/signoff messages' section. A tip: Keep the number of lines and the their length limited. Most FTP clients will mess up lines over 80 characters, and since a FTP reply code is tagged to the beginning of these lines before they are sent, it is wise to keep them to less then 75 characters. [IP-ACCESS] This section determines which client IP-numbers will be allowed access to Serv-U. There are two kinds of rules: Those that refuse access in the form of `Bounce' 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 (`Bounce' or `Allow') then only those clients will be allowed to contact the server that pass the rule. All entries are numbered sequentially (`Allow1', `Allow2' etc.) and they are evaluated according to their number from first to last. Numbers should be consecutive. The `Bounce' rules are evaluated before the `Allow' rules. The IP-number of the client is matched section by section to each rule until a match is found. If the matching rule is one of the `Bounce' ones, the client is disconnected. If the IP number matches an `Allow' rule then he can proceed. The rules can be exact IP-numbers, or contain special characters. There are two of those: * = wildcard, match any number - = denotes a range A quick example: The 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). [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 `ALL' is searched. Now to the entries that can be found in this section. The identity of a user is verified by comparing his password, after encryption, with the one in the `Password' entry. The UNIX `crypt()' command is used to encode the passwords. This makes it possible to extract users with their password from the PASSWD file of a UNIX system, the same passwords should work on both systems. Unfortunately, there is not a single standard for password encryption on UNIX systems these days. Serv-U uses the most common scheme, but this might not work for your system. If the password matches, the home directory of the user is taken from the `HomeDir' entry. This should always be a full path name, including drive letter! To make a user a member of a certain group, the `Group' entry can be used. All information needed and not found in the 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, than a rule with that directory should appear before its parent, i.e. with a lesser number (As a consequence of the order in which Serv-U evaluates access rules). The path in an access rule is followed by a comma and the access information itself. This can be a combination of up to eight different characters: R = read access to files W = write access to files M = modify access to files (implies write access) E = execute access, for remotely starting programs C = right to create subdirectories D = right to delete subdirectories L = directory list access P = the rule `propagates' to sub directories as well It is entirely possible to have no access information at all (only a path). This means that the user will not have any access to that path. One thing to realize is that write access to a file does not imply read access! As you can see it is also possible to specify access rights for the parallel and serial ports. They are part of the regular security scheme and to transfer to or from a port a user needs access rights. Then finally, the path in an access rule does not have to point to a directory. It is also possible to specify a filename. Of course, the `C', `D', `L', and `P' rights will not have any meaning then. There are two special user names: `Anonymous' and `ALL'. 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 `ALL' are never searched. The user `ALL' is searched if no appropriate rule is found in a user's or his group's entry. It can contain any of the regular entries. 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. [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. 4. Getting In Touch - Bugs & Registration ========================================= If you have questions or want to offer suggestions you are most welcome to drop me a line. However, please check out this manual and the Cat Soft Web site first to see if the answer to your question is already in there. Although I truly love to hear from you and will do my best to help, the problem is that each day between 30 and 50 E-mail messages arrive here, and you are talking to a one-man, spare-time company! As it is I'm spending 2-3 hours a day on answering E-mail and that is about as much as I have to spare. The easiest way to get in touch with me is via E-mail. The address is: RB5@acpub.duke.edu The Cat Soft Web site can be found at: HTTP://CatSoft.dorm.duke.edu Regular mail should work as well, but might take a bit longer. My address for this is: Rob Beckers 210 Alexander Ave., Apt. D Durham, NC 27705 U.S.A. 4.1 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, let me know! There are a few things I need to know in order to improve chances of fixing the beasty, 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. * What TCP/IP and WinSock stack are you using? Brand/type and version number please. Also, what operating system (DOS version and Windows or Windows-For-Workgroups, Windows 95, NT version x.xx)? Any memory manager (QEMM etc.), what version? * Please indicate also if this bug is merely cosmetic or of vital importance for using Serv-U. Somewhere in between is possible as well of course. By the way, I consider security related bugs very important! * Finally, please give me a chance to fix a bug, before you start to shout all over the Internet how bad this program is . . . 4.2 Registering Serv-U ---------------------- If you're happy with the performance of Serv-U, then please make me happy and register this program! Just a few words for those who are in doubt: Making this program took me (very literally) months of work, spread out over the last two years. Your registration fee is going to motivate me to continue improving Serv-U. In general, registration is important for shareware programs: It makes it possible for you to use professional quality software for peanuts. Lastly, being a biomedical engineering graduate student, I'm not exactly making lots of $$'s (to put it mildly). So, those 25 bucks for registration mean a lot to me! What do you get if you register? As soon as I get your registration I'll send you a registration code plus instructions on how to add it to the program. This will enable you to use the program after the 30 day try-out period. Please let me know your E-mail address, since Serv-U is tailored to pick the registration key out of the E-mail message I will send you. In case I have your E-mail address you'll also get notified when there are updates. Once registered you'll get those updates for free. That is, you can use the same registration code on the updates, but you'll have to get them yourself. Apart from all this you'll also get the nice, warm feeling of having contributed to improving my earthly wealth! The registration code is tied to the user/company name you specify on the registration form. You can see if your server is registered by looking at the `About' dialogbox: If registered it will tell you to whom. Another thing to keep in mind is that the registration information is sent back to any FTP client who uses the FTP command `HELP'. This is not a much used command but in principle it allows the whole world to find out who paid for your copy of Serv-U. If you're the lawful owner of the server this shouldn't bother you, if not. The registration fee is $25 for each copy. If you want to make me even happier and need several copies, the following license prices apply: The FTP Serv-U license prices: ------------------------------ 1-9 $25 per copy License for: 20 $250 50 $500 100 $700 100+ $500 per block of 100 copies Licenses for more than 500 copies are negotiable. Educational discount: For licenses of 50 or more copies: 30% discount. The `number of copies' in the above refers to the number of concurrently run Serv-U FTP servers in your organization (I.e. it is independent of the number of concurrent FTP clients). The last page of this manual is the registration form. Please use this form for all registrations! That way I can keep my administration manageable. 4.3 Registration in the US -------------------------- To register from within the US, please fill out the registration form and send it along with payment to the address on the form. A (personal) check made out to Rob Beckers is the preferred form of payment, but a Postal Money Order, or Purchase Order is welcome too. If you need a receipt, then please mention this on the registration form and I will send you one by paper mail. It is also possible to register via CompuServe's SWREG service. The registration ID for that is 7743 and this costs $30 (Since CS takes $5). Sorry, but I cannot accept credit cards. Important Note: =============== Make sure to include the registration form with whatever you send me!! I'm receiving way too many checks and purchase orders without a form, often even without a name nor a phone number. If your order goes through a purchasing department then please make sure they include the registration form with the PO or check! 4.4 Registration from Abroad ---------------------------- While borders are disappearing in many parts of the world, getting money across from one country to another is still not easy, at least not when you want to keep the cost down. Below is a list of payment options that I accept (In order of preference). Please make sure to include the registration form with anything you send me. Sorry, but no credit cards! Instead, these are the payment options: * Using CompuServe's SWREG service. The registration ID for Serv-U is 7743 and registration costs $30 this way (CS takes $5, so I end up with $25). * By check, drawn at an American bank and in US dollars. The check should be made out to Rob Beckers. * By American Express Travelers Checks for the correct amount in US dollars. These are cheap and safe, but there might be a minimum commission charged by your bank. The checks should be made out to Rob Beckers and don't forget to sign them twice! * By Postal Money Order. As I understand it, you can buy these international money orders in most countries for very little money ($3 here in the US). Payment is in your own currency, but the money order should be made out for USD $25 and to Rob Beckers. * By cash, but only in US dollars and I give no guarantees about safe arrival! Please do not send me other currencies, it would probably cost me much more to convert them to $$'s than it costs you. A trick I found useful for sending cash in envelopes: put the money in a folded sheet of paper so it doesn't shine through the envelope. This might improves chances of arrival considerably. * For Europeans: It is possible to pay using a Euro- Cheque. Make the check out for 40 Dutch guilders, i.e. write "DFL 40" for the currency. Don't forget to add the security number at the back. Send it to: Rob Beckers; St. Agnesstraat 16; 6241CB Bunde; The Netherlands. Please send or E-mail the registration form to me in the US. * For the Dutch: Het is ook mogelijk te betalen door fl. 40 over te maken op girorekening 53.95.461 t.n.v. Rob Beckers te Bunde. Stuur dan wel even het registratie formulier per E- mail naar mij toe. * For Canadians only: By any type of (personal) bank check of Canada. Just make the check out in US dollars. Doing so is easy: Write "US" in front of the dollar sign. Also add "US Funds" below the sum. This way neither of us pays anything extra (I don't, and as far as I know you don't either, but check with your bank if you want to make sure). The check should be made out to Rob Beckers. * By direct money transfer in US dollars to my American bank account. Please add $9 extra, since that is the fee my bank charges me to receive money this way. Please send me the registration form by E-mail in this case. The details for a wire transfer are: Bank: Wachovia Durham - North Carolina ABA/Routing no: 053100494 Account: No. 2373193064 Rob Beckers 210 Alexander Ave., Apt. D Durham, NC 27705 USA ******************** REGISTRATION FORM ********************** ROB BECKERS 210 Alexander Ave., Apt. D Durham, NC 27705 U.S.A. REGISTRATION FORM SERV-U ======================== Name: ............................................ Company Name: ............................................ Address: ............................................ ............................................ ............................................ Phone Number: ............................................ E-Mail Address: ............................................ (Important! Reg. Code is sent by E-mail) No. of copies: ......... Additional comments, suggestions, complaints, praise, etc . ............................................................. ............................................................. ............................................................. Registration fee is $25 per copy. Send this order form along with your payment to: Rob Beckers, 210 Alexander Ave. Apt. D, Durham NC 27705, USA. If you have any questions, comments or suggestions please contact Rob Beckers at the above address or via e-mail to RB5@acpub.duke.edu. Check out the site license prices in the manual if you need multiple copies. As this software is shareware it comes `as is', there is no warranty implied or otherwise, nor is support provided. However, if you discover any bugs or problems please contact the developer at the above e-mail address.