Proftpd

A User's Guide

Mark Lowes



Dedication

This book is dedicated to Lady Kayla.

Table of Contents
Preface
This Book's Audience
Why Read This Book?
Request for Comments
Organization of This Book
Acknowledgements
Copyrights and Trademarks
I. Introduction
1. Background
What is Proftpd
Who codes/maintains Proftpd?
Website & documenation
Bug reporting?
Availability
Mailing lists
Copyright Issues
The FTP protocol
2. Compilation and installing
Architecture
Installing packaged versions
Compiling from source
Compatibility Issues
linux
CVS
How do I get debug output
Patches
Using non-default modules
Plans for next version (1.3.x)
Longer term development
NT Support
New features/modules
3. Security Issues
Securing ftp servers
Daemon security
Password Issues
Server attacks
Firewall issues
Security by obscurity and warnings
How can I control what commands the server accepts?
Secure Sockets Layer (SSL)
4. Day to day issues
Starting and stopping your server
Timezone issues
Log management
FXP
II. Configuration
5. Getting ready
What do you want from your server?
Config file
Scoreboard file
Standalone or inetd?
Contexts
6. Generic issues
File permissions and UMASK
proftpd.umask
Setting the Umask
7. Virtual Hosting
What is virtual hosting
IP address space considerations
VirtualHost directive
Setting up a basic virtual host
Anonymous only servers
vhost notes
DNS issues
Reloading the config
8. Authentication
Password files
Pluggable Authentication Modules (PAM)
SQL
UserPassword
Lightweight Directory Access Protocol (LDAP)
Normal users can't login, only anon.
Other authentication methods
9. DefaultRoot and other issues
Locking users into a directory (chroot)
Finer grained control
Symlinks and chroot()
10. Anonymous Servers
How do I create individual anonymous FTP sites for my users?
I want to support normal login and Anonymous under a particular user
I only want to allow anonymous access to a virtual server.
Why doesn't Anonymous ftp work
Additional anonymous accounts
Secure upload facilities
11. Using AuthUserFiles
Formats
Choice of IDs
Shadow passwords
Permissions
ID-to-name mapping
12. Configuration for NAT
Basic information
Configuring ProFTPD
Configuring Linux
Security
13. Configuring ProFTPD for FTP over SSH
Basic premise
Client Configuration
Server Configuration
III. Advanced configuration
14. Access controls
Access limitation
Bandwidth control
Quota controls
Access controls
Limit
mod_ratio
Controlling permission changes
.ftpaccess files
15. Debugging Problems
Know the version
Know the modules
Perform syntax checks
Common problems
Locate log files
Collect debug information
16. Common Problems
17. More complex Configuration Issues
How can I stop my users from using their space as a warez repository
Can I rotate files out of an upload directory after upload?
How can I hide a directory from anonymous clients.
File/Directory hiding isn't working for me!
I want to prevent users from accessing a hidden directory
How do I setup a virtual FTP server?
How does <Limit LOGIN> work, and where should I use it?
18. Running ProFTPD As A Nonroot User
IV. WorkShop
19. Cleaned sections
Cleaned - part A
proftpd.filter
20. Initial ponderings from the list
stuff_a
proftpd.binding
proftpd.auth
proftpd.chmod
proftpd.ls
proftpd.sql
proftpd.timeouts
21. Compatibility and Integration
SQL
Hints
sendfile()
Regular expressions
22. Cookbook
V. References
I. Configuration Directives
AccessDenyMsg -- Customise the response on failed authentication
AccessGrantMsg -- Customise the response on successful authentication
Allow -- Access control directive
AllowAll -- Allow all clients
AllowChmod -- Enable the CHMOD command (deprecated)
AllowFilter -- Regular expression of command arguments to be accepted
AllowForeignAddress -- Control the use of the PORT command
AllowGroup -- Group based allow rules
Allow -- Permit logging to symlinked files
AllowOverwrite -- Enable files to be overwritten
AllowRetrieveRestart -- Allow clients to resume downloads
AllowStoreRestart -- Allow clients to resume uploads
AllowUser -- User based allow rules
AnonRatio -- Ratio directive
AnonRequirePassword -- Make anonymous users supply a valid password
Anonymous -- Define an anonymous server
AnonymousGroup -- Treat group members as anonymous users
AuthAliasOnly -- Allow only aliased login names
AuthGroupFile -- Specify alternate group file
AuthPAM -- Enable/Disable PAM authentication
AuthPAMAuthoritative -- Set whether PAM is the authoritive authentication scheme
AuthPAMConfig -- Select PAM service name
AuthUserFile -- Specify alternate passwd file
AuthUsingAlias -- Authenticate via Alias-name instead of mapped username
Bind -- Bind the server or Virtualhost to a specific IP address
ByteRatioErrMsg -- Ratio directive
CDPath -- Sets "search paths" for the cd command
Class -- Definition statements for class based tracking
Classes -- Enable Class based connection tracking
CommandBufferSize -- Limit the maximum command length
CwdRatioMsg -- Ratio directive
DefaultChdir -- Set starting directory for FTP sessions
DefaultQuota -- Sets the default quota
DefaultRoot -- Sets default chroot directory
DefaultServer -- Set the default server
DefaultTransferMode -- Set the default method of data transfer
DeferWelcome -- Don't show welcome message until user has authenticated
DeleteAbortedStores -- Enable automatic deletion of partially uploaded files
Deny -- Access control directive
DenyAll -- Deny all clients
DenyFilter -- Regular expression of command arguments to be blocked
DenyGroup -- Group based deny rules
DenyUser -- User based deny rules
Directory -- FIXME FIXME
DirFakeGroup -- Hide real file/directory group
DirFakeMode -- Hide real file/directory permissions
DirFakeUser -- Hide real file/directory owner
DisplayConnect -- Sets connect banner file
DisplayFirstChdir -- FIXME FIXME
DisplayGoAway -- FIXME FIXME
DisplayLogin -- FIXME FIXME
DisplayQuit -- FIXME FIXME
DisplayReadme -- FIXME FIXME
ExtendedLog -- FIXME FIXME
FileRatioErrMsg -- FIXME FIXME
FooBarDirective -- FIXME FIXME
Global -- FIXME FIXME
Group -- FIXME FIXME
GroupOwner -- FIXME FIXME
GroupPassword -- FIXME FIXME
GroupRatio -- Ratio directive
HiddenStor -- Enables more safe file uploads
HideGroup -- FIXME FIXME
HideNoAccess -- Block the listing of directory entries to which the user has no access permissions
HideUser -- FIXME FIXME
HostRatio -- Ratio directive
IdentLookups -- Toggle ident lookups
IgnoreHidden -- Treat 'hidden' files as if they don't exist
Include -- Load additional configuration directives from a file
LDAPAuthBinds -- FIXME FIXME
LDAPDefaultAuthScheme --  Set the authentication scheme/hash that is used when no leading {hashname} is present.
LDAPDefaultGID --  Set the default GID to be assigned to users when no uidNumber attribute is found.
LDAPDefaultUID --  Set the default GID to be assigned to users when no uidNumber attribute is found.
LDAPDNInfo -- Set DN information to be used for initial bind
LDAPDoAuth -- Enable LDAP authentication
LDAPDoGIDLookups --  Enable LDAP lookups for user group membership and GIDs in directory listings
LDAPDoUIDLookups --  Enable LDAP lookups for UIDs in directory listings
LDAPForceDefaultGID -- Force all LDAP-authenticated users to use the same GID.
LDAPForceDefaultUID -- Force all LDAP-authenticated users to use the same UID.
LDAPHomedirOnDemand --  Enable the creation of user home directories on demand
LDAPHomedirOnDemandPrefix --  Enable the creation of user home directories on demand
LDAPHomedirOnDemandPrefixNoUsername -- FIXFIXFIX
LDAPHomedirOnDemandSuffix --  Specify an additional directory to be created inside a user's home directory on demand.
LDAPNegativeCache -- Enable negative caching for LDAP lookups
LDAPQueryTimeout -- Set a timeout for LDAP queries
LDAPSearchScope -- Specify the search scope used in LDAP queries
LDAPServer -- Specify the LDAP server to use for lookups
LDAPUseTLS -- Enable TLS/SSL connections to the LDAP server.
LeechRatioMsg -- Sets the 'over ratio' error message
Limit -- FIXME FIXME
LogFormat -- Specify a logging format
LoginPasswordPrompt -- FIXME FIXME
LsDefaultOptions -- FIXME FIXME
MasqueradeAddress -- Configure the server address presented to clients
MaxClients -- Limits the number of users that can connect
MaxClientsPerHost -- Limits the connections per client machine
MaxHostsPerUser -- Limit the number of connections per userid
MaxInstances -- Sets the maximum number of child processes to be spawned
MaxLoginAttempts -- Sets how many password attempts are allowed before disconnection
MultilineRFC2228 -- FIXME FIXME
MySQLInfo -- Configures the MySQL driver
Order -- Configures the precedence of the Limit directives
PassivePorts -- Specify the ftp-data port range to be used
PathAllowFilter -- FIXME FIXME
PathDenyFilter -- FIXME FIXME
PersistentPasswd -- FIXME FIXME
PidFile -- FIXME FIXME
Port -- FIXME FIXME
PostgresInfo -- Postgres backend configuration (Deprecated)
PostgresPort -- Sets the port postgres is listening on
QuotaBlockName -- FIXME FIXME
QuotaBlockSize -- FIXME FIXME
QuotaCalc -- FIXME FIXME
QuotaExempt -- FIXME FIXME
Quotas -- FIXME FIXME
QuotaType -- FIXME FIXME
RateReadBPS -- FIXME FIXME
RateReadFreeBytes -- FIXME FIXME
RateReadHardBPS -- FIXME FIXME
RateWriteBPS -- FIXME FIXME
RateWriteFreeBytes -- FIXME FIXME
RateWriteHardBPS -- FIXME FIXME
RatioFile -- Ratio directive
Ratios -- FIXME FIXME
RatioTempFile -- Ratio directive
RequireValidShell -- Allow connections based on /etc/shells
RLimitCPU -- Configure the maximum CPU time in seconds used by a process
RLimitMemory -- Configure the maximum memory in bytes used by a process
RLimitOpenFiles -- Configure the maximum number of open files used by a process
RootLogin -- Permit root user logins
SaveRatios -- FIXME FIXME
ScoreboardPath -- Sets the path to the scoreboard file
ServerAdmin -- Set the address for the server admin
ServerIdent -- Set the message displayed on connect
ServerName -- Configure the name displayed to connecting users
ServerType -- Set the mode proftpd runs in
ShowDotFiles -- Toggle display of 'dotfiles'
ShowSymlinks -- Toggle the display of symlinks
SocketBindTight -- Controls how TCP/IP sockets are created
SQLAuthenticate --  Specify authentication methods and what to authenticate
SQLAuthoritative -- FIXFIXFIX
SQLAuthTypes -- FIXME FIXME
SQLConnectInfo -- FIXME FIXME
SQLDefaultGID -- FIXME FIXME
SQLDefaultHomedir -- FIXFIXFIX
SQLDefaultUID -- FIXME FIXME
SQLDoAuth -- FIXME FIXME
SQLDoGroupAuth -- FIXME FIXME
SQLEmptyPasswords -- Allow zero length passwords (DEPRECATED)
SQLEncryptedPasswords -- Assume SQL passwords are encrypted (DEPRECATED)
SQLGidField -- FIXFIXFIX
SQLGroupGIDField -- FIXFIXFIX
SQLGroupInfo -- FIXFIXFIX
SQLGroupMembersField -- FIXME FIXME
SQLGroupnameField -- FIXME FIXME
SQLGroupTable -- FIXME FIXME
SQLGroupWhereClause -- FIXFIXFIX
SQLHomedir -- FIXFIXFIX
SQLHomedirField -- FIXFIXFIX
SQLHomedirOnDemand -- FIXME FIXME
SQLLog -- FIXFIXFIX
SQLLogDirs -- FIXFIXFIX
SQLLogHits -- FIXFIXFIX
SQLLogHosts -- FIXFIXFIX
SQLLoginCountField -- FIXFIXFIX
SQLLogStats -- FIXFIXFIX
SQLMinID -- FIXME FIXME
SQLMinUserGID -- FIXFIXFIX
SQLMinUserUID -- FIXFIXFIX
SQLNamedQuery -- FIXFIXFIX
SQLPasswordField -- FIXFIXFIX
SQLProcessGrEnt -- FIXFIXFIX
SQLProcessPwEnt -- FIXFIXFIX
SQLRatios -- FIXFIXFIX
SQLRatioStats -- FIXFIXFIX
SQLScrambledPasswords -- FIXME FIXME
SQLShellField -- FIXME FIXME
SQLShowInfo -- FIXFIXFIX
SQLSSLHashedPasswords -- FIXME FIXME
SQLUidField -- FIXFIXFIX
SQLUserInfo -- FIXFIXFIX
SQLUsernameField -- FIXFIXFIX
SQLUserTable -- FIXFIXFIX
SQLUserWhereClause -- FIXFIXFIX
SQLWhereClause -- FIXME FIXME
SyslogFacility -- Set the facility level used for logging
SyslogLevel -- Set the verbosity level of system logging
SystemLog -- Redirect syslogging to a file
TCPAccessFiles -- Sets the access files to use
TCPAccessSyslogLevels -- Sets the logging levels for mod_wrap
tcpBackLog -- Control the tcp backlog in standalone mode
TCPGroupAccessFiles -- Sets the access files to use
tcpNoDelay -- Control the use of TCP_NODELAY
tcpReceiveWindow -- Set the size of the tcp receive window
tcpSendWindow -- Set the size of the tcp send window
TCPServiceName -- Configures the name proftpd will use with mod_wrap
TCPUserAccessFiles -- Sets the access files to use
TimeoutIdle -- Sets the idle connection timeout
TimeoutLogin -- Sets the login timeout
TimeoutNoTransfer -- Sets the connection without transfer timeout
TimeoutStalled -- Sets the timeout on stalled downloads
TimesGMT -- Toggle time display between GMT and local
TransferLog -- Specify the path to the transfer log
Umask -- Set the default Umask
UseFtpUsers -- Block based on /etc/ftpusers
UseGlobbing -- Toggles use of glob() functionality
User -- Set the user the daemon will run as
UserAlias -- Alias a username to a system user
UserDirRoot -- Set the chroot directory to a subdirectory of the anonymous server
UseReverseDNS -- Toggle rDNS lookups
UserOwner -- Set the user ownership of new files / directories
UserPassword -- Creates a hardcoded username/password pair
UserRatio -- Ratio directive
VirtualHost -- Define a virtual ftp server
WtmpLog -- Toggle logging to wtmp
II. Configuration by Module
mod_auth -- Authentication module
mod_code -- FIX ME FIX ME
mod_core -- Core module
mod_ldap -- LDAP authentication support
mod_log -- Logging support
mod_ls -- file listing functionality
mod_pam -- Pluggable authentication modules support
mod_quota -- Module to implement per-user quotas
mod_ratio -- FIX ME FIX ME
mod_readme -- "README" file support
mod_sample -- Example module
mod_site -- FIX ME FIX ME
mod_sql -- SQL support module
mod_unixpw -- UNIX style authentication methods
mod_wrap -- Interface to libwrap
mod_xfer -- FIX ME FIX ME
III. Configuration by Context
server config -- server config
Global -- Global
VirtualHost -- VirtualHost
Anonymous -- Anonymous
Limit -- Limit
.ftpaccess -- .ftpaccess
VI. Appendices
A. Resources
Latest Versions of DocBook
Resources for Resources
Introductory Material on the Web
References and Technical Noteson the Web
Internet RFCs
Specifications
Books and Printed Resources
SGML/XML Tools
B. Cookbook examples
Index
Colophon
List of Examples
2-1. Configuring for additional modules
3-1. Other approaches
4-1. logrotate configuration
4-2. logrotate configuration
4-3. logrotate configuration
4-4. Configuration fragment
8-1. Generic Linux PAM config
8-2. Redhat 6.* configuration
8-3. SuSe configuration
8-4. FreeBSD configuration
8-5. ...
8-6. A typical configuration fragment
9-1. Simple DefaultRoot setup
9-2. Sample svc.conf file
9-3. DefaultRoot, modified by system group
10-1. Access control using LIMIT
14-1. Configuration using classes
14-2. Simple throttling config
14-3. Rate limiting
14-4. .ftpaccess file
16-1. xinetd configuration
19-1. Filter example
21-1.
21-2. Contents
21-3. SQL database layout
21-4. Configuration fragment for SQL
21-5.
21-6. Contents
21-7. proftpd.conf
21-8. Updated authentication table
21-9. File tracking table
21-10. proftpd.conf
B-1. Basic Configuration
B-2. VirtualHost Config
B-3. Complex Configuration
B-4.

Preface

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.

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 suffcient. In Oct 1999 I started work on developing this document using the DocBook DTD in conjunction with the jade.

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.


This Book's Audience

This text is primarily targetted 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 Appendix A.

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.

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 managable scale.


Organization of This Book

This book is divided into xxxmultiplexxx parts. Part I: Introduction is an introduction to ftp, security and your first ftp server:

Chapter 1

A quick introduction to FTP

Part II: Configuration is a guide to getting the server configured and running

Chapter 1

A quick introduction to FTP


Chapter 1. Background


The FTP protocol

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.

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.

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 plaintext. There is a RFC defining the specification for encrypted passwords for use with ftp servers but this not had a widespread takeup.


Sockets and ports

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 adminitrative tasks on the server.

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.


Chapter 2. Compilation and installing

Being Open Source code Proftpd is availble 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 suffcient 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.


Chapter 3. Security Issues

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.

The cautious and security concious 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.

Server Security security holes weak passwords Abuse of server warez dumping ground


Server attacks

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


Firewall issues

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.

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 comparision, opening ports 20 and 21 is sufficient, nothing more complex is required.


Security by obscurity and warnings

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.


Chapter 4. Day to day issues


Timezone issues

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.

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

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.

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.

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


Log management

rotation, location, opening, log analysis


Chapter 5. Getting ready


