How to Install phpMyAdmin on Ubuntu 18.04

Reading Time: 1 minute

Working with a database can be intimidating at times, but phpMyAdmin can simplify tasks by providing a control panel to view or edit your MySQL or MariaDB database.  In this quick tutorial, we’ll show you how to install phpMyAdmin on an Ubuntu 18.04 server.

 

Pre-flight

 

Step 1: Update the apt package tool to ensure we are working with the latest and greatest.

apt update && upgrade

 

Step 2: Install phpMyAdmin and PHP extensions for managing non-ASCII string and necessary tools.

apt install phpmyadmin php-mbstring php-gettext

During this installation you’ll be asked for the web server selection, we will select Apache2 and select ENTER.

In this step, you have the option for automatic setup or to create the database manually. For us, we will do the automatic installation by pressing ENTER for yes.

At this setup, you’ll be asked to set the phpMyAdmin password. Specifically for the phpMyAdmin user, phpmyadmin,  you’ll want to save this in a secure spot for later retrieval.

Step 3:  Enable PHP extension.

phpenmod mbstring

Note
If you’re running multiple domains on one server then you’ll want to configure your /etc/apache2/apache2.conf to enable phpMyAdmin to work.

vim /etc/apache2/apache2.conf

Add:

Include /etc/phpmyadmin/apache.conf

Step 4:  Restart the Apache service to recognize the changes made to the system.

systemctl restart apache2

 

Step 5: Verify phpMyAdmin installation by going to http://ip/phpmyadmin (username phpmyadmin).

Still having issues installing?  Our Liquid Web servers come with 24/7 technical support, contact us for a support team members help!

How to Setup Let’s Encrypt on Ubuntu 18.04

Reading Time: 3 minutes

Sites with SSL are needed more and more every day. It’s ubiquitious enforcement challenges website encryption and is even an effort that Google has taken up. Certbot and Let’s Encrypt are popular solutions for big and small businesses alike because of the ease of implementation.  Certbot is a software client that can be downloaded on a server, like our Ubuntu 18.04, to install and auto-renew SSLs. It obtains these SSLs by working with the well known SSL provider called Let’s Encrypt. In this tutorial, we’ll be showing you a swift way of getting HTTPS enabled on your site.  Let’s get started!

Pre-flight

 

Step 1: Update apt to ensure we are working with the latest package tool.

apt update && upgrade

 

Step 2: We’ll install the Certbot software, as this will aid in obtaining the SSL (certificates) from Let’s Encrypt.  Type Y when prompted to continue.

sudo apt install certbot

 

Step 3: Installing Certbot’s Apache package is also required. Type Y when prompted to continue.

apt install python-certbot-apache

 

Step 4: Time to attain the SSL from Let’s Encrypt.  Enter your email address and go through the prompts.  This step will look through your /etc/apache2/sites-available/yourdomain.com.conf file, specifically the website name set with the ServerName directive.

Note
If your installation gives the “Failed authorization procedure” message ensure you have followed the steps in the Apache Configuration article and that the A record is set for your domain.

certbot --apache

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A

Your choice to opt in to their newsletter.
-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o:

 

Jumping off of our Apache Configuratio tutorial, we want both of our domains covered with the option of www and non www for our visitors. We’ll leave the input blank and hit ENTER.

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: domain.com
2: www.domain.com
3: domain2.com
4: www.domain2.com
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

 

In our tutorial we will select the Redirect option, you may choose No redirect if you would still like your site reachable through HTTP.

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):2

 

A congratulation message will appear as well as instructions of where your SSL certificates are, just in case you need them later on.

- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/domain.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/domain.com/privkey.pem
Your cert will expire on 2019-07-16. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
Donating to EFF:                    https://eff.org/donate-le

 

Step 5: Verify your domain was issued the Let’s Encrypt SSL by visiting your site in the browser.  Be sure to clear your browser if you don’t readily see the SSL lock.

You now have an SSL encrypting the traffic to your site.  A few things to point out:

  • SSLs are valid for 90 days at a time
  • Let’s Encrypt will automatically renew
  • Any notifications from Let’s Encrypt will be sent to the email address specified in the .conf file

Get our fully Managed VPS servers, and you can control Let’s Encrypt through your WHM control panel.  Not only will you get a clean control panel to adjust server aspects but you also get 24/7 support at your fingertips.  See how our servers can make admin tasks easier!

How to Install Apache on a Windows Server

Reading Time: 4 minutes

When looking to host web sites or services from a Windows server, there are several options to consider. It is worth reviewing the strengths and weaknesses of each to determine which one is most likely to meet your particular needs before you spend the time installing and configuring a web service. Some of the most common web servers available for Windows services are Tomcat, Microsoft IIS (Internet Information Services), and of course the Apache server. Many server owners will choose to use a control panel which manages most of the common tasks usually needed to administer a web server such as e-mail and firewall configuration. At Liquid Web that option means you’re using one of our Fully Managed Windows Servers with Plesk. Alternately, some administrators who need more flexibility choose one of our Core or Self-Managed Windows Servers. This article is intended for the latter type of server with no Plesk (or other) server management control panel.

Pre-flight

This guide was written for 64-bit Windows since a modern server is more likely to use it. There are a few potential issues with Apache on Win32 systems (non 64-bit) which you should be aware of and can find here.

Downloading Apache:

While there are several mirrors to choose from for downloading the pre-compiled Apache binaries for windows, we’ll be using ApacheHaus for our purposes.

