Tag: Part

Welcome to the last part of the CentOS 7 LAMP Server Tutorial: Modernized and Explained! In this article, we will turn our LAMP server into an LEMP server by removing Apache and installing NGINX (pronounced "Engine X") in its place.

Why would we want to replace the Apache web server with NGINX? The answer is simultaneity. NGINX can simultaneously handle more connections than Apache without causing additional work for the server. It can be used as a standalone web server or as a "buffer" or "buffer" between Apache and the rest of the Internet. In this tutorial, we will replace the Apache web server with a stand-alone installation of NGINX. Let's start!

Preparation for change

If you followed our series, you now have a WordPress website running Apache with PHP 7.3 and a Let Encrypt SSL certificate. Apache serves the non-SSL site on port 80 and the SSL site on port 443. NGINX also wants to listen on port 80 and port 443, because these are the ports that HTTP and HTTPS always use. We can not use NGINX alternate ports because no web browser would ever find it. The solution is to disable or remove Apache, and then configure NGINX for it.

In the second part, we have configured Apache with a VirtualHost that tells Apache where to serve our WordPress site. NGINX will need a similar configuration to use our website. We will also need to tell NGINX how to use Let's Encrypt's SSL certificate.

We will make some drastic changes to the configuration in this tutorial. Therefore, a cautionary statement is required: Back up your data, and do not do it on a production server. If you already have an operational website that brings you income or is important to you, stop. We have every interest in getting a second VPS server, going through the entire tutorial, and then setting up a test site. Once you're sure it works for you, migrate your site to your new NGINX-based server.

Delete Apache

Always with us? Awesome! It will be fun. As mentioned before, we need to eliminate Apache so that NGINX can do its job. There are two ways to do this: stop and disable Apache or simply delete Apache. We will remove it. This is easily done with one command:

yum -y remove httpd

Here's how it was on our low-end VPS:

You will notice that Yum has also removed mod_ssl (Apache SSL module) and the Let'Encrypt SSL certbot for Apache. We will replace them with the NGINX equivalents in the next step.

Install NGINX

NGINX can be installed directly from the Centos 7 Yum base repositories, but some features that we will need are missing. We will use a repository managed by someone with the user name "error". Do not worry, there are no mistakes! We need to install this repository before installing NGINX. Here is the command to use:

curl -o /etc/yum.repos.d/nginx-error.repo 
https://copr.fedorainfracloud.org/coprs/error/nginx/repo/epel-7/error-nginx-epel-7.repo

What about SSL Certificates of Let Encrypt? In part 3 of this series, we learned that certbot uses its Apache module to request and intelligently install Let'Encrypt SSL certificates. But as we move to NGINX, we need to install the similar NGINX module for certbot.

The following command will install the updated version of NGINX and the NGINX certbot module:

yum-yo install nginx python2-certbot-nginx

Here is what it looked like on our VPS:

We will now enable NGINX to start at startup and start for the first time:

systemctl enable nginx.service
systemctl start nginx

You may notice that we do not do anything with PHP. This is because we had previously configured PHP-FPM for PHP 7.3. PHP-FPM is independent of the web server. We can use any web server to communicate with PHP-FPM via its Unix socket. We will configure this communication very soon. For the moment, you should see the following page when you go to your website:

If you do not see this page, go back and check your work. It's probably something small.

Configuring NGINX to replace Apache

Originally, we had configured Apache with a VirtualHost configuration so that it could serve files for our virtually hosted website. NGINX has the same functionality, but NGINX calls them "server blocks" instead of "virtual hosts." And just like Apache, we can create a directory that only applies to the configuration files specific to each hosted website.

Let's start by creating the necessary directory, then save the default nginx.conf file (the main NGINX configuration file) before creating our own files.

mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
mkdir / etc / nginx / sites-enabled

We will now use "nano" to create two files: /etc/nginx/nginx.conf and /etc/nginx/sites-enabled/lowend.conf. The nginx.conf file contains guidelines for the entire server, where lowend.conf contains the server block and configuration information specific to our website. Copy and paste these configuration files. Be sure to read them completely because they explain the entire configuration. The comments are really part of this tutorial.

