Menu

Category Archives: Linux Server Administration

In this tutorial, i will show you how to setup firewall for standalone server (redhat, centos based)1.Install shorewall$yum install shorewall2.Setup & configuration$vi /etc/shorewall/zones################################################################################ZONE TYPE OPTIONS IN OUT# OPTIONS OPTIONSfw firewallnet ipv4#LAST LINE – ADD YOUR ENTRIES ABOVE THIS ONE – DO NOT REMOVE

Setting up a mail server is a big project. Before installing and configuring the necessary packages on your mail server, you should learn what everything does and understand how the components work together to send and receive email. For the purposes of this guide, we’ll assume that you’ll be using the following packages and operating system:

Postfix: This Mail Transfer Agent (MTA) handles relaying mail between different servers. It decides what to do with email from the outside world, and whether a particular user is allowed to send email using your server. It handles both incoming and outgoing SMTP. Postfix hands off local delivery (that is, the actual saving of the mail files on the server) to Dovecot’s Local Mail Transfer Protocol service (LMTP). Postfix also lets Dovecot take care of authentication before users are allowed to send email from the server. We’ll use version 2.9.6.

Dovecot: This IMAP/POP3 server handles requests from users who want to log in and check their email. Dovecot’s LMTP service functions as the Mail Delivery Agent (MDA) by saving mail files on the server. Dovecot also handles all authorization. It checks users’ email addresses and passwords in the MySQL database before allowing them to view or send email. We’ll use version 2.0.19.

MySQL: This database server stores lookup tables for domains, usernames and passwords, and aliases on the mail server. We’ll use version 14.14 Distrib 5.5.29.

Ubuntu 12.04 LTS: These instructions are designed to work with Ubuntu 12.04 LTS. Other distributions can also be made to work with Postfix, Dovecot, and MySQL, but those instructions are outside the scope of this guide.

If you encounter problems while using this guide, please double-check that you are using Ubuntu 12.04, and that the package versions match the ones listed above.

Before setting up your mail server, you’ll need to set up your Linode as specified in the Getting Started and Securing Your Server guides. You’ll also need to verify that you’ve completed the following steps:

Before we dive into the nitty-gritty of getting everything set up, let’s take a look at how we want everything to work together once it’s installed. The following process details what happens when an incoming message from the someone@somewhereelse.com email account makes its way to your Linode.

someone@somewhereelse.com sends an email to me@mydomain.net.

DNS is checked. The MX record for mydomain.net points to my Linode.

The message reaches Postfix, the MTA.

Postfix checks whether it is allowed to relay for mydomain.net by checking the virtual domains table in MySQL.

MySQL returns a positive response for mydomain.net.

Postfix relays the message using Dovecot’s LMTP socket.

Dovecot saves the message to the me@mydomain.net mailbox on the server, which is located at /var/mail/mydomain.net/me/.

The email is now saved in the appropriate mailbox on the server. Next let’s see what happens when you check mail. The process starts when you decide you want to check your me@mydomain.net email from your local email client.

Dovecot to MySQL: MySQL, are this username and password in the users table?

MySQL to Dovecot: Yes. This username and password are in the users table.

Dovecot accesses the mailbox at /var/mail/mydomain.net/me/.

Dovecot gets the mail files.

Dovecot shows the messages to your local mail client using the IMAP protocol.

Now you can read your email using Outlook, Apple Mail, Thunderbird, etc. Finally, let’s see what happens when you send an email message from your account. Let’s say you want to send a reply from me@mydomain.net back to someone@somewhereelse.com. You compose a message in your local mail client and send it. What happens?

Local Mail Client to Postfix: Can I make an SMTP connection?

Postfix to Local Mail Client: Sure. You have to use encryption. Here’s my SSL certificate. Now I need your username and password.

Local Mail Client to Postfix: Here’s my username and password.

Postfix to Dovecot: Dovecot, check this username and password for me.

Dovecot to MySQL: MySQL, are this username and password in the users table?

MySQL to Dovecot: Yes. This username and password are in the users table.

Dovecot to Postfix: Postfix, this user is authenticated.

Postfix to Local Mail Client: You are allowed to send your message.

Local Mail Client to Postfix: Here’s the message.

Postfix sends the email. This is known as relaying. The reason there are so many processes involved is for security – you don’t want just anyone to be able to send email through your server, otherwise they would quickly start sending lots of spam. The authentication process makes it safe for you and your authorized users to send email using this server while blocking everyone else.

Start thinking about the best time to switch your DNS records. Once you switch the MX records, you’ll start sending and receiving mail from your Linode. If you currently have live email accounts on another server, you shouldn’t change the DNS until you have everything set up and working. In the meantime, you can test your mail server setup with the default domain name Linode assigns to your server. And if you’re setting up a new domain, you might as well point the DNS records at your Linode now so you don’t have to change anything later.