Standalone or inetd?

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 programm listening on Port 21 whenn I tried inetd. > What are the differences etc. etc. etc. ? One difference is that the process controll (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.


Contexts

At present, ProFTPD has seven different configuration contexts: "main" server, <Anonymous>, <Directory>, <Global>, <Limit>, <VirtualHost>, and .ftpaccess files. These contexts are checked for in configuration handlers using the CHECK_CONF macro.

Valid Configuration contexts

Main server

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.

<Anonymous>

The <Anonymous> 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 <Anonymous> directory.

Note that since an <Anonymous> 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 <Anonymous> as well, unless overridden by a directive of the same name in the <Anonymous> context itself.

<Directory>

The <Directory> 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; <Limit> sections often appear in a <Directory> section as well.

<Global>

The description in the documentation for the <Global> 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 <VirtualHost> contexts with different parameters, those parameters take precedence over the <Global> parameters. This allows you to configure things for everyone equally, then tweak specific ervers individually, on a per-server basis.

<Limit>

The <Limit> context is used to place limits on who and how individual FTP commands, or groups of FTP commands, may be used.

.ftpaccess

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.


Chapter 6. Generic issues

File permissions and UMASK

What is a UMASK?

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

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


proftpd.umask

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

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.

Vincent Paglione wrote: > > Hello, > 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. 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.

Vincent Paglione wrote: > > > 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. > > -job > > 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

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.

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.

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 <%h> %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. <Directory /*> AllowOverwrite on Umask 022 </Directory> [...End] (the <VirtualHost>s have been removed) The Umask in the <Directory /*> 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 :)

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

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 mabe with a <Directory ...> only for ~/web/cgi-bin/ ? Thanks for any help, I'm desperate to have those cgis +x right after uplo= ad :)

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.

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.

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.

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.

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 <- This is the umask that you want.

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.

However, I am getting one strange problem. I've got this in my config: <Directory ~> <Limit ALL> Order deny,allow DenyGroup public AllowAll </Limit> <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> Order allow,deny AllowAll </Limit> </Directory>

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

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.

On Mon, Mar 06, 2000 at 09:08:57AM -0500, Matthew Eash wrote: > 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.

That's true (having forgot to account for that in my other comments :)

The directories need x set to allow 'searching'. You cannot execute a directory ;)

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

<Directory ~> Umask 0007 </Directory> 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!


Chapter 7. Virtual Hosting


vhost notes

I have tried to configure a name-based Virtual Host, but I always get to = the Directory which I configured in the <global>-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).

> I have tried to configure a name-based Virtual Host, but I always get > to the Directory which I configured in the <global>-area. > All Hosts should have the same IP (212.172.160.148). > 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 <global>-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 ScoreboardPath /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" <Global> 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 </Global> <VirtualHost 212.172.160.148> 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 </VirtualHost> # 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:<hashed password>:<id>:<group>::<homedir>:/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: <Global> ... DefaultRoot /var/ftp/data/group-a groupa,!staff DefaultRoot /var/ftp/data/group-b groupb,!staff ... </Global> 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. <Directory private> HideGroup crack </Directory> <Directory pub/consult/> HideGroup consult </Directory> 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 <virtualhost> 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? :) <VirtualHost xxx.xxx.xxx.xxx> DefaultRoot /usr/local/httpd/htdocs/ ServerName "xxx mainserver" ExtendedLog /var/log/proftpd.paranoid_log ALL default <Limit STOR> AllowAll </Limit> <Directory /> AllowOverwrite on <Limit STOR CWD CDUP> AllowAll </Limit> </Directory> </VirtualHost> 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."


Reloading the config

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.


What happens to connected users?

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.

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.

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

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


Chapter 8. Authentication

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.

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.


Pluggable Authentication Modules (PAM)

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.

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.


Typical PAM configuration

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.

There is a README.Pam in the top directory of the ProFTPD install directory :


Lightweight Directory Access Protocol (LDAP)

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.

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.


Ldap notes

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

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.

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.

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,

On Wed, Jan 12, 2000 at 11:05:15AM +0100, Juli=E1n Romero wrote: > 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. 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.

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?

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 <Directory /*> AllowOverwrite on </Directory> <Anonymous ~> User ftp Group ftp UserAlias anonymous ftp MaxClients 10 DisplayLogin welcome.msg DisplayFirstChdir .message <Directory *> <Limit WRITE> DenyAll </Limit> </Directory> <Directory incoming> <Limit READ WRITE> DenyAll </Limit> <Limit STOR> AllowAll </Limit> </Directory> </Anonymous> --------------------- % % 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.

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?

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.

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?

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] - => get_ldapmessage_controls [28/Feb/2000:15:28:28 +0100] - <= 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] - => slapi_pw_find value: "password" [28/Feb/2000:15:28:28 +0100] - <= slapi_pw_find matched "password" using scheme "clear" [28/Feb/2000:15:28:28 +0100] - => 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] - <= 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?

---------------------------------- > What attribute is "allowedservices"? I don't have that attribute > in my Directory Server. Is it a standard attribute or something > you've created? > 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: > What attribute is "allowedservices"? I don't have that attribute > in my Directory Server. Is it a standard attribute or something > you've created? > 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 **

Just a wild guess - what about escapeing the whitespace ? like : LDAPDNInfo cn=3DDirectory\ Manager,dc=3Ddatelec,dc=3Dcom [ ] > % 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 : > % > % > LDAPServer ldap_shagga > % > 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 : > % > % > [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; oops ... sorry :) > 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" [ ] I've tried : same error... So I've to change the name of my Cn...... Exact ?

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 : > LDAPServer ldap_shagga > LDAPDNinfo cn="Directory Manager",dc=datelec,dc=com micr0sc0n > LDAPDoAuth on "dc=People,dc=datelec,dc=com" > LDAPDoUIDLookups off > LDAPDoGIDLookups off > But I guess your module doesn't parse correctly the cn field cause in my ldap server logs I get this error : > [16/Feb/2000:12:47:20 +0100] conn=7371 fd=164 slot=164 connection from 192.168.120.164 to 192.168.120.160 > [16/Feb/2000:12:47:20 +0100] conn=7371 op=0 BIND dn="cn="Directory" method=128 version=2 > [16/Feb/2000:12:47:20 +0100] conn=7371 op=0 RESULT err=32 tag=97 nentries=0 etime=0 > [16/Feb/2000:12:47:20 +0100] conn=7371 op=-1 fd=164 closed - B1 > Normally that should be (like a good connection): > [16/Feb/2000:12:47:59 +0100] conn=7372 fd=164 slot=164 connection from 192.168.120.165 to 192.168.120.160 > [16/Feb/2000:12:47:59 +0100] conn=7372 op=0 BIND dn="cn=Directory Manager" method=128 version=2 > [16/Feb/2000:12:47:59 +0100] conn=7372 op=0 RESULT err=0 tag=97 nentries=0 etime=0 >

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

% 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 : % % > LDAPServer ldap_shagga % > 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 : % % > [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" [ ]

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) > shagga (root) /tmp/proftpd-1.2.0pre10 > ./proftpd -l > Compiled-in modules: > mod_core.c > mod_auth.c > mod_xfer.c > mod_site.c > mod_ls.c > mod_unixpw.c > mod_log.c > mod_pam.c > mod_ratio.c > mod_ldap.c > mod_quota.c > My configuration file is something like that : > ServerName "Internal FTP Server" > ServerType StandAlone > DefaultServer on > Port 21 > > User nobody > Group nogroup > > MaxInstances 30 > > TimeoutStalled 300 > > DisplayLogin welcome.msg > DisplayFirstChdir .message > > RootLogin on > > AuthPAMAuthoritative off > > LDAPServer ldap_shagga > LDAPDNinfo cn=admin,dc=datelec,dc=com password > LDAPDoAuth on "dc=People,dc=datelec,dc=com" > LDAPDoUIDLookups off > LDAPDoGIDLookups off > When I start proftpd ( proftpd -d 5 -n ) and i try to connect to the server, I get this message : > shagga - ProFTPD 1.2.0pre10 standalone mode STARTUP > shagga (snardone.datelec.ch[192.168.120.165]) - connected - local : 192.168.120.164:21 > shagga (snardone.datelec.ch[192.168.120.165]) - connected - remote : 192.168.120.165:3451 > shagga (snardone.datelec.ch[192.168.120.165]) - ProFTPD terminating (signal 11) > 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

> 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? 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). > > > % 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. 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 <snip> 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) <snip> 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) % % > shagga (root) /tmp/proftpd-1.2.0pre10 > ./proftpd -l % > Compiled-in modules: % > mod_core.c % > mod_auth.c % > mod_xfer.c % > mod_site.c % > mod_ls.c % > mod_unixpw.c % > mod_log.c % > mod_pam.c % > mod_ratio.c % > mod_ldap.c % > mod_quota.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] % > LDAPServer ldap_shagga % > LDAPDNinfo cn=admin,dc=datelec,dc=com password % > LDAPDoAuth on "dc=People,dc=datelec,dc=com" % > LDAPDoUIDLookups off % > 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 : % % % > shagga - ProFTPD 1.2.0pre10 standalone mode STARTUP % > shagga (snardone.datelec.ch[192.168.120.165]) - connected - local : 192.168.120.164:21 % > shagga (snardone.datelec.ch[192.168.120.165]) - connected - remote : 192.168.120.165:3451 % > 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: > 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 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) % % > shagga (root) /tmp/proftpd-1.2.0pre10 > ./proftpd -l % > Compiled-in modules: % > mod_core.c % > mod_auth.c % > mod_xfer.c % > mod_site.c % > mod_ls.c % > mod_unixpw.c % > mod_log.c % > mod_pam.c % > mod_ratio.c % > mod_ldap.c % > mod_quota.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] % > LDAPServer ldap_shagga % > LDAPDNinfo cn=admin,dc=datelec,dc=com password % > LDAPDoAuth on "dc=People,dc=datelec,dc=com" % > LDAPDoUIDLookups off % > 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 : % % % > shagga - ProFTPD 1.2.0pre10 standalone mode STARTUP % > shagga (snardone.datelec.ch[192.168.120.165]) - connected - local : 192.168.120.164:21 % > shagga (snardone.datelec.ch[192.168.120.165]) - connected - remote : 192.168.120.165:3451 % > 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?

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.

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

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.

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

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

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 <bert@be.easynet.net> and Krzysztof Dabrowski <brush@pol.pl> for ideas/patches in this area.)

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

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.

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.


Why use LDAP over SQL?

> >- Because LDAP is a standard, SQL is not. > > Excuse me? I think you're misinformed here, as SQL is a standard. What > various companies have done with propietary "extensions" is another issue, > but you can always choose not to use them and stick with core. But still , > I think I understand what you're getting at: portability.

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.

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.

> I have been considering using LDAP, which is what prompted my inquiry in > the first place. Feedback I've gotten from a few people implementing it is > that it works great, but does not scale as well as SQL, is more resource > intensive, and that for large user bases (e.g. couple hundred thousand) is > much slower. But I've not yet delved into this thoroughly enough to make a > sound evaluation.

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.

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

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.

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.

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


Chapter 9. DefaultRoot and other issues

Locking users into a directory (chroot)

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 <Anonymous> directive. For more normal users the DefaultRoot directive is required

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

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:

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

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.


Security Implications

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.

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.

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)

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

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.


Required files

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:

/dev/tcp
/dev/ticotsord
/dev/udp
/dev/tcp

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


Symlinks and chroot()

Contributor: Rod Whitworth <rodw at witworx dot com>

There have been many questions on the ProFTPD user mailing list about why symlinked directories are not visible to chrooted users (this includes <Anonymous> 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.

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.


How Links Work

There are two types of links in Unix: hard and symbolic.

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:

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

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:

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

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:

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

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


Filesystem Tricks

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.

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:

    * 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

The same technique can be used for <Anonymous> directories, which also operate in a chroot()ed environment.

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.

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.


Chapter 10. Anonymous Servers

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.


How do I create individual anonymous FTP sites for my users?

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.

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 <VirtualHost>, 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 <Directory> block to carefully limit outside access to each user's site.

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

 <VirtualHost my.per-user.virtual.host.address>
 
 # the next line limits all logins to this virtual host, so that only
 anonftp users can connect
 
 <Limit LOGIN>
 DenyGroup !anonftp
 </Limit>
 
 # limit access to each user's anon-ftp directory, we want read-only
 except on incoming
 
 <Directory ~/anon-ftp>
 
 <Limit WRITE>
 DenyAll
 </Limit>
 
 </Directory>
 
 # permit stor access to each user's anon-ftp/incoming directory,
 but deny everything else
 
 <Directory ~/anon-ftp/incoming>
 
 <Limit STOR>
 AllowAll
 </Limit>
 <Limit READ WRITE>
 DenyAll
 </Limit>
 
 </Directory>
 
 # 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
 
 </VirtualHost>

Chapter 11. Using AuthUserFiles

Originally by TJ Saunders

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.

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.

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.


Shadow passwords

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.

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.


Chapter 12. Configuration for NAT

Contributed by Tobias Ekbom


Chapter 13. Configuring ProFTPD for FTP over SSH

Chapter by TJ Saunders


Server Configuration

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:

#!/bin/sh
  sleep 10

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:

ssh -l test -f -L3000:ftpserver:21 ftpserver true && ftp localhost 3000

You'll also need to use the AllowForeignAddress configuration directive to your configuration file:

AllowForeignAddress on

or proftpd will reject the passive transfer connections and log:

SECURITY VIOLATION: Passive connection from {host} rejected

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.


Chapter 14. Access controls

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.


Access limitation


Access classes

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

Ok, been playing again :) Example of a real life classes based config.

Example 14-1. Configuration using classes

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

<Global>
	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)$"
</Global>

# ----------------------------------------------------
# ftp.linux.co.uk ("Linux.co.uk FTP Archive") 
# Contact : zathras@linux.co.uk
#
<VirtualHost 195.200.4.15>
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

<Anonymous /ftp/ftp.linux.co.uk>
        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.
	#
	<Directory pub/incoming/*>
		AllowOverwrite off
		<Limit STOR CWD XCWD CDUP MKD>
			AllowAll
		</Limit>
		<Limit READ DELE WRITE DIRS>
			DenyAll
		</Limit>
	</Directory>
</Anonymous>
</VirtualHost>

Bandwidth control

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.

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.

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.


Limiting the total usage by a VirtualHost

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 ?

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.

And a comment: if the normal cases one should not use "RateReadHardBPS on", it is cruel to the users. :)

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. >From section 6.16 of the FAQ:

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

A section of my proftpd.conf might look like this: <Global> MaxClients 6 RateReadBPS 10000 </Global> It looks like total bandwidth should be limited to ~60 KB/s (after restarting inetd). However, this is not the case. Any suggestions?

On Mon, Feb 28, 2000 at 05:22:12PM -0500, dboyles@r75h121.res.gatech.edu wrote: > "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." > > A section of my proftpd.conf might look like this: > > <Global> > MaxClients 6 > RateReadBPS 10000 > </Global> > > It looks like total bandwidth should be limited to ~60 KB/s (after > 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.

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.

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." <Global> <Limit LOGIN> AllowGroup ftp </Limit> DefaultRoot /home/ftp </Global> <Directory /*> AllowOverwrite off </Directory>

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.

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." <Global> <Limit LOGIN> AllowGroup ftp </Limit> DefaultRoot /home/ftp </Global> <Directory /*> AllowOverwrite off </Directory>

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

# 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. <Directory /*> AllowOverwrite on </Directory> # A basic anonymous configuration, no upload directories. <Anonymous ~ftp> 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 <Limit WRITE> DenyAll </Limit> </Anonymous>

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: <Anonymous /somefilepath/somedir > User ftp Group ftp UserAlias anonymous ftp RateReadBPS 12000 RequireValidShell off MaxClients 15 <Limit LOGIN> AllowAll </Limit> <Limit WRITE> DenyAll </Limit> </Anonymous>

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

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

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:

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

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: pam >= 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


Quota controls


Limit

(Problem #1 :) Currently I have the following: <Directory /home> <Limit LIST NLST> DenyAll </Limit> </Directory> <Directory /home/*/> <Limit LIST NLST> AllowAll </Limit> </Directory> 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 <Directory> 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 <Directory> 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.


mod_ratio

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


Chapter 15. Debugging Problems

Originally by TJ Saunders

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.


Collect debug information

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:

proftpd -nd5

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:

proftpd -nd5 2>&1 >& /path/to/debug/file

and send that file, compressed, along with your post.

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.

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.

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.

The following document describes how to ask good questions that are likely to be answered:

http://www.tuxedo.org/~esr/faqs/smart-questions.html

Chapter 16. Common Problems


Chapter 17. More complex Configuration Issues

Problems encountered in trying to make the server behave exactly as required after compilation and installation are complete and the server is running.


How does <Limit LOGIN> work, and where should I use it?

The <LOGIN> 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 <Limit LOGIN> 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.

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 <Limit LOGIN> applies. Normally, <Limit> directive blocks are allowed in the server config, <VirtualHost>, <Anonymous> and <Directory> contexts. However, <Limit LOGIN> should not be used in a <Directory> context, as clients do not connect/login to a directory (and thus it is meaningless).

By way of example, the following configuration snippet illustrates a <Limit LOGIN> deny which will cause any incoming connections from the 10.1.1.x subnet to be immediately disconnected, without a welcome message: ... <Limit LOGIN> Order deny,allow Deny from 10.1.1. Allow from all </Limit> ...

Next, an example of a configuration using <Limit LOGIN> that will not immediately disconnect an incoming client, but will return "Login invalid" for all login attempts except anonymous. ... <Limit LOGIN> DenyAll </Limit> <Anonymous ~ftp> ... <Limit LOGIN> AllowAll </Limit> ...


Chapter 18. Running ProFTPD As A Nonroot User

Chapter by TJ Saunders

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.

Here are the configuration directives that you will need to use in order to run the server without root privileges:

Port

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

AuthUserFile, AuthGroupFile

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

AuthPAM

PAM authentication requires root privileges. This directive will need to be set off.

WtmpLog

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:

host.domain.net (localhost[127.0.0.1]) - wtmpx /var/adm/wtmpx: Permission denied
User, Group

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

Note that other configuration directives will be affected by the lack of root privileges: DefaultRoot will not work, nor will <Anonymous> sections, nor UserOwner. Basically any operation that requires root privileges will be disabled.

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


Chapter 19. Cleaned sections

Cleaned - part A


proftpd.filter

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 ScoreboardPath /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" <mliu@rmsys.net> Reply-To: proftpd@proftpd.org To: "Proftpd@Proftpd. Net" <proftpd@proftpd.org> 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 ScoreboardPath /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 <Global> 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


Chapter 20. Initial ponderings from the list

stuff_a


Installation

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.

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/

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.

3. 6 files in i386 directory, ...core... ...inetd... and ...standalone... for versions 9 and 10 OK, I want standalone version 10 so I definatelly need that small 4,21 file ... and I presume that core file for version 10 is needed as well ...

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

Also, there is no mailing list archive, so I am posting this question after reading faq and user guide.

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.

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.


proftpd.binding

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: > Just compiled and installed pre9 w/ the TYPE A N patch... Running in > standalone mode works great...Running from inetd gives the following in > /var/log/messages - > Dec 17 15:22:51 dmz1 proftpd[7163]: dmz1.freitrater.com - bind() failed in > 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

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.


proftpd.auth

On Mon, Apr 03, 2000 at 06:51:49PM -0700, Irwan Hadi wrote: > Is it possible to make proftpd use it's own username + password and not use > I don't want use the system account because the more user in /etc/passwd > (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.tm**, has written a message, and here is the reply : >On Mon, Apr 03, 2000 at 06:51:49PM -0700, Irwan Hadi wrote: >AuthUserFile >DefaultRoot > >or > >SQL/LDAP authentication >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.

In the basic /usr/local/etc/proftpd.conf you will need to add this line: AuthUserFile <File path> Where <File Path> 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 <File Path> 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: > > In the basic /usr/local/etc/proftpd.conf you will need to add >this line: > >AuthUserFile <File path> > > Where <File Path> 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 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.

Irwan Hadi wrote: > 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. > 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. :-)

#--- 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 <password> -- The password to encrypt\n"; print "\t-s <salt> -- 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...

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

#--- 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 <password> -- The password to encrypt\n"; print "\t-s <salt> -- 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...

At 09:29 07/04/2000 -0400, **Michael Grabenstein**, has written a message, and here is the reply : >Irwan Hadi wrote: > I use Perl to encrypt the password, or if you already have a /etc/passwd to >start with, then just copy it... > Attached is a simple Perl script that will encrypt a plain text password >sent >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: > 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) ? 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: > 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. Is must be crypted, there is a script in the contrib directory (genuser.pl IIRC) to do this.

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, <limit login> allowall </limit> 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. :)

On Wed, Mar 22, 2000 at 09:35:15AM -0500, Alderman, Sean wrote: > You might want to check the archives. I believe someone had built a perl > script and posted it to the list to create encrypted username/password pairs > 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)]; } > Syntax is "htpasswd.pl userid password". Output is > "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?

I was wondering, what utility do you use to generate the encrypt shadow passwd??

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: > You might want to check the archives. I believe someone had built a perl > script and posted it to the list to create encrypted username/password pairs > for custom proftpd auth files. genuser.pl in the contrib/ directory. > genuser.pl in the contrib/ directory. > > Mark

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

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?

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?

On Sat, 25 Mar 2000, Vincent Paglione wrote: >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? >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.

> and save this as your $CONF/authpasswdfile and then reference it from > 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?

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.

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.

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.

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.

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

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.

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.

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

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

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

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.

On Mon, Jan 31, 2000 at 07:29:13AM -0500, Alicia da Conceicao wrote: > 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 [...] > I have added the following directives to proftpd.conf: > > AuthUserFile /opt/proftpd/etc/passwd > AuthGroupFile /opt/proftpd/etc/group > PersistentPasswd off [...] > 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'. [..] > 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 Given that you don't appear to have PAM installed on your machine you don't need to concern yourself with the "AuthPAMAuthoritative" directive.

>> I have added the following directives to proftpd.conf: >> AuthUserFile /opt/proftpd/etc/passwd >> AuthGroupFile /opt/proftpd/etc/group >> PersistentPasswd off >> ... >> 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. 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?

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.

On Fri, Jan 28, 2000 at 04:38:26PM +0100, Chris Loos wrote: > Hi, > 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... Check the FAQ.... AuthPAMAuthoritive off (check the spelling of the directive) PersistantPasswd off (IIRC)

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.

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)

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)<<< 220 members.friendfactory.com Net::FTP=GLOB(0xc9268)>>> user whoami Net::FTP=GLOB(0xc9268)<<< 331 Password required for whoami. Net::FTP=GLOB(0xc9268)>>> PASS .... Net::FTP=GLOB(0xc9268)<<< 230 User whoami logged in. Net::FTP=GLOB(0xc9268)>>> QUIT Net::FTP=GLOB(0xc9268)<<< 221 Goodbye. Net::FTP=GLOB(0xc604c)<<< 220 members.friendfactory.com Net::FTP=GLOB(0xc604c)>>> user whatsyrname Net::FTP=GLOB(0xc604c)<<< 331 Password required for whatsyrname. Net::FTP=GLOB(0xc604c)>>> PASS .... Net::FTP=GLOB(0xc604c)<<< 530 Login incorrect. Net::FTP=GLOB(0xc604c)>>> QUIT Net::FTP=GLOB(0xc604c)<<< 421 Login Timeout (300 seconds): closing control connection. >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 -

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?

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.

John Hearns wrote: > > 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. 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.

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

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 <VirtualHost>? 5. How is an <Anonymous> section inside a <VirtualHost> influenced? 6. If (1) is true, what is the significance of the UIDs and GIDs?

Note to Mark: Maybe we should clarify the documentation on the AuthUserFile directive? > 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. > 3. Under which user will the VirtualHost execute? Pardon? Under whatever user you've specified via the User directive of course. > 4. How do they influence a chroot'd <VirtualHost>? They don't really. Whatever you've listed as the home directories is used in determined a user-chroot jail as appropriate. > 5. How is an <Anonymous> section inside a <VirtualHost> influenced? Huh? > 6. If (1) is true, what is the significance of the UIDs and GIDs? > 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.

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.

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 <Anonymous ~ftp> 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 <Limit WRITE> AllowUser User1 AllowUser User2 DenyAll </Limit> <Limit STOR> AllowAll </Limit> Ratios on UserRatio * 0 0 1 0 UserRatio user1 0 0 10 0 UserRatio user2 0 0 0 0 </Anonymous> How do I generate the AuthUserFile so that this will work?? Thanks in advance!

I'm using pre9, with an anon section like this: <Anonymous /virtual/ftp> User virtual Group virtual UserAlias joe virtual AuthAliasOnly on </Anonymous> This works as expected -- I can't login anonymously with "virtual", but I can with "joe". When I do this: <Anonymous /virtual/ftp> User virtual Group virtual UserAlias joe virtual AuthAliasOnly off </Anonymous> There is no change -- I still can't login anonymously with "virtual", but I should be able to. Now, if I do this: <Anonymous /virtual/ftp> User virtual Group virtual UserAlias joe virtual # AuthAliasOnly off </Anonymous>

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

Yes, you can. Go to httpd://www.proftpd.org Read the Documentation. Using an alternate password is documented very well. Tsanko Stoev Lyon College > Can I use a different password file (other than /etc/passwd) with in the > same domain???

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

I tried that already but it still does not work. >From: Matt Critcher <MCritch@lifeplususa.com> >Reply-To: proftpd@proftpd.org >To: "'proftpd@proftpd.org'" <proftpd@proftpd.org> >Subject: RE: [ProFTPD] Login Problems >Date: Wed, 15 Mar 2000 08:33:14 -0600 > >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.

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.

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.


proftpd.chmod

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

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: >=20 > I'm not even using Anonymous Blocks...! >=20 > What I have is a Directory Block with users home Dirs and within that j= ust a > Limit block that say Everything is allowed - at least that's what my co= nfig > has come down to when trying to solve this problem... :) >=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... > > Hi, > > Simple Question - (Hard answer?): > > 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... > > 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 <anonymous> 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 <limit ..> 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 ?


proftpd.ls

if I'm ftping from a remote server. ftp> ls 200 PORT command successful. 421 Service not available, remote server has closed connection edward> 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.

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 > > Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1]) > > - bind() failed in inet_create_connection(): Permission > > denied > > 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

Thanks for help, Chris

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

> > Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1]) > > - bind() failed in inet_create_connection(): Permission > > denied > > 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

