./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':
+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).
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:
+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
----------------------
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).
+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.
+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.
-
-If sendfile() support is enabled, and the circumstances allow it (binary
-mode downloading), BetaFTPD will not mmap() at all, bringing the memory
-total down to a more realistic value.
+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.
+
+If sendfile() support is enabled, 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.
+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/ .
+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.
---------------------------------------------
E-mail: sgunderson@bigfoot.com (all spam/flame go
to antispam@bigfoot.com or /dev/null)
-Homepage, new versions: http://members.xoom.com/sneeze/
- (Click the link, and see under Projects.)
+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.)
projects / betaftpd / commitdiff