Either way, you can lower the time to live (TTL) on your domain’s zone file now, in anticipation of the upcoming DNS change. This will help the DNS records propagate faster when you’re ready to switch them. You should do this whether you are planning to change your DNS right away or later.

When you’re ready to switch the DNS and start sending mail to the server, edit your domain’s MX record so it points to your Linode’s domain or IP address, similar to the example below:

Make sure you do this for all domains and subdomains that might receive email for your domain. If you use Linode’s DNS Manager, you will need to create an MX record that points to the desired domain or subdomain, and then create an A record for that domain or subdomain as well, that points to the correct IP address.

You should think about whether you need to purchase a valid SSL certificate or not. In this guide, you’ll use the default self-signed certificate that comes with Dovecot for free. This certificate encrypts your mail connections just like a purchased certificate, but your email users will receive warnings about the certificate when they attempt to set up their email accounts.

This can be confusing for users, and it may encourage bad security habits by forcing them to accept a self-signed certificate. If you’re going to set up all of your users’ mail clients yourself, or if you have a small number of tech-savvy users, this might not be a problem. You’ll need to use your best judgement to decide whether you need to purchase a signed SSL certificate or not. For information about SSL certificates, see these guides in the Linode Library.

Now that you understand how everything works and have finished preparing your Linode to act as a mail server, let’s configure your server for mail. We’ll start by installing all of the necessary packages. Here’s how:

Log in as the root user by entering the following command:

su

Enter the password for the root user when prompted.

Install the required packages by entering the following command. Here’s what you’ll install:

You’ll be prompted to enter a System mail name, as shown below. You can use your FQDN or any domain name that resolves to the server. This will become your server’s default domain for mail when none is specified.

You just installed packages to support three applications: MySQL, Postfix, and Dovecot. Now it’s time to configure the individual applications to work together as a mail server.

First, you’ll create a dedicated database in MySQL for your mail server. It will have three tables: one with domains, one with email addresses and encrypted passwords, and one with email aliases. You’ll also create a dedicated MySQL user for Postfix and Dovecot.

Note

Strictly speaking, you don’t have to use MySQL to store this information. You could, for example, just list it all in the Postfix and Dovecot config files. But that gets unwieldy pretty quickly when you have lots of domains and users. Having the information in a database makes it easier to access and update, and it should make the maintenance of your mail server easier in the long run.

Create a new database by entering the following command. We’ll call the database mailserver in this example.

mysqladmin -p create mailserver

Enter the MySQL root password.

Log in to MySQL by entering the following command:

mysql -p mailserver

Enter the root MySQL password. You should see a command line prompt that looks like this:

mysql>

Create a new MySQL user (mailuser) by entering the following command. You’ll grant the user local, read-level access on the mailserver database, and you’ll also set the user’s password, which is mailuserpass in the example below. Please change this and make a note of the password for future use.

GRANT SELECT ON mailserver.* TO 'mailuser'@'127.0.0.1' IDENTIFIED BY 'mailuserpass';

Reload MySQL’s privileges to make sure the user has been added successfully:

FLUSH PRIVILEGES;

Enter the following command to create a table for the domains that will receive mail on your Linode. You can copy and paste the whole block of code at once – MySQL won’t execute it until you get to the semicolon (;). This will create a table called virtual_domains and give it two fields, an id field, and a name field for the domains.

Enter the following command to create a table for all of the email addresses and passwords. This command will create a table called virtual_users. It has adomain_id field to associate each entry with a domain, a password field to hold an encrypted version of each user’s password, and an email field to hold each user’s email address.

Enter the following command to create a table for your email aliases. This lets you forward mail from one email address to another. This command will create a table called virtual_aliases. It has an id field, a domain_id field which will associate each entry with a domain, a source field for the original email address, and adestination field for the target email address.

Now that you’ve created the database and tables, let’s add some data to MySQL. Here’s how:

Add your domains to the virtual_domains table. You can add as many domains as you want in the VALUES section of the command below, but in this example you’ll add just the primary domain (example.com), your hostname (hostname), your FQDN (hostname.example.com), and localhost.example.com. (You’ll add localhost in a different file later). Be sure to replace example.com and hostname with your own domain name and hostname. You’ll need an id value and aname value for each entry. Separate each entry with a comma (,), and close the last one with a semicolon (;).

Make a note of which id goes with which domain – you’ll need for the next two steps.

Add email addresses to the virtual_users table. In this example, you’ll add two new email addresses, email1@example.com and email2@example.com, with the passwords firstpassword and secondpassword, respectively. Be sure to replace the examples with your own information, but leave the password encryption functions intact. For each entry you’ll need to supply an id value, a domain_id, which should be the id number for the domain from Step 1 (in this case we’re choosing 1 for example.com), a password which will be in plain text in this command but which will get encrypted in the database, and an email, which is the full email address. Entries should be separated by a comma, and the final entry should be closed with a semicolon.

