Building for Production: Web Applications — Deploying

Building for Production: Web Applications — Deploying
Introduction

In this part of the tutorial, we will deploy our example PHP application, WordPress, and a private DNS:

DNS + Application Diagram

Your users will access your application over HTTPS via a domain name, e.g. “https://www.example.com”, that points to the load balancer. The load balancer will act as a reverse proxy to the application servers, which will connect to the database server. The private DNS will enable us to use names to refer to the private network addresses of our servers which ease the process of configuration of our servers.

We will set up the components that we just discussed on six servers, in this order:

  • Private DNS (ns1 and ns2)
  • Database Server (db1)
  • Application Servers (app1 and app2)
  • Load Balancer (lb1)

Let’s get started with the DNS setup.

Private DNS Servers

Using names for addresses helps with identifying the servers you are working with and becomes essential for the maintenance of a larger server setup, as you can replace a server by simply updating your DNS records (in a single place) instead of updating countless configuration files with IP addresses. In our setup, we will set up our DNS so we can reference the private network addresses of our servers by name instead of IP address.

We will refer to the private network address of each server by a hostname under the “nyc3.example.com” subdomain. For example, the database server’s private network address would be “db1.nyc3.example.com”, which resolves to it’s private IP address. Note that the example subdomain is almost completely arbitrary, and is usually chosen based on logical organization purposes; in our case, we “nyc3” indicates that the servers are in the NYC3 datacenter, and “example.com” is our application’s domain name.

Set this up by following this tutorial, and adding DNS records for each server in your setup:

After completing the DNS tutorial, you should have two BIND servers: ns1 and ns2. If you already know the private IP addresses of all of the servers in your setup, add them to your DNS now; otherwise, add the appropriate DNS records as you create your servers.

Now we’re ready to set up our database server.

Set Up Database Server

Because we want to load balance the our application servers, i.e. the ones running Apache and PHP, we need to decouple the database from the application servers by setting it up on a separate server. Decoupling the database from the application is an essential step before horizontally scaling many types of applications, as explained in this blog post: Horizontally Scaling PHP Applications: A Practical Overview.
Continue reading Building for Production: Web Applications — Deploying

Building for Production: Web Applications — Overview

Building for Production: Web Applications — Overview

Introduction

This 6-part tutorial will show you how to build out a multi-server production application setup from scratch. The final setup will be supported by backups, monitoring, and centralized logging systems, which will help you ensure that you will be able to detect problems and recover from them. The ultimate goal of this series is to build on standalone system administration concepts, and introduce you to some of the practical considerations of creating a production server setup.

If you are interested in reviewing some of the concepts that will be covered in this series, read these tutorials:

While the linked articles provide general guidelines of a production application setup, this series will demonstrate how to plan and set up a sample application from start to finish. Hopefully, this will help you plan and implement your own production server environment, even if you are running a different application on a completely different technology stack. Because this tutorial covers many different system administration topics, it will often defer the detailed explanation to external supporting articles that provide supplemental information.

Our Goal

By the end of this set of tutorials, we will have a production server setup for a PHP application, WordPress for demonstration purposes, that is accessible via https://www.example.com/. We will also include servers that will support the production application servers. The final setup will look something like this (private DNS and remote backups not pictured):

Production Setup

In this setup, the servers in the Application box are considered to be essential for the application run properly. Aside from the recovery plan and the remote backup server, the remaining components—backups, monitoring, and logging—will be added to support the production application setup. Each component will be installed on a separate Ubuntu 14.04 server within the same DigitalOcean region, NYC3 in our example, with Private Networking enabled.

Continue reading Building for Production: Web Applications — Overview

Back Up a LAMP Server with Bacula on Ubuntu 14.04

Introduction

After getting your application server up and running, an important next step is to set up a backup system. A backup system will allow you to create periodic backup copies of your data, and restore data from those backups. As data can be lost due to user error or the eventual hardware failure that any computer system is prone to, you will want set up backups as a safety net.

This tutorial will show you how to create proper backups of a PHP application, running a LAMP stack on a single Ubuntu 14.04 server, by using a separate backups server that is running Bacula. One of the benefits of using a backup system like Bacula is that it gives you full control of what should be backed up and restored, at the individual file level, and the schedule of when the backups should be created. Having file-level granularity when creating backups allows us to limit our backup selections to only the files that are needed, which will save disk space compared to backing up the entire filesystem.

Backup Diagram

If this seems excessive to you, you may want to consider DigitalOcean Droplet Backups (snapshot backups of your entire Droplet), which must be enabled when you create your Droplet. These backups are easy to set up and may be sufficient for your needs if you only require weekly backups. If you opt for DigitalOcean Backups, be sure to set up hot backups of your database by following the Create Hot Backups of Your Database section—this is necessary to ensure that your database backups will be consistent (usable).