Download Here:

Apache 2.4.38 with SSL

(This is the 64-bit version with OpenSSL version 1.1.1a included.)

If you would like to use a different version they are listed here:

Available Versions Page

 

Install Apache on Windows

We will assume that you have installed all the latest available updates for your version of Windows. If not, it is important to do so now to avoid unexpected issues.

These instructions are adapted from those provided by ApacheHaus where we obtained the binary package. You may find the entire document in the extracted Apache folder under the file “readme_first.html”.

 

Visual C++ Installation

Before installing Apache, we first need to install the below package. Once it has been installed, it is often a good idea to restart the system to ensure any remaining changes requiring a restart are completed.

  1. Download the Visual C++ 2008 Redistributable Package and install it. It is located here.
    Note:
    Download the x64 version for 64 bit systems.
  2. Restart (optional but recommended).

 

Apache Installation

  1. Extract the compressed Apache download. While you can extract it to any directory it is a best practice to extract it to the root directory of the drive it is located on (our example folder is located in C:\Apache24). This is the location we will be using for these instructions. Please note that once installed you can see Apache’s base path by opening the configuration file and checking the “ServerRoot” directive).
  2. Open an “Administrator” command prompt. (Click the Windows “Start” icon, then type “cmd”. Right-click the “Command Prompt” item which appears, and select “Run As Administrator.”)
  3. Change to the installation directory (For our purposes C:\Apache24\bin).
  4. Run the program httpd.exe.
  5. You will likely notice a dialogue box from the Windows Firewall noting that some features are being blocked. If this appears, place a checkmark in “Private Networks…” as well as “Public Networks…”, and then click “Allow access.”
  6. As noted in the ApacheHaus instructions:

“You can now test your installation by opening up your Web Browser and typing in the address: http://localhost

If everything is working properly, you should see the Apache Haus’ test page.“

To shut down the new Apache server instance, you can go back to the Command Prompt and press “Control-C”.

  1. Now that you have confirmed the Apache server is working and shut it down, you are ready to install Apache as a system service.
  2. In your Command Prompt window, enter (or paste) the following command:

httpd.exe -k install -n "Apache HTTP Server"

Output:

Installing the 'Apache HTTP Server' service
The 'Apache HTTP Server' service is successfully installed.
Testing httpd.conf....
Errors reported here must be corrected before the service can be started.
(this line should be blank)

  1. From your Command Prompt window enter in the following command and press ‘Enter.’services.msc

Look for the service “Apache HTTP Server.” Looking towards the left of that line you should see “Automatic.” If you do not, double-click the line and change the Startup Type to “Automatic.”

  1. Restart your server and open a web browser once you are logged back in. Go to this page in the browser’s URL bar: http://localhost/

Configure Windows’ Firewall

To allow connections from the Internet to your new web server, you will need to configure a Windows Firewall rule to do so. Follow these steps:

  1.  Click the “Windows Start” button, and enter “firewall.” Click the “Windows Firewall With Advanced Security” item.
  2. Click “New Rule” on the right-hand sidebar.
  3. Select “Port,” and click Next. Select the radio button next to “Specific remote ports:” Enter the following into the input box: 80, 443, 8080

  4. Click Next, then select the radio button next to “Allow the connection.”
  5. Click Next, ensure all the boxes on the next page are checked, then click Next again.
  6. For the “name” section enter something descriptive enough that you will be able to recognize the rule’s purpose later such as: “Allow Incoming Apache Traffic.”
  7. Click “finish.”

  8. Try connecting to your server’s IP address from a device other than the one you are using to connect to the server right now. Open a browser and enter the IP address of your server. For example http://192.168.1.21/. You should see the test webpage.
  9. For now, go back to the windows firewall and right-click the new rule you created under the “Inbound Rules” section. Click “Disable Rule.” This will block any incoming connections until you have removed or renamed the default test page as it exposes too much information about the server to the Internet. Once you are ready to start serving your new web pages, re-enable that firewall rules, and they should be reachable from the Internet again.

That’s it! You now have the Apache Web Server installed on your Windows server. From here you’ll likely want to install some Apache modules. Almost certainly you will need to install the PHP module for Apache, as well as MySQL. Doing so is beyond the scope of this tutorial; however, you should be able to find a variety of instructions by searching “How to Install PHP (or other) Apache module on Windows server,” or similar at your favorite search engine.

 

Install and Configure Mod_Security on Ubuntu 16.04 Server

Reading Time: 5 minutes

Mod_security, also commonly called Modsec for short, is a powerful WAF (Web Application Firewall) that integrates directly into Apache’s module system. This direct integration allows the security module to intercept traffic at the earliest stages of a request. Early detection is crucial for blocking malicious requests before they are passed along to web applications hosted by Apache web sites. This provides and extra layer of protection against common threats a server faces. This article will explore the installation of mod_security along with the CRS (Core Rule Set) in a Ubuntu 16.04 LTS Server running Apache 2.4.

Prerequisites

The target system environment must meet the following requirements:

  • Ubuntu 16.04 LTS Server
  • Baseline Apache 2.4 pre-installed
  • Pre-configured Network & Internet Connection
  • Root user shell access (console or SSH)

Additionally, familiarity with the following system administration concepts are necessary:

 

Pre-Flight Checks