If you want to set up an email alias, add it to the virtual_aliases table. Just like in the previous step, we’ll need an id value, and a domain_id value chosen from the virtual_domains list in Step 1. The source should be the email address you want to redirect. The destination should be the target email address, and can be any valid email address on your server or anywhere else.

As the Mail Transfer Agent, Postfix decides where to relay messages that get directed to your server from anywhere else on the Internet. It also handles all SMTP connections and sends out messages for your users. In this section, you’ll modify some of these Postfix configuration options:

Virtual domains, aliases, and users, so you don’t have to make an actual UNIX user for everybody that needs an email address

MySQL access, so it can read the list of domains for which it should be handling mail

Hand-off for incoming email to Dovecot’s LMTP service so it can get saved on the server

STARTTLS encryption for all connections, for increased security

Hand-off for authentication to Dovecot

Here’s how to configure Postfix:

Before doing anything else, enter the following command to make a copy of the default Postfix configuration file. This will come in handy if you mess up and need to revert to the default configuration.

cp /etc/postfix/main.cf /etc/postfix/main.cf.orig

Open the configuration file for editing by entering the following command:

nano /etc/postfix/main.cf

The default configuration file looks like this. The myhostname and mydestination lines are specific to your server, but everything else should be as it looks here:

Comment out all of the lines in the #TLS parameters section, and then paste in the four new lines shown below. Since we’re using Dovecot for authentication, we’re going to use Dovecot’s default certificate rather than Postfix’s default certificate. For increased security, we’re also going to force users to use TLS encryption.

Note

If you have purchased an SSL certificate for your mail server, you should use the path to that certificate and its corresponding key, not the default Dovecot certificate. Otherwise, you can just use the following values.

Copy and paste the following values into the config file below the TLS settings. This will ease the restrictions and allow users to send email from their home or office. By default, only users who are logged into the server locally are able to send email. They will be required to log in with a password before being able to send email – this is very important, or anyone could start using your server to send spam! The smtpd_sasl_type and smtpd_sasl_path lines tell Postfix to use Dovecot for user authentication. Dovecot already authenticates users checking their email, so it makes sense to have it handle outgoing authentication too.

Explanation of parameters:

smtpd_sasl_type: SASL (Simple Authentication and Security Layer) is the framework for authentication that Postfix uses. Authentication is needed so that only authorized users can use your server to send mail. In this case, we’re telling Postfix to use Dovecot’s authentication.

smtpd_sasl_path: This is the path to the authentication socket. The path used here is relative to /var/spool/postfix/. The socket is located at/var/spool/postfix/private/auth, or it will be when we create it with Dovecot.

smtpd_sasl_auth_enable: This tells Postfix to let people send email using this server if they’ve successfully authenticated. If this was turned off, Postfix would let people send email only if they were already on the server (e.g., they were logged in with SSH).

smtpd_recipient_restrictions: This tells Postfix which types of users are allowed to send email to other email addresses using the server. (Specifically, it applies to messages that have a RCPT TO component.) The first two parameters we added tell Postfix to allow sending for SASL-authenticated users and for users connecting from a network listed in the mynetworks parameter (in our case, just the server’s local network). The final parameter tells Postfix to reject sending email unless the recipient is for someone on this server.

Comment out the existing mydestination line and replace it with one for localhost. This allows you to use the virtual domains listed in our MySQL table. It’s important that there is no overlap between the domains in the MySQL table and the domains in the mydestination line. Keeping the localhost entry inmydestination lets you keep things simple for mail sent within the server using localhost, which could be helpful if you’re ever having problems with your virtual domains.

Add a new line for local mail delivery (the service that actually saves the emails to individual user mailboxes). We’re telling Postfix not to use its own Local Delivery Agent (LDA) and instead use Dovecot’s LMTP (Local Mail Transfer Protocol) for local delivery. This applies to all virtual domains listed in the MySQL table.

File excerpt:/etc/postfix/main.cf

#Handing off local delivery to Dovecot's LMTP, and telling it where to store mail
virtual_transport = lmtp:unix:private/dovecot-lmtp

Add the following values to configure your virtual domains, users, and aliases. No changes are necessary.

Explanation of parameters:

virtual_mailbox_domains: Here you tell Postfix that you’re using MySQL to store virtual domains, and then give it a path to another file where you’ll put all the MySQL connection details.

Create the three files you specified earlier. These files will tell Postfix how to connect to MySQL to read the lists of domains, email addresses, and aliases. Create the file for virtual domains by entering the following command:

nano /etc/postfix/mysql-virtual-mailbox-domains.cf

