Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
By MasterC at 2003-07-11 03:55
Part 1: What ProFTPD is, and what it isn't.
Proftpd is a linux FTP server. It has the same basic functionality as ANY other FTP server out there. It recieves connections into the server in the form of a
file request, and then tranfers that via File Transport Protocol (FTP) back to the requester.
Proftpd is well documented should you need to further enhance your basic configuration file. This means that if you go to Proftpd's Home Page that you will find more information to specialize or customize your configuration to your needs.
Proftpd is NOT an http server. You can access FTP servers via a browser, but this does not mean that the server you are accessing is an HTTP server. The main difference to note is that FTP is specifically for File Transfer, where HTTP (HyperText Transport Protocol) is for broadcasting a wide array of information in a coded (HTML or PHP usually) format.
Part 2: Obtaining ProFTPD.
You can obtain ProFTPD straight from the applications home page: http://proftpd.org Here you can grab either the latest stable version (1.2.8 as of this writing) or you can grab the latest "release candidate" meaning it's not officially stable, but may have more features, and possibly less bugs than the current "stable" release. As always, you can grab the CVS version of this software in their CVS repository: http://proftpd.org/cvs.html CVS is the truly "latest and greatest" but will also not work on many systems. CVS is usually not the way to go unless you are an active developer with the project, or if you must have a feature only included in the CVS version (until it makes the stable release sometime down the road).
Other options for obtaining include FTP mirrors for your distribution (distro) where packaged versions may be available. Official mirrors listed on Proftpd's homepage are also a great place to grab from. If you use Gentoo, Proftpd in it's latest stable release is always available through portage. Debian has it's packages available through apt-get as well. Proftpd is a very common, strong FTP, so it's likely your distro has made packages for it. Ideally though, and in this document, we will use the source. This should be the case whenever feasible because of the amazing flexibility in compiling your own applications. For those just starting out, and/or needing to simply "get things working" RPM's and .deb are an excellent way to do this.
Where should I put this file? Is there a "standard" place on linux where I should place the files I download?
Yes, with a sometimes...
It's quite a hot topic, and a very arguable one at that. You are encouraged to place files wherever you feel the most comfortable, and where it is likely you'll remember where they are at. It's also advisable to use a place where all users will be able to write to, so system wide user directories, such as /home and /usr are where I'll suggest to keep them. On several distros I've used (such as Mandrake) they have even created a location in /usr/src for source files, and /usr/src/RPM for RPM files. This may be what you will want to look into for your file(s) storage, or feel free to arbitrarily choose your own location. Should you choose to use /usr/src you will need to give the users write privileges, as well as own the directory to the group users (although you may find other options work great as well). To do this, we will need to have root privileges, so open up your favorite terminal (I'll be using xterm and bash) and type:
This will send the command to switch users, and specifically switch to root. We will then be prompted for root's password:
And type it in, as always cASe SenSItiVe in linux.
Once in, we will then proceed with the setting up of permissions for users on /usr/src
First up, we'll need to ensure the directory exists:
ls -l /usr/src
It is VERY likely this will be there. Most systems kernel compiles go here, and many applications know this and use it when creating drivers. In the rare instance /usr/src does not exist, we will create it:
We now want to make sure group rights are writable:
chmod 770 /usr/src
Which will allow owner (currently root) and group (currently root) full read/write and execute permissions. This is necessary on this directory because:
root should [almost] always have full rights on files;
Your group will need to be able to read the directory, write to it, and list file contents (the result of adding execute to a directory).
We will now need to change the group ownership to that of the users group on the system, on most distros this is the 'users' group ;-) Ingenious. So we will do that with chown:
chown root.users /usr/src
(*Note: You can use <i>Either</i> a dot ( . ) <i>OR</i> a colon ( : ) when specifying user.group on a chown)
Now your users and root should be able to place files in that directory without recieving warnings that you don't have the rights to. Log out of root and proceed onto the next section as an unprivileged user (any user on the system other than root).
Part 3: Unpacking and configuring ProFTPD
For the rest of this helper, I will assume you have:
Obtained the latest source (tar.bz2 1.2.8) from the official HomePage;
Saved it (as an unprivileged user) to /usr/src
So when I refer to /usr/src/proftpd-1.2.8 you should use whatever directory you have chosen.
Let's get into the directory now containing the bzipped tarball (tar.bz2):
And using tar we will both extract it from the compressed tarball, and unpack the tarball into it's directory:
tar xvjf proftpd-1.2.8.tar.bz2
What this will do is unpack tar into a directory called proftpd-1.2.8 which we will then need to enter:
Now you can view all the files in the directory using ls:
Ensure there are files, specifically you can check the README and INSTALL files that are included with quite a few project tarballs, to view them use a reading application such as less:
This will allow you to scroll freely through those 2 text files which describe functions of the software, and sometimes how to install them (usually generically).
Once we've verified these 2 files exist, we will move onto configuring the Makefile. The Makefile is a file that is created from the configure process (configure is actually simply a script that will verify applications locations, and can be very in depth or very simple depending on the needs of the application it's configuring) that will eventually build the the necessary executables that proftpd will need to run. First you should always check a configure script's help file:
./configure --help | less
What we are doing there is calling the configure script from it's current directory (. means use this directory I am in and ./ means run this executable file) and piping it's output to something we can easily use to scroll up and down the screen, less. Pipes are VERY useful; I won't go into much detail with them as they deservant of their own small helper, but I will say, learn about them, use them, love them. Nuf' said.
Reading over the options always helps you to see an applications capabilities and to see it's requirements if they are not discussed in the README or INSTALL files. If you wish to use a feature, these are usually indicated with a --enable-feature attached to the configure script as I will show below. The same goes for disabling a feature. Should you decide something isn't necessary for your purposes, and you would like to ensure it's not included as a function in your final product, you can usually specify --disable-feature to do so. The configuration help (./configure --help) should have more information on that. After you are finished viewing all your options with the configure script, we will then execute it with those we wish to use:
It can be as complex as you'd like, or as simple as:
Which often works great on standard system setups. But should you wish more from your application, or just more control over exactly what is and isn't used, it's available. For information on each option, you should search the documentation from the projects website, and/or http://google.com/linux for answers. In my example I've chosen to enable 2 security featues for checking for username/password authentications. Security is always something to consider when setting up anything on your system, especially a server.
Part 4: The Makefile and the make options
Once the configure script has completed successfully (if there are errors, these are usually due to not having required dependencies, satisfy them, and then re-run the script) you can then run:
which will go through the Makefile that is created from configure's output. If you want to change things that configure found, such as the install_user (which can also
be specified prior to ./configure along with install_group to setup default ownership and permissions) variable, you can edit it then. It's not always a great idea to tweak this file, and I suggest not to. Simply run the 'make' and sit back and watch your application happily compile. Once finished without errors, you now have a working proftpd executable. You can run it from the current directory for testing if you'd like. If you didn't change the install_user option above, then this will need to be done as root (as shown above use the 'su -' option to change to root again) and then:
What these options will do is run proftpd (/usr/src/proftpd-1.2.8/proftpd) by calling it with it's full path since likely it's not in the system PATH (and rightly shoudn't be yet); and it will also call a specific conf file (configuration file) by using the -c option. If you don't receive an error after starting it, try to ftp to yourself:
Login as your default user, use your password when requested, and you should be in. Standard console commands work, try 1 just to make sure you are in:
And you should see a list of files.
We will exit the ftp now:
Since everything is working out, we can safely choose to install this now, so while we are still root:
You now have propftd installed, and you can smile proudly! :-)
Having an application installed is only half the battle, especially when talking about a server. There is more to it than simple install and run (usually). In the next section(s) we'll talk about the ProFTPD configuration file.
Part 5: The Basic configuration file (proftpd.conf)
Several different style 'sample' configurations can be found inside the source directory of proftpd-1.2.8/sample-configurations At this point I start to assume you know a little bit more about your wants/needs and desires for your FTP server. If all you want is "for it to work" you can probably just use the basic.conf as your configuration file. To do this, you only need to copy it to your configuration files directory (/etc usually). You will need to be root to do this, so let's get back to root with 'su -' :
And now, again as root, you'll need to start it. You have several ways of doing this, but for ease of this document, we will start it straight from the command line, no
t as a daemon service (such as inetd). So open up your terminal and 'su -' to root and:
/usr/sbin/proftpd -c /etc/proftpd.conf
And make sure it's running by:
Once you've verified it's working, you are done! Well, for basic FTP you are done, and you should now have a working FTP server on your linux box!
Test it from outside connections, ensure you make IPTables rules that allow port 21 to be open (this is the standard port that FTP runs on) and enjoy your new server. This does allow anonymous access, but to actually allow this type of access more must be done.
Part 6: Basic Anonymous Access
First, you will need to open up, in your favorite text editor, /etc/ftpusers If this file does not exist, you will need to create one. Simple syntax, so do not worry about this part, just add the users that you don't want people to be able to login as, this should include root at the very least, an example of the ftpusers file could be:
# ftpusers This file describes the names of the users that may
# _*NOT*_ log into the system via the FTP server.
# This usually includes "root", "uucp", "news" and the
# like, because those users have too much power to be
# allowed to do "just" FTP...
# Version: @(#)/etc/ftpusers 3.00 02/25/2001 volkerdi
# Original Author: Fred N. van Kempen, <email@example.com>
# The entire line gets matched, so no comments or extra characters on
# lines containing a username.
# To enable anonymous FTP, remove the "ftp" user:
# End of ftpusers.
This is taken from Slackware 8.1 should anyone wonder :-) As noted in the comments in that file, be sure to not have "ftp" listed if you want to allow anonymous. If you do not want anonymous however, simply add that user into the file just below "news". We will assume you do want anonymous and move on with setting that up.
Anonymous FTP users will default to using the directory /home/ftp as their home directory. This is the action most people will want, so we will leave that alone. We will need to create the user, and that will need to be done as root, be very careful when adding users, you do not want to use existing uid's otherwise your new "user" will be masquerading as an already existing one. On we go with creating the ftp user. As root ( su - ) type:
What this will do is:
Create a user named ftp (the last argument) with a uid of 5555 (usually safe to assume that's not used yet, you can choose another uid if you are sure it's not already used, to check, you can open /etc/passwd up with your favorite text reader ( less ) and view already used uid's), a default group of ftp, a home directory of /home/ftp and a shell as rbash. No that's not a typo, rbash is the chosen shell, it's restricted bash for those users who need limited or no shell. If you don't have rbash on your system, it's created as easily as this (as root):
ln -s /bin/bash /bin/rbash
And that's it. Now you've got a restricted bash shell on your machine, you should feel even cooler. We will now need to create the group ftp so that your ftp user actually belongs to something. To do that, we will use groupadd:
groupadd -g 5555 ftp
Last thing we need to do is create the users home directory and own it to them. In this case it's the ftp, but that makes nothing different from any other user, so again, as root type:
Now everything should be ready to go, and your ftp user should be happy as can be. Basic anonymous should now be working, complete and good to go.
Part 7: Adding to your Basic proftpd.conf file
Here we will discuss more in depth options in your conf file, specifically whether "to chroot, or not chroot", a bit on <Directory> directives, and other various parts of the file. So let's dig in!!
Here is the basic.conf file (in the sample-configurations directory) which we'll use as our example:
# 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"
# Port 21 is the standard FTP port.
# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
# 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).
# Set the user and group under which the server will run.
# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
# Normally, we want files to be overwriteable.
# A basic anonymous configuration, no upload directories. If you do not
# want anonymous users, simply delete this entire <Anonymous> section.
# We want clients to be able to login with "anonymous" as well as "ftp"
UserAlias anonymous ftp
# Limit the maximum number of anonymous logins
# We want 'welcome.msg' displayed at login, and '.message' displayed
# in each newly chdired directory.
# Limit WRITE everywhere in the anonymous chroot
Most of these can be referenced here: http://www.proftpd.org/docs/directives/configuration_full.html
I'll go into what I've found to be the most common questions: DefaultRoot (not shown above) directive is used to "chroot" a user to a specific directory. This is commonly ~ which is also known as (AKA) the user's home directory. For example, if you have user "donald" on your system, it is highly likely their home directory is: /home/donald Therefor, if you have the DefaultRoot directive in your conf file, and you follow it with~: DefaultRoot ~
Then when they FTP into your server, they'll be automatically placed into their home directory and will not be able to go above it (folders inside their home directory will be accessible, simply not other folders in /home or lower). This is known as "chrooting" the user. It makes their root directory ( / ) the directory specified. If you wanted a common DefaultRoot for everyone who FTP's into your server, you would specify that directory. Replacing ~ above with the example you want them in. For example, if you wanted to only allow FTP into /var/ftp you would have: DefaultRoot /var/ftp
**Remember, this directory must exist, otherwise there will be no one able to get into your system. Furthermore, you should also realize no files exist outside this directory. This will essentially be the root directory ( / ). You cannot soft-symlink here since the file will basically be, not there ( /home/user is not inside /var/ftp ).
I'll quickly touch on Logging. I strongly suggest you specify a location to log your FTP information to, I personally like the /var/log/proftpd.log and /var/log/xferlog as my 2 logfiles, and to have them, the only thing you have to add to your proftpd.conf file is: SystemLog /var/log/proftpd.log
(*Note, after any changes to your /etc/proftpd.conf file, be sure to restart your process. That can be done (if you are using inetd - see below for discussion on this)
you: ps aux | grep inetd
kill -HUP 1234
Where 1234 is the PID you get from 'ps aux | grep intetd'
For standalone, simply substitute 'grep inetd' with 'grep ftp'
We'll move onto <Directory> Directives.
Most often it seems people are unable to either create or delete files. This can usually be fixed within the <Directory> directives. Here's an example:
If you want to be able to write and delete from a specific directory (in this example we assume you have a DefaultRoot of /var/ftp and a subdirectory in there called /pub):
The last part of this section, we'll discuss using inetd vs standalone.
Inetd is known as the SuperServer daemon of the system. It can take control of all server requests and further request the servers as required for each request. What this means is you don't have to have several servers running constantly when they are not in use. Instead INETD will run, waiting to discover new requests for your server (in this case FTP) and will call your /usr/sbin/proftpd to use it. This is an excellent way to reduce the load on your system, especially if you are running 2 or more servers that will wait until a connection is made to begin working. It's also a great idea to use inetd because the FTP user is serviced immediately. Whereas if run in standalone mode, proftpd will be run and waiting for connections, and then when it recieves one, will then spawn child processes and this child process will serve all connections for the new process.
Basically, use inetd if possible, in the rare instance you cannot, standalone will hopefully be sufficient.
Hopefully this covered most common questions when setting up ProFTPD . If you have anymore questions, please feel free to post them up at LinuxQuestions.org and be sure to be as specific as possible. Include as much information as possible, paying extra special attenti
on to any error messages you find. And always, check your logs.