Mod_security is a standard module in many Apache-based OS images and may already be installed on the target system. Before we continue, lets first make sure we are running Apache 2.4 and mod_security is not already installed. This is done simply with the following two commands.

Note:
sudo is a prefix to all commands in this documentation. It allows execution of root-level permissions on a command by command basis. If you are not familiar with sudo, you may be prompted for your password to authorize execution one or more of the commands in this outline.

Check Apache’s Version

sudo apache2ctl -v

Example Output:
Server version: Apache/2.4.18 (Ubuntu)
Server built:   2018-06-07T19:43:03

Check if the Security Module is Active

apache2ctl -M | grep security

– If this command returns nothing, mod_security is not installed so proceed to the Installation Section.

– If the command returns security2_module, mod_security is installed so proceed to the Configuration Section.

 

Installation Section

The apt package manager in all Debian-based system (like Ubuntu) makes installation quick and painless. Supply the correct package name, libapache-modsecurity in this case, to the apt command and confirm the installation.

Use Apt to Install the libpache2-modseurity Plugin

sudo apt install libapache2-modsecurity -y

Example Output:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libapache2-mod-security2 libyajl2 modsecurity-crs
Suggested packages:
lua geoip-database-contrib ruby
The following NEW packages will be installed:
libapache2-mod-security2 libapache2-modsecurity libyajl2 modsecurity-crs
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 545 kB of archives.
After this operation, 3,960 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 libyajl2 amd64 2.1.0-2 [19.6 kB] Get:2 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 libapache2-mod-security2 amd64 2.9.0-1 [314 kB] Get:3 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 libapache2-modsecurity all 2.9.0-1 [2,006 B] Get:4 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 modsecurity-crs all 2.2.9-1 [210 kB] Fetched 545 kB in 0s (1,659 kB/s)
Selecting previously unselected package libyajl2:amd64.
(Reading database ... 92965 files and directories currently installed.)
Preparing to unpack .../libyajl2_2.1.0-2_amd64.deb ...
Unpacking libyajl2:amd64 (2.1.0-2) ...
Selecting previously unselected package libapache2-mod-security2.
Preparing to unpack .../libapache2-mod-security2_2.9.0-1_amd64.deb ...
Unpacking libapache2-mod-security2 (2.9.0-1) ...
Selecting previously unselected package libapache2-modsecurity.
Preparing to unpack .../libapache2-modsecurity_2.9.0-1_all.deb ...
Unpacking libapache2-modsecurity (2.9.0-1) ...
Selecting previously unselected package modsecurity-crs.
Preparing to unpack .../modsecurity-crs_2.2.9-1_all.deb ...
Unpacking modsecurity-crs (2.2.9-1) ...
Setting up libyajl2:amd64 (2.1.0-2) ...
Setting up libapache2-mod-security2 (2.9.0-1) ...
apache2_invoke: Enable module security2
Setting up libapache2-modsecurity (2.9.0-1) ...
Setting up modsecurity-crs (2.2.9-1) ...
Processing triggers for libc-bin (2.23-0ubuntu11) ...

Once installed, it’s a simple matter to confirm the security module is being loaded by Apache:

Check if the Security Module is Active

apache2ctl -M | grep security

Example Output:

security2_module (shared)

 

Configuration Section

Now that the base module is installed, we need to configure and enable it. This requires a few steps:

Step 1) Copy the recommended config over as the live config

sudo cp /etc/modsecurity/modsecurity.conf{-recommended,}

Step 2) Modify the live config and change “SecRuleEngine DetectionOnly” to “SecRuleEngine On”

sudo sed -i -e 's/DetectionOnly$/On/i' /etc/modsecurity/modsecurity.conf

Step 3) Check Apache’s config syntax & restart Apache if OK

sudo apache2ctl -t && sudo apache2ctl restart

Example output:

Syntax OK

Apache is now actively running with mod_security in place. However, there are no rules in place for it. The next section goes over configuring these rules.

 

Enable Core Rule Set & Base Rules

The security module is only as good as the rules governing it. To help get started, the libapache2-modsecurity package comes with a companion package (modsecurity-crs). This package contains the Core Rule Set or CRS, which is a basic set of rules that handle some of the most common malicious activity on the Internet today.  The CRS protects against many dangerous types of traffic include, but not limited to:

  • SQL Injections (SQLi)
  • Remote Code Execution (RCE)
  • Cross Site Scripting (XSS)
  • And many other common malicious behavior

 

The CRS gets installed along with the security module. Follow these next steps to enable CRS & it’s Base Rules.

Step 1) Add the following lines to modsecurity.conf with your preferred editor

