Hmmmmm... :-) [Insert insanely cool ASCII logo here yourself -- I'd rather spend my time coding] 0. Before you start ------------------- This is NOT a stable version of BetaFTPD. The latest stable, tried and tested version is 0.0.7. Use this version at your own risk. That being said, this version is rather stable now, actually _more_ stable than 0.0.7, which contains quite a few lethal bugs, and is almost a year old. 1. What is it? -------------- BetaFTPD is a _single_-threaded FTP daemon (server). This makes it _faster_ than most other FTP daemons (in most situations), contrary to popular belief. BetaFTPD is, as the name implies, work in progress. Please don't expect it to be finished yet! 2. How do you build it? ----------------------- BetaFTPD uses GNU autoconf. Just type: ./configure make And see what happens. (Run the resulting file called `betaftpd', of course...) There are some flags that you can (and probably want to) give to `configure': --enable-xferlog Makes the server output some logging information to /var/log/xferlog (or /usr/adm/xferlog if that fails). --enable-fullscreen Makes the server start in fullscreen mode, where you can see what the users are doing, their transfer speed etc. (There is other no way of turning on or off fullscreen mode -- this switch is the only way.) --enable-upload Enable STOR (uploading) and APPE commands, and all necessary code for uploading. --enable-stat Enable STAT command (server statistics). Note that I see very little use for such a command, and you shouldn't enable it unless you have a very good reason. Such commands are one of the best weapons in a cracker's arsenal. It is only included for RFC1123 compliance, and disabled by default. In addition, it tries to give as little `cracker-help' data as possible. --enable-shadow Enable support for shadow passwords. --enable-fork Makes the server fork into the background, so you can logout etc. without `disturbing' it. --enable-nonroot Enable running without root privilegies. Please read README.nonroot _first_, it will save you a lot of grief. --enable-ascii Enable ASCII mode transfers (ASCII translation on-the-fly). --enable-dcache Enable directory listing caches, for faster directory listings (the listings are only generated the first time they are needed). Note that this still quite experimental code, and the cache is only invalidated when it expires (ie. if nobody uses the entry in 15 minutes), or when files are added or deleted in the cached directory. (In other words, if a file is changed, the directory cache entry is _not_ updated. Do a `touch' on the directory to force invalidation of the dcache entry.) --enable-message Enable welcome.msg/.message files and README notes, like `normal' ftpds do. Note that this is relatively crude (and probably will stay so) -- for instance, README notes and .message files are printed every time the user enters the directory, even if he/she has been there before. To get the smallest executable possible, _first_ check everything in `strip-exec' (it's unsupported -- don't complain to me if it doesn't work, fix it yourself! :-) ), and type: strip-exec 3. Some things to note ---------------------- a) BetaFTPD now listen on port 21 by default (it used to run on port 121). To change it, change FTP_PORT in ftpd.h to whatever you'd like it to listen on. b) BetaFTPD must definitely be run as root (unless you use --enable-nonroot as mentioned above). c) Some commands and features are missing, but probably not many that you'd really miss. See the KNOWN-BUGS and RFC-COMPLIANCE files. d) BetaFTPD can _not_ be run from inetd. This is a design decision. 4. Design decisions ------------------- BetaFTPD was originally designed to be a single-threaded FTP server, nothing else. After a while, work was done to reduce the executable size, and from then, design was more and more concentrated around a `minimalistic' server (after all, the fewer lines of code there are to execute, the faster will things go, and the fewer bugs are possible). However, as GNU autoconf support was added, it was realized that features could be added and selected by users without hurting overall speed or size for the others. Therefore, more and more features are (and will be) implemented in BetaFTPD. There are intendedly no command line switches it BetaFTPD. Such switches are generally there to make for quick change of options without recompiling the program. This is ideal for most command-line utilities, but is rather pointless for an FTP server. FTP servers are designed to be online 24 hours a day, 7 days a week, and serve users with files. Rapid confiuration changes (in the form of command line switches, configuration files et al) are usually not important, and has thus been omitted from BetaFTPD. There is no (and will never be a) ratio function in BetaFTPD, as such features are only used for warez/MP3/porn servers, and are quite stupid even then. 5. Eek! `top' says BetaFTPD uses tons of memory! ------------------------------------------------ Yes, but top really is wrong :-) Well, actually, I don't think it could do better -- every file BetaFTPD mmap()s is counted towards the total number. So if you were serving the same 128MB file 10 times, top would claim you used over a gigabyte of memory, still only a couple of megabytes would be used at most, as cache. If you ran out of memory, this could actually shrink to zero. It's just that the kernel tries to be more effective (and it succeeds) by reducing the number of reads, and instead reading larger chunks at once. Actually, for 32-bit architectures, if you serve large several large files, you might get a problem with hitting the 2GB address space (every mmap() counts towards this limit, it appears). The solutions are many: Use sendfile() (see below), do without mmap, or enable high memory support in your kernel (at least Linux 2.3/2.4 can do this at compile time). For most of us, though, this will never be a problem, just be aware of it if you're doing a benchmark, for instance. Future versions of BetaFTPD might just mmap() once per file (instead of once per transfer per file), but this is probably more problems than it's worth. If sendfile() support is enabled (note that only Linux sendfile() is working at the moment, BSD sendfile() is detected but not utilized), and the circumstances allow it (binary mode downloading), BetaFTPD will not mmap() at all, bringing the memory total down to a more realistic value. Bragging: On my Intel system, every user needs 1104 bytes (`struct conn'). When a user has a file transfer, an additional 324 bytes (`struct ftran') would be needed, or 1428 bytes per user in total. In addition, you have some `startup costs', of course. `ps' (again on my system) reports a startup memory usage of 432 kB (RSS, I don't know enough about memory to know if this is a realistic number ;-) ), compared to 484 kB for a single wu-ftpd session (again RSS). To be honest, I don't think BetaFTPD uses much memory. [Note that this information is a bit old -- I haven't tested it lately; expect 2-300 bytes extra per user.] Oh, while we're at it: A 486 running BetaFTPD will easily be able to saturate a T1 line, with room to spare. The bottleneck will most likely lie somewhere else (like the bandwidth, or how fast the disk can deliver data). Unless you've got a 386 running gigabit, of course... (I must admit, I've never really tried it with more than 100Mbit/sec, but the problem then was clearly on the client machine ;-) BetaFTPD has later shown itself to be more than able of saturating a 10mbit link in real- world tests, with about 3% CPU utilization (PII/450MHz, IDE disks all the way, about 2GB of files in all, 7-8 users at once).) Recent load tests (see http://www.kegel.com/dkftpbench/results.html) show that a P90 is able to serve about 250 clients (each at 28.800-speeds) on a 10Mbit line. 6. Misc. -------- Have fun -- after all, it's about 5% the size of wu-ftpd (about 20k compiled!) and provides (IMHO) about 98% of the needed, everyday functionality -- in fact, if you don't need the _really_ exotic commands, it's faster (=better?) and uses *much* less memory (especially when you have many users logged in at once) than the majority of the FTP servers out there... (6 line sentence.) This program is GPLed, version 2 (see the file COPYING), not any later or earlier version (later versions will probably `upgrade' to new GPLs as they become available, I just want to be able to choose what license I put my code under). For more info on the GPL, visit http://www.gnu.org/ . 7. Where to get new versions, contact me etc. --------------------------------------------- Homepage, new versions: http://betaftpd.sourceforge.net/ Mirror site: ftp://metalab.unc.edu/pub/Linux/system/network/daemons/ (Note that Metalab will always lag behind a few days, and doesn't carry beta versions.) The homepage also contains information on how to get the very latest copy of BetaFTPD via CVS, a bug tracker, a patch tracker, more mirror pages, nightly CVS tarballs and much more, thanks to SourceForge. The old page at xoom.com has been discontinued; please update your links accordingly. -Steinar H. Gunderson