-
Notifications
You must be signed in to change notification settings - Fork 0
/
proftpdfaq-docbook.sgml
1906 lines (1847 loc) · 72.8 KB
/
proftpdfaq-docbook.sgml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
]>
<book>
<?dbhtml filename="faq.html">
<bookinfo>
<title>Professional FTP Daemon FAQ</title>
<author>
<firstname>Mark</firstname>
<surname>Lowes</surname>
<affiliation>
<address><email>[email protected]</email></address>
</affiliation>
</author>
<date>27 Feb 2004</date>
<copyright>
<year>1999-2004</year>
<holder>Mark Lowes</holder>
</copyright>
<releaseinfo>v1.1.0 (CVS $Id$)</releaseinfo>
<legalnotice>
<title>Copyrights and Trademarks</title>
<para>This document may be reproduced in whole or in part, without fee,
subject to the following restrictions:</para>
<orderedlist spacing="compact">
<listitem>
<para>The copyright notice above and this permission notice must be
preserved complete on all complete or partial copies</para>
</listitem>
<listitem>
<para>Any translation or derived work must be approved by the author in
writing before distribution.</para>
</listitem>
<listitem>
<para>If you distribute this work in part, instructions for obtaining
the complete version of this manual must be included, and a means
for obtaining a complete version provided.</para>
</listitem>
<listitem>
<para>Small portions may be reproduced as illustrations for reviews or
quotes in other works without this permission notice if proper
citation is given.</para>
</listitem>
</orderedlist>
<para>Exceptions to these rules may be granted for academic purposes:
Write to the author and ask. These restrictions are here to protect us
as authors, not to restrict you as learners and educators. </para>
</legalnotice>
</bookinfo>
<toc>
</toc>
<preface><?dbhtml filename="faq-preface.html">
<title>Preface</title>
<abstract>
<para>This document sets out many of the FAQs related to the installation,
functioning and configuration of ProFTPD. It also provides some guidance
on policy and security issues.</para>
</abstract>
</preface>
<chapter><?dbhtml filename="faq-ch1.html">
<title>Introduction to ProFTPD</title>
<qandaset defaultlabel='number'>
<qandaentry>
<question>
<para>What is ProFTPD?</para>
</question>
<answer>
<para>ProFTPD is a ftp server written for use on Unix and
Unix-a-like operating systems, there is no support for native use
under Microsoft Windows.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Website & documentation</para>
</question>
<answer>
<para><ulink
url="http://www.proftpd.org/">http://www.proftpd.org/</ulink>
is the primary source for all information about the
project including documentation and security alerts.
There are a number of geographic mirror sites,
see the mirror pages on www.proftpd.org for more
details or try www.<isocode>.proftpd.org (ie
www.uk.proftpd.org).</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Bug reporting</para>
</question>
<answer>
<para>Bug reports should be made via <ulink
url="http://bugs.proftpd.org/">http://bugs.proftpd.org/</ulink>
which uses the bugzilla tracking system. Patches should be
attached to the appropriate bug and not mailed directly to
the mailing lists or any given team member.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>I've found a security hole</para>
</question>
<answer>
<para>Please report all security problems with the code to
<email>[email protected]</email> before releasing the information into the public
domain. It would be appreciated if you give the core team a few days
to put together a patch and/or new release to address the issue.</para>
<para>Please adhere to the proceedures and timescales given in the RF
Policy document <ulink url="http://www.wiretrip.net/rfp/policy.html">http://www.wiretrip.net/rfp/policy.html</ulink>, this will give the core development team a chance to get a fix or workaround in place before the problem becomes fully public domain.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Downloading</para>
</question>
<answer>
<para>There are two main methods of getting the software. Downloading a
compressed tarball or rpm (there is also a Debian package available in the main distribution) from proftpd.org or from a mirror site, alternatively if you wish to run the latest bleeding edge code then collecting from the cvs server is the best method.</para>
<blockquote>
<bridgehead renderas=sect2>Mirror sites</bridgehead>
<para>There is a complete and maintained list of ftp mirror sites available
from <ulink url="http://www.proftpd.org/download.html">http://www.proftpd.org/download.html</ulink></para>
<bridgehead renderas=sect2>CVS</bridgehead>
<para> cvs -d :pserver:[email protected]:/cvsroot/proftp
login (Hit Enter when prompted for a password.)</para>
<para>Then do:</para>
<para>cvs -d :pserver:[email protected]:/cvsroot/proftp -z3 co proftpd</para>
<para>To obtain the latest/greatest updates, just hop into the
proftpd directory and do: cvs update</para>
<para>A couple of sites generate downloadable tarballs of the latest CVS
code to make obtaining the test code easier.</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Mailing lists</para>
</question>
<answer>
<para>There are a number of mailing lists for ProFTPD</para>
<blockquote>
<bridgehead renderas=sect2>Announce</bridgehead>
<para>[email protected]</para>
<para>This is a very low traffic list where only ProFTPD announcements/changes
will be announced. Subscribe by sending a message to <email>[email protected]</email> with
"subscribe" in the subject.</para>
<para>Web interface:
<ulink url="https://lists.sourceforge.net/lists/listinfo/proftp-announce">
https://lists.sourceforge.net/lists/listinfo/proftp-announce
</ulink>
</para>
<bridgehead renderas=sect2>Users</bridgehead>
<para>[email protected]</para>
<para>This is intended to the the user support channel for the software,
in most likelihood this is going to be a high traffic list and
slightly chatty. Please read the FAQ, the documentation and the list
archives before posting a question.</para>
<para>Subscribe by sending a message to <email>[email protected]</email> with
"subscribe" in the subject.</para>
<para>Web interface: <ulink url="https://lists.sourceforge.net/lists/listinfo/proftp-user">https://lists.sourceforge.net/lists/listinfo/proftp-user</ulink></para>
<bridgehead renderas=sect2>Development</bridgehead>
<para>[email protected]</para>
<para>This list is intended for discussion of development-related issues
of ProFTPD, and feature design. It is NOT intended to be a "user
help" group.</para>
<para>Subscribe by sending a message to <email>[email protected]</email>
with "subscribe" in the subject.</para>
<para>Web interface:
<ulink url="https://lists.sourceforge.net/lists/listinfo/proftp-devel">
https://lists.sourceforge.net/lists/listinfo/proftp-devel
</ulink>
</para>
<bridgehead renderas=sect2>Archives</bridgehead>
<para>The mailing list archives can be found at:</para>
<itemizedlist>
<listitem>
<para><ulink url="http://www.proftpd.org/proftpd-announce-archive/">
http://www.proftpd.org/proftpd-announce-archive/</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.proftpd.org/proftpd-l-archive/">
http://www.proftpd.org/proftpd-l-archive/</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.proftpd.org/proftpd-devel-archive/">
http://www.proftpd.org/proftpd-devel-archive/</ulink></para>
</listitem>
</itemizedlist>
<bridgehead renderas=sect2>Unsubscribing</bridgehead>
<para>Before posting to any of the lists or mailing the list admins
please try and remove yourself first. Either by emailing
<listname>[email protected] with the subject "unsubscribe" or
visiting the web interface and unsubscribing from there.</para>
<para>I've (lost / never had) a password to the interface. Easy,
enter the address you are subscribed to the list as into the form and
hit the "email me my password" button.</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Copyright Issues</para>
</question>
<answer>
<para>The software is currently distributed under the GNU General Public License
(version 2 or later) as published by the Free Software Foundation.
Copyright is held by Public Flood Software.</para>
</answer>
</qandaentry>
</qandaset>
</chapter>
<chapter><?dbhtml filename="faq-ch2.html">
<title>Compilation and installing</title>
<qandaset defaultlabel="number">
<qandaentry>
<question>
<para>What platforms will it compile on?</para>
</question>
<answer>
<para>ProFTPD has been reported as compiling and running
on Linux, all BSD variants, Solaris and a number of other similar
operating systems.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>CVS</para>
</question>
<answer>
<para>CVS (Concurrent Versions System), is a version control system which
allows multiple developers (scattered across the same room or across
the world) to maintain a single codebase and keep a record of all
changes to the work.</para>
<para>The CVS repository for ProFTPD is available for non-developers in
read-only mode, however this code is right on the bleeding edge and is
not guaranteed to even compile let alone work. Access to CVS is given
to allow important security patches out into the wild and to allow
users and interested users to test out the latest changes on real
systems. </para>
<para>Nightly tarballs of the current CVS are available on
ftp.proftpd.org, these are built at approx 1am UK time.</para>
<blockquote>
<bridgehead renderas=sect2>Recommended ~/.cvsrc settings</bridgehead>
<programlisting>
cvs -z 3
update -Pd
diff -u
</programlisting>
<bridgehead renderas=sect2>Where can I get information on cvs?</bridgehead>
<para>CVS is produced by Cyclic Software (http://www.cyclic.com/) and
details on CVS can be found on their website. The CVS documentation
is clear, detailed and above all heavy when printed. I'd recommend
reading it if you're planning on using CVS a lot.</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I get debug output</para>
</question>
<answer>
<para>The easiest way is to fire up proftpd manually from the command
line with the debug level cranked up.</para>
<programlisting>
/usr/local/sbin/proftpd -d9 -n
</programlisting>
<para>This will result in maximal debug output direct to the
console. Warning, this can get messy on a busy server, for testing I
would suggest copying the config and altering the port the server
binds to and then testing.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Patches</para>
</question>
<answer>
<para>Any patches should be submitted in Universal format, this makes
integrating them into the main cvs source a lot easier. When
generating a diff against the current cvs source use "cvs diff -uw" to
generate the patch.</para>
<programlisting>
cvs diff -u filename > filename.patch
or
cvs diff -u > bigger.patch
</programlisting>
<para>Patches that add configuration directives without proper
documentation. Will be rejected. New features without documentation
are less than useless to the community at large.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Using non-default modules</para>
</question>
<answer>
<para>Simply configure ProFTPD with </para>
<programlisting>
./configure --with-modules=mod_module1:mod_module2:mod_module3
make
make install
</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>New features/modules</para>
</question>
<answer>
<para>While anything new is welcomed it's probably better
to at least float the idea first on the devel mailing list
to ensure that someone else isn't already hacking on it.
Also when submitting the patch or module for inclusion into
the ProFTPD source full documentation is needed.</para>
</answer>
</qandaentry>
</qandaset>
</chapter>
<chapter><?dbhtml filename="faq-ch3.html">
<title>Compatibility and Integration</title>
<qandaset defaultlabel="number">
<qandaentry>
<question>
<para>SQL</para>
</question>
<answer>
<para>ProFTPD has support for authentication and logging via SQL
databases using the mod_sql module as supplied in the main
distribution.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>SSH</para>
</question>
<answer>
<para>There is a mini-HOWTO at <ulink url="http://www.castaglia.org/proftpd/doc/">http://www.castaglia.org/proftpd/doc/</ulink> detailing how to tunnel ftp connections over ssh.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>sendfile()</para>
</question>
<answer>
<para>sendfile() is a system call which streamlines the copying of data
between the disk and the tcp socket. The call copied from the page
cache directly rather than requiring a kernel -> user space -> kernel
space copy for every read() and write() call. Generally the
advantages are only felt on heavily loaded servers. The call is
supported in ProFTPD for Linux and FreeBSD.</para>
<blockquote>
<bridgehead renderas=sect2>Linux 2.0.x</bridgehead>
<para>sendfile is not supported under 2.0.x, this is not an issue when
compiling for 2.0.x on a 2.0.x system. However when compiling on a
2.2.x system for use on 2.0.x use the --disable-sendfile flag.</para>
<bridgehead renderas=sect2>Runtime detection of sendfile()</bridgehead>
<para>Johnie Ingram (aka netgod)'s:
<ulink url="http://www.proftpd.org/proftpd-devel-archive/99-10/msg00073.html">http://www.proftpd.org/proftpd-devel-archive/99-10/msg00073.html</ulink></para>
<para>John Pierce <[email protected]>
<ulink url="http://www.proftpd.org/proftpd-devel-archive/99-10/msg00112.html">http://www.proftpd.org/proftpd-devel-archive/99-10/msg00112.html</ulink></para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>IPv6</para>
</question>
<answer>
<para>IPv6 support first appeared in the 1.2.9rc2 release. To
enable IPv6 support, use the --enable-ipv6 configure option.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Filename case sensitivity</para>
</question>
<answer>
<para>ProFTPD is utterly dependant on the underlying OS to handle
filename case sensitivity. If the underlying OS is case sensitive
then ProFTPD will be, there are currently no plans for a module to
handle this.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>FXP</para>
</question>
<answer>
<para>FXP is capable of bouncing data between websites. There have been
a number of reports of problems in configuring ProFTPD to function
cleanly with this program (http://flashfxp.skuz.net/).
</para>
<para>To support FXP when connecting as a user place "AllowForeignAddress
on" in the Global or VirtualHost context.</para>
<para>To support FXP when connecting as anon "AllowForeignAddress on"
must be placed in the Anonymous context.</para>
<para>The config will happily support "AllowForeignAddress on" in
multiple places within the config.</para>
</answer>
</qandaentry>
</qandaset>
</chapter>
<chapter><?dbhtml filename="faq-ch4.html">
<title>Common Running problems</title>
<qandaset defaultlabel="number">
<qandaentry>
<question>
<para>ProFTPD doesn't seem to work.</para>
</question>
<answer>
<para>Starting ProFTPD in standalone mode it doesn't show in "ps" It
could be many things, possibly something like not running ProFTPD as
root (it needs to be run as root initially, but will switch to a
non-privileged user). Regardless, ProFTPD logs all errors via the
standard syslog mechanism. You need to check your system logs in order
to determine what the problem is.</para>
<blockquote>
<bridgehead renderas=sect2>It doesn't work!</bridgehead>
<para>There are many times when there's a completely random problem which
appears to be insoluble. The best place to ask for help is definately
the mailing list (proftpd-l) but it's not productive to ask for help
without giving enough information for intelligent debugging.</para>
<para>Have you?</para>
<itemizedlist>
<listitem>
<para>Checked your logs</para>
</listitem>
<listitem>
<para>Tried the server in debug mode</para>
</listitem>
<listitem>
<para>Read the FAQ?</para>
</listitem>
<listitem>
<para>Checked the mailing list archive?</para>
</listitem>
<listitem>
<para>Are you running the latest version?</para>
</listitem>
</itemizedlist>
</blockquote>
</answer>
<answer>
<para>When posting try giving enough information, this might include but
not be limited to.</para>
<itemizedlist>
<listitem>
<para>OS and server version (proftpd -vv)</para>
</listitem>
<listitem>
<para>List of included modules (proftpd -l)</para>
</listitem>
<listitem>
<para>Appropriate log extracts</para>
</listitem>
<listitem>
<para>Output fom debug mode</para>
</listitem>
<listitem>
<para>Configration fragment</para>
</listitem>
</itemizedlist>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>"inet_create_connection() failed: Operation not permitted".</para>
</question>
<answer>
<para>You aren't starting ProFTPD as root, or you have inetd configured
to run ProFTPD as a user other than root. The ProFTPD daemon must be
started as root in order to bind to tcp ports lower than 1024, or to
open your shadow password file when authenticating users. The daemon
switches uid/gids to the user and group specified by the User/Group
directives during normal operation, so a "ps" will show it running as
the user you specified.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Unable to bind to port/Address already in use</para>
</question>
<answer>
<para>0.0.0.0 is INADDR_ANY, which means to bind to any interface. The
"address in use" will normally mean that something has already bound
to that address.</para>
<para>Under linux it is possible to run:</para>
<programlisting>
fuser -n tcp 21
</programlisting>
<para>to get the PID of the process currently bound to port ProFTPD is
configured to run as.</para>
<para>The most common cause is that ProFTPD is configured standalone and
inetd is still configured for port 21. Comment out the line starting
"ftp" in /etc/inetd.conf and restart (killall -HUP inetd or something
similar should do the trick) and try again. </para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>"(Login failed): Invalid shell"</para>
</question>
<answer>
<para>The user attempting to login has been given a shell that is
not listed in the system's /etc/shells file. By default, proftpd will require
that users logging in have valid shells. Use the RequireValidShell directive
to turn off this requirement:</para>
<programlisting>
RequireValidShell off
</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>"Fatal: Socket operation on non-socket"</para>
</question>
<answer>
<para>You have ProFTPD configured to run in inetd mode rather than
standalone. In this mode, ProFTPD expects that it will be run from the
inetd super-server, which implies that stdin/stdout will be sockets
instead of terminals. As a result, socket operations will fail and the
above error will be printed. If you wish to run ProFTPD from the
shell, in standalone mode, you'll need to modify your proftpd.conf
configuration file and add or edit the ServerType directive to read:</para>
<programlisting>
ServerType standalone
</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>"Fatal: unable to determine IP address of "hostname:</para>
</question>
<answer>
<para>The hosting machine has a poorly configured hostname setup to the
point where the resolver library cannot determine the IP from the
name. Solutions include, fixing the DNS for the domain, fixing the
hostname, fixing the /etc/hosts file. Which one works for you will
largely depend on your OS and exactly what is wrong.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>I'm having problems with FTP clients behind firewalls</para>
</question>
<answer>
<para>The FTP Specification defines that two sockets should be used for
all communications. The first runs over port 21 and is the control
channel over which all commands and response codes are sent. Whenever
data is required to be transfered, for example for a file download, a
directory listing etc etc. A second channel is created on demand,
this socket can take one of two forms.</para>
<blockquote>
<bridgehead renderas=sect2>non-Passive</bridgehead>
<para>The server end of the data socket uses port 20. This is nice and
easy to work into a firewall configuration.</para>
<bridgehead renderas=sect2>Passive</bridgehead>
<para>The port at either end is dynamically allocated. This is virtually
impossible to cater for in a firewall configuration given that the
port mapping will be different for every data connection.
</para>
<para>The solution is to force the users to configure their clients to
use the non-passive mode (ie port 20)</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Can I run more that one VirtualHost on a single IP?</para>
</question>
<answer>
<para>No, or at least not in the HTTP/1.1 manner of virtual hosting.
This is an inbuilt limitation of the current FTP RFC., unlike the
HTTP/1.1 spec there is no mechanism comparable to the "Host:
foo.bar.com" HTTP header for specifying which host the connection is
for. Therefore the only method for determining which VirtualHost the
connection is destined for is by the destination IP.</para>
<para>The one exception to this is if you host multiple servers on the same
IP but using different ports, however this requires that the connecting
client uses a non-standard port and therefore is probably not a good
solution for mass hosting.</para>
<blockquote>
<bridgehead renderas=sect2>Is there anything in the pipeline to fix this?</bridgehead>
<para>There is a draft standard <ulink url="http://search.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-12.txt">http://search.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-12.txt</ulink> with the IETF which extends and improves on the FTP specification including support for a HOST command. However given that the IP crunch is coming from websites and not virtual ftp servers this is unlikely to be pushed through any time soon.</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I run ProFTPD from inetd?</para>
</question>
<answer>
<para>Find the line in /etc/inetd.conf that looks something like this:</para>
<blockquote>
<para>ftp stream tcp nowait root in.ftpd in.ftpd</para>
</blockquote>
<para>Replace it with:</para>
<blockquote>
<para>ftp stream tcp nowait root in.proftpd in.proftpd</para>
</blockquote>
<para>Then, find your inetd process in the process listing and send it
the SIGHUP signal so that it will rehash and reconfigure itself. You
may also need to add in.ProFTPD to hosts.allow on your system.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Can I use tcp-wrappers with ProFTPD?</para>
</question>
<answer>
<para>Yup. Although ProFTPD has built-in IP access control (see the Deny
and Allow directives), many admins choose to consolidate IP access
control in one place via in.tcpd. Just configure ProFTPD to run from
inetd as any other tcp-wrapper wrapped daemon and add the
appropriate lines to hosts.allow/deny files.</para>
<para>If running ProFTPD in standalone mode, mod_wrap can be used to direct the
server to use the normal hosts.allow/deny files.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Can I run an FTP server on a non-standard port?</para>
</question>
<answer>
<para>Yes. Use a <VirtualHost> block with your machine's FQDN
(Fully Qualified Domain Name) or IP address, and a Port directive
inside the <VirtualHost> block. For example, if your host is
named "myhost.mydomain.com" and you want to run an additional FTP
server on port 2001, you would:
</para>
<programlisting>
...
<VirtualHost myhost.mydomain.com>
Port 2001
...
</VirtualHost>
</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question
<para>Can control upload/download ratios?</para>
</question>
<answer>
<para>Yes the mod_ratio module provides for doing just this.</para>
<para>The ratio directives take four numbers: file ratio, initial file
credit, byte ratio, and initial byte credit. Setting either ratio
to 0 disables that check.</para>
<para>The directives are HostRatio (matches FQDN, wildcards allowed),
AnonRatio (matches password entered at login), UserRatio (accepts "*"
for "any user"), and GroupRatio.
</para>
<programlisting>
Ratios on # enable module
UserRatio ftp 0 0 0 0
HostRatio master.debian.org 0 0 0 0 # leech access (default)
GroupRatio proftpd 100 10 5 100000 # 100:1 files, 10 file cred 5:1 bytes, 100k byte cred
AnonRatio [email protected] 1 0 1 0 # 1:1 ratio, no credits
UserRatio * 5 5 5 50000 # special default case
</programlisting>
<para>This example is for someone who (1) has downloaded 1 file of 82k,
(2) has uploaded nothing, (3) has a ratio of 5:1 files and 5:1
bytes, (4) has 4 files and 17k credit remaining, and (5) is now
changing directory to /art/nudes/young/carla. The initial credit,
not shown, was 5 files and 100k (UserRatio * 5 5 5 100000).
</para>
<para>Version 2.0 and above of this module integrate with mod_sql.</para>
<blockquote>
<bridgehead renderas=sect2>Limitations of mod_ratio</bridgehead>
<para>It appears that the ratio limits in mod_ratio are only maintained
on a per session basis and there is no ongoing tracking of usage.
</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Slow logins</para>
</question>
<answer>
<para>This is probably caused by a firewall or DNS timeout. By default
ProFTPD will try to do both DNS and ident lookups against the incoming
connection. If these are blocked or excessively delayed a slower than
normal login will result. To turn off DNS and ident use:</para>
<programlisting>
UseReverseDNS off
IdentLookups off
</programlisting>
<para>IdentLookups and tcpwrappers
***</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Lots of "FTP session closed" messages</para>
</question>
<answer>
<programlisting>
Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed.
Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed.
Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed.
Oct 7 12:30:48 salvage2 proftpd[8874]: FTP session closed.
</programlisting>
<para>The above log extract is likely to be caused by a local monitoring
system or a particularly aggressive DoS attack. Most service
monitoring systems try opening the ftp port on the target server to
detect whether it is active and running. Most of the time these tests
are followed by an immediate "QUIT" or disconnection.</para>
<para>TCPdump/TCPshow on the server in question should show which machine
on your network is is generating these connections.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I see who is connected?</para>
</question>
<answer>
<para>The ftpwho command lists the state of each ftp connection to the
server and what it's current activity is. However this does not
detail the connection information on a virtual by virtual basis.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Can I force ProFTPD to listen on only one IP?</para>
</question>
<answer>
<para>Sort, of it's not quite as clean as the socket binding under Apache
but the principle works something like this.</para>
<blockquote>
<bridgehead renderas=sect2>Standalone mode</bridgehead>
<para>To listen on the primary IP of a host use the SocketBindTight directive</para>
<para>To listen on a interfaces which are not the primary host interface use the SocketBindTight directive, place your server configuration in a <VirtualHost ftp.mydomain.com> block and use "Port 0" for the main host configuration and and "Port 21" inside the VirtualHost block.</para>
<bridgehead renderas=sect2>inetd</bridgehead>
<para>There are two approaches possible, the first is to use the patch
from Daniel Roesen <[email protected]> (check
the mailing list archives).</para>
<para>The second method is to run ProFTPD from xinetd
(http://synack.net/xinetd/), a more advanced replacement of inetd. An
entry for this in xinetd.conf would be something like this:</para>
<programlisting>
service ftp
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/proftpd
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
#bind = [IP to bind to]
}
</programlisting>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>"FTP server shut down ... please try again later."</para>
</question>
<answer>
<para>Check for /etc/shutmsg and delete it.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I shutdown the server without killing proftpd?</para>
</question>
<answer>
<para>ftpshut, allows the server to disallow connections with a message
without actually taking down the service. The shutdown can be
scheduled for a point in the future or right now, existing connections
can be allowed to finish, or be terminated now. Re-enabling is done
by removing the /etc/shutmsg file.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Is is possible to shutdown a single VirtualHost?
</para>
</question>
<answer>
<para>No, the shutmsg file works at a daemon level not at a virtual host
level.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I restart/reload the server?</para>
</question>
<answer>
<para>This depends on the mode you're running the server in.
</para>
<blockquote>
<bridgehead renderas=sect2>inetd</bridgehead>
<para>Unless you're making a configuration change to inetd itself nothing
needs doing. The server reloads the configuration everytime a new
connection is made.</para>
<bridgehead renderas=sect2>Standalone</bridgehead>
<para>Either stop and start the server completely (a little aggressive
for most admins tastes) or send a SIGHUP to the master daemon
process.</para>
</blockquote>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Fatal: unable to determine IP address of</para>
</question>
<answer>
<para>Proftpd was unable to work out what IP is associated with the
hostname in the VirtualHost block. Normally caused by a problem
with the DNS resolution of the host, check the resolv.conf file
and that your chosen nameservers are functional.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>451 append/restart not permitted, try again</para>
</question>
<answer>
<para>AllowStoreRestart is disabled by default because it will allow any
writable file to be corrupted by a malicious user. It is recommended
that this option is only used with authenticated users and then only
in certain directories.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>501 REST not compatible with server configuration</para>
</question>
<answer>
<para>As mentioned in the description of the HiddenStores configuration directive,
use of that directive is incompatible with the FTP command REST. Either
disable use of REST with the AllowRetrieveRestart and AllowStoreRestart
directives, or do not use HiddenStores.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>The time being displayed is wrong
</para>
</question>
<answer>
<para>The default behaviour for ProFTPD is to display all times relative
to GMT. To use local time set "TimesGMT off" in the server section of
the config. There is a known issue with Redhat 7, with regard to time
handling.
<ulink url="http://www.redhat.com/support/rh7-errata-bugfixes.html">http://www.redhat.com/support/errata/rh7-errata-bugfixes.html</ulink></para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Corrupted files</para>
</question>
<answer>
<para>There appear to be some problems with both the use of sendfile()
in ProFTPD and with the implementation within certain operating systems.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Can I upgrade ProFTPD without terminating the current sessions?</para>
</question>
<answer>
<para>Short answer, no. Longer answer is no, but you can minimise the
effects. The cleanest approach on servers which have significant
amounts of traffic appears to be to use ftpshut to block new
connections and terminate existing ones after a pre-determined time
period and then to upgrade and restart. This approach limits the
number of downloads which are terminated part way through.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>No such group "nogroup"</para>
</question>
<answer>
<para>The default ProFTPD configuration file uses the user "nouser" and
the group "nogroup", some systems / distributions do not have the
group "nogroup" defined. The solution is to either add the group
"nogroup" to /etc/groups or to change the "nogroup" entry in the
proftpd.conf to a group which does exist.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>Why do I see "unable to set groups: Invalid argument"? </para>
</question>
<answer>
<para>The setting of the group privileges for a process uses the setgroups(2)
system call. This call will fail with the above error message for
one of two reasons: there is a negative GID value for one of the
groups, or the maximum number of groups for a single user has been
exceeded.</para>
<para>Ideally, all IDs, both UID and GID, will be positive. Unfortunately,
it is common on many systems to use -1 or -2, especially for such
users as 'nobody', or group 'nogroup'. Use of these values uses C's
treatment of data types to make the actual numeric value very high;
some functions, like setgroups(), do not like this, though. In
general, always use positive ID numbers.</para>
<para>The other limitation is the number of supplemental groups for a user
(eg non-primary groups, the ones configured in /etc/group). The
maximum number of supplemental groups to which a user may belong
is defined by the operating system constant NGROUPS_MAX. On
some operating systems, such as Solaris, this limitation may be
tunable.</para>
<para>Some other applications may not encounter this error if they use the
initgroups(3) function, which reads the /etc/group file for a user's
supplemental group memberships, and sets those groups. This function,
however, silently ignores any supplemental groups for user greater than
NGROUPS_MAX, unlike setgroups(2), which complains.</para>
<para>
If this is the cause of your error message, any solution will most
likely involve reducing the number of groups your users are members of,
or tuning the NGROUPS_MAX value, if your operating system allows it.</para>
</answer>
</qandaentry>
</qandaset>
</chapter>
<chapter><?dbhtml filename="faq-ch5.html">
<title>Configuration problems</title>
<qandaset defaultlabel="number">
<para>Problems encountered in trying to make the server behave
exactly as required after compilation and installation are
complete and the server is running.
</para>
<qandaentry>
<question>
<para>How do I add another anonymous login or guest account?</para>
</question>
<answer>
<para>You should look in the sample-configurations/ directory from
your distribution tarball. Basically, you'll need to create another
user on your system for the guest/anonymous ftp login. For security
reasons, it's very important that you make sure the user account
either has a password or has an "unmatchable" password. The root
directory of the guest/anonymous account doesn't have to be the user's
directory, but it makes sense to do so. After you have created the
account, put something like the following in your /etc/proftpd.conf
file (assuming the new user/group name is private/private):</para>
<programlisting>
<Anonymous ~private>
AnonRequirePassword off
User private
Group private
RequireValidShell off
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>
</programlisting>
<para>This will allow ftp clients to login to your site with the username
"private" and their e-mail address as a password. You can change the
AnonRequirePassword directive to "on" if you want clients to be
forced to transmit the correct password for the "private" account.
This sample configuration allows clients to change into, list and read
all directories, but denies write access of any kind.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>How do I ftp as root?</para>
</question>
<answer>
<para>First off this is a <emphasis>bad</emphasis> idea ftping as root is insecure,
there are better more secure ways of shifting files as root.</para>