]> git.sesse.net Git - betaftpd/blob - README
Documentation re-linebreaking and updating.
[betaftpd] / README
1 Hmmmmm... :-)
2
3 [Insert insanely cool ASCII logo here yourself -- I'd rather spend my time
4  coding]
5
6 0. Before you start
7 -------------------
8 This is NOT a stable version of BetaFTPD. The latest stable, tried and tested
9 version is 0.0.7. Use this version at your own risk. That being said, this
10 version is rather stable now, actually _more_ stable than 0.0.7, which contains
11 quite a few lethal bugs, and is almost a year old.
12
13 1. What is it?
14 --------------
15 BetaFTPD is a _single_-threaded FTP daemon (server). This makes it _faster_
16 than most other FTP daemons (in most situations), contrary to popular belief.
17 BetaFTPD is, as the name implies, work in progress. Please don't expect it to
18 be finished yet!
19
20 2. How do you build it?
21 -----------------------
22 BetaFTPD uses GNU autoconf. Just type:
23
24 ./configure
25 make
26
27 And see what happens. (Run the resulting file called `betaftpd', of
28 course...) There are some flags that you can (and probably want to) give
29 to `configure':
30
31 --enable-xferlog        Makes the server output some logging information
32                         to /var/log/xferlog (or /usr/adm/xferlog if that fails).
33 --enable-fullscreen     Makes the server start in fullscreen mode, where you
34                         can see what the users are doing, their transfer
35                         speed etc. (There is other no way of turning on or off
36                         fullscreen mode -- this switch is the only way.)
37 --enable-upload         Enable STOR (uploading) and APPE commands, and all necessary
38                         code for uploading.
39 --enable-stat           Enable STAT command (server statistics). Note that I see
40                         very little use for such a command, and you shouldn't enable
41                         it unless you have a very good reason. Such commands are
42                         one of the best weapons in a cracker's arsenal. It is only
43                         included for RFC1123 compliance, and disabled by default.
44                         In addition, it tries to give as little `cracker-help' data
45                         as possible. 
46 --enable-shadow         Enable support for shadow passwords.
47 --enable-fork           Makes the server fork into the background, so you
48                         can logout etc. without `disturbing' it.
49 --enable-nonroot        Enable running without root privilegies. Please read    
50                         README.nonroot _first_, it will save you a lot of
51                         grief.
52 --enable-ascii          Enable ASCII mode transfers (ASCII translation on-the-fly).
53 --enable-dcache         Enable directory listing caches, for faster directory
54                         listings (the listings are only generated the first time
55                         they are needed). Note that this still quite experimental
56                         code, and the cache is only invalidated when it expires
57                         (ie. if nobody uses the entry in 15 minutes), or when
58                         files are added or deleted in the cached directory.
59                         (In other words, if a file is changed, the directory
60                         cache entry is _not_ updated. Do a `touch' on the directory
61                         to force invalidation of the dcache entry.)
62 --enable-message        Enable welcome.msg/.message files and README notes, like
63                         `normal' ftpds do. Note that this is relatively crude
64                         (and probably will stay so) -- for instance, README notes
65                         and .message files are printed every time the user enters
66                         the directory, even if he/she has been there before.
67
68 To get the smallest executable possible, _first_ check everything
69 in `strip-exec' (it's unsupported -- don't complain to me if it doesn't
70 work, fix it yourself! :-) ), and type:
71
72 strip-exec
73
74 3. Some things to note
75 ----------------------
76 a) BetaFTPD now listen on port 21 by default (it used to run on port 121). To
77    change it, change FTP_PORT in ftpd.h to whatever you'd like it to listen on.
78 b) BetaFTPD must definitely be run as root (unless you use --enable-nonroot
79    as mentioned above).
80 c) Some commands and features are missing, but probably not many that you'd
81    really miss. See the KNOWN-BUGS and RFC-COMPLIANCE files.
82 d) BetaFTPD can _not_ be run from inetd. This is a design decision.
83
84 4. Design decisions
85 -------------------
86 BetaFTPD was originally designed to be a single-threaded FTP server,
87 nothing else. After a while, work was done to reduce the executable size,
88 and from then, design was more and more concentrated around a
89 `minimalistic' server (after all, the fewer lines of code there are to
90 execute, the faster will things go, and the fewer bugs are possible).
91
92 However, as GNU autoconf support was added, it was realized that
93 features could be added and selected by users without hurting overall
94 speed or size for the others. Therefore, more and more features are
95 (and will be) implemented in BetaFTPD.
96
97 There are intendedly no command line switches it BetaFTPD. Such switches
98 are generally there to make for quick change of options without
99 recompiling the program. This is ideal for most command-line utilities,
100 but is rather pointless for an FTP server. FTP servers are designed
101 to be online 24 hours a day, 7 days a week, and serve users with files.
102 Rapid confiuration changes (in the form of command line switches,
103 configuration files et al) are usually not important, and has thus been
104 omitted from BetaFTPD.
105
106 There is no (and will never be a) ratio function in BetaFTPD, as such
107 features are only used for warez/MP3/porn servers, and are quite stupid
108 even then.
109
110 5. Eek! `top' says BetaFTPD uses tons of memory!
111 ------------------------------------------------
112 Yes, but top really is wrong :-) Well, actually, I don't think it could
113 do better -- every file BetaFTPD mmap()s is counted towards the total
114 number. So if you were serving the same 128MB file 10 times, top would
115 claim you used over a gigabyte of memory, still only a couple of
116 megabytes would be used at most, as cache. If you ran out of memory,
117 this could actually shrink to zero. It's just that the kernel tries to
118 be more effective (and it succeeds) by reducing the number of reads, and
119 instead reading larger chunks at once.
120
121 If sendfile() support is enabled, and the circumstances allow it (binary
122 mode downloading), BetaFTPD will not mmap() at all, bringing the memory
123 total down to a more realistic value.
124
125 Bragging:
126
127 On my Intel system, every user needs 1104 bytes (`struct conn').
128 When a user has a file transfer, an additional 324 bytes (`struct ftran')
129 would be needed, or 1428 bytes per user in total. In addition, you have
130 some `startup costs', of course. `ps' (again on my system) reports a
131 startup memory usage of 432 kB (RSS, I don't know enough about memory
132 to know if this is a realistic number ;-) ), compared to 484 kB for a
133 single wu-ftpd session (again RSS). To be honest, I don't think BetaFTPD
134 uses much memory. [Note that this information is a bit old -- I haven't
135 tested it lately; expect 2-300 bytes extra per user.]
136
137 Oh, while we're at it: A 486 running BetaFTPD will easily be able to
138 saturate a T1 line, with room to spare. The bottleneck will most likely
139 lie somewhere else (like the bandwidth, or how fast the disk can deliver
140 data). Unless you've got a 386 running gigabit, of course... (I must
141 admit, I've never really tried it with more than 100Mbit/sec, but the
142 problem then was clearly on the client machine ;-) BetaFTPD has later
143 shown itself to be more than able of saturating a 10mbit link in real-
144 world tests, with about 3% CPU utilization (PII/450MHz, IDE disks all
145 the way, about 2GB of files in all, 7-8 users at once).)
146
147 Recent load tests (see http://www.kegel.com/dkftpbench/results.html)
148 show that a P90 is able to serve about 250 clients (each at 28.800-speeds)
149 on a 10Mbit line.
150
151 6. Misc.
152 --------
153 Have fun -- after all, it's about 5% the size of wu-ftpd (about 20k
154 compiled!) and provides (IMHO) about 98% of the needed, everyday
155 functionality -- in fact, if you don't need the _really_ exotic commands,
156 it's faster (=better?) and uses *much* less memory (especially when
157 you have many users logged in at once) than the majority of the FTP
158 servers out there... (6 line sentence.)
159
160 This program is GPLed, version 2 (see the file COPYING), not any later
161 or earlier version (later versions will probably `upgrade' to new GPLs
162 as they become available, I just want to be able to choose what license
163 I put my code under). For more info on the GPL, visit http://www.gnu.org/ .
164
165 7. Where to get new versions, contact me etc.
166 ---------------------------------------------
167 E-mail:                 sgunderson@bigfoot.com (all spam/flame go
168                         to antispam@bigfoot.com or /dev/null)
169 Homepage, new versions: http://members.xoom.com/sneeze/
170                         (Click the link, and see under Projects.)
171 Mirror site:            ftp://metalab.unc.edu/pub/Linux/system/network/daemons/
172                         (Note that Metalab will always lag behind a few days, and
173                          doesn't carry beta versions.)
174
175                         There are more mirror sites at the homepage.