Prerequisites

This tutorial assumes that you are running a PHP application, such as WordPress, that is running on a LAMP (Linux, Apache, MySQL/MariaDB, and PHP) stack on a single Ubuntu 14.04 server, with private networking enabled. We will refer to this as the LAMP server. For our example, we will be creating backups of a WordPress server that was created by following these tutorials:

If you are running a different PHP application, or using Nginx instead of Apache, this tutorial will still work fine assuming that you make any necessary adjustments to your backup selection.

Of course, you will need sudo access to a server that the Bacula server software will be installed on, which we’ll refer to as the backups server. Ideally, it will be in the same data center as your LAMP server, and have private networking enabled. The backups that are created will live on this server, so it will need enough disk space to store multiple copies of your backup selection.

Backup Selection

As mentioned in the introduction, our backup selection—the files that will be copied every time a backup is created—will consist only of the files that are necessary to restore your application to a previous state. In short, this means we will backup the following data:

  • PHP Application Files: This will be the DocumentRoot of your web server. On Ubuntu, this will be /var/www/html by default
  • MySQL Database: While the MySQL data files are typically stored in /var/lib/mysql, we must create a hot backup of the database in another location. The hot backups will be part of our backup selection

As a matter of convenience, we will also include the Apache and MySQL configuration files in our backup selection. If you have any other important files, such as SSL key and certificate files, be sure to include those too.

The rest of the files on the server can be replaced by following the software installation steps of the initial setup. In the case of a server failure, we could create a replacement LAMP server by following the prerequisite tutorials then restoring the backups, and restarting the appropriate services.

If you are not sure why we are including the aforementioned files in the backup selection, check out the Recovery Planning segment of the multi-part Building for Production: Web Applications tutorial series. It describes how a recovery plan can be developed for a web application, using a multi-server setup as its example.

Let’s set up the hot backups of our database. Continue reading Back Up a LAMP Server with Bacula on Ubuntu 14.04

Set Up a Firewall with UFW on Ubuntu 14.04

Introduction

UFW, or Uncomplicated Firewall, is an interface to iptables that is geared towards simplifying the process of configuring a firewall. While iptables is a solid and flexible tool, it can be difficult for beginners to learn how to use it to properly configure a firewall. If you’re looking to get started securing your network, and you’re not sure which tool to use, UFW may be the right choice for you.

This tutorial will show you how to set up a firewall with UFW on Ubuntu 14.04.

Prerequisites

Before you start using this tutorial, you should have a separate, non-root superuser account—a user with sudo privileges—set up on your Ubuntu server. You can learn how to do this by completing at least steps 1-3 in the Initial Server Setup with Ubuntu 14.04 tutorial.

UFW is installed by default on Ubuntu. If it has been uninstalled for some reason, you can install it with apt-get:

  • sudo apt-get install ufw

Using IPv6 with UFW

If your Ubuntu server has IPv6 enabled, ensure that UFW is configured to support IPv6 so that it will manage firewall rules for IPv6 in addition to IPv4. To do this, open the UFW configuration with your favorite editor. We’ll use nano:

  • sudo nano /etc/default/ufw

Then make sure the value of “IPV6” is to equal “yes”. It should look like this:

/etc/default/ufw excerpt
...
IPV6=yes
...

Save and quit. Hit Ctrl-X to exit the file, then Y to save the changes that you made, then ENTER to confirm the file name.

When UFW is enabled, it will be configured to write both IPv4 and IPv6 firewall rules.

This tutorial is written with IPv4 in mind, but will work fine for IPv6 as long as you enable it.

Check UFW Status and Rules

At any time, you can check the status of UFW with this command:

  • sudo ufw status verbose

By default, UFW is disabled so you should see something like this:

Output:
Status: inactive

If UFW is active, the output will say that it’s active, and it will list any rules that are set. For example, if the firewall is set to allow SSH (port 22) connections from anywhere, the output might look something like this: Continue reading Set Up a Firewall with UFW on Ubuntu 14.04

Iptables Essentials: Common Firewall Rules and Commands

Introduction

Iptables is the software firewall that is included with most Linux distributions by default. This cheat sheet-style guide provides a quick reference to iptables commands that will create firewall rules are useful in common, everyday scenarios. This includes iptables examples of allowing and blocking various services by port, network interface, and source IP address.

How To Use This Guide

  • If you are just getting started with configuring your iptables firewall, check out our introduction to iptables
  • Most of the rules that are described here assume that your iptables is set to DROP incoming traffic, through the default input policy, and you want to selectively allow traffic in
  • Use whichever subsequent sections are applicable to what you are trying to achieve. Most sections are not predicated on any other, so you can use the examples below independently
  • Use the Contents menu on the right side of this page (at wide page widths) or your browser’s find function to locate the sections you need
  • Copy and paste the command-line examples given, substituting the values in red with your own values