nano /etc/nginx/nginx.conf

Paste the following configuration file:

nginx user;
auto worker_processes;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/nginx/README.dynamic.

include /usr/share/nginx/modules/*.conf;

events {
worker_connections 1024;
}

http {
log_format main $ remote_addr - $ remote_user [$time_local] "$ request" & # 39;
& # 39; $ status $ body_bytes_sent "$ http_referer" & # 39;
& # 39; "$ http_user_agent" "$ http_x_forwarded_for" & # 39 ;;
access_log /var/log/nginx/access.log main;
log_format cache_status & # 39;[$time_local] "$ request" $ upstream_cache_status & # 39 ;;
access_log /var/log/nginx/cache.log cache_status;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
keepalive_requests 1024;

include /etc/nginx/mime.types;
default_type application / octet-stream;

#Enable the NGIXN fastcgi cache in / var / run / nginx-cache and configure the cache keys.

fastcgi_cache_path / var / run / nginx-cache levels = 1: 2 keys_zone = nginx-cache: 100 m inactive = 60 m;
fastcgi_cache_key "$ scheme $ request_method $ host $ request_uri";

# Add X-Cache headers to HTTP requests. This allows us to see if the cached content is served.
# If the cached content is served, the header will contain the value "HIT", otherwise "MISS".

add_header X-Cache $ upstream_cache_status;

# Detect a connected WordPress user cookie
# This is used in the server block to bypass the cache for connected WordPress users.
map $ http_cookie $ logs_in {
default 0;
~ SESS 1;
~ wordpress_logged_in 1;
}

# Enable storage of individual server blocks in / etc / nginx / site-enabled
# and still be included in the NGINX configuration.

include /etc/nginx/sites-enabled/*.conf;

}

We will now create the server block for our website:

nano /etc/nginx/sites-enabled/lowend.conf

Paste the following configuration file:

server {

# We will start by enabling GZIP compression for the server
gzip on;
gzip_types text / plain text / css application / json application / x-javascript text / xml application / xml application / xml + rss text / javascript application / vnd.ms-fontobject app / x-font-ttf font / opentype image / svg + xml image / x-icon;
gzip_proxied no-cache no-store private expir auth;
gzip_min_length 1000;

#This Server Block listens on port 80 for HTTP requests
listen to 80;

# Set the host names for this server block, separated by a space
server_name lowend-tutorial.tld www.lowend-tutorial.tld;

# Set the root document that NGINX will serve the pages of the site.
root / home / lowend / public_html;

#Look for index.php. If you want to add index.html or any other default page, add it here.
index.php index;

# Set the log file for the account
access_log /home/lowend/logs/lowend-tutorial.tld-access.log main;

# Do not log in to favicon.ico
location = /favicon.ico {
log_not_found off;
access_log off;
}

# Do not connect the robots.txt file
location = /robots.txt {
authorize everything;
log_not_found off;
access_log off;
}

location / {
# includes the "? $ args" part so that non-default permanent links do not break when using a query string
try_files $ uri $ uri / /index.php?$args;

Cache cache #Bypass for connected WordPress users
#This is important so that caching does not hinder the development
fastcgi_cache_bypass $ logs_in;
fastcgi_no_cache $ logs_in;
}

location ~  .php $ {
try_files $ uri = 404;
# Connect to PHP-FPM for fastcgi PHP calls
# This is the NGINX equivalent of the previously used Apache fastcgi directives
fastcgi_pass unix: /var/run/php73-fpm/php73-fpm.lowend.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_scriptname;
include fastcgi_params;

#Use the nginx-cache defined in nginx.conf
fastcgi_cache nginx-cache;
fastcgi_cache_valid 200 60m;
}

# Set a maximum timeout for different types of files, and do not save 404 for them
location ~ * . (js | css | png | jpg | jpeg | gif | ico) $ {
expires max;
log_not_found off;
}
# Configure the cache purge. This will allow us to use a small shell script to purge the cache every hour.
location ~ /purge(/.*) {
allow 127.0.0.1;
Deny all;
fastcgi_cache_purge nginx-cache "$ scheme $ request_method $ host $ 1";
}

}

We can now restart NGINX to activate the new configuration:

systemctl restart nginx

NGINX and Let's Encrypt

In the previous steps, we removed the certbot-apache module and installed the certbot-nginx module. The new module does the same thing for NGINX as certbot-apache for Apache. We will use the certbot-nginx module to reinstall our certificate with the following command:

certbot --nginx

Since there is already a certificate, we can select the option "1: Try to reinstall this existing certificate"

We also need to update our cron job for certificate renewal. Edit the crontab with the following command:

crontab -e

Edit the configuration so that it looks like the following line:

1 * / 12 * * * certbot --nginx renew

Check your work

You should now be able to load your WordPress website into a browser. Otherwise, please check all the previous steps and consult the NGINX error logs.

With this restart, NGINX is fully configured for your WordPress site. Caching is enabled and when you are connected to WordPress, NGINX will bypass the cache so you can easily see your changes.

Clearing the cache

We have configured a way to clear the NGINX cache by calling a URL with HTTP "PURGE" instead of "GET". This is a great way to do it. In fact, we have installed the customized version of NGINX just to enable this feature. But there is a minor problem. At the time of writing this article, no NGINX cache plugin for WordPress actually works when it empties the cache with the help of the "PURGE" method. They require that PHP have direct access to NGINX cache files, which poses a security risk: all sites share the same cache directory, and the PHP-FPM instance of each site would have access to another site cache. It's not safe at all!

To remedy this, we will use wp-cli to give us a list of all the articles and pages of your WordPress site, then pass it to a "for" loop that calls CURL to create an HTTP request that purges the cache. of each post or page. We will do this in a very simple shell script. This script should not be placed in the public_html directory, but should be managed and maintained by the user of the website. The username of our website is "lowend" and this file will go to / home / lowend /. We used the following command to create the file:

sudo -u lowend nano /home/lowend/flush.sh

Paste in the following script. Make sure to correct the URL so that it matches your site:

#! / bin / bash
#Use wp-cli to find all pages and articles and use CURL to issue a
# HTTP PURGE to clear the cache of each page and publish.
for page in
$ (/ usr / local / bin / wp --path = / home / lowend / public_html publications list --post_type = page, post --format = csv --field = job name)
do curl --silent --output / dev / null -X PURGE -I "https: //lowend-tutorial.tld/$page"
completed

Now set the permissions to 755:

chmod 755 /home/lowend/flush.sh

We want to empty the cache regularly, so we will create a cron job that will execute our flush.sh script every hour:

crontab -e -u lowend

Paste in the following cron job:

1 * * * * /home/lowend/flush.sh

Finally, log in to your WordPress website and delete all caching plugins. Instead, we will install a plugin called "Redis Object Cache" by Till Krüss. Install and activate the script, which will cache objects via Redis, while NGINX will cache pages. It is an excellent configuration.

And with that, it's over! Our tests showed that we could answer about 30% more requests per second with this configuration. Depending on your VPS, you may be able to do the same thing or much more.

The end is only a beginning

This tutorial marks the conclusion of the LAMP Server series. We hope you found it informative! What you learned by building your own server from scratch will help you understand and appreciate what's happening behind the scenes when you use a control panel that manages the configurations for you. They really save a lot of work! But even more, you've learned how virtual hosting works, configuring PHP, and using basic Linux tools to administer your server.

What other things could you do? Instead of configuring NGINX as we did in this tutorial, why not leave Apache configured and learn how to configure NGINX as a caching proxy server? Learn how to create multiple websites by creating new users and new virtual hosts or server blocks (or both, as the case may be). Tired of building configuration files from scratch every time? Learn a tool like Ansible that will do all the work for you. The possibilities are limitless. This may be the end of this series, but this is just the beginning for someone who is ready to continue learning. Enjoy!