# ModSecurity Core Rule Set (CRS)
IncludeOptional /usr/share/modsecurity-crs/*.conf
IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf

Step 2) Create a symlink in the activated_rules directory for all *.conf files in the base_rules directory

CSRD=/usr/share/modsecurity-crs; for e in $CSRD/base_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done

Step 3) [Optional] Confirm symlinks are in the activated_rules directory

sudo ls /usr/share/modsecurity-crs/activated_rules/*.conf

/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_20_protocol_violations.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_21_protocol_anomalies.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_23_request_limits.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_30_http_policy.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_35_bad_robots.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_40_generic_attacks.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_41_xss_attacks.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_42_tight_security.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_45_trojans.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_47_common_exceptions.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_49_inbound_blocking.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_50_outbound.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_59_outbound_blocking.conf
/usr/share/modsecurity-crs/activated_rules/modsecurity_crs_60_correlation.conf

Step 4) Check Apache’s config syntax & restart Apache if OK

sudo apache2ctl -t && sudo apache2ctl restart

Example output:

Syntax OK

The server is now configured and actively using the base_rules from the CRS. There are additional rules provided by the CRS package. These additional rules are discussed in greater detail in the next section.

Rule of Thumb:
It is necessary to verify syntax and restart Apache, anytime changes are made to one or more mod_security rules.

 

Enable Additional Rules [Optional]

The Core Rule Set includes many additional rules. These rules are separated into three distinct categories: experimental_rules, optional_rules, and slr_rules. Each category’s rules are contained within their own directory of the same name. Activating these rules is the same process as enabling the base_rules. Create a symlink to the desired rule from the activated_rules directory.  The following commands can be used to quickly enable these rules if needed.

Caution:
Discernment is warranted when enabling additional rules beyond those in the base_rules set. The additional rules, especially experimental_rules, are more likely to encounter false positives, blocking legitimate traffic. The commands below are provided for convenience and is not an endorsement of enabling all rules indiscriminately.

experimental_rules

CSRD=/usr/share/modsecurity-crs; for e in $CSRD/experimental_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done

optional_rules

CSRD=/usr/share/modsecurity-crs; for e in $CSRD/optional_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done

slr_rules

CSRD=/usr/share/modsecurity-crs; for e in $CSRD/slr_rules/*.conf; do sudo ln -s $e $CSRD/activated_rules/; done

 

Disable Rules

To disable rules, delete the symlink within the activated_rules directory that pertains to the rule in question. Once deleted, a quick restart of Apache services is necessary to make the change active.

Example: Delete the application_defects rule then restart Apache.

sudo rm -rf /usr/share/modsecurity-crs/activated_rules/modsecurity_crs_55_application_defects.conf

sudo apache2ctl restart

 

The Most Helpful Humans In Hosting

There is more than one-way Liquid Web can help. Whether it’s contacting our support or providing you the managed services you need to succeed, you can rely on us to be there with you. If you find yourself having trouble with these instructions our support teams are here to help. We pride ourselves on being  The Most Helpful Humans In Hosting™.  Our support teams work diligently with Apache and Mod_security daily. With availability 24 hours a day, 7 days a week, and 365 days a year, we are always available to assist when your tasks become too arduous to tackle on your own. We encourage you to share the burden with our support teams by phone, chat or email. We can help!

 

Fully Managed Servers & Applications

All of the Liquid Web Fully Managed Servers & Applications come with mod_security installed, configured, and managed by our support teams. In addition to the Core Rule Set packaged with mod_security, all of our fully managed server kicks include our very own Liquid Web internal rules. These additional rules protect against further threats that our security engineers have identified attacking servers in the wild. These additional rules are a direct countermeasure against known attack vectors and update when new attacks have been identified. We take care of it all, so you don’t have to worry.

 

 

Server Protection Packages

When standard security is not enough, you don’t have to wage war alone. The Liquid Web Server Protection Packages provides additional server hardening beyond just mod_security rules. These packages offer hardened configurations to maintain the best level of protection against intrusion and other malicious activity. This is merely one of our many security-related Hosting Add-on Services.

How to Install PHP 7.2 on Ubuntu 16.04

Reading Time: 5 minutes

Using PHP 7.2 on an Ubuntu server is highly recommended over previous PHP versions for several reasons, first being security. Active Support for PHP 7.2 goes until November 30th, 2019 and Security Support until Nov 30, 2020. Older versions like 7.0 and anything 5.6 and below are no longer getting any support and can leave open security holes on a server if they are not replaced. Another main reason to upgrade is the big performance increase over previous versions when PHP 7.2 is installed and is using the OPcache module.  This can greatly decrease the time it takes for your webpage to load! If you are developing a site locally or launching it on one of Liquid Web’s Ubuntu VPS or Dedicated Servers, using PHP 7.2 or newer would be the way to go.

Continue reading “How to Install PHP 7.2 on Ubuntu 16.04”

Install Poweradmin on Ubuntu 16.04

Reading Time: 3 minutes

What is Poweradmin?

Poweradmin is a web-based graphical user interface to interact with PowerDNS. It is released under the open source GPL license. It makes it easy to create and edit zone files and interacts directly with the SQL server. Poweradmin has full support for most PowerDNS features, including all zone types (master, native and slave), supermasters, for automatic provisioning of slave zones and full support for A, AAAA, CNAME, HINFO, MX, NS, PTR, SOA, SRV and TXT record types, validation against RFC’s. It also has user and permission management setup for controlling user permissions with templates.  In this tutorial, we’ll be showing you how to install and configure Poweradmin as well as some records.

Continue reading “Install Poweradmin on Ubuntu 16.04”

Apache Performance Tuning: Configuring MPM Directives

Reading Time: 3 minutes

 

Our previous article in this series focused on defining and fitting MPM to match your environment.  Building off of our last tutorial we will be discussing specific details on how to adjust the previously mentioned Apache configuration directives on the various types of Liquid Web servers.  

Continue reading “Apache Performance Tuning: Configuring MPM Directives”

Apache Performance Tuning: MPM Directives

Reading Time: 12 minutes

How directives behave and which directives are mainly available hinges on the loaded MPM. As discussed in our previous series, MPM is short for MultiProcess Modules, and they determine the basis for how Apache addresses multiprocessing. Using our last article on Apache MPM Modules as a springboard, we will use this section to cover the following subsections:

Each part will focus on how the directives affect performance for their respective MPM and some common considerations that should be assessed when optimizing Apache with those specific MPMs.

Note:
Be sure to review this article in its entirety as the universal directives operate in the same manner regardless of the MPM chosen.

 

General Optimization

IfModule

An important directive to learn when working with Apache servers is the IfModule conditional statement. There are two parts to the IfModule statement. A beginning, which also accepts a module name or module source file name, as well as a closing statement. When the provided module is loaded into Apache, then all directives between the beginning IfModule statement and the closing IfModule statement are also read into the Apache running configuration. Please review the provided example below for further clarification:

 

<ifModule mpm_prefork_module>
MaxSpareServers 16
</ifModule>
Timeout 60
The above example defines the MaxSpareServers directive only when loaded by mpm_prefork_module. The Timeout directive is applied every time due to it being outside of the IfModule closing statement.

 

IfModule statements are used to maintain compatibility within Apache configuration between module changes. Maintaining compatibility is done by grouping directives into IfModule statements, so they are only used when the required module is loaded. Ensuring a syntactically correct configuration file even when swapping modules.

Rule of Thumb:
Appropriately wrapping everything in an IfModule statement is a best practice standard with Apache and should be adhered to for superior compatibility in config files.

Timeout

The numerical value of seconds Apache waits for all common I/O events. Apache will abandon requests fail to complete before the provided Timeout value.

Determining the right Timeout depends on both traffic habits and hosted applications. Ideally, Timeout should be as low as possible while still allowing the vast majority of regular traffic to operate without issue. Large timeouts, those above 1 minute, open the server to SlowLoris style DOS attacks and foster a long wait in the browser when it encounters a problem. Lower timeouts allow Apache to recover from errant stuck connections quickly. It becomes necessary to strike a balance between the two extremes.

Tip:
Avoid increasing the global Timeout when addressing issues with a single script, or user, that requires a long Timeout. Problems can usually be resolved by a .htaccess file or include file to increase the Timeout directive for that specific script.

KeepAlive

KeepAliveA simple on|off toggle enables the KeepAlive protocols with supported browsers. The KeepAlive feature can provide as much as a 50% reductions in latency, significantly boosting the performance of Apache. KeepAlive accomplishes this by reusing the same initial connections a browser creates when connecting to Apache for all follow-up requests which occur within a short period.

KeepAlive is a powerful feature and in general, should be enabled in most situations. It works great for reducing some of the CPU and Network overhead with modern element heavy websites. For example, an easy way to visualize KeepAlive is with the “hold the door” phrase. Imagine a queue of people entering a building through a single doorway. Each person is required to open the door, walk through it, then close the door before the next person does the same process. Mostly, that’s how Apache works without KeepAlive. When enabled, the door stays open until all the people in line are through the door before it closes again.

Two additional related directives also govern KeepAlive. MaxKeepAliveRequests and KeepAliveTimeout. Discussed in the next section, each one plays a vital role in fine-tuning of the KeepAlive directive.

 

MaxKeepAliveRequests

Sets a limit on the number of requests an individual KeepAlive connection is permitted to handle. Once reached, Apache forces the connection to terminate, and creates a new one for any additional requests.

Determining an ideal setting here is open to interpretation. Generally, you want this value to be at least as high as the largest count of elements (HTML, Text, CSS, Images, Etc..) served by the most heavily trafficked pages on the server.

Rule-of-Thumb:
MaxKeepAliveRequestsSet MaxKeepAliveRequests to double that of the largest count of elements on common pages. (Services like webpagetest.org or gtmetrix.com can count elements on a page).

KeepAliveTimeout

This directive is measured in seconds and will remain idle waiting for additional requests from its initiator. Since these types of connections are only accessible to their initiator, we want to keep KeepAliveTimeout very low. A low value prevents too many KeepAlive connections from locking out new visitors due to connection priority.

Tip:
KeepAliveTimoutA large MaxKeepAliveRequests directive with a very low KeepAliveTimeout allows active visitors to reuse connections while also quickly recovering threads from idle visitors.
Configuration: Set MaxKeepAliveRequests to 500+, Set KeepAliveTimeout to 2
Requirements: Works best on MPM Event.

MPM Event/Worker Optimization

This section details the use and performance considerations that are essential when running Worker based MPMs, including both MPM Event and MPM Worker. These MPMs are considered multi-threaded solutions and some directives behave differently based on the loaded MPM. The information provided in this section is only a portion about Worker based MPMs.

Note:
In Worker based MPMs: ServerLimit, ThreadsPerChild, and MaxRequestWorkers are intrinsically linked with each other. It is essential to understand the role of each one and how changing one affects the others. The following directives govern the fine-tuning of the thread handling capabilities of Apache web servers.
MPM Worker and MPM Event

The two modules, MPM Event, and MPM Worker for most intents and purposes operate identically. The difference is apparent in the way each handles KeepAlive requests. The MPM Worker locks threads for the duration of the KeepAlive process and directly affects the number of available threads able to handle new requests. The MPM Event uses a Listener thread for each child. These Listener threads handle standard requests, and KeepAlive requests alike meaning thread locking will not reduce the capacity of the server. Without thread locking, MPM Event is the superior choice but only in Apache 2.4. Before Apache 2.4 the MPM Event was unstable and prone to problems.

ServerLimit

ServerLimit represents the upper limit of children Apache is allowed. The practical usage for ServerLimit is creating a hard ceiling in Apache to protect against input errors with MaxRequestWorkers. The cap prevents spawning vastly more children than a system can handle, resulting in downtime, revenue loss, reputation loss or even data loss.ServerLimit

ServerLimit ties in directly with the thrashing point discussed earlier in this article. The thrashing point is the maximum number of children Apache can run before memory usage tips the scale into perpetual swap. Match the ServerLimit to the calculated thrashing point to safeguard the server.

 

ThreadsPerChild

Used to define the limit of threads that each Apache child can manage. Every thread running can handle a single request. The default of 25 works well for most cases and is a fair balance between children and threads.ThreadsPerChild

There is an upper limit on this directive as well, and the limit is controlled by the ThreadLimit directive, which defaults to 64 threads. The adjustments to increase ThreadsPerChild past 64 threads also need to be made to ThreadLimit.

Increasing this value allows each child to handle more requests keeping memory consumption down while allowing a larger MaxRequestWorkers directive. A key benefit of running more threads within each child is shared memory cache access. Threads from one child cannot access caches from another child. Boosting the number of threads per child squeezes out more performance due to this sharing of cache data. The major downside for increased threads per child occurs during child recycling. The capacity of the server is diminished by the number of threads configured for each child when that child process is eventually recycled (graceful restart).

MPM Event/Worker

Inversely the opposite reaction is achieved by lowering ThreadsPerChild. Fewer threads per child require more children to run an equal amount of MaxRequestWorkers. Since children are full copies of Apache, this increases Apache’s overall memory footprint but reduces the impact when recycling children. Fewer threads mean fewer potential “stuck” threads during the recycle procedure, keeping the higher capacity of requests available overall children. Having fewer threads per child provides increased shared memory isolation. For instance, dropping ThreadsPerChild to 1 gives the same request isolation of MPM Prefork but also inherits its massive performance tax as well, requiring one child per one request.

Tip:
When setting ThreadsPerChild always consider the server environment and hardware.

  • A memory-heavy shared server hosting numerous independent accounts might opt for a lower ThreadsPerChild, reducing the potential impact of one user affecting another.
  • A dedicated Apache server in a high capacity load balanced configuration can choose to increase ThreadsPerChild significantly for a better overall performance of each thread.

ThreadLimit

Used to set the maximum value of ThreadsPerChild. This directive is a hard ceiling for ThreadsPerChild. It helps protect against typographical errors with the ThreadLimit
ThreadsPerChild directive which could quickly spin a server out of control if too many threads are allowed due to an input error. This setting need to be adjusted in some high-end servers when the system needs more than the default of 64 threads per child.

MaxRequestWorkers / MaxClients

The directive sets the limit for active worker threads across all running children and acts as a soft ceiling with ServerLimit taking control as the hard limit. When the number of total running threads has reached or exceeded MaxRequestWorkers, Apache no longer spawns new children.MaxRequestWorkers/MaxClients

Determining the MaxRequestWorkers is a critical part of server optimization. An optimal setting is based on several changing variables. This means its configuration needs to be reevaluated and tailored periodically over time, changed by watching traffic habits and system resource usage. The Apache status Scoreboard is an effective tool for analysis of Apache performance.

 

It is typical of Worker based MPM systems to run an isolated third-party PHP handler like Mod_fcgid, PHP-FPM, and mod_lsapi. These modules are responsibleMPM Event/Worker2

for processing PHP code outside of Apache and frees up Apache to handle all other non-PHP requests such as HTML, TEXT, CSS, Images, etc… These requests are far less taxing on server resources which allows Apache to handle larger volumes of requests, such as those beyond 400 MaxRequestWorkers.

MinSpareThreads

The least number of Threads that should remain open, waiting for new requests. MinSpareThreads is a multiple of ThreadsPerChild and cannot exceed MaxSpareThreads, though it can match it.

Rule-of-Thumb:
Set MinSpareThreads to equal 50% of MaxRequestWorkers.

Spare threads are idle workers threads. These threads are merely waiting for new incoming requests and are governed by the Apache child process that spawned them. If there are less available threads than MinSpareThreads, The Apache parent will generate a new child with another ThreadsPerChild worth of threads.

MinSpareThreads

MaxSpareThreads

This directive governs the total number of idle threads allowed on the server across all children. Any threads above this limit direct their parent to shut down to reduce memory consumption during off-peak hours.MaxSpareThreads

Having a limit to the number of idle open threads is excellent for smaller servers with hardware constraints. However, it mostly unneeded on today’s modernizing hardware.

Tip:
Configuring Apache as an open throttle is a high-performance configuration for servers with significant RAM and multiple CPU cores. When running the open throttle configuration, all available threads become available at all time. Apache’s memory usage will stay near its peak at all times, a side effect due to running all the configured children into memory preemptively. This configuration will produce the best possible response times from Apache by maintaining persistent open connections ready to do work and removing the overhead of spawning new processes in response to traffic surges.

Configuration: Match both MinSpareThreads and MaxSpareThreads to MaxRequestWorkers.

Requirements: Make sure there is enough server RAM to run all MaxRequestWorkers at once.

StartServers

This directive governs the initial amount of children the Apache Parent process spawns when the Apache service is started or restarted. This is commonly left unchanged since Apache continuously checks the current running children in conjunction with ThreadsPerChild and compare it to MinSpareThreads to determine if more children get forked. This process is repeated perpetually, with a doubling of new children on each iteration, until MinSpareThreads is satisfied.

Rule-of-Thumb:
StartServerManually calculating StartServers is done by dividing MaxRequestWorkers by ThreadsPerChild, rounding down to the nearest whole number. This process forces all children to be created without delay at startup and begins handling requests immediately. This aspect is especially useful in modern Apache servers which require periodic restarts to load in directive changes.

MaxConnectionsPerChild / MaxRequestsPerChild

The number of requests a single Apache child process can handle equals a cumulative total on the child server across all threads it controls. Each request handled by a thread counts toward this limit to its parent. Once the child server has reached its limit, the child is then recycled.
This directive is a stop-gap for accidental memory leaks. Some code executed through Apache threads may contain memory leaks. Leaked memory are portions of memory that subprocess failed to release properly, so they are inaccessible to any outside processes. The longer a leaking program is left running, the more memory it will leak. Setting a MaxConnectionsPerChild limit is a specific method for assuring Apache is periodically recycling programs to reduce the impact of leaked memory on the system. When using external code handlers like Mod_fcgid, PHP-FPM or mod_lsapi, it becomes necessary to set MaxConnectionsPerChild to 0 (unlimited), doing so prevents periodic error pages caused by Apache terminating threads prematurely.

Rule-of-Thumb:
MaxConnectionsPerChild/MaxRequestsPerChild If the server encounters a memory leak never set the MaxConnectionsPerChild / MaxRequestsPerChild too low, instead start with 10,000 and reduce it incrementally.

 

MPM Prefork Optimization

This MPM Prefork section details the use and performance considerations for various directives when running this module. This MPM is a non-threaded multi-processor designed for compatibility. It consists of a single Apache parent process, which is used to govern all new Apache processes also known as children. The following directives show how Apache is capable of performance tuning when using MPM Prefork. Unlike Worker based MPMs, optimizing MPM Prefork is generally simple and straightforward. There is a 1:1 ratio of Apache processes to incoming requests. However, MPM Prefork does not scale well with hardware and the more traffic it encounters, the more hardware it will need to keep up with the pace. It should be noted that some directives behave differently based on which MPM is loaded. The information provided in this section is only the portion about MPM Prefork.

MaxRequestWorkers / MaxClients

Used to control the upper limit of children that the Apache parent server is allowed to have in memory at one time. These children (also called workers) handle requests on a 1:1 ratio. This translates into the maximum number of simultaneous requests the server can handle.

MaxRequestWorkers / MaxClientsIf this directive is too low, Apache under-utilizes the available hardware which translates to wasted money and long delays in page load times during peak hours. Alternatively, if this directive is too high, Apache outpaces the underlying hardware sending the system into thrashing (link to thrashing article) scenario which can lead to server crashes and potential data loss.

 

MinSpareServers

This directive defines a minimum number of spare children the Apache parent process can maintain in its memory. An additional server is a preforked idle Apache child that is ready to respond to a new incoming request. Having idle children waiting for new requests is essential for providing the fastest server response times. When the total idle children on the server drop below this value, a new child is preforked at the rate of one per second until this directive is satisfied. The “one per second” rule is in place to prevent surges of the creation process that overload the server, however, this failsafe comes at a cost. The one per second spawn rate is particularly slow when it comes to handling page requests. So it’s highly beneficial to make sure enough children are preforked and ready to handle incoming requests.

 

Rule of Thumb:
MinSpareServers Default settingNever set this to zero. Setting this to 25% of MaxRequestWorkers ensures plenty resources are ready and waiting for requests.

MaxSpareServers

MasSpareServers controls the maximum number of idle Apache child servers running at one time. An idle child is one which is not currently handling a request but waiting for a new request. When there are more than MaxSpareServers idle children, Apache kills off the excess.

If the MaxSpareServers value is less than MinSpareServers, Apache will automatically adjust MaxSpareServers to equal MinSpareServers plus one.

Like with MinSpareServers, this value should always be altered with available server resources in mind.

Rule of Thumb:
MaxSpareServersSet this to double the value of MinSpareServers.
Tip:
Configuring Apache as an open throttle is a high-performance configuration for servers with significant RAM and multiple CPU cores. When running the open throttle configuration, all available Apache children become available at all times. As a side effect of running open throttle, the Apache memory usage will stay near its peak at all times, due to running all the configured children into memory preemptively. This configuration will produce the best possible response times by maintaining persistent open connections. Furthermore, in response to traffic surges, it removes the overhead that comes from spawning new processes.
Configuration: Match both MinSpareServers and MaxSpareServers to MaxRequestWorkers.
Requirements: Make sure there is enough server RAM to run all MaxRequestWorkers at once.

StartServers

Created at startup, are the initial amount of Apache child servers.

This seldom changed directive only impacts Apache startup and restart processes. Generally not altered because Apache uses internal logic to work out how many child servers should be running.

Many modern servers periodically restart Apache to address configuration changes, rotate log files or other internal processes. When this occurs during a high load traffic surge, every bit of downtime matters. You can manually set the StartServers directive to mirror that of your MinSpareServers to shave off time from the Apache startup.

Rule of Thumb:
StartServersThe StartServers directive should mirror that of MinSpareServers.

 

ServerLimit

The ServerLimit directive represents the upper limit of MaxRequestWorkers. This setting is generally used as a safeguard or ceiling against input errors when modifying MaxRequestWorkers.ServerLimit Default Setting

It becomes necessary to adjusted ServerLimit when the server is expected to handle more than the default of 256 requests simultaneously.

ServerLimit ties in directly with the thrashing point. The thrashing point is the maximum number of children Apache can run before memory usage tips the scale into perpetual swap. Match the ServerLimit to the calculated thrashing point to safeguard the server.

Note:
Increasing ServerLimit is not recommended with MPM Prefork. Running more than 256 simultaneous requests is hardware intensive when using the MPM Prefork module.

ThreadsPerChild Default Settings

MaxConnectionsPerChild / MaxRequestsPerChild

This directive equals the number of requests a single Apache child server can handle.

This directive is a stop-gap for accidental memory leaks. Code executed through Apache may contain faults which leak memory. These leaks add up over time making less and less of the shared memory pool of the child usable. The way to recover from leaked memory is to recycle the affected Apache child process. Setting a MaxConnectionsPerChild limit will protect from this type of memory leakage.

Note:
MaxConnectionsPerChild/MaxRequestsPerChild Rule-of-Thumb: Never set this too low. If the server encounters memory leak issues start with 10,000 and reduce incrementally.

 

Apache Performance Tuning: MPM Modules

Reading Time: 3 minutes

The keystone for understanding Apache server performance is by far the MultiProcessing Modules (MPMs). These modules determine the basis for how Apache addresses multiprocessing. Multiprocessing means running multiple operations simultaneously in a system with multiple central processing units (CPU Cores).

There are many MPMs to choose; however, this article focuses on the most commonly used modules found in Liquid Web Linux based servers. These modules are:

The self-regulating MPM Prefork derives its namesake from how it forks or copies itself into new identical processes preemptively to wait for incoming requests. A non-threaded process-based approach at multiprocessing, MPM Prefork runs Apache in a single master parent server process. This parent is responsible for managing any additional child servers that make up its serverpool. While using MPM Prefork, each child server handles only a single request. This focus provides complete isolation from other requests dealt with on the server. MPM Prefork is typically used for compatibility when non-threaded libraries/software, like mod_php (DSO), are required. From an optimization standpoint, MPM Prefork can be sorely lacking when compared to multi-threaded solutions, requiring vastly more resources to reach similar traffic levels as a threaded MPM. It is resource intensive due to its need to spawn full copies of Apache for every request.

MPM Prefork

Rule-of-Thumb:
Avoid using MPM Prefork whenever possible. It’s inability to scale well with increased traffic will quickly outpace the available hardware on most system configurations.

 

A hybrid pre-forking, multithreaded, multiprocessing web server. In the same fashion as MPM Prefork, MPM Worker uses the same approach with a single master parent process governing all children within its serverpool. However, unlike MPM Prefork, these children are multi-threaded processes that can handle dozens of threads (requests) simultaneously. MPM Worker has set the foundation for multithreaded multiprocessing in Apache servers which became stable in Apache 2.2. The threaded configuration allows Apache to service hundreds of requests with ease while retaining only a dozen or so child processes in memory. The MPM Worker make for both a high capacity and low resource solution for web service.

MPM Worker

Note
The KeepAliveTimeOut directive currently defines the amount of time Apache will wait for requests. When utilizing KeepAlive with MPM Worker use the smallest KeepAliveTimeout as possible (1 second preferably).

Based off the MPM Worker source code, MPM Event shares configuration directives with MPM Worker. It works nearly identical to MPM Worker except when it comes to handling KeepAlive requests. MPM Event uses a dedicated Listener thread in each child process. This Listening thread is responsible for directing incoming requests to an available worker thread. The Listening thread solves the issue encountered by MPM Worker which locks entire threads into waiting for the KeepAliveTimeout. The Listener approach of MPM Event ensures worker threads are not “stuck” waiting for KeepAliveTimeout to expire. This method keeps the maximum amount of worker threads handling as many requests as possible.


MPM EventMP

Tip:
MPM Event is stable in Apache 2.4, older versions can use MPM Worker as an alternative.

There is an assortment of additional MPMs available. These are typically part of Apache’s integration into Operating Systems other than Unix based systems. These have specific MPMs which are requirements or utilizing Apache on their respective system types. These types of MPMs are beyond the purview of this article. You can find more information on specific MPM in the MPM Defaults section of the official Apache Documentation.

MPM EventMP

Tip:
We recommend staying away from experimental and unstable MPMs. The unreliable nature of these types of software renders them unsupportable.

 

When considering optimization, it is essential to understand there is no such thing as a one-size-fits-all Apache configuration. Correctly choosing an MPM requires analysis of many moving variables like traffic, site code, server type, PHP Handler and available hardware. Every server is unique making the best MPM an entirely subjective choice.

If your application code does not support multi-threading, then your choice will inevitably be MPM Prefork purely on a compatibility basis. MPM Prefork includes software modules like mod_php (DSO). MPM Worker without KeepAlive performs very well if your application is a high-performance load balanced API system. The scalability and flexibility of MPM Event is a solid choice for hosting multiple small to medium sites in a shared hosting configuration.

Most simple servers setups operate well under the self-governing default configuration of MPM Event, making it an ideal starting point for optimization tuning. Once chosen, an MPM can then move onto Configuration Directives to review which settings pertain to server performance and optimization. Or check out our previous article in this series, Apache Performance Tuning: Swap Memory.