Keep in mind that the order of your rules matter. All of these iptables commands use the -A option to append the new rule to the end of a chain. If you want to put it somewhere else in the chain, you can use the -I option which allows you to specify the position of the new rule (or simply place it at the beginning of the chain by not specifying a rule number).

Note: When working with firewalls, take care not to lock yourself out of your own server by blocking SSH traffic (port 22, by default). If you lose access due to your firewall settings, you may need to connect to it via the console to fix your access. Once you are connected via the console, you can change your firewall rules to allow SSH access (or allow all traffic). If your saved firewall rules allow SSH access, another method is to reboot your server.

Remember that you can check your current iptables ruleset with sudo iptables -S and sudo iptables -L.

Let’s take a look at the iptables commands!

Saving Rules

Iptables rules are ephemeral, which means they need to be manually saved for them to persist after a reboot.

Ubuntu

On Ubuntu, the easiest way to save iptables rules, so they will survive a reboot, is to use the iptables-persistent package. Install it with apt-get like this:

  • sudo apt-get install iptables-persistent

During the installation, you will asked if you want to save your current firewall rules.

If you update your firewall rules and want to save the changes, run this command:

  • sudo invoke-rc.d iptables-persistent save

CentOS 6 and Older

On CentOS 6 and older—CentOS 7 uses FirewallD by default—you can use the iptables init script to save your iptables rules:

  • sudo service iptables save

This will save your current iptables rules to the /etc/sysconfig/iptables file.

Listing and Deleting Rules

If you want to learn how to list and delete iptables rules, check out this tutorial: How To List and Delete Iptables Firewall Rules.

Generally Useful Rules

This section includes a variety of iptables commands that will create rules that are generally useful on most servers.

Allow Loopback Connections

The loopback interface, also referred to as lo, is what a computer uses to for network connections to itself. For example, if you run ping localhost or ping 127.0.0.1, your server will ping itself using the loopback. The loopback interface is also used if you configure your application server to connect to a database server with a “localhost” address. As such, you will want to be sure that your firewall is allowing these connections.
Continue reading Iptables Essentials: Common Firewall Rules and Commands

List and Delete Iptables Firewall Rules

Introduction

Iptables is a firewall that plays an essential role in network security for most Linux systems. While many iptables tutorials will teach you how to create firewall rules to secure your server, this one will focus on a different aspect of firewall management: listing and deleting rules.

In this tutorial, we will cover how to do the following iptables tasks:

  • List rules
  • Clear Packet and Byte Counters
  • Delete rules
  • Flush chains (delete all rules in a chain)
  • Flush all chains and tables, delete all chains, and accept all traffic

Note: When working with firewalls, take care not to lock yourself out of your own server by blocking SSH traffic (port 22, by default). If you lose access due to your firewall settings, you may need to connect to it via the console to fix your access. Once you are connected via the console, you can change your firewall rules to allow SSH access (or allow all traffic). If your saved firewall rules allow SSH access, another method is to reboot your server.

Prerequisites

Before you start using this tutorial, you should have a separate, non-root superuser account—a user with sudo privileges—set up on your server. If you need to set this up, follow the appropriate guide:

Let’s look at how to list rules first. There are two different ways to view your active iptables rules: in a table or as a list of rule specifications. Both methods provide roughly the same information in different formats.

List Rules by Specification

To list out all of the active iptables rules by specification, run the iptables command with the -S option:

  • sudo iptables -S
Example: Rule Specification Listing
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ICMP
-N TCP
-N UDP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT

As you can see, the output looks just like the commands that were used to create them, without the preceding iptables command. This will also look similar to the iptables rules configuration files, if you’ve ever used iptables-persistent or iptables save.

List Specific Chain

If you want to limit the output to a specific chain (INPUT, OUTPUT, TCP, etc.), you can specify the chain name directly after the -S option. For example, to show all of the rule specifications in the TCP chain, you would run this command:

  • sudo iptables -S TCP
Example: TCP Chain Rule Specification Listing
-N TCP
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT

Let’s take a look at the alternative way to view the active iptables rules, as a table of rules.

List Rules as Tables

Listing the iptables rules in the table view can be useful for comparing different rules against each other, Continue reading List and Delete Iptables Firewall Rules

What is a Firewall and How Does It Work?

Introduction

A firewall is a system that provides network security by filtering incoming and outgoing network traffic based on a set of user-defined rules. In general, the purpose of a firewall is to reduce or eliminate the occurrence of unwanted network communications while allowing all legitimate communication to flow freely. In most server infrastructures, firewalls provide an essential layer of security that, combined with other measures, prevent attackers from accessing your servers in malicious ways.