-- 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.tm ([212.32.5.30] helo=flyhmstr.vom.tm) by weasel.vom.tm with esmtp (Exim 3.12 #1) id 12PRgv-0007aS-00 for mark@weasel.vom.tm; Mon, 28 Feb 2000 15:02:33 +0000 Received: from starbase.tos.net ([209.212.188.150]) by flyhmstr.vom.tm with esmtp (Exim 3.11 #1 (Debian)) id 12PRgt-0006DF-00 for <hamster@vom.tm>; 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 <hamster@vom.tm> To: proftpd@proftpd.org Subject: Re: [ProFTPD] Can't do "ls" command Message-ID: <20000228145341.A29107@weasel.vom.tm> References: <002101bf81f9$3f83b820$843365c1@kakoi.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <002101bf81f9$3f83b820$843365c1@kakoi.co.jp>; from kasiwagi@kakoi.co.jp on Mon, Feb 28, 2000 at 11:36:44PM +0900 Resent-Message-ID: <7cBfHD.A.yAC.Owou4@starbase.tos.net> Resent-From: proftpd@proftpd.org Reply-To: proftpd@proftpd.org X-Mailing-List: <proftpd@proftpd.org> 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: > Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1]) > - bind() failed in inet_create_connection(): Permission > denied Did you start ftp as root? Mark

-- The Flying Hamster <hamster@suespammers.org> 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.tm ([212.32.5.30] helo=flyhmstr.vom.tm) by weasel.vom.tm with esmtp (Exim 3.12 #1) id 12PS2h-0007bQ-00 for mark@weasel.vom.tm; Mon, 28 Feb 2000 15:25:03 +0000 Received: from starbase.tos.net ([209.212.188.150]) by flyhmstr.vom.tm with esmtp (Exim 3.11 #1 (Debian)) id 12PS2e-0006I8-00 for <hamster@vom.tm>; 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: <004801bf81ff$1c09a160$843365c1@kakoi.co.jp> From: "Norio Kashiwagi" <kasiwagi@kakoi.co.jp> To: <proftpd@proftpd.org> References: <002101bf81f9$3f83b820$843365c1@kakoi.co.jp> <20000228145341.A29107@weasel.vom.tm> 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: <NLL9UC.A.fJC.ZEpu4@starbase.tos.net> Resent-From: proftpd@proftpd.org Reply-To: proftpd@proftpd.org X-Mailing-List: <proftpd@proftpd.org> 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

> > Feb 28 14:00:17 edward proftpd[776]: edward (localhost[127.0.0.1]) > > - bind() failed in inet_create_connection(): Permission > > denied > > 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

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 >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 -> ../../../rea l_dir/test lrwxrwxrwx 1 root root 17 Feb 29 06:26 real_dir -> ../../../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.

Thanks, Andreas Wehler

+------ "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?

Charles Seeger wrote: > > +------ "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). 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?

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.tm ([212.32.5.30] helo=flyhmstr.vom.tm) by weasel.vom.tm with esmtp (Exim 3.12 #1) id 12JQ67-0000GC-00 for mark@weasel.vom.tm; Sat, 12 Feb 2000 00:07:39 +0000 Received: from starbase.tos.net ([209.212.188.150]) by flyhmstr.vom.tm with esmtp (Exim 3.11 #1 (Debian)) id 12JQ65-0001KI-00 for <hamster@vom.tm>; 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" <lan@recol.com> To: <proftpd@proftpd.org> Date: Fri, 11 Feb 2000 15:44:38 -0500 Message-ID: <NDBBLOICLKHIHOKDAEGKAEGFCBAA.lan@recol.com> 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: <56183983FF5AD31185F70060B06DF1683FF394@dot.ctcts.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [ProFTPD] Can't do "ls" Resent-Message-ID: <JDSsr.A.bMC.dRHp4@starbase.tos.net> Resent-From: proftpd@proftpd.org Reply-To: proftpd@proftpd.org X-Mailing-List: <proftpd@proftpd.org> 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

I can do a "ls" if I ftp from localhost. However, "ls" does not work if I'm ftping from a remote server. ======= > | 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). 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?

I can do a "ls" if I ftp from localhost. However, "ls" does not work if I'm ftping from a remote server. ftp> ls 200 PORT command successful. It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14. Any ideas?

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.tm ([212.32.5.30] helo=flyhmstr.vom.tm) by weasel.vom.tm with esmtp (Exim 3.12 #1) id 12KAP1-0006ds-00 for mark@weasel.vom.tm; Mon, 14 Feb 2000 01:34:15 +0000 Received: from starbase.tos.net ([209.212.188.150]) by flyhmstr.vom.tm with esmtp (Exim 3.11 #1 (Debian)) id 12KAOz-00081n-00 for <hamster@vom.tm>; 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: <200002140125.BAA07792@xrdsv1> Subject: Re: [ProFTPD] Can't do "ls" To: proftpd@proftpd.org Date: Mon, 14 Feb 2000 01:25:21 +0000 (GMT) In-Reply-To: <NDBBLOICLKHIHOKDAEGKAEGFCBAA.lan@recol.com> 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: <v-puK.A.-xC.Tm1p4@starbase.tos.net> Resent-From: proftpd@proftpd.org Reply-To: proftpd@proftpd.org X-Mailing-List: <proftpd@proftpd.org> 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

> I can do a "ls" if I ftp from localhost. However, "ls" does not work > if I'm ftping from a remote server. > > ftp> ls > 200 PORT command successful. > > It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14. > 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?

On Mon, Feb 14, 2000 at 01:25:21AM +0000, L.M.D.Cranswick@dl.ac.uk wrote: > > I can do a "ls" if I ftp from localhost. However, "ls" does not work > > if I'm ftping from a remote server. > > > > ftp> ls > > 200 PORT command successful. > > > > It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14. > > 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.

> I can do a "ls" if I ftp from localhost. However, "ls" does not work > 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.

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?

-----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" > I can do a "ls" if I ftp from localhost. However, "ls" does not work > 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.

On Fri, Feb 11, 2000 at 04:15:47PM -0500, Lan Tran wrote: > 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? 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 > 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, >1023 outgoing from server to all client ports (if you have to limit it, ports >1023)

On Fri, Feb 11, 2000 at 03:44:38PM -0500, Lan Tran wrote: > ftp> ls > 200 PORT command successful. > > It hangs like this forever. Running on RH60 proftpd-1.2pre10 Kernel 2.2.14. > Any ideas? it sounds like there's a firewall in the way blocking the request. try passive mode and see what happens.


proftpd.sql

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

At 15:36 10/04/2000 +0400, **Roman Korolyov**, has written a message, and here is the reply : >Hi! >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: Sorry this is not an answer, but after checking my archive I found this ----- ProFTPD and mod_sqlpw create a security hole ---------------------------------------------------------------------------- ----

SUMMARY Compiling the mod_sqlpw module into ProFTPD makes it possible for local users to view the passwords of users who have connected to the ftp server. When the module is used, it writes information to wtmp. Unfortunately, it writes the password to wtmp where the username should be. The passwords can be seen when a command such as 'last' is used locally.

DETAILS Solution: Adding the following to your ProFTPd configuration file should solve this problem: <Global> Wtemplog off </Global> Wtmplog details below: WtmpLog Syntax: WtmpLog on|off|NONE Default: WtmpLog on Context: server config, <VirtualHost>, <Anonymous>, <Global> Compatibility: 1.1.7 and later The WtmpLog directive controls proftpd's logging of ftp connections to the host system's wtmp file (used by such commands as `last'). By default, all connections are logged via wtmp.

ADDITIONAL INFORMATION The mentioned vulnerability has been discovered by: <mailto:toddc@NET-LINK.NET> Todd C. Campbell.

Got the latest CVS a few days ago, and the wtmp output of proftpd (with mod_sqlpw & mysql) is still really wired : sometimes is the password (!) logged, and the other times, a kind of random string (*J***J**).

*J***J** ftp 195.130.185.44 Sat Apr 8 01:02 - 01:07 (00:04) *J***J** ftp megazh-d-218.agr Sat Apr 8 00:17 - 00:18 (00:00) *J***J** ftp 195.130.185.92 Fri Apr 7 23:30 - 23:39 (00:08) *J***J** ftp 195.130.185.92 Fri Apr 7 23:14 - 23:14 (00:00) *J***J** ftp 195.130.185.92 Fri Apr 7 23:12 - 23:14 (00:01) *J***J** ftp megazh-d-56.agri Fri Apr 7 21:15 - 21:15 (00:00) *J***J** ftp orion.www-hostin Fri Apr 7 14:13 - 14:14 (00:00) *J***J** ftp orion.www-hostin Fri Apr 7 14:11 - 14:12 (00:00) wxcff.97 ftp 147.78.21.30 Fri Apr 7 13:37 - 13:38 (00:01) wxcff.97 ftp 147.78.21.30 Fri Apr 7 13:34 - 13:35 (00:01) wxcff.97 ftp 147.78.21.30 Fri Apr 7 13:31 - 13:31 (00:00) Af773,r ftp sulzer.ch Fri Apr 7 11:51 - 11:52 (00:00) wxcff.97 ftp 147.78.21.30 Fri Apr 7 10:39 - 10:39 (00:00) wxcff.97 ftp 147.78.21.30 Fri Apr 7 10:38 - 10:38 (00:00)

Are these (really practical btw) modules not maintained ? Logging the password to the wtmp is just an *huge* security hog... :(

At 15:36 10/04/2000 +0400, **Roman Korolyov**, has written a message, and here is the reply : >Hi! >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: Sorry this is not an answer, but after checking my archive I found this ----- ProFTPD and mod_sqlpw create a security hole ---------------------------------------------------------------------------- ----

SUMMARY Compiling the mod_sqlpw module into ProFTPD makes it possible for local users to view the passwords of users who have connected to the ftp server. When the module is used, it writes information to wtmp. Unfortunately, it writes the password to wtmp where the username should be. The passwords can be seen when a command such as 'last' is used locally. DETAILS Solution: Adding the following to your ProFTPd configuration file should solve this problem: <Global> Wtemplog off </Global> Wtmplog details below: WtmpLog Syntax: WtmpLog on|off|NONE Default: WtmpLog on Context: server config, <VirtualHost>, <Anonymous>, <Global> Compatibility: 1.1.7 and later The WtmpLog directive controls proftpd's logging of ftp connections to the host system's wtmp file (used by such commands as `last'). By default, all connections are logged via wtmp. ADDITIONAL INFORMATION The mentioned vulnerability has been discovered by: <mailto:toddc@NET-LINK.NET> Todd C. Campbell.

http://bugs.proftpd.org/show_bug.cgi?id=108 *** shadow/108 Thu Apr 6 12:01:58 2000 --- shadow/108.tmp.7160 Thu Apr 6 13:58:46 2000 *************** *** 23,25 **** --- 23,39 ---- 1) references missing flags.c program, need to remove references to flags.* 2) modmysql does not have the ".o" extension in the file. That needs ot be added... + + ------- Additional Comments From hamster@hamster.wibble.org 04/06/00 13:58 ------- + I think the "flags" stuff is a result of the wording in the FAQ, I'll amend the + FAQ to make this clearer. + + It should be + configure --with-modules='mod_sqlpw:mod_mysql' + + not + + configure --with-modules='mod_sqlpw:mod_mysql flags' + + flags' +

http://bugs.proftpd.org/show_bug.cgi?id=109 *** shadow/109 Thu Apr 6 12:06:53 2000 --- shadow/109.tmp.7078 Thu Apr 6 12:06:53 2000 *************** *** 0 **** --- 1,27 ---- + Bug#: 109 + Product: ProFTPD + Version: 1.2.0pre10 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: normal + Priority: P2 + Component: mod_sqlpw + AssignedTo: proftpd-devel@proftpd.org + ReportedBy: mgrabenstein@mac.com + URL: + Summary: mod_sqlpw (mysql): Make.rules needs libaries and includes specified. + + In Make.rules, The definition for LIBS needs to have -lmysqlclient added to it. + LDFLAGS needs the path to your mysql library added. CPPFLAGS needs the location + of your mysql include files added. + Depending on installation they should look like: + LIBS=-lsupp -ldl -lcrypt -lm -lmysqlclient -lpam + LDFLAGS=-L/home/builds/proftpd-1.2.0pre10/lib -L/usr/local/mysql/lib/mysql + CPPFLAGS= $(DEFAULT_PATHS) $(PLATFORM) -I.. -I$(top_srcdir)/include + -I/usr/local/mysql/include/mysql + + Would be nice if there was a readme somwhere in the distribution that hinted at + these things... + Would be best if configure would do this...

http://bugs.proftpd.org/show_bug.cgi?id=108 *** shadow/108 Thu Apr 6 11:57:28 2000 --- shadow/108.tmp.7054 Thu Apr 6 12:01:34 2000 *************** *** 11,19 **** AssignedTo: proftpd-devel@proftpd.org ReportedBy: mgrabenstein@mac.com URL: ! Summary: reference to flags.c needs to be removed to compile mod_sqlpw (mysql) To get mod_sqlpw to compile. You must first edit the Make.modules file and remove the references to flags.c. Or is it missing from the pre10 distribution ? mod_sqlpw seems work fine with ou it. :-) --- 11,25 ---- AssignedTo: proftpd-devel@proftpd.org ReportedBy: mgrabenstein@mac.com URL: ! Summary: mmod_sqlpw (mysql) in Make.modules, remove flag.* and add .o to modmysql To get mod_sqlpw to compile. You must first edit the Make.modules file and remove the references to flags.c. Or is it missing from the pre10 distribution ? mod_sqlpw seems work fine with ou it. :-) + + ------- Additional Comments From mgrabenstein@mac.com 04/06/00 12:01 ------- + Two problems in Make.modules: + 1) references missing flags.c program, need to remove references to flags.* + 2) modmysql does not have the ".o" extension in the file. That needs ot be + added...

http://bugs.proftpd.org/show_bug.cgi?id=108 *** shadow/108 Thu Apr 6 12:01:34 2000 --- shadow/108.tmp.7065 Thu Apr 6 12:01:58 2000 *************** *** 11,17 **** AssignedTo: proftpd-devel@proftpd.org ReportedBy: mgrabenstein@mac.com URL: ! Summary: mmod_sqlpw (mysql) in Make.modules, remove flag.* and add .o to modmysql To get mod_sqlpw to compile. You must first edit the Make.modules file and remove the references to flags.c. --- 11,17 ---- AssignedTo: proftpd-devel@proftpd.org ReportedBy: mgrabenstein@mac.com URL: ! Summary: mod_sqlpw (mysql) in Make.modules, remove flag.* and add .o to modmysql To get mod_sqlpw to compile. You must first edit the Make.modules file and remove the references to flags.c.

http://bugs.proftpd.org/show_bug.cgi?id=107 *** shadow/107 Thu Apr 6 11:54:53 2000 --- shadow/107.tmp.7006 Thu Apr 6 11:54:53 2000 *************** *** 0 **** --- 1,24 ---- + Bug#: 107 + Product: ProFTPD + Version: 1.2.0pre10 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: major + Priority: P2 + Component: mod_sqlpw + AssignedTo: proftpd-devel@proftpd.org + ReportedBy: mgrabenstein@mac.com + URL: + Summary: Atempts to log in after the first failure always fail with mod_sqlpw (mysql) + + When I ftp to my host, if I type in the user id and password the first time + everything is fine and I am able to log in. + If I make a typo in the password and the log in fails. I can use the "user" + command in the ftp client to attempt logging in again. Problem is now, that no + matter what I type it will fail. + Work around: Get it right the first time, in other words: if you fail the first + time, quit ftp and re-start your ftp client. + This was noticed when ftp'ing from RedHat v6.1 and from Solaris 2.6 to my RedHat + v6.1 box...

http://bugs.proftpd.org/show_bug.cgi?id=105 *** shadow/105 Thu Apr 6 11:33:59 2000 --- shadow/105.tmp.6990 Thu Apr 6 11:50:29 2000 *************** *** 11,17 **** AssignedTo: proftpd-devel@proftpd.org ReportedBy: mgrabenstein@mac.com URL: ! Summary: DefaultRoot does not work as advertised with mod_sqlpw OtherBugsDependingOnThis: 52[NEW] DefaultRoot does not work as advertised. It will now --- 11,17 ---- AssignedTo: proftpd-devel@proftpd.org ReportedBy: mgrabenstein@mac.com URL: ! Summary: DefaultRoot does not work as advertised with mod_sqlpw (mysql) OtherBugsDependingOnThis: 52[NEW] DefaultRoot does not work as advertised. It will now

http://bugs.proftpd.org/show_bug.cgi?id=105 *** shadow/105 Thu Apr 6 11:33:37 2000 --- shadow/105.tmp.6930 Thu Apr 6 11:33:37 2000 *************** *** 0 **** --- 1,21 ---- + Bug#: 105 + Product: ProFTPD + Version: 1.2.0pre10 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: major + Priority: P2 + Component: mod_sqlpw + AssignedTo: proftpd-devel@proftpd.org + ReportedBy: mgrabenstein@mac.com + URL: + Summary: DefaultRoot does not work as advertised with mod_sqlpw + + DefaultRoot does not work as advertised. It will now + chroot in 1.2pre10, but the group expression field does not work. Specifing + something can disable DefaultRoot. (DefaultRoot ~ !mygroup == is not respected, + but Default root does chroot, where as DefaultRoot ~ ! mygroup == (with a space + between ! and group) seems to disable chroot.) Also DefaultRoot ~ does work (if + the group expression is blank).

http://bugs.proftpd.org/show_bug.cgi?id=108 *** shadow/108 Thu Apr 6 11:57:28 2000 --- shadow/108.tmp.7017 Thu Apr 6 11:57:28 2000 *************** *** 0 **** --- 1,19 ---- + Bug#: 108 + Product: ProFTPD + Version: 1.2.0pre10 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: normal + Priority: P2 + Component: mod_sqlpw + AssignedTo: proftpd-devel@proftpd.org + ReportedBy: mgrabenstein@mac.com + URL: + Summary: reference to flags.c needs to be removed to compile mod_sqlpw (mysql) + + To get mod_sqlpw to compile. You must first edit the Make.modules file and + remove the references to flags.c. + Or is it missing from the pre10 distribution ? mod_sqlpw seems work fine with ou + it. :-)

http://bugs.proftpd.org/show_bug.cgi?id=106 *** shadow/106 Thu Apr 6 11:50:13 2000 --- shadow/106.tmp.6979 Thu Apr 6 11:50:13 2000 *************** *** 0 **** --- 1,19 ---- + Bug#: 106 + Product: ProFTPD + Version: 1.2.0pre10 + Platform: PC + OS/Version: Linux + Status: NEW + Resolution: + Severity: normal + Priority: P2 + Component: mod_sqlpw + AssignedTo: proftpd-devel@proftpd.org + ReportedBy: mgrabenstein@mac.com + URL: + Summary: inetd not working with mod_sqlpw (mysql) + + Using inetd to spawn proftpd with mod_sqlpw loaded resulted in: + "421 Service not available, remote server has closed connection" + Changing the proftpd.conf so the server was "standalone" and disabling ftp in + inetd.conf. Allows me to start a working server.

http://bugs.proftpd.org/show_bug.cgi?id=105 *** shadow/105 Thu Apr 6 11:33:37 2000 --- shadow/105.tmp.6941 Thu Apr 6 11:33:59 2000 *************** *** 12,17 **** --- 12,18 ---- ReportedBy: mgrabenstein@mac.com URL: Summary: DefaultRoot does not work as advertised with mod_sqlpw + OtherBugsDependingOnThis: 52[NEW] DefaultRoot does not work as advertised. It will now chroot in 1.2pre10, but the group expression field does not work. Specifing

http://bugs.proftpd.org/show_bug.cgi?id=52 *** shadow/52 Tue Feb 15 14:26:57 2000 --- shadow/52.tmp.6948 Thu Apr 6 11:34:00 2000 *************** *** 1,6 **** Bug#: 52 Product: ProFTPD ! Version: 1.2.0preX Platform: All OS/Version: All Status: NEW --- 1,6 ---- Bug#: 52 Product: ProFTPD ! Version: 1.2.0pre9 Platform: All OS/Version: All Status: NEW *************** *** 12,17 **** --- 12,18 ---- ReportedBy: wigstah@akitanet.co.uk URL: Summary: chroot'ing to user's home directory doesn't work when mod_mysql is in use + BugsThisDependsOn: 105[NEW] Hi,

+------ "Mark Renouf" wrote (Fri, 7-Jan-00, 18:21 -0500): | | ns1:/usr/local/mysql/var# /usr/sbin/proftpd --version | ProFTPD Version 1.2.0pre8 | | I'm running with mod_sqlpw and mod_mysql | | wtmp is logging ftp logins VERY incorrectly | | example: a login by=20 | user: ftpuser=20 | password: mypassword | | [should show:] | | ns1:/usr/local/mysql/var# last -1 | ftpuser ftp nrwc-sh7-port89 Fri Jan 7 12:36 - 12:51 = | (00:15) | | [but instead shows like this:] | | ns1:/usr/local/mysql/var# last -1 | mypassword ftp nrwc-sh7-port89 Fri Jan 7 12:36 - 12:51 = | (00:15) | | Can anyone confirm this? Should I try pre9 ? Is this related the problem previously reported last November? AFAIK, neither pre9 nor CVS (but I haven't looked in a few days) includes a fix. It sounds similar though slightly different. +------ "Charles Seeger" wrote (Thu, 30-Dec-99, 11:25 -0500): | | o Passwords are logged to wtmp by mod_sqlpw! | http://www.proftpd.org/proftpd-l-archive/99-11/msg00212.html | http://www.proftpd.org/proftpd-l-archive/99-11/msg00216.html | http://www.proftpd.org/proftpd-l-archive/99-11/msg00217.html | http://www.proftpd.org/proftpd-l-archive/99-11/msg00221.html | (includes a fix to mod_sqlpw.c:_checkpass function to prevent | logging the correct and wrong password in debug mode) | http://www.proftpd.org/proftpd-l-archive/99-11/msg00235.html | http://www.proftpd.org/proftpd-l-archive/99-11/msg00242.html Looks like it bears further investigation.

Uhmmmm Yes, the problem remains in pre9... The workaround is to disable that type of logging.

http://www.iusb.edu/~awalton/pro-mysql.txt that should help. -Andy ----- Original Message ----- From: "Mitch Vincent" <mitch@venux.net> To: <proftpd@proftpd.org> Sent: Saturday, March 11, 2000 2:00 PM Subject: [ProFTPD] Compile error with pre 10 > modules/mod_sqlpw.o: In function `auth_cmd_getpwnam': > /usr/source/proftpd-1.2.0pre10/modules/mod_sqlpw.c(.text+0x44a): undefined > reference to `mysql_escape_string' > modules/mod_sqlpw.o: In function `auth_cmd_auth': > /usr/source/proftpd-1.2.0pre10/modules/mod_sqlpw.c(.text+0x76c): undefined > reference to `mysql_escape_string' > *** Error code 1 > > > I'm trying to compile in mod_mysql and mod_sqlpw, however I get the above > error... Also, I couldn't find any documentation on the table layouts and > such require for mod_sqlpw and mod_mysql to work, could anyone point me to > it? >


Chapter 21. Compatibility and Integration

SQL

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.


Format of SQL tables

(take care : uid and gid must be > 500. or change the source code of the module).

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.


SQL Authentication

o Install MySQL o Compile Proftpd with the --with-modules=mod_sqlpw:mod_mysql flags

Note: I had to alter the path slighly so the modules got mysql.h from the rightplace.

Detailing how to use MySQL is outside the scope of this document, so here's some links.

o http://www.devshed.com/Server_Side/MySQL/Administration/ o http://www.devshed.com/Server_Side/MySQL/Intro/

Quick rundown of what's needed to make a databae

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)


SQL Logging

There's definately 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.tm 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 <host> <IP> <time> 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.


Hints

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-module=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.

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


Hints

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-module=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 <mysql.h> 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 ?

I. Configuration Directives

Table of Contents
AccessDenyMsg -- Customise the response on failed authentication
AccessGrantMsg -- Customise the response on successful authentication
Allow -- Access control directive
AllowAll -- Allow all clients
AllowChmod -- Enable the CHMOD command (deprecated)
AllowFilter -- Regular expression of command arguments to be accepted
AllowForeignAddress -- Control the use of the PORT command
AllowGroup -- Group based allow rules
Allow -- Permit logging to symlinked files
AllowOverwrite -- Enable files to be overwritten
AllowRetrieveRestart -- Allow clients to resume downloads
AllowStoreRestart -- Allow clients to resume uploads
AllowUser -- User based allow rules
AnonRatio -- Ratio directive
AnonRequirePassword -- Make anonymous users supply a valid password
Anonymous -- Define an anonymous server
AnonymousGroup -- Treat group members as anonymous users
AuthAliasOnly -- Allow only aliased login names
AuthGroupFile -- Specify alternate group file
AuthPAM -- Enable/Disable PAM authentication
AuthPAMAuthoritative -- Set whether PAM is the authoritive authentication scheme
AuthPAMConfig -- Select PAM service name
AuthUserFile -- Specify alternate passwd file
AuthUsingAlias -- Authenticate via Alias-name instead of mapped username
Bind -- Bind the server or Virtualhost to a specific IP address
ByteRatioErrMsg -- Ratio directive
CDPath -- Sets "search paths" for the cd command
Class -- Definition statements for class based tracking
Classes -- Enable Class based connection tracking
CommandBufferSize -- Limit the maximum command length
CwdRatioMsg -- Ratio directive
DefaultChdir -- Set starting directory for FTP sessions
DefaultQuota -- Sets the default quota
DefaultRoot -- Sets default chroot directory
DefaultServer -- Set the default server
DefaultTransferMode -- Set the default method of data transfer
DeferWelcome -- Don't show welcome message until user has authenticated
DeleteAbortedStores -- Enable automatic deletion of partially uploaded files
Deny -- Access control directive
DenyAll -- Deny all clients
DenyFilter -- Regular expression of command arguments to be blocked
DenyGroup -- Group based deny rules
DenyUser -- User based deny rules
Directory -- FIXME FIXME
DirFakeGroup -- Hide real file/directory group
DirFakeMode -- Hide real file/directory permissions
DirFakeUser -- Hide real file/directory owner
DisplayConnect -- Sets connect banner file
DisplayFirstChdir -- FIXME FIXME
DisplayGoAway -- FIXME FIXME
DisplayLogin -- FIXME FIXME
DisplayQuit -- FIXME FIXME
DisplayReadme -- FIXME FIXME
ExtendedLog -- FIXME FIXME
FileRatioErrMsg -- FIXME FIXME
FooBarDirective -- FIXME FIXME
Global -- FIXME FIXME
Group -- FIXME FIXME
GroupOwner -- FIXME FIXME
GroupPassword -- FIXME FIXME
GroupRatio -- Ratio directive
HiddenStor -- Enables more safe file uploads
HideGroup -- FIXME FIXME
HideNoAccess -- Block the listing of directory entries to which the user has no access permissions
HideUser -- FIXME FIXME
HostRatio -- Ratio directive
IdentLookups -- Toggle ident lookups
IgnoreHidden -- Treat 'hidden' files as if they don't exist
Include -- Load additional configuration directives from a file
LDAPAuthBinds -- FIXME FIXME
LDAPDefaultAuthScheme --  Set the authentication scheme/hash that is used when no leading {hashname} is present.
LDAPDefaultGID --  Set the default GID to be assigned to users when no uidNumber attribute is found.
LDAPDefaultUID --  Set the default GID to be assigned to users when no uidNumber attribute is found.
LDAPDNInfo -- Set DN information to be used for initial bind
LDAPDoAuth -- Enable LDAP authentication
LDAPDoGIDLookups --  Enable LDAP lookups for user group membership and GIDs in directory listings
LDAPDoUIDLookups --  Enable LDAP lookups for UIDs in directory listings
LDAPForceDefaultGID -- Force all LDAP-authenticated users to use the same GID.
LDAPForceDefaultUID -- Force all LDAP-authenticated users to use the same UID.
LDAPHomedirOnDemand --  Enable the creation of user home directories on demand
LDAPHomedirOnDemandPrefix --  Enable the creation of user home directories on demand
LDAPHomedirOnDemandPrefixNoUsername -- FIXFIXFIX
LDAPHomedirOnDemandSuffix --  Specify an additional directory to be created inside a user's home directory on demand.
LDAPNegativeCache -- Enable negative caching for LDAP lookups
LDAPQueryTimeout -- Set a timeout for LDAP queries
LDAPSearchScope -- Specify the search scope used in LDAP queries
LDAPServer -- Specify the LDAP server to use for lookups
LDAPUseTLS -- Enable TLS/SSL connections to the LDAP server.
LeechRatioMsg -- Sets the 'over ratio' error message
Limit -- FIXME FIXME
LogFormat -- Specify a logging format
LoginPasswordPrompt -- FIXME FIXME
LsDefaultOptions -- FIXME FIXME
MasqueradeAddress -- Configure the server address presented to clients
MaxClients -- Limits the number of users that can connect
MaxClientsPerHost -- Limits the connections per client machine
MaxHostsPerUser -- Limit the number of connections per userid
MaxInstances -- Sets the maximum number of child processes to be spawned
MaxLoginAttempts -- Sets how many password attempts are allowed before disconnection
MultilineRFC2228 -- FIXME FIXME
MySQLInfo -- Configures the MySQL driver
Order -- Configures the precedence of the Limit directives
PassivePorts -- Specify the ftp-data port range to be used
PathAllowFilter -- FIXME FIXME
PathDenyFilter -- FIXME FIXME
PersistentPasswd -- FIXME FIXME
PidFile -- FIXME FIXME
Port -- FIXME FIXME
PostgresInfo -- Postgres backend configuration (Deprecated)
PostgresPort -- Sets the port postgres is listening on
QuotaBlockName -- FIXME FIXME
QuotaBlockSize -- FIXME FIXME
QuotaCalc -- FIXME FIXME
QuotaExempt -- FIXME FIXME
Quotas -- FIXME FIXME
QuotaType -- FIXME FIXME
RateReadBPS -- FIXME FIXME
RateReadFreeBytes -- FIXME FIXME
RateReadHardBPS -- FIXME FIXME
RateWriteBPS -- FIXME FIXME
RateWriteFreeBytes -- FIXME FIXME
RateWriteHardBPS -- FIXME FIXME
RatioFile -- Ratio directive
Ratios -- FIXME FIXME
RatioTempFile -- Ratio directive
RequireValidShell -- Allow connections based on /etc/shells
RLimitCPU -- Configure the maximum CPU time in seconds used by a process
RLimitMemory -- Configure the maximum memory in bytes used by a process
RLimitOpenFiles -- Configure the maximum number of open files used by a process
RootLogin -- Permit root user logins
SaveRatios -- FIXME FIXME
ScoreboardPath -- Sets the path to the scoreboard file
ServerAdmin -- Set the address for the server admin
ServerIdent -- Set the message displayed on connect
ServerName -- Configure the name displayed to connecting users
ServerType -- Set the mode proftpd runs in
ShowDotFiles -- Toggle display of 'dotfiles'
ShowSymlinks -- Toggle the display of symlinks
SocketBindTight -- Controls how TCP/IP sockets are created
SQLAuthenticate --  Specify authentication methods and what to authenticate
SQLAuthoritative -- FIXFIXFIX
SQLAuthTypes -- FIXME FIXME
SQLConnectInfo -- FIXME FIXME
SQLDefaultGID -- FIXME FIXME
SQLDefaultHomedir -- FIXFIXFIX
SQLDefaultUID -- FIXME FIXME
SQLDoAuth -- FIXME FIXME
SQLDoGroupAuth -- FIXME FIXME
SQLEmptyPasswords -- Allow zero length passwords (DEPRECATED)
SQLEncryptedPasswords -- Assume SQL passwords are encrypted (DEPRECATED)
SQLGidField -- FIXFIXFIX
SQLGroupGIDField -- FIXFIXFIX
SQLGroupInfo -- FIXFIXFIX
SQLGroupMembersField -- FIXME FIXME
SQLGroupnameField -- FIXME FIXME
SQLGroupTable -- FIXME FIXME
SQLGroupWhereClause -- FIXFIXFIX
SQLHomedir -- FIXFIXFIX
SQLHomedirField -- FIXFIXFIX
SQLHomedirOnDemand -- FIXME FIXME
SQLLog -- FIXFIXFIX
SQLLogDirs -- FIXFIXFIX
SQLLogHits -- FIXFIXFIX
SQLLogHosts -- FIXFIXFIX
SQLLoginCountField -- FIXFIXFIX
SQLLogStats -- FIXFIXFIX
SQLMinID -- FIXME FIXME
SQLMinUserGID -- FIXFIXFIX
SQLMinUserUID -- FIXFIXFIX
SQLNamedQuery -- FIXFIXFIX
SQLPasswordField -- FIXFIXFIX
SQLProcessGrEnt -- FIXFIXFIX
SQLProcessPwEnt -- FIXFIXFIX
SQLRatios -- FIXFIXFIX
SQLRatioStats -- FIXFIXFIX
SQLScrambledPasswords -- FIXME FIXME
SQLShellField -- FIXME FIXME
SQLShowInfo -- FIXFIXFIX
SQLSSLHashedPasswords -- FIXME FIXME
SQLUidField -- FIXFIXFIX
SQLUserInfo -- FIXFIXFIX
SQLUsernameField -- FIXFIXFIX
SQLUserTable -- FIXFIXFIX
SQLUserWhereClause -- FIXFIXFIX
SQLWhereClause -- FIXME FIXME
SyslogFacility -- Set the facility level used for logging
SyslogLevel -- Set the verbosity level of system logging
SystemLog -- Redirect syslogging to a file
TCPAccessFiles -- Sets the access files to use
TCPAccessSyslogLevels -- Sets the logging levels for mod_wrap
tcpBackLog -- Control the tcp backlog in standalone mode
TCPGroupAccessFiles -- Sets the access files to use
tcpNoDelay -- Control the use of TCP_NODELAY
tcpReceiveWindow -- Set the size of the tcp receive window
tcpSendWindow -- Set the size of the tcp send window
TCPServiceName -- Configures the name proftpd will use with mod_wrap
TCPUserAccessFiles -- Sets the access files to use
TimeoutIdle -- Sets the idle connection timeout
TimeoutLogin -- Sets the login timeout
TimeoutNoTransfer -- Sets the connection without transfer timeout
TimeoutStalled -- Sets the timeout on stalled downloads
TimesGMT -- Toggle time display between GMT and local
TransferLog -- Specify the path to the transfer log
Umask -- Set the default Umask
UseFtpUsers -- Block based on /etc/ftpusers
UseGlobbing -- Toggles use of glob() functionality
User -- Set the user the daemon will run as
UserAlias -- Alias a username to a system user
UserDirRoot -- Set the chroot directory to a subdirectory of the anonymous server
UseReverseDNS -- Toggle rDNS lookups
UserOwner -- Set the user ownership of new files / directories
UserPassword -- Creates a hardcoded username/password pair
UserRatio -- Ratio directive
VirtualHost -- Define a virtual ftp server
WtmpLog -- Toggle logging to wtmp

AccessDenyMsg

Name

AccessDenyMsg -- Customise the response on failed authentication

Description

Normally, a 530 response message is sent to an FTP client immediately after a failed authentication attempt, with a standard message indicating the the reason of failure. In the case of a wrong password, the reason is usually "Login incorrect." It is this message can be customized with the AccessDenyMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login.

See also

Examples

AccessDenyMsg "Guest access denied for %u."

AccessGrantMsg

Name

AccessGrantMsg -- Customise the response on successful authentication

Description

Normally, a 230 response message is sent to an FTP client immediately after authentication, with a standard message indicating that the user has either logged in or that anonymous access has been granted. This message can be customized with the AccessGrantMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login.

See also

Examples

AccessGrantMsg "Guest access granted for %u."

Allow

Name

Allow -- Access control directive

Description

The Allow directive is used inside a <Limit> context to explicitly specify which hosts and/or networks have access to the commands or operations being limited. Allow is typically used in conjunction with Order and Deny in order to create sophisticated (or perhaps not-so-sophisticated) access control rules. Allow takes an optional first argument; the keyword from. Using from is purely cosmetic. The remaining arguments are expected to be a list of hosts and networks which will be explicitly granted access. The magic keyword all can be used to indicate that all hosts will explicitly be granted access (analogous to the AllowAll directive, except with a lower priority). Additionally, the magic keyword none can be used to indicate that no hosts or networks will be explicitly granted access (although this does not prevent them from implicitly being granted access). If all or none is used, no other hosts or networks can be supplied. Host and network addresses can be specified by name or numeric address. For security reasons, it is recommended that all address information be supplied numerically. Relying solely on named addresses causes security to depend a great deal upon DNS servers which may themselves be vulnerable to attack or spoofing. Numeric addresses which specify an entire network should end in a trailing period (i.e. 10.0.0. for the entire 10.0.0 subnet). Named address which specify an entire network should begin with a trailing period (i.e. .proftpd.net for the entire proftpd.net domain).

See also

Allow Order Limit

Examples

<Limit LOGIN>
Order allow,deny
Allow from 128.44.26.,128.44.26.,myhost.mydomain.edu,.trusted-domain.org
Deny from all
</Limit>

AllowAll

Name

AllowAll -- Allow all clients

Description

The AllowAll directive explicitly allows access to a <Directory>, <Anonymous> or <Limit> block. Although proftpd's default behavior is to allow access to a particular object, the default is an implicit allow. AllowAll creates an explicit allow, overriding any higher level denial directives.

See also

DenyAll

Examples

AllowChmod

Name

AllowChmod -- Enable the CHMOD command (deprecated)

Description

This directive is deprecated, please use >Limit SITE_CHMOD< instead.

AllowChmod allows control over whether the "SITE CHMOD" command is allowed to clients.

See also

Examples

AllowChmod false

AllowFilter

Name

AllowFilter -- Regular expression of command arguments to be accepted

Description

AllowFilter allows the configuration of a regular expression that must be matched for all command arguments sent to ProFTPD. It is extremely useful in controlling what characters may be sent in a command to ProFTPD, preventing some possible types of attacks against ProFTPD. The regular expression is applied against the arguments to the command sent by the client, so care must be taken when creating a proper regex. Commands that fail the regex match result in a "Forbidden command" error being returned to the client. If the regular-expression argument contains whitespace, it must be enclosed in quotes.

See also

DenyFilter

Examples

# Only allow commands containing alphanumeric characters and whitespace
AllowFilter "^[a-zA-Z0-9 ,]*$"

AllowForeignAddress

Name

AllowForeignAddress -- Control the use of the PORT command

Description

Normally, proftpd disallows clients from using the ftp PORT command with anything other than their own address (the source address of the ftp control connection), as well as preventing the use of PORT to specify a low-numbered (< 1024) port. In either case, the client is sent an "Invalid port" error and a message is syslog'd indicating either "address mismatch" or "bounce attack". By enabling this directive, proftpd will allow clients to transmit foreign data connection addresses that do not match the client's address. This allows such tricks as permitting a client to transfer a file between two FTP servers without involving itself in the actual data connection. Generally it's considered a bad idea, security-wise, to permit this sort of thing. AllowForeignAddress only affects data connection addresses; not tcp ports. There is no way (and no valid reason) to allow a client to use a low-numbered port in its PORT command.

See also

Examples

AllowGroup

Name

AllowGroup -- Group based allow rules

Description

AllowGroup specifies a group-expression that is specifically permitted within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be allowed access to the block. The expression is parsed as a boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in order for the explicit allow to apply.

Examples

Allow

Name

AllowLogSymlinks -- Permit logging to symlinked files

Description

By default, the server will the path of any configured SystemLog, any configured TransferLogs, and any configured ExtendedLogs to see if they are symbolic links. If the paths are symbolic links, the server will refuse to log to that link unless explicitly configured to do so via this directive.

Security note:

Security note: this behaviour should not be allowed unless for a very good reason. By allowing the server to open symbolic links with its root privileges, you are allowing a potential symlink attack where the server could be tricked into overwriting arbitrary system files. You have been warned.

See also

Examples

AllowLogSymlinks on

AllowOverwrite

Name

AllowOverwrite -- Enable files to be overwritten

Description

The AllowOverwrite directive permits newly transfered files to overwrite existing files. By default, ftp clients cannot overwrite existing files.

See also

Examples

AllowRetrieveRestart

Name

AllowRetrieveRestart -- Allow clients to resume downloads

Description

The AllowRetrieveRestart directive permits or denies clients from performing "restart" retrieve file transfers via the FTP REST command. By default this is enabled, so that clients may resume interrupted file transfers at a later time without losing previously collected data.

Examples

AllowStoreRestart

Name

AllowStoreRestart -- Allow clients to resume uploads

Description

The AllowStoreRestart directive permits or denies clients from "restarting" interrupted store file transfers (those sent from client to server). By default restarting (via the REST command) is not permitted when sending files to the server. Care should be taken to disallow anonymous ftp "incoming" transfers to be restarted, as this will allow clients to corrupt or increase the size of previously stored files (even if not their own).

The REST (Restart STOR) command is automatically blocked when HiddenStor is enabled, with the server returning a 501 error code to the client.

Examples

AllowUser

Name

AllowUser -- User based allow rules

Description

AllowUser specifies a user-expression that is specifically permitted access within the context of the <Limit> block it is applied to. user-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of users or "not" users (by prefixing a user name with the `!' character) that are to be allowed access to the block. The expression is parsed as a boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in order to the explicit allow to apply.

Examples

AnonRatio

Name

AnonRatio -- Ratio directive

Description

The AnonRatio directive ....

See also

AnonRatio

Examples

AnonRequirePassword

Name

AnonRequirePassword -- Make anonymous users supply a valid password

Description

Normally, anonymous FTP logins do not require the client to authenticate themselves via the normal method of a transmitted cleartext password which is hashed and matched against an existing system user's password. Instead, anonymous logins are expected to enter their e-mail address when prompted for a password. Enabling the AnonRequirePassword directive requires anonymous logins to enter a valid password which must match the password of the user that the anonymous daemon runs as. However using AuthUsingAlias authentication can be matched against the password of the login username. This can be used to create "guest" accounts, which function exactly as normal anonymous logins do (and thus present a "chrooted" protected file system to the client), but require a valid password on the server's host system.

Examples

Example of a "guest" account configuration:
<Anonymous ~roger>
User roger
Group other
UserAlias proftpd roger
AnonRequirePassword on
# Deny write operations to all directories, underneath root-dir
# Default is to allow, so we don't need a <Limit> for read operations.
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
# Deny all read/write operations in incoming. Because these are command-group
# limits, we can explicitly permit certain operations which will take precedence
# over our group limit.
<Directory incoming>
<Limit READ WRITE>
DenyAll
</Limit>
# The only command allowed in incoming is STOR (transfer file from client 
to server)
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>

Anonymous

Name

Anonymous -- Define an anonymous server

Description

The Anonymous configuration block is used to create an anonymous FTP login, and is terminated by a matching </Anonymous> directive. The root-directory parameters specifies which directory the daemon will first chdir to, and then chroot, immediately after login. Once the chroot operation successfully completes, higher level directories are no longer accessible to the running child daemon (and thus the logged in user). By default, proftpd assumes an anonymous login if the remote client attempts to login as the currently running user; unless the current user is root, in which case anonymous logins are not allowed regardless of the presence of an <Anonymous> block. To force anonymous logins to be bound to a user other than the current user, see the User and Group directives. In addition, if a User or Group directive is present in an <Anonymous> block, the daemon permanently switches to the specified uid/gid before chroot()ing. Normally, anonymous logins are not required to authenticate with a password, but are expected to enter a valid e-mail address in place of a normal password (which is logged). If this behavior is undesirable for a given <Anonymous> configuration block, it can be overridden via the AnonRequirePassword directive.

Note: Chroot()ed anonymous directories do not need to have supplemental system files in them, nor do they need to have any sort of specific directory structure. This is because proftpd is designed to acquire as much system information as possible before the chroot, and to leave open those files which are needed for normal operation and reside outside the new root directory.

See also

Examples

Example of a typical anonymous FTP configuration:
<Anonymous /home/ftp>
User ftp # After anonymous login, daemon runs as user ftp.
Group ftp # After anonymous login, daemon runs as group ftp.
UserAlias anonymous ftp # Client login as 'anonymous' is aliased to 'ftp'.
# Deny write operations to all directories, underneath root-dir
# Default is to allow, so we don't need a <Limit> for read operations.
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
<Directory incoming>
<Limit READ WRITE>
DenyAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>

AnonymousGroup

Name

AnonymousGroup -- Treat group members as anonymous users

Description

The AnonymousGroup directive specifies a group-expression to which all matching users will be considered anonymous logins. The group-expression argument is a boolean logically ANDed list of groups to which the user must be a member of (or non-member if the group name is prefixed with a `!' character). For more information on group-expressions see the DefaultRoot directive. If the authenticating user is matched by an AnonymousGroup directive, no valid password is required, and a special dynamic anonymous configuration is created, with the user's home directory as the default root directory. If a DefaultRoot directive also applies to the user, this directory is used instead of the user's home dir. Great care should be taken when using AnonymousGroup, as improper configuration can open up user home directories to full read/write access to the entire world.

Examples

AuthAliasOnly

Name

AuthAliasOnly -- Allow only aliased login names

Description

AuthAliasOnly restricts authentication to "aliased" logins only; i.e. those usernames provided by clients which are "mapped" to a real userid by the UserAlias directive. Turning AuthAliasOnly `on' in a particular context will cause proftpd to completely ignore all non-aliased logins for the entire context. If no contexts are available without AuthAliasOnly set to `on', proftpd rejects the client login and sends an appropriate message to syslog.

Examples

AuthGroupFile

Name

AuthGroupFile -- Specify alternate group file

Description

AuthGroupFile specifies an alternate groups file, having the same format as the system /etc/group file, and if specified is used during authentication and group lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthGroupFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthUserFile).

Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.

See also

AuthUserFile

Examples

AuthPAM

Name

AuthPAM -- Enable/Disable PAM authentication

Description

This directive determines whether PAM is used as an authentication method by ProFTPD. Enabled by default to fit in with the design policy of using PAM as the primary authentication mechanism.

See also

Examples

AuthPAMAuthoritative

Name

AuthPAMAuthoritative -- Set whether PAM is the authoritive authentication scheme

Description

This directive allows you to control whether or not PAM is the ultimate authority on authentication. Setting this directive to on will cause authentication to fail if PAM authentication fails. The default setting, off, allows other modules and directives such as AuthUserFile and friends to authenticate users, should PAM authentication fail. If you are having problems with PAM and using other directives like AuthUserFile, set this directive to off.

See also

Examples

AuthPAMConfig

Name

AuthPAMConfig -- Select PAM service name

Description

This directive allows you to specify the PAM service name used in authentication. PAM allows you to specify a service name to use when authenticating. This allows you to configure different PAM service names to be used for different virtual hosts. The directive was renamed from PAMConfig post 1.2.0 pre10.

See also

Examples

# Virtual host foobar authenticates differently than the rest

AuthPAMConfig foobar

# This assumes, that you have a PAM service named foobar
# configured in your /etc/pam.conf file or /etc/pam.d directory. 

AuthUserFile

Name

AuthUserFile -- Specify alternate passwd file

Description

AuthUserFile specifies an alternate passwd file, having the same format as the system /etc/passwd file, and if specified is used during authentication and user lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthUserFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthGroupFile).

Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.

Examples

AuthUsingAlias

Name

AuthUsingAlias -- Authenticate via Alias-name instead of mapped username

Description

AuthUsingAlias disables the resolving of mapped usernames for authentication purposes. For example, if you have mapped the username anonymous to the "real" user ftp, the password gets checked against the user "anonymous". When AuthUsingAlias is disabled, the checked username would be "ftp".

Examples

An example of an Anonymous configuration using
AuthUsingAlias
# Basic Read-Only Anonymous Configuration.
<Anonymous /home/ftp>
UserAlias             anonymous  nobody
UserAlias             ftp        nobody
AuthAliasOnly         on
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>
# Give Full Read-Write Anonymous Access to certain users
<Anonymous /home/ftp>
AnonRequirePassword   on
AuthAliasOnly         on
AuthUsingAlias        on
# The list of authorized users.
# user/pass lookup is for each user, not password entry
# of server uid ('nobody' in this example).
UserAlias             fred       nobody
UserAlias             joe        nobody
<Limit ALL>
AllowAll
</Limit>
</Anonymous>

Bind

Name

Bind -- Bind the server or Virtualhost to a specific IP address

Description

The Bind directive allows additional IP addresses to be bound to a main or VirtualHost configuration. Multiple Bind directives can be used to bind multiple addresses. The address argument should be either a fully qualified domain name or a numeric dotted-quad IP address. Incoming connections destined to an additional address added by Bind are serviced by the context containing the directive. Additionally, if SocketBindTight is set to on, a specific listen connection is created for each additional address.

See also

Examples

ByteRatioErrMsg

Name

ByteRatioErrMsg -- Ratio directive

Description

The ByteRatioErrMsg directive .... Example: ByteRatioErrMsg

See also

Examples

CDPath

Name

CDPath -- Sets "search paths" for the cd command

Description

Adds an entry to a search path that is used when changing directories. For example: CDPath /home/public CDPath /var/devel This allows a user to cd into any directory directly under /home/public or /var/devel, provided they have the appropriate rights. So, if /home/public/proftpd exists, cd proftpd will bring the user to that directory, regardless of where they currently are in the directory tree.

See also

Examples

Class

Name

Class -- Definition statements for class based tracking

Description

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 (default is 100) for that class name, regex sets a hostname regex (POSIX) for inclusion in the class and ip sets an IP/netmask based inclusion.

See also

Examples

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

Name

Classes -- Enable Class based connection tracking

Description

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

See also

Examples

For examples, see Class

CommandBufferSize

Name

CommandBufferSize -- Limit the maximum command length

Description

The CommandBufferSize directive controls the maximum command length permitted to be sent to the server. This allows you to effectively control what the longest command the server may accept it, and can help protect the server from various Denial of Service or resource-consumption attacks.

See also

Examples

CwdRatioMsg

Name

CwdRatioMsg -- Ratio directive

Description

The CwdRatioMsg directive .... Example: CwdRatioMsg

See also

Examples

DefaultChdir

Name

DefaultChdir -- Set starting directory for FTP sessions

Description

Determines the directory a user is placed in after logging in. By default, the user is put in their home directory. The specified directory can be relative to the user's home directory. NOTE: if the specified directory is not available the user will not be able to log in.

See also

DefaultRoot

Examples

DefaultQuota

Name

DefaultQuota -- Sets the default quota

Description

The DefaultQuota directive sets the default quota in bytes, this value is used if the .quota file does not exist.

See also

Quotas

Examples

#
# Set default to 1kb
#
DefaultQuota 1024 

DefaultRoot

Name

DefaultRoot -- Sets default chroot directory

Description

The DefaultRoot directive controls the default root directory assigned to a user upon login. If DefaultRoot is set to a directory other than "/", a chroot operation is performed immediately after a client authenticates. This can be used to effectively isolate the client from a portion of the host system filespace. The specified root directory must begin with a / or can be the magic character '~'; meaning that the client is chroot jailed into their home directory.

If the DefaultRoot directive specifies a directory which disallows access to the logged-in user's home directory, the user's current working directory after login is set to the DefaultRoot instead of their normal home directory. DefaultRoot cannot be used in <Anonymous> configuration blocks, as the <Anonymous> directive explicitly contains a root directory used for Anonymous logins. The special character '~' is replaced with the authenticating user's home directory immediately after login. Note that the default root may be a subdirectory of the home directory, such as "~/anon-ftp".

The optional group-expression argument can be used to restrict the DefaultRoot directive to a unix group, groups or subset of groups. The expression takes the format: [!]group-name1[,[!]group-name2[,...]]. The expression is parsed in a logical boolean AND fashion, such that each member of the expression must evaluate to logically TRUE in order for the DefaultRoot directive to apply. The special character '!' is used to negate group membership.

Care should be taken when using DefaultRoot. Chroot "jails" should not be used as methods for implementing general system security as there are potentially ways that a user can "escape" the jail.

See also

Examples

Example of a DefaultRoot configuration:
ServerName "A test ProFTPD Server"
ServerType inetd
User ftp
Group ftp
#
# This causes proftpd to perform a chroot into the authenticating user's directory 
immediately after login.
# Once this happens, the user is unable to "see" higher level directories.
# Because a group-expression is included, only users who are a member of
# the group 'users' and NOT a member of 'staff' will have their default
# root directory set to '~'.
DefaultRoot ~ users,!staff
... 

DefaultServer

Name

DefaultServer -- Set the default server

Description

The DefaultServer directive controls which server configuration is used as the default when an incoming connection is destined for an IP address which is neither the host's primary IP address or one of the addresses specified in a <VirtualHost> configuration block. Normally such "unknown" connections are issued a "no server available to service your request" message and disconnected. When DefaultServer is turned on for either the primary server configuration or a virtual server, all unknown destination connections are serviced by the default server. Only a single server configuration can be set to default.

See also

Examples

DefaultTransferMode

Name

DefaultTransferMode -- Set the default method of data transfer

Description

DefaultTransferMode sets the default transfer mode of the server. By default, carriage-return/linefeed translation will be performed (ASCII mode).

See also

Examples

DeferWelcome

Name

DeferWelcome -- Don't show welcome message until user has authenticated

Description

The DeferWelcome directive configures a master or virtual server to delay transmitting the ServerName and address to new connections, until a client has successfully authenticated. If enabled, the initial welcome message will be exceedingly generic and will not give away any type of information about the host that the daemon is actively running on. This can be used by security-conscious administrators to limit the amount of "probing" possible from non-trusted networks/hosts.

Examples

DeleteAbortedStores

Name

DeleteAbortedStores -- Enable automatic deletion of partially uploaded files

Description

The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded files if the transfer is stopped via the ABOR command rather than a connection failure.

See also

HiddenStor

Examples

Deny

Name

Deny -- Access control directive

Description

The Deny directive is used to create a list of hosts and/or networks which will explicitly be denied access to a given <Limit> context block. The magic keywords all and none can be used to indicate that all hosts are denied access, or that no hosts are explicitly denied (respectively). For more information on the syntax and usage of Deny see: Allow and Order.

See also

Allow Order Limit

Examples

DenyAll

Name

DenyAll -- Deny all clients

Description

The DenyAll directive is analogous to a combination of "order deny,allow <cr> deny from all", with the exception that it has a higher precendance when parsed. It is provided as a convenient method of completely denying access to a directory, anonymous ftp or limit block. Because of its precedence, it should not be intermixed with normal Order/Deny directives. The DenyAll directive can be overridden at a lower level directory by using AllowAll. DenyAll and AllowAll are mutually exclusive.

See also

AllowAll

Examples

DenyFilter

Name

DenyFilter -- Regular expression of command arguments to be blocked

Description

Similar to AllowFilter, DenyFilter specifies a regular expression which must not match any of the command arguments. If the regex does match, a "Forbidden command" error is returned to the client. This can be especially useful for forbidding certain command argument combinations from ever reaching ProFTPD.

Notes: The 'PASV' command cannot be blocked using this directive.

See also

AllowFilter

Examples

# We don't want to allow any commands with % being sent to the server
DenyFilter "%"

DenyGroup

Name

DenyGroup -- Group based deny rules

Description

DenyGroup specifies a group-expression that is specifically denied within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be denied access to the block. The expression is parsed as a boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in order for the explicit deny to apply.

Examples

DenyUser

Name

DenyUser -- User based deny rules

Description

DenyUser specifies a user-expression that is specifically denied within the context of the <Limit> block it is applied to. user-expression is a comma delimited list of users or "not" users (by prefixing a user name with the `!' character). The expression is parsed as a boolean "and" list, meaning that all elements of the expression must evaluate to logically true in order for the explicit deny to apply.

Examples

Directory

Name

Directory -- FIXME FIXME

Description

This directive creates a block of configuration directives which applies only to the specified directory and its sub-directories. The block is ended with </Directory>. Per-directory configuration is enabled during run-time with a "closest" match algorithm, meaning that the <Directory> directive with the closest matching path to the actual pathname of the file or directory in question is used. Per-directory configuration is inherited by all sub-directories until a closer matching <Directory> is encountered, at which time the original per-directory configuration is replaced with the closer match. Note that this does not apply to <Limit> </Limit> blocks, which are inherited by all sub-directories until a <Limit> block is reached in a closer match.

A trailing slash and wildcard ("/*") can be appended to the directory, specifying that the configuration block applies only to the contents (and sub-contents), not to the actual directory itself. Such wildcard matches always take precedence over non-wildcard <Directory> configuration blocks. <Directory> blocks cannot be nested (they are automatically nested at run-time based on their pathnames). Pathnames must always be absolute (except inside <Anonymous>), and should not reference symbolic links. Pathnames inside an <Anonymous> block can be relative, indicating that they are based on the anonymous root directory.

[Notes for ProFTPD 1.1.3 and later only] Pathnames that begin with the special character '~' and do not specify a username immediately after ~ are put into a special deferred mode. When in deferred mode, the directory context is not hashed and sorted into the configuration tree at boot time, but rather this hashing is deferred until a user authenticates, at which time the '~' character is replaced with the user's home directory. This allows a global <Directory> block which applies to all user's home directories, or sub-directories thereof.

See also

Limit

Examples

#Default usage of the directory directive
<Directory /users/robroy/private>
  HideNoAccess
</Directory>

#Example with username-expanding
<Directory ~/anon-ftp>
  <Limit WRITE>
    DenyAll
  </Limit>
</Directory>

DirFakeGroup

Name

DirFakeGroup -- Hide real file/directory group

Description

DirFakeGroup can be used to hide the true group of files (including directories, fifos, etc.) in a directory listing. If simply turned On, DirFakeGroup will display all files as being owned by group 'ftp'. Optionally, the groupname argument can be used to specify a specific group other than 'ftp'. "~" can be used as the argument in order to display the primary group name of the current user.

Both DirFakeGroup and DirFakeUser are completely cosmetic; the groupname or username specified don't need to exist on the system, and neither directive affects permissions, real ownership or access control in any way.

Examples

DirFakeMode

Name

DirFakeMode -- Hide real file/directory permissions

Description

The DirFakeMode directive configures a mode (or permissions) which will be displayed for ALL files and directories in directory listings. For each subset of permissions (user, group, other), the "execute" permission for directories is added in listings if the "read" permission is specified by this directive. As with DirFakeUser, and DirFakeGroup, the "fake" permissions shown in directory listings are cosmetic only, they do not affect real permissions or access control in any way.

Examples

  DirFakeMode 0640

Will result in:

  -rw-r----- ... arbitrary.file
  drwxr-x--- ... arbitrary.directory

DirFakeUser

Name

DirFakeUser -- Hide real file/directory owner

Description

DirFakeUser can be used to hide the true user owners of files (including directories, fifos, etc.) in a directory listing. If simply turned On, DirFakeUser will display all files as being owned by user 'ftp'. Optionally, the username argument can be used to specify a specific user other than 'ftp'. "~" can be used as the argument in order to display the current user's username.

Both DirFakeGroup and DirFakeUser are completely cosmetic; the groupname or username specified don't need to exist on the system, and neither directive affects permissions, real ownership or access control in any way.

Examples

DisplayConnect

Name

DisplayConnect -- Sets connect banner file

Description

The DisplayConnect directive configures an ASCII text filename which will be displayed to the user when they initially connect but before they login. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for starting in the home directory of the user the server is running as. As this can lead confusion, absolute pathnames are suggested. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.

See also

Examples

DisplayFirstChdir

Name

DisplayFirstChdir -- FIXME FIXME

Description

The DisplayFirstChdir directive configures an ASCII text filename which will be displayed to the user the first time they change into a directory (via CWD) per a given session. The file will also be displayed if proftpd detects that its last modification time has changed since the previous CWD into a given directory. If the filename is relative, it is looked for in the new directory that the user has changed into. Note that for anonymous ftp logins (see <Anonymous>), the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.

DisplayFirstChdir, DisplayConnect, DisplayLogin and DisplayQuit support the following "magic cookies" (only in 0.99.0pl10 and later), which are replaced with their respective strings before being displayed to the user.

%T	Current Time

%F	Available space on file system

%C	Current working directory

%R	Remote host name

%L	Local host name

%u	Username reported by ident protocol

%U	Username originally used in login

%M	Max number of connections

%N	Current number of connections

%E	Server admin's e-mail address

 
%x	The name of the user's class

%y	Current number of connections from the user's class

%z	Max number of connections from the user's class

NOTE: not all of these may have a rational value, depending on the context in which they're used (e.g., %u if ident lookups are off).

Examples

DisplayGoAway

Name

DisplayGoAway -- FIXME FIXME

Description

The DisplayGoAway directive specifies an ASCII text filename which will be displayed to the user if the class they're a member of has too many users logged in and their login request has been denied. DisplayGoAway supports the same "magic cookies" as DisplayFirstChdir.

See also

DisplayFirstChdir

Examples

DisplayLogin

Name

DisplayLogin -- FIXME FIXME

Description

The DisplayLogin directive configures an ASCII text filename which will be displayed to the user when they initially login. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for in the initial directory a user is placed in immediately after login (home directory for unix user logins, anonymous-root directory for anonymous logins). Note: that for jailed logins, the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client. DisplayLogin supports the same "magic cookies" as DisplayFirstChdir.

See also

Examples

DisplayQuit

Name

DisplayQuit -- FIXME FIXME

Description

DisplayQuit configures an ASCII text filename which will be displayed to the user when they quit. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for in current directory a user is in when they logout -- for this reason, a absolute filename is usually preferable. NOTE: for jailed logins, the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client. DisplayQuit supports the "magic cookies" listed under DisplayFirstChdir.

See also

Examples

DisplayReadme

Name

DisplayReadme -- FIXME FIXME

Description

Module: mod_readme The DisplayReadme directive notifies the user of the last change date of the specified file or pattern. Only a single DisplayReadme directive is allowed per configuration scope. DisplayReadme README Will result in: Please read the file README it was last modified on Sun Oct 17 10:36:14 1999 - 0 days ago Being displayed to the user on a cwd. DisplayReadmePattern README* Will result in: Please read the file README it was last modified on Tue Jan 25 04:47:48 2000 - 0 days ago Please read the file README.first it was last modified on Tue Jan 25 04:48:04 2000 - 0 days ago Being displayed to the user on a cwd.

See also

Examples

ExtendedLog

Name

ExtendedLog -- FIXME FIXME

Description

The ExtendedLog directive allows customizable logfiles to be generated, either globally or per VirtualHost. The filename argument must contain an absolute pathname to a logfile which will be appended to when proftpd starts; the pathname should not be to a file in a nonexistent directory, to a world-writeable directory, or be a symbolic link (unless AllowLogSymlinks is set to on). Multiple logfiles (potentially with different command classes and formats) can be created. Optionally, the command-classes argument can be used to control which types of commands are logged. If not command classes are specified, proftpd logs all commands by default (passwords are hidden). command-classes is a comma delimited (no whitespace!) list of which commands to log.

The following are valid classes: NONE No commands AUTH Authentication commands (USER, PASS) INFO Informational commands (PWD, SYST, etc) DIRS Directory commands (LIST, CWD, MKD, etc) READ File reading (RETR) WRITE File/directory writing or creation MISC Miscellaneous commands (SITE, etc) ALL All commands (default)

If a format-nickname argument is supplied, ExtendedLog will use the predefined logformat (created by LogFormat). Otherwise, the default format of "%h %l %u %t \"%r\" %s %b" is used.

Examples

For example, to log all read and write operations to /var/log/ftp.log (using the default format), you could:

ExtendedLog /var/log/ftp.log read,write

FileRatioErrMsg

Name

FileRatioErrMsg -- FIXME FIXME

Description

The FileRatioErrMsg directive .... Example: FileRatioErrMsg

See also

Examples

FooBarDirective

Name

FooBarDirective -- FIXME FIXME

Description

FooBarDirective is a dummy directive to be used as a coding example only.

See also

Examples

Global

Name

Global -- FIXME FIXME

Description

The Global configuration block is used to create a set of configuration directives which is applied universally to both the main server configuration and all VirtualHost configurations. Most, but not all other directives can be used inside a Global block. In addition, multiple <Global> blocks can be created. At runtime, all Global blocks are merged together and finally into each server's configuration. Global blocks are terminated by a matching </Global> directive.

See also

Examples

Group

Name

Group -- FIXME FIXME

Description

The Group directive configures which group the server daemon will normally run at. See User for more details.

See also

Examples

GroupOwner

Name

GroupOwner -- FIXME FIXME

Description

The GroupOwner directive configures which group all newly created directories and files will be owned by, within the context that GroupOwner is applied to. The group ID of groupname cannot be 0. Note that GroupOwner cannot be used to override the host OS/file system user/group paradigm. If the current user is not a member of the specified group, new files and directories will not be able to be chown()ed to the GroupOwner group. If this happens, file STOR (send file from client to server) and MKD/XMKD (mkdir) operations will succeed normally, however the new directory entries will be owned by the current user's default group (a warning message is also logged) instead of by the desired group. If you also use UserOwner in the same context, this restriction is lifted.

See also

Examples

GroupPassword

Name

GroupPassword -- FIXME FIXME

Description

The GroupPassword directive creates a special "group" password which allows all users in the specified group to authenticate using a single password. The group/password supplied is only effective inside the context to which GroupPassword is applied. The hashed-password argument is a standard cleartext password which has been passed through the standard unix crypt() library function. Extreme care should be taken when using GroupPassword, as serious security problems may arise if group membership is not carefully controlled.

See also

UserPassword

Examples

GroupRatio

Name

GroupRatio -- Ratio directive

Description

The GroupRatio directive .... Example: GroupRatio

See also

Examples

HiddenStor

Name

HiddenStor -- Enables more safe file uploads

Description

The HiddenStor directive enables two-step file uploads: files are uploaded as ".in.filename." and once the upload is complete, renamed to just "filename". This provides a degree of atomicity and helps prevent 1) incomplete uploads and 2) files being used while they're still in the progress of being uploaded. Note: if the temporary file name is already in use (e.g., a server crash during upload), it will prevent the file from being uploaded.

The REST (Restart STOR) command is automatically blocked when HiddenStor is enabled, with the server returning a 501 error code to the client.

Examples

HideGroup

Name

HideGroup -- FIXME FIXME

Description

The HideGroup directive configures a <Directory> or < Anonymous> block to hide all directory entries owned by the specified group, unless the group is the primary group of the currently logged-in, authenticated user . Normally, hidden directories and files cannot be seen via LIST or NLST commands but can be operated on via other FTP commands (CWD, DELE, RETR, etc). This behavior can be modified via the IgnoreHidden directive.

See also

See Also: HideUser, HideNoAccess, IgnoreHidden

Examples

HideNoAccess

Name

HideNoAccess -- Block the listing of directory entries to which the user has no access permissions

Description

The HideNoAccess directive configures a <Directory> or <Anonymous> block to hide all directory entries in a directory listing (via the LIST or NLST FTP commands) to which the current logged-in, authenticated user has no access to. Normal Unix-style permissions always apply, so that although a user may not be able to see a directory entry that has HideNoAccess applied, they will receive a normal "Permission denied" error message when attempting to blindly manipulate the file system object. The directory or file can be made completely invisible to all FTP commands by applying IgnoreHidden in conjunction with HideNoAccess.

See also

See Also: HideUser, HideGroup, IgnoreHidden

Examples

HideUser

Name

HideUser -- FIXME FIXME

Description

The HideUser directive configures a <Directory> or <Anonymous> block to hide all directory entries owned by the specified user, unless the owning user is the currently logged-in, authenticated user. Normally, hidden directories and files cannot be seen via LIST or NLST commands but can be operated on via other FTP commands (CWD, DELE, RETR, etc). This behavior can be modified via the IgnoreHidden directive.

See also

HideGroup, HideNoAccess, IgnoreHidden

Examples

HostRatio

Name

HostRatio -- Ratio directive

Description

The HostRatio directive .... Example: HostRatio

See also

Examples

IdentLookups

Name

IdentLookups -- Toggle ident lookups

Description

Normally, when a client initially connects to proftpd, the ident protocol (RFC1413) is used to attempt to identify the remote username. This can be controlled via the IdentLookups directive.

See also

Examples

IgnoreHidden

Name

IgnoreHidden -- Treat 'hidden' files as if they don't exist

Description

Normally, files hidden via HideNoAccess, HideUser or HideGroup can be operated on by all FTP commands (assuming Unix file permissions allow access), even though they do not appear in directory listings. Additionally, even when normal file system permissions disallow access, proftpd returns a "Permission denied" error to the client, indicating that the requested object does exist, even if it cannot be acted upon. IgnoreHidden configures a <Limit> block to completely ignore any hidden directory entries for the set of limited FTP commands. This has the effect of returning an error similar to "No such file or directory" when the client attempts to use the limited command upon a hidden directory or file.

See also

Examples

Include

Name

Include -- Load additional configuration directives from a file

Description

This directive allows you to include another configuration file within your current configuration file. The given file argument must be the full path to the file to be included.

See also

Examples

LDAPAuthBinds

Name

LDAPAuthBinds -- FIXME FIXME

Description

By default, the DN specified by LDAPDNInfo will be used to bind to the LDAP server to obtain user information, including the userPassword attribute. If LDAPAuthBinds is set to on, the DN specified by LDAPDNInfo will be used to fetch all user information except the userPassword attribute. Then, mod_ldap will bind to the LDAP server as the user who is logging in via FTP with the user-supplied password. If this bind succeeds, the user is considered authenticated and is allowed to log in. This method of LDAP authentication has the added benefit of supporting any password encryption scheme that your LDAP server supports.

See also

Examples

LDAPDefaultAuthScheme

Name

LDAPDefaultAuthScheme --  Set the authentication scheme/hash that is used when no leading {hashname} is present.

Description

Specifies the authentication scheme used for passwords with no {prefix} in the LDAP database. For example, if you are using something like userPassword: mypass in your LDAP database, you would want to set LDAPDefaultAuthScheme to clear.

See also

Examples

LDAPDefaultGID

Name

LDAPDefaultGID --  Set the default GID to be assigned to users when no uidNumber attribute is found.

Description

This directive is useful primarily in virtual-user environments common in large-scale ISPs and hosting organizations. If a user does not have a LDAP gidNumber attribute, the LDAPDefaultGID is used. This allows one to have a large number of users in an LDAP database without gidNumber attributes; setting this configuration directive will automatically assign those users a single GID.

See also

Examples

LDAPDefaultUID

Name

LDAPDefaultUID --  Set the default GID to be assigned to users when no uidNumber attribute is found.

Description

This directive is useful primarily in virtual-user environments common in large-scale ISPs and hosting organizations. If a user does not have a LDAP uidNumber attribute, the LDAPDefaultUID is used. This allows one to have a large number of users in an LDAP database without uidNumber attributes; setting this configuration directive will automatically assign those users a single UID.

See also

Examples

LDAPDNInfo

Name

LDAPDNInfo -- Set DN information to be used for initial bind

Description

This directive specifies the LDAP DN and password to use when binding to the LDAP server. If this configuration directive is not specified, anonymous binds are used.

See also

Examples

LDAPDoAuth

Name

LDAPDoAuth -- Enable LDAP authentication

Description

This configuration directive activates LDAP authentication. The second argument to this directive is the LDAP prefix to use for authentication. The third argument is a template to be used for the search filter; %u will be replaced with the username that is being authenticated. By default, the search filter template "(&(uid=%u)(objectclass=posixAccount))" is used. Search filter templates are only supported in mod_ldap v2.7 and later.

See also

Examples

LDAPDoGIDLookups

Name

LDAPDoGIDLookups --  Enable LDAP lookups for user group membership and GIDs in directory listings

Description

This configuration directive activates LDAP GID-to-name lookups in directory listings. The second argument to this directive is the LDAP prefix to use for GID-to-name lookups. The third argument is a template to be used for the search filter; %u will be replaced with the GID that is being looked up. By default, the search filter template "(&(gidNumber=%u)(objectclass=posixGroup))" is used. Search filter templates are only supported in mod_ldap v2.7 and later.

See also

Examples

LDAPDoUIDLookups

Name

LDAPDoUIDLookups --  Enable LDAP lookups for UIDs in directory listings

Description

This configuration directive activates LDAP UID-to-name lookups in directory listings. The second argument to this directive is the LDAP prefix to use for UID-to-name lookups. The third argument is a template to be used for the search filter; %u will be replaced with the UID that is being looked up. By default, the search filter template "(&(uidNumber=%u)(objectclass=posixAccount))" is used. Search filter templates are only supported in mod_ldap v2.7 and later.

See also

Examples

LDAPForceDefaultGID

Name

LDAPForceDefaultGID -- Force all LDAP-authenticated users to use the same GID.

Description

Even when a LDAPDefaultGID is configured, mod_ldap will allow individual users to have gidNumber attributes that will override this default GID. With LDAPForceDefaultGID enabled, all LDAP-authenticated users are given the default GID; GIDs may not be overridden by gidNumber attributes.

See also

Examples

LDAPForceDefaultUID

Name

LDAPForceDefaultUID -- Force all LDAP-authenticated users to use the same UID.

Description

Even when a LDAPDefaultUID is configured, mod_ldap will allow individual users to have uidNumber attributes that will override this default UID. With LDAPForceDefaultUID enabled, all LDAP-authenticated users are given the default UID; UIDs may not be overridden by uidNumber attributes.

See also

Examples

LDAPHomedirOnDemand

Name

LDAPHomedirOnDemand --  Enable the creation of user home directories on demand

Description

LDAPHomedirOnDemand activates on-demand home directory creation. If a user logs in and does not yet have a home directory, a home directory is created automatically.

In mod_ldap <= 2.7.6, the home directory will be owned by the same user and group that ProFTPD runs as (see the User and Group configuration directives). mod_ldap >= 2.8 can create home directories for users with any UID/GID, not just those with the same UID/GID as the main ProFTPD server.

The second argument allows you to specify the mode (default permissions) to use when creating home directories on demand, subject to ProFTPD's umask (see the Umask directive). If no directory mode is specified, the default of 0755 is used. Directory mode setting is only supported in mod_ldap v2.7 or later.

See also

Examples

LDAPHomedirOnDemandPrefix

Name

LDAPHomedirOnDemandPrefix --  Enable the creation of user home directories on demand

Description

LDAPHomedirOnDemandPrefix enables a prefix to be specified for on-demand home directory creation. This is most useful if mod_ldap is being used to authenticate against an LDAP directory that does not return a homeDirectory attribute, either because it cannot (Microsoft Active Directory, for example) or because you do not wish to extend your existing directory schema.

For example, setting this directive to "/home" and logging in as the user "joe" would result in his home directory being created as "/home/joe". The directory will be created with the mode specified in LDAPHomedirOnDemand. To use this directive, LDAPHomedirOnDemand must be enabled.

See also

Examples

LDAPHomedirOnDemandPrefixNoUsername

Name

LDAPHomedirOnDemandPrefixNoUsername -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

LDAPHomedirOnDemandSuffix

Name

LDAPHomedirOnDemandSuffix --  Specify an additional directory to be created inside a user's home directory on demand.

Description

to be created within a user's home directory when it is created on demand. For example, if a user's home directory is "/home/user", setting this configuration directive to "public_html" will also create "/home/user/public_html" on demand. In mod_ldap v2.7.6 and earlier, you must also activate LDAPHomedirOnDemand in your configuration.

mod_ldap >= 2.8 supports multiple suffix arguments and does not require LDAPHomedirOnDemand to be enabled.

See also

Examples

LDAPNegativeCache

Name

LDAPNegativeCache -- Enable negative caching for LDAP lookups

Description

LDAPNegativeCache specifies whether or not to cache negative responses from the LDAP server when using LDAP for UID/GID lookups. This option is useful if you also use/are in transition from another authentication system; if there are many users in your old authentication system that aren't in the LDAP database, there can be a significant delay when a directory listing is performed as the UIDs not in the LDAP database are repeatedly looked up in an attempt to present usernames instead of UIDs in directory listings. With LDAPNegativeCache set to on, negative ("not found") responses from the LDAP server will be cached and speed will improve on directory listings that contain many users not present in the LDAP database.

See also

Examples

LDAPQueryTimeout

Name

LDAPQueryTimeout -- Set a timeout for LDAP queries

Description

Sets the timeout used for LDAP directory queries. The default is the default timeout used by your LDAP API.

See also

Examples

LDAPSearchScope

Name

LDAPSearchScope -- Specify the search scope used in LDAP queries

Description

Set the scope used for LDAP searches. The default setting, subtree, searches for all entries in the tree from the current level down. Setting this directive to onelevel searches only one level deep in the LDAP tree.

See also

Examples

LDAPServer

Name

LDAPServer -- Specify the LDAP server to use for lookups

Description

LDAPServer allows you to to specify the hostname(s) and port(s) of the LDAP server(s) to use for LDAP authentication. If no LDAPServer configuration directive is present, the default LDAP servers specified by your LDAP API will be used.

See also

Examples

LDAPUseTLS

Name

LDAPUseTLS -- Enable TLS/SSL connections to the LDAP server.

Description

By default, mod_ldap connects to the LDAP server via a non-encrypted connection. Enabling this option causes mod_ldap to use an encrypted (TLS/SSL) connection to the LDAP server. If a secure connection to the LDAP server fails, mod_ldap will not authenticate users (mod_ldap will *not* fall back to an unsecure connection).

See also

Examples

LeechRatioMsg

Name

LeechRatioMsg -- Sets the 'over ratio' error message

Description

The LeechRatioMsg directive defines the response message sent back to the client upon breaking their quota limits.

See also

Examples

LeechRatioMsg "please upload as well as download"

Limit

Name

Limit -- FIXME FIXME

Description

The Limit configuration block is used to place access restrictions on one or more FTP commands, within a given context. Limits flow downward, so that a Limit configuration in the server config context applies to all <Directory> and <Anonymous> blocks that also reside in the configuration; until it is overridden by a "lower" <Limit> block. Any number of command parameters can be specified, against which the contents of the <Limit> block will be applied. command can be any valid FTP command, but is generally one of the following: CWD (Change Working Directory) Sent by client when changing directories. MKD / XMKD (MaKe Directory) Sent by client to create a new directory. RNFR (ReName FRom), RNTO (ReName TO) Sent as a pair by client to rename a directory entry. DELE (DELEte) Sent by client to delete a file. RMD / XRMD (ReMove Directory) Sent by client to remove a directory. RETR (RETRieve) Transfer a file from the server to the client. STOR (STORe) Transfer a file from the client to the server. In addition, the following command-groups are accepted. They have a lower precedence than real commands, meaning that a real command limit will always be applied instead of the command-group. READ All FTP commands which deal with file reading (directory listing not included): RETR, SITE, SIZE, STAT WRITE All FTP commands which deal with file or directory write/creation/deletion: APPE, DELE, MKD, RMD, RNTO, STOR, XMKD, XRMD DIRS All FTP commands which deal with directory listing: CDUP, CWD, LIST, MDTM, NLST, PWD, RNFR, XCUP, XCWD, XPWD ALL ALL FTP commands (identical to READ WRITE DIRS). Note this group has the lowest precedence of all; it will not override a limit imposed by another command-group (e.g. DIRS). Finally, a special command is allowed which can be used to control login access: LOGIN Connection or login to the server. Applying a <Limit> to this pseudo-command can be used to allow or deny initial connection or login to the context. It has no effect, and is ignored, when used in a context other than server config, <VirtualHost> or <Anonymous> (i.e. using it in a <Directory> context is meaningless). <Limit> command restrictions should not be confused with file/directory access permission. While limits can be used to restrict a command on a certain directory, they cannot be used to override the file permissions inherent to the base operating/file system. The following FTP commands cannot be restricted via <Limit>: ABOR HELP MODE (not implemented, always S) NOOP PASS (use <Limit LOGIN>) PASV PORT QUIT REST (use AllowRetrieveRestart, AllowStoreRestart) STRU (not implemented, always F) SYST TYPE USER (use <Limit LOGIN>)

See also

See Also: IgnoreHidden

Examples

LogFormat

Name

LogFormat -- Specify a logging format

Description

The LogFormat directive can be used to create a custom logging format for use with the ExtendedLog directive. Once created, the format can be referenced by the specified nickname. The format-string argument can consist of any combination of letters, numbers and symbols. The special character % is used to start a meta-sequence (see below). To insert a literal % character, use %%.

The following meta sequences are available and are replaced as indicated when logging. %A   Anonymous username (password given), or UNKNOWN if non-anonymous %b   Bytes sent for request %f   Filename stored or retrieved, absolute path (not chrooted) %F   Filename stored or retrieved, as the client sees it %{FOOBAR}e   Contents of environment variable FOOBAR. Note that the server does not set any environment variables itself. %h   Remote host name %a   Remote IP address %l   Remote username (from ident), or UNKNOWN if ident lookup failed %m   Command (method) name received from client, e.g., RETR %p   Local server port number %v   Local server name %P   Local server process id (pid) %r   Full command line received from client %t   Current local time %{format}t   Current local time formatted (strftime(3) format) %T   Time taken to transmit/receive file, in seconds %s   Numeric FTP response code (status) %u   Local authenticated userid

Examples

LoginPasswordPrompt

Name

LoginPasswordPrompt -- FIXME FIXME

Description

If set to off, ProFTPd will skip the password request if the login will be denied regardless of password, e.g., if a <Limit LOGIN> directive forbids the connection.

See also

Examples

LsDefaultOptions

Name

LsDefaultOptions -- FIXME FIXME

Description

Normally, FTP commands involving directory listings (NLST, LIST and STAT) use the arguments (options) passed by the client to determine what files are displayed and the format they are displayed in. Using the LsDefaultOptions directive can alter the default behavior of such listings, but implying that a certain option (or options) is always present. For example, to force all directory listings to always display ".dotfiles", one might: LsDefaultOptions "-a"

See also

Examples

MasqueradeAddress

Name

MasqueradeAddress -- Configure the server address presented to clients

Description

MasqueradeAddress causes the server to display the network information for the specified IP address or DNS hostname to the client, on the assumption that that IP address or DNS host is acting as a NAT gateway or port forwarder for the server.

See also

Examples

    MasqueradeAddress nat-gw.mydomain.com

MaxClients

Name

MaxClients -- Limits the number of users that can connect

Description

The MaxClients directive configures the maximum number of authenticated clients which may be logged into a server or anonymous account. Once this limit is reached, additional clients attempting to authenticate will be disconnected. The special value none may be supplied which removes all maximum connection limits from the applicable configuration context. Additionally, an optional message argument may be used which will be displayed to a client attempting to exceed the maximum value; immediately before disconnection. The message argument is parsed for the magic string "%m", which is replaced with the configured maximum value. If message is not supplied, a system-wide default message is used. Example: MaxClients 5 "Sorry, the maximum number of allowed users are already connected (%m)" Results in: 530 Sorry, the maximum number of allowed users are already connected (5)

See also

Examples

MaxClientsPerHost

Name

MaxClientsPerHost -- Limits the connections per client machine

Description

The MaxClientsPerHost directive configures the maximum number of clients allowed to connect per host. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number clients (%m) from your host are already connected." is used.

See also

MaxClients, MaxHostsPerUser

Examples

MaxClientsPerHost 1 "Sorry, you may not connect more than one time."
Results in: 530 Sorry, you may not connect more than one time.

MaxHostsPerUser

Name

MaxHostsPerUser -- Limit the number of connections per userid

Description

The MaxHostsPerUser directive configures the maximum number of times any given login can connection at any given time. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number of hosts (%m) for this user already connected."

Examples

MaxHostsPerUser 1 "Sorry, you may not connect more than one time."
Results in: 530 Sorry, you may not connect more than one time.

MaxInstances

Name

MaxInstances -- Sets the maximum number of child processes to be spawned

Description

The MaxInstances directive configures the maximum number of child processes that may be spawned by a parent proftpd process in standalone mode. The directive has no effect when used on a server running in inetd mode. Because each child proftpd process represents a single client connection, this directive also controls the maximum number of simultaneous connections allowed. Additional connections beyond the configured limit are syslog'd and silently disconnected. The MaxInstances directive can be used to prevent undesirable denial-of-service attacks (repeatedly connecting to the ftp port, causing proftpd to fork-bomb). By default, no limit is placed on the number of child processes that may run at one time.

See also

Examples

MaxLoginAttempts

Name

MaxLoginAttempts -- Sets how many password attempts are allowed before disconnection

Description

The MaxLoginAttempts directive configures the maximum number of times a client may attempt to authenticate to the server during a given connection. After the number of attempts exceeds this value, the user is disconnected and an appropriate message is logged via the syslog mechanism.

See also

Examples

MultilineRFC2228

Name

MultilineRFC2228 -- FIXME FIXME

Description

By default, proftpd sends multiline responses as per RFC 959, i.e.: 200-First line More lines... 200 Last line RFC 2228 specifies that "6xy" response codes will be sent as follows: 600-First line 600-More lines... 600 Last line Note that 2228 ONLY specifies this for response codes starting with '6'. Enabling this directive causes ALL responses to be sent in this format, which may be more compatible with certain web browsers and clients. Also note that this is NOT the same as wu-ftpd's multiline responses, which do not comply with any RFC. Using this method of multilines is more likely to be compatible with all clients, although it isn't strictly RFC, and is thus not enabled by default.

See also

Examples

MySQLInfo

Name

MySQLInfo -- Configures the MySQL driver

Description

This directive is deprecated as of 1.2.0. Please use SQLConnectInfo instead.

Configures the MySQL database driver (the database may be remote). A connection isn't made until use of a SQL feature requires it, after which it may be held open for the lifetime of the FTP session depending on the directives in use. Use `""' to specify a null password.

See also

Examples

Order

Name

Order -- Configures the precedence of the Limit directives

Description

The Order directive configures the order in which Allow and Deny directives are checked inside of a <Limit> block. Because Allow directives are permissive, and Deny directives restrictive, the order in which they are examined can significantly alter the way security functions. If the default setting of allow,deny is used, "allowed" access permissions are checked first. If an Allow directive explicitly allows access to the <Limit> context, access is granted and any Deny directives are never checked. If Allow did not explicitly permit access, Deny directives are checked. If any Deny directive applies, access is explicitly denied. Otherwise, access is granted. When deny,allow is used, "deny" access restrictions are checked first. If any restriction applies, access is denied immediately. If nothing is denied, Allow permissions are checked. If an Allow explicitly permits access, access to the entire context is permitted; otherwise access is implicitly denied. For clarification, the following illustrates the steps used when checking Allow/Deny access: Order allow,deny Check Allow directives. If one or more apply, exit with result: ALLOW Check Deny directives. If one or more apply, exit with result: DENY Exit with default implicit ALLOW Order deny,allow Check Deny directives. If one or more apply, exit with result: DENY Check Allow directives. If one or more apply, exit with result: ALLOW Exit with default implicit: DENY

See also

Examples

PassivePorts

Name

PassivePorts -- Specify the ftp-data port range to be used

Description

PassivePorts restricts the range of ports from which the server will select when sent the PASV command from a client. The server will randomly choose a number from within the specified range until an open port is found. Should no open ports be found within the given range, the server will default to a normal kernel-assigned port, and a message logged.

The port range selected must be in the non-privileged range (eg. greater than or equal to 1024); it is STRONGLY RECOMMENDED that the chosen range be large enough to handle many simultaneous passive connections (for example, 49152-65534, the IANA-registered ephemeral port range).

See also

Examples

# Use the IANA registered ephemeral port range
PassivePorts 49152 65534

PathAllowFilter

Name

PathAllowFilter -- FIXME FIXME

Description

PathAllowFilter allows the configuration of a regular expression that must be matched for all newly uploaded (stored) files. The regular expression is applied against the entire pathname specified by the client, so care must be taken when creating a proper regex. Paths that fail the regex match result in a "Forbidden filename" error being returned to the client. If the regular-expression argument contains whitespace, it must be enclosed in quotes.

See also

Examples

# Only allow a-z 0-9 . - _ in file names,
PathAllowFilter ^[a-z0-9._-]+$

# as above but with upper case characters as well
PathAllowFilter ^[A-Za-z0-9._-]+$

PathDenyFilter

Name

PathDenyFilter -- FIXME FIXME

Description

Similar to PathAllowFilter, PathDenyFilter specifies a regular expression which must not match any uploaded pathnames. If the regex does match, a "Forbidden filename" error is returned to the client. This can be especially useful for forbidding .ftpaccess or .htaccess files.

See also

Examples

# We don't want .ftpaccess or .htaccess files to be uploaded
PathDenyFilter "(\\.ftpaccess)|(\\.htaccess)$"

PersistentPasswd

Name

PersistentPasswd -- FIXME FIXME

Description

The PersistentPasswd directive controls how proftpd handles authentication, user/group lookups, and user/group to name mapping. If set to On, proftpd will attempt to open the system-wide /etc/passwd, /etc/group (and /etc/shadow, potentially) files itself, holding them open even during a chroot()ed login (note that /etc/shadow is never held open, for security reasons). On some platforms, you must turn this option on, as the libc functions are incapable of accessing these databases from inside of a chroot(). At configure-time, the configuration script will attempt to detect whether or not you need this support, and make it the default. However, such "guessing" may fail, and you will have to manually enable or disable the feature. If you cannot see user or group names when performing a directory listing inside an anonymous chrooted login, this indicates you must enable the directive. Use of the AuthUserFile or AuthGroupFile directives will force partial support for persistent user or group database files; regardless of PersistentPasswd's setting.

Note: NIS or NIS+ users will most likely want to disable this feature, regardless of proftpd's detected configuration defaults. Failure to disable this will make your NIS/NIS+ maps not work! On certain systems, you may also need to compile ProFTPD with the --enable-autoshadow option in order to authenticate both users from NIS maps and local users.

See also

Examples

PidFile

Name

PidFile -- FIXME FIXME

Description

The PidFile directive sets the file to which the server records the process id of the daemon. The filename should be relative to the system root, ie /var/run/proftpd/pidfile. The PidFile is only used in standalone mode. It is often useful to be able to send the server a signal, so that it closes and then reopens its ErrorLog and TransferLog, and re-reads its configuration files. This is done by sending a SIGHUP (kill -1) signal to the process id of the master daemon listed in the PidFile.

See also

Examples

Port

Name

Port -- FIXME FIXME

Description

The Port directive configures the TCP port which proftpd will listen on while running in standalone mode. It has no effect when used upon a server running in inetd mode (see ServerType). The directive can be used in conjunction with <VirtualHost> in order to run a virtual server on the same IP address as the master server, but listening on a different port.

For any server, either <VirtualHost> or server config, setting Port 0 effectively turns off that server.

See also

Examples

PostgresInfo

Name

PostgresInfo -- Postgres backend configuration (Deprecated)

Description

This directive is deprecated, please use SQLConnectInfo instead.

Configures the Posgresql database driver (the database may be remote). A connection isn't made until use of a SQL feature requires it, after which it may be held open for the lifetime of the FTP session depending on the directives in use.

See also

Examples

PostgresInfo myserver.example.com proftpd wibble ftpusers

PostgresPort

Name

PostgresPort -- Sets the port postgres is listening on

Description

This directive is deprecated, please use SQLConnectInfo instead

Specifies which TCP/IP port to use for connecting. Default is 5432, or UNIX socket for localhost.

See also

Examples

PostgresPort 3306

QuotaBlockName

Name

QuotaBlockName -- FIXME FIXME

Description

The QuotaBlockName directive is used in conjunction with the QuotaBlockSize directive to control user output from the module. This directive specifies the name given to the values displayed (ie byte, kilobyte, kb etc etc). Example: QuotaBlockName kb

See also

Examples

QuotaBlockSize

Name

QuotaBlockSize -- FIXME FIXME

Description

The QuotaBlockSize directive is used in conjuntion with the QuotaBlockName directive to control how the user output is handled. QuotaBlockSize specifies the factor by which the values in the user reports are divided before display. Example: QuotaBlockSize 1024

See also

Examples

QuotaCalc

Name

QuotaCalc -- FIXME FIXME

Description

The QuotaCalc directive controls whether calculation is done on the fly. If the directive is set to 'on' and either there is no .quota file or the quota would go negative then calculation is done on the fly rather than at the end of the session.

See also

Examples

QuotaExempt

Name

QuotaExempt -- FIXME FIXME

Description

The QuotaExempt directive lists the UIDs which are not subject to quota controls, using UIDs rather than symbolic user names speeds up the loading and resolution process. Example: QuotaExempt 3000,3401,500

See also

Examples

Quotas

Name

Quotas -- FIXME FIXME

Description

The Quotas directive enables or disables Quota support. Example: Quotas on

See also

Examples

QuotaType

Name

QuotaType -- FIXME FIXME

Description

The QuotaType directive defines what happens to files which break the quota limits as they are uploaded. Setting the type to hard ensures that the file which violates the quota is deleted. uploaded.

See also

Examples

RateReadBPS

Name

RateReadBPS -- FIXME FIXME

Description

RateReadBPS sets the allowed byte per second download bandwidth in the given config context. Zero means no bandwidth limit. (See RateReadFreeBytes about limiting bandwidth only after some amount of downloaded bytes.) The usual place for this directive is in <VirtualHost> or <Directory> sections.

See also

Examples

RateReadFreeBytes

Name

RateReadFreeBytes -- FIXME FIXME

Description

RateReadFreeBytes is the amount of bytes to be transferred without any bandwidth limits, so with that option you can give full bandwidth for small files while limiting big ones. (See RateReadHardBPS on further info about what happens after the free amount was transferred.)

See also

Examples

RateReadHardBPS

Name

RateReadHardBPS -- FIXME FIXME

Description

RateReadHardBPS forces the bandwidth to the given RateReadBPS value after the RateReadFreeBytes amount of file was transfered. This means that if the user have huge bandwidth and downloaded the "free" amount fast, HardBPS will stop the transfer until the average goes down to the given limit. If the amount of FreeBytes is high and the ReadBPS is low then the user may wait for extended periods of time until the transfer continues. :-)

See also

Examples

RateWriteBPS

Name

RateWriteBPS -- FIXME FIXME

Description

RateWriteBPS sets the allowed byte per second upload bandwidth in the given config context. Zero means no bandwidth limit. (See RateWriteFreeBytes about limiting bandwidth only after some amount of uploaded bytes.) The usual place for this directive is in <VirtualHost> or <Directory> sections.

See also

Examples

RateWriteFreeBytes

Name

RateWriteFreeBytes -- FIXME FIXME

Description

RateWriteFreeBytes is the amount of bytes to be transferred without any bandwidth limits, so with that option you can give full bandwidth for small files while limiting big ones. (See RateWriteHardBPS on further info about what happens after the free amount was transferred.)

See also

Examples

RateWriteHardBPS

Name

RateWriteHardBPS -- FIXME FIXME

Description

RateWriteHardBPS forces the bandwidth to the given RateWriteBPS value after the RateWriteFreeBytes amount of file was transfered. This means that if the user have huge bandwidth and uploaded the "free" amount fast, HardBPS will stop the transfer until the average goes down to the given limit. If the amount of FreeBytes is high and the WriteBPS is low then the user may wait for extended periods of time until the transfer continues. :-) RateWriteHardBPS RatioFile (mod_ratio) Incomplete Ratios (mod_ratio) Incomplete RatioTempFile (mod_ratio) Incomplete

See also

Examples

RatioFile

Name

RatioFile -- Ratio directive

Description

The RatioFile directive .... Example: RatioFile

See also

Examples

Ratios

Name

Ratios -- FIXME FIXME

Description

The Ratios directive .... Example: Ratios

See also

Examples

RatioTempFile

Name

RatioTempFile -- Ratio directive

Description

The RatioTempFile directive .... Example: RatioTempFile

See also

Examples

RequireValidShell

Name

RequireValidShell -- Allow connections based on /etc/shells

Description

The RequireValidShell directive configures the server, virtual host or anonymous login to allow or deny logins which do not have a shell binary listed in /etc/shells. By default, proftpd disallows logins if the user's default shell is not listed in /etc/shells. If /etc/shells cannot be found, all default shells are assumed to be valid.

See also

Examples

RLimitCPU

Name

RLimitCPU -- Configure the maximum CPU time in seconds used by a process

Description

RLimitCPU takes 1 or 2 parameters. The first parameter sets the soft resource limit for all proftpd processes. The optional second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration.

CPU resource limits are expressed in seconds per process.

Examples

RLimitMemory

Name

RLimitMemory -- Configure the maximum memory in bytes used by a process

Description

RLimitMemory takes 1 or 2 parameters. The first parameter sets the soft resource limit for all proftpd processes. The optional second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration.

Memory resource limits are expressed in bytes per process. An optional case-insensitive units specifier may follow the number of bytes given: G (Gigabytes), M (Megabytes), K (Kilobytes), or B (bytes). If the units specifier is used, the given number of bytes is multiplied by the appropriate factor.

See also

RLimitCPU, RLimitMaxProcesses, RLimitOpenFiles

RLimitOpenFiles

Name

RLimitOpenFiles -- Configure the maximum number of open files used by a process

Description

RLimitOpenFiles takes 1 or 2 parameters. The first parameter sets the soft resource limit for all proftpd processes. The optional second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration.

File resource limits are expressed in number of files per process.

See also

RLimitCPU, RLimitMaxProcesses, RLimitMemory

RootLogin

Name

RootLogin -- Permit root user logins

Description

Normally, proftpd disallows root logins under any circumstance. If a client attempts to login as root, using the correct password, a special security message is sent to syslog. When the RootLogin directive is turned On, the root user may authenticate just as any other user could (assuming no other access control measures deny access); however the root login security message is still sysloged. Obviously, extreme care should be taken when using this directive.

The use of RootLogin in the Anonymous context is only valid when the User / Group defined in the Anonymous block is set to 'root'

See also

Examples

SaveRatios

Name

SaveRatios -- FIXME FIXME

Description

The SaveRatios directive .... Example: SaveRatios

See also

Examples

ScoreboardPath

Name

ScoreboardPath -- Sets the path to the scoreboard file

Description

The ScoreboardPath directive sets the directory where proftpd run-time scoreboard files (proftpd-*) are kept. These file(s) are necessary for MaxClients to work properly, as well as other utilities (such as ftpwho and ftpcount).

See also

Examples

ServerAdmin

Name

ServerAdmin -- Set the address for the server admin

Description

The ServerAdmin directive sets the email address of the administrator for the server or virtualhost. This address is displayed in magic cookie replacements (see DisplayLogin and DisplayFirstChdir).

See also

Examples

ServerIdent

Name

ServerIdent -- Set the message displayed on connect

Description

The ServerIdent directive sets the default message displayed when a new client connects. Setting this to off displays "[hostname] FTP server ready." If set to on, the directive can take an optional string argument, which will be displayed instead of the default text. Sites desiring to give out minimal information will probably want a setting like ServerIdent on "FTP Server ready.", which won't even reveal the hostname.

See also

Examples

ServerIdent on "Welcome to ftp.linux.co.uk"

ServerName

Name

ServerName -- Configure the name displayed to connecting users

Description

The ServerName directive configures the string that will be displayed to a user connecting to the server (or virtual server if the directive is located in a <VirtualHost> block). See Also: <VirtualHost>

See also

Examples

ServerType

Name

ServerType -- Set the mode proftpd runs in

Description

The ServerType directive configures the server daemon's operating mode. The type-identifier can be one of two values: inetd The daemon will expect to be run from the inetd "super server." New connections are passed from inetd to proftpd and serviced immediately. standalone The daemon starts and begins listening to the configured port for incoming connections. New connections result in spawned child processes dedicated to servicing all requests from the newly connected client.

See also

Examples

ShowDotFiles

Name

ShowDotFiles -- Toggle display of 'dotfiles'

Description

If set to on, files starting with a '.', except for the directories '.' and '..', will be displayed in directory listings. This directive has been deprecated in favor of LsDefaultOptions -- e.g., LsDefaultOptions "-A" -- and may be removed in future versions. See Also: LsDefaultOptions

See also

Examples

ShowSymlinks

Name

ShowSymlinks -- Toggle the display of symlinks

Description

Compatibility: 0.99.0pl6 and later Symbolic links (if supported on the host OS and filesystem) can be either shown in directory listings (including the target of the link) or can be "hidden" (proftpd dereferences symlinks and reports the target's permissions and ownership). The default behavior is to show all symbolic links when normal users are logged in, and hide them for anonymous sessions. If a symbolic link cannot be dereferenced for any reason (permissions, target does not exist, etc) and ShowSymlinks is off, proftpd displays the link as a directory entry of type 'l' (link) with the ownership and permissions of the actual link. Under ProFTPD versions 1.1.5 and higher, the default behavior in regard to ShowSymlinks has been changed so that symbolic links are always displayed as such (in all cases), unless ShowSymlinks off is explicitly set.

See also

Examples

SocketBindTight

Name

SocketBindTight -- Controls how TCP/IP sockets are created

Description

The SocketBindTight directive controls how proftpd creates and binds its initial tcp listen sockets in standalone mode (see ServerType). The directive has no effect upon servers running in inetd mode, because listen sockets are not needed or created. When SocketBindTight is set to off (the default), a single listening socket is created for each port that the server must listen on, regardless of the number of IP addresses being used by <VirtualHost> configurations. This has the benefit of typically requiring a relatively small number of file descriptors for the master daemon process, even if a large number of virtual servers are configured. If SocketBindTight is set to on, a listen socket is created and bound to a specific IP address for the master server and all configured virtual servers. This allows for situations where an administrator may wish to have a particular port be used by both proftpd (on one IP address) and another daemon (on a different IP address). The drawback is that considerably more file descriptors will be required if a large number of virtual servers must be supported. Example: Two servers have been configured (one master and one virtual), with the IP addresses 10.0.0.1 and 10.0.0.2, respectively. The 10.0.0.1 server runs on port 21, while 10.0.0.2 runs on port 2001. SocketBindTight off #default # proftpd creates two sockets, both bound to ALL available addresses. # one socket listens on port 21, the other on 2001. Because each socket is # bound to all available addresses, no other daemon or user process will be # allowed to bind to ports 21 or 2001. ... SocketBindTight on # proftpd creates two sockets again, however one is bound to 10.0.0.1, port 21 # and the other to 10.0.0.2, port 2001. Because these sockets are "tightly" # bound to IP addresses, port 21 can be reused on any address OTHER than # 10.0.0.1, and visa-versa with 10.0.0.2, port 2001. One side-effect of setting SocketBindTight to on is that connections to non-bound addresses will result in a "connection refused" message rather than the typical "500 Sorry, no server available to handle request on xxx.xxx.xxx.xxx.", due to the fact that no listen socket has been bound to the particular address/port pair. This may or may not be aesthetically desirable, depending on your circumstances.

See also

Examples

SQLAuthenticate

Name

SQLAuthenticate --  Specify authentication methods and what to authenticate

Description

The SQLAuthenticate directive controls the behavior of mod_sql regarding the authentication process. SQLAuthenticate can provide fine grained control over authentication of logins and file access for both users and groups. Using this directive, mod_sql can be configured to be the authoritative authentication mechanism - in that case, mod_sql provides authentication and all other authentication mechanisms will be bypassed.

The syntax for SQLAuthenticate can take one of two possible formats. The simplest syntax is a simple on | off format:

on

mod_sql will perform login authentication and will also control file access using both user ID and group ID. This is equivalent to the following alternative syntax:

SQLAuthenticate users groups userset groupset

off

mod_sql will not perform user or group lookups nor will it control file access or functionality.

A more complex syntax is provided to provide finer control of the behavior of mod_sql. Two features in particular may be controlled via this syntax:

  • Authorititative lookups and authentication

  • File access or functionality control based on UID or GID

The following command options are used to control these features. Note that each of these options may be listed in any order.

users[*]

If this option is present, user lookups will take place. Appending an asterisk to users will cause mod_sql to become authoritiative for user lookups. All other user authentication methods will be ignored. If this option is not included, mod_sql will not perform any user lookups.

groups[*]

If this option is present, group lookups will take place. Appending an asterisk to groups will cause mod_sql to become authoritiative for group lookups. All other authentication methods will be ignored. If this option is not included, mod_sql will not perform any group lookups.

userset[fast]

If this option is present, mod_sql will control file access or functionality by processing the (get|set|end)pwent calls. These calls are used to determine file access rights based on username. This option has no effect if the user[*] option is not present.

If mod_sql is used to authenticate a significant number of users, the (set|get|end)pwent calls can become expensive. The number of queries will be n+1, where n is the number of users to be looked up. On a large system, this can significantly slow logins. Using the usersetfast option will cause a single query to be performed to lookup all users, speeding up the login process. The drawback to this option is that memory utilization will be increased.

groupset[fast]

If this option is present, mod_sql will control file access or functionality by processing the (get|set|end)grent calls. These calls are used to determine file access rights based on groupname. This option has no effect if the group[*] option is not present.

If mod_sql is used to authenticate a significant number of groups, the (set|get|end)grent calls can become expensive. The number of queries will be n+1, where n is the number of groups to be looked up. On a large system, this can significantly slow logins. Using the groupsetfast option will cause a single query to be performed to lookup all groups, speeding up the login process. The drawback to this option is that memory utilization will be increased.

Turning off (not including) userset or groupset affects the functionality of mod_sql. Not allowing these lookups may remove the ability to control access or control functionality by group membership, depending on your other auth handlers and the data available to them. At the same time, choosing not to do these lookups may dramatically speed login for many large sites.

The 'fast' suffix is not appropriate for every site. Normally, mod_sql will retrieve a list of users and groups, and get information from the database on a per-user or per-group basis. This is query intensive -- it requires (n+1) queries, where n is the number of users or groups to lookup. By choosing 'fast' lookups, mod_sql will make a single SELECT query to get information from the database.

In exchange for the radical reduction in the number of queries, the single query will increase the memory consumption of the process -- all group or user information will be read at once rather than in discrete chunks.

Note:If the groupset option is specified, mod_sql requires that the SQL group table contain only a single record for each group. All members of a group must be specified in the single record. Make sure that the group table is created with a sufficent column size for group members - for example, a MySQL group table should use type TEXT for the group members column, providing 65535 characters for listing all of the group members in a comma-separated list.

SQLAuthoritative

Name

SQLAuthoritative -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLAuthTypes

Name

SQLAuthTypes -- FIXME FIXME

Description

This directive deprecates 'SQLEmptyPasswords', 'SQLScrambledPasswords', 'SQLSSLHashedPasswords', 'SQLPlaintextPasswords', and 'SQLEncryptedPasswords'. Specifies the allowed authentication types and their check order. YOU MUST SPECIFY AT LEAST ONE AUTHENTICATION METHOD. For example: SQLAuthTypes Crypt Empty means check whether the password in the database matches in UNIX crypt() format; if that fails, check to see if the password in the database is empty (matching ANY given password); if that fails, mod_sql refuses to authenticate the user. Current Types Plaintext: allows passwords in the database to be in plaintext OpenSSL: allows passwords in the database to be of the form '{digestname}hashedvalue'. This check is only available if you define 'HAVE_OPENSSL' when you compile proftd and you link with the OpenSSL 'crypto' library. Crypt: allows passwords in the database to be in UNIX crypt() form Backend: a database-specific backend check function. Not all backends support this. Specifically, the MySQL backend uses this type to authenticate MySQL 'PASSWORD()' encrypted passwords. The Postgres backend does nothing. Empty: allows empty passwords in the database, which match against ANYTHING the user types in. The database field must be a truly empty string -- that is, NULL values are never accepted. BE VERY CAREFUL WITH THIS AUTHTYPE.

SQLConnectInfo

Name

SQLConnectInfo -- FIXME FIXME

Description

This directive deprecates 'MySQLInfo', 'PostgresInfo', and 'PostgresPort'. Specifies connection information. Connection-info specifies the database, host, port, and other backend-specific information. username and password specify the username and password to connect as, respectively. Both default to NULL, which the backend will treat in some backend-specific manner. If you specify a password, you MUST specify a username. Any given backend has the opportunity (but not the responsibility) to check for syntax errors in the connection-info field at proftpd startup, but you shouldn't expect semantic errors (i.e., can't connect to the database) to be caught until mod_sql attempts to connect for a given host. The MySQL and Postgres backends connection-info is expected to be of the form: database[@hostname][:port] hostname will default to a backend-specific hostname (which happens to be 'localhost' for both the MySQL and Postgres backends), and port will default to a backend-specific default port (3306 for the MySQL backend, 5432 for the Postgres backend). Examples: SQLConnectInfo ftpusers@foo.com means "Try connecting to the database 'ftpuser' via the default port at 'foo.com'. Use a NULL username and a NULL password." SQLConnectInfo ftpusers:3000 admin means "Try connecting to the database 'ftpuser' via port 3000 at 'localhost'. Use the username 'admin' and a NULL password." SQLConnectInfo ftpusers@foo.com:3000 admin mypassword means "Try connecting to the database 'ftpuser' via port 3000 at 'foo.com'. Use the username 'admin' and the password 'mypassword'" Backends may require different information in the connection-info field; check your backend module for specifics.

SQLDefaultGID

Name

SQLDefaultGID -- FIXME FIXME

Description

Sets the default GID for users. Must be greater than SQLMinID.

SQLDefaultHomedir

Name

SQLDefaultHomedir -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLDefaultUID

Name

SQLDefaultUID -- FIXME FIXME

Description

Sets the default UID for users. Must be greater than SQLMinID.

SQLDoAuth

Name

SQLDoAuth -- FIXME FIXME

Description

Activates SQL authentication. This overrides all other directives -- SQLDoGroupAuth and SQLAuthoritative are ineffectual if SQLDoAuth is off.

SQLDoGroupAuth

Name

SQLDoGroupAuth -- FIXME FIXME

Description

This directive causes mod_sql to pretend it has no group information. It necessarily breaks ALL CONFIG FILES up to 1.2.0rc2, since mod_sql now assumes that group information is available UNLESS this directive is set to OFF. This DOESN'T override SQLAuthoritative -- if SQLAuthoritative is set to 'On' but SQLDoGroupAuth is set to 'Off', all group-related queries will fail without giving other modules the opportunity to handle them. Prior to 1.2.0, there was no way to provide group information from the database. This caused a few bugs, and reduced the functionality of this module.

SQLEmptyPasswords

Name

SQLEmptyPasswords -- Allow zero length passwords (DEPRECATED)

Description

This directive is deprecated, please use SQLAuthTypes instead

Specifies whether an empty (non-NULL but zero-length) password is acceped from the database. Default is no, and truly NULL passwords are never accepted. If the retrieved password is empty then whatever password the user typed is accepted as valid, but the module logs a warning at debug level 4.

See also

Examples

SQLEmptyPasswords on

SQLEncryptedPasswords

Name

SQLEncryptedPasswords -- Assume SQL passwords are encrypted (DEPRECATED)

Description

This directive is deprecated, please SQLAuthTypes instead

Specifies whether the password in the database may be in UNIX crypt() format. Default is true, with this being the only check done. A tool for generating crypted password text may be found at ftp://ftp.linpeople.org/pub/People/lilo/source/makepasswd-1.07.tar.gz

See also

Examples

SQLEncryptedPasswords on

SQLGidField

Name

SQLGidField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLGroupGIDField

Name

SQLGroupGIDField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLGroupInfo

Name

SQLGroupInfo -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLGroupMembersField

Name

SQLGroupMembersField -- FIXME FIXME

Description

Specifies the field in the group table that holds the group's member list.

SQLGroupnameField

Name

SQLGroupnameField -- FIXME FIXME

Description

Specifies the field in the group table that holds the group name.

SQLGroupTable

Name

SQLGroupTable -- FIXME FIXME

Description

Specifies the name of the table that holds group information.

SQLGroupWhereClause

Name

SQLGroupWhereClause -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLHomedir

Name

SQLHomedir -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLHomedirField

Name

SQLHomedirField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLHomedirOnDemand

Name

SQLHomedirOnDemand -- FIXME FIXME

Description

Specifies whether to automatically create a user's home directory if it doesn't exist at login.

SQLLog

Name

SQLLog -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLLogDirs

Name

SQLLogDirs -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLLogHits

Name

SQLLogHits -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLLogHosts

Name

SQLLogHosts -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLLoginCountField

Name

SQLLoginCountField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLLogStats

Name

SQLLogStats -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLMinID

Name

SQLMinID -- FIXME FIXME

Description

SQLMinID is checked whenever retrieving a user's GID or UID. If the retrieved values for GID or UID are less than the value of SQLMinID, they are reported as the values of, respectively, 'SQLDefaultGID' and 'SQLDefaultUID'.

SQLMinUserGID

Name

SQLMinUserGID -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLMinUserUID

Name

SQLMinUserUID -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLNamedQuery

Name

SQLNamedQuery -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLPasswordField

Name

SQLPasswordField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLProcessGrEnt

Name

SQLProcessGrEnt -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLProcessPwEnt

Name

SQLProcessPwEnt -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLRatios

Name

SQLRatios -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLRatioStats

Name

SQLRatioStats -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLScrambledPasswords

Name

SQLScrambledPasswords -- FIXME FIXME

Description

This directive is DEPRECATED. Please use SQLAuthTypes instead. Specifies whether to accept passwords in a backend specific format. For the MySQL backend, this means 'PASSWORD()' scrambled passwords. For the Postgres backend, this check does nothing.

SQLShellField

Name

SQLShellField -- FIXME FIXME

Description

Specifies the field in the user table that holds the user's shell. If this field doesn't exist or the result of the query is NULL, the shell is reported as "".

SQLShowInfo

Name

SQLShowInfo -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLSSLHashedPasswords

Name

SQLSSLHashedPasswords -- FIXME FIXME

Description

This directive is DEPRECATED. Please use SQLAuthTypes instead. Specifies whether to accept passwords of the form {digestname}hashedpassword from the database. This directive is only available if you define 'HAVE_OPENSSL' when you compile proftd and you link with the OpenSSL 'crypto' library. As an example, any of the following password entries in the database would match if the user typed the password 'testpassword': {SHA}IoFZRnP0iujh/70lps6DjKPgwkk= {SHA1}i7YRj4/Wk1rQh2o740pxfTJwj/0= {MD2}nS6iguewvAdrCnOMyQjB1w== {MD4}5wsGtJCkyXBzDJoVsQKjSg== {MD5}4WsquNEjFL9O+9YgOQbqbA==

SQLUidField

Name

SQLUidField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLUserInfo

Name

SQLUserInfo -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLUsernameField

Name

SQLUsernameField -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLUserTable

Name

SQLUserTable -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLUserWhereClause

Name

SQLUserWhereClause -- FIXFIXFIX

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

SQLWhereClause

Name

SQLWhereClause -- FIXME FIXME

Description

This directive deprecates 'SQLKey' and 'SQLKeyField'. Specifies a where clause that is added to every user query (this has no effect on group queries). The where clause *must* contain all relevant punctuation, and *must not* contain a leading 'and'. As an example of switching from the old-style 'SQLKey' and 'SQLKeyField' directives, if you had: SQLKey true SQLKeyfield LoginAllowed You would now use: SQLWhereClause "LoginAllowed = 'true'" This would be appended to every user-related query as the string " and (LoginAllowed = 'true')"

SyslogFacility

Name

SyslogFacility -- Set the facility level used for logging

Description

Proftpd logs its activity via the Unix syslog mechanism, which allows for several different general classifications of logging messages, known as "facilities." Normally, all authentication related messages are logged with the AUTHPRIV (or AUTH) facility [intended to be secure, and never seen by unwanted eyes], while normal operational messages are logged with the DAEMON facility. The SyslogFacility directive allows ALL logging messages to be directed to a different facility than the default. When this directive is used, ALL logging is done with the specified facility, both authentication (secure) and otherwise. The facility-level argument must be one of the following: AUTH (or AUTHPRIV), CRON, DAEMON, KERN, LPR, MAIL, NEWS, USER, UUCP, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6 or LOCAL7. See Also: SystemLog

See also

Examples

SyslogLevel

Name

SyslogLevel -- Set the verbosity level of system logging

Description

SyslogLevel adjusts the verbosity of the messages recorded in the error logs. The following levels are available, in order of decreasing significance: Level Description emerg Emergencies - system is unusable. alert Action must be taken immediately. crit Critical Conditions. error Error conditions. warn Warning conditions. notice Normal but significant condition. info Informational. debug Debug-level messages When a particular level is specified, messages from all other levels of higher significance will be reported as well. E.g., when SyslogLevel info is specified, then messages with log levels of notice and warn will also be posted. Using a level of at least crit is recommended.

See also

Examples

SystemLog

Name

SystemLog -- Redirect syslogging to a file

Description

The SystemLog directive disables proftpd's use of the syslog mechanism and instead redirects all logging output to the specified filename. The filename argument should contain an absolute path, and should not be to a file in a nonexistent directory, in a world-writeable directory, or be a symbolic link (unless AllowLogSymlinks is set to on). Use of this directive overrides any facility set by the SyslogFacility directive. Additionally, the special keyword NONE can be used which disables all syslog style logging for the entire configuration.

Examples

TCPAccessFiles

Name

TCPAccessFiles -- Sets the access files to use

Description

TCPAccessFiles specifies two files, an allow and a deny file, each of which contain the IP addresses, networks or name-based masks to be allowed or denied connections to the server. The files have the same format as the standard tcpwrappers hosts.allow/deny files.

Both file names are required. Also, the paths to both files must be the full path, with two exceptions: if the path starts with ~/, the check of that path will be delayed until a user requests a connection, at which time the path will be resolved to that user's home directory; or if the path starts with ~user/, where user is some system user. In this latter case, mod_wrap will attempt to resolve and verify the given user's home directory on start-up.

The service name for which mod_wrap will look in the indicated access files is proftpd by default; this can be configured via the TCPServiceName directive. There is a built-in precedence to the TCPAccessFiles, TCPGroupAccessFiles, and TCPUserAccessFiles directives, if all are used. mod_wrap will look for applicable TCPUserAccessFiles for the connecting user first. If no applicable TCPUserAccessFiles is found, mod_wrap will search for TCPGroupAccessFiles which pertain to the connecting user. If not found, mod_wrap will then look for the server-wide TCPAccessFiles directive. This allows for access control to be set on a per-server basis, and allow for per-user or per-group access control to be handled without interfering with the server access rules.

Examples

# server-wide access files TCPAccessFiles /etc/ftpd.allow /etc/ftpd.deny # per-user access files, which are to be found in the user's home directory TCPAccessFiles ~/my.allow ~/my.deny

TCPAccessSyslogLevels

Name

TCPAccessSyslogLevels -- Sets the logging levels for mod_wrap

Description

ProFTPD can log when a connection is allowed, or denied, as the result of rules in the files specified in TCPAccessFiles, to the Unix syslog mechanism. A discussion on the syslog levels which can be used is given in the SyslogLevel directive.

The allow-level parameter sets the syslog level at which allowed connections are logged; the deny-level parameter sets the syslog level for denied connections.

See also

SyslogLevel

Examples

TCPAccessSyslogLevels debug warn

tcpBackLog

Name

tcpBackLog -- Control the tcp backlog in standalone mode

Description

The tcpBackLog directive controls the tcp "backlog queue" when listening for connections in standalone mode (see ServerType). It has no affect upon servers in inetd mode. When a tcp connection is established by the tcp/ip stack inside the kernel, there is a short period of time between the actual establishment of the connection and the acceptance of the connection by a user-space program. The duration of this latency period is widely variable, and can depend upon several factors (hardware, system load, etc). During this period tcp connections cannot be accepted, as the port that was previously "listening" has become filled with the new connection. Under heavy connection load this can result in occasional (or even frequent!) "connection refused" messages returned to the incoming client, even when there is a service available to handle requests. To eliminate this problem, most modern tcp/ip stacks implement a "backlog queue" which is simply a pre-allocation of resources necessary to handle backlog-size connections during the latency period. The larger the backlog queue, the more connections can be established in a very short time period. The trade-off, of course, is kernel memory and/or other kernel resources. Generally it is not necessary to use a tcpBackLog directive, unless you intend to service a large number of virtual hosts (see <VirtualHost>), or have a consistently heavy system load. If you begin to notice or hear of "connection refused" messages from remote clients, try setting a slightly higher value to this directive.

See also

Examples

TCPGroupAccessFiles

Name

TCPGroupAccessFiles -- Sets the access files to use

Description

TCPGroupAccessFiles allows for access control files, the same types of files required by TCPAccessFiles, to be applied to select groups. The given group-expression is a logical AND expression, which means that the connecting user must be a member of all the groups listed for this directive to apply. Group names may be negated with a ! prefix.

The rules for the filename paths are the same as for TCPAccessFiles settings.

Examples

# every member of group wheel must connect from restricted locations TCPGroupAccessFiles wheel /etc/ftpd-strict.allow /etc/ftpd-strict.deny # everyone else gets the standard access rules TCPGroupAccessFiles !wheel /etc/hosts.allow /etc/hosts.deny

tcpNoDelay

Name

tcpNoDelay -- Control the use of TCP_NODELAY

Description

The tcpNoDelay directive controls the use of the TCP_NODELAY socket option (which disables the Nagle algorithm). ProFTPd uses TCP_NODELAY by default, which usually is a benefit but this can occasionally lead to problems with some clients, so tcpNoDelay is provided as a way to disable this option. You will not normally need to use this directive but if you have clients reporting unusually slow connections, try setting this to off.

See also

Examples

tcpReceiveWindow

Name

tcpReceiveWindow -- Set the size of the tcp receive window

Description

The tcpReceiveWindow directive configures the size (in octets) of all data connections' tcp receive windows. It is only used when receiving a file from a client over the data connection. Typically, a given tcp/ip implementation will use a relatively small receive window size (the number of octets that can be received at the tcp layer before a "turnaround" acknowledgement is required). When transferring a large amount of data over fast digital transmission lines which have a relatively high latency, a small receive window can dramatically affect perceived throughput because of the necessity to completely stop the transfer occasionally in order to wait for the remote endpoint to receive the acknowledgement and continue transmission. For example, on a T1 line (assuming full 1.544Mbps endpoint-to-endpoint throughput) with 100 ms latency, a 4k receive buffer will very dramatically reduce the perceived throughput. The default value of 8192 octets (8k) should be reasonable in common network configurations. Additionally, proftpd allocates its internal buffers to match the receive/send window sizes; in order to maximize the reception/transmission performance (reducing the number of times data must be transfered from proftpd to the kernel tcp/ip stack). The tradeoff, of course, is memory; both kernel- and user-space. If running proftpd on a memory tight host (and on a low-bandwidth connection), it might be advisable to decrease both the tcpReceiveWindow and tcpSendWindow sizes.

See also

Examples

tcpSendWindow

Name

tcpSendWindow -- Set the size of the tcp send window

Description

The tcpSendWindow directive configures the size (in octets) of all data connections' tcp send windows. It is only used when sending a file from the server to a client on the data connection. For a detailed description of receive/send window sizes see tcpReceiveWindow.

See also

Examples

TCPServiceName

Name

TCPServiceName -- Configures the name proftpd will use with mod_wrap

Description

TCPServiceName is used to configure the name of the service under which mod_wrap will check the allow/deny files. By default, this is the name of the program started, i.e. "proftpd". However, some administrators may want to use a different, more generic service name, such as "ftpd"; use this directive for such needs.

See also

TCPUserAccessFiles

Name

TCPUserAccessFiles -- Sets the access files to use

Description

TCPUserAccessFiles allows for access control files, the same types of files required by TCPAccessFiles, to be applied to select users. The given user-expression is a logical AND expression. Listing multiple users in a user-expression does not make much sense; however, this type of AND evaluation allows for expressions such as "everyone except this user" with the use of the ! negation prefix.

The rules for the filename paths are the same as for TCPAccessFiles settings.

Examples

# user admin might be allowed to connect from anywhere TCPUserAccessFiles admin /etc/ftpd-anywhere.allow /etc/ftpd-anywhere.deny # while every other user has to connect from LAN addresses TCPUserAccessFiles !admin /etc/ftpd-lan.allow /etc/ftpd-lan.deny

TimeoutIdle

Name

TimeoutIdle -- Sets the idle connection timeout

Description

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 See Also: TimeoutLogin, TimeoutNoTransfer

See also

Examples

TimeoutLogin

Name

TimeoutLogin -- Sets the login timeout

Description

The TimeoutLogin directive configures the maximum number of seconds a client is allowed to spend authenticating. The login timer is not reset when a client transmits data, and is only removed once a client has transmitted an acceptable USER/PASS command combination. See Also: TimeoutIdle, TimeoutNoTransfer

See also

Examples

TimeoutNoTransfer

Name

TimeoutNoTransfer -- Sets the connection without transfer timeout

Description

The TimeoutNoTransfer directive configures the maximum number of seconds a client is allowed to spend connected, after authentication, without issuing a command which results in creating an active or passive data connection (i.e. sending/receiving a file, or receiving a directory listing). See Also: TimeoutIdle, TimeoutLogin

See also

Examples

TimeoutStalled

Name

TimeoutStalled -- Sets the timeout on stalled downloads

Description

The TimeoutStalled directive sets the maximum number of seconds a data connection between the proftpd server and an FTP client can exist but have no actual data transferred (i.e. "stalled"). If the seconds argument is set to 0, data transfers are allowed to stall indefinitely.

See also

Examples

TimesGMT

Name

TimesGMT -- Toggle time display between GMT and local

Description

Compatibility: 1.2.0pre9 and later The TimesGMT option causes the server to report all ls and MDTM times in GMT and not local time.

See also

Examples

TransferLog

Name

TransferLog -- Specify the path to the transfer log

Description

The TransferLog directive configures the full path to the "wu-ftpd style" file transfer log. Separate log files can be created for each Anonymous and/or VirtualHost. Additionally, the special keyword NONE can be used, which disables wu-ftpd style transfer logging for the context in which the directive is used (only applicable to version 1.1.7 and later). See Also: ExtendedLog, LogFormat

See also

Examples

Umask

Name

Umask -- Set the default Umask

Description

Umask sets the mask applied to newly created file and directory permissions within a given context. By default, the Umask in the server configuration, <VirtualHost> or <Anonymous> block is used, unless overridden by a "per-directory" Umask setting. Any arguments supplied must be an octal number, in the format 0xxx. An optional second argument can specify a Umask to be used when creating directories. If a second argument isn't specified, directories are created using the default Umask in the first argument. For more information on umasks, consult your operating system documentation/man pages.

Proftpd will not create files that have the execution bit turned on, this is a security driven design decision. The permissions of the uploaded file can be changed by issuing a SITE CHMOD command can be used to change the mode of the uploaded file. Syntax of the command is: SITE CHMOD <mode> <file>.

See also

Examples

UseFtpUsers

Name

UseFtpUsers -- Block based on /etc/ftpusers

Description

Legacy FTP servers generally check a special authorization file (typically /etc/ftpusers) when a client attempts to authenticate. If the user's name is found in this file, FTP access is denied. For compatibility sake, proftpd defaults to checking this file during authentication. This behavior can be suppressed using the UseFtpUsers configuration directive.

See also

Examples

UseGlobbing

Name

UseGlobbing -- Toggles use of glob() functionality

Description

The UseGlobbing directive controls use of glob() functionality, which is needed for supporting wildcard characters such as *.

See also

User

Name

User -- Set the user the daemon will run as

Description

The User directive configures which user the proftpd daemon will normally run as. By default, proftpd runs as root which is considered undesirable in all but the most trustful network configurations. The User directive used in conjunction with the Group directive instructs the daemon to switch to the specified user and group as quickly as possible after startup. On some unix variants, the daemon will occasionally switch back to root in order to accomplish a task which requires super-user access. Once the task is completed, root privileges are relinquished and the server continues to run as the specified user and group. When applied to a <VirtualServer> block, proftpd will run as the specified user/group on connections destined for the virtual server's address or port. If either User or Group is applied to an <Anonymous> block, proftpd will establish an anonymous login when a user attempts to login with the specified userid, as well as permanently switching to the corresponding uid/gid (matching the User/Group parameters found in the anonymous block) after login. Note: When an authorized unix user is authenticated and logs in, all former privileges are released, the daemon switches permanently to the logged in user's uid/gid, and is never again capable of switching back to root or any other user/group.

See also

Examples

UserAlias

Name

UserAlias -- Alias a username to a system user

Description

ProFTPD requires a real username/uid when authenticating users as provided by PAM, AuthUserFile or another authentication mechanism. There are however times when additional aliases are required but it is undesirable to provide additional login accounts.

UserAlias provides a mechanism to do this, a typical and common example is within Anonymous configuration blocks. It is normal for the server to use 'ftp' as the primary authentication user, however it is common practice for users to login using "anonymous". This is achieved by adding the following to the config file.

See also

Examples

UserAlias anonymous ftp

UserDirRoot

Name

UserDirRoot -- Set the chroot directory to a subdirectory of the anonymous server

Description

When set to true, the chroot base directory becomes a subdirectory of the anonymous ftp directory, based on the username of the current user. For example, assuming user "foo" is aliased to "ftp", logging in as "foo" causes proftpd to run as real user ftp, but to chroot into ~ftp/foo instead of just ~ftp.

See also

Examples

UseReverseDNS

Name

UseReverseDNS -- Toggle rDNS lookups

Description

Normally, incoming active mode data connections and outgoing passive mode data connections have a reverse DNS lookup performed on the remote host's IP address. In a chroot environment (such as <Anonymous> or DefaultRoot), the /etc/hosts file cannot be checked and the only possible resolution is via DNS. If for some reason, DNS is not available or improperly configured this can result in proftpd blocking ("stalling") until the libc resolver code times out. Disabling this directive prevents proftpd from attempting to reverse-lookup data connection IP addresses.

See also

Examples

UserOwner

Name

UserOwner -- Set the user ownership of new files / directories

Description

The UserOwner directive configures which user all newly created directories and files will be owned by, within the context that UserOwner is applied to. The user ID of username cannot be 0 (root). Where it is used, the GroupOwner directive is not restricted to groups that the current user is a member of.

See also

Examples

UserPassword

Name

UserPassword -- Creates a hardcoded username/password pair

Description

The UserPassword directive creates a password for a particular user which overrides the user's normal password in /etc/passwd (or /etc/shadow). The override is only effective inside the context to which UserPassword is applied. The hashed-password argument is a cleartext string which has been passed through the standard unix crypt() function. Do NOT use a cleartext password. This can be useful when combined with UserAlias to provide multiple logins to an Anonymous FTP site. See Also: GroupPassword

See also

Examples

UserRatio

Name

UserRatio -- Ratio directive

Description

The UserRatio directive .... Example: UserRatio

See also

Examples

VirtualHost

Name

VirtualHost -- Define a virtual ftp server

Description

The VirtualHost configuration block is used to create an independent set of configuration directives that apply to a particular hostname or IP address. It is often used in conjunction with system level IP aliasing or dummy network interfaces in order to establish one or more "virtual" servers which all run on the same physical machine. The block is terminated with a </VirtualHost> directive. By utilizing the Port directive inside a VirtualHost block, it is possible to create a virtual server which uses the same address as the master server, but listens on a separate tcp port (incompatible with ServerType inetd). When proftpd starts, virtual server connections are handled in one of two ways, depending on the ServerType setting: inetd The daemon examines the destination address and port of the incoming connection handed off from inetd. If the connection matches one of the configured virtual hosts, the connection is serviced based on the appropriate configuration. If no virtual host matches, and the main server does not match, the client is informed that no server is available to service their requests and disconnected. standalone After parsing the configuration file, the daemon begins listening for connections on all configured ports, spawning child processes as necessary to handle connections for either the main server or any virtual servers. Because of the method that the daemon uses to listen for connections when in standalone mode, it is possible to support an exceedingly large number of virtual servers, potentially exceeding the number of per-process file descriptors. This is due to the fact that a single file descriptor is used to listen to each configured port, regardless of the number of addresses being monitored. Note that it may be necessary to increase the tcpBackLog value on heavily loaded servers in order to avoid kernel rejected client connections ("Connection refused").

See also

Examples

WtmpLog

Name

WtmpLog -- Toggle logging to wtmp

Description

The WtmpLog directive controls proftpd's logging of ftp connections to the host system's wtmp file (used by such commands as `last'). By default, all connections are logged via wtmp. Please report any corrections or additions via http://bugs.proftpd.net/

See also

Examples

II. Configuration by Module

Table of Contents
mod_auth -- Authentication module
mod_code -- FIX ME FIX ME
mod_core -- Core module
mod_ldap -- LDAP authentication support
mod_log -- Logging support
mod_ls -- file listing functionality
mod_pam -- Pluggable authentication modules support
mod_quota -- Module to implement per-user quotas
mod_ratio -- FIX ME FIX ME
mod_readme -- "README" file support
mod_sample -- Example module
mod_site -- FIX ME FIX ME
mod_sql -- SQL support module
mod_unixpw -- UNIX style authentication methods
mod_wrap -- Interface to libwrap
mod_xfer -- FIX ME FIX ME

mod_auth

Name

mod_auth -- Authentication module

Description

FIXME FIXME FIXME

mod_code

Name

mod_code -- FIX ME FIX ME

Description

FIXME FIXME FIXME

mod_core

Name

mod_core -- Core module

Description

This module provides all the core functionality ProFTPD needs to function, this module must be compiled in.

mod_ldap

Name

mod_ldap -- LDAP authentication support

Description

mod_ldap provides LDAP authentication support for ProFTPD. It supports many features useful in "toaster" environments such as default UID/GID and autocreation/autogeneration of home directories.

mod_log

Name

mod_log -- Logging support

Description

Logging support, including enhanced formatting options.

mod_ls

Name

mod_ls -- file listing functionality

Description

FIXME FIXME FIXME

mod_pam

Name

mod_pam -- Pluggable authentication modules support

Description

FIXME FIXME FIXME

mod_quota

Name

mod_quota -- Module to implement per-user quotas

Description

FIXME FIXME FIXME

Notes

mod_quota forces a quota recalculation when the .quota file is missing. It is therefore possible to tie normal shell logins into deleting the file to force recalcualtions.

mod_ratio

Name

mod_ratio -- FIX ME FIX ME

Description

FIXME FIXME FIXME

mod_readme

Name

mod_readme -- "README" file support

Description

FIXME FIXME FIXME

See also

DisplayReadme

mod_sample

Name

mod_sample -- Example module

Description

This module only provides an example set of code as a template for a budding module programmer.

mod_site

Name

mod_site -- FIX ME FIX ME

Description

FIXME FIXME FIXME

See also

AllowChmod

mod_sql

Name

mod_sql -- SQL support module

Description

This module provides the necessary support for SQL based authentication, logging and other features as required. It replaces the SQL modules which were shipped with 1.2.0rc2 and earlier.

mod_unixpw

Name

mod_unixpw -- UNIX style authentication methods

Description

This module supports the password file (/etc/passwd) style of authentication methods.

mod_wrap

Name

mod_wrap -- Interface to libwrap

Description

It enables the daemon to use the common tcpwrappers access control library while in standalone mode, and in a very configurable manner. It is not compiled by default.

If not installed on your system, the TCP wrappers library, required by this module, can be found here, on Wietse Venema's site. Once installed, it highly recommended that the hosts_access(3) and hosts_access(5) man pages be read and understood.

Many programs will automatically add entries in the common allow/deny files, and use of this module will allow a ProFTPD daemon running in standalone mode to adapt as these entries are added. The portsentry program does this, for example: when illegal access is attempted, it will add hosts to the /etc/hosts.deny file.

mod_xfer

Name

mod_xfer -- FIX ME FIX ME

Description

FIXME FIXME FIXME

server config

Name

server config -- server config

Description

FIXME FIXME FIXME

See also

Global

Name

Global -- Global

Description

FIXME FIXME FIXME

See also

VirtualHost

Name

VirtualHost -- VirtualHost

Description

FIXME FIXME FIXME

See also

Anonymous

Name

Anonymous -- Anonymous

Description

FIXME FIXME FIXME

See also

AccessDenyMsg AccessGrantMsg AllowAll AllowChmod AllowFilter AllowForeignAddress AllowOverwrite AllowRetrieveRestart AllowStoreRestart AnonRatio AnonRequirePassword AuthAliasOnly AuthUsingAlias ByteRatioErrMsg CDPath CwdRatioMsg DefaultChdir DefaultQuota DeleteAbortedStores DenyAll DenyFilter Directory DirFakeGroup DirFakeMode DirFakeUser DisplayFirstChdir DisplayGoAway DisplayLogin DisplayQuit DisplayReadme ExtendedLog FileRatioErrMsg FooBarDirective Group GroupOwner GroupPassword GroupRatio HiddenStor HideGroup HideNoAccess HideUser HostRatio Include LDAPHomedirOnDemandPrefixNoUsername LeechRatioMsg Limit LoginPasswordPrompt LsDefaultOptions MaxClients MaxClientsPerHost MaxHostsPerUser PathAllowFilter PathDenyFilter QuotaBlockName QuotaBlockSize QuotaCalc QuotaExempt Quotas QuotaType RateReadBPS RateReadFreeBytes RateReadHardBPS RateWriteBPS RateWriteFreeBytes RateWriteHardBPS RatioFile Ratios RatioTempFile RequireValidShell RootLogin SaveRatios ShowDotFiles ShowSymlinks SQLAuthenticate SQLAuthoritative SQLDefaultHomedir SQLGidField SQLGroupGIDField SQLGroupInfo SQLGroupWhereClause SQLHomedir SQLHomedirField SQLLog SQLLogDirs SQLLogHits SQLLogHosts SQLLoginCountField SQLLogStats SQLMinUserGID SQLMinUserUID SQLNamedQuery SQLPasswordField SQLProcessGrEnt SQLProcessPwEnt SQLShowInfo SQLUidField SQLUserInfo SQLUsernameField SQLUserTable SQLUserWhereClause SyslogLevel TCPAccessFiles TCPAccessSyslogLevels TimesGMT TransferLog Umask UseFtpUsers UseGlobbing User UserAlias UserDirRoot UserOwner UserPassword UserRatio WtmpLog

Limit

Name

Limit -- Limit

Description

FIXME FIXME FIXME

.ftpaccess

Name

.ftpaccess -- .ftpaccess

Description

FIXME FIXME FIXME


Appendix A. Resources

This appendix is under development... I've borrowed the formatting from elsewhere and am busy hacking it around to what i want

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?

The quantity of information about SGML and XML 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 SGML and XML in general. Although not all of these resources are focused specifically on DocBook, they still provide helpful information for DocBook users.


Resources for Resources

Here's where to find pointers to the subjects you want to find.

The Most Recent Version of This Book

The most recent online version of this book can be found at http://docbook.org/.

The Most Recent Version of Proftpd

can be found... wibble wobble.

Another mirror

desc...wibble.

comp.text.sgml and comp.text.xml

USENET newsgroups devoted to SGML and XML issues.

FAQs

For pointers to several SGML FAQs, see http://www.oasis-open.org/cover/general.html#faq. The XML FAQ is available at http://www.ucc.ie/xml.

XML.com

XML.com, run jointly by Songline Studios and Seybold, is a site devoted to making XML accessible.


Specifications

Here are pointers to the specifications.

The XML Specification

The W3C technical recommendation that defines XML 1.0.

Namespaces in XML

The W3C technical recommendation that defines XML namespaces.

Mathematical Markup Language (MathML) 1.0 Specification

The W3C technical recommendation that defines MathML, an XML representation of mathematical equations.

The Unicode Standard, Version 2.0

The Unicode standard.

Unicode Technical Report #8

Version 2.1 of the Unicode standard.


Books and Printed Resources

There are also a number of books worth checking out:

Bibliography

Developing SGML DTDs: From Text to Model to Markup, Eve Maler and Jeanne El Andaloussi, 0-13-309881-8, Prentice-Hall PTR, Upper Saddle River, 1996.

Practical SGML, Erik van Herwijnen, 2, 0-7923-9434-8, Kluwer Academic Press, 1994.

The SGML Handbook, Charles Goldfarb and Yuri Rubinksy, 0-7923-9434-8, 1991, Oxford University Press.

SGML: an author's guide to the Standard Generalized Markup Language, Martin Bryan, 0-201-17535-5, 1988, Addison-Wesley Publishing Company.

$GML: The Billion Dollar Secret, Chet Ensign, 0-13-226705-5, 1998, Prentice Hall.

Creating Documents with XML, Chris Maden, 1-56592-518-1, 1999, O'Reilly & Associates.

XML: A Primer, Simon St. Laurent, 1-5582-8592-X, 1998, MIS:Press/IDG Books Worldwide.

Understanding SGML and XML Tools, Peter Flynn, 0-7923-8169-6, 1998, Kluwer Academic Publishers.

The LaTeX Web Companion: Integrating TeX, HTML, and XML, Michel Goosens and Sebastian Rahtz, 0-201-43311-7, 1999, Addison-Wesley Publishing Company.


Appendix B. Cookbook examples

Example B-1. Basic Configuration

# 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.
<Directory /*>
  AllowOverwrite		on
</Directory>

# A basic anonymous configuration, no upload directories.
<Anonymous ~ftp>
  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
  <Limit WRITE>
    DenyAll
  </Limit>

</Anonymous>

Example B-2. VirtualHost Config

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

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

# 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
<VirtualHost ftp.virtual.com>

  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.
  <Limit LOGIN>
    DenyAll
  </Limit>

  # Next, create a "guest" account (which could be used
  # by a customer to allow private access to their web site, etc)
  <Anonymous ~cust1>
    User			cust1
    Group			cust1
    AnonRequirePassword		on

    <Limit LOGIN>
      AllowAll
    </Limit>

    HideUser			root
    HideGroup			root

    # A private directory that we don't want the user getting in to.
    <Directory logs>
      <Limit READ WRITE DIRS>
        DenyAll
      </Limit>
    </Directory>

  </Anonymous>

</VirtualHost>

# Another virtual server, this one running on our primary address,
# but on port 4000.  The only access is to a single anonymous login.
<VirtualHost our.ip.address>

  ServerName			"Our private FTP server"
  Port				4000
  Umask				027

  <Limit LOGIN>
    DenyAll
  </Limit>

  <Anonymous /usr/local/ftp/virtual/a_customer>

    User			ftp
    Group			ftp
    UserAlias			anonymous ftp

    <Limit LOGIN>
      AllowAll
    </Limit>

    <Limit WRITE>
      DenyAll
    </Limit>

    <Directory incoming>
      <Limit WRITE>
        AllowAll
      </Limit>
    </Directory>

  </Anonymous>

</VirtualHost>

Example B-3. Complex Configuration

#
# Virtual Hosting Server Configuration
# by M.Lowes <markl@ftech.net>
# 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?
#
ScoreboardPath			/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
#
<Global>
	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
</Global>

#
# Deny writing to the base server...
#
<Limit WRITE>
	DenyAll
</Limit>


# --------------------------------------------
# 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
#
<VirtualHost www.ftech.net>
	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
	# --------------------------------------------
	<Directory ~/public_html>
	#
	# Block them from doing anything other than reading...
	#
		<Limit STOR RNFR DELE>
			DenyGroup fpage
		</Limit>	
	</Directory>
	#
	# ditto for ftp_root if it's there...
	#
	<Directory ~/ftp_root>
		<Limit STOR RNFR DELE>
			DenyALL
		</Limit>	
	</Directory>
	#
	# Limit by IP...
	#
	<Directory /web/zsl>
		<Limit ALL>
			Order Allow,Deny
			Allow 195.200.31.220
			Allow 212.32.17.0/26
			Deny ALL
		</Limit>
	</Directory>	

</VirtualHost>

# --------------------------------------------
#
# Legacy server, left in because some people
# haven't realised it's gone yet.  Shove 'em into 
# a dummy $home
#
<VirtualHost web-1.ftech.net>
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
</VirtualHost>

# --------------------------------------------
#
# ftp.ftech.net
#
<VirtualHost ftp.ftech.net>
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.
<Anonymous /ftp/ftp.ftech.net>
	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.

	<Directory pub/incoming>
		<Limit STOR>
			AllowAll
		</Limit>
		<Limit WRITE DIRS READ>
			DenyAll
		</Limit>
		<Limit CWD XCWD CDUP>
			AllowAll
		</Limit>
	</Directory>

	<Directory home>
		<Limit ALL>
			DenyAll
		</Limit>
	</Directory>

   #
   # Limit access to the mirrors to LINX 
   # only
   #
   <Directory mirrors>
      <Limit RETR>
         Order Allow,Deny
         Allow .uk, .ftech.net
         Allow .vom.tm
         Deny ALL
      </Limit>
   </Directory>

  	# Limit WRITE everywhere in the anonymous chroot
  	<Limit WRITE>
    		DenyAll
  	</Limit>


</Anonymous>

</VirtualHost>

# ----------------------------------------------------
# Virtual ftp with anon access, but no incoming
#
<VirtualHost ftp.foo1.com>
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

<Anonymous /ftp/ftp.foo1.com>
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20
	<Limit WRITE>
		DenyAll
	</Limit>
</Anonymous>
</VirtualHost>


# ----------------------------------------------------
# ftp.foo2.com 
# Anon, no incoming, some private access areas 
#
<VirtualHost ftp.foo2.com>
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

<Anonymous /ftp/ftp.foo2.com>
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20

	<Directory download>
		<Limit ALL>
			DenyAll
		</Limit>
	</Directory>
	<Limit WRITE>
		DenyAll
	</Limit>
</Anonymous>

	<Directory /ftp/ftp.foo2.com/pub>
		<Limit WRITE>
			AllowUser mcres
			DenyAll
		</Limit>
	</Directory>

	<Directory /ftp/ftp.foo2.com/download>
		<Limit ALL>
			AllowUser mcres
			AllowUser customer
			DenyAll
		</Limit>
	</Directory>
</VirtualHost>


# ----------------------------------------------------
# ftp.foo3.com
# 
#
<VirtualHost ftp.foo3.com>
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

<Anonymous /web/farrukh2/ftp_root>
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20

	<Directory pub/incoming/*>
		<Limit STOR>
			AllowAll
		</Limit>
		<Limit WRITE DIRS READ>
			DenyAll
		</Limit>
		<Limit CWD XCWD CDUP>
			AllowAll
		</Limit>
	</Directory>


	<Directory pub/Incoming/*>
		<Limit STOR>
			AllowAll
		</Limit>
		<Limit WRITE DIRS READ>
			DenyAll
		</Limit>
		<Limit CWD XCWD CDUP>
			AllowAll
		</Limit>
	</Directory>
	#
	# block access to the secure areas by anon...
	#
	<Directory fpub>
		<Limit ALL>
			DenyAll
		</Limit>
	</Directory>

	<Directory fgroup>
		<Limit ALL>
			DenyAll
		</Limit>
	</Directory>
	<Limit WRITE>
		DenyAll
	</Limit>
</Anonymous>

	#
	# define user based access
	#
	<Directory /web/farrukh2/ftp_root/fpub>
		<Limit ALL>
			AllowUser farrukh
			AllowUser fguest
			DenyAll
		</Limit>
	</Directory>

	<Directory /web/farrukh2/ftp_root/fgroup>
		<Limit ALL>
			AllowUser farrukh
			AllowUser fgroup
			DenyAll
		</Limit>
	</Directory>
</VirtualHost>


# ----------------------------------------------------
# ftp.foo4.com 
# anon, with incoming upload 
#
<VirtualHost ftp.foo4.com>
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

<Anonymous /ftp/ftp.foo4.com>
        User                    ftp
        Group                   ftp
        UserAlias               anonymous ftp
        RequireValidShell       no
        MaxClients              20

	<Directory pub/incoming/*>
		<Limit STOR>
			AllowAll
		</Limit>
		<Limit WRITE DIRS READ>
			DenyAll
		</Limit>
		<Limit CWD XCWD CDUP>
			AllowAll
		</Limit>
	</Directory>


	<Directory pub/Incoming/*>
		<Limit STOR>
			AllowAll
		</Limit>
		<Limit WRITE DIRS READ>
			DenyAll
		</Limit>
		<Limit CWD XCWD CDUP>
			AllowAll
		</Limit>
	</Directory>

	<Limit WRITE>
		DenyAll
	</Limit>
</Anonymous>
</VirtualHost>

# ----------------------------------------------------
# The end.... 
# ----------------------------------------------------


Index

...


Colophon

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.