Enter the following values. At a minimum, you’ll need to change the password entry to the one you created for mailuser. If you used a different user, database name, or table name, customize those settings as well.

Save the changes you’ve made to the /etc/postfix/mysql-virtual-mailbox-domains.cf file.

Restart Postfix by entering the following command:

service postfix restart

Enter the following command to ensure that Postfix can find your first domain. Be sure to replace example.com with your first virtual domain. The command should return 1 if it is successful; if nothing is returned, you have an issue.

Save the changes you’ve made to the /etc/postfix/mysql-virtual-mailbox-maps.cf file.

Restart Postfix by entering the following command:

service postfix restart

Test Postfix to verify that it can find the first email address in your MySQL table. Enter the following command, replacing email1@example.com with the first email address in your MySQL table. You should again receive 1 as the output:

Dovecot allows users to log in and check their email using POP3 and IMAP. In this section, you’ll configure Dovecot to force users to use SSL when they connect so that their passwords are never sent to the server in plain text. Users will have to connect using the standard SSL ports – 993 for IMAP and 995 for POP3 – and only those ports. Dovecot’s LMTP service will function as the MDA and store incoming messages in the proper locations on the server. Dovecot will also be handling all user authentication for mail.

Dovecot 2 uses a number of different configuration files. The primary configuration file contains a few directives, and then several inclusions of other configuration files. This helps to separate different configuration parameters logically so they’re not all grouped together in one file. This is a major change from Dovecot 1, where virtually everything was configured in the same file.

In this section, you’ll configure Dovecot to:

Set the IMAP, POP3, and LMTP protocols

Define the mail location

Use MySQL for username/password lookups for authentication

Configure needed sockets for authentication and LMTP

Require SSL encryption

You’ll modify a total of 7 Dovecot configuration files. Here’s the list:

Enter the following command to open the main configuration file for editing:

nano /etc/dovecot/dovecot.conf

Note

Click this link to see the final, complete version of our dovecot.conf example file.

Verify that dovecot.conf is including all of the other configuration files. This option should be enabled by default:

File excerpt:/etc/dovecot/dovecot.conf