This guide will discuss how firewalls work, with a focus on stateful software firewalls, such as iptables and FirewallD, as they relate to cloud servers. We’ll start with a brief explanation of TCP packets and the different types of firewalls. Then we’ll discuss a variety of topics that a relevant to stateful firewalls. Lastly, we will provide links to other tutorials that will help you set up a firewall on your own server.

TCP Network Packets

Before discussing the different types of firewalls, let’s take a quick look at what Transport Control Protocol (TCP) network traffic looks like.

TCP network traffic moves around a network in packets, which are containers that consist of a packet header—this contains control information such as source and destination addresses, and packet sequence information—and the data (also known as a payload). While the control information in each packet helps to ensure that its associated data gets delivered properly, the elements it contains also provides firewalls a variety of ways to match packets against firewall rules.

It is important to note that successfully receiving incoming TCP packets requires the receiver to send outgoing acknowledgment packets back to the sender. The combination of the control information in the incoming and outgoing packets can be used to determine the connection state (e.g. new, established, related) of between the sender and receiver. Continue reading What is a Firewall and How Does It Work?

Migrate Iptables Firewall Rules to a New Server

Introduction

When migrating from one server to another, it is often desirable to migrate the iptables firewall rules as part of the process. This tutorial will show you how to easily copy your active iptables rule set from one server to another.

Prerequisites

This tutorial requires two servers. We will refer to the source server, which has the existing iptables rules, as Server A. The destination server, where the rules will be migrated to, will be referred to as Server B.

You will also need to have superuser, or sudo, access to both servers.

View Existing Iptables Rules

Before migrating your iptables rules, let’s see what they are set to. You can do that with this command on Server A:

  • sudo iptables -S
Example output:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 15.15.15.51/32 -j DROP

The example rules above will be used to demonstrate the firewall migration process. Continue reading Migrate Iptables Firewall Rules to a New Server

Configure BIND as a Private Network DNS Server on Ubuntu 14.04

Introduction

An important part of managing server configuration and infrastructure includes maintaining an easy way to look up network interfaces and IP addresses by name, by setting up a proper Domain Name System (DNS). Using fully qualified domain names (FQDNs), instead of IP addresses, to specify network addresses eases the configuration of services and applications, and increases the maintainability of configuration files. Setting up your own DNS for your private network is a great way to improve the management of your servers.

In this tutorial, we will go over how to set up an internal DNS server, using the BIND name server software (BIND9) on Ubuntu 14.04, that can be used by your Virtual Private Servers (VPS) to resolve private host names and private IP addresses. This provides a central way to manage your internal hostnames and private IP addresses, which is indispensable when your environment expands to more than a few hosts.

The CentOS version of this tutorial can be found here.

Prerequisites

To complete this tutorial, you will need the following:

  • Some servers that are running in the same datacenter and have private networking enabled
  • A new VPS to serve as the Primary DNS server, ns1
  • Optional: A new VPS to serve as a Secondary DNS server, ns2
  • Root access to all of the above (steps 1-4 here)

If you are unfamiliar with DNS concepts, it is recommended that you read at least the first three parts of our Introduction to Managing DNS.

Example Hosts

For example purposes, we will assume the following:

  • We have two existing VPS called “host1” and “host2”
  • Both VPS exist in the nyc3 datacenter
  • Both VPS have private networking enabled (and are on the 10.128.0.0/16 subnet)
  • Both VPS are somehow related to our web application that runs on “example.com”

With these assumptions, we decide that it makes sense to use a naming scheme that uses “nyc3.example.com” to refer to our private subnet or zone. Therefore, host1‘s private Fully-Qualified Domain Name (FQDN) will be “host1.nyc3.example.com”. Refer to the following table the relevant details:

Host Role Private FQDN Private IP Address
host1 Generic Host 1 host1.nyc3.example.com 10.128.100.101
host2 Generic Host 2 host2.nyc3.example.com 10.128.200.102

Note: Your existing setup will be different, but the example names and IP addresses will be used to demonstrate how to configure a DNS server to provide a functioning internal DNS. You should be able to easily adapt this setup to your own environment by replacing the host names and private IP addresses with your own. It is not necessary to use the region name of the datacenter in your naming scheme, but we use it here to denote that these hosts belong to a particular datacenter’s private network. If you utilize multiple datacenters, you can set up an internal DNS within each respective datacenter.

Our Goal

Continue reading Configure BIND as a Private Network DNS Server on Ubuntu 14.04

Ubuntu Applications

Ubuntu comes with many pre-installed applications, but if you require more, the Ubuntu Software Centre provides an excellent way to browse the additional applications which are available in the software repositories.

You can read more about managing applications in the Official Ubuntu Documentation (see the section on Adding and Removing Software) and the SoftwareManagement page.

Software repositories

To search for applications in the software repositories, either use

To read more about repositories, what they are and what the different repositories in Ubuntu are used for, see the Repositories page.

Continue reading Ubuntu Applications