userguide.sgml

 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
<!ENTITY directivesbyname    SYSTEM "directives/output/by_name_source.sgml">
<!ENTITY directivesbymodule  SYSTEM "directives/output/by_module_source.sgml">
<!ENTITY directivesbycontext SYSTEM "directives/output/by_context_source.sgml">
]>
<book ID="PROFTPD"><?dbhtml filename="userguide.html">
<bookinfo>
    <title>Proftpd</title>
    <subtitle>A User's Guide</subtitle>
    <authorgroup>
      <author>
	<firstname>Mark</firstname><surname>Lowes</surname>
      </author>
    </authorgroup>
    <ISBN>None.</ISBN>
    <RELEASEINFO>Build 20020919 - draft</RELEASEINFO>
    <PUBDATE>$Date$</PUBDATE>
    <edition>Version 0.1.4</edition>
    <pubdate>31/Jan/2001</pubdate>
    <copyright><year>2001</year>
      <holder>Mark Lowes</holder>
    </copyright>

    <legalnotice>
      <para>Permission to use, copy, modify and distribute the ProFTPD
      User Guide and its accompanying documentation for any purpose
      and without fee is hereby granted in perpetuity, provided that
      the above copyright notice and this paragraph appear in all
      copies.</para>
    </legalnotice>

    <legalnotice>
      <para>The copyright holders make no representation about the
      suitability of this document for any purpose. It is provided
      <quote>as is</quote> without expressed or implied
      warranty.</para>
    </legalnotice>
    
  </bookinfo>

  <dedication>
    <para>This book is dedicated to Lady Kayla.</para>
  </dedication>
  
<PREFACE ID="PREFACE"><?dbhtml filename="ch00.html">
<!--
<DOCINFO>
<PUBDATE>$Date$</PUBDATE>
<RELEASEINFO>$Revision$</RELEASEINFO>
</DOCINFO>
-->
<TITLE>Preface</TITLE>

    <para>Welcome to this text on the ProFTPD server software, this
    document grew out of a need for good documentation for the
    software.  ProFTPD was written as an Open source software project
    released under the Gnu Public License (GPL).  Many of the concepts
    have been inspired by or derived from the Apache webserver
    project.</para>

    <para>This book grew out of a small FAQ on the proftpd.org website
    prior to the change in maintainer in Sept 1999.  The need for a
    accurate and comprehensive FAQ as obvious, it rapidly became clear
    that a simple FAQ would not be sufficient.  In Oct 1999 I started
    work on developing this document using the DocBook DTD in
    conjunction with the jade.</para>
    
    <para>The software is currently designed for the Unix operating
    system and it's derivatives including Linux and the BSD variants.
    It is also reported to compile under win32, however it has not
    been designed for this environment.</para>
    
    <SECT1>
      <TITLE>This Book's Audience</TITLE>
      
      <para>This text is primarily targeted at system administrators
      who wish to make the most of the Proftpd software package.  I
      expect that most readers will have at least a grasp of the ftp
      protocol and reasonable skills in compiling and maintaining a
      live Unix based system.  For a list of resources which I
      consider to be useful reading to give this base knowledge
      consult <XREF LINKEND="APP-RESOURCES">.</PARA>

      <para>It is my hope, however, that the text is sufficiently
      generic in approach that it will be of use to those simply
      wishing to know more about ftp and the function of a typical ftp
      server.</para>

      <para>The later chapters go into more depth on complex
      configurations and discuss the needs of a live server hosting
      multiple virtual hosts and hopefully suggest ways in which to
      keep the administration of these configurations to a manageable
      scale.</para>
    </SECT1>

    <SECT1>
      <TITLE>Why Read This Book?</TITLE> 

      <PARA>This book is designed to be the clear, concise, informative
      reference to the Proftpd <ACRONYM>FTP</ACRONYM> server software,
      I hope that this document will become the official documentation
      for this software.</para>

      <PARA>I hope to answer, all the questions you
      might have about the issues concerning setting up and
      configuring Proftpd and running the server software in the open
      and sometimes hostile environment of the Internet.  In
      particular I cover the following subjects:</para>

      <ITEMIZEDLIST>
	<LISTITEM>
	  <PARA>How FTP operates, is defined and how it fits into
	  todays Internet.</para>
	</LISTITEM>
	<LISTITEM>
	  <PARA>How to configure a basic anonymous ftp server and a
	  basic user based ftp server.</para>
	</LISTITEM>
      </ITEMIZEDLIST>
    </sect1>

    <SECT1 ID="PREF-REQ-COMMENTS">
      <TITLE>Request for Comments</TITLE> 

      <PARA>Please help me improve future editions of this book by
      reporting any errors, inaccuracies, bugs, misleading or
      confusing statements, and plain old typos that you find. An
      online errata list is maintained at.  Email your bug reports and
      comments to us at <ULINK URL="mailto:hamster@vom.org.uk"
      ROLE="online">hamster@vom.org.uk</ULINK>.</PARA>

    </SECT1>

    <sect1>
      <TITLE>Organisation of This Book</TITLE>
      
      <PARA>This book is divided into xxxmultiplexxx parts. <CITETITLE>Part I:
      Introduction</CITETITLE> is an introduction to ftp, security and
      your first ftp server:</para>
      <VARIABLELIST>
	<VARLISTENTRY>
	  <TERM><XREF LINKEND="CH-BACKGROUND"></TERM>
	  <LISTITEM>
	    <PARA>A quick introduction to FTP</PARA>
	  </LISTITEM>
	</VARLISTENTRY>
      </VARIABLELIST>

      <para><CITETITLE>Part II: Configuration</citetitle> is a guide
	to getting the server configured and running</para>
      <VARIABLELIST>
	<VARLISTENTRY>
	  <TERM><XREF LINKEND="CH-BACKGROUND"></TERM>
	  <LISTITEM>
	    <PARA>A quick introduction to FTP</PARA>
  </LISTITEM>
	</VARLISTENTRY>
      </VARIABLELIST>
    </sect1>
        
    <sect1>
      <title>Acknowledgements</title>
      <para>Many thanks to the Proftpd developers, anyone who's posted
      useful information to the mailing lists and everyone who has
      mailed me direct.</para>
    </sect1>
    
    <sect1>
      <title>Copyrights and Trademarks</title>

      <para>This document may be reproduced in whole or in part,
      without fee, subject to the following restrictions:</para>
  
      <para>The copyright notice above and this permission notice must
      be preserved complete on all complete or partial copies</para>

      <para>Any translation or derived work must be approved by the
      author in writing before distribution.</para>

      <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>

      <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>

      <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>
    </sect1>
  </preface>

  <PART ID="PROFTPD-INTRO">
    <?dbhtml filename="part1.html">
    <title>Introduction</title>

    <chapter id="CH-BACKGROUND">
<?dbhtml filename="ch01.html">
<title>Background</title>



<sect1>
<title>What is Proftpd</title> 

<para>ProFTPD is a ftp server primarily written for the various unix
variants though it will now compile under win32.  It has been designed
to be much like Apache in concept taking many of the ideas
(configuration format, modular design, etc) from it.</para>
</sect1>

<sect1>
<title>Who codes/maintains Proftpd?</title>

<para>As with all Open source projects, no one person can really lay claim to
the entire package.  The ProFTPD project was started by Floody who took
it to approximately 1.2.0pre2/3 before he found that his available time
was insufficient to handle this project as well as his other commitments.
From approximately mid-1999 MacGyver took over the project and pushed
it forward getting 1.2.0 out into the wild.  From early 2002 TJ took
the reins of the project and started to get releases and new features
into the code.</para> 

<para>There are also numerous people involved in developing modules and
documentation for the project.  A number of these have been merged into
the core distribution and more are likely to follow.</para>
</sect1>

      <sect1>
	<title>Website & documentation</title>
	
	<para>The official website for the project is
	http://www.proftpd.org/, both should be a mirror of the
	other.</para>

	<para>The documentation is being brought back into shape at
	the moment, the configuration on the website is reasonable but
	the documentation supplied in the source should be considered
	to be canonical.  Even this is still being brought up to
	date.</para>
      </sect1>

      <sect1>
	<title>Bug reporting?</title>

	<para>Bugs are best reported via the Bugzilla interface at
	http://bugs.proftpd.org/</para>

      </sect1>

      <sect1>
	<title>Mailing lists</title>

	<para>There are three lists for ProFTPD</para>

	<sect2>
	  <title>Announce</title>
	  <para>
proftpd-announce@proftpd.org</para>

<para>This is a very low traffic list where only ProFTPD announcements/changes
will be announced.</para>

	  <para>Subscribe by sending a message to
	  proftpd-announce-request@proftpd.org with "subscribe" in the
	  subject.</para>
	</sect2>
	
	<sect2>
	  <title>Users</title>

	  <para>proftpd@proftpd.org</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
	  proftpd-request@proftpd.org with "subscribe" in the
	  subject.</para>
	</sect2>

	<sect2>
	  <title>Development</title>

	  <para>proftpd-devel@proftpd.org</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
	  proftpd-devel-request@proftpd.org with 'subscribe' in the
	  subject.</para>
	</sect2>
      </sect1>
      
      <sect1>
	<title>Copyright Issues</title>

	<para>The Proftpd 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>
      </sect1>
      
    <sect1>
	<title>The FTP protocol</title>
	
	<para>FTP was defined initially in RFC959 and has been updated
	in RFC2228.  The protocol pre-dates RFC959 by over a decade
	during which time various RFC's were written to move the
	protocol towards a clear stable standard.  This standard has
	now served the Internet well for fourteen years and shows only
	minor signs of it's age.  RFC2228 currently only has standards
	track status but shows all the signs of becoming a full IETF
	standard for the internet.  This new RFC extends the protocol
	to include encrypted and authenticated connections and to
	provide methods of assurance of data integrity.  Proftpd is
	RFC959 compliant and there are plans to make it RFC2228
	compliant in version 1.4 and later.</para>

	<para>The File Transfer Protocol (FTP) does exactly what it
	says, it allows the movement of files from one place to
	another.  Like most of the services on the internet it's
	designed round the client-server model.  Given this software
	related to ftp can be split along these lines, Proftpd is a
	ftp server.</para>

	<para>FTP servers allow access by authenticating users against
	a password database of some description.  Historically this
	has been the unix /etc/passwd file (and later /etc/shadow)
	more recently support for other authentication systems as been
	provided including NIS, Radius, SQL, LDAP and many others.
	For most servers the username and password are sent over the
	network in plain-text.  There is a RFC defining the
	specification for encrypted passwords for use with ftp servers
	but this not had a widespread takeup.</para>

	<sect2>
	  <title>Anonymous Servers</title>
	  
	  <para>In addition to properly authenticated users there ftp
	  has historically allowed a special class of user.  The
	  "anonymous" connection, primarily used for public archives
	  of data, programs or general "stuff" anonymous logins allow
	  anyone on the network to connect to a server.  Normally
	  anonymous connections are limited in number to prevent the
	  free aspect to the server from overwhelming it's primary
	  function and the access permissions and rights of the
	  anonymous user are locked down.</para>

	  <para>Anonymous servers are one of the great resources of
	  the Internet, over the years they collectively have become a
	  massive redundant public storage system for information and
	  programs.  This is partly due to the open nature of many
	  admins in what they will allow to be hosted and partly in
	  the habit of "mirroring" other sites to spread the load.
	  Without anonymous servers it's unlikely that the Open Source
	  community would have been able to achieve the critical mass
	  and accessibility required for it's current success.</para>
	</sect2>

	<sect2>
	  <title>Sockets and ports</title>

	  <para>FTP was designed round a two socket model, streaming
	  data down one socket and control information down the other.
	  This design makes it possible for a well designed client to
	  be uploading and downloading while still permitting the user
	  to perform other administrative tasks on the server.</para>

	  <para>
	    Normally the control socket uses port 21 (ftp) at the
	    server end, the data socket handling is more complex.  Two
	    modes of operation are defined for ftp connections.
	  </para>

	  <sect3>
	    <title>Active</title>

	    <para>Active mode connections run control over port 21 and
	      allow the server to decide which socket to use locally
	      for data traffic.
	    </para>

	  </sect3>
	  <sect3>
	    <title>Passive</title>
	    
	    <para>
	      Passive Mode connections work the same way as normal
	      (Active Mode) connections, except the data connection is
	      also made from the client to the server. This avoids the
	      problem of incoming data connections being blocked by
	      the firewall by making both connections from the
	      client. </para>
	  </sect3>

	  <sect3>
	    <title>Problems</title>
	    <para>Unfortunately, not all FTP clients are capable of
	      passive mode transfers, and not all users are aware of
	      their existence or the problems they solve. Some
	      firewalls can be configured to allow incoming FTP data
	      connections while blocking all other incoming TCP
	      connections. (The firewall recognises FTP data
	      connections because they originate from port 20, the FTP
	      data port). This allows Active Mode FTP transfers
	      through the firewall without blocking the incoming FTP
	      data connections. Support for port connections
	      established on the traditional FTP data port (20) was
	      added in Rumpus 1.2, so older versions of Rumpus will
	      not work correctly with firewalls configured this
	      way.</para>

	    <para>Passive Mode connections work the same way as normal
	      (Active Mode) connections, except the data connection is
	      also made from the client to the server ie made to port
	      ftp-data (20). This avoids the problem of incoming data
	      connections being blocked by the firewall by making both
	      connections from the client.  What it boils down to is
	      Active control channel, port 21 data channel, server
	      specifies random port.  Passive control channel, port 21
	      data channel, port 20 I guess it's doc time :)
	    </para>
	  </sect3>
	</sect2>
      </sect1>
    </chapter>
    
    <chapter id="install">
      <title>Compilation and installing</title>
      
      <para>Being Open Source code Proftpd is available primarily as
      source code for local compilation.  There are a number of
      maintainers within the project who create the packaged builds
      for the primary platforms and distributions.  For most users the
      packaged builds will prove to be sufficient and the least hassle
      route to installing Proftpd.  However to use the daemon to it's
      fullest or to explore some of the more interesting features a
      local custom build will be required.</para>

      <sect1>
	<title>Architecture</title>

	<para>Proftpd was designed from the ground up to be both
	extensible and as secure by design as possible.  Security is
	discussed in depth later in this document, however while there
	are no known security holes it cannot be said of this or any
	other piece of software that there are no problems waiting to
	be found.  The extensibility is provided by means of a modular
	architecture which takes many lessons and features from the
	Apache webserver project.  Almost all the functionality has
	been supplied by moving most functions into modules.  This
	includes features such as "ls" and the authentication
	handling, this approach allows third party developers to
	provide additional modules to latch onto these hooks to add or
	extend the basics provided.  Most of the more interesting
	modules have to be compiled in as they are not part of the
	standard builds.  Unfortunately dynamically loadable modules
	are not available within the 1.2.x code tree though
	development and testing is planned for the 1.3.x development
	branch.</para>
      </sect1>

      <sect1>
	<title>Installing packaged versions</title>
	
	<sect2>
	  <title>Linux (RPM)</title>

	  <para>The Linux RPM package is available on the main
	  distribution sites for Proftpd.  Installation is as simple as

<prompt>rpm --install proftpd-{version}.rpm</prompt>
</para>
	  <para>Note: check multiple rpm route now supported.</para>
	</sect2>
	
	<sect2>
	  <title>Linux (DEB)</title>

	  <para>The Debian package is equally as simple to install as
	  the RPM with either

<programlisting>
dpkg --install {debfile}

or

apt-get install proftpd
</programlisting>

</para>
	</sect2>

	<sect2>
	  <title>FreeBSD</title>
	  <para>Does anyone have any comments on the BSD install?</para>
	</sect2>
      </sect1>

      <sect1>
	<title>Compiling from source</title>
	
	<sect2>
	  <title>Supported Platforms</title>

	  <para>Proftpd is reported to compile and function on the
	  following platforms,</para>

<programlisting>
Linux 2.0.x &amp; 2.2.x (glibc 2.x only), 2.4.x
BSDI 3.1 & 4.0
IRIX 6.2, 6.3, 6.4, 6.5
Solaris 2.5.1, 2.6 & 2.7, 8, 9
AIX 3.2, 4.2, 4.3.3
OpenBSD 2.2/2.3
FreeBSD 2.2.7, 3.x, 4.x, 5.0
Digital UNIX 4.0A, 5.1A, 5.1B
DEC OFS/1
UnixWare 7
SCO OpenServer 5.0.5
</programlisting>

	  <para>Some platforms require that compilation is done with
	  gcc (or one of it's variants) while other platforms only
	  function properly if compiled with the compiler shipped with
	  the OS.  Experiences vary and at this time there is no
	  reliable list of which platform requires what.</para>

<sect3>
<title>FreeBSD</title>

<para>ProFTPD is part of the FreeBSD ports collection. The minimal install
commands on a system with a properly installed ports tree are:</para>
<literallayout>
 cd /usr/ports/ftp/proftpd
 make install
</literallayout>
<para>More information can be found in the README.html file in the same
directory.</para>

</sect3>

	</sect2>
	
	<sect2>
	  <title>Including additional modules</title>

	  <para>Only the essential core modules are compiled in by
	  default, most of the more interesting features such as sql
	  support, upload/download ratios etc etc are contained within
	  the non-standard modules.</para>

	  <para>Including additional modules is only possible at
	  compile time, at the moment there is no chance of
	  dynamically loadable modules entering the 1.2.x code tree.
	  This is primarily due to time and the need for some major
	  structural changes within the code to support dynamically
	  loadable modules.</para>

<example>
<title>Configuring for additional modules</title>
<programlisting>
./configure --with-modules=mod_module1:mod_module2
make
make install
</programlisting>
</example>
	</sect2>
</sect1>

      <sect1>
	<title>Compatibility Issues</title>

	<para>
sendfile
	  bsd
	  linux 2.2 vs 2.0
mod_linuxprivs
libc5

</para>
      </sect1>

      <sect1>
	<title>linux</title>
	<para></para>
	<sect2>
	  <title>Why not libc5 on Linux?</title>

	  <para>There are several known problems with libc5-based
	    systems, including improperly implemented library routines
	    (vsprintf and vsnprintf are examples).  There are known
	    problems with the resolver library.  For these reasons and
	    others lib5 is not being supported at all, the latest
	    versions of the major distributions (inc Debian, Redhat
	    and Suse) are all glibc.</para>
	</sect2>
      </sect1>

      <sect1>
	<title>CVS</title>

	<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
	  code base 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>

	<sect2>
	  <title>Recommended ~/.cvsrc settings</title>
	  <informalexample>
	    <programlisting>
cvs -z 3
update -Pd
diff -u
	    </programlisting>
	  </informalexample>
	</sect2>

	<sect2>
	  <title>Where can I get information on cvs?</title>

	  <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>
	  </sect2>
      </sect1>

      <sect1>
	<title>How do I get debug output</title>

	<para>The easiest way is to fire up proftpd manually from the
	  command line with the debug level cranked up.
	  /usr/local/sbin/proftpd -d9 -n</para>

	<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>
      </sect1>

      <sect1>
	<title>Patches</title>

	<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 -u" to generate the patch.

cvs diff -u filename > filename.patch

or

cvs diff -u > bigger.patch
</para>

	<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>
      </sect1>

      <sect1>
	<title>Using non-default modules</title>

	<para>Simply configure ProFTPD with 

./configure --with-modules=mod_module1:mod_module2:mod_module3
make
make install
</para>
      </sect1>

      <sect1>
	<title>Plans for next version (1.3.x)</title>
	
	<para>The new development series will be 1.3.x, using the same
	number scheme as the linux kernel developers.  The
	targets/goals are:

refining/redefining the module API to make it more extensible and useful.
dynamic modules
security APIs and implementations
mod_ls rewrite
Implementing some security-related RFCs
Creating a web and GUI configuration interface to ProFTPD.
	</para>

	<para>1.4.x will be the production release of the 1.3.x
	development set.</para>
      </sect1>

      <sect1>
	<title>Longer term development</title>

	<para>For 1.9.x/2.0.x there are plans to completely recode
	some core sections of the software and creating an abstract
	layer to build the 2.x version on.  The abstract layer will
	handle all filesystem and OS-specific stuff.  This layer will
	then have backends onto the major environments (ie Unix and
	NT)</para>
      </sect1>

      <sect1>
	<title>NT Support</title>

	<para>If/when a port is undertaken for NT, it will only be
	after a near complete rethinking of ProFTPD.  This is planned
	for 2.0 and onwards.</para>
      </sect1>

      <sect1><title>New features/modules</title>

	<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>

	<sect2>
	  <title>Suggestions made for future development</title>
	  <para>

GUI based configuration tool
</para>
	</sect2>
	</sect1>

    </chapter>

    <chapter id="security">
      <title>Security Issues</title>

      <para>As with all services there is the risk that abuse can
      happen or that a crack attempt will be made on the hosting
      server.  As a general rule crackers will attempt to break in
      through known holes in the various server daemons
      running.</para>

      <para>The cautious and security conscious system admin should be
      aware of the two main avenues for abuse, external and internal.
      I will consider external attacks to be those made by individuals
      without valid accounts or "user" level access to the server.
      Internal I will consider as being those individuals with
      authenticated user access of some form to the server.</para>

      <para>Server Security security holes weak passwords Abuse of
      server warez dumping ground</para>

      <sect1>
	<title>Securing ftp servers</title>

	<para>In general there is not much more to securing a ftp
	server than there is to any other public access server.
	However the twin socket design and thus the requirement to
	never quite give up root privileges completely leaves a window
	ajar for the competent cracker to climb through.  Or
	occasionally a thumping great sign and open door for a script
	kiddie with some time to spare.</para>

	<para>Proftpd provides for some additional security by it's use
	of chroot(), user and IP access limits, command and path
	filters to limit what and where files can be uploaded and it's
	attention to when root privs are needed and when they are not.
	However a buffer overflow in the wrong place and it's possible
	that the server is compromised beyond hope.</para>

	<para>Simple steps which can be taken to tighten security
	include</para>
	
	<itemizedlist mark=opencircle>
	  <listitem><para>Log to a separate machine</para></listitem>
	  <listitem><para>Traffic filtering upstream of the server</para></listitem>
	  <listitem><para>chroot() all sessions</para></listitem>
	  <listitem><para>Don't give a valid shell where it's not needed</para></listitem>
	  <listitem><para>Run an intrusion detection system</para></listitem>
	  <listitem><para>If possible place the OS itself on a bootable CDrom</para></listitem>
	  <listitem><para>Tripwire</para></listitem>
	  <listitem><para>Decent backups</para></listitem>
	</itemizedlist>

      </sect1>

      <sect1>
	<title>Daemon security</title>

	<para>Recently (between versions 1.2.0pre3 - 1.2.0pre7) there
	have been a number of buffer overflow type security problems
	with ProFTPD, with the coming release of pre7 these should be
	under control.  Though no absolute statement can be given on
	the security of the software (this is true for every piece of
	software out there).  A significant amount of effort has been
	put into removing the more 'dangerous' system calls which are
	prone to overflow attacks.</para>

	<para>There is a known security problem with ALL unix FTP
	daemons, which requires the daemon to retain root privileges
	even after a client has fully authenticated. In ProFTPD
	versions 1.0.x, a decision was made to ignore RFC959's port 20
	requirements in the interests of security.  This approach has
	now been abandoned in favour of a more rfc compliant
	approach.</para>

	<para>ProFTPD takes a middle road in terms of security.  It
	only uses root privileges where required and drops to the UID
	defined in the config file at all other times.  Times when
	root is required include, binding to ports < 1024, setting
	resource limits, reading configuration information and some
	network code.</para>
      </sect1>

      <sect1>
	<title>Password Issues</title> 

	<para>One of the biggest security problems about the whole FTP
	protocol is the need to have the password transmitted in clear
	text across the network.  In effect the username and passowrd
	pair are available at all times during the authentication
	sequence, resulting in this information being available to
	crackers and sniffers alike.</para>

	<sect2>
	  <title>Encrypted passwords</title>

	  <para>Currently (as of 1.2.0pre9) Proftpd does not support
	  encrypted passwords for authentication.  Development for
	  this feature is scheduled for post 1.2.0rel1, and it will
	  remove the absolute need to send the password in clear text
	  over the network.  There are some additional approaches
	  involving ssh (secure shell) which I will not cover in
	  detail in this text which can be used to secure a ftp
	  session without encrypted keys.</para>
	</sect2>

	<sect2>
	  <title>FTP as root</title>

	  <para>This is a bad idea simply because it's a major
	  security risk to send the root passowrd in clear text over
	  any network.  If there is a need to get files onto a server
	  there are always better ways of achieving it than connecting
	  via ftp as root.</para>

	  <example>
	    <title>Other approaches</title>
	    <itemizedlist mark=opencircle>
	      <listitem><para>rcp</para></listitem>
	      <listitem><para>ssh/scp</para></listitem>
	      <listitem><para>ftp as a safe user and change the ownership later.</para></listitem>
	    </itemizedlist>
	  </example>

	  <para>If you really must ftp as root then our thoughts go
	  with you on this dangerous journey as you add "RootLogin on"
	  to your proftpd configuration and may your god go with
	  you.</para>
	</sect2>
      </sect1>

      <sect1>
	<title>Server attacks</title>

	<para>As with all server processes the primary method of
	cracking remains the buffer overflow.  Due to the nature of
	the protocol and the requirement for root level privileges
	this leaves ftp daemons open to attack.  Buffer overflows are
	the result of weak programming where boundary condition checks
	have been skipped or "unsafe" system calls have been used.
	These allow a fixed length storage area to be overflowed, this
	overflow can then be used as the transport to allow the
	execution of arbitary commands as the root user.  In
	combination this is known as a "root exploit".</para>

	<sect2>
	  <title>Stack smashing protection</title>
	  <sect3>
	    <title>What about using Stackguard?</title>

	    <para>Stackguard is a gcc variant which can protect
	    programs from stack-smashing attacks, programs compiled
	    using Stackguard dies without executing the stack code.
	    While this approach is a good first line of defense
	    against future problems it's not a complete cure-all.
	    Some of the buffer overflows were found on static
	    variables, which are not protected by stack protection
	    mechanisms. </para>
	  </sect3>

	  <sect3>
	    <title>Libsafe</title> <para>Libsafe implements a
	    'middleware' layer which sits between the OS and the
	    daemon process and protects against buffer overflows.
	    This is achieved by intercepting all calls known to be
	    vulnerable to overflow.
	    http://www.bell-labs.com/org/11356/html/security.html</para>
	  </sect3>


	</sect2>

	<sect2>
	  <title>Running Proftpd as non-root</title>
	  
	  <para>Running ProFTPD as a non-root user gives only a
	  marginal security improvement on the normal case and adds
	  some functional problems.  Such as not being able to bind to
	  ports 20 or 21, unless it's spawned from inetd.  The
	  inability to bind to ports 20 and 21 makes this approach
	  useless for commercial hosting environments where the
	  customers are expecting the connection to be on a "standard"
	  port.</para>
	</sect2>

	<sect2>
	  <title>Linux</title>

	  <para>For Linux 2.2.x kernel systems there is the POSIX
	  style mod_linuxprivs module which allows very fine grain
	  control over privileges.  This is highly recommended for
	  security-conscious admins.</para>
	</sect2>
      </sect1>

      <sect1>
	<title>Firewall issues</title>

	<para>Generally ftp and firewalls are quite capable of
	co-existing on the same or separate networks with the minimum
	of fuss.  The source of problems stem from the fundamental
	design of ftp and it's twin socket approach to data transfer.
	Firewalls, good ones at least, approach security by assuming
	everything is hostile and then starting to open up holes to
	trusted ports and destinations.</para>

	<para>FTP, as has been mentioned in an earlier chapter has two
	main methods of operation, passive and active.  Passive mode
	support is difficult in the extreme to support within a
	firewall, it requires the tracking of port 21 connections in
	and outbound and opening up complete tcp holes for that
	connection on the fly and tearing down once the control socket
	is closed.  Active support is brainlessly simple by
	comparison, opening ports 20 and 21 is sufficient, nothing
	more complex is required.</para>

<sect2>
<title>ProFTPD behind a firewall</title>
<para>Due to the multiple socket and semi-random port assignment nature of
the ftp protocol Because of the bi-socket nature of the ftp protocol
additional care must be taken when setting up ProFTPD behind a
firewall.  Setting the firewall to allow the control socket through is
easy enough, allow tcp packets destined for port 21 on the target
server.  However the data socket in passive mode may be targetted on a
random port number on the server side resulting in either a highly
complex or very weak firewall.  The PassivePorts directive allows the
admin to specify the range of ports the server will use to service
ftp-data connections, this range can then be configured on the
firewall. 
</para>
</sect2>

      </sect1>


      <sect1>
	<title>Security by obscurity and warnings</title>

	<para>Good security practice works on a combination of locking
	down all the holes as tightly as possible and letting as
	little information about the network out as possible.
	Additionally some legal systems require that explicit warnings
	are put up letting the casual connecting host know that
	unauthorised access is not permitted.  To provide these
	features Proftpd supplies a number of directives which control
	the message presented to the user.</para>

	<sect2>
	  <title>How can I prevent the server version from being displayed</title>

	  <para>Setting SeverIdent to "off" should turn off the
	  information about what type of server is running.  To have
	  maximum effect this directive should either be in the Global
	  context or included in every virtual host block and the
	  default block.</para>

	  <programlisting>
ServerIdent  on "Linux.co.uk server"

ServerIdent  off

ServerIdent  on ""
</programlisting>
	</sect2>

	<sect2>
	  <title>I want to show a message prior to login</title>

	  <para>Use the DisplayConnect directive to specify a file
	  containing a message to be displayed prior to login.</para>

	  <para>DisplayConnect /ftp/ftp.virtualhost/login.msg</para>
	</sect2>

	<sect2>
	  <title>I want to display a message after login</title>
	  
	  <para>Use the DisplayLogin directive, this sends a specified
	  ASCII file to the connected user.</para>

	  <para>DisplayLogin       /etc/proftp.msg</para>
	</sect2>

	<sect2>
	  <title>Can I have a custom welcome response?</title>

	  <para>Use the AccessGrantMsg directive, this sends a simple
	  single line message back to the user after a successful
	  authentication.  Magic cookies appear to be honoured in this
	  directive.</para>

	  <para>AccessGrantMsg "Guest access granted for %u."</para>

	  <para>Note, this directive has an overriding default and
	  needs to be specified in both VirtualHost and Anonymous
	  blocks.</para>
	</sect2>
      </sect1>

      <sect1>
	<title>How can I control what commands the server accepts?</title>

        <para>The &lt;Limit&gt; context allows for fine-grained control over
        which FTP commands will be accepted by the server.</para>

	<para>Use a sane Allow/DenyFilter, these directives use
	regular expressions to control all text sent over the control
	socket.  (If anyone has some good examples please let me
	know.)</para>
      </sect1>
      <sect1>
	<title>Secure Sockets Layer (SSL)</title>

        <para>Support for SSL/TLS officially appeared in the 1.2.8rc1
        release.</para>
      </sect1>


    </chapter>
    

    <chapter>
     <title>Day to day issues</title>
      <sect1>
	<title>Starting and stopping your server</title> 
	
	<para>inetd, standalone, hosts.allow, HUP, PID,
	/etc/shutmsg</para>
      </sect1>

      <sect1>
	<title>Timezone issues</title>
	
	<para>http://proftpd.org/docs/configuration.html#TimesGMT says
	the default for this config option is 'on' in versions
	1.2.0pre9 and beyond, and that the command exists in those
	same versions.  That said, my install (from src) of 1.2.0pre10
	neither supports the directive nor uses GMT.</para>

	<para>(And, of course, exporting TZ=GMT before running it
	doesn't help, since it overwrites its environment after
	starting.  I presume this is why the directive was added.)
	Jim, the ChangeLog file in the current CVS source tree
	contains these entries dated after the release of 1.2.0pre10
	(17 Jan 2000):</para>

	<para>My copy of the pre10 doc/Configuration.html doesn't
	contain the TimesGMT directive, nor is there any code for it.
	So, it looks like it was added after pre10, and the
	documentation is flat out wrong about the time of its
	introduction.</para>

	<para>Well, with the environment overwritten time will be
	reported GMT, so I don't think that was the motivation.  FYI,
	the environment overwrite bug should be fixed (finally!) in
	the current CVS sources (but it had nothing to do with the
	TimesGMT directive).  However, you also may need to apply the
	suggested fix for Bug#76, if you wish to compile the current
	CVS sources on most non-Linux systems:
	http://bugs.proftpd.org/show_bug.cgi?id=76
	http://bugs.proftpd.org/showattachment.cgi?attach_id=27 So, it
	looks like it was added after pre10, and the documentation is
	flat out wrong about the time of its introduction.</para>

	<para>It will be reported in whatever zoneinfo file
	/etc/localtime is (or is a symlink to).  At least it is on my
	box.</para>
      </sect1>

      <sect1>
	<title>Log management</title> 

	<para>rotation, location, opening, log analysis</para>


	<sect2>
	  <title>Rotating the log</title>
	  
	  <para>Any of the common tools for managing log rotatation
	  can be used with Proftpd.  The most commonly used package is
	  logrotate as shipped with Redhat.  Some suggested
	  configurations are shown below.</para>

	  <example>
	    <title>logrotate configuration</title>
	    <programlisting>
        # cat /etc/logrotate.d/proftpd
        /var/log/proftpd {
                nocompress
                missingok
        }
</programlisting>
</example>

	  <example>
	    <title>logrotate configuration</title>
	    <programlisting>
/var/log/xferlog {
    # ftpd doesn't handle SIGHUP properly
    nocompress
}
/var/log/proftpd {
    nocompress
}    
</programlisting>
	  </example>

	  <example>
	    <title>logrotate configuration</title>
	    <programlisting>
/var/log/xferlog {
     postrotate
         /usr/bin/killall -HUP proftpd
     endscript
}
</programlisting>
	  </example>

	  <para>Proftpd does not use SIGHUP to close and reopen the
	  logfiles so one of two basic stratagies have to be employed
	  to ensure that the logfiles are not being held open.  The
	  first and most aggressive is to shutdown proftpd, rotate the
	  logs and restart.  This might be acceptable on a small
	  server but not on a commercial system</para>

	  <para>A second approach would be to rotate the logfiles and
	  not perform any parsing or compression until all the live
	  connections have ended.  This time can either be based on
	  guesswork (ie I'm pretty sure everyone will have finished
	  the active connection within 60 minutes) or by employing a
	  script to kill off any remaining connections after a
	  suitable time period (by using such as the fuser
	  command).</para>
	</sect2>

	<sect2>
	  <title>Analysis of logfiles</title>

	  <para>So, you want to know what's happening with your ftp
	  server, are those logs any help.  Not normally is the most
	  common response, as a general rule logfiles are unreadable
	  and while providing the raw information for spotting trends
	  are not the best format for presenting the
	  information.</para>

	  <para>There are a number of different packages and
	  approaches available to the sysadmin on the go to process
	  his logs into a more readily understandable format.</para>

	  <variablelist>
	    <title></title>

	    <varlistentry>
	      <term><filename>Webalizer</filename></term>
	      <listitem>
		<para>Webalizer is primarily designed as a web server
		log analysis tool.  However it is capable of handling
		ftp server logs (set the logtype configuration option
		to 'ftp').  The latest version uses the png graphic
		format.</para>

		<para>http://www.mrunix.net/webalizer/</para>

		</listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><filename>http-analyze</filename></term>
	      <listitem>
		<para>http-analyze is the system from which webalizer
		was derived.  It requires more work in setting up
		proftpd's logging format however it can give far more
		detailed reports.</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><filename>HTTP-analyze</filename></term>
	      <listitem>
		<para>http://www.netstore.de/Supply/http-analyze/</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><filename>analog</filename></term>
	      <term><filename>http://www.analog.cx/</filename></term>
	      <listitem>

		<para>If you want to use Analog (works fine for me)
		this is your logformat: </para>
		<informalexample>
		  <programlisting>
LOGFORMAT (%j %M %d %h:%n:%j %Y %t %S %b %r %j %j %j %j %u %j %j %j)
		  </programlisting>
		</informalexample>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><filename>Report Magic</filename></term>
	      <term><filename>http://www.wadsack-allen.com/digitalgroup/reportmagic/</filename></term>
	      <listitem>
		<para>Produces more 'professional' looking reports
		based on analog data.</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><filename>logwatch</filename></term>
	      <term><filename></filename></term>
	      <listitem>
		<para></para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term>Others</term>
	      <listitem>
		<para>Logsurfer (need URL) and a Perl custom reporting
		module
		(http://www.cpan.org/modules/by-authors/id/S/SN/SNEEX/)</para>
	      </listitem>
	    </varlistentry>

	  </variablelist>
        </sect2>

	<sect2>
	  <title>Custom Logging</title>
	  <para>Thank you so much! This has GREATLY reduced the load on my server! Now I
just have my ftp log, and the secure log with proftpd entries. Thanks
again!


LogFormat	xfer_fmt		"%t %u %f"
ExtendedLog	/var/log/upload	write	xfer_fmt
ExtendedLog	/var/log/dnload	read	xfer_fmt


You can use this directive to disable the syslogd usage :

SystemLog                       /usr/local/proftpd/logs/system_log

a) will proftpd support piped logs?
b) anyone intersted in make a mod_cronolog?
	http://www.ford-mason.co.uk/resources/cronolog/


im running Proftpd 1.2.0pre3 and i'm having trouble finding a log analyser
that will support the type of logs i run through it. the main problem being
i have extended characters and white spaces in file names. all log analysers
i've tried interperet the whitespace as the end of the file name.

is there any way to have proftpd use %20 instead of a space in the log file?
or better yet, have proftpd keep a log CLF style?

</para>
	  </sect2>

      </sect1>
      <sect1>
	<title>FXP</title>

	<para>FlashFXP is a Windows program which allows site to site
	transfers via the port bouncing technique described in rfc2577
	(FTP Security Considerations [informational]).  As a general
	rule allowing port bouncing is a bad idea and a major security
	hole.</para>

	<para>Configuring Proftpd to allow port bouncing is simple,
	add "AllowForeignAddress on" in either the Global or Anonymous
	sections as appropriate and reloading the configuration will
	suffice.  Without these directives the server will report "425
	Passive PASV port theft" to syslog.</para>

	<example>
	  <title>Configuration fragment</title>
	  <programlisting>	
ServerName			"Frostbite FTPserver"
ServerType			standalone
.
.
.
&lt;Global&gt;
.
.
.
	ExtendedLog    /var/spool/syslog/proftpd/fascist.log ALL default
	ServerIdent			on "Linux.co.uk server"
	AllowForeignAddress	on
	PathDenyFilter			"(\.htaccess)|(\.ftpaccess)$"
&lt;/Global&gt;
.
.
.
&lt;VirtualHost 195.200.4.15&gt;
ServerAdmin             zathras@linux.co.uk                     
ServerName              "Linux.co.uk FTP Archive"
.
.
.
&lt;Anonymous /ftp/ftp.linux.co.uk&gt;
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
	AllowForeignAddress	on
.
.
.
</programlisting>	
	</example>

      </sect1>
    </chapter>

  </part>

  <part id="PROFTPD-CONFIG">
    <?dbhtml filename="part2.html">
    <title>Configuration</title>
<chapter id="config-gettingready">
<title>Getting ready</title>

<sect1>
<title>What do you want from your server?</title>
<para>
Deciding what you want to get from your server is often the most
important part and usually the most often ignored part of the whole
process of configuring any server software for use.  Working out the
details of the server, the loading expected and the levels of access
to be given are critical to ensuring that you provide the service
levels required.
</para>
</sect1>

<sect1>
<title>Config file</title>
<para>Do you know where the daemon is expecting to find the config
file?  If not check now, the two most likely places are
/usr/local/etc/proftpd.conf and /etc/proftpd.conf.  The compile time
default as shipped with the bare source is the former however the
latter is the the default for many of the packaged versions of
ProFTPD.  
</para>
</sect1>

<sect1>
<title>Scoreboard file</title>
<para></para>
</sect1>

<sect1>
<title>Standalone or inetd?</title>

<para>


On Thu, Nov 30, 2000 at 08:01:42PM -0000, Tanuj Shah, -  mailings wrote:
> Is ProFTPd (1.2.0) better to run as standalone or via (x)inetd?
Both runs fine. Only on one Solaris box I was forced to run in
standalone mode cause it said all the time that there is another
program listening on Port 21 when I tried inetd.
 
> What are the differences etc. etc. etc. ?
One difference is that the process control (childs etc) is mananaged
bei the inetd.  Another thing is that you can start proftpd with the
tcpd when you're using the inetd.
In the standanlone mode you can use Virtual Hosts.


Personal preference, inetd for lightly used systems where resources
are an issue.  Standalone for production machines which are likely to
get pounded into the dirt and I need the additional configuration
features not available under inetd.


Well, after reading here about Redhat 7 having xinetd, and needing to =
put the server in standalone I noticed something fairly big....
I used to be able to edit the proftpd.conf file and the changes would =
take place immediately, now I have to kill the process and restart the =
server....anyone have any solutions?


If I'm not mistaken, that's normal.  A big advantage of inetd
(or xinetd) is that it listens on ports for you.  Only when it
gets a connection on a port does it launch the respective
program.  So basically proftpd gets re-launched with every
connection, thus you can edit the config and it will be in
effect for the next user.  Standalone mode though is always
running with the config it saw when it first started up,
so you do have to kill it and restart it to see the new config.


Well, after reading here about Redhat 7 having xinetd, and needing to put
the server in standalone I noticed something fairly big....
I used to be able to edit the proftpd.conf file and the changes would take
place immediately, now I have to kill the process and restart the
server....anyone have any solutions?
 

If you send the main proftpd process the HUP signal, it will re-read it's
configuration file without stopping...


I'm a Linux (RH6.0) newbie and I'm trying to get ProFtpD running on my
box...  I'm having some little problems tough :(

My first question... should I run it in standalone or inetd mode?  My ftp
won't have much traffic...  the box is a 486 dx 33 w/ 8 megs of ram...
nothing fancy...

Second question...  I tried to run it from commandline in inetd mode... it
said that in order to run it from commandline it needs to be in standalone
mode... and for inetd mode, proftpd has to be started by the inetd
super-server.  What is this super-server and how do I get this thing to
start proftpd?

Right now when I do ftp localhost, i get a 'connection refused' error
message...  maybe proftpd isn't even running (that's my guess)... how do I
make sure it is running?


On Sun, 13 Aug 2000, Carl Mercier wrote:
> 
> My first question... should I run it in standalone or inetd mode?  My ftp
> won't have much traffic...  the box is a 486 dx 33 w/ 8 megs of ram...
> nothing fancy...

if you won't be taking on that much traffic, inetd is the preferred
method. If it's going to be a busy or "production" FTP server, standalone
is best. Frankly, it doesn't matter that much in your case.

> 
> Second question...  I tried to run it from commandline in inetd mode... it
> said that in order to run it from commandline it needs to be in standalone
> mode... and for inetd mode, proftpd has to be started by the inetd
> super-server.  What is this super-server and how do I get this thing to
> start proftpd?

type "man inetd". Reading the manual page will tell you everything you
need to know.


> 
> Right now when I do ftp localhost, i get a 'connection refused' error
> message...  maybe proftpd isn't even running (that's my guess)... how do I
> make sure it is running?

in standalone mode, you will see "proftpd" in the output of 'ps -ef'. In
inetd mode, it will be running provided you have inetd up and
configured to accept connections for proftpd.


    One thing to add... if you run proftpd in standalone mode and not
through the "inetd" server, then you must edit your /etc/inetd.conf
file and comment out the reference to ftp (the only line starting
with ftp).

    If you are going to run it through inetd, instead of commenting
out that one line, change it to run proftpd... Again see "man inetd."

    My 2 cents would be on your system to run it in inetd. That way
you don't have a ftpd server taking up memory all the time. With
inetd, the server will only take up memory when you want to use it.
Not to mention processor time, even idle processes have to be polled
by the kernel.

Later,

Hello, I have a limited use server 10+ logins a week, 20mb a week transfers
(usually upload).
I have the server setup as inetd (changing to xinetd).

Can anyone give a guideline table of when you want to use standalone vs
inetd server model?


Well, off the top of my head:

INETD
    PROS
    Can use TCP wrappers
    Not using system resources when not in use
    Does not have to run as root (better security)

    CONS
    Can't use MaxClients
    Overhead from launching process for each session (although in my
experience this is negligible)

DAEMON
    PROS
    Better performance, since the daemon is always ready to take calls
    Can use MaxClients to allot resources or avoid a DOS attack

    CONS
    Daemon must run as root to bind to port 21, although I believe ProFTPD
has some internal mechanisms to reduce risks
    Is always using system resources even when idle

There are certainly other reasons that I am sure other users can add.

I have always felt that the primary reason for choosing one over the other
is volume. Low volume tends to indicates inetd, while high volume almost
always indicates daemon. But its a balance of security and performance
either way.

A few less important pro/cons:

 INETD
      no User lockouts after too many false logins
      no reset needed after changing configuration

 DAEMON
      may suffer from memory leaks (system libs, modules,..)




Things that run on ports <1024 (as does everything in inetd.conf) have to
be run as root initially, which opens the possibility of exploitation. 
I think (keyword=think) running as standalone uses more memory than inetd.
Speed isn't an issue for me since I have logins capped at 3 simultaneous.
As for security I have a firewall router between the ftp box and well...all
I can do is all I can do. 

Stand alone is faster in theory.  I don't run anything from inetd.  My
ftp, www, ssh all run standalone.  

Given proftpd 1.2.0pre10, what are the relative merits of running it 
via inetd as opposed to standalone?

I imagine that there's greater security with inetd given its use of 
host.deny.  True?  Are there any other security issues related to 
these 2 mode of running proftpd?

If you insist not running it in standalone mode, something like tcpserver
would be much better.  Inetd does nasty things to busy systems because of
the rate limiting it has.

I run proftpd in standalone, and used to run it from inetd ;)

Are there any performance differences between the two implementations
or is the gap down entirely to the inetd overhead? if so another
superserver (tcpserver?) could be used instead and one could have the
superior rules access with a minimal overhead and performance
degredation.

</para>

</sect1>

<sect1>
<sect1info>
<author><firstname>TJ</firstname></author>
</sect1info>
<title>Contexts</title>
<para>
At present, ProFTPD has seven different configuration contexts: "main"
server, &lt;Anonymous&gt;, &lt;Directory&gt;, &lt;Global&gt;,
&lt;Limit&gt;, &lt;VirtualHost&gt;, and .ftpaccess files. These
contexts are checked for in configuration handlers using the
CHECK_CONF macro.
</para>

<variablelist>
<title>Valid Configuration contexts</title>
<varlistentry>
<term>Main server</term>
<listitem>
<para>
The "main" server context, listed as "server config" in the
configuration directive documentation, encompasses everything outside
of the other contexts (i.e. every configuration directive that is not
explicitly contained within another configuration context), and
signalled by the macro CONF_ROOT in a configuration directive handler.
</para>
</listitem>
</varlistentry>


<varlistentry>
<term>&lt;Anonymous&gt;</term>
<listitem>
<para>

The &lt;Anonymous&gt; section is used to set up the very common
configuration of an anonymous FTP server. It does a chroot() to the
anonymous FTP directory by default, and turns off the requirement for
a valid password, requesting only a valid email address as the
password. Other system binaries or files need not be contained within
the &lt;Anonymous&gt; directory.</para>

<para>Note that since an &lt;Anonymous&gt; section is not considered a
separate server, but rather a "subset" of its containing server, any
configuration directives set for that server will be in effect for the
&lt;Anonymous&gt; as well, unless overridden by a directive of the
same name in the &lt;Anonymous&gt; context itself.</para>

</listitem>
</varlistentry>

<varlistentry>
<term>&lt;Directory&gt;</term>
<listitem>
<para>

The &lt;Directory&gt; context is for configurations specific to
directories, of course. This includes views of the contained files
based on the logged-in user's username or group membership or on the
name of the files (e.g. Unix-style "hidden" files), and on whether the
user has permission to see the files. .ftpaccess files occur within
this context by definition; &lt;Limit&gt; sections often appear in a
&lt;Directory&gt; section as well.

</para>
</listitem>
</varlistentry>

<varlistentry>
<term>&lt;Global&gt;</term>
<listitem>
<para>

The description in the documentation for the &lt;Global&gt; context is
good. Another point to know is that if a directive is set in this
context, and then the same directive is used in the main or
&lt;VirtualHost&gt; contexts with different parameters, those
parameters take precedence over the &lt;Global&gt; parameters. This
allows you to configure things for everyone equally, then tweak
specific servers individually, on a per-server basis.

</para>
</listitem>
</varlistentry>

<varlistentry>
<term>&lt;Limit&gt;</term>
<listitem>
<para>
The &lt;Limit&gt; context is used to place limits on who and how
individual FTP commands, or groups of FTP commands, may be used.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>.ftpaccess</term>
<listitem>
<para>
These files are akin to Apache's .htaccess files, which are
parsed-on-the-fly configuration files -- with restricted scopes --
that users can place in their own directories. Note that .ftpaccess
are similar to Apache's .htaccess files, they are not the same. For
example, ProFTPD's .ftpaccess files do not support a "require"
directive, nor Apache's AuthRealm directive. That particular area of
Apache configuration is targetted for restricting access to anonymous
connections; by its nature, ProFTPD handles anonymous connections as
special cases of the normal authenticated connections.
</para>
</listitem>
</varlistentry>
</variablelist>

</sect1>



</chapter>


<chapter id="generic">
<title>Generic issues</title>

<sect1>
<title>File permissions and UMASK</title>

<sect2>
<title>What is a UMASK?</title>

<para>The umask is the method of automatically defining the default
set of permissions a file will have when created or uploaded.

you know how unix files have permissions, something like the following:

-rwxr-x---  

which you will see when doing an "ls -l" in a directory.

here's what they mean:

-rwxrwxrwx  
1234567890

1) For normal files, the 1st character is "-".  For directories, it's "d".
   For symbolic links, it's "l".  for other files (devices and FIFOs, see
   the ls man page)

2,3,4) Read, write and execute permissions for the file's owner.

5,6,7) Read, write and execute permissions for the file's group.

8,9,0) Read, write and execute permission for everyone else.

So, lets say that I have a file with these permissions:

-r-x------

If I want to change it to

-rwxr-xr-x

I have to do something like this

chmod a+rx file
chmod u+w file

Do you know how to count in octal?

If not, use this cheat, I mean, shortcut:

r = 4
w = 2
x = 1

so, read + execute = 4 + 1 = 5,
and read + write + execute = 7.

so If I did a

chmod 755 file

I would get

-rwxr-xr-x

When one does a "chmod xyz file":

The x is the file's owner permissions,
the y is the file's group permissions,
and the z is the files others permissions.

This way, one can do a single chmod, and effect ALL the file's
permissions at once.


As for a umask, this is the REVERSE of the permissions:

-rwxr-x---  is 750

The REVERSE of the umask is is 027  (-----w-rwx).

I guess you could think of a umask as the permissions to TAKE AWAY
from a file.

by setting one's umasks to 027 would make it so any file you create,
will be created with the permissions 027 REMOVED from the file. Like:

        -rwxrwxrwx
minus   -----w-rwx
__________________
equals  -rwxr-x---


}}What is a umask that will create 775?
002


Want to know how you can tell?

777; where each 7 is equal to rwx, therefore 002 is 775.
So, then 775 = -rwxrwxr-x

Where the r = 4
      the w = 2
  and the x = 1
         ------
              7


HTH,  -Sneex-  :]

(Note that the leading 0 is assumed -- yes it's octal :)

</para>
<para>I've got a quick question.. We've picked proftpd as our best bet at our
site and we're trying to configure it.  Everything looks great except
for one problem.  Users can create directories just fine, but they
can't change to them once they're created - when the directories are
created, they lack the execute bit.  We're shooting for permissions of
640 (rw-r-----) for files and 750 (rwxr-x---) for directories.  I've
been using the Umask configuration directive as shown below:

Umask		0137	0027
</para>
	</sect2>
</sect1>

<sect1>
<title>proftpd.umask</title>

<para>I am having some trouble. I looked through all of the FAQs, but couldn't
find anything. I looked in the different configurations, and it wasn't
much help. I was hoping someone could help me with this problem, if not
through umask then some other method.

Every time I create a directory through FTP, it is automatically chmodded
to 022. Now, I found in proftpd.conf it said:

Umark 022

So I got smart and changed it to 755, as that is what I want directories
to be at when they are created. But it still is at 022. Does anyone know
how to solve this? Is there another way? Thanks.</para>

<para>I set the umask back to 022 and now when I upload files or make
directories, the permissions are set tono one allowed to
read/write/execute. Any other way around this? I do have umask 022 in a
global block too.
</para>



<para>Vincent Paglione wrote:
&gt; 
&gt; Hello,
&gt; I set the umask back to 022 and now when I upload files or make
&gt; directories, the permissions are set tono one allowed to
&gt; read/write/execute. Any other way around this? I do have umask 022 in a
&gt; global block too.

So your effective umask is 0777 now ? If your configuration does contain
only umask 022 or less, your server is apparently started with this
setting. Check the environment from which you start proftpd.
</para>




<para>
Vincent Paglione wrote:
&gt; 
&gt; &gt; So your effective umask is 0777 now ? If your configuration does contain
&gt; &gt; only umask 022 or less, your server is apparently started with this
&gt; &gt; setting. Check the environment from which you start proftpd.
&gt; &gt;                   -job
&gt; 
&gt; Can you please explain this a little more? Thank you.

If you play around with the "umask" command in the shell you will get
a good idea what it is doing. For instance:
   rm a; umask 0 ; touch a ; ls -l a
   rm a; umask 0777; touch a ; ls -l a
   rm a; umask 022 ; touch a ; ls -l a

The umask is a property of a process and is inherited by its children,
so if you start proftpd from a shell script that sets its umask it will
start proftpd with that umask. Wait - hold that, i just looked in the
source, and i think proftpd resets its umask to 022 (or to the value in
the config file). So forget what i said about checking the environment.
It must be something in that file.                -job
 </para>



<para>Well from the way i undersood it, Umask 022 sets all directories to be 755
and all files 644, i think.....

I think your problem came when it said umark instead of umask in the config
file. Also by setting the umask to 755, your chmod becomes 022.  To get your
chmod from umask you subtract the umask # (In this case it's 022) from 777.
So:
777 - 022 = 755

Sorry if I couldn't state this more clearly but I am not good at explaining
things and I am still a Linux/Unix newbie.</para>







<para>execute should NOT be set as the default on files (on directories it
is), so you can't do it.  use chmod to get them executable if they need
to be executable.</para>


<para>I'm running ProFTPD 1.2.0pre10 for a few weeks now on a server
mainly use= d for customers websites. Someone made me notice this
problem today : All files uploaded have 644 permissions whereas
directories do have 755...  Since I've put a "Umask 022" directive in
my main server config part, I don't understand why I don't get 755
permission on created files...  I used to have BeroFTPD working fine
(for a few years), I've also tried t= o search for help or clues in
the faq or in the ML archives but without success :(

Here's what my config file looks like :

[Begin proftpd.conf ...]

ServerAdmin                     ftp@asi.fr
ServerIdent                     on "FTP Server Ready - Webpro asi.fr"
ServerType                      inetd
DefaultServer                   on
SystemLog                       /var/log/proftpd

LogFormat       default         "%h %l %u %t \"%r\" %s %b"
LogFormat       detail          "%{%a %b %d %H:%M:%S %Y}t %h %b %f (\"%r\=
")"
LogFormat       fichiers        "%{%a %b %d %H:%M:%S %Y}t &lt;%h&gt; %b bytes, =
%f"

TimeoutStalled                  300
RootLogin                       on

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask                           022

User                            nobody
Group                           nogroup
IdentLookups                    off

DefaultRoot             ~       !root
DefaultTransferMode             binary

# Normally, we want files to be overwriteable.
&lt;Directory /*&gt;
  AllowOverwrite                on
  Umask                         022
&lt;/Directory&gt;

[...End]
(the &lt;VirtualHost&gt;s have been removed)

The Umask in the &lt;Directory /*&gt; has been added just to test... but it
doesn't work better.
Any comments, ideas are very welcome since all my users have to use the
chmod command for now!
Thanks :)</para>


<para>This is usually treated in introductory Unix courses, it has been the
custom since 1973 (+/-) to set the default file permissions on files to
666 and directories to 777, and subtract umask from that. Are your users
uploading programs ?           -job
</para>


<para>Yes, the problem in having 644 (666 minus the 022 Umask
according to what you say), is that all uploaded files (including cgi
scripts) aren't executable...  Is there a way to have them all in 755
mode again? Or maybe with a &lt;Directory ...&gt; only for
~/web/cgi-bin/ ?  Thanks for any help, I'm desperate to have those
cgis +x right after uplo= ad :)
</para>

<para>I just looked in the source, but not long enough to find a spot
where the default permissions could be set to 777. Perhaps in
fs.c:std_creat - which would probably mess up the umask directive. The
proper thing would be something like a new directive FileMode, with
same context as Umask, so it could be used in .ftpaccess files.  At my
current programming speed it would take me 3 years if i would not get
distracted.  You could shellscript it in 6 minutes of course, from the
log.
</para>


<para>I had a big problem with the second parameter of the "Umask" directive.
(Better said I couldn't get it worked.) I think there is a bug in the
dir_check(_full) function in the file dirtree.c. 
</para>

<para>
The functions check only the existing directories when searching for the
right umask while when MKD (or XMKD) command is issued, the directory
(usually :-) doesn't exist. After adding the test whether actual command
is (X)MKD is umask set up properly.
</para>

<para>I have been checking the ProFTPD archives, and am currently
using ProFTPD 1.2.0pre10 to provide FTP functionality to the web
server I administer.  My problem is that the permissions on my server
are screwed = up (mask 0755 for all files and directories).  I have
been able to set the directory permissions correctly using the Umask
directive, but not the file directives (which need to be the directory
equivalent of 0755, if that makes sense).  This is actually two
questions - one, is there still a problem with the Umask directive,
and two, how do you calculate octal permissions?  I understand that
you need to generate the octal code from a list (which is how I came
up with 0755) and subtract it from 777 to get the correct umask for
directories and 666 for files, but doing 666-755 results in a
negative, non-octal number - how would I convert the directory octal
mask that I already have to the file octal mask that I need?  Thanks
in advance for any help you can give on either = of these
questions.</para>



<para>The UNIX permissions are not octal.  The permissions are a combination of
the following values: 1=eXecute, 2=Write, 4=Read.  To get the mask just
subtract each value from 7:
  777
  755
  022 &lt;- This is the umask that you want.
</para>



<para>Hm.  Well, I've recompiled ProFTPD, this time with the Y2K patch that
was just posted to the list, along with linuxprivs (thought I had it
compiled in but I guess not..?).  The server still completely ignores
the second paramater on Umask.. however, if I set the Umask to 0027,
the execute bits are automagically stripped from regular files (they
stay on new directories though).  By exploiting this behavior I've
been able to set the default file permissions on upload files to the
way I originally wanted them to be, and since users in the group 
public (A) have no real shell, (B) are denied use of the SITE CHMOD
command, and (C) can't even talk to the machine on ports other than
20, 21, and 80, they'll stay that way.  Woo.
</para>
<para>
However, I am getting one strange problem.  I've got this in my 
config:

&lt;Directory ~&gt;
  &lt;Limit ALL&gt;
    Order	deny,allow
    DenyGroup	public
    AllowAll
  &lt;/Limit&gt;
  &lt;Limit TYPE STRU MODE STOU ABOR STAT ALLO APPE REST READ LIST NLST \
         STOR RETR DELE MKD RMD CWD RNFR RNTO XMKD XRMD XPWD XCUP \   
	 NOOP PWD CDUP&gt;
    Order	allow,deny
    AllowAll
  &lt;/Limit&gt;
&lt;/Directory&gt;
</para>

<para>
That long line I split a couple times isn't actually like that in my
config.. it's all one line.
</para>

<para>
Strangely enough, this results in users who are not members of group
public to be denied access to NLST while in their home directories.
They can NLST anywhere else on the filesystem, but once they get
within their home directory (and within the scope of those limits,
I presume), they're denied NLST (but strangely enough, any of the
other commands listed in the block with NLST work fine).  I am 
completely confused by this.  Anybody have any idea how this ends up 
happening?  My goal is to ensure that as far as group public goes, 
anything not explicitly permitted is forbidden.  In particular, we
don't want users in group public changing permissions on their files, 
although after reading the RFC, there's a large amount of other stuff
that I'm cutting them off from, too.  Any user in any other group
besides public should have access to the full set of ftp commands.
</para>



<para>On Mon, Mar 06, 2000 at 09:08:57AM -0500, Matthew Eash wrote:
&gt; What is a umask that will create 775?

002

However it will only be the case for entries which would have the execute
bit set on them by default - directories in otherwords. Files will have the
mode of 664 with the above umask.
</para>
<para>
That's true (having forgot to account for that in my other comments :)
</para>
<para>
The directories need x set to allow 'searching'.
You cannot execute a directory ;)

</para>

<para>
which, unless I'm having a fit of moronic stupidity (which could
indeed be the case =) should set those permissions correctly.  It half
works - permissions on normal files are set right, but permissions on
directories are set to the same thing as normal files.  It seems that
the second parameter to Umask isn't been recognized at all.. I've
tried mucking about with it to see if there were any changes when the
second parameter was changed, but no dice.. 
</para>

<para>
&lt;Directory ~&gt;
Umask   0007
&lt;/Directory&gt;

Note I have two umask settings, one in the server context for files and
one in the directory context for dirs. This is very strange that it works
like this, but this is the only way I've found!

I run 1.2pre9 and FreeBSD 3.3. I would be very happy if the 1.2pre10 with
y2k and umask fixes released this month!</para>

</sect1>

<sect1>
<title>Setting the Umask</title> 

<para>I am using Proftpd 1.2.0Pre9 on Linux on my ftp/web server.  I
would like all the files uploaded into a directory (/cgi-bin) to
automatically receive the execute attribute (the rights should be
"-rwxr-xr-x").  I tried to do it by setting a "Umask 000" in the
proftpd.conf file but it doesn't work.</para>

	  
<para>Proftpd will not do this automatically; clients should be able
to do it with the "chmod" command, which translates to "SITE CHMOD",
but I always get "permission denied" when i try it, i have not found
why yet. Anyway, several ways to get it automatic: a script doing
chmods every x minutes, or a script reading the logfile and looking
for cgi-bins being uploaded, I have not done this, but this sounds
like what you want. Though it is very thinly documented... The
AllowFilter/DenyFilter:
http://www.proftpd.org/docs/proftpdfaq-7.html#ss7.3

</para>

</sect1> 
</chapter>


    <chapter id="virthost">
      <title>Virtual Hosting</title>
      <sect1>
	<title>What is virtual hosting</title>

	<para>When ftp was first concieved it was only possible to
	host a single ftp server on any given box.  A method to
	increase the hosting density from one site per server to many
	sites on a given server grew.  This many to one mapping is
	Virtual hosting.  The design change in the server software was
	to allow for multiple unique ftp server configurations and
	binding these to particular interfaces on the server.
	Densities of hundreds of ftp sites per serving machine are not
	unknown on today's Internet.</para>
      </sect1>

      <sect1>
	<title>IP address space considerations</title>

	<para>Unlike the HTTP/1.1 protocol there is no method to host
	more than one ftp server on a single IP.  HTTP/1.1 provides an
	additional transaction header, "Host:", to allow the server
	software to route the request to the correct virtual
	configuration.  Currently this capability does not exist in
	the FTP protocol specification.</para>

	<para>The only workaround to this limitation if address space
	is tight would be to host multiple servers on the same IP but
	different ports.  however this is not a viable solution for a
	"normal" hosting farm because of the use of non-standard
	ports.</para>

	<sect2>
	  <title>IETF draft standard</title>
	  
	  <para>There is a draft standard draft standard under
	  consideration with the IETF which extends and improves on
	  the current 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>
	</sect2>

	<sect2>
	  <title>Port based VirtualHosts</title>

	  <para>The Ports directive only makes sense within a
	  proftpd.conf in standalone mode.  In inetd mode the opening,
	  closing and handling of the listening ports is handled
	  entirely by the inetd super server daemon.</para>

	</sect2>
      </sect1>

      <sect1>
	<title>VirtualHost directive</title>
	<para>basic usage and concepts of virtualhost</para>
      </sect1>

      <sect1>
	<title>Setting up a basic virtual host</title>

	<para>virtual host.</para>

	<sect2>
	  <title>Preparing the system</title>

	  <para>The host system will need configuring with the
	  additional IP addresses for each virtual host to be
	  installed.  On most unix systems this can be done as aliases
	  on the primary ethernet interface or by dummy
	  interfaces.</para>
	</sect2>

	<sect2>
	  <title>Minimal Configuration</title>

	  <para>
&lt;VirtualHost 10.0.0.1&gt;
ServerName "My virtual FTP server"
&lt;/VirtualHost&gt;
</para>

	  <para>You can add additional directive blocks into the
	  &lt;VirtualHost&gt; block in order to create anonymous/guest
	  logins and the like which are only available on the virtual
	  host.</para>
	</sect2>
      </sect1>

      <sect1>
	<title>Anonymous only servers</title>

	<para>Use a &lt;Limit LOGIN&gt; block to deny access at the
	top-level of the virtual host, then use &lt;Limit LOGIN&gt;
	again in your &lt;Anonymous&gt; block to allow access to the
	anonymous login. This permits logins to a virtual anonymous
	server, but denies to everything else. Example:
</para>

	<para>
&lt;VirtualHost 10.0.0.1&gt;
ServerName "My virtual FTP server"
&lt;Limit LOGIN&gt;
DenyAll
&lt;/Limit&gt;
&lt;Anonymous /usr/local/private&gt;
User private
Group private
&lt;Limit LOGIN&gt;
AllowAll
&lt;/Limit&gt;
...
&lt;/Anonymous&gt;
&lt;/VirtualHost&gt;
</para>
      </sect1>

<sect1>
<title>vhost notes</title>
<para>


I have tried to configure a name-based Virtual Host, but I always get to =
the Directory which I configured in the &lt;global&gt;-area.
My system: SuSE-Linux 6.3, ProFTP 1.2.0pre10. Yes, I've read the FAQ =
:-). All Hosts should have the same IP (212.172.160.148).
</para>

<informalexample>
<programlisting>
my proftpd.conf:
# START
ServerName "Webmasters FTP-Server"
ServerType inetd
ServerAdmin admin@webmasters.at

DeferWelcome on

Port                  21
Umask                002
TimeoutLogin         120
TimeoutIdle          600
TimeoutNoTransfer    900
TimeoutStalled      3600
User    ftp
Group    nogroup
#DefaultRoot   ~
UseReverseDNS        off
ScoreboardFile   /var/run/proftpd
TransferLog   /var/log/proftpd/xferlog.legacy
LogFormat       default "%h %l %u %t \"%r\" %s %b"
LogFormat auth    "%v [%P] %h %t \"%r\" %s"
LogFormat write   "%h %l %u %t \"%r\" %s %b"

&lt;Global&gt;
 DisplayLogin     /usr/local/ftp/msgs/welcome.msg
 #DisplayFirstChdir    readme
 MaxClients 30
 AllowOverwrite     yes
 IdentLookups         off
 ExtendedLog /var/log/proftpd/access.log WRITE,READ write
 ExtendedLog  /var/log/proftpd/auth.log AUTH auth
  #ExtendedLog    /var/log/proftpd/paranoid.log ALL default
&lt;/Global&gt;

&lt;VirtualHost www.joydisco.at&gt;
 ServerName  "www.joydisco.at"
 ServerAdmin  admin@joydisco.at
 #TransferLog  /var/log/proftpd/xferlog.www
 MaxClients  50
 #DefaultServer  on
 DefaultRoot  /www/www.joydisco.at
 AllowOverwrite  yes

&lt;/VirtualHost&gt;
# END
</programlisting>
</informalexample>

<para>


&gt; I have tried to configure a name-based Virtual Host, but I always get
&gt; to the Directory which I configured in the &lt;global&gt;-area.
&gt; All Hosts should have the same IP (212.172.160.148).
&gt; My system: SuSE-Linux 6.3, ProFTP 1.2.0pre10. Yes, I've read the FAQ

Including http://www.proftpd.org/docs/proftpdfaq-5.html#ss5.6 ?

I have tried to configure a Virtual Host, but I always get to the =
Directory which I configured in the &lt;global&gt;-area.
My system: SuSE-Linux 6.3, ProFTP 1.2.0pre10.

my proftpd.conf:
# START
ServerName "Webmasters FTP-Server"
ServerType inetd
ServerAdmin admin@webmasters.at

DeferWelcome on

Port                  21
Umask                002
TimeoutLogin         120
TimeoutIdle          600
TimeoutNoTransfer    900
TimeoutStalled      3600
User    ftp
Group    nogroup
#DefaultRoot   ~
UseReverseDNS        off
ScoreboardFile   /var/run/proftpd
TransferLog   /var/log/proftpd/xferlog.legacy
LogFormat       default "%h %l %u %t \"%r\" %s %b"
LogFormat auth    "%v [%P] %h %t \"%r\" %s"
LogFormat write   "%h %l %u %t \"%r\" %s %b"

&lt;Global&gt;
 DisplayLogin     /usr/local/ftp/msgs/welcome.msg
 #DisplayFirstChdir    readme
 MaxClients 30
 AllowOverwrite     yes
 IdentLookups         off
 ExtendedLog /var/log/proftpd/access.log WRITE,READ write
 ExtendedLog  /var/log/proftpd/auth.log AUTH auth
  #ExtendedLog    /var/log/proftpd/paranoid.log ALL default
&lt;/Global&gt;

&lt;VirtualHost 212.172.160.148&gt;
 ServerName  "www.joydisco.at"
 ServerAdmin  admin@joydisco.at
 #TransferLog  /var/log/proftpd/xferlog.www
 MaxClients  50
 #DefaultServer  on
 DefaultRoot  /www/www.joydisco.at
 AllowOverwrite  yes

&lt;/VirtualHost&gt;
# END

many thx for your help

Thomas, tom@goisern.net


Von: Falk Kuehnel [mailto:mailing-falk@salia.de]
Gesendet am: Freitag, 24. M=E4rz 2000 13:15
An: proftpd@proftpd.org
Betreff: [ProFTPD] Virtual FTP-Server

Hi There!

I was wondering if there is an way to set up severall VirtualFtpServers=20
with just one IP-Adress which can be connected to by anonymous users?
I know this is not possible just by referring to the name of the server,=20
but if i understood correctly, it can be done by using different ports. I=
s=20
there a howto, where the solution ist described?

Thanx for your help
Falk



I'm using proftpd on several of my servers and I like its flexibility
and security mechanisms. I'm running also a few virtualhosts (ip- and
port-ba= sed).  Now I would like to make a plan (or scheme) for adding
new virtualhosts s= erving access for directories containing WWW
services. Since particular users (i.e. website developers) should have
access only to their projects= and often one project is developed by
many of them, I want to make one (e.g. = port based) virtual host for
one project. Do you see any disadvantages of such= a solution? How
many port-based virtualhosts can proftpd (running on a linu= x system)
handle? Are there any limitations other than CPU speed and RAM
availability?


this is my first post to the list.

My question is:

- is possible to create accounts that are only valid for FTP access?(I 
don't want that the user have a UNIX account) . Send me an example please.

- IP restrict access doesn't works for me (I see an example in the 
documentation...but ...) so can someone send me his **proftpd.conf** where 
I can see that?



On the users side of things, you just need to set the users' shell to
/bin/false.

Easy Way:
In your proftpd.conf [or your virtual host line in there]
AuthUserFile            /config/ftp.passwd
AuthGroupFile           /config/ftp.group

Then copy the SAME FORMAT AS /etc/passwd and /etc/group

for example
user:&lt;hashed password&gt;:&lt;id&gt;:&lt;group&gt;::&lt;homedir&gt;:/bin/false
mark:x:980:100::/ftp/mark:/bin/false

x being an encrypted password

Enjoy!  Its a great feature- especially if you make a quick 10 line web
interface for the owner of vhosts to be able to change their own passwd
files.
--
Mike Krieger
phyre@home.com

On the users side of things, you just need to set the users' shell to
/bin/false.

- is possible to create accounts that are only valid for FTP access?(I
don't want that the user have a UNIX account) . Send me an example please.

- IP restrict access doesn't works for me (I see an example in the
documentation...but ...) so can someone send me his **proftpd.conf** where
I can see that?



Can I make a VirtualHost write to a separate wtmp file?  I 
already have it writing to a separate xferlog but I'd like to write 
to a separate wtmp if possible.  I'd like an easy way of seeing if 
someone is connected to a given VirtualHost.  I guess I could compare 
the users that are still on (via ftpwho) to the output of netstat to 
see who connected to where.  That's not very elegant though.  Ideas?

Another question, with DisplayGoAway, will it display the 
file to the user if they aren't allowed to connect in general, via a 
Limit block?  The docs don't really say.  They just say that it "will 
be displayed to the user if the class they're a member of has too 
many users logged in".  It doesn't say if it will do that for all 
denied requests.  In my case, I'm limiting this VirtualHost to 
certain IP ranges.  I am limiting it to 75 anonymous users on that 
virtualhost but I don't care about displaying the file then, just 
when the user is connecting from and IP that isn't authorized.   Any 
ideas if it will work or if there's a better way or if I'm just SOL?
	I had a 3rd question but I forgot it so it must not be important.

Does proftpd support virtual directories (not necessarily virtual
servers).

Here's my situation, I wish to provide a group of users with access to a
common directory (Group A), and another group of users with access to
another common directory (Group B).  Group A must not have access to
Group B's files.

Using AuthUserFile and AuthGroupFile to establish separate
authentication.

My hunch would be using multiple DefaultRoot entries.  Something like:

&lt;Global&gt;
    ...
    DefaultRoot /var/ftp/data/group-a groupa,!staff
    DefaultRoot /var/ftp/data/group-b groupb,!staff
    ...
&lt;/Global&gt;

Would the above even be parseable or work?

Read the FAQ and docs, but examples didn't quite apply.

If anyone has any suggestions I'd appreciate it.

--
George M. Ellenburg
S1 Corp.




That's hard to say.  For security purposes, I'm faking the user/group 
in my anonymous block.

   DirFakeUser                     on      Willie
   DirFakeGroup                    on      Wildcat

I'm not using seperate Auth files either.  From the way that the 
AuthGroup config directives are worded, it would appear that all 
authentication is done via the the AuthUser/Group files (unless they 
aren't defined) but to make HideGroup/User work the files must be 
group or owned by the appropriate user on the actual system.  I'm 
sure if there is a way around that.  Just for the hell of it, chgrp 
70 groupa's directory.  Make sure 70 doesn't conflict with something 
else on your system.  Maybe it does work.


I've hidden a directory from users before.  To see that directory you 
had to belong to a certain group.

   &lt;Directory private&gt;
     HideGroup crack
   &lt;/Directory&gt;

   &lt;Directory pub/consult/&gt;
     HideGroup consult
   &lt;/Directory&gt;


I use both and they work well.  I believe the file(s) have to be 
grouped and writable by the respect group.  There are also other 
things you can do to keep the Group A from getting an "permission 
denied" error (even though the can't see the directory) when trying 
to cd into Group B directory.

This is the situation:

I have a &lt;virtualhost&gt; that allows anonymous logins, users can log in and
upload files, but not download them.

I need to give ONE user all permissions to the same virtualhost.

What should my proftpd.conf look like? :)




&lt;VirtualHost xxx.xxx.xxx.xxx&gt;
        DefaultRoot /usr/local/httpd/htdocs/
        ServerName "xxx mainserver"
        ExtendedLog          /var/log/proftpd.paranoid_log  ALL default
        &lt;Limit STOR&gt;
                AllowAll
        &lt;/Limit&gt;
        &lt;Directory /&gt;
          AllowOverwrite                on
          &lt;Limit STOR CWD CDUP&gt;
            AllowAll
          &lt;/Limit&gt;
       &lt;/Directory&gt;
&lt;/VirtualHost&gt;

why am i not allowed to write in any directory ??? when connecting this
server ??




Hi,

Oh. I just found the FAQ and it seems to answer the question. 

However the liink to the "draft standard" has gone stale:
"File Not Found
The requested URL /internet-drafts/draft-ietf-ftpext-mlst-08.txt was not
found on this server."

</para>
</sect1>

      <sect1>
	<title>DNS issues</title>

	<sect2>
	  <title>Hosting VirtualHosts on a single IP</title>

	  <para>This is not possible to do in the same way as it is
	  with Apache / http, this is not a failing of ProFTPD but
	  rather a problem with the basic ftp protocol which as no
	  method of uniquely identifying the target host during a
	  session. The only work around at this time is to use a
	  different primary port for each virtual if more than one per
	  IP is required.
	  </para>
	</sect2>

	<sect2>
	  <title>DNS entry not resolving</title>

	  <para>If the &lt;VirtualHost&gt; block is built using names
	    rather than IP's there[A is a chance that a configuration
	    reload will cause the server to die.  Proftpd treats DNS
	    resolution as a fatal error "Fatal: unable to determine IP
	    address of `www.blah.com'".  The best solutions to this
	    problem are either to use raw IP addresses in the config
	    thus removing all the resolution problems or to use the -t
	    option to check the config prior to reloading.</para>
	</sect2>
      </sect1>

      <sect1>
	<title>Reloading the config</title>

	<para>Two basic methods, stop and restart the server, or send
	a SIGHUP to the master proftpd lister.  The scripts which come
	with both the normal distribution and the various packaged
	versions will do both.  There is a minor bug in the SIGHUP
	handling which has not yet been found and dealt with.  When
	reloading servers with many virtual hosts about 30% of the
	time the reload will fail in some way taking out the entire
	daemon.</para> 

	<sect2>
	  <title>Non resolving names</title>

	  <para>problem with non-existant names killing the
	  daemon</para>

	  <para>Part of being a decent system administrator is solving
	  the problem -- at the core. Apache lets you "pretend the
	  problem doesn't exist" (yes, it spits out crap to stdout on
	  runtime, but that doesn't necessarily mean you're going to
	  be there to see it), allowing people to slack off and avoid
	  doing their job in it's entirety.  I care about the
	  technicalities, as well as the principle behind the above
	  situation. If my webserver (or FTP server) "skips" a host,
	  it's more than likely going to cause a cust- omer or client
	  to throw a fit.</para>

	  <sect3>
	    <title>DNS</title>
	    <para></para>

	    <para>It isn't absurd when you are running for than a few
	    virtual hosts. Software isn't supposed to die at the first
	    sign of trouble. If you had a few hundred virtual hosts,
	    you wouldn't want apache to completely die because one of
	    them wouldn't resolve, or wasn't aliased, etc.</para>

	  </sect3>

	  <sect3>
	    <title>UID/GID</title>
	    <para></para>
	  </sect3>

	</sect2>

	<sect2>
	  <title>many vhost entries death</title>
	  <para></para>
	</sect2>

	<sect2>
	  <title>What happens to connected users?</title>

	<para>Wait...does it not make sense that you shouldn't have
	users logged in when you refresh the daemon?I'm no expert, but
	I've never seen something that will allow you to bind an
	application to a port that's already in use.  It doesn't make
	sense to be able to do that.  If you in effect kill the
	proftpd daemon and restart it...and orphan it's children, when
	it restarts it will attempt to bind to IPs and Ports.  If a
	child process is still running on one of those IPs or Ports,
	how should proftpd handle it?  Kill the process holding the
	port and then start?  If it can't bind to the port or IP, I
	don't see how it will be able to recover.</para>

	<para>Since no one else is responding to my message, I'm
	writing my own follow-up.  The problem is worse than I
	thought: if you send a HUP to the master process (again, in
	standalone mode) to get it to recognize configuration changes,
	and someone is connected to one of the VirtualHosts, the whole
	process fails because it can't bind to that address. This is
	another case that I don't think should cause the entire server
	to fail. Am I the only one having these problems? Is anyone
	else running standalone? Thanks for any feedback.</para>

	  <para>I don't like the idea of kicking off all our connected
	  users just to add a VirtualHost, and less, having all the
	  servers die if it can't bind to 1 of 60 addresses. I
	  understand that it can't bind to a port that is in use, but
	  the bound process could understand that the configuration
	  has changed and NOT stop/restart; I thought that was part of
	  the benefit of sending a HUP rather than killing the whole
	  thing and restarting (sort of like rebooting Windows for
	  every little change you make)...</para>

	  <para>I just connected to one of the Virtual Hosts (running
	  close to 200) on my FTP server (running ProFTPD in
	  standalone) then HUP'd it while still connected which did
	  not cause any fatal errors for me.  It didn't cause my
	  connection to drop either.  HUP should only cause the
	  process to reread the config not stop and restart as far as
	  I know.  So there is no logical reason why a HUP doesn't
	  work, unless you attempt to use a domain name/IP that is not
	  yet aliased to the NIC on that system.  DNS shouldn't have
	  anything to do with it as long as the IP/domain is aliased
	  to the NIC, usually with ifconfig.  But hey, I could be
	  wrong, it has happened before :)</para>


	</sect2>
      </sect1>
    </chapter>

    <chapter id="auth">
      <title>Authentication</title>

      <para>One of the core functions of every ftp is how it
      authenticates it's local users and assigns them the access
      rights to the ftp filesystem.  At the moment Proftpd only
      supports the standard plaintext USER/PASS authentication
      interface, there is work underway to support crypted passwords,
      this will probably surface in the 1.3.x development series and
      the 1.4.x stable codebase which results from it.</para>

      <para>Providing the backend to the user authentication interface
      there re a host of methods for storing user information and
      querying these databases of users for valid authentication
      sequences.  The standard in ProFTPD is the Pluggable
      Authentication Modules system, or PAM.  Support is also provided
      for the classic /etc/passwd and /etc/shadow password files as
      well as more "interesting" solutions such as SQL and
      LDAP.</para>

      <sect1>
	<title>Password files</title>

	<para>Three variants on the password file theme are supported
	by the core Proftpd authentication code, these are
	/etc/passwd, /etc/shadow and uderdefined files by using the
	AuthUserFile and AuthGroupFile directives.</para>

	<para>Support for passwd and shadow files is simple and well
	documented and conforms to the accepted standards and methods
	for handling these authentication sources.  It should be noted
	that Proftpd unless told otherwise, by using
	"PersistantPassword off" directive, will attempt to open and
	leave open the passwd file throughout the life of the server
	process.

/etc/passwd
/etc/shadow

AuthUserFile
crypt, code fragment for generating cryoted passwords

NIS

ld.so.preload magic...
	</para>
      </sect1>

      <sect1>
	<title>Pluggable Authentication Modules (PAM)</title>

	<para>PAM has become a standard method of providing secure
	authentication services within the UNIX environment in the
	past few years.  PAM acts as the interface between the program
	or system daemon and the underlying authentication methods.
	It's great strengths are the higher levels of security it
	affords to the system administrator and it's flexability.  As
	the name suggests the coding interface is common for all PAM
	supported methods, however behind the scenes many different
	methods of authentication can be supported.  Even to the
	extent of (for example) supporting RADIUS for ftp access and
	/etc/shadow for telnet.</para>

	<para>ProFTPD requires PAM version 0.59 or better.  The
	pam_sm_open_session system call is not provided in earlier
	versions and is a requirement of the PAM implementation within
	Proftpd.</para>

	<sect2>
	  <title>Why is PAM the default authentication system?</title>

	  <para>Security, pure and simple.  PAM is the most secure (or
	  securable) of the available authentication systems.  Many of
	  the issues and configuration hints for PAM are contained in
	  README.PAM which is bundled with the server source and in
	  the various packaged builds.  To use /etc/passwd manual
	  compilation will be required with the configure script being
	  run with the --without-pam flag.  Unless the PAM subsystem
	  is properly configured authentication will fail.</para>
	</sect2>

	<sect2>
	  <title>AuthPAMAuthoritive</title>

	  <para>AuthPAMAuthorative defaults to "off"" allowing other
	  authentication methods to get a look in at authentication
	  time.  Setting this to "on" will break support for external
	  files such as AuthUserFile.</para>
	</sect2>

	<sect2>
	  <title>Preloading</title>

	  <para>If these don't fit in with your system then writing a
	  custom module or using such as the 'ld.so.preload' approach
	  to intercept getpwbynam() system calls works happily with
	  ProFTPD.</para>
	</sect2>

	<sect2>
	  <title>Typical PAM configuration</title>

	  <para>Proftpd itself should need little or no configuration
	  to support PAM, however some configuration of the PAM
	  subsystem may be required.  One of the most common problems
	  encountered when configuring and using Proftpd is a missing
	  /etc/pam.d/ftp file, if this file isn't installed the
	  authentication requests will fail.</para>

	  <para>There is a README.Pam in the top directory of the
	  ProFTPD install directory :</para>

	  <sect3>
	    <title>Linux</title>

	    <para>Most of the development of Proftpd is done on Redhat
	    based systems, however this should not prevent users of
	    other distributions running the daemon without
	    problems.</para>

	    <example>
	      <title>Generic Linux PAM config</title>
	      <programlisting>
#%PAM-1.0
auth       required     /lib/security/pam_listfile.so item=user
sense=deny file=/etc/ftpusers onerr=succeed
auth       required     /lib/security/pam_pwdb.so shadow nullok
account    required     /lib/security/pam_pwdb.so
session    required     /lib/security/pam_pwdb.so
</programlisting>
	    </example>

	    <sect4>
	      <title>Redhat Linux</title>
	      <example>
		<title>Redhat 6.* configuration</title>
		<programlisting>
#%PAM-1.0
auth       required     /lib/security/pam_listfile.so item=user
sense=deny file=/etc/ftpusers onerr=succeed
auth       required     /lib/security/pam_pwdb.so shadow nullok
account    required     /lib/security/pam_pwdb.so
session    required     /lib/security/pam_pwdb.so
</programlisting>
	      </example>
	    </sect4>

	    <sect4>
	      <title>SuSE</title>

	      <para>SuSE appears to uses pam_unix rather than pam_pwdb
	      which is the Redhat approach.  All references to
	      pam_pwdb should be replaced with "pam_unix" on SuSE
	      systems.</para>

	      <example>
		<title>SuSe configuration</title>
<programlisting>
/etc/pam.d/ftpd
#%PAM-1.0

# Uncomment this to achieve what used to be ftpd -A.
# auth       required     /lib/security/pam_listfile.so item=user sense=allow file=/etc/ftpchroot onerr=fail

auth     required       /lib/security/pam_listfile.so item=user
sense=deny file=/etc/ftpusers onerr=succeed
auth     sufficient     /lib/security/pam_ftp.so
auth     required       /lib/security/pam_unix.so
auth     required       /lib/security/pam_shells.so
account  required       /lib/security/pam_unix.so
password required       /lib/security/pam_unix.so
session  required       /lib/security/pam_unix.so
</programlisting>
	      </example>
	    </sect4>
	  </sect3>

	  <sect3>
	    <title>FreeBSD</title>

	    <para>FreeBSD does not support PAM session directives. If
	    you remove the following line from the FreeBSD section of
	    README.PAM, PAM should work properly under recent versions
	    of FreeBSD.</para>

	    <example>
	      <title>FreeBSD configuration</title>
<programlisting>
ftp session required    pam_unix.so         try_first_pass
</programlisting>
</example>
	  </sect3>
	</sect2>

	<sect2>
	  <title>pam_sm_open_session errors</title>

	  <para>ProFTPD requires PAM version 0.59 or better.
	  pam_sm_open_session is not part of previous versions.</para>
	</sect2>

	<sect2>
	  <title>Conficts with PAM authentication</title>

	  <para>Generally these problems will be cured by either
	  disabling PAM completely or by ensuring that these
	  directives are set</para>

	  <informalexample>
	    <programlisting>
PersistentPasswd   off
AuthPAMAuthorative off
</programlisting>
	    </informalexample>
	</sect2>
      </sect1>

      <sect1>
	<title>SQL</title>

<epigraph>
<para>You are in a maze of twisty SQL statements, none alike.</para>
</epigraph>

<para>This section has been removed completely and needs a complete
re-write to account for the new approach to SQL handling as of
1.2.0</para>
</sect1>


      <sect1>
	<title>UserPassword</title>

	<para>I've been waiting patiently and trying new versions
	(right now, I have 1.2.0pre7-3 from debian potato), but
	UserAlias in anonymous ftp now forces me to use the password
	of the user I alias to, and not the user I log in as.
	</para>

	<example>
	  <title>...</title>
	  <programlisting>
&lt;Anonymous ~ftp/sub/dir/&gt;
  AnonRequirePassword on
  RequireValidShell off
  User ftp
  Group nobody

#  UserPassword ftp encpasswd
  UserPassword ftpuser1 encpasswd1
  UserPassword ftpuser2 encpasswd2
  (...)

  UserAlias ftpuser1 ftp
  UserAlias ftpuser2 ftp
  (...)
&lt;/Anonymous&gt;
</programlisting>
</example>

	<para>So, I used to be able to log as ftpuser1 and use
	  ftpuser1's password with older versions of proftpd.  Now I'm
	  forced to uncomment the "UserPassword ftp encpasswd" line
	  and everyone would have to log with ftp's password.

I really do not want to go back to wuftpd (with which I got this to work
jusr fine).
1) Can this still be made to work somehow?
2) If not, how do I provide anonymous ftp access to a select number of
   users, each with their own password?
   (I'd rather not have to put users in /etc/passwd and /etc/group)
	</para>
      </sect1>

      <sect1>
	<title>Lightweight Directory Access Protocol (LDAP)</title>

	<para>Lightweight Directory Access Protocol (LDAP)
	  authentication from within Proftpd is provided via the
	  mod_ldap module, which is not compiled in by default.  For
	  information on compiling in additional modules go back and
	  read the chapter on installing Proftpd.</para>

	<para>As of version 1.2 most of the annoying bugs have been
	  removed and the code is of suitable quality to provide a
	  stable authentication backend.  The module became part of
	  the distribution as of version 1.1.</para>

	<sect2>
	  <title>What is LDAP</title>

	  <para>LDAP is a distributed, hierarchical directory service
	  access protocol which is used to access repositories of
	  users and other network- related entities. Because LDAP is
	  often not tightly integrated with the host operating system,
	  information such as users may need to be kept both in LDAP
	  and in an operating system supported nameservice such as
	  NIS. By using LDAP as the the primary means of resolving
	  these entities, these redundancy issues are minimized and
	  the scalability of LDAP can be exploited. (By comparison,
	  NIS services based on flat files do not have the scalability
	  or extensibility of LDAP or X.500.)</para>

	  <para>The object classes and attributes defined below are
	  suitable for representing the aforementioned entities in a
	  form compatible with LDAP and X.500 directory
	  services.</para>

<example>
<title>A typical configuration fragment</title>
<programlisting>
LDAPServer                      "localhost"
LDAPPrefix                      "dc=horde,dc=net"
LDAPDN                          "cn=thedn,dc=horde,dc=net"
LDAPDNPass                      "ldap_dnpass"
LDAPNegativeCache       on
	    </programlisting>
	  </example>
	</sect2>

	<sect2>
	  <title>Ldap notes</title>

	  <para>I try to compile Proftpd 1.2.0pre9 with the ldap
	    support.  According to info on the homepage of the ldap
	    module, the mod_ldap.c is in the /modules directory and I
	    run configure with the --with-modules=mod_ldap but make
	    always complains about missing lber.h and ldap.h (which
	    are found in the OpenLDAP package).

	    Does that means that I have to compile (or copy some files
	    from?) OpenLDAP on the computer?  My aim is to use a
	    remote LDAP server, not a locally installed one (and I
	    don't want, if possible, to install a LDAP server on this
	    machine).  How can I do?

	    Sorry if my question seems a bit simple to the "gurus"!
	    :-)</para>

	  <para> mon avis you don't need to install a full ldap server
	    on your system,= but you need to have a set of ldap
	    library (openldap, netscape...) and the corres= ponding
	    include headers. I recommend you to install the openldap
	    and build the li= braries only.</para>

<para>
That's correct. For OpenLDAP, you can build the client header files,
libraries, and utilities _only_ by saying:

./configure --disable-slapd --disable-slurpd

when you build OpenLDAP.



=C0 mon avis you don't need to install a full ldap server on your
system,= but you need to have a set of ldap library (openldap,
netscape...) and the corres= ponding include headers. I recommend you
to install the openldap and build the li= braries only.

</para>

<para>
I try to compile Proftpd 1.2.0pre9 with the ldap support.  According to info
on the homepage of the ldap module, the mod_ldap.c is in the /modules
directory and I run configure with the --with-modules=mod_ldap but make
always complains about missing lber.h and ldap.h (which are found in the
OpenLDAP package).

Does that means that I have to compile (or copy some files from?) OpenLDAP
on the computer?  My aim is to use a remote LDAP server, not a locally
installed one (and I don't want, if possible, to install a LDAP server on
this machine).  How can I do?

Sorry if my question seems a bit simple to the "gurus"! :-)


I've a proftpd authenticating users against a ldap server.
The users are not unix users, then I can't use the normal quotta system.

Does have proftpd an internal system to limit the size of a directory??

How can I control the size of each user directory??

thanks,
</para>

<para>

On Wed, Jan 12, 2000 at 11:05:15AM +0100, Juli=E1n Romero wrote:
&gt; I've a proftpd authenticating users against a ldap server.
&gt; The users are not unix users, then I can't use the normal quotta system.

Hmmmm - considering that I've not dealt with the mod_ldap stuff this
may well be a silly question. Does each of your users have a unique
UID on the system ? Or are you using DefaultRoot and a single UID for
all users ?

If you've got a unique UID for each user then you *can* still use the
quota system as it actually uses UIDs for the work - the user name to
UID map is performed by the quota commands. That said, the quota
commands often accept UIDs in the place of usernames.

It has to be said that the standard quota stuff (at least under
Solaris) is painful to use in automatic systems - its often easier to
dig into the quota system and code your own programs to control the
quota system than use the system provided ones.
</para>

<para>
    Thanks to Jim, i succeeded in linking mod-ldap with LDAP-C SDK librai=
ries
(-lpthread -lldapssl30 is a good way)...

    But now, when I try to run proftpd, I get an error message which says=
:
            - Fatal: Group: Unknown group 'nogroup'.

    ...I tried to add "ftp-master", "nobody", "nogroup" entries to my LDA=
P
server...but nothing changes!

    Thanx for any help...Peter, could you send me part of your proftpd.co=
nf, or
ldif entries you had to add on your LDAP server?
</para>

<para>
here's my proftpd.conf (very basic one, i thought...)
-------------------
# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

ServerName                      "Serveur test"
ServerType      standalone
DefaultServer                   on

#PAMConfig                       ftp
#AuthPAMAuthoritative            off

LDAPServer            test.rouen.men.fr
LDAPDNInfo            xxxxxxxxxxxxxxx
LDAPDoAuth            on "ou=3D..."
LDAPDoUIDLookups      off
LDAPDoGIDLookups      off
LDAPNegativeCache     on
Port                            21
Umask                           022
MaxInstances                    30
User                            nobody
Group                           nobody
&lt;Directory /*&gt;
  AllowOverwrite                on
&lt;/Directory&gt;
&lt;Anonymous ~&gt;
  User                          ftp
  Group                         ftp
  UserAlias                     anonymous ftp
  MaxClients                    10
  DisplayLogin                  welcome.msg
  DisplayFirstChdir             .message
        &lt;Directory *&gt;
                &lt;Limit WRITE&gt;
                        DenyAll
                &lt;/Limit&gt;
        &lt;/Directory&gt;
        &lt;Directory incoming&gt;
                &lt;Limit READ WRITE&gt;
                        DenyAll
                &lt;/Limit&gt;
                &lt;Limit STOR&gt;
                        AllowAll
                &lt;/Limit&gt;
        &lt;/Directory&gt;
&lt;/Anonymous&gt;
---------------------


% %     Thanks to Jim, i succeeded in linking mod-ldap with LDAP-C SDK librairies
% (-lpthread -lldapssl30 is a good way)...
% 
%     But now, when I try to run proftpd, I get an error message which says:
%             - Fatal: Group: Unknown group 'nogroup'.
% 
%     ...I tried to add "ftp-master", "nobody", "nogroup" entries to my LDAP
% server...but nothing changes!
%
% LDAPServer            test.rouen.men.fr
% LDAPDNInfo            xxxxxxxxxxxxxxx
% LDAPDoAuth            on "ou=..."
% LDAPDoUIDLookups      off
% LDAPDoGIDLookups      off
% LDAPNegativeCache     on

In theory, you can have the users referenced in your proftpd.conf User/Group
config directives in the LDAP database. I really haven't done any testing
with a situation like that, though, but it *should* work. I usually have
my User/Group users listed in /etc/passwd and /etc/group and just use the
LDAP directory for user authentication. If you choose to reference LDAP-only
users/groups in your User/Group config directives, you'll need to set both
LDAPDoAuth and LDAPDoGIDLookups to on.

</para>

<para>
I am trying to build mod_ldap module (2.5.2) with proftpd on Solaris
2.6.  I use Netscape DirectoryServer API libldapssl30.so.  When I do
make with the package it says one error: cannot find "llber" library.
I remember if use Netscape directory server API 3.0, we need not llber
library. Where to get llber (which looks for openldap on linux)?

Does any one succeed to use proftpd authenticate with 
ldap on Solaris ? DO you get the same 
compiling problem?  

When I do ./configure --with module=mdo_ldap, for some system 
check the answer is no, does that matter?
</para>

<para>I have a problem in running Proftpd from command line. I
configure it as default run by "inet" NOT standalone.  I add few
entries in proftpd.conf but when I run it, error message say Fatal:
unknown configuration directive 'LDAPDNInfo', any first directive
start with 'LDAP' get the same error.  I searched the source code no
place read in "proftpd.conf" file , what is wrong with my mod_ldap
module?

Please drop me few lines if you have any idea where this config 
file is read in and how it proftpd talk to Unix Solaris nation 
unix.pam.so 1 module  and pam talk to mod_ldap?  Atcuallt where is
the mod_ldap lib installed?

In other email group, I succeeded allow wu_ftp to talk to standard 
pam_ldap and nss_ldap module for ftp user to authenticate with a remote 
LDAP server. I know here Proftp has its native LDAP support.  
Can anyone help me describe the code architecture?  
I am new to proftp.
</para>

<para>
A quick question is that, you user login as uid and pass then search on the
proconfigured base in mod_ldap.conf file which is static. But uid may not
unique in a whole LDAP server, for example a ISP company providing service
for many domains. The search base is root.
 
How you avoid this problem? 

OR, if use login as 

                         uid@domain.com

can you parse it into "uid" and "domain.com" then do the ldap search with dn
in mod_ldap.conf plus "domian.com" as new search base?

OR your ProFTP can prompt user for a "domain" in addition to "user:"
"password"? 

Which way is easier to deal with this problem?
</para>

<para>
I have problems with authentication when using mod_ldap. I'm using Solaris2.6,
Netscape Directory Server, 1.2.0pre10 and mod_ldap-2.5.2. ProFTPD is running
standalone.

When trying to login I get:
----------
220 ProFTPD 1.2.0pre10 Server (ProFTPD) [hostname]
Name (IP-address:user): profuser
421 Service not available, remote server has closed connection
Login failed.
----------

The "profuser" is registered in the NDS and has the objectclass posixaccount. In the
errorlog of the NDS it looks like bind is ok but what happens after that???

errorlog:
-----------
[28/Feb/2000:15:28:28 +0100] - new connection on 44
[28/Feb/2000:15:28:28 +0100] - listening for connections on 0
[28/Feb/2000:15:28:28 +0100] - activity on 44r
[28/Feb/2000:15:28:28 +0100] - read activity on 44
[28/Feb/2000:15:28:28 +0100] - add_pb 
[28/Feb/2000:15:28:28 +0100] - listening for connections on 0
[28/Feb/2000:15:28:28 +0100] - get_pb 
[28/Feb/2000:15:28:28 +0100] - do_bind
[28/Feb/2000:15:28:28 +0100] - BIND dn="cn=Directory Manager" method=128 version=2
[28/Feb/2000:15:28:28 +0100] - =&gt; get_ldapmessage_controls
[28/Feb/2000:15:28:28 +0100] - &lt;= get_ldapmessage_controls no controls
[28/Feb/2000:15:28:28 +0100] - do_bind: version 2 method 0x80 dn cn=Directory Manager
[28/Feb/2000:15:28:28 +0100] - =&gt; slapi_pw_find value: "password"
[28/Feb/2000:15:28:28 +0100] - &lt;= slapi_pw_find matched "password" using scheme "clear"
[28/Feb/2000:15:28:28 +0100] - =&gt; send_ldap_result 0::
[28/Feb/2000:15:28:28 +0100] - flush_ber() wrote 14 bytes to socket 44
[28/Feb/2000:15:28:28 +0100] - &lt;= send_ldap_result
[28/Feb/2000:15:28:28 +0100] - listener got signaled
[28/Feb/2000:15:28:28 +0100] - listening for connections on 0
[28/Feb/2000:15:28:28 +0100] - activity on 44r
[28/Feb/2000:15:28:28 +0100] - read activity on 44
[28/Feb/2000:15:28:28 +0100] - add_pb 
[28/Feb/2000:15:28:28 +0100] - listening for connections on 0
[28/Feb/2000:15:28:28 +0100] - get_pb 
[28/Feb/2000:15:28:28 +0100] - PR_Recv(2588624) 0 (EOF)
[28/Feb/2000:15:28:28 +0100] - listener got signaled
-----------


In proftpd.conf I have these values:
-----------
LDAPServer                      localhost
LDAPDNInfo                     "cn=Directory Manager" password
LDAPDoAuth                    on "ou=users,ou=customers,o=organization"
LDAPDoUIDLookups         off
LDAPDoGIDLookups         off
LDAPNegativeCache         on
LDAPHomedirOnDemand  off
LDAPDefaultAuthScheme clear
----------

Is there anyone who knows what happens here after the Bind???
I added the "allowedservices" attribute but it makes no difference.
How is it used? Have you edited mod_ldap.c? Did you do something
else to get it going?
</para>

<para>
----------------------------------
&gt; What attribute is "allowedservices"? I don't have that attribute
&gt; in my Directory Server. Is it a standard attribute or something
&gt; you've created?
&gt;

Something I added in each LDAP user definition


Same problem I got.

Verify that your user as the following attributes (LDAP definition):
userpassword
homedirectory
allowedservices (set it to FTP)

It's the minimum requirements.



Joakim Br=E5n=E4s (QRA) wrote:

&gt; What attribute is "allowedservices"? I don't have that attribute
&gt; in my Directory Server. Is it a standard attribute or something
&gt; you've created?
&gt;

Something I added in each LDAP user definition

--
Laurent PIERRE
T=E9l:01 47 33 82 84 Fax:01 47 33 76 98
E-mail: laurent.pierre@alcove.fr
** Alc=F4ve lib=E8re votre informatique... Web: http://www.alcove.fr **

</para>

<para>Just a wild guess - what about escapeing the whitespace ?  like :

LDAPDNInfo    cn=3DDirectory\ Manager,dc=3Ddatelec,dc=3Dcom [      ]

&gt; % I guess this new release had correctly fixed the solaris bugs.
&gt; %
&gt; % I can connect to proftpd without this "signal 11" error. Nice job !
&gt;
&gt; Good, I'm glad to hear it.
&gt;
&gt; % But I have now another issue :
&gt; %
&gt; % My cn for my Netscape Directory server is : Directory Manager
&gt; %
&gt; % So my proftpd.conf file seems like :
&gt; %
&gt; % &gt; LDAPServer       ldap_shagga
&gt; % &gt; LDAPDNinfo       cn="Directory Manager",dc=datelec,dc=com [     ]
&gt; [misc. snippage]
&gt; % But I guess your module doesn't parse correctly the cn field cause in my
ldap
&gt; % server logs I get this error :
&gt; %
&gt; % &gt; [16/Feb/2000:12:47:20 +0100] conn=7371 op=0 BIND dn="cn="Directory"
method=128 version=2
&gt;
&gt; Config-file parsing is taken care of by proftpd;

oops ... sorry :)

&gt; it basically splits config
&gt; file parameters on whitespace. I think that the quotes in the middle of the
&gt; paramter are confusing it. What happens if you try:
&gt;
&gt; LDAPDNInfo    "cn=Directory Manager,dc=datelec,dc=com" [      ]

I've tried : same error...
So I've to change the name of my Cn......  Exact ?
</para>

	  <para>I guess this new release had correctly fixed the
	  solaris bugs.  I can connect to proftpd without this "signal
	  11" error. Nice job ! But I have now another issue : My cn
	  for my Netscape Directory server is : Directory Manager

So my proftpd.conf file seems like :


&gt; LDAPServer                      ldap_shagga
&gt; LDAPDNinfo                      cn="Directory Manager",dc=datelec,dc=com micr0sc0n
&gt; LDAPDoAuth                      on "dc=People,dc=datelec,dc=com"
&gt; LDAPDoUIDLookups      off
&gt; LDAPDoGIDLookups      off
&gt;

But I guess your module doesn't parse correctly the cn field cause in my ldap
server logs I get this error :

&gt; [16/Feb/2000:12:47:20 +0100] conn=7371 fd=164 slot=164 connection from 192.168.120.164 to 192.168.120.160
&gt; [16/Feb/2000:12:47:20 +0100] conn=7371 op=0 BIND dn="cn="Directory" method=128 version=2
&gt; [16/Feb/2000:12:47:20 +0100] conn=7371 op=0 RESULT err=32 tag=97 nentries=0 etime=0
&gt; [16/Feb/2000:12:47:20 +0100] conn=7371 op=-1 fd=164 closed - B1
&gt;

Normally that should be (like a good connection):


&gt; [16/Feb/2000:12:47:59 +0100] conn=7372 fd=164 slot=164 connection from 192.168.120.165 to 192.168.120.160
&gt; [16/Feb/2000:12:47:59 +0100] conn=7372 op=0 BIND dn="cn=Directory Manager" method=128 version=2
&gt; [16/Feb/2000:12:47:59 +0100] conn=7372 op=0 RESULT err=0 tag=97 nentries=0 etime=0
&gt;
</para>

<para>
&gt; I released mod_ldap v2.5.1 on Saturday. It adds support for authenticated
&gt; binds and also fixes all known bugs up until this point in time (most
&gt; notably the mod_ldap-segfaults-under-solaris bug). Authenticated binds
&gt; allows mod_ldap to support any password encryption scheme that your LDAP
&gt; server supports; it will bind to your LDAP server with the credentials
&gt; listed by LDAPDNInfo and fetch all user information except for userPassword.
&gt; It will then re-bind to the LDAP server as the FTP user who is attempting
&gt; to log in with the user-supplied password. If the bind succeeds, the user
&gt; is allowed access. http://horde.net/~jwm/software/mod_ldap/
&gt;
&gt; I know that a bunch of people on the list are using mod_ldap, so I figured
&gt; it would be of enough interest to post here. If there's a more appropriate
&gt; place for this (or you'd rather I didn't announce new versions here), please
&gt; let me know.
</para>

<para>
% I guess this new release had correctly fixed the solaris bugs.
% 
% I can connect to proftpd without this "signal 11" error. Nice job !

Good, I'm glad to hear it.

% But I have now another issue :
% 
% My cn for my Netscape Directory server is : Directory Manager
% 
% So my proftpd.conf file seems like :
% 
% &gt; LDAPServer       ldap_shagga
% &gt; LDAPDNinfo       cn="Directory Manager",dc=datelec,dc=com [     ]
[misc. snippage]
% But I guess your module doesn't parse correctly the cn field cause in my ldap
% server logs I get this error :
% 
% &gt; [16/Feb/2000:12:47:20 +0100] conn=7371 op=0 BIND dn="cn="Directory" method=128 version=2

Config-file parsing is taken care of by proftpd; it basically splits config
file parameters on whitespace. I think that the quotes in the middle of the
paramter are confusing it. What happens if you try:

LDAPDNInfo    "cn=Directory Manager,dc=datelec,dc=com" [      ]

</para>
<para>

I'm trying to use proftpd with the ldap module (v2.0).

I've made a beautiful compilation of proftpd with some others modules
(the problem is the same without quota and ratio)



&gt; shagga (root) /tmp/proftpd-1.2.0pre10 &gt; ./proftpd -l
&gt; Compiled-in modules:
&gt;   mod_core.c
&gt;   mod_auth.c
&gt;   mod_xfer.c
&gt;   mod_site.c
&gt;   mod_ls.c
&gt;   mod_unixpw.c
&gt;   mod_log.c
&gt;   mod_pam.c
&gt;   mod_ratio.c
&gt;   mod_ldap.c
&gt;

My configuration file is something like that :


&gt; ServerName                      "Internal FTP Server"
&gt; ServerType                      StandAlone
&gt; DefaultServer                   on
&gt; Port                            21
&gt;
&gt; User                            nobody
&gt; Group                           nogroup
&gt;
&gt; MaxInstances                    30
&gt;
&gt; TimeoutStalled                  300
&gt;
&gt; DisplayLogin                    welcome.msg
&gt; DisplayFirstChdir               .message
&gt;
&gt; RootLogin                       on
&gt;
&gt; AuthPAMAuthoritative            off
&gt;
&gt; LDAPServer                      ldap_shagga
&gt; LDAPDNinfo                      cn=admin,dc=datelec,dc=com password
&gt; LDAPDoAuth                      on "dc=People,dc=datelec,dc=com"
&gt; LDAPDoUIDLookups                off
&gt; LDAPDoGIDLookups                off
&gt;

When I start proftpd ( proftpd -d 5 -n ) and i try to connect to the server, I get this message :


&gt; shagga - ProFTPD 1.2.0pre10 standalone mode STARTUP
&gt; shagga (snardone.datelec.ch[192.168.120.165]) - connected - local  : 192.168.120.164:21
&gt; shagga (snardone.datelec.ch[192.168.120.165]) - connected - remote : 192.168.120.165:3451
&gt; shagga (snardone.datelec.ch[192.168.120.165]) - ProFTPD terminating (signal 11)
&gt;

Not too much debug infos !!

Other important point : when I sniff if something come out off my ftp server I can see : NOTHING !

I guess something is wrong in my configuration file (I'm really not a LDAP "guru").

Thanks in advance,

Stephan
</para>
<para>
&gt; Yes, I admit that mod_ldap needs some serious debugging info added; the next
&gt; release is pretty frozen right now, but definitely in the next release.
&gt; After mod_ldap is called to parse its config file entries, it logs a summary
&gt; of all its config paramters, if you run proftpd normally (letting it fork
&gt; and without debugging), do you see something like this in your syslogs? Can
&gt; you look in your LDAP server's logs to see if mod_ldap is querying the LDAP
&gt; database yet? Also, what operating system are you using?

Even if I try to start proftpd normally I can't see anything additional debug.
I also do not see any connections from proftpd to my ldap (netscape Directory 4.1).
I'm running proftpd under Solaris 2.6 (Sun).

&gt;
&gt;
&gt; % Other important point : when I sniff if something come out off my ftp server I can see : NOTHING !
&gt; %
&gt; % I guess something is wrong in my configuration file (I'm really not a LDAP "guru").
&gt; %
&gt; % PS: that's may be due to the compilation with netscape SDK....
&gt;
&gt; I compiled pre10 on this machine (Slack Linux 4), and mod_ldap works fine
&gt; with your config (without AuthPAMAuthoritative, I don't have access to a
&gt; PAMified machine). But I'd like to find out if you see the config-summary
&gt; syslogged anywhere before I'm lead to believe that it's an SDK problem.

So, I'm now looking for an Sun solaris 2.6 binaries plus libraries (ldap and lber)....


I am seeing the same thing as Stephan (signal 11, proftpd closes
connection). My proftpd config is the same as well. I'm on a solaris 7 box
that has PAM and I have tried the proftpd directive
"AuthPAMAuthoritative" set to "on" and "off" with the same result.

I have carried out John's instruction to Stephan (run proftpd in standalone
mode without debugging and check syslog for mod_ldap config parsing entries.
However, I do not see anything.
What I do see logged when a ftp client connection is made is the following:
/var/adm/messages &lt;snip&gt;
Jan 27 07:35:08 thumbsuck proftpd[20813]: thumbsuck.mweb.co.za
(net-61-51.mweb.c
o.za[196.2.61.51]) - ProFTPD terminating (signal 11)
Jan 27 07:35:08 thumbsuck proftpd[20813]: thumbsuck.mweb.co.za
(net-61-51.mweb.c
o.za[196.2.61.51]) - ProFTPD terminating (signal 11)
Jan 27 07:36:51 thumbsuck proftpd[20816]: thumbsuck.mweb.co.za
(localhost[127.0.
0.1]) - ProFTPD terminating (signal 11)
Jan 27 07:36:51 thumbsuck proftpd[20816]: thumbsuck.mweb.co.za
(localhost[127.0.
0.1]) - ProFTPD terminating (signal 11)
&lt;snip&gt;

Seems odd that proftpd is logging what appears to 2 duplicate lines for each
client connection. Note that I tried from two different clients.

I also do not see any connections from proftpd to my ldap (openldap).

Hopefully this may assist in pinning down this problem?
Paul Gamble.


On Wed, Jan 26, 2000 at 08:25:48PM +0100, Stephan Nardone wrote:
% 
% I'm trying to use proftpd with the ldap module (v2.0).
% 
% I've made a beautiful compilation of proftpd with some others modules
% (the problem is the same without quota and ratio)
% 
% &gt; shagga (root) /tmp/proftpd-1.2.0pre10 &gt; ./proftpd -l
% &gt; Compiled-in modules:
% &gt;   mod_core.c
% &gt;   mod_auth.c
% &gt;   mod_xfer.c
% &gt;   mod_site.c
% &gt;   mod_ls.c
% &gt;   mod_unixpw.c
% &gt;   mod_log.c
% &gt;   mod_pam.c
% &gt;   mod_ratio.c
% &gt;   mod_ldap.c

I believe you need something like MySQL or PostgreSQL to store persistent
ratios across FTP sessions; mod_ldap doesn't support storing ratio
information (yet, I'll have to look to see what's involved).

% My configuration file is something like that :
% 
[snip]
% &gt; LDAPServer                      ldap_shagga
% &gt; LDAPDNinfo                      cn=admin,dc=datelec,dc=com password
% &gt; LDAPDoAuth                      on "dc=People,dc=datelec,dc=com"
% &gt; LDAPDoUIDLookups                off
% &gt; LDAPDoGIDLookups                off

This looks fine.

% When I start proftpd ( proftpd -d 5 -n ) and i try to connect to the
server, I get this message :
% 
% 
% &gt; shagga - ProFTPD 1.2.0pre10 standalone mode STARTUP
% &gt; shagga (snardone.datelec.ch[192.168.120.165]) - connected - local  :
192.168.120.164:21
% &gt; shagga (snardone.datelec.ch[192.168.120.165]) - connected - remote :
192.168.120.165:3451
% &gt; shagga (snardone.datelec.ch[192.168.120.165]) - ProFTPD terminating
(signal 11)
% 
% Not too much debug infos !!

Yes, I admit that mod_ldap needs some serious debugging info added; the next
release is pretty frozen right now, but definitely in the next release.
After mod_ldap is called to parse its config file entries, it logs a summary
of all its config paramters, if you run proftpd normally (letting it fork
and without debugging), do you see something like this in your syslogs? Can
you look in your LDAP server's logs to see if mod_ldap is querying the LDAP
database yet? Also, what operating system are you using?

% Other important point : when I sniff if something come out off my ftp
server I can see : NOTHING !
% 
% I guess something is wrong in my configuration file (I'm really not a LDAP
"guru").
% 
% PS: that's may be due to the compilation with netscape SDK....

I compiled pre10 on this machine (Slack Linux 4), and mod_ldap works fine
with your config (without AuthPAMAuthoritative, I don't have access to a
PAMified machine). But I'd like to find out if you see the config-summary
syslogged anywhere before I'm lead to believe that it's an SDK problem.

On Thu, Jan 27, 2000 at 07:48:45AM +0200, Paul Gamble - MWeb wrote:
&gt; I am seeing the same thing as Stephan (signal 11, proftpd closes
&gt; connection). My proftpd config is the same as well. I'm on a solaris 7 box

It may not help much, but its probably worth pointing out that signal
number 11 is a segmentation violation (SIGSEGV, see /usr/include/sys/signal.h)
which indicate that some code within ProFTPD is doing bad things to
memory.

-- 

On Wed, Jan 26, 2000 at 08:25:48PM +0100, Stephan Nardone wrote:
% 
% I'm trying to use proftpd with the ldap module (v2.0).
% 
% I've made a beautiful compilation of proftpd with some others modules
% (the problem is the same without quota and ratio)
% 
% &gt; shagga (root) /tmp/proftpd-1.2.0pre10 &gt; ./proftpd -l
% &gt; Compiled-in modules:
% &gt;   mod_core.c
% &gt;   mod_auth.c
% &gt;   mod_xfer.c
% &gt;   mod_site.c
% &gt;   mod_ls.c
% &gt;   mod_unixpw.c
% &gt;   mod_log.c
% &gt;   mod_pam.c
% &gt;   mod_ratio.c
% &gt;   mod_ldap.c

I believe you need something like MySQL or PostgreSQL to store persistent
ratios across FTP sessions; mod_ldap doesn't support storing ratio
information (yet, I'll have to look to see what's involved).

% My configuration file is something like that :
% 
[snip]
% &gt; LDAPServer                      ldap_shagga
% &gt; LDAPDNinfo                      cn=admin,dc=datelec,dc=com password
% &gt; LDAPDoAuth                      on "dc=People,dc=datelec,dc=com"
% &gt; LDAPDoUIDLookups                off
% &gt; LDAPDoGIDLookups                off

This looks fine.

% When I start proftpd ( proftpd -d 5 -n ) and i try to connect to the server, I get this message :
% 
% 
% &gt; shagga - ProFTPD 1.2.0pre10 standalone mode STARTUP
% &gt; shagga (snardone.datelec.ch[192.168.120.165]) - connected - local  : 192.168.120.164:21
% &gt; shagga (snardone.datelec.ch[192.168.120.165]) - connected - remote : 192.168.120.165:3451
% &gt; shagga (snardone.datelec.ch[192.168.120.165]) - ProFTPD terminating (signal 11)
% 
% Not too much debug infos !!

Yes, I admit that mod_ldap needs some serious debugging info added; the next
release is pretty frozen right now, but definitely in the next release.
After mod_ldap is called to parse its config file entries, it logs a summary
of all its config paramters, if you run proftpd normally (letting it fork
and without debugging), do you see something like this in your syslogs? Can
you look in your LDAP server's logs to see if mod_ldap is querying the LDAP
database yet? Also, what operating system are you using?

% Other important point : when I sniff if something come out off my ftp server I can see : NOTHING !
% 
% I guess something is wrong in my configuration file (I'm really not a LDAP "guru").
% 
% PS: that's may be due to the compilation with netscape SDK....

I compiled pre10 on this machine (Slack Linux 4), and mod_ldap works fine
with your config (without AuthPAMAuthoritative, I don't have access to a
PAMified machine). But I'd like to find out if you see the config-summary
syslogged anywhere before I'm lead to believe that it's an SDK problem.


Hi all,

I am trying to use Apache's mass virtual hosting features to create a
mass virtual hosting server for web data. Trouble is, to upload their
data, users need to use ftp to do it.

I am looking for an ftp server daemon wchich will let me do the
following:

- authenticate username/password in LDAP
- chroot access to their home directory
- NO POSIX ACCOUNT NEEDED in the LDAP server (easier to maintain, more
secure)

Can proftpd (with LDAP patches) do this?

</para>

<para>

P

On Thu, Dec 02, 1999 at 03:28:04PM +0100, Graham Leggett wrote:
% I am trying to use Apache's mass virtual hosting features to create a
% mass virtual hosting server for web data. Trouble is, to upload their
% data, users need to use ftp to do it.
% 
% I am looking for an ftp server daemon wchich will let me do the
% following:
% 
% - authenticate username/password in LDAP

Sure, mod_ldap can do this.

% - chroot access to their home directory

This is a part of ProFTPD itself, and has no problems with mod_ldap as far
as I can see.

% - NO POSIX ACCOUNT NEEDED in the LDAP server (easier to maintain, more
% secure)

Currently, mod_ldap uses the posixAccount objectclass; if you really don't
want to use it, you can modify this behavior, but it will require
modification of the mod_ldap source to change the names of the attributes
that the module is looking for from the LDAP database. I'm thinking of
making this compile-time configurable in the next release of mod_ldap[1];
a couple other people have mentioned that they don't want to use the
posixAccount objectclass.

[1] mod_ldap v2.0 will be released any day now; I've got 95% of the docs
done, just gotta get the web site updated. I'll think about adding a
non-posixAccount objectclass to my todo for the next release. If anybody
wants an advance copy of v2.0, please let me know.

</para>
<para>

% Ideally what I am looking for is something that can match the
% VirtualDocumentRoot directive in the Apache mod_vhost_alias module.
% 
% Here you define a template of some kind that tells Apache where to find
% the document root directory based on the DNS name of the website.
% 
% It would be great if ProFTPd could do this also, either getting the DNS
% name from an attribute in LDAP, or by using the username+SomeDNSSuffix
% to correspond.
</para>
<para>
Hm, that would be interesting. Maybe a config option to vary the LDAPPrefix
based on the IP address the remote user connected to. I'll have to check it
out.
</para>
<para>
% The reason why I don't want to use the posixAccount objectclass is
% because I cannot seem to find any widely available LDAP editors that
% allow me to edit an object using it.

What editors have you looked at, and what objectclasses have they supported?
I'm still considering making objectclass a compile-time option, I just
need some other objectclasses to support. :-)
</para>
<para>
% In addition, the need for posix user and group ids is a pain, something
% has to assign them, and ensure these numbers are unique. This is too
% much work just for ftp.
</para>
<para>
mod_ldap 2.0 changes that; it's the first release that will let you run in a
pure virtual environment (an "ftp toaster" kind of deal). You can assign a
single default UID/GID in your proftpd.conf and also create home directories
on demand (when the user logs in for the first time). (Thanks to Bert
Vermeulen &lt;bert@be.easynet.net&gt; and Krzysztof Dabrowski &lt;brush@pol.pl&gt; for
ideas/patches in this area.)
	  </para>
	  <para>
	    % &gt; Hm, that would be interesting. Maybe a config
	    option to vary the LDAPPrefix % &gt; based on the IP
	    address the remote user connected to. I'll have to check
	    it % &gt; out.  % % The Apache mass virtual hosting places
	    many sites under one IP address, % so determining the
	    hostname this way won't work - but it will work in % the
	    case everyone is given their own IP address.
	  </para>

	  <para>
	    Okay; I didn't consider that possibility. In that case,
	    something like that for the FTP protocol in general won't
	    work; there's no way to do virtual hosting without an IP
	    address for each FTP virtual host. I've heard that there's
	    been some draft work on changing this situation, I don't
	    have any URLs handy, but I think that some have been
	    posted to the list in the past.
	  </para>

	  <para>
	    Yup, it's at
	    http://horde.net/~jwm/software/proftpd-ldap/. It works
	    well for me, and I've had reports of v2.0 working well at
	    other (some large) sites.  Let me know how things go.
	  </para>
	</sect2>

	<sect2>
	  <title>Why use LDAP over SQL?</title>

<para>
&gt; &gt;- Because LDAP is a standard, SQL is not.
&gt; 
&gt; Excuse me?  I think you're misinformed here, as SQL is a standard.  What
&gt; various companies have done with propietary "extensions" is another issue,
&gt; but you can always choose not to use them and stick with core.  But still ,
&gt; I think I understand what you're getting at: portability.
</para>
<para>
SQL thinks it's a standard, but I'm talking in practical terms. Each
vendor seems to have it's own variation on syntax, as well as access
libraries, otherwise you have to install and correctly configure ODBC, a
real pain.
</para>
<para>
The lack of a standard SQL schema is also a problem. The way application
A stores it's user information is usually completely different to the
way that application B does it, because there is no "right" way of doing
it. Assuming it's even possible, making application A and B share the
same schema is usually lots of work. Yuck.
</para>
<para>
&gt; I have been considering using LDAP, which is what prompted my inquiry in
&gt; the first place.  Feedback I've gotten from a few people implementing it is
&gt; that it works great, but does not scale as well as SQL, is more resource
&gt; intensive, and that for large user bases (e.g. couple hundred thousand) is
&gt; much slower.  But I've not yet delved into this thoroughly enough to make a
&gt; sound evaluation.

</para>

	  <para>LDAP scales much better than SQL because of the way
	  the database is designed. You can spread your data logically
	  across multiple machines, allowing different people to have
	  different access to data sets (such as the US people being
	  able to edit their userids, and the Europe people being able
	  to edit thier userids, but neither can edit the other's, if
	  you want it like that), while at the same time keeping the
	  tree looking like a single logical data set. You can also
	  (as we do here) mirror your data across many LDAP servers,
	  so if one server goes down it won't take out your
	  applications.</para>

<para>
&gt; &gt;- LDAP's replication, scalability and fault tolerance support is simpl=
e
&gt; &gt;to configure and use, SQL's is vendor specific and unnecessarily
&gt; &gt;complicated.
&gt;
&gt; I have been considering using LDAP, which is what prompted my inquiry i=
n
&gt; the first place.  Feedback I've gotten from a few people implementing i=
t is
&gt; that it works great, but does not scale as well as SQL, is more resourc=
e
&gt; intensive, and that for large user bases (e.g. couple hundred thousand)=
 is
&gt; much slower.  But I've not yet delved into this thoroughly enough to ma=
ke a
&gt; sound evaluation.
</para>

	  <para>I'm speaking for a commercial LDAP implementation,
	  Netscape-iPlanet Direc= tory Server 4.11.  It's fast like
	  hell! If you use the personalisation features of
	  my.netscape.com, you can see that's it fast. And
	  my. netscape has over 20million users in their ldap servers
	  and each user has around 400 attri= butes.</para>

	  <para>PcWeek measured on a 4 CPU NT box over 5000
	  authentication / second with = this LDAP server.  As Paul
	  Tavernier wrote it really uses cool caching, and it's one of
	  the = most stabe product I've ever seen.  But if you have a
	  lot's of write operation LDAP is not about handling the= m
	  very fast.</para>

<para>
1. performance is better for read operations (what an authentication is)
2. price
3. easier to implement failover than with eg an Oracle.
</para>
	</sect2>
      </sect1>

      <sect1>
	<title>Normal users can't login, only anon.</title>

	<para>Check that the /etc/pam.d/ftp file exists on the system
	  and is configured as detailed in README.PAM</para>
      </sect1>

      <sect1>
	<title>Other authentication methods</title>
	<para>...</para>

	<sect2>
	  <title>NIS/YP</title>
	  <para>Be sure to read the documentation on the PersistentPasswd
            configuration directive.</para>
	</sect2>

	<sect2>
	  <title>Radius</title>

	  <para>Radius support isn't built into ProFTPD, though
	    there's nothing stopping someone writing a module and
	    submitting it for inclusion in the code tree. Possibly the
	    easist way to implement Radius is by using the modules
	    available for PAM and using the inbuilt PAM support.</para>
	</sect2>

	<sect2>
	  <title>Encrypted passwords</title>
	  <para>No support yet. </para>
	</sect2>

	<sect2>
	  <title>SecureID</title>
	  <para>No support yet. </para>
	</sect2>

	<sect2>
	  <title>One time passwords</title>

	  <para>This is possible using either PAM or the Opie
	    modules. The module passes back a challenge which the user
	    puts into a key generator along with their 'pass phrase'
	    and it gives them back 5 words which get sent as the
	    password. As long as you do it correctly it will never
	    repeat. </para>

	  <para>It requires opie to be installed on the server. There
	    are key gen clients for win95/98, *nix,
	    mac. ftp://ftp.urbanrage.com/pub/c/mod_opie.c</para>
	</sect2>
      </sect1>
    </chapter>

<chapter id="proftpd-chroot">
<?dbhtml filename="chroot.html">
<title>DefaultRoot and other issues</title>

      <sect1>
	<title>Locking users into a directory (chroot)</title>

	<para>Preventing users from moving round the filesystem is a
	must for many system admistrators.  Proftpd achieves this
	functionality using the chroot() system call.  This call moves
	the system root directory to the specified location.
	Anonymous connections do this by default setting the chroot()
	to the directory specified in the &lt;Anonymous&gt; directive.
	For more normal users the DefaultRoot directive is
	required</para>

	<para>For general open access you can use an &lt;Anonymous&gt;
	directive context block, possibly in combination with a
	UserPassword/AnonRequirePassword directive.</para>

	<para>However if you wish to jail an entire group (or groups)
	of users, you can use the DefaultRoot directive.  DefaultRoot
	lets you specify a root jailed directory (or '~' for the
	user's home directory), and an optional group-expression
	argument which can be used to control which groups of users
	the jail will be applied to. For example:</para>

<example>
<title>Simple DefaultRoot setup</title>
<programlisting>
#
# A simple DefaultRoot setup
# limiting all users to their $HOME
#
&lt;VirtualHost myhost.mynet.foo&gt;
DefaultRoot ~
&lt;/VirtualHost&gt;
</programlisting>
</example>

	<para>In this example, all users who are members of group
	'users', but not members of group "staff" are jailed into
	/u2/public. If a user does not meet the group-expression
	requirements, they login as per normal (not jailed, default
	directory is their home).  You can use multiple DefaultRoot
	directives to create multiple jails inside the same directive
	context. If two DefaultRoot directives apply to the same user,
	ProFTPD arbitrarily chooses one (based on how the
	configuration file was parsed).</para>

	<para>The chroot() system call simply moves the root (or "/")
	directory to a specified point within the filesystem.  When
	implemented properly this has the effect of jailing a user
	into a particular branch of the filesystem directory
	structure.  The security advantages of this approach are
	easily seen and it is a common method used by programmers and
	system administrators worldwide to enhance their local
	security models.</para>

<sect2>
<?dbhtml filename="chroot-security.html">
<title>Security Implications</title>

	<para>This approach should not be considered a high security
	model it has a number of flaws, not least of which is that
	chroot jails can be broken out of.  Breaking a chroot is not a
	trivial task but it's nowhere near to being impossible and a
	competant cracker should be able to breach the security
	offered by chroot.  This said it is still a valuable tool in
	the armoury of the admin.</para>

	<para>The DefaultRoot directive is implemented using the
	chroot(2) system call.  This moves the "/" (or root) directory
	to a specified point within the file system and jails the user
	into this sub-tree.  However this is not the holy grail of
	security, a chroot jail can be broken, it is not a trivial
	matter but it's nowhere near impossible.  DefaultRoot should
	be used as part of a general system of security not the only
	security measure.</para>

	<para>A more detailed discussion on this subject and on the
	  breaking of chroot jails has been written by Simon Burr
	  (http://www.bpfh.net/simes/computing/chroot-break.html)</para>

	<para>This prevention method was developed by Carole Fennelly
	and her partner.  Have a look at the August 1999 Security
	column of SunWorld Online for the article - see
	http://www.sunworld.com/sunworldonline/swol-08-1999/swol-08-security-2.html
	</para>

	<para>It's worth noting that almost all FTP servers retain
	root privileges throughout their life, though they may revert
	to lower levels where possible.  This is because the daemon
	needs to keep its root privs around when a user is logged in
	for things like opening sockets on ports less than
	1024.</para>

	<sect3>
	<title>Non-root server issues</title>

	<para>The chroot() system call will not work under a non-root
	ftp server process, the call requires root privileges.
	Without them it simply doesn't work, there doesn't appear to
	be any checking in the code of the uid/gid before calling
	chroot so using DefaultRoot in such a setup will cause the
	server to fail.</para>
	</sect3>
	</sect2>

	<sect2>
	  <title>Required files</title>

	  <para>Some OSs require files to always exist in an
	  environment for certain things to work. For example you need
	  the following files available for chroot()ed work under
	  Solaris 2.5.1:</para>
	  <simplelist>
	    <member>/dev/tcp</member>
	    <member>/dev/ticotsord</member>
	    <member>/dev/udp</member>
	    <member>/dev/tcp</member>
	  </simplelist>

	  <para>So to actually make Proftpd work in a chrooted
	  environment it may be necessary to create $HOME/etc/
	  $HOME/dev/ and similar directories and create certain files.
	  While files are required will vary from system to system and
	  are generally outside the scope of this guide</para>

	<sect3>
	<title>svc.conf</title>

	<para>For systems which require the svc.conf file, tyically
	Digital Unix systems, it is essential that a copy of this file
	is placed within the chroot ($HOME/etc/svc.conf) or all
	attempts to authenticate will fail with error messages similar
	to those below.</para>

<screen>
331 Password required for test.
Password:
230 User test logged in.
ftp&gt; dir
200 PORT command successful.
getsvc: stat of /etc/svc.conf failed
ftp&gt; pwd
getsvc: stat failed: No such file or direc
getsvc: stat of /etc/svc.conf failed
getsvc: stat failed: No such file or direc
150 Opening ASCII mode data connection for
ftp&gt; pwd
226 Transfer complete.
257 "/" is current directory.
ftp&gt; dir
200 PORT command successful.
getsvc: stat of /etc/svc.conf failed
ftp&gt;
</screen>

<example>
<title>Sample svc.conf file</title>
<programlisting>
# WARNING: This file is MANDATORY !
#
# Setup recommendation: As you add distributed services to database
#       entries, it is recommended that "local" is the first service.
#       For example:
#                       passwd=local,yp
#
# Note: White space allowed only after commas or newlines.
#
# File Format
# -----------
# database=service,service
#
# The database can be:
#       aliases
#       group
#       hosts
#       netgroup
#       networks
#       passwd
#       protocols
#       rpc
#       services
# The service can be:
#       local
#       yp
#       bind (hosts ONLY)
#
aliases=local
group=local
hosts=local,bind,yp
netgroup=local
networks=local
passwd=local
protocols=local
rpc=local
services=local
SECLEVEL=BSD   # for backwards compatibility ONLY
</programlisting>
</example>
</sect3>
</sect2>
</sect1>

<sect1>
<title>Finer grained control</title>

<para>There are situations where different classes of user should be
limited in different ways.  For example, developers working on a site
should only be able to see the section they are responsible for,
whereas the sysadmins and supervisors need to have a wider view on the
server.  This can be acomplished either by setting the $HOME of each
user to the location on the disk which is most appropriate, or more
commonly by using system groups.</para>

<example>
<title>DefaultRoot, modified by system group</title>
<programlisting>
#
# A more complex setup where all users are locked into 
# their home except those in group 'staff' who are 
# locked into /u2/allweb
#
&lt;VirtualHost myhost.mynet.foo&gt;
DefaultRoot ~ !staff
DefaultRoot /u2/allweb staff
&lt;/VirtualHost&gt;
</programlisting>
</example>
</sect1>

<sect1>
<?dbhtml filename="chroot-symlinks.html">
<title>Symlinks and chroot()</title>
<authorblurb>
<para>
Contributor: Rod Whitworth &lt;rodw at witworx dot com&gt;
</para>
</authorblurb>

<para>There have been many questions on the ProFTPD user mailing list
about why symlinked directories are not visible to chrooted users
(this includes &lt;Anonymous&gt; users as well as users restricted
using DefaultRoot. This document is intended to clarify the issues and
discuss some ways of achieving what is commonly desired.</para>

<para>These issues are not specific to ProFTPD, but rather to the
workings of a Unix system. First, a brief review of how links work,
and why chroot(2) poses such a problem. Then a look at ways around the
issue.</para>

<sect2>
<title>How Links Work</title>

<para>There are two types of links in Unix: hard and symbolic.</para>

<para>A hard link is a file that is, for all intents and purposes, the file
to which it is linked. The difference between a hardlink and the
linked file is one of placement in the filesystem. Editing the
hardlink edits the linked file. One limitation of hard links is that
linked files cannot reside on different filesystems. This means that
if /var and /home are two different mount points in /etc/fstab (or
/etc/vfstab), then a file in /var/tmp cannot be hardlinked with a file
in /home:</para>

<screen>
&gt; pwd
/var/tmp
  &gt; ln /home/tj/tmp/tmpfile tmplink
ln: cannot create hard link `tmplink' to `/home/tj/tmp/tmpfile': Invalid cross-device link
</screen>

<para>A symbolic link (also referred to as a "symlink") is a file
whose contents contain the name of the file to which the symbolic link
points. For example:</para>

<screen>
lrwxrwxrwx   1 root     root           11 Mar  2  2000 rmt -> /sbin/rmt
</screen>

<para>The file rmt contains the nine characters /sbin/rmt. The reason
symbolic links fail when chroot(2) is used to change the position of
the root (/)of the filesystem is that, once / is moved, the pointed-to
file path changes. If, for example, if chroot(2) is used to change the
filesystem root to /ftp, then the symlink above would be actually be
pointing to /ftp/sbin/rmt. Chances that that link, if chroot(2) is
used, now points to a path that does not exist. Symbolic links that
point to nonexistent files are known as dangling symbolic links. Note
that symbolic links to files underneath the new root, such as symlinks
to a file in the same directory:</para>

<screen>
&gt; pwd
/var/ftp
  &gt; ls -l
-rw-r--r--   1 root     root            0 Jan 16 11:50 tmpfile
  lrwxrwxrwx   1 root     root            7 Jan 16 11:50 tmplink -&gt; tmpfile
</screen>

<para>will be unaffected; only paths that point outside/above the new
root will be affected.</para>

</sect2>

<sect2>

<title>Filesystem Tricks</title>

<para>A typical scenario is one where "DefaultRoot ~" is used to
restrict users to their home directories, and where the administrator
would like to have a shared upload directory, say /var/ftp/incoming,
in each user's home directory. Symbolic links would normally be used
to provide an arrangement like this. As mentioned above, though, when
chroot(2) is used (which is what the DefaultRoot directive does),
symlinks that point outside the new root (the user's home directory in
this case) will not work. To get around this apparent limitation, it
is possible on modern operating systems to mount directories at
several locations in the filesystem.</para>

<para>To have an exact duplicate of the /var/ftp/incoming directory
available in /home/bob/incoming and /home/dave/incoming, use one of
these commands:</para>

<screen>
    * Linux (as of the 2.4.0 kernel):

mount --bind /var/ftp/incoming /home/bob/incoming
  mount --bind /var/ftp/incoming /home/dave/incoming

    * BSD (as of 4.4BSD):

mount_null /var/ftp/incoming /home/bob/incoming
  mount_null /var/ftp/incoming /home/dave/incoming

    * Solaris:

mount -F lofs /var/ftp/incoming /home/bob/incoming
  mount -F lofs /var/ftp/incoming /home/dave/incoming
</screen>

<para>The same technique can be used for &lt;Anonymous&gt; directories,
which also operate in a chroot()ed environment.</para>

<para>As usual, more information can be found by consulting the man
pages for the appropriate command for your platform. The commands for
other flavors of Unix will be added as needed.</para>

<para>In order to have these tricks persist, to survive a system
reboot, the /etc/fstab (or /etc/vfstab) file may need to have these
mounts added. Consult your local fstab(5) (or vfstab(4) for Solaris)
man pages for more information.</para>
</sect2>
</sect1>

</chapter>

    <chapter id="anon-server">
      <title>Anonymous Servers</title>

      <para>ProFTPD is a ftp server primarily written for the various
      unix variants though it will now compile under win32.  It has
      been designed to be much like Apache in concept, taking many of
      the ideas (configuration format, modular design, etc.) from
      it.</para>

      <sect1>
	<title>How do I create individual anonymous FTP sites for my users?</title>

	<para>There are two methods of accomplishing this (possibly
	more).  First, you can create a directory structure inside
	your anonymous FTP root directory, creating a single directory
	for each user and setting ownership/permissions as
	appropriate. Then, either create a symlink from each user's
	home directory into the FTP site, or instruct your users on
	how to access their directory.</para>

	<para>The alternate method (and more versatile) of
	accomplishing per-user anonymous FTP is to use AnonymousGroup
	in combination with the DefaultRoot directory. You'll probably
	want to do this inside a &lt;VirtualHost&gt;, otherwise none
	of your users will be able to access your system without being
	stuck inside their per-user FTP site.  Additionally, you'll
	want to use a deferred &lt;Directory&gt; block to carefully
	limit outside access to each user's site.</para>

	<para>Create a new unix group on your system named
	`anonftp'. Please each user who will have per-user anonymous
	FTP in this group.  Create an `anon-ftp' and
	`anon-ftp/incoming' directory in each user's home directory.
	Modify your /etc/proftpd.conf file to look something like this
	(you'll probably want to customize this to your needs):</para>

<programlisting>
 &lt;VirtualHost my.per-user.virtual.host.address&gt;
 
 # the next line limits all logins to this virtual host, so that only
 anonftp users can connect
 
 &lt;Limit LOGIN&gt;
 DenyGroup !anonftp
 &lt;/Limit&gt;
 
 # limit access to each user's anon-ftp directory, we want read-only
 except on incoming
 
 &lt;Directory ~/anon-ftp&gt;
 
 &lt;Limit WRITE&gt;
 DenyAll
 &lt;/Limit&gt;
 
 &lt;/Directory&gt;
 
 # permit stor access to each user's anon-ftp/incoming directory,
 but deny everything else
 
 &lt;Directory ~/anon-ftp/incoming&gt;
 
 &lt;Limit STOR&gt;
 AllowAll
 &lt;/Limit&gt;
 &lt;Limit READ WRITE&gt;
 DenyAll
 &lt;/Limit&gt;
 
 &lt;/Directory&gt;
 
 # provide a default root for all logins to this virtual host.
 DefaultRoot ~/anon-ftp
 # Finally, force all logins to be anonymous for the anonftp group
 AnonymousGroup anonftp
 
 &lt;/VirtualHost&gt;
</programlisting>
      </sect1>


      <sect1>
	<title>I want to support normal login and Anonymous under a
particular user</title>

	<para>You can use the AuthAliasOnly directive to control how
	and where real usernames get authenticated (as opposed to
	aliased names, via the UserAlias directive). Note that it is
	still impossible to have two identical aliased names login to
	different anonymous sites; for that you would need
	&lt;VirtualHost&gt;.</para>

<para>Example:


...
&lt;Anonymous ~jrluser&gt;

 User jrluser
 Group jrluser
 UserAlias ftp jrluser
 UserAlias anonymous jrluser
 AuthAliasOnly on
 ...
 
&lt;/Anonymous&gt;

</para>

	<para>Here, the &lt;Anonymous&gt; configuration for ~jrluser
	is set to allow alias authentication only. Thus, if a client
	attempts to authenticate as 'jrluser', the anonymous config
	will be ignored and the client will be authenticated as if
	they were a normal user (typically resulting in `jrluser'
	logging in normally). However, if the client uses the aliased
	username `ftp' or `anonymous', the anonymous block is
	applied.</para>
      </sect1>

      <sect1>
	<title>I only want to allow anonymous access to a virtual server.</title>

	<para>Use a &lt;Limit LOGIN&gt; block to deny access at the
	top-level of the virtual host, then use &lt;Limit LOGIN&gt;
	again in your &lt;Anonymous&gt; block to allow access to the
	anonymous login. This permits logins to a virtual anonymous
	server, but denies to everything else. Example:


&lt;VirtualHost 10.0.0.1&gt;
ServerName "My virtual FTP server"
&lt;Limit LOGIN&gt;
DenyAll
&lt;/Limit&gt;
&lt;Anonymous /usr/local/private&gt;
User private
Group private
&lt;Limit LOGIN&gt;
AllowAll
&lt;/Limit&gt;
...
&lt;/Anonymous&gt;
&lt;/VirtualHost&gt;
</para>
</sect1>
<sect1>
<title>Why doesn't Anonymous ftp work</title>
<subtitle>550 login incorrect</subtitle>

	<para>
Things to check
Check the following first:
        </para>
	<para>Make sure the user/group you specified inside the
	&lt;Anonymous&gt; block actually exists. This must be a real
	user and group, as it is used to control whom the daemon runs
	as and authenticates as.

If RequireValidShell is not specifically turned off, make sure
that your "ftp user" (as specified by the User directive inside an
&lt;Anonymous&gt; block), has a valid shell listed in /etc/shells. If you do
not wish to give the user a valid shell, you can always use
"RequireValidShell off" to disable this check.

If UseFtpUsers is not specifically turned off, make sure that
your "ftp user" is not listed in /etc/ftpusers.
</para>

	<para>If all else fails, you should check your syslog. When
	authentication fails for any reason, ProFTPD uses the syslog
	mechanism to log the reason for failure; using the AUTH (or
	AUTHPRIV) facility. If you need further assistance, you can
	send email, including related syslog entries and your
	configuration file, to the ProFTPD mailing list mentioned
	elsewhere in this FAQ.</para>
      </sect1>
      
      <sect1>
	<title>Additional anonymous accounts</title>

	<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):

<example>
<title>Access control using LIMIT</title>
<programlisting>
&lt;Anonymous ~private&gt;
AnonRequirePassword off
User private
Group private
RequireValidShell off
&lt;Directory *&gt;
&lt;Limit WRITE&gt;
DenyAll
&lt;/Limit&gt;
&lt;/Directory&gt;
&lt;/Anonymous&gt;
</programlisting>
</example>
</para>
	<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>
</sect1>

<sect1>	
<title>Secure upload facilities</title>

<para>The following snippet from a sample configuration file
illustrates how to protect an "upload" directory in such a fashion
(which is a very good idea if you don't want people using your site
for "warez"):</para>

<programlisting>
&lt;Anonymous /home/ftp&gt;
  # All files uploaded are set to username.usergroup ownership
  User username
  Group usergroup
  UserAlias ftp username
  AuthAliasOnly on
  RequireValidShell off

  &lt;Directory pub/incoming/&gt;
     &lt;Limit STOR CWD XCWD&gt;
        AllowAll
     &lt;/Limit&gt;
     &lt;Limit READ DELE MKD RMD XMKD XRMD&gt;
        DenyAll
     &lt;/Limit&gt;
  &lt;/Directory&gt;
&lt;/Anonymous&gt;
</programlisting>

	<para>This denies all write operations to the anonymous root
	directory and sub-directories, except "incoming/" where the
	permissions are reversed and the client can store but not
	read. If you used &lt;Limit WRITE&gt; instead of &lt;Limit
	STOR&gt; on &lt;Directory incoming&gt;, ftp clients would be
	allowed to perform all write operations to the sub-dir,
	including deleting, renaming and creating directories.</para>
	</sect1>
    </chapter>


<chapter id="config-usingauthuserfile">
<?dbhtml filename="config-usingauthuserfile.html">
<title>Using AuthUserFiles</title>
<authorblurb>
<para>Originally by TJ Saunders</para>
</authorblurb>

<para>The FTP protocol is old, stemming from the days of Telnet,
before security came to be the relevant issue it is today. One of the
protocol's biggest flaws, in today's security-conscious world, is the
transmission of passwords "in the clear", unencrypted, easily visible
to network sniffers. There are several ways of attempting to deal with
this flaw.</para> 

<para>ProFTPD allows for the definition of "virtual" users: users who do not
have accounts on the host machine, whose account information is
defined in other sources. The passwords for these users are then
specific only to FTP access, and thus do not expose shell access (ssh,
hopefully) to unauthorized users. These alternative account
information sources include SQL tables (via mod_sql), LDAP servers
(via mod_ldap), CDB files (via mod_auth_cdb), and other system files
(via the AuthUserFile and AuthGroupFile configuration directives). The
proftpd server can be configured to use multiple account information
sources simultaneously as well, allowing for flexible support of a
range of environments. </para>

<para>This document focuses on the use of the AuthUserFile and AuthGroupFile
directives. Several questions often arise about the use of these
directives. In general, the answers to those questions apply to other
authentication/account sources, too. </para>

<sect1>
<title>Formats</title>
<para>Any configured AuthUserFile is used instead of /etc/passwd, not in
addition to it; similarly for AuthGroupFile and /etc/group. The format
of an AuthUserFile is the same as /etc/passwd (man passwd(5)), and the
format of an AuthGroupFile is the same as /etc/group (man
group(5)). There is an ftpasswd script available that can be used to
create and update these files. </para>

<para>It is important to note here that not all flavors of Unix use these
formats; one notable exception is FreeBSD. With FreeBSD, user account
information is stored in binary database files as opposed to ASCII
files. The C library on this platform also lacks the functions
necessary for making the AuthUserFile and AuthGroupFile directives
work properly. In this case, proftpd uses an internal implementation
of the missing functions to read AuthUserFiles and
AuthGroupFiles. This internal implementation requires that
AuthUserFiles have the traditional passwd(5) format: </para>

<programlisting>
username:password:uid:gid:gecos:homedir:shell
</programlisting>

<para>and that AuthGroupFiles have this format:</para>

<programlisting>
groupname:grouppasswd:gid:member1,member2,...memberN
</programlisting>

<para>The ftpasswd script mentioned creates files in these required
formats.</para> 
</sect1>

<sect1>
<title>Choice of IDs</title>

<para>The choice of IDs for your users is important; the operating
system does not deal with user processes in terms of their user names,
it knows only of the numeric identity of a process. In general, it is
best if each user has a unique positive user ID (negative IDs are an
ugly hack, and proftpd will complain if they are used).</para>

<para>However, in some mass-hosting environments such as ISPs, the
number of users is greater than the number of IDs available. In these
cases, you can give each user the same ID; additional steps should
then be taken to make sure that each user is isolated from affecting
other users' files. These additional steps are to make sure each user
has a unique home directory, and then to restrict each user to their
respective home directories by having</para> 

<programlisting>
DefaultRoot ~
</programlisting>

<para>in your proftpd.conf.</para>

<para>There is also currently an issue with using the same usernames
in different authentication schemes (e.g. having the same username in
both /etc/passwd and a mod_sql SQL table); read this thread for more
information:</para> 

<para>http://www.proftpd.org/proftpd-l-archive/full/msg16600.html</para>

</sect1>

<sect1>
<title>Shadow passwords</title>

<para>There really is no need for an AuthShadowFile directive. The
purpose of a shadow file is separate sensitive information
(e.g. passwords) from other account information (username/UID/GID,
etc). Programs like /bin/ls often reference the passwd file in order
to display user/group names rather than numbers; these programs do not
really need that sensitive information. Rather than relying on
programs like /bin/ls to ignore the sensitive information, libraries
were developed to split the information into /etc/passwd, /etc/shadow
(and similarly for /etc/group, but very few administrators use group
passwords anymore). Some operating systems, most notably FreeBSD,
though, chose a different form of information separation. Since
FreeBSD maintains account information in binary database files, the
shadow libraries mentioned above are not used. Instead, FreeBSD
returns the sensitive information to the calling program only if it
has sufficient (i.e. superuser) privileges. </para>

<para>When proftpd uses an AuthUserFile, it is looking for all of the
account information, including the password. And since AuthUserFiles
are specific to proftpd, there is no need to split any passwords out
of an AuthUserFile into an AuthShadowFile. As the documentation
states, an AuthUserFile need not reside inside a chroot() filesystem,
which means that users can be effectively isolated from having access
to that AuthUserFile. At that point, the only consideration is making
sure that the permissions on the AuthUserFile are sufficient for the
server to have access, but no other users.</para>
</sect1>

<sect1>
<title>Permissions</title>

<para>As the AuthUserFile and AuthGroupFile files are meant to be
drop-in replacements for their system cousins, there are a few
caveats. /etc/passwd and /etc/group are normally world-readable on
modern Unix systems. This allows programs like /bin/ls to map system
ID numbers to more legible names; sensitive information in the
/etc/passwd and /etc/group is normally stored elsewhere, in restricted
shadow files. The proftpd server thus assumes that it will not need
special privileges to read an AuthUserFile or an AuthGroupFile. The
process will access any AuthUserFiles and AuthGroupFiles with the
credentials of the user and group configured via the User and Group
directives. The files may contain sensitive information, so they
should not have as open of permissions as /etc/passwd and
/etc/group. The most paranoid setting will have user-read-only
permissions for those files, and have the files be owned by the user
configured for the relevant server via the User directive. Hopefully
the server administrator has created a new account on the system just
for the ftpd daemon.</para> 
</sect1>

<sect1>
<title>ID-to-name mapping</title>

<para>A consequence of which to be aware when using an AuthUserFile is
the difference between that AuthUserFile's mapping of system IDs to
names, and the mapping in /etc/passwd. This may catch some system
administrators unawares when they go to check the ownership of files
uploaded by some user whose account is defined in an AuthUserFile, and
find those files being reported as being owned by different users
and/or groups by /bin/ls. Keep in mind that /bin/ls is using
/etc/passwd, not the AuthUserFile. This issue crops up with any
alternative account information source, not just AuthUserFiles.</para>

<para>If you are using the same UID/GID for your users, e.g. in a mass
hosting environment, one trick you might like to do is make all of the
files, as listed by the server, appear to be owned by the logged in
user. This is done using the DirFakeUser and DirFakeGroup directives,
like this:</para> 

<programlisting>
# make listed files appear to be owned by the logged-in user
  DirFakeUser on ~
  DirFakeGroup on ~
</programlisting>

<para>These directives are purely cosmetic, and in no way change the
real ownership of files. This may cause some confusion on the client
side in some cases, if the user sees a file that is reported to be
owned by them, and the permissions on the file show user access is
allowed, and yet the client is unable to access the file. HideNoAccess
can help in situations like this.</para> 
</sect1>

</chapter>

<!-- START OF CHAPTER -->
<chapter id="config-nat">
<?dbhtml filename="config-nat.html">
<title>Configuration for NAT</title>
<authorblurb>
<para>Contributed by  Tobias Ekbom</para>
<!-- tobias@vallcom.com -->
</authorblurb>
			
<sect1>
<title>Basic information</title>

<para>A NAT is a system that acts like a proxy, but on "packet level".
When a computer on your local network connects to a computer on the
Internet, the NAT replaces the "from" information of packets with it's
own address, making your local network invisible to the
Internet.</para>

<para>For server systems, NAT can improve security and enable multiple
servers to be accessed as a single IP.</para>

<para>This is done by allowing certain ports forwarded "inwards" to
the local network. However, the part of the FTP protocol known as
"Passive" mode is not by default compatible with NAT solutions.  But
NAT functionality is possible with ProFTPD from versions 1.2rc2, and
this document shows you how.</para>

<para>For details on NAT configuration, read the Linux IP-masq HOWTO
(http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html) or search for
information concerning your OS of choice.</para>
</sect1>

<sect1>
<title>Configuring ProFTPD</title>

<para>First configure your ProFTPD install so that it works right from
inside the NAT. There are example configuration files included with
the source.</para>

<para>Then add the directive "MasqueradeAddress" in your
etc/proftpd.conf file to define the public name or IP address of the
NAT:</para>

<programlisting>
MasqueradeAddress	ftp.mydomain.com
	-or-
MasqueradeAddress	123.45.67.89
</programlisting>

<para>Now your ProFTPD will hide it's local address and instead use the
public address of your NAT.</para>

<para>However, one BIG problem exists.</para>

<para>The passive FTP connections will use ports from 1024 and up,
which means that you must forward all ports 1024-65535 from the NAT to
the FTP server!  And you have to allow lots of (possibly) dangerous
ports in your firewalling rules!</para>

<para>Have no fear, simply use the PassivePorts directive in your
etc/proftpd.conf to control what ports ProFTPD uses:</para>

<programlisting>
PassivePorts 60000 65535	# These ports should be safe...
</programlisting>

<para>Now start the FTP daemon and you should see something
like</para>

<screen>
123.45.67.89 - Masquerading as '123.45.67.89' (123.45.67.89)
</screen>
</sect1>

<sect1>
<title>Configuring Linux</title>

<para>This example is for Linux kernel version 2.2.x with ipchains and
ipmasqadm.  The examples below assume that your FTP server has local
address 192.168.1.2.</para>

<para>First we need to enable NAT for our FTP server. As root user:</para>

<screen>
  echo "1">/proc/sys/net/ipv4/ip_forward
  ipchains -P forward DENY
  ipchains -I forward -s 192.168.1.2 -j MASQ
</screen>

<para>Now we load the autofw kernel module and forward port 21 to the FTP
server:</para>

<screen>
  insmod ip_masq_autofw
  ipmasqadm autofw -A -r tcp 21 21 -h 192.168.1.2
</screen>

<para>Then we forward ports for Passive FTP. In our etc/proftpd.conf
file we restriced passive ports to 60000-65535, so that's what we'll
use here:</para>

<screen>
  ipmasqadm autofw -A -r tcp 60000 65535 -h 192.168.1.2
</screen>

<para>Now you can try to login to your FTP server from a computer on
the Internet!</para>
</sect1>

<sect1>
<title>Security</title>

<para>Setting up a ProFTPD install that allows PASV mode connections
requires that a range of ports is forwarded from the NAT to the local
network.  This could be a security hazard, but since you can specify
what port range to use, you are still able to setup relatively tight
firewalling rules.</para>

<para>To be sure that you have no other processes listening on the
ports you have specified for Passive FTP, use a port scanner such as
nmap:</para>

<screen>
  nmap -sT -I -p 60000-65535 localhost
</screen>

<para>If the result says something like</para>

<screen>
  All 5536 scanned ports on localhost (127.0.0.1) are: closed
</screen>

<para>then you should be safe.</para>
</sect1>



</chapter>
<!-- END OF CHAPTER -->

<!-- START OF CHAPTER -->
<chapter id="config-ftpoverssh">
<?dbhtml filename="config_ftpoverssh.html">
<title>Configuring ProFTPD for FTP over SSH</title>
<authorblurb>
<para>
Chapter by TJ Saunders
</para>
</authorblurb>

<sect1>
<title>Basic premise</title>

<para>The File Transfer Protocol is an old protocol, and like many of
the older protocols it was developed in a time when security was not
of such a paramount concern. One aspect of FTP that reflects this is
the transmission of passwords, used to prove to the server that the
client is who they say they are, "in the clear", unencrypted, visible
to any packet sniffer. Protocols like SSH, and its scp program, are
replacing FTP as a means to securely transfer files among
hosts.</para>

<para>However, many people still prefer to use their standard FTP
clients. What would be easiest would be a way to allow such clients to
function while transparently providing the encryption necessary for
today's networks. Can this be done? Yes - after a fashion. This
document aims to describe how to tunnel FTP over an SSH channel,
providing for secure transmission of the user's password.</para>
</sect1>

<sect1>
<title>Client Configuration</title>

<para>The trick to encrypting the password is to make use of ssh's
local port forwarding capability. It works by creating a sort of proxy
on the local host that listens to some high-numbered port. Any traffic
sent to that port is encrypted, and forwarded to the configured remote
address and port. (Note: the prior instructions' flaw was that the
local port forwarding request was sent to localhost, rather than to
the remote server, which effectively set up the encrypted channel
between localhost and itself). Here's how to set up a local port
forward:</para>

<screen>
ssh -Llocal-port:remote-addr:remote-port user@host
</screen>

<para>This says to listen on port local-port on localhost, and to send
that encrypted traffic to host's remote-addr at port remote-port. To
use this trick to secure an FTP session (to be specific, the control
channel, through which passwords are transmitted, will be encrypted;
the data channel will not), it would look like:</para>

<screen>
ssh -f -L3000:ftpserver:21 ftpserver 'exec sleep 10' && ftp localhost 3000
</screen>

<para>Note that the choice of local-port is arbitrary. Using port 3000
is not a requirement. This trick also requires that the ftp client use
passive mode data transfers, so make sure to use a client that
understands FTP passive mode.</para>

<para>Remember that only the control connection is encrypted, not the
data connection: any data you transfer (eg directory listings, files
uploaded or downloaded) are still sent "in the clear". Your password
(and the other FTP commands sent by the client) is not.</para>
</sect1>

<sect1>
<title>Server Configuration</title>

<para>The server side of the connection needs some configuration to
make the ssh tunneling work as well. First, the client need a valid
account on the remote host is necessary in order to support the ssh
tunnel. A valid shell is not strictly necessary for these ssh tunnels,
though; something like:</para>

<screen>
#!/bin/sh
  sleep 10
</screen>

<para>would suffice. This would prevent the FTP users from logging in,
yet give them enough time to establish a port forwarded ssh
connection. With this sort of quasi-shell (although, strictly
speaking, there are better, more restrictive shells than this example,
as it could be escaped from), one can ssh over any command:</para>

<screen>
ssh -l test -f -L3000:ftpserver:21 ftpserver true && ftp localhost 3000
</screen>

<para>You'll also need to use the AllowForeignAddress configuration
directive to your configuration file:</para>

<screen>AllowForeignAddress on</screen>

<para>or proftpd will reject the passive transfer connections and log:</para>

<screen>
SECURITY VIOLATION: Passive connection from {host} rejected
</screen>

<para>Note that the use of the server host's DNS name, or its IP
address, in the setting up of the ssh tunnel assumes that the routing
of traffic to the host's own IP address will be short-circuited in the
kernel and thus not actually be transmitted on the wire. On modern
kernels this is a fair assumption, but may not always be the case. For
the truly paranoid, use of localhost or 127.0.0.1 as the remote-addr
parameter in the ssh tunnel command would cause traffic on host to be
sent over its loopback address, and not over the network. However,
this will prevent data transfers from working altogether. The author
is presently developing a patch for scenarios like this; if
interested, please contact him directly via email.</para>

</sect1>
</chapter>

<!-- END OF CHAPTER -->

</part>

  <part id="part-advancedconfig">
    <?dbhtml filename="partIII-advanced-config.html">
    <title>Advanced configuration</title>
    <toc>
    </toc>

    <chapter>
      <title>Access controls</title> 

      <para>It's a rare day in the life of the systems administrator
      when he doesn't want to limit the access a user or network has
      to a resource.  Whether the limits are prohibitions on access or
      limits on the amount of use that can be made they are a fact of
      life on anything but the simplest of configurations.</para>

      <sect1>
	<title>Access limitation</title>

	<sect2>
	  <title>Controlling timeouts</title>

	  <para>There are a number of methods for controlling how long
	  the daemon waits for connections to complete, and how long a
	  connection is held open by the daemon while waiting for
	  traffic.  The times given in the various Timeout* directives
	  are in seconds.</para>

	  <informalexample>
	    <programlisting>
TimeoutNoTransfer               900
TimeoutIdle                     900
	    </programlisting>
	  </informalexample>

	  <para>Setting the various timeouts too high can result in
	    problems because of connections being held open too long.
	    Setting the timeout to zero is definitely recommended
	    against, infinite timeouts are bad without a very good
	    reason.</para>

	  <informalexample>
	    <programlisting>
TimeoutIdle
Syntax: TimeoutIdle seconds
Default: TimeoutIdle 600
Context: server config
Compatibility: 0.99.0 and later
	      </programlisting>
	    </informalexample>

	  <para>The TimeoutIdle directive configures the maximum
	    number of seconds that proftpd will allow clients to stay
	    connected without receiving any data on either the control
	    or data connection. If data is received on either
	    connection, the idle timer is reset. Setting TimeoutIdle
	    to 0 disables the idle timer completely (clients can stay
	    connected for ever, without sending data). This is
	    generally a bad idea as a "hung" tcp connection which is
	    never properly disconnected (the remote network may have
	    become disconnected from the Internet, etc) will cause a
	    child server to never exit (at least not for a
	    considerable period of time) until manually killed</para>
	</sect2>

	<sect2>
	  <title>Abusive users</title>

	  <para>Your attempt to post to the ProFTPD mailing list at
	    i've got a problem with people who "hammer" my ftp site
	    when its quite busy..........i have my max connections per
	    IP set at 1, but when people hammer, they try connecting
	    several times per second! this sometimes allows them to
	    connect many times, often using up all the users for the
	    account. i have looked through the documentation and have
	    been unable to find something to eliminate this. is there
	    anything?  something i can configure to, let's say "if
	    user connects X times in X seconds, then ban. or ignore
	    for X minutes" etc.  any help would be appreciated.
	    eric</para>

	  <para>You mean you have MaxClientsPerHost set to 1 already
	    ? If so then this and a user from the same IP address can
	    connect more than once then this is presumably a bug
	    (check the logs to make sure that they are coming from the
	    same IP address) or do you mean that they connect and
	    disconnect quickly ?</para>
	</sect2>

	<sect2>
	  <title>Access classes</title>

	  <para>How do I go about using the class directive in
	  proftpd.  Under wu-ftpd, I could limit function base on
	  define class (anonymous, guest, etc) How would you do this
	  under proftpd? (ie anonymous could only do this, real user
	  from this ip could do this, where real user from this other
	  IP could do this!)  Class

Syntax: Class "name" limit|regex|ip value
Default: None
Context: server config 
Compatibility: 1.2.0pre9 and later

Controls class based access. Class base access allows each connecting IP to be classified into a separate class. Each class has its
own maximum number of connections. limit sets the maximum number of connections for that class name, regex sets a hostname
regex (POSIX) for inclusion in the class and ip sets an IP/netmask based inclusion. The default class is called default. Example: 

  Classes on
  Class local limit 100
  Class default limit 10
  Class local regex .*foo.com
  Class local ip 172.16.1.0/24

This creates two classes, local and default, with local being everything in *.foo.com and 172.16.1.* combined. 



Classes

Syntax: Classes on|off 
Default: Off
Context: server config 
Compatibility: 1.2.0pre9 and later

Controls class based access. Enables class based access control. see:
Class 

</para>

<para>

Ok, been playing again :)

Example of a real life classes based config.
</para>

<example>
	    <title>Configuration using classes</title>
	    <programlisting>
ServerName			"Frostbite FTPserver"
ServerType			standalone
DeferWelcome			on
Port				21
Umask				002
User				ftp
Group				ftp
TransferLog			/var/spool/syslog/proftpd/xferlog.legacy
DefaultRoot			/ftp/ftp.linux.co.uk
TimeoutLogin			120
TimeoutIdle			600
TimeoutNoTransfer		900
TimeoutStalled			3600
ScoreboardFile			/var/run/proftpd
LogFormat         		default "%h %l %u %t \"%r\" %s %b"
LogFormat			auth    "%v [%P] %h %t \"%r\" %s"
LogFormat			write   "%h %l %u %t \"%r\" %s %b"
UseReverseDNS			off
MultilineRFC2228		on
AllowFilter ".*/[a-zA-Z0-9 ]+$"
Port 0

&lt;Global&gt;
	DisplayLogin		welcome.msg
	DisplayFirstChdir	readme
	AllowOverwrite		yes
	AccessGrantMsg          "Welcome to Tux's kingdom oh chilly %u"
	DisplayConnect /ftp/ftp.linux.co.uk/login.msg
	IdentLookups         off
	ExtendedLog		/var/spool/syslog/proftpd/access.log WRITE,READ write
	ExtendedLog		/var/spool/syslog/proftpd/auth.log AUTH auth
	ServerIdent		on "Linux.co.uk server"
	AllowForeignAddress	on
	PathDenyFilter		"(\.htaccess)|(\.ftpaccess)$"
&lt;/Global&gt;

# ----------------------------------------------------
# ftp.linux.co.uk ("Linux.co.uk FTP Archive") 
# Contact : zathras@linux.co.uk
#
&lt;VirtualHost 195.200.4.15&gt;
ServerAdmin             zathras@linux.co.uk                     
ServerName              "Linux.co.uk FTP Archive"
TransferLog             /var/spool/syslog/xfer/ftp.linux.co.uk
MaxLoginAttempts        3
RequireValidShell       no
DefaultRoot             /ftp/ftp.linux.co.uk
User                    linux
Group                   linux
AllowOverwrite          yes
DefaultServer		yes
LoginPasswordPrompt     off "Wibble"
#
# Allow 50 users from Local network, local WAN 
# Limit everyone else to 20 connections
#
Classes on
Class local limit 50
Class default limit 20
Class local regex .*ftech.co.uk
Class local ip 195.200.0.0/19
Class local ip 212.32.0.0/17
Class local ip 192.168.0.0/16

&lt;Anonymous /ftp/ftp.linux.co.uk&gt;
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        ##MaxClients              200
	MaxClientsPerHost	5 "Please don't be a hog and open any more sessions"
	AccessGrantMsg          "Welcome to Tux's kingdom oh chilly anonymous user"
	AllowForeignAddress	on
	#
	# Global upload, no download or browsing.
	#
	&lt;Directory pub/incoming/*&gt;
		AllowOverwrite off
		&lt;Limit STOR CWD XCWD CDUP MKD&gt;
			AllowAll
		&lt;/Limit&gt;
		&lt;Limit READ DELE WRITE DIRS&gt;
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;
&lt;/Anonymous&gt;
&lt;/VirtualHost&gt;
</programlisting>
	  </example>




	</sect2>

<sect2>
<title>Stopping permission changes</title> 
<para>As of 1.2.0rc1 it is possible to prevent end users from altering
the permissions on files in directories they have modify rights to.
The AllowChmod directive, which defaults to deny, can be used to allow
chmod on a server, global, virtualhost or directory basis.  Giving a
much finer degree of control over what the end users are capable
of.</para>
</sect2>
</sect1>

<!-- BANDWIDTH -->
      
<sect1>
<title>Bandwidth control</title>

<para>The bandwidth control mechanisms inside Proftpd have changed
dramatically during the 1.2.0 development and release cycle.  The
original 'Bandwidth' directive has been removed and replaced with a
nubmer of 'Rate*' directives.  These only work on a per session basis
with no scope for limiting on a VirtualHost basis or a netblock
basis.  This functionality is planned for the 1.3.x development
branch.</para> 

<example>
<title>Simple throttling config</title>
<programlisting>
Bandwidth                       81920

is replaced with something like

RateReadBPS                     81920
RateReadFreeBytes               5120
RateReadHardBPS                 on
</programlisting>
</example>

<para>To achieve a total limit on a per virtual basis a mix of
RateReadBPS and MaxClients is needed.  ie RateReadBPS x MaxClients =
Total Bandwidth allocation.  There is no way (at the moment) to
specify that virtual server xyz has a maximum total bandwidth of
200K/s that it can use between all connections.</para>

<para>Per-virtual, per-user and global limits are currently in the "to
be coded" pile and are being penciled in for the 1.3.x development
series.  There is some work in providing for a shared communication
system between servers before this can happen.</para>

<sect2>
<title>Limiting the total usage by a VirtualHost</title>

<para></para>

	  <para>How can i achieve bandwidth restriction to depend on
	  current user.  one should have 1000 bytes per second write,
	  the other 100bytesps for example.  RateWriteBPS is global,
	  isn't it ?</para>

	  <para>I have a delimma that I need opinions and ideas on.
	  At K-State our Internet1 bandwidth is getting pretty hefty.
	  They are trying cut back on resources until they can get a
	  grip on the napster problem we're having.  One of the things
	  that they wanted done to my public mirror server (see sig)
	  was rate limiting.  I don't terribly mind it but I don't
	  want to do it to Internet2 Universities and other
	  participants.  My possible solution was to send all
	  Internet1 users to one hostname, and all Internet2 users to
	  a Virtualhost.  The Internet1 would have standard rate
	  limiting features (could someone give me an opinion on
	  numbers for this please?  I haven't used it before) and the
	  Interet2 virtualhost would be unlimited.  That's a
	  reasonable idea.  I'm trying to get a list of IP blocks for
	  all groups on Internet2 from the 'Net2 people themselves.
	  Then I thought of another thing.  Can it be done within the
	  same host?  Could I do a allow, deny for both groups within
	  the same host--one of them gets the good speeds, the other
	  gets limited?  How?  Would it be better to create an
	  internet2 user on my system that 'Net2 people could login in
	  with and then have it check to see if they really are 'Net2
	  people (according to the IP block)?  I'm having trouble
	  deciding what to try and/or which to use.  Any thoughts or
	  advice?  LinuxPPC 2000 will be coming out this weekend and
	  will be hosted by me.  I need to get something in place
	  before that happens.</para>

	<example>
	  <title>Rate limiting</title>
<programlisting>
&lt;Anonymous ~ftp&gt;
    # ...etc....
        RateWriteBPS                    16384           # all writes at max 16K/s
        &lt;Directory slow&gt;
                RateReadBPS             1024            # 1K/s max
                RateReadFreeBytes       64000           # less than 64KB at full speed
                RateReadHardBPS         on              # after 64KB xfer _forced_ down to 1K/s
        &lt;/Directory&gt;
        &lt;Directory pub/win95&gt;
                RateReadBPS             8192            # 8K/s max
                RateReadFreeBytes       256000          # until 256KB files at full speed, then 8K/s
        &lt;/Directory&gt;
&lt;/Anonymous&gt;
</programlisting>
	  </example>
	  <para>And a comment: if the normal cases one should not use
	  "RateReadHardBPS on", it is cruel to the users. :)</para>

	  <para>I'm currently running 1.2.0pre10 in inetd mode, and
	  the RateReadBPS directive works well for users who are
	  individually defined within my proftpd.conf.  However, I
	  would like to restrict total outgoing FTP bandwidth, and it
	  looks like this should be possible with RateReadBPS.
	  &gt;From section 6.16 of the FAQ:
</para><para>
"To achieve a total limit on a per virtual basis a mix of RateReadBPS and
MaxClients is needed. ie RateReadBPS x MaxClients = Total
Bandwidth allocation. There is no way (at the moment) to specify that
virtual server xyz has a maximum total bandwidth of 200K/s
that it can use between all connections."
</para><para>

A section of my proftpd.conf might look like this:

&lt;Global&gt;
 MaxClients     6
 RateReadBPS    10000
&lt;/Global&gt;

It looks like total bandwidth should be limited to ~60 KB/s (after
restarting inetd).  However, this is not the case.  Any suggestions?

</para><para>

On Mon, Feb 28, 2000 at 05:22:12PM -0500, dboyles@r75h121.res.gatech.edu wrote:
&gt; "To achieve a total limit on a per virtual basis a mix of RateReadBPS and
&gt; MaxClients is needed. ie RateReadBPS x MaxClients = Total
&gt; Bandwidth allocation. There is no way (at the moment) to specify that
&gt; virtual server xyz has a maximum total bandwidth of 200K/s
&gt; that it can use between all connections."
&gt; 
&gt; A section of my proftpd.conf might look like this:
&gt; 
&gt; &lt;Global&gt;
&gt;  MaxClients     6
&gt;  RateReadBPS    10000
&gt; &lt;/Global&gt;
&gt; 
&gt; It looks like total bandwidth should be limited to ~60 KB/s (after
&gt; restarting inetd).  However, this is not the case.  Any suggestions?

	inetd (with or without tcpd) may be the problem. Try running
	proftpd in standalone mode as a single daemon.
</para><para>

Hi,
    I'm having a problem getting the RateReadBPS limit to work.  I've =
put it in the 'global', in the 'directory' and in the body.  No matter =
where I put it, it doesn't seem to work.  Can someone please give me an =
example, or something?  This is not an anon site, and my users all have =
different logins, but go to the same dir tree, where they are jailed.
</para><para>

Thanx!!

ServerType                      inetd
DisplayConnect                  /home/ftp/.ftpmess=20
DefaultServer                   on
maxclients                      22 "Sorry, max number of users has been =
reached"
maxclientsperhost               1 "Sorry, only 1 connection per user is =
allowed"
Group                           ftp
User                            ftp
AllowStoreRestart               on

ExtendedLog /var/log/ftp.log    all=20
LogFormat                       default "%h %l %u %t \"%r\" %s %b"
Umask                           0000

TimeoutNoTransfer 600
TimeoutIdle 600
TimeoutStalled 600
AccessGrantMsg                  "User access granted for %u."

&lt;Global&gt;
        &lt;Limit LOGIN&gt;
                AllowGroup ftp
        &lt;/Limit&gt;
        DefaultRoot                     /home/ftp
&lt;/Global&gt;
&lt;Directory /*&gt;
  AllowOverwrite                off
&lt;/Directory&gt;

</para><para>

    I'm having a problem getting the RateReadBPS limit to work.  I've =
put it in the 'global', in the 'directory' and in the body.  No matter =
where I put it, it doesn't seem to work.  Can someone please give me an =
example, or something?  This is not an anon site, and my users all have =
different logins, but go to the same dir tree, where they are jailed.
</para><para>

Thanx!!

ServerType                      inetd
DisplayConnect                  /home/ftp/.ftpmess=20
DefaultServer                   on
maxclients                      22 "Sorry, max number of users has been =
reached"
maxclientsperhost               1 "Sorry, only 1 connection per user is =
allowed"
Group                           ftp
User                            ftp
AllowStoreRestart               on

ExtendedLog /var/log/ftp.log    all=20
LogFormat                       default "%h %l %u %t \"%r\" %s %b"
Umask                           0000

TimeoutNoTransfer 600
TimeoutIdle 600
TimeoutStalled 600
AccessGrantMsg                  "User access granted for %u."

&lt;Global&gt;
        &lt;Limit LOGIN&gt;
                AllowGroup ftp
        &lt;/Limit&gt;
        DefaultRoot                     /home/ftp
&lt;/Global&gt;
&lt;Directory /*&gt;
  AllowOverwrite                off
&lt;/Directory&gt;
</para><para>



"Doesn't work" simply means that proftpd acts
as if there were no RateReadBPS lines in the
config file. To say in other words: the download
xfer rate is the speed of the LAN independently
of the login type (user or anonymous) and of
the number behind the RateReadBPS directive.
A very intersting thing: the download time is
very high when running the proftpd with the "-n -d 5"
switches. In this case the download xfer rate is
constant: 0.71 kBytes/sec, and it's independent
of the RateReadBPS setting, and the download is
performed in the following way: one block is
transmitted, then there is a 5-minute-wait-state,
then the rest of the file is transmitted at the
speed of the LAN, instead of waiting smaller
amounts of time between blocks of transfers.

</para><para>

# This is a basic ProFTPD configuration file (rename it to=20
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

ServerName			"ProFTPD Default Installation"
ServerType			inetd
DefaultServer			on

# Port 21 is the standard FTP port.
Port				21
# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask				022

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances			32
MaxClientsPerHost 1 "The client number trying to connect from the same ho=
st
is limited to 1!"
TimeoutStalled			600

# Set the user and group that the server normally runs at.
User				nobody
Group				nobody
AuthUserFile			/etc/passwd

# Normally, we want files to be overwriteable.
&lt;Directory /*&gt;
  AllowOverwrite		on
&lt;/Directory&gt;

# A basic anonymous configuration, no upload directories.
&lt;Anonymous ~ftp&gt;
  User				ftp
  Group				ftp
  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias			anonymous ftp

  # Limit the maximum number of anonymous logins
  MaxClients			4
  RateReadBPS			8192

  # We want 'welcome.msg' displayed at login, and '.message' displayed
  # in each newly chdired directory.
  DisplayLogin			welcome.msg
  DisplayFirstChdir		.message

  # Limit WRITE everywhere in the anonymous choot
  &lt;Limit WRITE&gt;
    DenyAll
  &lt;/Limit&gt;

&lt;/Anonymous&gt;

</para>

<para>

I'm using RateReadBPS on a Redhat 6.0 system with pre10 RPMs and it works
fine.  I have kernel 2.2.14.

here is a snippet of my config file that limits anonymous users to 12000
kbs:
       &lt;Anonymous /somefilepath/somedir &gt;
                User ftp
                Group ftp
                UserAlias               anonymous ftp
                RateReadBPS             12000
                RequireValidShell       off
                MaxClients              15
                &lt;Limit LOGIN&gt;
                        AllowAll
                &lt;/Limit&gt;
                &lt;Limit WRITE&gt;
                        DenyAll
                &lt;/Limit&gt;
        &lt;/Anonymous&gt;

</para><para>

Does this limit each seperate anonymous user to 12000bytes D/L or all 
anonymous users as a whole?
</para>

<para>

&gt; But I really think you should consider other points ( security for example
&gt; ), and upgrade AS SOON AS POSSIBLE.
&gt;
&gt;          pre10 has MANY advantages over pre1, including built-in bandwidth
&gt; control, as you desire.
</para><para>

The reason i didnt uprgrade yet is the following:

I am a very newbie to linux. I have SuSE 6.0 installed with very little
packages selected (Almost only network things, because i only want to use
the P100/16MB Ram as a FTP-Server in text mode without graphics)

My problem is, that i'm not able to install proftp-opre10.

I know that i have to install it with RPM. I downloaded core and inetd RPMs,
but if want to install them, i get the following dependencies:
</para>


<para>


&gt; But I really think you should consider other points ( security for example
&gt; ), and upgrade AS SOON AS POSSIBLE.
&gt;
&gt;          pre10 has MANY advantages over pre1, including built-in bandwidth
&gt; control, as you desire.
</para>
<para>
The reason i didnt uprgrade yet is the following:

I am a very newbie to linux. I have SuSE 6.0 installed with very little
packages selected (Almost only network things, because i only want to use
the P100/16MB Ram as a FTP-Server in text mode without graphics)
</para><para>

My problem is, that i'm not able to install proftp-opre10.

I know that i have to install it with RPM. I downloaded core and inetd RPMs,
but if want to install them, i get the following dependencies:

pam &gt;= 0.59
fileutils
libpam.so.0
libc.so.6 (GLIBC_2.0) # I installed libc, didnt help
libc.so.6 (GLIBC_2.1)
libcrypt.so.1 (GLIBC_2.0)

Yast installs the packages without any error messages, but then the programs
wont run.

Does anyone of you have mercy and tell me where i can find those packages ?

Very big thanks in advance, Schinken
</para>
</sect2>


      </sect1>

      <sect1>
	<title>Quota controls</title>
	
	<para></para>

	<sect2>
	  <title>System Quota</title>

	  <para>The users on my Redhat 6.1 system have a disk quota
	  set for management purposes.  I would like proftpd to run
	  /usr/bin/quota right after the welcome.msg displays and/or
	  let the users run quota while logged into ftp.  Anyone know
	  of a way to do this?  I noticed that proftpd returns an
	  error after the user has exceded his hard quota, so maybe
	  the quota can be displayed without the quota program?</para>

	  <para>'fraid that's not possible, ProFTPd doesn't allow any
	  external programs to be run like "site &lt;some command&gt;"
	  and I think this includes things like this 'pre-exec' (like
	  Samba can do) also.</para>
	</sect2>

<!-- 	
<sect2>
<title>mod_quota</title>
<para>mod_quota is maintained in parallel to the main code
tree, the most recent source is generally available from 
ftp://ftp.urbanrage.com/pub/c/mod_quota.c
</para>

<para>
I'm having a problem with proftpd & mod_quota.

my configuration:

Quotas On
DefaultQuota 1048576
QuotaExempt 500,501
QuotaType hard
QuotaCalc On

The problem is that user 500 & 501 also have a 1MB Quota. Haw can I
disable Quotas on certain users ? What am I'm doing wrong 

You aren't doing anything wrong, I just coded quota exempt wrong (it was
exempting only during quota calc rather than also shutting off quotas when that
user logs in).
</para><para>

This is my fault.  I put in documentation on GroupQuota but I haven't
finished the code that supports it.  Do not use it yet, it is not implemented
(only documented).

I updated mod_quota.c to use open instead of fopen so that it could
explicitly set the permissions on the file.  It was brought to my
attention that depending on your umask the .quota file could have
permissions that could give access that you do not want to the .quota
file.

</para>
</sect2>
-->
</sect1>

<sect1>
	<title>Access controls</title>
	<sect2>
	  <title>Access Prohibitions</title>
	  
	  <para>Preventing general access to part or all of a site or
	  blocking a particular user from reading some secure
	  documents, these are all common requirements.  All these are
	  provided within the &lt;Limit> directive, this permits
	  access control based on</para>
	  
	  <itemizedlist mark=opencircle>
	    <listitem><para>User</para></listitem>
	    <listitem><para>Group</para></listitem>
	    <listitem><para>Source IP</para></listitem>
	    <listitem><para>Source Network (netmask or CIDR)</para></listitem>
	  </itemizedlist>
	</sect2>

	<sect2>
	  <title>Limiting the network resources</title>
	  
	  <para>Bandwidth limiting, this cannot be done on a per
	  server or per VirtualHost basis, there are development plans
	  to try and implement this but within the current
	  architechure it is impossible.</para>

	  <para>Limiting is only possible at the moment on a per
	  connection basis where the maximum download or upload rate
	  can be specified, in addition to this a "grace" allocation
	  can be given.  The effect of this extra allocation is to
	  effectively remove the throttling on small files which are
	  downloaded within the allocation and only throttle larger
	  files.</para>
	</sect2>

	<sect2>
	  <title>stuff</title>
	  <para>ratios, upload vs download limiting.  mod_ratio.  can
	interface with SQL to maintain state between sessions</para>
	</sect2>
      </sect1>
      
      <sect1>
	<title>Limit</title>

	<para>(Problem #1 :)

Currently I have the following:

&lt;Directory /home&gt;
        &lt;Limit LIST NLST&gt;
                DenyAll
        &lt;/Limit&gt;
&lt;/Directory&gt;

&lt;Directory /home/*/&gt;
        &lt;Limit LIST NLST&gt;
                AllowAll
        &lt;/Limit&gt;
&lt;/Directory&gt;

What I mean it to do is permit /home to be listed in /, not permit the
contents of /home to be listed, permit ppl to cd into the directories
of /home and for people to be able to list the contents of the home
dirs themselves.

This ALMOST works except:

1. When in a home dir, NLST does not work. It's as if the second
   &lt;Directory&gt; never got read. Am I misusing the wildcard? I can't
   think of any other way of denying LIST and NLST access to just
   -ONE- directory level...
2. Doing something like: LIST -d ***** in /home circumvents the limit
   and permits listing of /home

Main reason I have for blocking this is that /home contains 10,000+ dirs
and listing this tends to suck CPU LOTS and ofcourse most people happen
to use graphical browsers and then they get lost and so on...

Problem #1.1:

Actually, looking at the top list, LIST -d ***** has caused the server
to spin out. It's currently sucking cpu like mad even though I've 
disconnected and quite the ftp client. This is obviously bad as it could
make a system's load skyrocket to the point of unusability and therefore
be a nice DoS attack.

Problem #2 :)

I have 1 user who cannot log in. We are using pam authentication and
even if I just put pam_permit for the auth block it still denies him
access. I've checked his shell (/bin/sh) and it's in /etc/shells. I
can log in as him with telnet using a similar auth sequence as 
proftpd (pam). Can anyone think of what might be causing this/I might
want to look for?

I have no limits on logging in in the proftpd.conf. Just &lt;Directory&gt;
based limits on reading and writing and listing.

I run Proftpd 1.2pre7 in a glibc 2.1.1 system and have compiled it
with gcc 2.95.1 on Linux 2.2.12. linux capabilities, pam and readme
modules compiled in.

</para>
</sect1>



<sect1>
<title>mod_ratio</title>
<para>


   To install, copy this file into modules/ and do:

      ./configure --with-modules=mod_ratio

   This module is inactive unless configured, which can be done with
   an Anonymous, Directory, or VirtualHost block in proftpd.conf, or
   with a .ftpaccess file.  (Ratios must be turned on elsewhere for a
   directive in .ftpaccess to take effect.)

   If compiled with -DMOD_MYSQL_RATIOS, this module can get and set
   session stats using mod_mysql, so the only directive needed is
   "Ratios on".  This acts like a weak "UserRatio" -- any directive
   described below can override it.  It also makes multiple concurrent
   uploads/downloads possible, with persistent credits.  See mod_mysql
   docs for setup details.

   Most ratio directives take four numbers: file ratio, initial file
   credit, byte ratio, and initial byte credit.  Setting either ratio
   to 0 disables that check:

     FooRatio bar [frate] [fcred] [brate] [bcred]
      
   The directives are HostRatio (matches FQDN -- wildcards are allowed
   in this one), AnonRatio (matches password entered in an anon login,
   usually an email address), UserRatio (accepts "*" for 'any user'),
   and GroupRatio.  Matches are looked for in that order.

   Some examples:

     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 billg@microsoft.com 1 0 1 0        # 1:1 ratio, no credits
     UserRatio * 5 5 5 50000                      # special default case

     FileRatioErrMsg "Come on you can send more files than that...."
     ByteRatioErrMsg "This file is %i big, you know...."
     LeechRatioMsg "Access: Unlimited"

   Setting "Ratios on" without configuring anything else will enable
   leech mode: it logs activity and sends status messages to the ftp
   client, but doesn't restrict traffic.

   Ratio module activity is recorded to syslog at DEBUG0; it usually
   shows up in /var/log/debug, like this:

      foo in /: CWD /teen :-15/3450 +0/0 (my 5 15 5 150000) =0/146550 [NO F]

   This example is for someone who (1) has downloaded 15 files
   totalling 3450k, (2) has uploaded nothing, (3) has a ratio of 5:1
   files and 15:1 bytes, (4) has 0 files and 146k credit remaining,
   (5) got the ratio from the MySQL record ("my") and (6) is changing
   directory from / to /teen.

   Note that if this module is turned on globally, any user can create
   a personal ratio area with a .ftpaccess file.  One way to prevent
   this is with: PathDenyFilter "\.ftpaccess$"

   The authors of this module, this ProFTPD software, and this OS and
   kernel disclaim all warranties and are not responsible for what
   random users of this module may do.

   If you have ideas on how to improve this module, please
   contact</para>
      </sect1>

<sect1>
<title>Controlling permission changes</title>

<Para>
By default proftpd does not allow the client to change the system
permissions of any file, this behaviour can be overridden using the
AllowChmod directive.  This directive is valid in the server,
VirtualHost and Directory contexts allowing a fine grained control
over the connecting clients.  
</para>

</sect1>

<sect1>
<title>.ftpaccess files</title> 

<para>The .ftpaccess file is used to give a measure of control to the
individual administrator of each VirtualHost without having to disturb
the sysadmin everytime a change is required.  Each .ftpaccess file can
be considered to be a 'floating' section of the &lt;Directory&gt;
configuration block.</para>

<para>The file uses the same structure as the main daemon
configuration, though there are a significant number of directives
which have no meaning within the .ftpacess context.</para>

<example>
<title>.ftpaccess file</title>
<programlisting>
#
# Simple .ftpaccess file to control which IPs
# can access this directory structure
#
&lt;Limit&gt;
	Allow 212.32.5.0/26
	Allow 158.152.0.0/16
	DenyAll
&lt;/Limit&gt;
#
# end
#
</programlisting>
</example>

<para>There is no way to disable the use of .ftpaccess files, however
for servers with no shell access a simple file filter which blocks
.ftpaccess should suffice to prevent users from using the
functionality.  There are also implications for letting untrained and
inexperienced end users from generating their own files as they may
lock themselves out of their space or leave it less secure than they
intend.</para>

</sect1>
</chapter>

<chapter id="debugging">
<?dbhtml filename="debugging-problems.html">
<title>Debugging Problems</title>
<authorblurb>
<para>Originally by TJ Saunders</para>
</authorblurb>

<para>Users of ProFTPD will often encounters problems. It happens with
all software, not just ProFTPD. How, then, does the user track down
the cause of the problem, and fix it? This is the art of
debugging. When users post these problems are the mailing lists, it is
extremely helpful to include the following bits of information to help
find the answer. Even better is when the user follows these steps and
determines the solution for themselves.</para>

<sect1>
<title>Know the version</title>

<para>Various problems afflict various versions of the code, so when tracking down problems, it is good to know the version being used:</para>

<screen>
proftpd -vv
</screen>

<para>It is possible that the problem you are encountering is due to some bug that may already be fixed in a more current version, fixed in the CVS repository, or has a bug report with an attached patch. Searching http://bugs.proftpd.org will often yield useful information, depending on the keywords used in the search.</para>
</sect1>
<sect1>

<title>Know the modules</title>

<para>System administrators who compile and install the server from
the souce code distribution will probably already know this, but
administrators who install using RPMs or other package formats may not
know the specifics of the contained pre-built binary. To list the
modules compiled into the server:</para> 

<screen>
proftpd -l
</screen>

<para>Knowing the modules helps to pinpoint the source of error
messages (e.g. mod_tls and certificate files).</para> 

</sect1>

<sect1>
<title>Perform syntax checks</title>

<para>When making changes to the configuration file, it is often
helpful to make sure that your changes are valid. The easiest way to
do this is to do an informative syntax check:</para> 

<screen>
proftpd -td5
</screen>

<para>The -t option directs the server to parse the configuration file
but stop before actually starting its operations as a server. The -d5
will cause the server to display debugging messages during this
testing of the configuration file. Another useful command is:</para> 

<screen>
proftpd -c /path/to/new/config/file -td5
</screen>

<para>which lets you test the syntax of some new configuration file
before it is put into production.</para> 

</sect1>

<sect1>
<title>Common problems</title>

<para>One common question is: "I changed the configuration file, but
the new configuration is not being seen!" The solution depends on your
configured ServerType. Almost certainly it will be standalone, as
inetd-mode servers pick up configuration changes almost instantly (the
server is started from the ground up for each connection). For
configuration changes to be seen by a standalone server, you need to
either stop, then start the server (the hard way), or to send the HUP
signal the the daemon process.</para> 

<para>Another common question involves use of ProFTPD's &lt;Limit&gt;
directive to restrict certain FTP commands. These limits always
function in addition to the normal filesystem permissions, not instead
of them. If having problems writing, deleting, or updating files,
check your directory and file permissions first.</para>

</sect1>

<sect1>
<title>Locate log files</title>

<para>A common response on the mailing lists to a posted question is:
"What do your server logs say?" Locating the server's log files can be
troublesome, depending on your configuration. If the SystemLog
configuration directive is in effect, you know exactly where the
server's log file is. If not, then by default the server uses syslog
for logging. The location of syslog'd log files is set in your
system's /etc/syslog.conf file. You may need to read your system's man
pages for syslog.conf or syslogd to understand the format of that
file. Note that the server will log using a syslog facility of daemon
for most of its messages; during authentication, messages are logged
using the authpriv facility.</para>
</sect1>

<sect1>
<title>Collect debug information</title>

<para>The code has built-in debug information reporting capabilities -
the trick is in enabling that reporting, and tracking down where it is
sent. The easiest way to get the debugging information is to start the
server from the command line using:</para> 

<screen>proftpd -nd5</screen>

<para>This will display lots of information on the connected
terminal's screen, both as the server starts up and during the
servicing of any clients. If clients are having trouble logging in or
authenticating, the debug messages reported by the server when a
client connects are much more useful than knowing the messages
displayed by the client, as the client does not know why it cannot log
in. If asked to send debugging information to the mailing list, you
can send the relevant snippets (if you know what the relevant debug
messages are), or you can capture the debug output to a file:</para> 

<screen>
proftpd -nd5 2>&1 >& /path/to/debug/file
</screen>

<para>and send that file, compressed, along with your post.</para>

<para>The above method works if you have ServerType standalone in your
configuration file. If you run the server in inetd mode instead, and
are unable or unwilling to make the changes necessary to run the
server in standalone mode for the sake of debugging, then use of the
SystemLog configuration directive is necessary for capturing the debug
information. Add this directive to your configuration file, and add
-d5 to your /etc/inetd.conf's ftp line, or to the server_args tag in
your xinetd configuration file for the server. Be sure to restart
inetd/xinetd so that your configuration changes will take
effect.</para>

<para>Note that use of the SystemLog directive is not necessarily
confined to inetd mode servers. If you are interested in letting your
standalone server run unattended and want to have that debugging
information in the log file, use SystemLog and add -d5 (or whatever
your preferred debug level is) to the server startup script.</para> 

<para>Once you have the debug output and various other information,
and are still in need of help, search the FAQ, Userguide, and mailing
list archives for material related to the problem. If you're unable to
find anything helpful in these sources, post your question to the
appropriate mailing list. Be sure to include the version used, your
proftpd.conf, and possibly any debug information.</para> 

<para>The following document describes how to ask good questions that
are likely to be answered:</para>

<screen>
http://www.tuxedo.org/~esr/faqs/smart-questions.html
</screen>
</sect1>


</chapter>

<chapter id="troubleshoot">
<title>Common Problems</title>

<sect1>
<title></title>
   
<sect2>
<title>"inet_create_connection() failed: Operation not permitted".
</title>

<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>
</sect2>

<sect2>
<title>"bind: unable to bind to port"</title>

<para>
Proftpd is unable to take control of port 21 (or whatever port has
been defined) at startup.  This is normally down to one of two
reasons.
</para>

<sect3>
<title>Clash with inetd</title>
<para>
Proftpd has been configured to in standalone mode but inetd hasn't
been reconfigured to not provide the ftp service.  Ensure that
the line starting with "ftp" has been removed or commented out and
send a SIGHUP to the inetd process.
</para>
</sect3>

<sect3>
<title>Another copy of Proftpd is running</title>
<para>
Check the process listing for the server to ensure that another
proftpd process is not already running.  If it is either kill this
process or send the master daemon a SIGHUP to make it reload it's
configuration if desired.
</para>
</sect3>
</sect2>

<sect2>
<title>"Fatal: Socket operation on non-socket"</title>

<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>

<screen>
ServerType standalone
</screen>
</sect2>

<sect2>
<title>I'm having problems with FTP clients behind firewalls</title>

<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>

<sect3><title>non-Passive
</title>
<para>The server end of the data socket uses port 20.  This is nice and
easy to work into a firewall configuration.</para>
</sect3>

<sect3><title>Passive
</title>
<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>
</sect3>
</sect2>

<sect2>
<title>Can I run more that one VirtualHost on a single IP?</title>

<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>
</sect2>

<sect2>
<title>Is there anything in the pipeline to fix this?</title>

<para>There is a draft standard
http://search.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-07.txt
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>
</sect2>

<sect2><title>
How do I run ProFTPD from inetd?
</title>

<para>Find the line in /etc/inetd.conf that looks something like this:
<quote>   ftp stream tcp nowait root in.ftpd in.ftpd</quote>
</para>
<para>Replace it with:
<quote>   ftp stream tcp nowait root in.proftpd in.proftpd</quote>
</para>

<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>
</sect2>

<sect2><title>Can I use tcp-wrappers with ProFTPD?
</title>
<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>
</sect2>

<sect2>
<title>Can I run an FTP server on a non-standard port?
</title>

<para>Yes. Use a &lt;VirtualHost&gt; block with your machine's FQDN
(Fully Qualified Domain Name) or IP address, and a Port directive
inside the &lt;VirtualHost&gt; 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:



...
&lt;VirtualHost myhost.mydomain.com&gt;
Port 2001
...
&lt;/VirtualHost&gt;
</para>
</sect2>

<sect2>
<title>Can control upload/download ratios?
</title>
<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 billg@microsoft.com 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>
</sect2>

<sect2>
<title>Limitations of mod_ratio
</title>

<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>
</sect2>

	<sect2>
	  <title>Slow logins</title>

	  <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: UseReverseDNS off
	  IdentLookups off</para>
	</sect2>


	<sect2>
	  <title>Lots of "FTP session closed" messages</title>

	<para></para>

<screen>
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.
</screen>


	  <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>
        </sect2>
	<sect2>
	  <title>How do I see who is connected?</title>

	  <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>
	</sect2>

	<sect2>
	  <title>Can I force ProFTPD to listen on only one IP?</title>

	  <para>Sort, of it's not quite as clean as the socket binding
	  under Apache but the principle works something like
	  this.</para>
	</sect2>

<sect2>
<title>Standalone mode
</title>
<para>
To listen on the primary IP of a host
Use the SocketBindTight directive

To listen on a interfaces which are not the primary host interface

Use the SocketBindTight directive, place your server configuration in
a &lt;VirtualHost ftp.mydomain.com&gt; block and use "Port 0" for the
main host configuration and and "Port 21" inside the VirtualHost
block.</para>
</sect2>
<sect2><title>inetd</title>

<para>There are two approaches possible, the first is to use the patch
from Daniel Roesen &lt;droesen@entire-systems.com&gt; (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>

<example>
<title>xinetd configuration</title>
<programlisting>
service ftp
{
        flags           = REUSE
        socket_type     = stream
        instances       = 50
        wait            = no
        user            = root
        server          = /usr/sbin/proftpd
        bind            = &lt;the-ip-you-wish-to-bind-to&gt;
        log_on_success  = HOST PID
        log_on_failure  = HOST RECORD
}
</programlisting>
</example>
</sect2>

<sect2>
<title>How do I shutdown the server without killing proftpd?
</title>
<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>

<sect3>
<title>Is is possible to shutdown a single VirtualHost?
</title>

<para>No, the shutmsg file works at a daemon level not at a virtual host
level.</para>
</sect3>
</sect2>

<sect2>
<title>Unable to resolve IP</title>

<para>This is not normally a problem with proftpd, but with the
configuration of the hosting server or the DNS servers it relies
on. The error message simply means the daemon was unable to map the
hostname given in the configuration to an IP address.  Check the
/etc/resolv.conf (or equivalent) and the spelling of the hostname in
the proftpd.conf file, also try tools such as nslookup to check the
behaviour of the local DNS servers.</para>

</sect2>

</sect1>

</chapter>


<chapter id="complex">
<title>More complex Configuration Issues</title>

<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>


<sect1>
<title>How can I stop my users from using their space as a warez repository
</title>

<para>The above fragment will control anonymous users however if a local
user with a full account with up and download capability is abusing
their space then the technical measures which can be taken are
limited.  Applying a sane system quota is a good start, using the
mod_quotatab and mod_ratio modules may control the rates of
upload/download making it less useful as a warez repository.  In the
end it comes down to system monitoring and good site AUP's and
enforcement.</para>
</sect1>

<sect1>
<title>Can I rotate files out of an upload directory after upload?
</title>

<para>Yes.  You'll need to write a script which either checks the
contents of the directory regularly and moves once it's detected no
size change in a file for xyz seconds.  Or a script which monitors an
upload log.  There is no automatic method for doing this.</para>
</sect1>

<sect1>
<title>How can I hide a directory from anonymous clients.
</title>

<para>Use the HideUser or HideGroup directive in combination with the
proper user/group ownership on the directive. For example, if you
have the follow directory in your anonymous ftp directory tree:

	drwxrwxr-x 3 ftp staff 6144 Apr 21 16:40 private
</para>

<para>You can use a directive such as "HideGroup staff" to hide the private
directory from a directory listing. For example:


&lt;Anonymous ~ftp&gt;
...
&lt;Directory Private&gt;
HideGroup staff
&lt;/Directory&gt;
...
&lt;/Anonymous&gt;
</para>
</sect1>
<sect1>
<title>
File/Directory hiding isn't working for me! 
</title>
<para>
You need to make sure that the group you are hiding isn't the
anonymous ftp user's primary group, or HideGroup won't apply.</para>
</sect1>

<sect1>
<title>I want to prevent users from accessing a hidden directory
</title>

<para>You can either change the permissions on the directory to prevent
the anonymous FTP user from accessing it, or if you want to make it
appear completely invisible (as though there is no such directory),
use the IgnoreHidden directive inside a &lt;Limit&gt; block for one or
more commands that you want to completely ignore the hidden directory
entries (ignore = act as if the directory entry does not exist).
</para>
</sect1>
<sect1>
<title>How do I setup a virtual FTP server?
</title>

<para>You'll need to configure your host to be able to handle multiple IP
addresses. This is often called "aliasing", and can generally be
configured through an IP alias or dummy interface. You need to read
your operating system documentation to figure out how to do this. Once
your have the host configured to accept the additional IP address that
you wish to offer a virtual FTP server on, use the &lt;VirtualHost&gt;
configuration directive to create the virtual server:


&lt;VirtualHost 10.0.0.1&gt;
ServerName "My virtual FTP server"
&lt;/VirtualHost&gt;

</para>
<para>You can add additional directive blocks into the
&lt;VirtualHost&gt; block in order to create anonymous/guest logins
and the like which are only available on the virtual host.</para>
</sect1>


<sect1>
<title>How does &lt;Limit LOGIN&gt; work, and where should I use it?
</title>

<para>The &lt;LOGIN&gt; directive is used to control connection or login
access to a particular context (the directive block which contains
it). When a client initially connects to ProFTPD, the daemon searches
the configuration tree for &lt;Limit LOGIN&gt; directives, and
attached parameters (such as Allow, Deny, etc). If it determines that
there is no possible way for the client to ever be allowed to login,
such as a "Deny from" matching the client's source address, without an
overriding "Allow from" at a lower level, the client is disconnected
without being offered the opportunity to transmit a user and password.
</para>

<para>However, if it is possible for the client to be allowed a login,
ProFTPD continues as per normal, allowing the client to login only if
the proper &lt;Limit LOGIN&gt; applies. Normally, &lt;Limit&gt; directive blocks
are allowed in the server config, &lt;VirtualHost&gt;, &lt;Anonymous&gt;
and &lt;Directory&gt; contexts. However, &lt;Limit LOGIN&gt; should not be
used in a &lt;Directory&gt; context, as clients do not connect/login to a
directory (and thus it is meaningless).
</para>

<para>By way of example, the following configuration snippet illustrates a
&lt;Limit LOGIN&gt; deny which will cause any incoming connections from the
10.1.1.x subnet to be immediately disconnected, without a welcome
message:


...
&lt;Limit LOGIN&gt;
Order deny,allow
Deny from 10.1.1.
Allow from all
&lt;/Limit&gt;
...
</para>

<para>Next, an example of a configuration using &lt;Limit LOGIN&gt; that will not
immediately disconnect an incoming client, but will return "Login
invalid" for all login attempts except anonymous.


...
&lt;Limit LOGIN&gt;
DenyAll
&lt;/Limit&gt;
&lt;Anonymous ~ftp&gt;
...
&lt;Limit LOGIN&gt;
AllowAll
&lt;/Limit&gt;
...
</para>
</sect1>

    </chapter>









<chapter id="advconfig-nonroot">
<?dbhtml filename="advconfig-nonroot.html">
<title>Running ProFTPD As A Nonroot User</title>
<authorblurb>
<para>
Chapter by TJ Saunders
</para>
</authorblurb>

<para>Occasionally, one might want to run ProFTPD on a system where
root privs are not available to you as a user. It is still possible to
setup a functioning FTP server without root privileges. There are a
few catches and special considerations for this, however.</para>

<para>Here are the configuration directives that you will need to use in
order to run the server without root privileges:</para>

<variablelist>
<varlistentry>
<term>Port</term>
<listitem>
<para>This needs to be a number greater than 1023. Lower number ports
require root privileges in order for the process to bind to that
address. This will also mean that clients wishing to contact your
server will need to know the port on which it is listening. Most FTP
clients connect to the standard FTP port (21).</para> 
</listitem>
</varlistentry>

<varlistentry>
<term>AuthUserFile, AuthGroupFile</term>
<listitem>

<para>In order to authenticate users, by default the server looks in
/etc/passwd for account information, and in /etc/shadow for the
password. Comparing stored passwords requires root privileges, which
this nonroot-running daemon will not have. You can get around this
requirement by supplying your own passwd (and possibly group) files
via the AuthUserFile and AuthGroupFile directives. Make sure the
permissions on your custom files allow for the daemon to read them
(but hopefully not other users).</para>

</listitem>
</varlistentry>

<varlistentry>
<term>AuthPAM</term>
<listitem>
<para>PAM authentication requires root privileges. This directive will need to be set off.</para>
</listitem>
</varlistentry>

<varlistentry>
<term>WtmpLog</term>
<listitem>
<para>
Logging to wtmp files requires root privileges. While it is not strictly necessary for this directive to be set to off, failure to do so will result in server log messages like:
</para>

<screen>
host.domain.net (localhost[127.0.0.1]) - wtmpx /var/adm/wtmpx: Permission denied
</screen>
</listitem>
</varlistentry>

<varlistentry>
<term>User, Group</term>
<listitem>
<para>The ability to switch the identity of the server process to
those configured by the User and Group directives requires, of course,
root privileges. It is best to configure User to be your username, and
Group to be the name of your primary group (which is usually the first
group listed by the groups command).</para> 
</listitem>
</varlistentry>


</variablelist>

<para>Note that other configuration directives will be affected by the
lack of root privileges: DefaultRoot will not work, nor will
&lt;Anonymous&gt; sections, nor UserOwner. Basically any operation
that requires root privileges will be disabled.</para>
</chapter>


  </part>

  <part id="workingstuff">
    <?dbhtml filename="part_working.html">
    <title>WorkShop</title>

    <article>
    <para>This is primarily cut and paste from the mailing list to get
    the text into my working files.  Once this is done I can look at
    starting to clean up the information into the user guide
    proper</para>
    </article>
    
    <chapter>
      <?dnhtml filename="chap_cleaned.html">
      <title>Cleaned sections</title>
      <sect1>
	<title>Cleaned - part A</title>

	<sect2>
	  <title>Filtering upload/download paths</title>

	  <para>There are occasions when it is desirable or essential
	  that access to certain files or paths is limited, or that
	  steps are taken to prevent uploading of certain kinds of
	  material.  The most common method of achieving these ends is
	  to use the PathAllowFilter and PathDenyFilter
	  directives.</para>

	  <example>
	    <title>Filter example</title>
	    <programlisting>
#
# Block alteration of .ftpaccess
# Prevent uploading of mp3 files.
#
PathDenyFilter "(^\.ftpaccess$)|(\.mp3$)"
	    </programlisting>
	  </example>
	</sect2>

	<sect2>
	  <title>File overwriting</title>
	  <para>The default configuration of the daemon prevents the
	  overwriting of files on the server.  To disable this
	  behaviour set "AllowOverwrite 1"</para>
	</sect2>

	<sect2>
	  <title>Logs report 'signal 11'</title>

	  <para>If 'ProFTPD terminating (signal 11) appears in your
	    logs it's an indication that there is a serious problem
	    with your insallation.  A signal 11 (or SEGV) is a
	    segmentation fault, usually caused by either incompatible
	    libraries or a bug in the daemon.  If recompiling from
	    a clean source distribution doesn't resolve the problem
	    it's probably worth reporting it as a bug.</para>
	</sect2>

	<sect2>
	  <title>Unknown group errors</title>

	  <para>A very simple problem, with an equally simple
	    solution.  Proftpd requires that a user and group are
	    specified for it to run the daemon as after a sucessful
	    login.  These names are resolved to their numeric values
	    by the appropriate system calls when the configuration is
	    loaded or tested (using the -t option).  Failure of these
	    to resolve is a non-recoverable solution and is almost
	    always caused by the group not existing in the appropriate
	    user directory (ie /etc/passwd or /etc/shadow).</para>

	  <para>The solution is to either create the user/group
	    account or to reconfigure Proftpd to use another
	    user/group account.  Which of these is the best solution
	    will depend on your local conditions.  The user Proftpd
	    runs as does not require a valid password or a usable
	    shell (/bin/true will suffice).</para>
	</sect2>

      </sect1>

<sect1>
<title>proftpd.filter</title>
<para>

Hi, there:

 I tried to setup proftpd.conf with allowFilter
in the proftpd.conf
#======
ServerName			mumble
ServerType              inetd
DeferWelcome            on
Umask                   002
User                    proftpd
Group                   proftpd
TransferLog             /var/log/proftpd/xferlog.log
DefaultRoot             ~ users,!staff
TimeoutLogin            120
TimeoutIdle             600
TimeoutNoTransfer       900
TimeoutStalled          3600
ScoreboardFile          /var/run/proftpd
LogFormat               default "%h %l %u %t\"%r\" %s %b"
LogFormat               auth "%v[%P] %h %t \"%r\" %s"
LogFormat               write "%h %l %u %t \"%r\" %s %b"
UseReverseDNS           off
AllowFilter ".*/[a-zA-Z0-9 ]+$"
#==========
When I tried to login at username after I hit enter, I got
"Forbidden command argument". I am using 1.2.0pre9.

Any ideas, After I marked AllowFilter out, everything is fine.
I tried to use Allowfilter too but couldn't get it to work no matter what I 
tried.  I ended up adding a denyfilter "%" instead.

----Original Message Follows----
From: "michael liu" &lt;mliu@rmsys.net&gt;
Reply-To: proftpd@proftpd.org
To: "Proftpd@Proftpd. Net" &lt;proftpd@proftpd.org&gt;
Subject: [ProFTPD] allowFilter
Date: Fri, 7 Apr 2000 17:40:29 -0500

Hi, there:

  I tried to setup proftpd.conf with allowFilter
in the proftpd.conf
#======
ServerName			mumble
ServerType              inetd
DeferWelcome            on
Umask                   002
User                    proftpd
Group                   proftpd
TransferLog             /var/log/proftpd/xferlog.log
DefaultRoot             ~ users,!staff
TimeoutLogin            120
TimeoutIdle             600
TimeoutNoTransfer       900
TimeoutStalled          3600
ScoreboardFile          /var/run/proftpd
LogFormat               default "%h %l %u %t\"%r\" %s %b"
LogFormat               auth "%v[%P] %h %t \"%r\" %s"
LogFormat               write "%h %l %u %t \"%r\" %s %b"
UseReverseDNS           off
AllowFilter ".*/[a-zA-Z0-9 ]+$"
#==========
When I tried to login at username after I hit enter, I got
"Forbidden command argument". I am using 1.2.0pre9.

Any ideas, After I marked AllowFilter out, everything is fine.

Anyone know a good string for AllowFilter?

I tried the one in the docs on www.proftpd.org but then every command is 
invalid.

i'm using 1.2.0pre8 on redhat 6.1.  i have sucessfully used the
PathDenyFilter in the &lt;Global&gt; section with the example:

PathDenyFilter	      "(\.ftpaccess)|(\.htaccess)$"

now i am trying to limit commands with DenyFilter.  i admit to not
understanding regular expressions, but using the above as a sort of
guide, i am still baffled.  i've tried the following variations
without success:

DenyFilter	           "proxy"
DenyFilter		   proxy
DenyFilter		   "(proxy)|(pwd)$"
DenyFilter		   "proxy$"
DenyFilter		   "(proxy)$"

if anyone could shed some light on this i would be very pleased.

1. proftpd-1.2p10 working OK.

2. Can I hidde on virtual root ftp servers FrontPage directory
   _vti_* ?

    When I add in proftpd.conf directive:

      PathDenyFilter           "(\.htaccess)|(\.ftpaccess)$"

   working OK.

 but add:

      PATHDenyFilter           "(\.htaccess)|(\.ftpaccess)|(_vti_*)$"

   directory _vti_* not hidding.

======================================================================
Wiesiek Glod              e-mail: wkg@x2.pl old wkg@halicz.com.pl
	</para>
      </sect1>
    </chapter>

    <chapter>
      <?dnhtml filename="chap_workshop.html">
      <title>Initial ponderings from the list</title>
      <sect1>
	<title>stuff_a</title>
	<para></para>

	<sect2>
		<title>showing all files</title>
	  <para>
How can i can show files starting with a "." ?
Surprisingly easy method:
LsDefaultOptions        "-a"
          </para>
	</sect2>

	<sect2>
	  <title>Setting defaults for all VirtualHosts</title>

	  <para>Many of the directives which are valid in the
	  VirtualHost context are also valid in the &lt;Global&gt;
	  context.  Proftpd will take the &lt;Global&gt; values as the
	  default but will allow them to be overridden on a
	  &lt;VirtualHost&gt; by &lt;VirtualHost&gt; basis</Para>
	</sect2>


	<sect2>
	  <title>Data connection problems</title>

	  <para>Why I get "Can't build data connection : Connection
	    refused" error when I send the list or dir commands to
	    proftpd from Windows Command prompt?

normally down to firewalls and pasv/acttive connections
> Does someone knows how to set up proftpd as a passive ftp server? I'm having trouble
+with proftp behind a firewall, upload speeds are very low.
> Could the problem be that it's running active instead of passive??

        It is not the job of the server to configure this. It is
        the client's job. Set your FTP client to use PASV.

</para>
	</sect2>

	<sect2>
	  <title>Installation</title>

	  <para>History: I need FTP server on my Linux
	  machine. Reading about it on many Linux sites i found
	  recommedations that proftpd is more secure than wuftpd, that
	  configuration is easier etc etc. OK, let's listen to more
	  expireanced linux admins and install proftpd. I found site
	  (good one), read all i could and decided that's the one,
	  let's install it.
</para><para>
1. No installation instructions.
OK, never mind, it must be peace of cake on RH6.1 with RPM's. Let's find
them. ftp://ftp.proftpd.org/pub/proftpd/RPMS/
</para><para>
2. There are 2 directories on above address: i386 and i686.
OK, i386 must be the one for my poor Pentium 133, the other one must be for
PII machines. Let's use i386 one.
</para><para>
3. 6 files in i386 directory, ...core...  ...inetd... and ...standalone...
for versions 9 and 10
OK, I want standalone version 10 so I definitely need that small 4,21 file
...  and I presume that core file for version 10 is needed as well ...
</para><para>
Too many maybe's. I am not far from giving up (wuftpd). Was it SO hard to
write few sentences describing installation issues for this case
scenario??????
</para><para>
Also, there is no mailing list archive, so I am posting this question after
reading faq and user guide.
</para><para>
Please could someone decribe me installation procedure for RH6.1 (RMP) v10
(reply to this message via e-mail)?

You need the main package: proftpd-core-1.2.0pre10-1.i386.rpm
Plus you need *either* the -inetd or -standalone package, depending upon
whether you want to start proftpd through inetd or have it run as a
standalone daemon.
</para><para>
Jim

P.S.  I encountered a problem with 1.2.0pre10 not recognizing secondary
group permissions, but skimming through the mailing list archives uncovered
a patch from MacGuyver that fixed it.
http://www.proftpd.org/proftpd-l-archive/00-01/msg00371.html

I included the patch in a revised RPM if you are interested in trying it.
http://hammer.prohosting.com/~onjapan/rpms/
| 1. No installation instructions.

Doesn't the INSTALL file count?

| Also, there is no mailing list archive, so I am posting this question after
| reading faq and user guide.

Actually, there are two in addition to the bugzilla system:

        http://www.proftpd.org/proftpd-l-archive/
        http://www.proftpd.org/proftpd-devel-archive/

| Please could someone decribe me installation procedure for RH6.1 (RMP) v10

The RPM spec file is in contrib/dist/rpm/.

All that said, I'm sure there is room for improvement.

</para>
	</sect2>

	<sect2>
	  <title>uploading issues</title>
	  <para>
how can i make two diferent users were the one can only upload in
upload_here and the other can do everything in directory ftp?

What I have so far:

User    nobody
Group    nogroup

DefaultRoot /ftp

{Directory /ftp}
 {Limit WRITE}
  Deny All
 {/Limit}
{/Directory}

{Directory /ftp/upload_here}
 {Limit CWD STOR RETR MKD RMD XCWD XMKD XRMD}
  Allow All
 {/Limit}
{/Directory}

</para>
	</sect2>
</sect1>

      <sect1>
	<title>proftpd.binding</title>

	<para>Using the default "basic.conf" file with a 1.2.0pre10
	installation on Slackware Linux 7 (2.2.14), proftpd has
	problems with all of the aliased interfaces on the box.  The
	daemon will start up and listen on port 21 on all of the
	interfaces, however if I connect to any of the aliased
	interfaces, the log shows a bind(): Permission Denied and the
	connection closes.  The primary and localhost interface will
	accept connections with no problems.  The daemon is running as
	nobody:nogroup, and those users exist on the system.
	Incedintally, if I run the daemon as root, proftpd works fine
	on ALL configured interfaces, however running the daemon as
	root is not desired.  I have had no problems running any
	versions previous to pre10 on the same machine and on other
	machines as well.


Anyone knows why am I getting this error??

Mar 13 16:44:40 gabriel proftpd[2997]: gabriel.domain.com - attempted bind
 to 0.0.0.0, port 21
Mar 13 16:44:40 gabriel proftpd[2997]: gabriel.domain.com - bind() failed
in inet_create_connection(): Address already in use
Mar 13 16:44:40 gabriel proftpd[2997]: gabriel.domain.com - Check the Serv
erType directive to ensure you are configured correctly.

I comment out the ftp in my inetd.conf.  I am using the proftpd as a
services



On Fri, 17 Dec 1999, Alderman, Sean wrote:

&gt; Just compiled and installed pre9 w/ the TYPE A N patch...  Running in
&gt; standalone mode works great...Running from inetd gives the following in
&gt; /var/log/messages -

&gt; Dec 17 15:22:51 dmz1 proftpd[7163]: dmz1.freitrater.com - bind() failed in
&gt; inet_create_connection(): Address already in use

Normally caused by one of the following

o Another proftpd running
o ftp being configured in inetd and running the daemon in standalone
o Something else listening on port 21</para>

	<para>See the SocketBindTight directive.  When off (the
	default), sockets are bound to 0.0.0.0:port.  When on,
	specific IPs are used (as specified by VirtualHost) and the
	"main" IP is guessed.  You can also use the port 0 trick to
	prevent binding the the main guessed IP.</para>
      </sect1>


      <sect1>
	<title>proftpd.auth</title>
	<para>

On Mon, Apr 03, 2000 at 06:51:49PM -0700, Irwan Hadi wrote:
&gt; Is it possible to make proftpd use it's own username + password and not use
&gt; I don't want use the system account because the more user in /etc/passwd
&gt; (system account) the more the system can be compromised.

AuthUserFile
DefaultRoot

or 

SQL/LDAP authentication 
DefaultRoot

At 14:01 06/04/2000 +0100, **hamster@vom.org.uk**, has written a message, and
here is the reply :
&gt;On Mon, Apr 03, 2000 at 06:51:49PM -0700, Irwan Hadi wrote:
&gt;AuthUserFile
&gt;DefaultRoot
&gt;
&gt;or 
&gt;
&gt;SQL/LDAP authentication 
&gt;DefaultRoot
Thanks fpr you reply, but if there is already somebody here who has done
similar like what I like, I hope that you can give the steps to me.
Because I'm in a hurry to setup the ftp server as the deadline for it is
next week.
</para>


<para>    In the basic /usr/local/etc/proftpd.conf you will need to add
this line:

AuthUserFile &lt;File path&gt;

    Where &lt;File Path&gt; is the pathname of the file to use instead of
/etc/passwd.

Note: the auth file has to have the same format as /etc/passwd.

More info:
http://www.proftpd.org/docs/configuration.html#AuthUserFile


You will probably also want to use:
AuthGroupFile &lt;File Path&gt;

    Much the same, format is the same as the /etc/group file.
More Info:
http://www.proftpd.org/docs/configuration.html#AuthGroupFile

    In the basic configuration file, you may want to comment out the
anonymous entry...

    That is the easiest way to do it... You can also use Ldap, MySQL,
but neither are for people in a rush. :-) Information on the
alternatives can be found in:
http://www.proftpd.org/docs/proftpdfaq-8.html


At 12:00 06/04/2000 -0400, Michael Grabenstein wrote:
&gt;
&gt;    In the basic /usr/local/etc/proftpd.conf you will need to add
&gt;this line:
&gt;
&gt;AuthUserFile &lt;File path&gt;
&gt;
&gt;    Where &lt;File Path&gt; is the pathname of the file to use instead of
&gt;/etc/passwd.
&gt;
&gt;Note: the auth file has to have the same format as /etc/passwd.
&gt;
&gt;More info:
&gt;http://www.proftpd.org/docs/configuration.html#AuthUserFile

First of all I want to thank you for your reply, but my question is what is
the meaning of "the same format ?"
so I make a list of
username:password::::/homedir/
how about the password ? can it be encrypted or not ?
if it *can* be encrypted, with which tool should I encrypt it then.
</para>

<para>Irwan Hadi wrote:

&gt; First of all I want to thank you for your reply, but my question is what is
&gt; the meaning of "the same format ?"
&gt; so I make a list of
&gt; username:password::::/homedir/
&gt; how about the password ? can it be encrypted or not ?
&gt; if it *can* be encrypted, with which tool should I encrypt it then.
&gt;

    Yes that would be the format...

    I use Perl to encrypt the password, or if you already have a /etc/passwd to
start with, then just copy it...

    An alternative easy way to do this is to encrypt a password and keep the
encrypted version around. Like Change your password to 'ABC123' then as you
create users in the alternate passwd file, paste the encrypted form of that
password into the new logon entry. And instruct the new user to change their
password as soon as they first FTP to the system, or change it for them via FTP
and give them the new password. :-) BTW: once you have the encrypted version of
'ABC123' feel free to change your password back. :-)

    Attached is a simple Perl script that will encrypt a plain text password sent
to it...

    Mark, please feel free to add this to the FAQ. TIA.

    I don't believe proftp has a way of using plain text passwords in the
password file, but Mark can correct me if I am wrong. :-)
</para>


<para>#--- Start Cut after this line
#!/usr/bin/perl
use Getopt::Std;
use vars qw($opt_h $opt_p $opt_s);
getopt ("hp:s:");
my ($salt);
if ( (defined($opt_h)) || (! defined($opt_p)) )
 {
   print "Usage: $0 -hps\n";
   print "\t-h -- This Usage message\n";
   print "\t-p &lt;password&gt; -- The password to encrypt\n";
   print "\t-s &lt;salt&gt; -- The salt to use, optional\n\n";
   exit (166);
 }
if ($opt_s =~ /(\w+)/)
 {
   $salt = $1;
 }
 else
  {
    $chr = chr(int(rand(26)+65));
    $salt = $chr;
    $chr = chr(int(rand(26)+97));
    $salt .= $chr;
  }
print crypt($opt_p, $salt) . "\n";
exit (0);
# -- Stop here. Don't get the signature at the bottom...
</para>

<para>&gt; First of all I want to thank you for your reply, but my question is what is
&gt; the meaning of "the same format ?"
&gt; so I make a list of
&gt; username:password::::/homedir/
&gt; how about the password ? can it be encrypted or not ?
&gt; if it *can* be encrypted, with which tool should I encrypt it then.
&gt;

    Yes that would be the format...

    I use Perl to encrypt the password, or if you already have a /etc/passwd to
start with, then just copy it...

    An alternative easy way to do this is to encrypt a password and keep the
encrypted version around. Like Change your password to 'ABC123' then as you
create users in the alternate passwd file, paste the encrypted form of that
password into the new logon entry. And instruct the new user to change their
password as soon as they first FTP to the system, or change it for them via FTP
and give them the new password. :-) BTW: once you have the encrypted version of
'ABC123' feel free to change your password back. :-)

    Attached is a simple Perl script that will encrypt a plain text password sent
to it...

    Mark, please feel free to add this to the FAQ. TIA.

    I don't believe proftp has a way of using plain text passwords in the
password file, but Mark can correct me if I am wrong. :-)

</para>

<para>#--- Start Cut after this line
#!/usr/bin/perl
use Getopt::Std;
use vars qw($opt_h $opt_p $opt_s);
getopt ("hp:s:");
my ($salt);
if ( (defined($opt_h)) || (! defined($opt_p)) )
 {
   print "Usage: $0 -hps\n";
   print "\t-h -- This Usage message\n";
   print "\t-p &lt;password&gt; -- The password to encrypt\n";
   print "\t-s &lt;salt&gt; -- The salt to use, optional\n\n";
   exit (166);
 }
if ($opt_s =~ /(\w+)/)
 {
   $salt = $1;
 }
 else
  {
    $chr = chr(int(rand(26)+65));
    $salt = $chr;
    $chr = chr(int(rand(26)+97));
    $salt .= $chr;
  }
print crypt($opt_p, $salt) . "\n";
exit (0);
# -- Stop here. Don't get the signature at the bottom...
</para>


<para>At 09:29 07/04/2000 -0400, **Michael Grabenstein**, has written a message,
and here is the reply :
&gt;Irwan Hadi wrote:
&gt;    I use Perl to encrypt the password, or if you already have a
/etc/passwd to
&gt;start with, then just copy it...

&gt;    Attached is a simple Perl script that will encrypt a plain text password 
&gt;sent
&gt;to it...

Umm, sorry to bother you again, but how about the shell of the users ?
should it be set to /bin/bash or /bin/ftponly (which is another name of
/bin/false) ?


On Tue, Apr 04, 2000 at 04:15:34PM -0700, Irwan Hadi wrote:
&gt; Umm, sorry to bother you again, but how about the shell of the users ?
&gt; should it be set to /bin/bash or /bin/ftponly (which is another name of
&gt; /bin/false) ?

The shell can be whatever you want, however it has to be in either
/etc/shells or the RequireValidShell directive has to be set to "off"


On Tue, Apr 04, 2000 at 09:17:07AM -0700, Irwan Hadi wrote:
&gt; username:password::::/homedir/
&gt; how about the password ? can it be encrypted or not ?
&gt; if it *can* be encrypted, with which tool should I encrypt it then.

Is must be crypted, there is a script in the contrib directory
(genuser.pl IIRC) to do this.</para>



<para>Hello ..

Just to clarify something for me .....  

If I use mySQL (with mySQL users) as the authentication method for users
of my proftpd server, then I will not need to add them as users in the
system password file.  

I want all users to this server to have to login, but I'd prefer not to
have to add them to the password file. 

Am I way off base on this ? or  ??

    Nope, sounds pretty correct.

    You do have to add a couple of things to the /etc/ group and passwd file, but
not all of the users.

    In /etc/passwd, you need to add a user for the user that proftpd will run
under (or use nobody...).

    In /etc/group, you need to add a group for the user that will run proftpd (or
use nobody, again...).

    Plus in /etc/group, you need the group you will be assigning to all the users
on the system. (or list of groups...)

    Then in MySQL's user table you need to have an entry for the user you will be
connecting with. The line in proftpd.conf:
MySQLInfo                     localhost hamster ABC123   proftpd

    Means you need a user in the user table of the mysql DB for user id 'hamster'
with password 'ABC123'. Also from the line above the DB name is proftpd...

    My user's don't have upload, so everything looks good. This only gets sticky
if you want your users to upload...

    When they upload the files are assigned the user id number assigned in MySQL,
but if that does not exist in /etc/passwd then 'ls' shows only the uid number. If
you make the uid number the same as a user that exists in the /etc/passwd, then
it looks normal with the added benefit of that user owning the file. :-)

    You could have a "generic" user in the /etc/passwd that can not log in and
have all MySQL user id's assigned that uid. The home directory comes form MySQL,
so they can all have different homes with no problems...

Greetings:
	I am trying to get 1.20pre10 running on Solaris 7, and,
using the basic configuration file shipped, can only log in
as anonymous (or ftp) but never an actual user of the system.
I have a shadow file (o' course) and compiled with --enable-shadow
and --enable-shadow-autodetect options .. the only changes to the
basic config file were in using inetd and, well, allowoverwrite off.
I have since added a preemptive, if unnecessary, &lt;limit login&gt; 
allowall &lt;/limit&gt; and remove the anonymous block (now I have no
ftp access, duh!).

Any ideas about what I am missing?


I have several users on my Linux system. I am trying to allow them all to
be able to have logins for FTP. For example, one customer can create the
FTP account webmaster which logs into /home/customer1/public_html with the
password poiuy, while another customer can create the FTP account
webmaster which logs into /home/customer2/public_html with the password
lkjhg. I looked through the configurations and AuthUserFile looked like
the best way to do it.

So I setup a test one. In the proftpd.conf vhost for game-guys.com, I
setup AuthUserFile /home/game-guys/game-guys. In that game-guys, I would
like to have several logins and passwords (encrypted of course) which can
only login to game-guys.com on the server.

My question is, what should go in /home/game-guys/game-guys, and how
should I add users to it and set the password? All three commands,
useradd, passwd and htpasswd don't seem to want to work properly. Does
anyone have any ideas? Thanks, help would be appreciated.  :)

</para>


<para>On Wed, Mar 22, 2000 at 09:35:15AM -0500, Alderman, Sean wrote:
&gt; You might want to check the archives.  I believe someone had built a perl
&gt; script and posted it to the list to create encrypted username/password
pairs
&gt; for custom proftpd auth files.

genuser.pl in the contrib/ directory.


Syntax is "htpasswd.pl userid password". Output is
"userid:encryptedPassword". You might need to change the path to your perl.
 
#!/usr/bin/perl
$user = $ARGV[0]; $pass1 = $ARGV[1];
my($salt)=seedchar().seedchar();
$pass = crypt($pass1, $salt);
print STDOUT "$user:$pass\n";
 
sub seedchar {
   ('a'..'z','A'..'Z','0'..'9','.','/','"')[rand(64)];
}


&gt; Syntax is "htpasswd.pl userid password". Output is
&gt; "userid:encryptedPassword". You might need to change the path to your
perl.

Well, I tried using htpasswd, but that does not go to the same format as
/etc/passwd. ProFTPD will only read the /etc/passwd format, correct?
</para>

<para>

	I was wondering, what utility do you use to generate the encrypt
shadow passwd??
</para>


<para>	I have several users on my Linux system. I am trying to allow them
all to
	be able to have logins for FTP. For example, one customer can create
the
	FTP account webmaster which logs into /home/customer1/public_html
with the
	password poiuy, while another customer can create the FTP account
	webmaster which logs into /home/customer2/public_html with the
password
	lkjhg. I looked through the configurations and AuthUserFile looked
like
	the best way to do it.

	So I setup a test one. In the proftpd.conf vhost for game-guys.com,
I
	setup AuthUserFile /home/game-guys/game-guys. In that game-guys, I
would
	like to have several logins and passwords (encrypted of course)
which can
	only login to game-guys.com on the server.

	My question is, what should go in /home/game-guys/game-guys, and how
	should I add users to it and set the password? All three commands,
	useradd, passwd and htpasswd don't seem to want to work properly.
Does
	anyone have any ideas? Thanks, help would be appreciated.  :)

On Wed, Mar 22, 2000 at 09:35:15AM -0500, Alderman, Sean wrote:
&gt; You might want to check the archives.  I believe someone had built a perl
&gt; script and posted it to the list to create encrypted username/password pairs
&gt; for custom proftpd auth files.

genuser.pl in the contrib/ directory.


&gt; genuser.pl in the contrib/ directory.
&gt;
&gt;       Mark</para>

<para>Okay, I ran genuser with ftp1 as my username and lala as my password. It
came up as this:

ftp1:9l/MJ4vLeAAlU

So everything after that colon can be put in the passwd file, and it will
work? Thanks for all of your help!


On Thu, Mar 23, 2000 at 06:09:56PM -0500, Vincent Paglione wrote:
&gt; ftp1:9l/MJ4vLeAAlU
&gt; 
&gt; So everything after that colon can be put in the passwd file, and it will
&gt; work? Thanks for all of your help!

What you need to do from this point is generate a /etc/passwd compatible
file ie.

ftp1:9l/MJ4vLeAAlU:103:65534::/var/run/identd:/bin/false
ftp2:9l/MJ4vLeAAlU:103:65534::/var/run/identd:/bin/false
ftp3:9l/MJ4vLeAAlU:103:65534::/var/run/identd:/bin/false
ftp4:9l/MJ4vLeAAlU:103:65534::/var/run/identd:/bin/false

and save this as your $CONF/authpasswdfile and then reference it from
the proftpd.conf

I've got my own homebrew system running on the core ftp vhost server which
takes a condensed version of the proftpd.conf and builds it into the full
configuration and generates the passwd/group files.  I'll toss it up there
if anyone is interested (but it's nasty evil perl with no documentation :)
</para>


<para>Okay, I have everything with my AuthUserFile setup. THANKS everyone who
helped me. I just have one more request.

In /etc/passwd, if I wanted to make additional FTP accounts for a user, I
would make the UID the same as the original account so that the sub-ftp
account could write/overwrite the data in the main accounts directory, and
once it was uploaded, the main account could write/overwrite it too.

Do you know how I can accomplis this with multiple passwd's?
</para>


<para>I was using Fetch 3.0.03 (MacOS) to transfer 10's of thousands
of files (over 1GB total data) and about half way through I
received:

Mar 25 01:48:15 sneex proftpd[539]: Internal error: non-PASV mode, yet data
connection already exists?!?


Anyone seen this or have comments?
</para>



<para>On Sat, 25 Mar 2000, Vincent Paglione wrote:

&gt;Okay, I have everything with my AuthUserFile setup. THANKS everyone who
&gt;helped me. I just have one more request.
&gt;
&gt;In /etc/passwd, if I wanted to make additional FTP accounts for a user, I
&gt;would make the UID the same as the original account so that the sub-ftp
&gt;account could write/overwrite the data in the main accounts directory, and
&gt;once it was uploaded, the main account could write/overwrite it too.
&gt;
&gt;Do you know how I can accomplis this with multiple passwd's?

&gt;From the sound of things what you want to do is create a group, say fnord,
and make all of the relevant users have fnord as their primary group then
play with umask to give everyone the requisite access. This is a far
tidier solution than creating multiple accounts with the same UID, which
while technically possible is messy.

Have a play with groupadd(8), addgroup(8), and group(5) and see how you
go.</para>



<para>
&gt; and save this as your $CONF/authpasswdfile and then reference it from
&gt; the proftpd.conf

This is the only part I did not udnerstand. I was hoping to save the
passwd file somewhere like /etc/users/userpasswd. What is this
$CONF/authpasswdfile?
</para>



<para>I noticed that there may be a bug in using AuthUserFile. When you create a new 
passwd file on FreeBSD 3.4, it only reads the first 3 lines of the passwd file. 
Any user that is after the 3rd line is not read, and proftpd says that user is 
not found. 
Anybody have any idea.</para>




<para>if you don't want to have PAM-support, try to compile without PAM, otherwise
compile with PAM. Configure looks like
configure --with-modules=mod_pam if you want to have PAM-Support, or
--without-modules=mod_pam (?) if you don't want to have support for PAM.
</para>

<para>tstoev@compsci.lyon.edu on 09.02.2000 06:42:18
Bitte antworten an proftpd@proftpd.org @ Internet
An:     proftpd@proftpd.org @ Internet
Kopie:
Thema:  [ProFTPD] AuthPAMAuthoritative

I have tried to use the AuthPAMAuthoritative directive and it does not seem to
work, because it seems like PAM is always the authority. That is on FreeBSD 3.4
and RedHat 6.0. Does anybody have an idea.
</para>


<para>I have tried to use the AuthPAMAuthoritative directive and it does not seem to 
work, because it seems like PAM is always the authority. That is on FreeBSD 3.4 
and RedHat 6.0. Does anybody have an idea.</para>



<para>I have a question, i am Using a special AuthUserFile which i think is =
correctly created!
(username:crypt(password,salt))

But when i try to login with a user, given in this AuthUserFile, it =
doesn't work. I have already added the Directive=20
RequireValidShell off

but it does not work, what can i do?? is there a way to find the mistake =
??</para>


<para>I wish to only have FTP access to to "fake", non shell users, since
my shell users login with ssh, and they cannot use the same username
password pair in an unencrypted FTP session.  The server running FTP
only has a single IP and will only be listening in on PORT 21, so
there won't be any virtual FTP hosts.  ProFTPd is configured in as
a standalone daemon, no inetd.</para>

<para>To that end, I have created an alternative passwd file, using the
apache htpasswd command, and a group file.  ProFTPd is configured to
run as user nobody, and does a chroot for to the www root directory
which it owns.  Just for testing purposes, I have made these
alternative passwd & group files, plus the directories they are in,
readable by all user ids.</para>

<para>I have added the following directives to proftpd.conf:

	AuthUserFile                    /opt/proftpd/etc/passwd
	AuthGroupFile                   /opt/proftpd/etc/group
	PersistentPasswd                off

As mentioned, I only want proftpd to use /opt/proftpd/etc/passwd
and *NOT* the server's /etc/passwd file.  Unfortunately, when I use
this configuration, no one can log in.  Reading the FAQ, I try to
add the directive:

	AuthPAMAuthoritative            off

Unfortunately when I do so, I get the following error when I start
up ProFTPd:

	- Fatal: unknown configuration directive 'AuthPAMAuthoritative'.

Running "proftpd -l" to get a list of modules reveals:

	mod_core.c
	mod_auth.c
	mod_xfer.c
	mod_site.c
	mod_ls.c
	mod_unixpw.c
	mod_log.c</para>

<para>Unfortunately the AuthPAMAuthoritative directive is *ONLY* read by the
"mod_pam" module, which is missing.  So when I try to recompile ProFTPd,
with the configure "--with-modules=mod_pam" option, I get the following
compiler error when I run gmake:

	mod_pam.c:39: security/pam_appl.h: No such file or directory</para>

<para>No "pam_appl.h" file is included with ProFTPd, and it is not included
in "/usr/include/security".  (I am running NetBSD 1.4.1 on ix86 and
sparc, neither of which have anything related to PAMs.  No pam_appl.h,
pam.conf, or pam_unix.so files.  "apropos pam" finds nothing
appropriate.)</para>

<para>What can I do?  I simple want ProFTPd to use an alternative passwd and
group file, just like my apache does.  I have went through all of the
ProFTPd documentation, FAQ, and mailing list archive without any
solution.</para>



<para>On Mon, Jan 31, 2000 at 07:29:13AM -0500, Alicia da Conceicao wrote:

&gt; I wish to only have FTP access to to "fake", non shell users, since
&gt; my shell users login with ssh, and they cannot use the same username
&gt; password pair in an unencrypted FTP session.  The server running FTP
[...]
&gt; I have added the following directives to proftpd.conf:
&gt; 
&gt; 	AuthUserFile                    /opt/proftpd/etc/passwd
&gt; 	AuthGroupFile                   /opt/proftpd/etc/group
&gt; 	PersistentPasswd                off
[...]
&gt; this configuration, no one can log in.  Reading the FAQ, I try to
&gt; add the directive:
&gt; 
&gt; 	AuthPAMAuthoritative            off
&gt; 
&gt; Unfortunately when I do so, I get the following error when I start
&gt; up ProFTPd:
&gt; 
&gt; 	- Fatal: unknown configuration directive
&gt; 'AuthPAMAuthoritative'.
[..]
&gt; with the configure "--with-modules=mod_pam" option, I get the following
&gt; compiler error when I run gmake:
&gt; 
&gt; 	mod_pam.c:39: security/pam_appl.h: No such file or directory

Given that you don't appear to have PAM installed on your machine you
don't need to concern yourself with the "AuthPAMAuthoritative"
directive.</para>



<para>&gt;&gt; I have added the following directives to proftpd.conf:
&gt;&gt; 	AuthUserFile                    /opt/proftpd/etc/passwd
&gt;&gt; 	AuthGroupFile                   /opt/proftpd/etc/group
&gt;&gt; 	PersistentPasswd                off
&gt;&gt; ...
&gt;&gt; 	mod_pam.c:39: security/pam_appl.h: No such file or directory
&gt; 
&gt; Given that you don't appear to have PAM installed on your machine you
&gt; don't need to concern yourself with the "AuthPAMAuthoritative"
&gt; directive.

Dear Mark:

If that is the case, then why doesn't the AuthUserFile work?  No one
can login using the alternative passwd and group files I created
with apache htpasswd.  I assumed that AuthPAMAuthoritative might
be the cause of the problem, since the FAQ mentioned it.

My goal is to restrict FTP access to users who do not have entries
in the server /etc/passwd file.  All FTP users must be specified
in /opt/proftpd/etc/passwd.  For security reasons, users with shell
access will be *NOT* be allowed to use FTP (they can use ssh/scp
instead).

Am I doing any thing work?</para>



<para>I have some problems with 'AuthUserFile' / 'AuthGroupFile'.
I set them to an absolute path but I cannot login.
I created my own passwd with the following line:
    userxyz:x:501:101:Webadmin:/var/http/userxyz:/bin/bash
and my own group file:
    wwwuser:x:101:
What about /etc/shadow?
A test with an own passwd (with the crypted password in it) of
    userxyz:fsdf76s23:501:101:Webadmin:/var/http/userxyz:/bin/bash
didn't work, too...

I am using SuSE Linux 6.3 on x86.</para>



<para>On Fri, Jan 28, 2000 at 04:38:26PM +0100, Chris Loos wrote:
&gt; Hi,
&gt; I have some problems with 'AuthUserFile' / 'AuthGroupFile'.
&gt; I set them to an absolute path but I cannot login.
&gt; I created my own passwd with the following line:
&gt;     userxyz:x:501:101:Webadmin:/var/http/userxyz:/bin/bash
&gt; and my own group file:
&gt;     wwwuser:x:101:
&gt; What about /etc/shadow?
&gt; A test with an own passwd (with the crypted password in it) of
&gt;     userxyz:fsdf76s23:501:101:Webadmin:/var/http/userxyz:/bin/bash
&gt; didn't work, too...

Check the FAQ....

AuthPAMAuthoritive off (check the spelling of the directive)
PersistantPasswd off   (IIRC)</para>


<para>of course I checked the FAQs but the only hint I found was theses two
comments you wrote.
But after using "AuthPamAuthoritve off" and "PersistantPasswd off" inetd
isn't able to start proftpd - seems that the ftpd crashed or stops itself
immediately.</para>

<para>Weird, I'm using AuthUserFile extensively on one machine
(virtualhosting and I want the user/password details to be unique to
the virtual) with no problems.  The only difference is I run in
standalone, can you try that approach and see what happens?  Can you
run in debug mode?  (ie proftpd -n -dx, where x = a number between 1
and 9)</para>

<para>Problem:  Valid user accounts are not able to log in.

System: Sun SPARC, running Solaris 7.  Hardware details available on request.

Symptoms:

(From perl Net::FTP, Debug mode)...

Net::FTP: Net::FTP(2.53)
Net::FTP:   Exporter
Net::FTP:   Net::Cmd(2.16)
Net::FTP:   IO::Socket::INET
Net::FTP:     IO::Socket(1.1603)
Net::FTP:       IO::Handle(1.1505)

Net::FTP=GLOB(0xc9268)&lt;&lt;&lt; 220 members.friendfactory.com
Net::FTP=GLOB(0xc9268)&gt;&gt;&gt; user whoami
Net::FTP=GLOB(0xc9268)&lt;&lt;&lt; 331 Password required for whoami.
Net::FTP=GLOB(0xc9268)&gt;&gt;&gt; PASS ....
Net::FTP=GLOB(0xc9268)&lt;&lt;&lt; 230 User whoami logged in.
Net::FTP=GLOB(0xc9268)&gt;&gt;&gt; QUIT
Net::FTP=GLOB(0xc9268)&lt;&lt;&lt; 221 Goodbye.

Net::FTP=GLOB(0xc604c)&lt;&lt;&lt; 220 members.friendfactory.com
Net::FTP=GLOB(0xc604c)&gt;&gt;&gt; user whatsyrname
Net::FTP=GLOB(0xc604c)&lt;&lt;&lt; 331 Password required for whatsyrname.
Net::FTP=GLOB(0xc604c)&gt;&gt;&gt; PASS ....
Net::FTP=GLOB(0xc604c)&lt;&lt;&lt; 530 Login incorrect.
Net::FTP=GLOB(0xc604c)&gt;&gt;&gt; QUIT
Net::FTP=GLOB(0xc604c)&lt;&lt;&lt; 421 Login Timeout (300 seconds): closing control connection.

&gt;From ftpdlog:

pluto.driftwood.com 207.229.89.167 nobody [23/Jan/2000:15:14:22 -0800] "USER whoami" 331 -
pluto.driftwood.com 207.229.89.167 whoami [23/Jan/2000:23:14:22 +0000] "PASS (hidden)" 230 -
pluto.driftwood.com 207.229.89.167 nobody [23/Jan/2000:15:14:23 -0800] "USER whatsyrname" 331 -
pluto.driftwood.com 207.229.89.167 nobody [23/Jan/2000:15:14:24 -0800] "PASS (hidden)" 530 -</para>




<para>Notes on above:

1) The output is from a perl script which goes cycling through random sets of known usernames and passwords in order to do performance testing on our new authentication server.  The names of the users have been changed to protect the innocent.

2) Note that the timezone in the ftpdlog changes from -0800 to +0000 when there is a sucessful login.  Note also that the username registers sucessfully.

3) This problem has repeated itself using Solaris /usr/bin/ftp, ncftp, and perl Net::FTP.  As such, I don't think it's a client issue per se.

4) On Net::FTP (the only one which I have done extensive testing on) we have gotten about 80% reproducability on a sample of 2000 attempted connections.  The other 20% of the queries validate normally.

5) I originally thought that the problem may be related to a disparity with the time clocks between the client and server machines.  (a mystic longshot, given that RFC-959 doesn't exchange date/time stamps per se).  An earlier test eradicated this problem by synchronizing the system clocks.

Any ideas on what the errors of my ways might be?</para>


<para>I am intending to use proftpd to set up an
ftp server (and thint it is a Good Thing)

Configuration is a Linux box, RedHat 6.1
kernel 2.2.12-20

Intending to use simply /etc/passwd
and shadow for authentication to begin with.

Therefore I'm using PAM, and have configured
/etc/init.d/ftp as per the README.PAM file

Problem is that at authentication time the
PAM module is tryint to make connections back to the
calling machine on Port 113, which is the
port for the auth protocol.

Has anyone come across this one please, and
how do we stop it doing this?
It is not what we want the ftp server to do, and is
making authentication take a long time.

Sorry if this is a real simple RTFM.</para>


<para>John Hearns wrote:
&gt; 
&gt; Problem is that at authentication time the
&gt; PAM module is tryint to make connections back to the
&gt; calling machine on Port 113, which is the
&gt; port for the auth protocol.


I answer my own question by finding the IdentLookups
directive. 
I hang my head in shame - I should have all my merit
badges ceremonially stripped off and be drummed out
of the sys admin brownies, to be banished to scratching
a poor existence loading Windows printer drivers.

Apologies for a wasted post to the list - 
I'm not a baby sys admin who's unwrapped his first box
of Linux CDs (honest!). I only asked for help after watching
loads of firewall log traces and a lot of head scratching.

One tip though - I finally got clued into my problem
by finding documentation on the Apache IdentityCheck directive,
which the IdentLookups directive is similar to.</para>



<para>I've been working with proftpd for a while and I still don't quite understand
how authentication works.  The object is to have users listed in /etc/passwd
authenticated via system methods which works but I would like to have an
additional password file used for guest users that are confined to their home
dir.  Can anyone suggest how to do this or point me to some documentation. 
I'm using the config file that gets installed when you run make install with 
1.2.0pre8 with the addition of the two lines below.

AuthUserFile                    /usr/local/etc/test.pwd
AuthPAMAuthoritative            off      
</para>


<para>Can someoe explain these two directives please? What I would like to
know is the following:

1. Must they exactly follow the format of /etc/passwd and /etc/group?=20
2. Which crypt must be used for the password - crypt or MD5?
3. Under which user will the VirtualHost execute?
4. How do they influence a chroot'd &lt;VirtualHost&gt;?
5. How is an &lt;Anonymous&gt; section inside a &lt;VirtualHost&gt; influenced?
6. If (1) is true, what is the significance of the UIDs and GIDs?
</para>


<para>

Note to Mark:  Maybe we should clarify the documentation on the AuthUserFile
directive?

&gt; 2. Which crypt must be used for the password - crypt or MD5?

The password check is done via the crypt() call...so if your system happens
to map that to an MD5 version of crypt(), then it's MD5.

There's a script in the contrib directory called genuser.pl that will
generate valid usename:password crypt-ed pairs for you.

&gt; 3. Under which user will the VirtualHost execute?

Pardon?  Under whatever user you've specified via the User directive of
course.

&gt; 4. How do they influence a chroot'd &lt;VirtualHost&gt;?

They don't really.  Whatever you've listed as the home directories is used
in determined a user-chroot jail as appropriate.

&gt; 5. How is an &lt;Anonymous&gt; section inside a &lt;VirtualHost&gt; influenced?

Huh?

&gt; 6. If (1) is true, what is the significance of the UIDs and GIDs?
&gt;

UIDs and GIDs are your method to control access on the system.  Presumably
you have these allocated in some fashion.  ProFTPD will honor whatever you
specify.
</para>


<para>Can somebody please tell me how to create the AuthUser file? I can't seem to
find out how I should encode the passwords in that file.</para>




<para>I am building a ProFTP ratio server. I was able to get mod.ratio installed
and working properly and I think I understand the rest of the
configuration that I need to do.

Except, I want a basic anonymous user, a user1/user1 (username/password)
user with better access and ration, and a user2/user2 with full access no
ratio.

As I understand it my conf file would look something like this...

AuthUserFile	/usr/ftp/etc/passwd
 
 &lt;Anonymous ~ftp&gt;
   User                         ftp
   Group                        ftp
   UserAlias                    anonymous ftp 
   
   MaxClients                   10 "Sorry, the maximum number of allowed
users are already connected (%m) "
   MaxClientsPerHost            1 "Sorry, you may not connect more than
one time."
   
   RequireValidShell            off
   
   DisplayLogin                 welcome.msg
   DisplayFirstChdir            .message
   
   &lt;Limit WRITE&gt;
    AllowUser User1
    AllowUser User2
    DenyAll
   &lt;/Limit&gt;

   &lt;Limit STOR&gt;
    AllowAll
   &lt;/Limit&gt;

        Ratios on
        UserRatio * 0 0 1 0
	UserRatio user1 0 0 10 0
	UserRatio user2 0 0 0 0

 &lt;/Anonymous&gt;

How do I generate the AuthUserFile so that this will work??

Thanks in advance!
</para>


<para>
I'm using pre9, with an anon section like this:

&lt;Anonymous /virtual/ftp&gt;
  User		virtual
  Group		virtual
  UserAlias	joe virtual
  AuthAliasOnly on
&lt;/Anonymous&gt;

This works as expected -- I can't login anonymously with "virtual", but I can
with "joe". When I do this:

&lt;Anonymous /virtual/ftp&gt;
  User		virtual
  Group		virtual
  UserAlias	joe virtual
  AuthAliasOnly off
&lt;/Anonymous&gt;

There is no change -- I still can't login anonymously with "virtual", but I
should be able to. Now, if I do this:

&lt;Anonymous /virtual/ftp&gt;
  User		virtual
  Group		virtual
  UserAlias	joe virtual
#  AuthAliasOnly off
&lt;/Anonymous&gt;
</para>

<para>
...it _does_ allow me to login anonymously with "virtual".

In other words, "AuthAliasOnly off" doesn't work. If I want the functionality
that it provides, I have to comment it out or remove it completely.
</para>




<para>Yes, you can. Go to httpd://www.proftpd.org   

Read the Documentation. Using an alternate password is documented very well.

Tsanko Stoev 
Lyon College
&gt; Can I use a different password file (other than /etc/passwd) with in the
&gt; same domain???

</para>


<para>My mail server is down so i gotta use hotmail...ugh. Anyway...
I fixed the anonymous login problem by adding a "RequireValidShell  off" 
into proftpd.conf. Now my problem is that valid users of the machine cannot 
login into the proftpd service but can with ssh and telnet. Anyone know any 
reasons as to why that is happening? Thanks in advance! -Andrew
</para>



<para>I tried that already but it still does not work.
&gt;From: Matt Critcher &lt;MCritch@lifeplususa.com&gt;
&gt;Reply-To: proftpd@proftpd.org
&gt;To: "'proftpd@proftpd.org'" &lt;proftpd@proftpd.org&gt;
&gt;Subject: RE: [ProFTPD] Login Problems
&gt;Date: Wed, 15 Mar 2000 08:33:14 -0600
&gt;
&gt;You probably dont have an entry in /etc/pam.d/ for ftp
&gt;
&gt;you have to put a file there called ftp that contains something similar the
&gt;following:
&gt;
&gt;#%PAM-1.0
&gt;auth       required     pam_listfile.so item=user sense=deny
&gt;file=/etc/ftpusers onerr=succeed
&gt;auth       sufficient   pam_userdb.so icase db=/tmp/dbtest
&gt;auth       required     pam_pwdb.so shadow nullok try_first_pass
&gt;auth       required     pam_shells.so
&gt;account    required     pam_pwdb.so
&gt;session    required     pam_pwdb.so
&gt;
&gt;or something like this.  its all i can remember without being on my machine
&gt;(stuck to the hells of windows at work).  in any case there is a file 
&gt;called
&gt;README.PAM that comes with the src for proftpd that has the correct
&gt;contents.</para>


<para>You probably dont have an entry in /etc/pam.d/ for ftp

you have to put a file there called ftp that contains something similar the
following:

#%PAM-1.0
auth       required     pam_listfile.so item=user sense=deny
file=/etc/ftpusers onerr=succeed
auth       sufficient   pam_userdb.so icase db=/tmp/dbtest
auth       required     pam_pwdb.so shadow nullok try_first_pass
auth       required     pam_shells.so
account    required     pam_pwdb.so
session    required     pam_pwdb.so

or something like this.  its all i can remember without being on my machine
(stuck to the hells of windows at work).  in any case there is a file called
README.PAM that comes with the src for proftpd that has the correct
contents.
</para>


<para>I'm having the exact same problem.
I have a binary and config file that allows logins on my 6.0 machines,
but when I copy them to a 6.1 box, I cannot login as a normal user...
I get this message (proftpd -n):

localhost (10.80.80.10[10.80.80.10]) - PAM(bobo): Authentication failure.
localhost (10.80.80.10[10.80.80.10]) - USER bobo (Login failed): Incorrect
password.</para>




</sect1>
















      <sect1>
	<title>proftpd.chmod</title>

	<para>I'm using RedHat 6.1 and proftpd 1.2.0pre10 (and I was
	  trying with pre2) and cannot change file permissions (under
	  no circumstances). The funny thing is that using a Windows
	  client like CuteFTP this client somehow seems to know that
	  from somewhere since the option change file attributes is
	  disabled.  When trying to do it with the ftp client from
	  linux I always get permission denied...
	</para>
	
	<para>
	  I'm not even using Anonymous Blocks...!  What I have is a
	  Directory Block with users home Dirs and within that just a
	  Limit block that say Everything is allowed - at least that's
	  what my conf= ig has come down to when trying to solve this
	  problem... :)=20


"Wimmer, Tobias" wrote:
&gt;=20
&gt; I'm not even using Anonymous Blocks...!
&gt;=20
&gt; What I have is a Directory Block with users home Dirs and within that j=
ust a
&gt; Limit block that say Everything is allowed - at least that's what my co=
nfig
&gt; has come down to when trying to solve this problem... :)
&gt;=20

Could it be that the permission denied comes from the Unix file system?
In that case it should be visible by running strace on the proftpd
process that is handling the session.



	  When I log into a shell with this user, setting file
	  permissions does wor= k,but I'll give it a try with
	  strace...



&gt; 
&gt; Hi,
&gt; 
&gt; Simple Question - (Hard answer?):
&gt; 
&gt; I'm using RedHat 6.1 and proftpd 1.2.0pre10 (and I was trying with pre2) and
&gt; cannot change file permissions (under no circumstances). The funny thing is
&gt; that using a Windows client like CuteFTP this client somehow seems to know
&gt; that from somewhere since the option change file attributes is disabled.
&gt; When trying to do it with the ftp client from linux I always get permission
&gt; denied...
&gt; 
&gt; Anyone any ideas?

I noticed this too, on SuSE 6.1, proftpd pre10; debug level 5 just says 

Apr  6 20:31:35 novix proftpd[1158]: novix (moniek[10.1.0.1]) -
received: SITE CHMOD 611 tim.htm 
Apr  6 20:31:35 novix proftpd[1158]: novix (moniek[10.1.0.1]) - in
dir_check(): path = '/tmp/tim.htm', fullpath = '/home/jei/tmp/tim.htm'. 

After some experimenting I noticed my test user/directory were
configured inside an &lt;anonymous&gt; block, after i got them out of there
the chmod did work. My current guess is that "Anonymous" has built-in
restrictions (no overwrite, rename, chmod, ..) that cannot be lifted by
&lt;limit ..&gt; blocks.

	  I peek in the source now and then, but 35k+ lines is a lot
	  to look at.



	  I have some trouble when I try to allow chmod file from my
	  user.  I have looking for directives in the doc, but I
	  didn't find anything.

	  So what is the way to allow my user to chmod their file in
	  they account ?
	</para>
      </sect1>



      <sect1>
	<title>proftpd.ls</title>
	<para>
if I'm ftping from a remote server.

ftp&gt; ls
200 PORT command successful.
421 Service not available, remote server has closed connection

edward&gt; cat syslog
Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
                - attempted bind to 127.0.0.1, port 20
Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
                - bind() failed in inet_create_connection(): Permission
denied
Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
                - Check the ServerType directive to ensure you are
configured correctly.
</para>
<para>
Mark was referring to the user you were logged in as when you actually
launched the ProFTPD server.

-----Original Message-----
From: Norio Kashiwagi [mailto:kasiwagi@kakoi.co.jp]
Sent: Monday, February 28, 2000 10:19 AM
To: proftpd@proftpd.org
Subject: Re: [ProFTPD] Can't do "ls" command


&gt; &gt; Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
&gt; &gt;                 - bind() failed in inet_create_connection(): Permission
&gt; &gt; denied
&gt; 
&gt; Did you start ftp as root?
Yes.
--- proftpd.conf ---
# Set the user and group that the server normally runs at.
#uSEr                           nobody
User                            root
Group                           nogroup
</para>
<para>
    Thanks for help,
      Chris
</para>
<para>
/etc/inetd.conf is
ftp stream tcp nowait root /usr/local/sbin/proftpd/in.proftpd in.proftpd

But ws-ftp's "Passive transfers" is no problem.
ProFTPD is Passive mode only?

</para>
<para>
&gt; &gt; Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
&gt; &gt;                 - bind() failed in inet_create_connection(): Permission
&gt; &gt; denied
&gt; 
&gt; Did you start ftp as root?
Yes.
--- proftpd.conf ---
# Set the user and group that the server normally runs at.
#uSEr                           nobody
User                            root
Group                           nogroup

</para>
<para>

--
To unsubscribe, send mail to proftpd-request@proftpd.org with "unsubscribe"
in the subject field of the message.

Please read the documentation and the FAQ before posting a question -- chances
are it's already been answered.

http://www.proftpd.org           -- The Official ProFTPD web site.
http://bugs.proftpd.org          -- Bug reporting and feature requests.
http://www.proftpd.org/docs/     -- The latest ProFTPD documentation and FAQ.


From proftpd-request@tos.net Mon Feb 28 15:02:33 2000
Received: from firewall.vom.org.uk ([212.32.5.30] helo=flyhmstr.vom.org.uk)
	by weasel.vom.org.uk with esmtp (Exim 3.12 #1)
	id 12PRgv-0007aS-00
	for mark@weasel.vom.org.uk; Mon, 28 Feb 2000 15:02:33 +0000
Received: from starbase.tos.net ([209.212.188.150])
	by flyhmstr.vom.org.uk with esmtp (Exim 3.11 #1 (Debian))
	id 12PRgt-0006DF-00
	for &lt;hamster@vom.org.uk&gt;; Mon, 28 Feb 2000 15:02:32 +0000
Received: (from listserv@localhost)
	by starbase.tos.net (8.9.3/8.9.3) id JAA08446;
	Mon, 28 Feb 2000 09:02:18 -0600
Resent-Date: Mon, 28 Feb 2000 09:02:18 -0600
Date: Mon, 28 Feb 2000 14:53:41 +0000
From: Mark Lowes &lt;hamster@vom.org.uk&gt;
To: proftpd@proftpd.org
Subject: Re: [ProFTPD] Can't do "ls" command
Message-ID: &lt;20000228145341.A29107@weasel.vom.org.uk&gt;
References: &lt;002101bf81f9$3f83b820$843365c1@kakoi.co.jp&gt;
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: &lt;002101bf81f9$3f83b820$843365c1@kakoi.co.jp&gt;; from kasiwagi@kakoi.co.jp on Mon, Feb 28, 2000 at 11:36:44PM +0900
Resent-Message-ID: &lt;7cBfHD.A.yAC.Owou4@starbase.tos.net&gt;
Resent-From: proftpd@proftpd.org
Reply-To: proftpd@proftpd.org
X-Mailing-List: &lt;proftpd@proftpd.org&gt; archive/latest/3697
X-Loop: proftpd@proftpd.org
Precedence: list
Resent-Sender: proftpd-request@proftpd.org
Resent-Bcc:
X-Filter: proftpd
Status: RO
Content-Length: 872
Lines: 27

On Mon, Feb 28, 2000 at 11:36:44PM +0900, Norio Kashiwagi wrote:

&gt; Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
&gt;                 - bind() failed in inet_create_connection(): Permission
&gt; denied

Did you start ftp as root?

    Mark
</para>
<para>
-- 
The Flying Hamster &lt;hamster@suespammers.org&gt;
http://hamster.wibble.org/
Do not meddle in the affairs of hamsters. Just don't. It's not worth it.
 - Ailbhe on #afp

--
To unsubscribe, send mail to proftpd-request@proftpd.org with "unsubscribe"
in the subject field of the message.

Please read the documentation and the FAQ before posting a question -- chances
are it's already been answered.

http://www.proftpd.org           -- The Official ProFTPD web site.
http://bugs.proftpd.org          -- Bug reporting and feature requests.
http://www.proftpd.org/docs/     -- The latest ProFTPD documentation and FAQ.


From proftpd-request@tos.net Mon Feb 28 15:25:03 2000
Received: from firewall.vom.org.uk ([212.32.5.30] helo=flyhmstr.vom.org.uk)
	by weasel.vom.org.uk with esmtp (Exim 3.12 #1)
	id 12PS2h-0007bQ-00
	for mark@weasel.vom.org.uk; Mon, 28 Feb 2000 15:25:03 +0000
Received: from starbase.tos.net ([209.212.188.150])
	by flyhmstr.vom.org.uk with esmtp (Exim 3.11 #1 (Debian))
	id 12PS2e-0006I8-00
	for &lt;hamster@vom.org.uk&gt;; Mon, 28 Feb 2000 15:25:00 +0000
Received: (from listserv@localhost)
	by starbase.tos.net (8.9.3/8.9.3) id JAA09041;
	Mon, 28 Feb 2000 09:24:40 -0600
Resent-Date: Mon, 28 Feb 2000 09:24:40 -0600
Message-ID: &lt;004801bf81ff$1c09a160$843365c1@kakoi.co.jp&gt;
From: "Norio Kashiwagi" &lt;kasiwagi@kakoi.co.jp&gt;
To: &lt;proftpd@proftpd.org&gt;
References: &lt;002101bf81f9$3f83b820$843365c1@kakoi.co.jp&gt; &lt;20000228145341.A29107@weasel.vom.org.uk&gt;
Subject: Re: [ProFTPD] Can't do "ls" command
Date: Tue, 29 Feb 2000 00:18:41 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Resent-Message-ID: &lt;NLL9UC.A.fJC.ZEpu4@starbase.tos.net&gt;
Resent-From: proftpd@proftpd.org
Reply-To: proftpd@proftpd.org
X-Mailing-List: &lt;proftpd@proftpd.org&gt; archive/latest/3698
X-Loop: proftpd@proftpd.org
Precedence: list
Resent-Sender: proftpd-request@proftpd.org
Resent-Bcc:
X-Filter: proftpd
Status: RO
Content-Length: 840
Lines: 24
</para>
<para>
&gt; &gt; Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1])
&gt; &gt;                 - bind() failed in inet_create_connection(): Permission
&gt; &gt; denied
&gt; 
&gt; Did you start ftp as root?
Yes.
--- proftpd.conf ---
# Set the user and group that the server normally runs at.
#uSEr                           nobody
User                            root
Group                           nogroup

</para>
<para>
 I can't get  mirror to work well with symlinks and proftpd.
After testing a while I found that proftpd seems to make 
no difference between the two commands:
    ls -lR
    ls -lLR
 where the last should make proftpd show up the real files,
not the symlinks which point to the files.

 Here is a simple test:

cd /var/tmp
mkdir -p d0/d1/d2/d3
mkdir d0/real_dir
date &gt;d0/real_dir/test
ln -s ../../../real_dir d0/d1/d2/d3
ln -s ../../../real_dir/test d0/d1/d2/d3/data_link

 Then, proftpd gives no difference with the above two ftp-commands:

...

d0:
drwxr-xr-x   4 root     root         1024 Feb 29 06:26 .
drwxrwxrwx   5 root     root         3072 Feb 29 08:35 ..
drwxr-xr-x   3 root     root         1024 Feb 29 06:26 d1
drwxr-xr-x   2 root     root         1024 Feb 29 06:26 real_dir

d0/d1:
drwxr-xr-x   3 root     root         1024 Feb 29 06:26 .
drwxr-xr-x   4 root     root         1024 Feb 29 06:26 ..
drwxr-xr-x   3 root     root         1024 Feb 29 06:26 d2

d0/d1/d2:
drwxr-xr-x   3 root     root         1024 Feb 29 06:26 .
drwxr-xr-x   3 root     root         1024 Feb 29 06:26 ..
drwxr-xr-x   2 root     root         1024 Feb 29 06:26 d3

d0/d1/d2/d3:
drwxr-xr-x   2 root     root         1024 Feb 29 06:26 .
drwxr-xr-x   3 root     root         1024 Feb 29 06:26 ..
lrwxrwxrwx   1 root     root           22 Feb 29 06:26 data_link -&gt; ../../../rea
l_dir/test
lrwxrwxrwx   1 root     root           17 Feb 29 06:26 real_dir -&gt; ../../../real
_dir

d0/real_dir:
drwxr-xr-x   2 root     root         1024 Feb 29 06:26 .
drwxr-xr-x   4 root     root         1024 Feb 29 06:26 ..
-rw-r--r--   1 root     root           29 Feb 29 06:26 test
...
 

 Of course, you may set ShowSymlinks off, but this is NOT the
desired mode.
</para>
<para>
 Thanks,
    Andreas Wehler

</para>
<para>
+------ "Dr. Andreas Wehler" wrote (Tue, 29-Feb-00, 08:44 +0100):
| 
|  I can't get  mirror to work well with symlinks and proftpd.
| After testing a while I found that proftpd seems to make 
| no difference between the two commands:
|     ls -lR
|     ls -lLR
|  where the last should make proftpd show up the real files,
| not the symlinks which point to the files.

That's right.  The mod_ls module doesn't recognize the -L option.

|  Of course, you may set ShowSymlinks off, but this is NOT the
| desired mode.

Try the attached patch, made against the current CVS sources
(mod_ls.c 1.21 2000/01/23).

This is my first look at the mod_ls.c code, and I didn't spend much
time on it, so there is some doubt in my mind about it, particularly
the push_cwd/pop_cwd bits.  So, don't be shy with feedback, positive
or negative.  If it looks OK, I can submit the patch.  It's probably
too late to get by the 1.2.0 release code freeze, though.

While we are thinking about this stuff, I noticed that a couple of
other common ls options are missing that might be reasonable to add,
e.g. -A, -p, and -s.  It also occurred to me that there might be
legitimate use for a method to disable the -R option, from a resource
conservation point of view.  This could be either a directive, or a
sentinel file (like the wu-ftpd .notar), or both.  A more comprehensive
directive, say "LsDisableOptions", might disable ls options selectively.
Thoughts?

Speaking of .notar, mod_tar doesn't appear to use that convention.
Does anyone miss that feature?
</para>
<para>
Charles Seeger wrote:
&gt; 
&gt; +------ "Dr. Andreas Wehler" wrote (Tue, 29-Feb-00, 08:44 +0100):
&gt; |
&gt; |  I can't get  mirror to work well with symlinks and proftpd.
&gt; | After testing a while I found that proftpd seems to make
&gt; | no difference between the two commands:
&gt; |     ls -lR
&gt; |     ls -lLR
&gt; |  where the last should make proftpd show up the real files,
&gt; | not the symlinks which point to the files.
&gt; 
&gt; That's right.  The mod_ls module doesn't recognize the -L option.
&gt; 
&gt; |  Of course, you may set ShowSymlinks off, but this is NOT the
&gt; | desired mode.
&gt; 
&gt; Try the attached patch, made against the current CVS sources
&gt; (mod_ls.c 1.21 2000/01/23).

 Thank you very much!  It works like a charme.  And this within hours.
What sort of commercial software company may reach this level of support?
</para>
<para>
 Thanks.

   Andreas Wehler

-- 
CCS Informationssysteme GmbH    Tel.: (+49)  211 - 52740 - 228
Dr.-Ing. Andreas Wehler         Fax.: (+49)  211 - 52740 - 280
                                http://www.ccs-web.com

--
To unsubscribe, send mail to proftpd-request@proftpd.org with "unsubscribe"
in the subject field of the message.

Please read the documentation and the FAQ before posting a question -- chances
are it's already been answered.

http://www.proftpd.org           -- The Official ProFTPD web site.
http://bugs.proftpd.org          -- Bug reporting and feature requests.
http://www.proftpd.org/docs/     -- The latest ProFTPD documentation and FAQ.


From proftpd-request@tos.net Sat Feb 12 00:07:39 2000
Received: from firewall.vom.org.uk ([212.32.5.30] helo=flyhmstr.vom.org.uk)
	by weasel.vom.org.uk with esmtp (Exim 3.12 #1)
	id 12JQ67-0000GC-00
	for mark@weasel.vom.org.uk; Sat, 12 Feb 2000 00:07:39 +0000
Received: from starbase.tos.net ([209.212.188.150])
	by flyhmstr.vom.org.uk with esmtp (Exim 3.11 #1 (Debian))
	id 12JQ65-0001KI-00
	for &lt;hamster@vom.org.uk&gt;; Sat, 12 Feb 2000 00:07:38 +0000
Received: (from listserv@localhost)
	by starbase.tos.net (8.9.3/8.9.3) id OAA09338;
	Fri, 11 Feb 2000 14:51:54 -0600
Resent-Date: Fri, 11 Feb 2000 14:51:54 -0600
From: "Lan Tran" &lt;lan@recol.com&gt;
To: &lt;proftpd@proftpd.org&gt;
Date: Fri, 11 Feb 2000 15:44:38 -0500
Message-ID: &lt;NDBBLOICLKHIHOKDAEGKAEGFCBAA.lan@recol.com&gt;
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: &lt;56183983FF5AD31185F70060B06DF1683FF394@dot.ctcts.com&gt;
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [ProFTPD] Can't do "ls"
Resent-Message-ID: &lt;JDSsr.A.bMC.dRHp4@starbase.tos.net&gt;
Resent-From: proftpd@proftpd.org
Reply-To: proftpd@proftpd.org
X-Mailing-List: &lt;proftpd@proftpd.org&gt; archive/latest/3385
X-Loop: proftpd@proftpd.org
Precedence: list
Resent-Sender: proftpd-request@proftpd.org
Resent-Bcc:
X-Filter: proftpd
Status: RO
Content-Length: 689
Lines: 22
</para>
<para>
I can do a "ls" if I ftp from localhost.  However, "ls" does not work
if I'm ftping from a remote server.
=======
&gt; | After testing a while I found that proftpd seems to make
&gt; | no difference between the two commands:
&gt; |     ls -lR
&gt; |     ls -lLR
&gt; |  where the last should make proftpd show up the real files,
&gt; | not the symlinks which point to the files.
&gt; 
&gt; That's right.  The mod_ls module doesn't recognize the -L option.
&gt; 
&gt; |  Of course, you may set ShowSymlinks off, but this is NOT the
&gt; | desired mode.
&gt; 
&gt; Try the attached patch, made against the current CVS sources
&gt; (mod_ls.c 1.21 2000/01/23).

 Thank you very much!  It works like a charme.  And this within hours.
What sort of commercial software company may reach this level of support?
</para>
<para>
I can do a "ls" if I ftp from localhost.  However, "ls" does not work
if I'm ftping from a remote server.

ftp&gt; ls
200 PORT command successful.

It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14.
Any ideas?
</para>
<para>
Thanks.

--
To unsubscribe, send mail to proftpd-request@proftpd.org with "unsubscribe"
in the subject field of the message.

Please read the documentation and the FAQ before posting a question -- chances
are it's already been answered.

http://www.proftpd.org           -- The Official ProFTPD web site.
http://bugs.proftpd.org          -- Bug reporting and feature requests.
http://www.proftpd.org/docs/     -- The latest ProFTPD documentation and FAQ.


From proftpd-request@tos.net Mon Feb 14 01:34:15 2000
Received: from firewall.vom.org.uk ([212.32.5.30] helo=flyhmstr.vom.org.uk)
	by weasel.vom.org.uk with esmtp (Exim 3.12 #1)
	id 12KAP1-0006ds-00
	for mark@weasel.vom.org.uk; Mon, 14 Feb 2000 01:34:15 +0000
Received: from starbase.tos.net ([209.212.188.150])
	by flyhmstr.vom.org.uk with esmtp (Exim 3.11 #1 (Debian))
	id 12KAOz-00081n-00
	for &lt;hamster@vom.org.uk&gt;; Mon, 14 Feb 2000 01:34:14 +0000
Received: (from listserv@localhost)
	by starbase.tos.net (8.9.3/8.9.3) id TAA11707;
	Sun, 13 Feb 2000 19:33:12 -0600
Resent-Date: Sun, 13 Feb 2000 19:33:12 -0600
From: L.M.D.Cranswick@dl.ac.uk (L. Cranswick)
Message-Id: &lt;200002140125.BAA07792@xrdsv1&gt;
Subject: Re: [ProFTPD] Can't do "ls"
To: proftpd@proftpd.org
Date: Mon, 14 Feb 2000 01:25:21 +0000 (GMT)
In-Reply-To: &lt;NDBBLOICLKHIHOKDAEGKAEGFCBAA.lan@recol.com&gt; from "Lan Tran" at Feb 11, 2000 03:44:38 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: &lt;v-puK.A.-xC.Tm1p4@starbase.tos.net&gt;
Resent-From: proftpd@proftpd.org
Reply-To: proftpd@proftpd.org
X-Mailing-List: &lt;proftpd@proftpd.org&gt; archive/latest/3425
X-Loop: proftpd@proftpd.org
Precedence: list
Resent-Sender: proftpd-request@proftpd.org
Resent-Bcc:
X-Filter: proftpd
Status: RO
Content-Length: 1379
Lines: 47


</para>
<para>
&gt; I can do a "ls" if I ftp from localhost.  However, "ls" does not work
&gt; if I'm ftping from a remote server.
&gt; 
&gt; ftp&gt; ls
&gt; 200 PORT command successful.
&gt; 
&gt; It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14.
&gt; Any ideas?

Sorry  if this has been answered - just quickly getting
through backlog of few 200 or so E-mails.

Do you have a firewall - or tunnelling (if being used)
configured correctly?  This could be blocking
the output?
</para>
<para>
On Mon, Feb 14, 2000 at 01:25:21AM +0000, L.M.D.Cranswick@dl.ac.uk wrote:
&gt; &gt; I can do a "ls" if I ftp from localhost.  However, "ls" does not work
&gt; &gt; if I'm ftping from a remote server.
&gt; &gt; 
&gt; &gt; ftp&gt; ls
&gt; &gt; 200 PORT command successful.
&gt; &gt; 
&gt; &gt; It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14.
&gt; &gt; Any ideas?

	This was one of the problems I experienced with proftpd under
	FreeBSD 4.0.

	The problem, from what I can tell (MacGyver has yet to respond
	to my Emails. Did you die, Mac?), seemed to be related to the
	fact that proftpd has #ifdefs which look for the definition of
	'FREEBSD3', generated during configure time, taken from uname
	(most likely). Since 'FREEBSD4' wasn't listed, well, you can
	see the problem. The code that used this was in inet.c, if
	my memory serves me right. The patch was very small.

	Check your logfiles. The error I was receiving made zero
	sense; proftpd was claiming port 21 was already bound (ab-
	surd, since the daemon was in standalone mode ;-) ).

	Can't really help you much more than this, as you're using
	Linux.

	Best of luck.
</para>
<para>
&gt; I can do a "ls" if I ftp from localhost.  However, "ls" does not work
&gt; if I'm ftping from a remote server.

Well, my gut feeling (sorry, just played who wants to be a millionaire on
abc.com) is to put this in your proftpd.conf:

LsDefaultOptions	-al

That will add -al, but you probably want that. If adding -al doesn't work
out, tell me.
</para>
<para>
Nope, doesn't work.  I'm behind a firewall.  Tried setting to passive mode:
"We only support stream mode, sorry."  I have to recompile the source?
</para>
<para>

-----Original Message-----
From: Vincent Paglione [mailto:mogom@jtan.com]
Sent: Friday, February 11, 2000 3:58 PM
To: proftpd@proftpd.org
Subject: Re: [ProFTPD] Can't do "ls"


&gt; I can do a "ls" if I ftp from localhost.  However, "ls" does not work
&gt; if I'm ftping from a remote server.

Well, my gut feeling (sorry, just played who wants to be a millionaire on
abc.com) is to put this in your proftpd.conf:

LsDefaultOptions	-al

That will add -al, but you probably want that. If adding -al doesn't work
out, tell me.
</para>
<para>
On Fri, Feb 11, 2000 at 04:15:47PM -0500, Lan Tran wrote:
&gt; Nope, doesn't work.  I'm behind a firewall.  Tried setting to passive mode:
&gt; "We only support stream mode, sorry."  I have to recompile the source?

it sounds like you can't run a FTP server ...  what is happening is
that a client can connect to port 21 to send the commands through,
but data transfers (either coming from a non-restricted port &gt; 1023,
or from port 20) going to the client are blocked on one end or the other.

you'll want to talk to the people in charge of your local firewall and see
what their setup is.  typically I'd allow:

incoming to server on port 20-21, &gt;1023
outgoing from server to all client ports (if you have to limit it, ports &gt;1023)
</para>

<para>
On Fri, Feb 11, 2000 at 03:44:38PM -0500, Lan Tran wrote:
&gt; ftp&gt; ls
&gt; 200 PORT command successful.
&gt; 
&gt; It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14.
&gt; Any ideas?

it sounds like there's a firewall in the way blocking the request.  try
passive mode and see what happens.
</para>

</sect1>

<sect1>
<title>proftpd.sql</title>
<para>

I'm trying to replace my current ftpd/realusers with proftpd/sqlpw auth
and I get the following problem with mod_sqlpw set to non-authoritative:
if real user tries to login to ftp with his name, that also exists
in the SQL DB but with different password and homedir, he gets the uid,gid
and home of the SQL user!

Is this the way it should work?
If no, is there someone who fixed this? I'm too lazy to make the work
already done by somebody ;)



    To rephrase your question:
You are saying that if a user logs in who's login id exists in both /etc/passwd
and in the MySQL DB and the user logs in gets the home directory of the user in
the MySQL DB. I am assuming that the passwords are the same in both /etc/passwd
and MySQL DB.

    That sounds right to me...

    Though I don't think we have a good description of what happens if you set
SQLauthoritative to "off" and build proftpd with mod_sqlpw... I hope Mark may
have some more insight here...
</para>
</sect1>

<sect1>
<title>proftpd.timeouts</title>
<para>


I'm running ProFTPD 1.2.0pre10

One of the people using our FTP server is reporting problems
connecting to it - I think the problems are related to timeouts.

Can I ask if anyone else has had timeout problems with particular
clients connecting to a proftpd server?

I have set:
TimeoutIdle          0
TimeoutStalled       0
TimeoutNoTransfer 3600

Yes - I do know that these may not be wise choices.

(Sorry to be so vague - if I had a better handle on this I would
be more precise).

John Hearns

</para>
<para>

&gt;&gt;&gt;&gt;&gt; "John" == John Hearns &lt;john.hearns@framestore.co.uk&gt; writes:

    John&gt; I'm running ProFTPD 1.2.0pre10 One of the people using our
    John&gt; FTP server is reporting problems connecting to it - I think
    John&gt; the problems are related to timeouts.

What problems exactly and from which FTP client (I ask because we have
had many problems with IE5) ?

    John&gt; Can I ask if anyone else has had timeout problems with
    John&gt; particular clients connecting to a proftpd server?

    John&gt; I have set: TimeoutIdle 0 TimeoutStalled 0 TimeoutNoTransfer
    John&gt; 3600

    John&gt; Yes - I do know that these may not be wise choices.

    John&gt; (Sorry to be so vague - if I had a better handle on this I
    John&gt; would be more precise).

    John&gt; John Hearns

I would suggest tracing this client using the logs, perhaps setting up
detailed logs of all the commands they send ?
</para>

</sect1>
    </chapter>


<chapter id="ch-compat"><?dbhtml filename="ch-compat.html">
<title>Compatibility and Integration</title>

<sect1>
<title>SQL</title>

<para>
Authentication and persistant ratio support for the mod_ratio module
    are provided using SQL databases.  The official documentation for
    this feature is currently a little thin on the ground.  At the
    moment unless SQL support is provided for mod_ratio the ratios are
    only considered within a single connection with no persistance of
    credits recorded.
</para>

<sect2>
<title>Compilation and support</title>
<para>
To include support for sql the appropriate module has to be added
	prior to building the binary for the host system

<programlisting>
./configure --with-modules=mod_sqlpw:mod_mysql
make 
make install
</programlisting>

This should ensure that support is properly enabled, in addiiton to
	this a local MySQL (or similar) server should be installed and
	configured with the appropriate accesses and tables for yor
	setup.  This is covered in later sections of this chapter.
</para>
</sect2>

<sect2>
<title>Format of SQL tables</title>

<para></para>

<example>
	    <title></title>
<programlisting>
<prompt>mysql&gt; show fields from proftp;</prompt>
+----------+-------------+------+-----+---------+-------+
| Field    | Type        | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| username | varchar(30) | YES  |     | NULL    |       |
| uid      | int(11)     | YES  |     | NULL    |       |
| gid      | int(11)     | YES  |     | NULL    |       |
| password | varchar(30) | YES  |     | NULL    |       |
| homedir  | varchar(50) | YES  |     | NULL    |       |
| count    | int(11)     | YES  |     | NULL    |       |
+----------+-------------+------+-----+---------+-------+
</programlisting>
</example>


<example>
<title>Contents</title>
<programlisting>
<prompt>mysql&gt; select * from proftp;</prompt>
+----------+------+------+----------+----------+-------+
| username | uid  | gid  | password | homedir  | count |
+----------+------+------+----------+----------+-------+
| oli      |  500 |  500 | test     | /home/om |     2 |
| oli2     |  500 |  500 | test     | /        |     1 |
+----------+------+------+----------+----------+-------+
</programlisting>
</example>

<para>(take care : uid and gid must be > 500. or change
the source code of the module).</para>

<para>
Authentication and persistant ratio support for the mod_ratio module
are provided using SQL databases.  The official documentation for this
feature is currently a little thin on the ground.  At the moment
unless SQL support is provided for mod_ratio the ratios are only
considered within a single connection with no persistance of credits
recorded.
</para>

<sect3>
<title>Compilation and support</title>
<para>
To include support for sql the appropriate module has to be added
	prior to building the binary for the host system

<programlisting>
./configure --with-modules=mod_mysql
make 
make install
</programlisting>

This should ensure that support is properly enabled, in addiiton to
	this a local MySQL (or similar) server should be installed and
	configured with the appropriate accesses and tables for yor
	setup.  This is covered in later sections of this chapter.
</para>
	  </sect3>

<sect3>
<title>SQL Authentication</title>

<para>
o Install MySQL
o Compile Proftpd with the --with-modules=mod_sqlpw:mod_mysql flags
</para>

<Para>Note: I had to alter the path slighly so the modules got mysql.h
from the rightplace.</Para>

<para>Detailing how to use MySQL is outside the scope of this document,
so here's some links.</Para>

<para>
o http://www.devshed.com/Server_Side/MySQL/Administration/
o http://www.devshed.com/Server_Side/MySQL/Intro/
</para>

<para>Quick rundown of what's needed to make a databae</Para>

<para>
o create a user for proftpd to access the database as
o create permissions for this user
o create new database (mine is called proftpd)
o reload as required to make this live
o create a table within proftpd (mine is ftp)
</para>

<para>
<example>
<title>SQL database layout</title>
<programlisting>
mysql> use proftpd;
Database changed
mysql> show tables;
+-------------------+
| Tables in proftpd |
+-------------------+
| ftp               |
+-------------------+
1 row in set (0.02 sec)

mysql> show columns from ftp ;
+----------+-------------+------+-----+---------+-------+
| Field    | Type        | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| username | varchar(60) | YES  |     | NULL    |       |
| uid      | int(11)     | YES  |     | NULL    |       |
| gid      | int(11)     | YES  |     | NULL    |       |
| password | varchar(30) | YES  |     | NULL    |       |
| homedir  | varchar(50) | YES  |     | NULL    |       |
| count    | int(11)     | YES  |     | NULL    |       |
+----------+-------------+------+-----+---------+-------+
6 rows in set (0.00 sec)
</programlisting>
</example>

<example>
<title>Configuration fragment for SQL</title>
<programlisting>
--[ proftpd.conf ]--
# auth using mysql            host      login   pass    db
MySQLInfo                     localhost hamster *****   proftpd
SQLUserTable                  ftp
SQLUsernameField              username
SQLUidField                   uid
SQLGidField                   gid
SQLPasswordField              password
SQLHomedirField               homedir
SQLLoginCountField            count
SQLAuthoritative              on
SQLPlaintextPasswords         on
--[ proftpd.conf ]--
</programlisting>
</example>
</para>

</sect3>

<sect3>
<title>Gotcha's</title>
<Para>
421 Service not availible
Make sure that the home directory of the user concerned actually
exists and has the right ownerships/permissions

Can't connect to the database

Is it running?
Is it listening?
Does the user proftpd is using have the right permissions?
</para>
</sect3>

<sect3>
<title>Format of SQL tables</title>

<para></para>

<example>
	      <title></title><programlisting>
<prompt>mysql&gt; show fields from proftp;</prompt>
+----------+-------------+------+-----+---------+-------+
| Field    | Type        | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| username | varchar(30) | YES  |     | NULL    |       |
| uid      | int(11)     | YES  |     | NULL    |       |
| gid      | int(11)     | YES  |     | NULL    |       |
| password | varchar(30) | YES  |     | NULL    |       |
| homedir  | varchar(50) | YES  |     | NULL    |       |
| count    | int(11)     | YES  |     | NULL    |       |
+----------+-------------+------+-----+---------+-------+
</programlisting>
</example>


<example>
<title>Contents</title>
<programlisting>
<prompt>mysql&gt; select * from proftp;</prompt>
+----------+------+------+----------+----------+-------+
| username | uid  | gid  | password | homedir  | count |
+----------+------+------+----------+----------+-------+
| oli      |  500 |  500 | test     | /home/om |     2 |
| oli2     |  500 |  500 | test     | /        |     1 |
+----------+------+------+----------+----------+-------+
</programlisting>
</example>

<para>(take care : uid and gid must be > 500. or change
the source code of the module).</para>
</sect3>


<sect3>
<title>Configuration details</title>

<para>The following configuration is needed in the proftpd.conf file
	  to enable sql support</para>

<example>
<title>proftpd.conf</title>
<programlisting>
MySQLInfo                       localhost test "" test
                                # HOST login password database
MySQLUserTable                  proftp
MySQLUsernameField              username
MySQLUidField                   uid
MySQLGidField                   gid
MySQLPasswordField              password
MySQLHomedirField               homedir 
MySQLLoginCountField            count   
MySQLAuthoritative              on      
MySQLPlaintextPasswords         on      
</programlisting>
</example>
</sect3>

<sect3>
<title>SQL Logging</title>
<para>

<example>
<title>Updated authentication table</title>
<programlisting>
mysql> show columns from ftpusers;
+----------+---------------+------+-----+---------+-------+
| Field    | Type          | Null | Key | Default | Extra |
+----------+---------------+------+-----+---------+-------+
| username | varchar(60)   | YES  |     | NULL    |       |
| uid      | int(11)       | YES  |     | NULL    |       |
| gid      | int(11)       | YES  |     | NULL    |       |
| password | varchar(30)   | YES  |     | NULL    |       |
| homedir  | varchar(50)   | YES  |     | NULL    |       |
| count    | int(11)       | YES  |     | NULL    |       |
| fretr    | int(10)       | YES  |     | NULL    |       |
| bretr    | int(10)       | YES  |     | NULL    |       |
| bstor    | int(10)       | YES  |     | NULL    |       |
| fstor    | int(10)       | YES  |     | NULL    |       |
| ftime    | timestamp(14) | YES  |     | NULL    |       |
| faddr    | varchar(255)  | YES  |     | NULL    |       |
| fhost    | varchar(255)  | YES  |     | NULL    |       |
| fcdir    | varchar(255)  | YES  |     | NULL    |       |
+----------+---------------+------+-----+---------+-------+
14 rows in set (0.01 sec)
</programlisting>
</example>

<example>
<title>File tracking table</title>
<programlisting>
mysql> show columns from logging2;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| fstor    | int(11)      | YES  |     | NULL    |       |
| fretr    | int(11)      | YES  |     | NULL    |       |
| bstor    | int(11)      | YES  |     | NULL    |       |
| bretr    | int(11)      | YES  |     | NULL    |       |
| fcdir    | varchar(255) | YES  |     | NULL    |       |
| fhost    | varchar(255) | YES  |     | NULL    |       |
| faddr    | varchar(255) | YES  |     | NULL    |       |
| ftime    | varchar(255) | YES  |     | NULL    |       |
| count    | int(11)      | YES  |     | NULL    |       |
| filename | varchar(255) | YES  |     | NULL    |       |
+----------+--------------+------+-----+---------+-------+
10 rows in set (0.01 sec)
</programlisting>
</example>


There's definitely some cruft in the logging2 table which I need to clean
out but I thought I'd make this post first >:)

# auth using mysql            host      login   pass    db
MySQLInfo                     bat.vom.org.uk hamster Ma3ros proftpd
#
SQLUserTable                  ftpusers
SQLUsernameField              username
SQLUidField                   uid
SQLGidField                   gid
SQLPasswordField              password
SQLHomedirField               homedir
SQLLoginCountField            count
#
# SQL Logging
#
SQLLogStats             on
# SQLLogHits "requires a table or table plus 3 fields: " "[table] filename
count dir"
SQLLogHits              logging2
# SQLLogDirs            fcdir SQLLogDirs              fcdir
# SQLLogHosts           &lt;host&gt; &lt;IP&gt; &lt;time&gt;
SQLLogHosts             fhost  faddr  ftime
Which results in authentication happening from the ftpusers table, and
running totals of the number of files up/download and the byte counts.
fcdir appears to hold the last directory change made (not sure what use
it is...) and fhost, faddr, ftime appear to hold details of the last
person to connect.
logging2 holds a list of files downloaded and the number of times they
have been collected.
Notes: the logging table only works properly if it's pre-populated with
filenames
ie
insert into logging2 (filename) values ('/full/dir/fromroot/filename');
Also with both tables the counters don't appear to work properly unless
zeroed before use.  Will ponder on this.

</para>
</sect3>
</sect2>
</sect1>

<sect1>
<title>Hints</title>

<para>I'm trying to build Proftp pre8 from the FreeBSD ports
collection with mod_mysql and having some troubles.  The port's
Makefile uses only the mod_ratio module by default.  I thought I'd be
able to build it with mod_mysql just by adding --with-modules=mod_mysql
into the Makefile, but did not meet with success.  Checking out the
unpacked Proftpd I see links in the modules dir pointing to mod_ratio
and mod_pgsql, so I tried it again with mod_pgsql instead.  In both
instances only the mod_ratio module was found and got made.  I
searched the archives and gave Johnnie's advice a go...</para>

<para>-with-modles=mod_sqlpw:mod_mysql:mod_pgsql:mod_ratio</para>

<para>Same story.  So what am I missing here (besides a few brain
cells)?  Anybody build the FreeBSD port with mod_mysql module?  Oh
yeah, this is on a 3.3 box.</para>

<para>It doesn't work "out-of-the CVS" on my system (where mysql is
installed in /usr/local/mysql).  Isn't there an option on ./configure
to tell where the files really are ? Currently, here are the "tricks"
I'm using to make proftpd compile (using 24oct99 CVS version) :</para>
<sect2>
<title>...</title>
<para>

./Make.rules
Replaced
LIBS=-lsupp -ldl -lcrypt  -lm -lmysqlclient  -lpam
by
LIBS=-lsupp -ldl -lcrypt  -lm  -lm /usr/local/mysql/lib/mysql/libmysqlclient.a -lpam


./modules/mod_mysql.c
and
./modules/mod_sqlpw.c
=====================
done an ln -s of these files from ./contrib to ./modules
and replaced in _both_ files :
#include &lt;mysql.h&gt;
by
#include "/usr/local/mysql/include/mysql/mysql.h"

./modules/Makefile
==================
Removed the line  
mod_mysql.o: mod_mysql.h
(there are no mod_mysql.h anymore)

Finally, I compiled the whole by :
./configure --with-modules=mod_sqlpw:mod_mysql --prefix=/usr/local
make 
make install

Results :
Oct 24 22:23:53 omega proftpd[7415]: omega.omnis.ch - ProFTPD 1.2.0pre8 standalone mode STARTUP

I think it would be nice to correct ./modules/Makefile in the CVS, and why not
to add symlinks from ./contrib to ./modules ? 

</para>
</sect2>


<sect2>
<title>Configuration details</title>

<para>The following configuration is needed in the proftpd.conf file
	  to enable sql support</para>

<example>
<title>proftpd.conf</title>
<programlisting>
MySQLInfo                       localhost test "" test
                                # HOST login password database
MySQLUserTable                  proftp
MySQLUsernameField              username
MySQLUidField                   uid
MySQLGidField                   gid
MySQLPasswordField              password
MySQLHomedirField               homedir 
MySQLLoginCountField            count   
MySQLAuthoritative              on      
MySQLPlaintextPasswords         on      
</programlisting>
</example>
</sect2>


<sect2>
<title>Hints</title>
<para>

Hello:

I'm trying to build Proftp pre8 from the FreeBSD ports collection with
mod_mysql and having some troubles.  The port's Makefile uses only the
mod_ratio module by default.  I thought I'd be able to build it with
mod_mysql just by adding --with-modules=mod_mysql into the  Makefile, but
did not meet with success.  Checking out the unpacked Proftpd I see links
in the modules dir pointing to mod_ratio and mod_pgsql, so I tried it again
with mod_pgsql instead.  In both instances only the mod_ratio module was
found and got made.  I searched the archives and gave Johnnie's advice a go...

-with-modles=mod_sqlpw:mod_mysql:mod_pgsql:mod_ratio

Same story.  So what am I missing here (besides a few brain cells)?
Anybody build the FreeBSD port with mod_mysql module?  Oh yeah, this is on
a 3.3 box.

Thanks bunches--Ken



It doesn't work "out-of-the CVS" on my system (where mysql is installed
in /usr/local/mysql).  Isn't there an option on ./configure to tell
where the files really are ? Currently, here are the "tricks" I'm
using to make proftpd compile (using 24oct99 CVS version) :

./Make.rules
============
Replaced
LIBS=-lsupp -ldl -lcrypt  -lm -lmysqlclient  -lpam
by
LIBS=-lsupp -ldl -lcrypt  -lm  -lm /usr/local/mysql/lib/mysql/libmysqlclient.a -lpam


./modules/mod_mysql.c
and
./modules/mod_sqlpw.c
=====================
done an ln -s of these files from ./contrib to ./modules
and replaced in _both_ files :
#include &lt;mysql.h&gt;
by
#include "/usr/local/mysql/include/mysql/mysql.h"

./modules/Makefile
==================
Removed the line  
mod_mysql.o: mod_mysql.h
(there are no mod_mysql.h anymore)

Finally, I compiled the whole by :
./configure --with-modules=mod_sqlpw:mod_mysql --prefix=/usr/local
make 
make install

Results :
Oct 24 22:23:53 omega proftpd[7415]: omega.omnis.ch - ProFTPD 1.2.0pre8 standalone mode STARTUP

I think it would be nice to correct ./modules/Makefile in the CVS, and why not
to add symlinks from ./contrib to ./modules ? 

</para>
</sect2>
</sect1>

<sect1><title>sendfile()</title>

<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>

<sect2>
<title>Linux 2.0.x 
</title>

<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>
</sect2>

<sect2><title>Runtime detection of sendfile()
</title>

<para>There are two patches available for runtime detection of
sendfile() which gets round the 2.0.x problems.</para>

<para>Johnie Ingram (aka netgod)'s:
http://www.proftpd.org/proftpd-devel-archive/99-10/msg00073.html</para>

<para>John Pierce &lt;hawkfan@pyrotechnics.com&gt;
http://www.proftpd.org/proftpd-devel-archive/99-10/msg00112.html</para>
</sect2>

<sect2><title>What are these log lines in pre8?
</title>

<para>The pre8 code has some additional debug logging going on 
tracking how sendfile is working.  Nothing to get excited 
about it's probably a case of MacGyver forgetting to comment 
it out.</para>
</sect2>

</sect1>

<sect1>
<title>Regular expressions
</title>

	<para>ProFTPD uses POSIX-style regexps.</para>
      </sect1>
</chapter>


<chapter id="cookbook">
<title>Cookbook</title>

<para>Sod all here...</para>
</chapter>
</part>
  
<part id="PROFTPD-reference">
<?dbhtml filename="part-reference.html">
<title>References</title>
<reference>
<?dbhtml filename="ref-directives.html">
<title>Configuration Directives</title>
<partintro>
<para>
This is a list of all the configuration directives
</para>
<epigraph>
<para>... FIX ME ...
</para>
</epigraph>
</partintro>
&directivesbyname;
</reference>

<reference>
<title>Configuration by Module</title>
<partintro>
<para>This is a list of all the configuration directives organised by
the module in which they are defined with details of each module, it's
purpose and the development team behind it.  </para>
</partintro>
&directivesbymodule;
</reference>

<reference>
<title>Configuration by Context</title>
<partintro>
<para>This is a list of all the configuration directives organised by
the module in which they are defined with details of each module, it's
purpose and the development team behind it.  </para>
</partintro>
&directivesbycontext;
</reference>



</part>

  <PART ID="PROFTPD-APP">
    <?dbhtml filename="appendix.html">
    <title>Appendices</title>

<APPENDIX ID="APP-RESOURCES"><?dbhtml filename="app-resource.html">
<title>Resources</title>

<para>This appendix is under development... I've borrowed the
formatting from elsewhere and am busy hacking it around to what i want</Para>

<PARA>placeholer for references and resources... ideas please.. I
      guess Mysql, postgres, rfc information etc should go here.
      Scripts for auto generating configs?  Links to linux resources?</para>

<PARA>The quantity of information about <ACRONYM>SGML</ACRONYM> and
<ACRONYM>XML</ACRONYM> is growing
 on a daily basis.  This appendix
strives to provide both a
 complete bibliography of the references
mentioned explicitly in
 this book, and a sampling of resources for
additional
 information about DocBook and about
<ACRONYM>SGML</ACRONYM> and <ACRONYM>XML</ACRONYM> in general.

Although not all of these resources are focused specifically on

DocBook, they still provide helpful information for DocBook

users.</PARA>

<SECT1>

<TITLE>Latest Versions of DocBook</TITLE>

<PARA>As of July 1998, responsibility for the advancement and maintenance

of the DocBook <ACRONYM>DTD</ACRONYM> has been transferred from the Davenport Group, which originated

it, to the DocBook Technical Committee of <ACRONYM>OASIS</ACRONYM> (Organization for the Advancement

of Structured Information Standards) at <ULINK URL="http://www.oasis-open.org/">http://www.oasis-open.org/</ULINK>.</PARA>

<PARA>The latest releases of DocBook can be obtained from the official DocBook

home page at <ULINK URL="http://www.oasis-open.org/docbook/">http://www.oasis-open.org/docbook/</ULINK>.</PARA>

</SECT1>

<SECT1>

<TITLE>Resources for Resources</TITLE>

<PARA>Here's where to find pointers to the subjects you want to find.</PARA>

<VARIABLELIST>

<VARLISTENTRY>

<TERM>The Most Recent Version of This Book</TERM>

<LISTITEM>

<PARA>The most recent online version of this book can be found at

<ULINK URL="http://docbook.org/">http://docbook.org/</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM>The Most Recent Version of Proftpd</TERM>

<LISTITEM>

<PARA>can be found... wibble wobble.</para>
</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM>Another mirror</TERM>
<LISTITEM>
<PARA>desc...wibble.</para>
</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><SYSTEMITEM ROLE="newsgroup">comp.text.sgml</SYSTEMITEM>

and <SYSTEMITEM ROLE="newsgroup">comp.text.xml</SYSTEMITEM></TERM>

<LISTITEM>

<PARA><ACRONYM>USENET</ACRONYM> newsgroups devoted to <ACRONYM>SGML</ACRONYM> and <ACRONYM>XML</ACRONYM> issues.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ACRONYM>FAQ</ACRONYM>s</TERM>

<LISTITEM>

<PARA>For pointers to several <ACRONYM>SGML</ACRONYM> <ACRONYM>FAQ</ACRONYM>s, see 

<ULINK URL="http://www.oasis-open.org/cover/general.html#faq">http://www.oasis-open.org/cover/general.html#faq</ULINK>. 

The <ACRONYM>XML</ACRONYM> <ACRONYM>FAQ</ACRONYM> is

available at <ULINK URL="http://www.ucc.ie/xml">http://www.ucc.ie/xml</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.xml.com/"><ACRONYM>XML</ACRONYM>.com</ULINK></TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.xml.com/"><ACRONYM>XML</ACRONYM>.com</ULINK>, run jointly

by Songline Studios and Seybold, is a site devoted to making <ACRONYM>XML</ACRONYM>

accessible.</PARA>

</LISTITEM>

</VARLISTENTRY>

</VARIABLELIST>

</SECT1>

<SECT1>

<TITLE>Introductory Material on the Web</TITLE>

<PARA>These documents provide a good background for a better understanding of

<ACRONYM>SGML</ACRONYM> and <ACRONYM>XML</ACRONYM>.</PARA>

<VARIABLELIST>

<VARLISTENTRY>

<TERM>A Guide to <ACRONYM>SGML</ACRONYM></TERM>

<LISTITEM>

<PARA>A helpful overview page with many pointers is available at <ULINK URL="http://www.shorelinerecordsmanagement.com/customer-service/education-center/a-guide-to-sgml---standard-generalized-markup-language/">http://www.shorelinerecordsmanagement.com/customer-service/education-center/a-guide-to-sgml---standard-generalized-markup-language/</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM>A Technical Introduction to <ACRONYM>XML</ACRONYM></TERM>

<LISTITEM>

<PARA>A close look at the ins-and-outs of <ACRONYM>XML</ACRONYM> is available at <ULINK URL="http://nwalsh.com/docs/articles/xml/">http://nwalsh.com/docs/articles/xml/</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

</VARIABLELIST>

</SECT1>

<SECT1>

<TITLE>References and Technical Notes<?lb>on the Web</TITLE>

<VARIABLELIST>

<VARLISTENTRY>

<TERM>Entity Management</TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.oasis-open.org/html/a401.htm"><ACRONYM>OASIS</ACRONYM> Technical

Resolution 9401:1997 (Amendment 2 to <ACRONYM>TR</ACRONYM> 9401)</ULINK>.</PARA>

<PARA>This document describes <ACRONYM>OASIS</ACRONYM> catalog files.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM>The <ACRONYM>SGML</ACRONYM> Declaration</TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.oasis-open.org/cover/wlw11.html">The <ACRONYM>SGML</ACRONYM> Declaration,</ULINK> by Wayne Wholer.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM>Table Interoperability: Issues for the <ACRONYM>CALS</ACRONYM> Table Model</TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.oasis-open.org/html/a501.htm"><ACRONYM>OASIS</ACRONYM>

Technical Research Paper 9501:1995</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM>Exchange Table Model Document Type Definition</TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.oasis-open.org/html/a503.htm"><ACRONYM>OASIS</ACRONYM>

Technical Resolution <ACRONYM>TR</ACRONYM> 9503:1995</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY ID="CALSDTD">

<TERM><ACRONYM>CALS</ACRONYM> Table Model Document Type Definition</TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.oasis-open.org/html/a502.htm"><ACRONYM>OASIS</ACRONYM>

Technical Memorandum <ACRONYM>TM</ACRONYM> 9502:1995</ULINK></PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY ID="CALSXMLDTD">

<TERM>XML Exchange Table Model Document Type Definition</TERM>

<LISTITEM>

<PARA><ULINK URL="http://www.oasis-open-org/html/a901.htm">OASIS

Technical Memorandum TM 9901:1999</ULINK>.</PARA>

</LISTITEM>

</VARLISTENTRY>

</VARIABLELIST>

</SECT1>


<SECT1>
<TITLE>Internet <ACRONYM>RFC</ACRONYM>s</TITLE>
<PARA><ACRONYM>RFC</ACRONYM>s (<QUOTE>Request for Comments</QUOTE>)
are standards documents produced by the Internet Engineering Task
Force (<ACRONYM>IETF</ACRONYM>).</PARA>
<VARIABLELIST>
<VARLISTENTRY>
<TERM><ULINK URL="http://www.rfc-editor.org/rfc/rfc959.txt"><ACRONYM>RFC</ACRONYM> 959</ULINK></TERM>

<LISTITEM>

<PARA>File Transfer Protocol (<ACRONYM>FTP</ACRONYM>).</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.rfc-editor.org/rfc/rfc1736.txt"><ACRONYM>RFC</ACRONYM> 2228</ULINK></TERM>

<LISTITEM>

<PARA>FTP Security Extensions</PARA>
</LISTITEM>

</VARLISTENTRY>

</VARIABLELIST>
</SECT1>

<SECT1>

<TITLE>Specifications</TITLE>

<PARA>Here are pointers to the specifications.</PARA>

<VARIABLELIST>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.w3.org/TR/REC-xml">The <ACRONYM>XML</ACRONYM> Specification</ULINK></TERM>

<LISTITEM>

<PARA>The <ACRONYM>W3C</ACRONYM> technical recommendation that defines <ACRONYM>XML</ACRONYM> 1.0.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.w3.org/TR/REC-xml-names/">Namespaces

in <ACRONYM>XML</ACRONYM></ULINK></TERM>

<LISTITEM>

<PARA>The <ACRONYM>W3C</ACRONYM> technical recommendation that defines <ACRONYM>XML</ACRONYM> namespaces.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.w3.org/TR/REC-MathML/">Mathematical

Markup Language (MathML) 1.0 Specification</ULINK></TERM>

<LISTITEM>

<PARA>The <ACRONYM>W3C</ACRONYM> technical recommendation that defines MathML, an <ACRONYM>XML</ACRONYM>

representation of mathematical equations.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.unicode.org/unicode/uni2book/u2.html">The Unicode Standard, Version 2.0</ULINK></TERM>

<LISTITEM>

<PARA>The Unicode standard.</PARA>

</LISTITEM>

</VARLISTENTRY>

<VARLISTENTRY>

<TERM><ULINK URL="http://www.unicode.org/unicode/reports/tr8.html">Unicode Technical Report #8</ULINK></TERM>

<LISTITEM>

<PARA>Version 2.1 of the Unicode standard.</PARA>

</LISTITEM>

</VARLISTENTRY>

</VARIABLELIST>

</SECT1>

<SECT1>

<TITLE>Books and Printed Resources</TITLE>

<PARA>There are also a number of books worth checking out:</PARA>

<BIBLIOGRAPHY>

<BIBLIOENTRY ID="MALER96">

<TITLE>Developing <ACRONYM>SGML</ACRONYM> <ACRONYM>DTD</ACRONYM>s</TITLE>

<SUBTITLE>From Text to Model to Markup</SUBTITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Eve</FIRSTNAME>

<SURNAME>Maler</SURNAME>

</AUTHOR>

<AUTHOR>

<FIRSTNAME>Jeanne</FIRSTNAME>

<SURNAME>El Andaloussi</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>0-13-309881-8</ISBN>

<PUBLISHER>

<PUBLISHERNAME>Prentice-Hall PTR</PUBLISHERNAME>

<ADDRESS>	    <CITY>Upper Saddle River</CITY>

	    <STATE>New Jersey</STATE>

	  </ADDRESS>

</PUBLISHER>

<PUBDATE>1996</PUBDATE>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE>Practical <ACRONYM>SGML</ACRONYM></TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Erik</FIRSTNAME>

<SURNAME>van Herwijnen</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<EDITION>2</EDITION>

<ISBN>0-7923-9434-8</ISBN>

<PUBLISHER>

<PUBLISHERNAME>Kluwer Academic Press</PUBLISHERNAME>

</PUBLISHER>

<PUBDATE>1994</PUBDATE>

<BIBLIOMISC>An introductory book, but not a simple one.</BIBLIOMISC>

</BIBLIOENTRY>

<BIBLIOENTRY><?Pub Caret1>

<TITLE>The <ACRONYM>SGML</ACRONYM> Handbook</TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Charles</FIRSTNAME>

<SURNAME>Goldfarb</SURNAME>

</AUTHOR>

<AUTHOR>

<FIRSTNAME>Yuri</FIRSTNAME>

<SURNAME>Rubinksy</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>0-7923-9434-8</ISBN>

<PUBDATE>1991</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>Oxford University Press</PUBLISHERNAME>

</PUBLISHER>

<BIBLIOMISC>A reference book by the author of the <ACRONYM>SGML</ACRONYM> <ACRONYM>ISO</ACRONYM> Standard.</BIBLIOMISC>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE>SGML: an author's guide to the Standard Generalized Markup Language</TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Martin</FIRSTNAME>

<SURNAME>Bryan</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>0-201-17535-5</ISBN>

<PUBDATE>1988</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>Addison-Wesley Publishing Company</PUBLISHERNAME>

</PUBLISHER>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE>$GML: The Billion Dollar Secret</TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Chet</FIRSTNAME>

<SURNAME>Ensign</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>0-13-226705-5</ISBN>

<PUBDATE>1998</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>Prentice Hall</PUBLISHERNAME>

</PUBLISHER>

<BIBLIOMISC>Effective <ACRONYM>SGML</ACRONYM> evangelism.</BIBLIOMISC>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE>Creating Documents with <ACRONYM>XML</ACRONYM></TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Chris</FIRSTNAME>

<SURNAME>Maden</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>1-56592-518-1</ISBN>

<PUBDATE>1999</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>O'Reilly &amp; Associates</PUBLISHERNAME>

</PUBLISHER>

<BIBLIOMISC>An introductory book about <ACRONYM>XML</ACRONYM>.</BIBLIOMISC>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE><ACRONYM>XML</ACRONYM>: A Primer</TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Simon</FIRSTNAME>

<SURNAME>St. Laurent</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>1-5582-8592-X</ISBN>

<PUBDATE>1998</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>MIS:Press/IDG Books Worldwide</PUBLISHERNAME>

</PUBLISHER>

<BIBLIOMISC>Another introductory book about <ACRONYM>XML</ACRONYM>.</BIBLIOMISC>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE>Understanding SGML and XML Tools</TITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Peter</FIRSTNAME>

<SURNAME>Flynn</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>0-7923-8169-6</ISBN>

<PUBDATE>1998</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>Kluwer Academic Publishers</PUBLISHERNAME>

</PUBLISHER>

<BIBLIOMISC>The standard work on SGML/XML software.</BIBLIOMISC>

</BIBLIOENTRY>

<BIBLIOENTRY>

<TITLE>The LaTeX Web Companion</TITLE>

<SUBTITLE>Integrating TeX, HTML, and XML</SUBTITLE>

<AUTHORGROUP>

<AUTHOR>

<FIRSTNAME>Michel</FIRSTNAME>

<SURNAME>Goosens</SURNAME>

</AUTHOR>

<AUTHOR>

<FIRSTNAME>Sebastian</FIRSTNAME>

<SURNAME>Rahtz</SURNAME>

</AUTHOR>

</AUTHORGROUP>

<ISBN>0-201-43311-7</ISBN>

<PUBDATE>1999</PUBDATE>

<PUBLISHER>

<PUBLISHERNAME>Addison-Wesley Publishing Company</PUBLISHERNAME>

</PUBLISHER>

</BIBLIOENTRY>

</BIBLIOGRAPHY>

</SECT1>

<SECT1>

<TITLE><ACRONYM>SGML</ACRONYM>/<ACRONYM>XML</ACRONYM> Tools</TITLE>

<PARA>An attempt to provide a detailed description of all of the <ACRONYM>SGML</ACRONYM>/<ACRONYM>XML</ACRONYM>

tools available is outside the scope of this book.</PARA>

<PARA>For a list of recent

of <ACRONYM>SGML</ACRONYM> tools, check out Robin Cover's <ACRONYM>SGML</ACRONYM>/<ACRONYM>XML</ACRONYM> page at <ACRONYM>OASIS</ACRONYM>: <ULINK URL="http://www.oasis-open.org/cover">http://www.oasis-open.org/cover</ULINK>.</PARA>

<PARA>For a list of <ACRONYM>XML</ACRONYM> tools,

check out <ACRONYM>XML</ACRONYM>.com: <ULINK URL="http://www.xml.com/">http://www.xml.com/</ULINK>.</PARA>

</SECT1>

</APPENDIX><?Pub *0000009853 0>


<appendix ID="APP-CONFIG"><?dbhtml filename="app-config.html">
<title>Cookbook examples</title>

<example>
<title>Basic Configuration</title>
<programlisting>
# This is a basic ProFTPD configuration file (rename it to 
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

ServerName			"ProFTPD Default Installation"
ServerType			standalone
DefaultServer			on

# Port 21 is the standard FTP port.
Port				21
# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask				022

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances			30

# Set the user and group that the server normally runs at.
User				nobody
Group				nogroup

# Normally, we want files to be overwriteable.
&lt;Directory /*&gt;
  AllowOverwrite		on
&lt;/Directory&gt;

# A basic anonymous configuration, no upload directories.
&lt;Anonymous ~ftp&gt;
  User				ftp
  Group				ftp
  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias			anonymous ftp

  # Limit the maximum number of anonymous logins
  MaxClients			10

  # We want 'welcome.msg' displayed at login, and '.message' displayed
  # in each newly chdired directory.
  DisplayLogin			welcome.msg
  DisplayFirstChdir		.message

  # Limit WRITE everywhere in the anonymous chroot
  &lt;Limit WRITE&gt;
    DenyAll
  &lt;/Limit&gt;

&lt;/Anonymous&gt;
</programlisting>
</example>



<example>
<title>VirtualHost Config</title>
<programlisting>
# This sample configuration file illustrates creating two
# virtual servers, and associated anonymous logins.

ServerName			"ProFTPD"
ServerType			inetd

# Port 21 is the standard FTP port.
Port				21

# Global creates a "global" configuration that is shared by the
# main server and all virtualhosts.

&lt;Global&gt;
  # Umask 022 is a good standard umask to prevent new dirs and files
  # from being group and world writable.
  Umask				022
&lt;/Global&gt;

# Set the user and group that the server normally runs at.
User				nobody
Group				nogroup

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances                    30

# Maximum seconds a data connection may "stall"
TimeoutStalled			300

# First virtual server
&lt;VirtualHost ftp.virtual.com&gt;

  ServerName			"Virtual.com's FTP Server"

  MaxClients			10
  MaxLoginAttempts		1

  # DeferWelcome prevents proftpd from displaying the servername
  # until a client has authenticated.
  DeferWelcome			on

  # Limit normal user logins, because we only want to allow
  # guest logins.
  &lt;Limit LOGIN&gt;
    DenyAll
  &lt;/Limit&gt;

  # Next, create a "guest" account (which could be used
  # by a customer to allow private access to their web site, etc)
  &lt;Anonymous ~cust1&gt;
    User			cust1
    Group			cust1
    AnonRequirePassword		on

    &lt;Limit LOGIN&gt;
      AllowAll
    &lt;/Limit&gt;

    HideUser			root
    HideGroup			root

    # A private directory that we don't want the user getting in to.
    &lt;Directory logs&gt;
      &lt;Limit READ WRITE DIRS&gt;
        DenyAll
      &lt;/Limit&gt;
    &lt;/Directory&gt;

  &lt;/Anonymous&gt;

&lt;/VirtualHost&gt;

# Another virtual server, this one running on our primary address,
# but on port 4000.  The only access is to a single anonymous login.
&lt;VirtualHost our.ip.address&gt;

  ServerName			"Our private FTP server"
  Port				4000
  Umask				027

  &lt;Limit LOGIN&gt;
    DenyAll
  &lt;/Limit&gt;

  &lt;Anonymous /usr/local/ftp/virtual/a_customer&gt;

    User			ftp
    Group			ftp
    UserAlias			anonymous ftp

    &lt;Limit LOGIN&gt;
      AllowAll
    &lt;/Limit&gt;

    &lt;Limit WRITE&gt;
      DenyAll
    &lt;/Limit&gt;

    &lt;Directory incoming&gt;
      &lt;Limit WRITE&gt;
        AllowAll
      &lt;/Limit&gt;
    &lt;/Directory&gt;

  &lt;/Anonymous&gt;

&lt;/VirtualHost&gt;

</programlisting>
</example>

<example>
<title>Complex Configuration</title>
<programlisting>
#
# Virtual Hosting Server Configuration
# by M.Lowes &lt;markl@ftech.net&gt;
# for Frontier Internet Services Limited
#      (http://www.ftech.net/)
#
ServerName			"Master Webserver"
#
# Spawn from inetd?
#
#ServerType         inetd
#
# or maybe a standalone server...
#
ServerType          standalone
#
# don't give the server banner until _after_ authentication
#
DeferWelcome			off
#
# Some basic defaults
#
Port                  21
Umask                002
TimeoutLogin         120
TimeoutIdle          600
TimeoutNoTransfer    900
TimeoutStalled      3600
#
# No, I don't think we'll run as root!
#
User				ftp
Group				ftp
#
# This is a non-customer usable name, (ie they should be connecting via www.{domain})
# not 'hostname'.  Therefore let's dump them in a dummy account and wait for them to 
# scream.
#
DefaultRoot			/web/Legacy/
#
# Performance, let's do DNS resolution when we process the logs...
#
UseReverseDNS        off
#
# Where do we put the pid files?
#
ScoreboardFile			/var/run/proftpd
#
# Logging options
#
TransferLog			/var/spool/syslog/proftpd/xferlog.legacy
#
# Some logging formats
#
LogFormat         default "%h %l %u %t \"%r\" %s %b"
LogFormat			auth    "%v [%P] %h %t \"%r\" %s"
LogFormat			write   "%h %l %u %t \"%r\" %s %b"
#
# Global settings
#
&lt;Global&gt;
	DisplayLogin		   welcome.msg
	DisplayFirstChdir	   readme
	#
	# having to delete before uploading is a pain ;)
	#
	AllowOverwrite		   yes
	#
	# Turn off Ident lookups
	#
	IdentLookups         off
	#
	# Logging
	#
	# file/dir access
	#
	ExtendedLog		/var/spool/syslog/proftpd/access.log WRITE,READ write
	#
	#
	# Record all logins
	#
	ExtendedLog		/var/spool/syslog/proftpd/auth.log AUTH auth
	#
	# Paranoia logging level....
	#
   ##ExtendedLog    /var/spool/syslog/proftpd/paranoid.log ALL default
&lt;/Global&gt;

#
# Deny writing to the base server...
#
&lt;Limit WRITE&gt;
	DenyAll
&lt;/Limit&gt;


# --------------------------------------------
# Virtual Servers start here....
# 
# (Note: this is normally auto generated by a 
# script written in house).
# --------------------------------------------
#
# www.ftech.net.
# This is the default server
# Gets all the connections for www.{customer.domain}, 
# & www.ftech.net
#
&lt;VirtualHost www.ftech.net&gt;
	ServerAdmin		webmaster@Ftech.net
	ServerName		"Master Webserver"
	MaxLoginAttempts	2
	RequireValidShell	no
	TransferLog		/var/spool/syslog/proftpd/xferlog.www
	MaxClients		50
	DefaultServer		on
	DefaultRoot		~ !staff
	AllowOverwrite		yes

	#
	# No quickly do we kick someone out
	#
	TimeoutLogin			120
	TimeoutIdle			600
	TimeoutNoTransfer		900

	# --------------------------------------------
	# Got a Frontpage customer who keeps breaking things????
	#  - stick 'em in group fpage
	# --------------------------------------------
	&lt;Directory ~/public_html&gt;
	#
	# Block them from doing anything other than reading...
	#
		&lt;Limit STOR RNFR DELE&gt;
			DenyGroup fpage
		&lt;/Limit&gt;	
	&lt;/Directory&gt;
	#
	# ditto for ftp_root if it's there...
	#
	&lt;Directory ~/ftp_root&gt;
		&lt;Limit STOR RNFR DELE&gt;
			DenyALL
		&lt;/Limit&gt;	
	&lt;/Directory&gt;
	#
	# Limit by IP...
	#
	&lt;Directory /web/zsl&gt;
		&lt;Limit ALL&gt;
			Order Allow,Deny
			Allow 195.200.31.220
			Allow 212.32.17.0/26
			Deny ALL
		&lt;/Limit&gt;
	&lt;/Directory&gt;	

&lt;/VirtualHost&gt;

# --------------------------------------------
#
# Legacy server, left in because some people
# haven't realised it's gone yet.  Shove 'em into 
# a dummy $home
#
&lt;VirtualHost web-1.ftech.net&gt;
ServerAdmin		webmaster@Ftech.net
ServerName		"Legacy Web Upload Server"
MaxLoginAttempts	2
RequireValidShell	no
MaxClients		50
DefaultRoot		~ !staff
MaxClients		2
AllowOverwrite		yes
TransferLog		/var/spool/syslog/proftpd/xferlog.web-1
&lt;/VirtualHost&gt;

# --------------------------------------------
#
# ftp.ftech.net
#
&lt;VirtualHost ftp.ftech.net&gt;
ServerAdmin			ftpmaster@ftech.net
ServerName 			"Frontier Internet Public FTP Server"
TransferLog			/ftp/xferlog/ftp.ftech.net
MaxLoginAttempts		3
RequireValidShell		no
DefaultRoot			/ftp/ftp.ftech.net
AllowOverwrite			yes

#
# Auth files....
#
AuthUserFile			/var/conf/ftp/authfiles/passwd.ftp.ftech.net
AuthGroupFile			/var/conf/ftp/authfiles/group.ftp.ftech.net

# A basic anonymous configuration, no upload directories.
&lt;Anonymous /ftp/ftp.ftech.net&gt;
	User			ftp
  	Group			ftp
  	# We want clients to be able to login with "anonymous" as well as "ftp"
  	UserAlias		anonymous ftp
	RequireValidShell		no

	# Limit the maximum number of anonymous logins
  	MaxClients		50

  	# We want 'welcome.msg' displayed at login, and '.message' displayed
  	# in each newly chdired directory.

	&lt;Directory pub/incoming&gt;
		&lt;Limit STOR&gt;
			AllowAll
		&lt;/Limit&gt;
		&lt;Limit WRITE DIRS READ&gt;
			DenyAll
		&lt;/Limit&gt;
		&lt;Limit CWD XCWD CDUP&gt;
			AllowAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;

	&lt;Directory home&gt;
		&lt;Limit ALL&gt;
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;

   #
   # Limit access to the mirrors to LINX 
   # only
   #
   &lt;Directory mirrors&gt;
      &lt;Limit RETR&gt;
         Order Allow,Deny
         Allow .uk, .ftech.net
         Allow .vom.org.uk
         Deny ALL
      &lt;/Limit&gt;
   &lt;/Directory&gt;

  	# Limit WRITE everywhere in the anonymous chroot
  	&lt;Limit WRITE&gt;
    		DenyAll
  	&lt;/Limit&gt;


&lt;/Anonymous&gt;

&lt;/VirtualHost&gt;

# ----------------------------------------------------
# Virtual ftp with anon access, but no incoming
#
&lt;VirtualHost ftp.foo1.com&gt;
ServerAdmin             ftpmaster@foo1.com                     
ServerName              "Foo1 FTP Server"
TransferLog             /var/spool/syslog/xfer/ftp.foo1.com
MaxLoginAttempts        3
RequireValidShell       no
DefaultRoot             /ftp/ftp.foo1.com
User                    foo1
Group                   foo1
AllowOverwrite          yes

#
# Auth files....
#
AuthUserFile	/var/conf/ftp//authfiles/passwd.ftp.foo1.com
AuthGroupFile	/var/conf/ftp//authfiles/group.ftp.foo1.com

&lt;Anonymous /ftp/ftp.foo1.com&gt;
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20
	&lt;Limit WRITE&gt;
		DenyAll
	&lt;/Limit&gt;
&lt;/Anonymous&gt;
&lt;/VirtualHost&gt;


# ----------------------------------------------------
# ftp.foo2.com 
# Anon, no incoming, some private access areas 
#
&lt;VirtualHost ftp.foo2.com&gt;
ServerAdmin             ftpmaster@mcresearch.co.uk                     
ServerName              "MC Research FTP Server"
TransferLog             /var/spool/syslog/xfer/ftp.foo2.com
MaxLoginAttempts        3
RequireValidShell       no
DefaultRoot             /ftp/ftp.foo2.com
User                    foo2
Group                   foo2
AllowOverwrite          yes

#
# Auth files....
#
AuthUserFile	/var/conf/ftp//authfiles/passwd.ftp.foo2.com
AuthGroupFile	/var/conf/ftp//authfiles/group.ftp.foo2.com

&lt;Anonymous /ftp/ftp.foo2.com&gt;
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20

	&lt;Directory download&gt;
		&lt;Limit ALL&gt;
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;
	&lt;Limit WRITE&gt;
		DenyAll
	&lt;/Limit&gt;
&lt;/Anonymous&gt;

	&lt;Directory /ftp/ftp.foo2.com/pub&gt;
		&lt;Limit WRITE&gt;
			AllowUser mcres
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;

	&lt;Directory /ftp/ftp.foo2.com/download&gt;
		&lt;Limit ALL&gt;
			AllowUser mcres
			AllowUser customer
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;
&lt;/VirtualHost&gt;


# ----------------------------------------------------
# ftp.foo3.com
# 
#
&lt;VirtualHost ftp.foo3.com&gt;
ServerAdmin             ftpmaster@farrukh.co.uk                     
ServerName              "Farrukh FTP Archive"
TransferLog             /var/spool/syslog/xfer/ftp.foo3.com
MaxLoginAttempts        3
RequireValidShell       no
DefaultRoot             /web/farrukh2/ftp_root
User                    farrukh2
Group                   farrukh2
AllowOverwrite          yes

#
# Auth files....
#
AuthUserFile	/var/conf/ftp//authfiles/passwd.ftp.foo3.com
AuthGroupFile	/var/conf/ftp//authfiles/group.ftp.foo3.com

&lt;Anonymous /web/farrukh2/ftp_root&gt;
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20

	&lt;Directory pub/incoming/*&gt;
		&lt;Limit STOR&gt;
			AllowAll
		&lt;/Limit&gt;
		&lt;Limit WRITE DIRS READ&gt;
			DenyAll
		&lt;/Limit&gt;
		&lt;Limit CWD XCWD CDUP&gt;
			AllowAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;


	&lt;Directory pub/Incoming/*&gt;
		&lt;Limit STOR&gt;
			AllowAll
		&lt;/Limit&gt;
		&lt;Limit WRITE DIRS READ&gt;
			DenyAll
		&lt;/Limit&gt;
		&lt;Limit CWD XCWD CDUP&gt;
			AllowAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;
	#
	# block access to the secure areas by anon...
	#
	&lt;Directory fpub&gt;
		&lt;Limit ALL&gt;
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;

	&lt;Directory fgroup&gt;
		&lt;Limit ALL&gt;
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;
	&lt;Limit WRITE&gt;
		DenyAll
	&lt;/Limit&gt;
&lt;/Anonymous&gt;

	#
	# define user based access
	#
	&lt;Directory /web/farrukh2/ftp_root/fpub&gt;
		&lt;Limit ALL&gt;
			AllowUser farrukh
			AllowUser fguest
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;

	&lt;Directory /web/farrukh2/ftp_root/fgroup&gt;
		&lt;Limit ALL&gt;
			AllowUser farrukh
			AllowUser fgroup
			DenyAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;
&lt;/VirtualHost&gt;


# ----------------------------------------------------
# ftp.foo4.com 
# anon, with incoming upload 
#
&lt;VirtualHost ftp.foo4.com&gt;
ServerAdmin             ftpmaster@teamwork.co.uk                     
ServerName              "Teamwork FTP Server"
TransferLog             /var/spool/syslog/xfer/ftp.foo4.com
MaxLoginAttempts        3
RequireValidShell       no
DefaultRoot             /ftp/ftp.foo4.com
User                    foo4
Group                   foo4
AllowOverwrite          yes

#
# Auth files....
#
AuthUserFile	/var/conf/ftp//authfiles/passwd.ftp.foo4.com
AuthGroupFile	/var/conf/ftp//authfiles/group.ftp.foo4.com

&lt;Anonymous /ftp/ftp.foo4.com&gt;
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20

	&lt;Directory pub/incoming/*&gt;
		&lt;Limit STOR&gt;
			AllowAll
		&lt;/Limit&gt;
		&lt;Limit WRITE DIRS READ&gt;
			DenyAll
		&lt;/Limit&gt;
		&lt;Limit CWD XCWD CDUP&gt;
			AllowAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;


	&lt;Directory pub/Incoming/*&gt;
		&lt;Limit STOR&gt;
			AllowAll
		&lt;/Limit&gt;
		&lt;Limit WRITE DIRS READ&gt;
			DenyAll
		&lt;/Limit&gt;
		&lt;Limit CWD XCWD CDUP&gt;
			AllowAll
		&lt;/Limit&gt;
	&lt;/Directory&gt;

	&lt;Limit WRITE&gt;
		DenyAll
	&lt;/Limit&gt;
&lt;/Anonymous&gt;
&lt;/VirtualHost&gt;

# ----------------------------------------------------
# The end.... 
# ----------------------------------------------------


</programlisting>
</example>

<example>
<title></title>
<programlisting>
</programlisting>
</example>

</appendix>

</part>
<index> 
<para>...</para>
</index>

<colophon><?dbhtml filename="colophon.html">

<para>Initial authoring of this of this book were produced with the
DocBook DSSSL Stylesheets. In the best tradition of geek books I've
decided to find an animal to shove on this document, given my handle
I've picked the closest thing in nature to a flying hamster.  The
sugar glider.</para>

<!--
<mediaobject>
<imageobject>
<imagedata fileref="sugar_glider.jpg" format="jpg">
</imageobject>
<textobject>
<phrase>The Sugar Glider</phrase>
</textobject>
<caption>
<para>The Sugar Glider, the closest animal I can find to a real life
flying hasmter.
</para>
</caption>
</mediaobject>
-->
</colophon>

</book>