!include conf.d/*.conf

Add the following line to /etc/dovecot/dovecot.conf so Dovecot knows to support IMAP, POP3, and LMTP. In this example, we have inserted it below the existing!include_try /usr/share/dovecot/protocols.d/*.protocol line:

Open the /etc/dovecot/conf.d/10-mail.conf file for editing by entering the following command. This file allows us to control how Dovecot interacts with the server’s file system to store and retrieve messages.

nano /etc/dovecot/conf.d/10-mail.conf

Note

Click this link to see the final, complete version of our 10-mail.conf example file. This is a long file, so you may need to use your editor’s search feature to find the values you need to edit.

Find the mail_location variable, uncomment it, and then set it to the following value. This tells Dovecot where to look for mail. In this case, the mail will be stored in /var/mail/vhosts/example.com/user/, where example.com and user are variables that get pulled from the connecting email address. For example, if someone logs in to the server with the email address email1@example.com, Dovecot will use example.com for %d, and email1 for %n. You can change this path if you want, but you’ll have to change it everywhere else the mail storage path is referenced in this tutorial. It’s useful to keep this location in mind if you ever need to manually download the raw mail files from the server.

File excerpt:/etc/dovecot/conf.d/10-mail.conf

mail_location = maildir:/var/mail/vhosts/%d/%n

Find the mail_privileged_group variable. Uncomment it, and then set it to the following value. This allows Dovecot to write to the /var/mail/ folder.

File excerpt:/etc/dovecot/conf.d/10-mail.conf

mail_privileged_group = mail

Save your changes to the /etc/dovecot/conf.d/10-mail.conf file.

Enter the following command to verify the permissions for /var/mail:

ls -ld /var/mail

Verify that the permissions for /var/mail are as follows:

drwxrwsr-x 2 root mail 4096 Mar 6 15:08 /var/mail

Create the /var/mail/vhosts/ folder and the folder(s) for each of your domains by entering the following command:

mkdir -p /var/mail/vhosts/example.com

Create the vmail user with a user and group id of 5000 by entering the following commands, one by one. This user will be in charge of reading mail from the server.

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /var/mail

Change the owner of the /var/vmail/ folder and its contents to belong to vmail by entering the following command:

chown -R vmail:vmail /var/mail

Open the user authentication file for editing by entering the command below. You need to set up authentication so only authenticated users can read mail on the server. You also need to configure an authentication socket for outgoing mail, since we told Postfix that Dovecot was going to handle that. There are a few different files related to authentication that get included in each other.

This password query lets you use an email address listed in the virtual_users table as your username credential for an email account. The primary email address should still be used as the username, even if you have set up your email client for an alias. If you want to be able to use the alias as your username instead (listed in the virtual_aliases table), you should first add every primary email address to the virtual_aliases table (directing to themselves) and then use the following line in /etc/dovecot/dovecot-sql.conf.ext instead:

Change the owner and group of the /etc/dovecot/ directory to vmail and dovecot by entering the following command:

chown -R vmail:dovecot /etc/dovecot

Change the permissions on the /etc/dovecot/ directory by entering the following command:

chmod -R o-rwx /etc/dovecot

Open the sockets configuration file by entering the following command. You’ll change the settings in this file to set up the LMTP socket for local mail delivery, and the auth socket for authentication. Postfix uses these sockets to connect to Dovecot’s services.

nano /etc/dovecot/conf.d/10-master.conf

Note

Click the link to see the final, complete version of 10-master.conf. There are many nested blocks of code in this file, so please pay very close attention to your brackets. It’s probably better if you edit line by line, rather than copying large chunks of code. If there’s a syntax error, Dovecot will crash silently, but you can check /var/log/upstart/dovecot.log to help you find the error.

Disable unencrypted IMAP and POP3 by setting the protocols’ ports to 0, as shown below. This will force your users to use secure IMAP or secure POP on 993 or 995 when they configure their mail clients:

Make sure you leave the secure versions alone – imaps and pop3s – so their ports still work. The default settings for imaps and pop3s are fine. You can leave the port lines commented out, as the default ports are the standard 993 and 995.

Find the service lmtp section and use the configuration shown below. You’ll need to add a few lines in the unix_listener block. This section makes the socket for LMTP in the place we told Postfix to look for it.

Locate the service auth section and use the configuration shown below. You’ll need to create a new unix_listener block, modify the existing one, and then uncomment and set the user. This section makes the authorization socket where we told Postfix to look for it:

File excerpt:/etc/dovecot/conf.d/10-master.conf

service auth {
# auth_socket_path points to this userdb socket by default. It's typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Its default
# permissions make it readable only by root, but you may need to relax these
# permissions. Users that have access to this socket are able to get a list
# of all usernames and get results of everyone's userdb lookups.
unix_listener /var/spool/postfix/private/auth {
mode = 0666
user = postfix
group = postfix
}
unix_listener auth-userdb {
mode = 0600
user = vmail
#group =
}
# Postfix smtp-auth
#unix_listener /var/spool/postfix/private/auth {
# mode = 0666
#}
# Auth process is run as this user.
user = dovecot
}

In the service auth-worker section, uncomment the user line and set it to vmail, as shown below.

File excerpt:/etc/dovecot/conf.d/10-master.conf

service auth-worker {
# Auth worker process is run as root by default, so that it can access
# /etc/shadow. If this isn't necessary, the user should be changed to
# $default_internal_user.
user = vmail
}

Save your changes to the /etc/dovecot/conf.d/10-master.conf file.

Verify that the default Dovecot SSL certificate and key exist by entering the following commands, one by one:

ls /etc/ssl/certs/dovecot.pem
ls /etc/ssl/private/dovecot.pem

Note

If you are using a different SSL certificate, you should upload the certificate to the server and make a note of its location and the key’s location.

Open the SSL configuration file for editing by entering the following command. This is where we tell Dovecot where to find our SSL certificate and key, and any other SSL-related parameters.

Verify that the ssl_cert setting has the path to your certificate, and that the ssl_key setting has the path to your key. The default setting here uses Dovecot’s built-in certificate, so you can leave this as-is if you are using the Dovecot certificate. You should update the paths if you are using a different certificate and key.

Force your clients to use SSL encryption for all connections. Set ssl to required:

File excerpt:/etc/dovecot/conf.d/10-ssl.conf

ssl = required

Save your changes to the /etc/dovecot/conf.d/10-ssl.conf file. Dovecot has been configured!

Restart Dovecot by entering the following command:

service dovecot restart

Set up a test account in an email client to make sure everything is working. You’ll need to use the following parameters:

Your full email address, including the @example.com part, is your username.

Your password should be the one you added to the MySQL table for this email address.

The incoming and outgoing server names must be a domain that resolves to your Linode.

Both the incoming and outgoing servers require authentication and SSL encryption.

You should use Port 993 for secure IMAP, Port 995 for secure POP3, and Port 25 with SSL for SMTP.

Try sending an email to this account from an outside email account and then reply to it. If it works, you’re in business! You can check your mail log file in/var/log/mail.log, where you should see something like this (the first block is for an incoming message, and the second block for an outgoing message):

Congratulations! You now have a functioning mail server that can securely send and receive email. At this point, you may want to consider adding spam and virus filtering and a webmail client. If you haven’t switched the DNS records for your mail server yet, you should be able to do so now. Once the DNS records have propagated, you will start receiving email for your domain on the server.

Now your mail server is up and running, but eventually you’ll probably need to add new domains, email addresses, and aliases for your users. To do this, all you’ll have to do is add a new line to the appropriate MySQL table. These instructions are for command-line MySQL, but you can just as easily use phpMyAdmin to add new entries to your tables as well.

Be sure to use the correct number for the domain_id. In this case, we are using 5, because we want to make an email address for newdomain.com, andnewdomain.com has an id of 5 in the virtual_domains table.

Verify that the new email address has been added by entering the following command. You should see the new email address in the output.

SELECT * FROM mailserver.virtual_users;

To exit MySQL, enter the following command:

quit

Congratulations! You have successfully added the new email address to your Postfix and Dovecot setup.

Enter the following command in MySQL, replacing alias@newdomain.com with the address from which you want to forward email, and myemail@gmail.comwith the address that you want to forward the mail to. The alias@newdomain.com needs to be an email address that already exists on your server.

Contents

Update Your System

The first thing we need to do is make sure your Cloud Server has all of it’s security patches. Connect to your Cloud Server with SSH (or the Console from the Control Panel) and login as your normal user. For the purposes of this walk-through our sample user is conveniently named ‘user’.

Execute the YUM package manager and use the ‘upgrade’ command to upgrade the system:

# sudo yum upgrade

A series of items will fly by and you will be prompted to install… press Y followed by Enter. This will take a few minutes.

It is a good idea to restart your Cloud Server to make sure any new packages that were downloaded are freshly loaded.

# sudo reboot

You can use the ping command to check when your server has come back online.

Another option is to copy the direct link and download the file manually on your Cloud Server. For purposes of demonstration we will show you this option. The link below was valid at the time of writing and may have changed — please adjust accordingly.

You will see the wget utility appear and it will download the file. Once it has finished you will be returned to the prompt.

Installing LiteSpeed

We need to unpack the LiteSpeed package that we downloaded. Type the following command to unpack: (note that your file name may be different)

# sudo tar -zxvf lsws-4.0.3-std-i386-linux.tar.gz

Now we need to enter the directory that we extracted the files into:

# cd lsws-4.0.3

We are now ready to start the installer. Type the following command to start the installer:

# sudo ./install.sh

You will be prompted with a license agreement. Read the agreement and press the space bar multiple times until you reach the end.

After you ‘space’ through the license you will be prompted with the following:

IMPORTANT: In order to continue installation you must agree with above
license terms by typing "Yes" with capital "Y"!
Do you agree with above license?

Type Yes at this point and press Enter. Note that you *must* put a capital Y.

The next screen that appears will ask you what directory you would like to install LiteSpeed. The default directory is sufficient. Simple press Enter to accept the default.

Please specify the destination directory. You must have permissions to
create and manage the directory. It is recommended to install the web server
at /opt/lsws, /usr/local/lsws or in your home directory like '~/lsws'.
ATTENTION: The user 'nobody' must be able to access the destination
directory.
Destination [/usr/local/lsws]:

The next prompt will ask you for the administrative login that you would like to use for the administrative console. Simply press Enter to accept the default.

Please specify the user name of the administrator.
This is the user name required to log into the administration web interface.
User name [admin]:

Enter the password that you’d like to use for administering your web server. Please make sure this is secure as it has the power to stop your server! Press Enter once you have entered it.

Please specify the administrator's password.
This is the password required to log into the administration web interface.
Password:

Retype the password again.

Enter an e-mail address for the server administrator. This will be displayed on error messages so the server administrator may be contacted in the event of server failure.

Please specify administrators' email addresses.
It is recommended to specify a real email address,
Multiple email addresses can be set by a comma
delimited list of email addresses. Whenever something
abnormal happened, a notificiation will be sent to
emails listed here.
Email addresses [root@localhost]:

Next you will be prompted for the user that the web server should run as. Leave it the default user of nobody and pressEnter.

As you are the root user, you must choose the user and group
whom the web server will be running as. For security reason, you should choose
a non-system user who does not have login shell and home directory such as
'nobody'.
User [nobody]:

You will be asked for the group next. Press Enter.

Please choose the group that the web server running as.
User 'nobody' is the member of following group(s): nobody
Group [nobody]:

Next you will be prompted for the port that the web server should answer on. Default HTTP traffic is port 80. Because the default port that the server selects is not correct, type in 80 and press Enter.

Please specify the port for normal HTTP service.
Port 80 is the standard HTTP port, only 'root' user is allowed to use
port 80, if you have another web server running on port 80, you need to
specify another port or stop the other web server before starting LiteSpeed
Web Server.
You can access the normal web page at http://<YOUR_HOST>:<HTTP_PORT>/
HTTP port [8088]: 80

You will be prompted for the port that the administrative control panel should answer on. We will select the default port of 7080. Simply press Enter.

Please specify the HTTP port for the administration web interface,
which can be accessed through http://<YOUR_HOST>:<ADMIN_PORT>/
Admin HTTP port [7080]:

You will be asked if you would like to install PHP support. For our demonstration we will turn on PHP support. Type Yand press Enter.

You can setup a global script handler for PHP with the pre-built PHP engine
shipped with this package now. The PHP engine runs as Fast CGI which
outperforms Apache's mod_php.
You can always replace the pre-built PHP engine with your customized PHP
engine.
Setup up PHP [Y/n]: Y

You will then be asked for the default PHP extension. Select the default PHP and press Enter.

Suffix for PHP script(comma separated list) [php]:

Next you will be prompted to install AWStats, a web-traffic logger. For our demonstration we have chosen to not install it. Press N and then press Enter.

AWStats is a popular log analyzer that generates advanced web server
statistics. LiteSpeed web server seamlessly integrates AWStats into
its Web Admin Interface. AWStats configuration and statistics update
have been taken care of by LiteSpeed web server.
Note: If AWStats has been installed already, you do not need to
install again unless a new version of AWStats is available.
Would you like to install AWStats Add-on module [y/N]? N

A large amount of text will pass (please read!) and then you will be prompted if you would like LiteSpeed to start automatically. Press Y and then Enter.

Would you like to have LiteSpeed Web Server started automatically
when the server restarts [Y/n]? Y

If that step completes successfully you will be asked if you would like to start LiteSpeed now. Press Y and then pressEnter.

[OK] The startup script has been successfully installed!
Would you like to start it right now [Y/n]? Y

If the server starts successfully you will be given an output that looks similar to the one below:

Testing LiteSpeed

Open up your web-browser and point it to your Cloud Server’s IP address (or domain name if you have DNS setup). You should see something like the following:

If you receive a similar screen then you have successfully installed LiteSpeed! Be sure to check out your administrative control panel at http://12.34.56.78:7080/. Change 12.34.56.78 to your IP address. If you changed the administrative port number you will have to change that as well.

After changing the value, save the file and restart Apache with apache2ctl graceful-stop && apache2ctl start.

Why It’s Important

One of the most common causes of a public Web server crash is that it’s consumed all available physical memory (RAM). When this happens, the operating system attempts to free RAM by moving some of it to disk. In Linux this is called the “swap” space; in Windows “page file.” This process defeats the purpose of RAM (which is to provide very fast access to data) and it requires resources (CPU power, disk I/O) to perform the “swapping” of data between the disk and RAM. The swap space can also become completely consumed, but the real problem is that in a very fast-paced environment like a Web server, the system can quickly become overwhelmed and effectively crash just by trying to manage its own memory. This is called thrashing.

The name of the game is to avoid thrashing and the only way to do so is to keep Apache from using more physical RAM than is available to it.

How To Determine How Much RAM is Available to Apache

The amount of RAM available to Apache is the total amount of RAM on the system minus the amount that will be used by all other processes. Unfortunately, it’s difficult to determine how much RAM is being used on the system.* It’s even harder to determine how muchmaximum possible RAM will be used by other processes when the server is under heavy load.

And it gets yet more difficult if you’re running MySQL on the same machine. Typically, each request handled by Apache will open at least one connection to MySQL, so as the Apache requests increase, so will MySQL’s RAM usage. In short, MySQL’s memory usage depends on how it’s being used by your application. You can use the mysqltuner script to get an absolute maximum value that MySQL will use, but once you have Apache tuned properly it will rarely hit this amount. Your best bet is to move MySQL to a separate server. Other than that, use the max value initially, watch the server under load, and make adjustments.

For all the other processes, use a value of 256 MiB. If you’re using a lot of other services, such as on a virtual hosting machine, you may want to use a higher value.

How to Determine How Much RAM a Single Apache Process Uses

Again, due to shared memory (especially if you’re using APC), buffering, caching, etc. it’s very difficult to determine this. In our experience, the best tool for determining memory usage per process is ps_mem.py.

Here you can see that there are 123 apache2 processes, consuming a total of 3.4 GiB, so each Apache process is using roughly 28 MiB of RAM. This system has about 8 GiB of RAM, and although mysqltuner.pl reports that MySQL’s maximum memory use is about 1 GiB, we can see that it’s using much less. To be safe though, I’ll reserve 1.5 GiB for all other processes and round up Apache’s average usage to 32 MiB:

(6.5 x 1024) / 32 = 208

To be extra safe, round this down to 200. It’s better to under-estimate.

Watch The Server

Keep an eye on the number of Apache processes, and the total RAM used. Here’s a command that wraps this into a single output that updates every second:

Use the -/+ buffers/cache row. The values are in MiB. You can see that at this point in time, about 2.3 GiB is in use and 5.7 GiB is free. If your Apache processes get close to the MaxClients setting and there’s plenty of extra RAM available, adjust the value up in small steps. If for some reason the value in the free column gets small (say less than 500), reduce Apache’s MaxClients value and restart.

Overview

First check the MPM (Multi-Processing Module) used, most distributions come with a default prefork configuration where a minimum number of Apache processes is started (preforked) and more are added depending on incoming traffic. In general Apache optimization is about monitoring the number of Apache processes(also called workers) in combination with the total memory used by the system. Real time monitoring how many workers are in use and what they are doing is easy after installing and configuring the Apache mod_status module.

We advise you enable server-status monitoring, calculate the number of memory needed by your typical workload and optimize and constantly monitor processes/workers used by your Apache installation.

Step 2: Check what mode Apache is running in

Apache can use a number of ways to handle requests. Apache calls this MPM (Multi-Processing Module) and there are several to choose from. By far the most widely used (at least on *nix platforms) are the three main ones: prefork, worker, and event. Essentially, they represent the evolution of the Apache web server, and the different ways that the server has been built to handle HTTP requests within the computing constraints of the time over its long (in software terms) history.

Prefork or mpm_prefork is compatible with everything including (simple) PHP and SSL and is easier to debug but not so kind on RAM usage if you have a lot of concurrent requests. For now we prefer to use mpm_prefork and enough free memory and keep a number of free workers to handle all http clients (both webacess/webapp and Z-push devices) at the same time.

mpm_itk (see http://mpm-itk.sesse.net/) mpm-itk is based on the traditional prefork MPM, which means it’s non-threaded. This means you can run non-thread-aware code (like many PHP extensions) without problems. You lose out to any performance benefit you’d get with threads. You will also take an additional performance hit over prefork, since there’s an extra fork per request.

mpm_worker uses threading which is a big help for concurrency. A worker spins off some child processes, which in turn spin off child threads; some spare threads are kept ready if possible, to service incoming connections. This approach is kinder on RAM, since the thread count doesn’t have a direct bearing on memory use like the server count does in prefork. It also handles concurrency much more easily, since the connections just need to wait for a free thread (which is usually available) instead of a spare server in prefork. If you have the RAM available and start enough spare workers processes then the advantages of mpm_worker are limited.

Step 3: Measure and calculate maximum memory usage

Investigate the current memory usage of Apache using one liner scripts. Take these measurements for systems that have been running for a few days to get an accurate measurement for the distribution of web and z-push users. After measuring the individual average, calculate to total memory needed based on the number of devices and concurrent web sessions.

NOTE 2 Do a full restart of your Apache server NOT a reload because not all changes can be done without completely shutting down the Apache mother process.

Step 5: Enable monitoring of the server-status page and plot some nice graphs

Because workloads change you need to continuously monitor the number of idle Apache processes and the memory/swap usage of your setup. Please use this Nagios plugin and complement your monitoring by using a project like Munin.

There are various settings that needs to be done before starting. These are specified in the configuration file for vsftpd located in “/etc/vsftpd.conf”. The default configuration is a little bit paranoid, not so usable for file sharing.
We can edit this, but lets keep a copy of the original somewhere.$ sudo cp /etc/vsftpd.conf /etc/vsftpd_conf_original.txt

2. I have used the following configuration for my FTP server. It allows anonymous access and anonymous users are jailed(thats the term used) to the chroot(eg. /home/ftp will be the default) directory. Enable/ Uncomment these lines in vsftpd.conf:
(Replace “abhishek” with your username on linux)listen=YES
anonymous_enable=YES
write_enable=YES
local_umask=022
anon_upload_enable=YES
anon_mkdir_write_enable=YES
xferlog_enable=YES
chown_uploads=YES
chown_username=abhishek
ftpd_banner=Welcome to Abhishek's FTP service.
chroot_local_user=NO
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd

4. You can make changes to the configuration file anytime. But remember to restart the ftp server, using the above command, to apply the changes.
After this your ftp server should start functioning.

5. To Allow FTP access to files outside the home directory chroot, see the Reference#2 below.

To access the files, there are many ways.
1. Open a browser like Internet explorer, firefox, opera etc. Type the url as
“ftp://servername” for anonymous access. e.g. ftp://10.117.113.24 or
“ftp://username@servername” for login. e.g. ftp://abhishek@10.117.113.24
Then the files will get listed.
In this method, you can only download files from the FTP server.

2. Using gFTP- Install gFTP from Synaptic Package Manager. Run it from Applications>Internet>gFTP. Enter the username and password to login(For anonymous access, give username as “anonymous” and any relevant password). Then start sharing files.

3. Using Command Prompt-
In windows, open command prompt or
In Linux, open terminal
and type:ftp servername or
ftp ftp://username@servername

To download a file use:ftp>get remote-file [local-file]
To upload:ftp>put local-file [remote-file]
To close connection:ftp>close