How to Convert .htaccess Rules to NGINX Directives

Reading Time: 6 minutes

NGINX is a webserver that is becoming an increasingly popular option for webhosting, as sixteen percent of all sites on the internet are utilizing NGINX. This percentage is constantly increasing as clients are in need of a web server that can serve content faster. It can also be used for proxies, reverse proxies, load balancing, and more depending on what modules you load onto NGINX. One of the significant differences between Apache (a popular webserver) and NGINX is the way each system handles access rules. If you are familiar with using .htaccess rules in Apache, then the method that NGINX uses of including directives in the server’s vhost block will be substantial change.

We will be showing how to convert .htaccess rewrite rules to NGINX rewrite directives. The NGINX rewrite directives will also need to be placed within the server block. Many server configurations include this server block information in the vhosts file, while some use a separate NGINX configuration file (for more information about the NGINX configuration file, see Redirecting URLs Using NGINX). To complete this task, you will need to understand some of the basic NGINX directives I will be discussing in the next session.

Introduction to NGINX Rewrite and Return Directives

The most commonly used directives with NGINX are the return and rewrite directives. When using an NGINX directive, a client visiting a page can be directed to a different directory or a different landing page. Requests can also be redirected to an application depending on the directives you specify. For example, clients visiting the page from a smartphone can be forwarded to a script that is coded specifically for phone browsers. Another example would be to forward a client based on IP or geographical location, making your site region specific and tailored to the visitor based on location.

NGINX Return Directive

The return directive is a bit less complicated than the rewrite directive. Best practice is to use this directive over the rewrite directive whenever possible. You will typically include the return in a server context that specifies the domains to be rewritten. I have included a common example below. Clients visiting the site will be redirected to the domain specified after the 301 status code. Using this directive will forward the client that visits www.liquidwebtest.com to www.liquidweb.com.

server {
listen 80;
server_name www.liquidwebtest.com;
return 301 $scheme://www.liquidweb.com$request_uri;
}

  • Server { } is defining the block
  • Listen “what port to listen to”
  • Server_name “defining the incoming requested URL”
  • Return “what the server returns from this request”

NGINX Rewrite Directive

The rewrite directive is somewhat different that the rewrite rules in .htaccess. It needs to be placed in a specific location or server block in order to rewrite the URL. The rewrite directive is usually used to perform smaller tedious tasks. For example, it is used in some cases to capture elements in the original URL or change elements in the path. The NGINX rewrite directive can get very complicated but once you understand the basic syntax it can be a lot less intimidating. I have included the basic syntax for a NGINX rewrite directive below.

rewrite regex URL [flag];
It is important to know a rewrite directive will almost always return a HTTP 301 or 302 status code. If you need your web server to return a different status code, the return directive is needed after the rewrite. I have included an example below from NGINX’s rewrite module documentation.

server{
...
rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra last;
return 403;
...
}

In this example the URLs that start with /download followed by /media or /audio are matched. Afterwards directories /media and /audio elements that contain /mp3 will have the extension .mp3 or .ra file extension added to the URL. This return directive will return a 403 to the client if the URL does not match the rewrite rule.

Converting .htaccess rules to NGINX directives

Hopefully by this point we have a basic understanding of the two most commonly used NGINX directives. However, learning these rules will take some time as the can be very complex. Learning regular expression is very helpful in this process. We’ll work through examples of commonly used htaccess rules that we will be converting to NGINX directives.

Example: Redirecting from example.com to www.example.com

Adding the www to a URL when a client requests content from your server can help certain sites (like those hosted on WordPress) to function more efficiently. A common .htaccess rule to accomplish this rewrite is:

RewriteCond %{HTTP_HOST} example.com
RewriteRule (.*)https://www.example.com$1

As I mentioned earlier it is best practice to use the return directive whenever possible. Below we will be creating a server block within the nginx.conf to accomplish the same task as the .htaccess rewrite rule above.

server {
listen 80;
server_name example.com;
return 301 http://www.example.com
$request_uri;
}
server {
listen 80'
server_name www.example.com;
#...
}

In this example there will be two server blocks defined with brackets” {}”. We are telling NGINX to listen on port 80 for requests to example.com. Then to return a 301 ”redirection” to www.example.com. We usually split these rules in two server blocks to make these directives as efficient as possible. The 2nd is not always needed but will serve content from the working directory if www.example.com is requested. If no exact match is found, NGINX then checks to see if there is a server_name with a starting wildcard that fits. The longest match beginning with a wildcard will be selected to fulfill the request.

You can test your syntax by running the following command:

nginx -t

This allows you to test the syntax for errors before loading the changes in the configuration file and possibly causing issues on your live site. Once you have edited the NGINX configuration file be sure to restart NGINX using a daemon or simply running the command below.

nginx -s reload

Example: WordPress Permalinks

In this example, I have included one of the most common set of .htaccess rules used today. The rules I have included below allow wordpress to utilize permalinks. This is installed by default with wordpress on an Apache server. A permalink is a URL that is intended to remain unchanged. For example, domainexample.com/blogexample.php can be loaded as domainexample.com/blog within your browsers address bar.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L] RewriteCond ${REQUEST_FILENAME} ~ - f
RewriteCond ${REQUEST_FILENAME} ~ - d
RewriteRule . /index.php [L] <IfModule>

Belowis the NGINX equivalent. No return or rewrite directive is needed here as we are only allowing the content management system to hide the paths using permalinks. For more information on this task please see NGINX’s documentation on permalinks.

location / {
try_files $uri $uri/ /index.php?$args;
}

You can test your syntax by running the following command:

nginx -t

This allows you to test the syntax for errors before loading the changes in the configuration file and possibly causing issues on your live site. Once you have edited the NGINX configuration file be sure to restart NGINX using a daemon or simply running the command below.

nginx -s reload

Example: Forcing http to https

Another popular use for the htaccess file is to force the browser to load the site using https over http. This allows the browser to verify the site is not a security risk by confirming the site exists on the server it claims to be on (see What Is an SSL Certificate?). It can also be used to verify a business location, business ID number, and location. This helps prevent visiting malicious sites that may cause harm to your personal computer or private information.

The following .htaccess rule will force https, so that requests using port 80 for example.com will be redirected to https://www.example.com.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC] RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

To accomplish this with NGINX, we will use the NGINX return directive.

server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}

You can test your syntax by running the following command:

nginx -t

This allows you to test the syntax for errors before loading the changes in the configuration file and possibly causing issues on your live site. Once you have edited the NGINX configuration file be sure to restart NGINX using a daemon or simply running the command below.

nginx -s reload

Conclusion
We could go on and on with examples but hopefully at this point we now have a basic understanding on converting htaccess for Apache to NGINX directives. If you require further information on accomplishing these tasks you can always reach out to our support for assistance. However, we do not fully support NGINX and it is considered Beyond Scope support. This means we will assist you as much as possible but we may not be able to resolve your issue and may instead refer you to a developer for additional assistance. If you want to use NGINX web server to host your content, we have multiple options including our VPS lineup to meet your business requirements. NGINX is currently being developed for use on cPanel servers as well, although it is not currently supported or recommended in production situations. See cPanel’s blog for more information.

An Intro to React JS

Reading Time: 6 minutes

In our modern world of smartphones and apps, it is more important than ever to have a fast, responsive website that impresses your visitors. Created by the development team at Facebook, ReactJS is a JavaScript ‘framework’ or method of building web pages and apps that can ‘react’ to user interaction and external changes. ReactJS does this by way of components that can refresh themselves and their contents without a page reload. Better still, these components are modular. This concept means they can be coded quickly (called ‘hacking’ in the ReactJs community) and reused easily between projects.

While programming React JavaScript code is outside the scope of this tutorial, we are happy to help you and your development team hit the ground running by creating a development environment. Our focus is on getting the official ReactJS tutorial example running on a Liquid Web WHM/cPanel Virtual Private Server or VPS. Servers built on our VPS platform work well as development/testing servers and can be easily created. Feel free to spin one up to follow along with me today!

A dedicated server may provide more stability for your application over the long term once development has been completed. If your application is HIPAA related, you will need a dedicated server with HIPAA compliance. The differences between the VPS and Dedicated Server platforms can be found in our Knowledge Base article. Addtionally, ReactJS can also be installed on our Plesk, Windows, and Ubuntu platforms. Let’s get started!

Install NodeJS

First, we will need to install the latest version of NodeJS; This application allows our JavaScript files to import (or reference) each other, share global variables, access advanced command-line arguments, install additional modules and more.

At the time of writing, the latest version of NodeJS is 11.X Always use the most up-to-date software to ensure the stability and safety of your applications. Today we will be downloading and installing the latest version.

First, we log into our terminal and set up the NodeSource repository :

curl  -sL https://rpm.nodesource.com/setup_11.x | bash -

Next, we install NodeJS and its dependencies :

yum  install  -y nodejs  gcc-c++ make

To verify the installation and check the version, we run :

node --version

Install Serve

ReactJS Apps can be served by Apache or by the lightweight “Serve” application. Serve can run alongside Apache/Nginx accomplished by running Serve on an alternate port.

To install Serve globally, we run the following command :

npm install -g serve

In this tutorial, we will be running this application on a newly created cPanel account. but it can also run on any existing account. Our cPanel username in this example is ‘react’, and our development folder meant to house our source code will be named ‘dev’. This dev folder will sit our cPanel account’s root folder (/home/react/dev). A folder can be created via File Manager or FTP, but in this example, we are doing this via the command line :

mkdir /home/react/dev/

Install ReactJS

Our next step is to use the application ‘create-react-app’ command to build the framework and install the necessary prerequisites. No need to worry about updating ‘create-react-app’, this application updates automatically when run.

This command requires a path to build properly. In our example we are running the following to build in our dev folder.

npx create-react-app /home/react/dev

The create-react-app process can take a few minutes, but it will keep you updated of progress like so :

When completed, you’ll see an overview of some important development commands and a warm welcome into the ReactJS Community.

The create-react-app script generated the above files for us with default content. With that, you and your developers can begin the development process.

Note
Three main components of a ReactJS application are:

  • .html files; These provide the structure to your app.
  • .css files; These contain the styling for your app content.
  • .js or Javascript Files; These provide app functionality.

Run ReactJS Default Application

While Liquid Web Support is not able to assist with code-related issues, in this tutorial, we will be going a step further by launching the default application. Finally, we’ll be reviewing and launching the ReactJS ‘tic-tac-toe game’ tutorial application.

First, let’s confirm that ReactJS is running by building the default application. We want to be in the command line and our working folder.

cd /home/react/dev/Run the following code to have React build the default package contents.

npm  run build

There are a few options here, by default if we use ‘Serve’ it will use port 5000;  This is run by calling the following :

serve -s build

Note
You may notice the error regarding ‘xsel’. That application is used to copy from command line to a Linux Desktop Environment or GUI (Gnome, KDE, Mate among others). In our case, our Linux server is not using a Desktop Environment, so we do not need nor could we use the xsel library so we’ll ignore the error.

Viewing ReactJS Default App

To have our app available to the outside world, we will need to ensure that port 5000 is open in the firewall; Though this port is not open by default we can adjust that easily;

We are looking for the section called ‘Opening and Closing Ports in the Firewall’. Once implemented, you’ll see the default ReactJS application running in the browser. We do not own the domain ‘react.com’ so we will need to adjust our /etc/hosts file locally on our workstation. More information on editing your /etc/hosts files can be found here.

If you own your domain and your site’s DNS ‘A’ Record pointing to the Liquid Web server IP this should also be visible to you. The default ReactJS screen looks like this if everything is configured and running properly.

Run ReactJS

It is possible to run ReactJS applications over the typical Apache or Nginx ports; Please note, running ReactJS with Serve over port 80 means Apache or Nginx would need to be disabled. If the primary focus of your server is to handle this application, Apache can be disabled server-wide. Serve is a very lightweight application and works very well. If you do not have another service running on port 80; The following command will start ‘Serve’ on port 80.

PORT=80 serve -s build

The above can be adjusted to a different port as well. In this way, multiple ReactJS applications can be run on the same domain. In addition to this, Apache can serve your ReactJS application as static content. To do so, we would need to copy the contents of our application’s /build folder to the desired location within the directory configured for web delivery.

In our case, we will be copying /home/react/dev/build to /home/react/public_html. This can be done on the command line with :

cp -r  /home/react/dev/build  /home/react/public_html

Depending on how you built the application package, you may need to adjust the permissions of your files. In our case, the ownership of these files was set to ‘root’. In response to this, we are changing the ownership to ‘react’.

In this example, we are going to be adjusting all files in the public_html folder to be owned by the user ‘react’ with the following command :

chown  -R react.  /home/react/dev/public_html/*

To have Apache serve the above, we are going to be adjusting the .htaccess configuration in our project.

vim /home/react/public_html/.htaccess

With our text editor, we are going to be adding the following :

Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]

If everything is configured correctly, you should now see the contents of your application as delivered by the Apache service when visiting your site. You now know the basics of how to get the default ReactJS environment running on a Liquid Web Linux WHM/cPanel VPS Server!

Example ReactJS Application

We are going one step further here by going over a tutorial. This tutorial goes over every aspect of getting started with ReactJS with great detail into programming some components needed to get a running tic-tac-toe game. We advise going line by line through the code as well as the documentation. With this knowledge, you can build your own application. The best source for ReactJS syntax and concepts can be found in their documentation. Feel free to take your time going through these examples and documentation; There is a lot to go through, but you can start small and build your way up. Today we are going to copy the contents of the Final Code to see how they run on our Liquid Web Server.

There are multiple ways to adjust the contents of index.html, index.css, and index.jss files. While outside of the scope of this tutorial, you can use other command line text editing tools, FTP, cPanel ‘s File Manager tool, Git  and many more to edit files. In our case, we are using the cPanel File Manager’s Text Editor. A walkthrough of this interface and how to edit files can be found here.

First, we open the File Manager, navigate to the location of our file /home/react/dev/public/index.html, then we select the index.html file ( 1 ) and click“Edit” ( 2 )

We are going to be copy-pasting the code from CodePen into our server-side files.

Second, we do the same with /src/index.css.

Finally, we copy paste the contents of /src/index.js.

At the top of the index.js file, we add some needed code; This is necessary for referencing the React installation and our CSS files.

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';

With all three files copied over, we are going to rebuild our project. To rebuild, we will go back to our development folder and rerun our build script. With that, we can test by serving our new build with our serve script. By visiting react.com:5000 we see our tic-tac-toe game live on our Liquid Web server!

In conclusion, we went over what ReactJS offers developers, installed ReactJS along with customization. WIth the official documentation, you now have all you need to build out your dream application. We cannot wait to see what you have in mind!

 

The Best Settings for Configuring FastCGI (mod_fcgid)

Reading Time: 5 minutes

In our last tutorial, we showed you how to install Apache’s mod_fcgid and provided Linux scripts to assist in transitioning from mod_php. In this next section, we’ll be discussing how to configure a baseline setting for PHP optimization. Continue reading “The Best Settings for Configuring FastCGI (mod_fcgid)”

How to Install mod_fcgid on cPanel’s EasyApache 4 with CloudLinux

Reading Time: 6 minutes

When it comes to PHP execution, mod_fcgid (also called FCGI) is one of the heavyweight contenders. There are a few rival handlers, like PHP-FPM or mod_lsapi, which come close to matching its execution speed, but they generally leave something to be desired when it comes to fine-tuning and resource consumption. FCGI is built for speed and includes a myriad of Apache directives that can be leveraged for resource regulation.

This article will cover installing mod_fcgid followed by basic configuration in a separate article. The article applies to any cPanel servers running the following operating systems:

The article will not cover EasyApache 3 (EA3). Due to the End-of-Fife (EOL) status of EA3, it is imperative that any systems running EA3 upgrade to EA4 as soon as possible. To avoid conflicts, upgrading to EA4 should be handled as an entirely separate procedure from installing mod_fcgid. If you need assistance with upgrading from EA3 to EA4, please feel free to contact our support team. If you’re running a Liquid Web Fully Managed cPanel server, our team will perform the entire upgrade procedure for you.

Expectations: Downtime & Performance

Downtime – Please plan ahead of time as this operation may cause downtime. While installing an Apache module and enabling a baseline configuration should only require an Apache restart, there may be unforeseen circumstances that require troubleshooting. This can lead to sites becoming unresponsive and/or slow.

Note
Always plan for more downtime than expected and always have a reversion plan. Allot extra time for troubleshooting, testing, and reverting all changes if necessary.

Performance – While FCGI provides superior PHP execution time, it is not a blanket fix for performance. For server optimization there will be an adjustment period for configuration tweaking.This period can take hours to weeks as it must account for the unique caveats with the specific server hardware, software, traffic habits, and many other unpredictable variables.

Note
Optimization is an ongoing, perceptual process. There is no one-size-fits-all optimized configuration. Traffic & resource usages continually change over time on all servers. Periodic evaluation and configuration adjustment are necessary to stay ahead of the curve.

 

Installation of mod_fcgid

The following steps should be followed as close to the examples as possible. Things will vary slightly depending on CentOS/CloudLinux versions, and a few other factors. The article will denote the differences where they are expected.

Step 1) [su_highlight background="#3ac6eb"]Liquid Web Servers Only[/su_highlight] Disable Mod_Zeus & Other EA3 Modules

Older Liquid Web cPanel servers with EasyApache 3 who upgraded to EA4 may find residual configs on the system that can cause conflicts in the Apache configuration. This step will help make sure these older configs are disabled. The following sed one-liner will take care of disabling the inclusion line for these modules. These modules are stored in the /usr/local/lp/configs/httpd/conf.d/ directory. This directory is typically mentioned in the /etc/apache2/conf.d/includes/post_virtualhost_global.conf config file. The sed code looks for and comments out the specific include statement for this file.

sed -i -e 's/[^#]+\(Include [/]usr[/]local[/]lp[/]configs[/]httpd[/]\)/#\1/g' /etc/apache2/conf.d/includes/post_virtualhost_global.conf

To confirm the change, print the contents of the post_virtualhost_global.conf file using cat:

cat /etc/apache2/conf.d/includes/post_virtualhost_global.conf

The output should be blank or have a commented out inclusion line like below:

#Include /usr/local/lp/configs/httpd/conf.d/*.conf

Step 2) Disable Litespeed

FCGI is not compatible with Litespeed, which uses its own mod_lsapi module to process PHP using lsphp. Disabling Litespeed in this way does not remove it from the server; it merely enables Apache as the default web server.

/usr/local/lsws/admin/misc/cp_switch_ws.sh apache

Step 3) Install mod_fcgid

The following yum command will install the necessary module:

yum install ea-apache24-mod_fcgid -y

Once completed, confirm Apache has the fcgid_module loaded:

httpd -M | grep expires\|version\|fcgid

Example output:

fcgid_module (shared)

Step 4) [su_highlight background="#3ac6eb"]CloudLinux Only[/su_highlight] Configure CageFS Map for FCGI

The following snippet will create the necessary directories needed by mod_fcgid to execute correctly. It will then add those directory entries into the /etc/cagefs/cagefs.mp file, allowing user-level access to said directories from within their caged environment. It finally forces cagefs to remount all user directories for access to the new directory on all sites.

mkdir -p /var/run/mod_fcgid /usr/share/cagefs-skeleton/var/run/mod_fcgid /run/mod_fcgid
cp -p /etc/cagefs/cagefs.mp{,.lwbak.$(date +%F_%H%M%S)}
cat <<EOF>>/etc/cagefs/cagefs.mp
/var/run/mod_fcgid
/run/mod_fcgid
/usr/local/cpanel/cgi-sys/
EOF
cagefsctl -M

Step 5) [OPTIONAL] Remove Unnecessary Writable Permission

Due to security restrictions, any website files or directories with group-writable or other-writable permissions will be denied and a 500 Internal Server Error will be displayed. The following awk one-liner uses the find command to search all DocumentRoot directories configured on the server. It is advised to run this process in a screen session as it may take an hour or more depending on the size of the file system in question. The code takes care to use nice and ionice commands to run the process as a low priority so there will be minimal impact on server load or disk I/O. All changed files and their previous permissions are recorded in the /var/log/fixperms.log file.

Step 5a) Create & Attach to a Screen Session

screen -dmS fixperms; screen -x fixperms

Step 5b) Run the One-Liner

nice -n 15 ionice -c2 -n7 awk '/DocumentRoot/{DR[$NF]=$NF}END{for (e in DR) {x="find \""e"\" \\( -type f -or -type d \\) -and -perm /g+w,o+w -printf \"%M %y %m %p\\n\" -exec chmod g-w,o-w {} +"; while(x|getline) {print $0;print strftime("%F %T %Z"),$0 >> "/var/log/fixperms.log"} close(x)}}' /etc/apache2/conf/httpd.confExit screen by holding CTRL/CMD then pressing A, then D.

 

Step 6) [OPTIONAL] Disable mod_php Directives in .htaccess Files

Another common caveat when switching to FCGI is that any existing mod_php related directives inside any .htaccess file are not compatible with mod_fcgid and will cause the site to throw a 500 Internal Server Error. So these entries need to be located and disabled or removed.  The following awk one-liner checks all configured DocumentRoot directories for .htaccess files, and if they contain a php_value or php_admin_value entry, it will disable by commentting the line out. First, an in-place backup is created of the original file. The backup is named .htaccess.bak.YYYY-MM-DD_HHMMSS. All changed files and their previous permissions are logged in the /var/log/fixhtaccess.log file.

Step 6a) Create & Attach to a Screen Session

screen -dmS fixhtaccess; screen -x fixhtaccess

Step 6b) Run the One-Liner

nice -n 15 ionice -c2 -n7 awk '/DocumentRoot/{DR[$NF]=$NF}END{for (e in DR) { x="find "e" -name .htaccess -exec grep -iEl \"^([^#]*php_(admin_)?value)\" {} +"; s="sed -i.bak.$(date +%F_%H%M%S) \047s/^\\([^#]*php_\\(admin_\\)\\?value\\)/#\\1/gi\047 2>&1";
while(x|getline) {print $0; print s,$0; print strftime("%F %T %Z"),s,$0 >> "/var/log/fixhtaccess.log"; while(s" "$0|getline y) { print y; print strftime("%F %T %Z"),y >> "/var/log/fixhtaccess.log" } close(s" "$0)} close(x)}}' /etc/apache2/conf/httpd.conf

Step 7) Rebuild Apache Config (Troubleshoot Any Errors)

The following command checks the system httpd.conf file for syntax error and if none are found, runs the cPanel httpd.conf rebuild script. Fix any syntax errors, until a clean rebuild is completed without error.

httpd -t && /scripts/rebuildhttpdconf

Step 8) [su_highlight background="#3ac6eb"]CloudLinux ONLY[/su_highlight] Setup PHP Selector

The PHP Selector feature of CloudLinux is only compatible with the inherit PHP versions in the cPanel MultiPHP Manager interface. All sites should be using the inherited version of PHP or PHP Selector will not function for that site. This only applies to CloudLinux servers.

Step 8a) Force All Sites to Use Inherited Version of PHP in MultiPHP Selector

The following command uses cPanel’s whmapi1 system to force all sites onto the inherited version of PHP in MultiPHP Manager.

/usr/sbin/whmapi1 php_get_vhost_versions | awk  -F'[: ]+' '$2~/vhost/{x="/usr/sbin/whmapi1 php_set_vhost_versions version=inherit vhost-0="$3;print x;system(x);close(x)}'

Step 8b) Disable MultiPHP Manager & MultiPHP INI Editor

The following uses the cPanel whmapi1 system to add MultiPHP Manager/INI Editor to the disabled features list.

/usr/sbin/whmapi1 update_featurelist featurelist=disabled multiphp=1 multiphp_ini_editor=1 ; /usr/sbin/whmapi1 update_featurelist featurelist=disabled multiphp_ini_editor=1

Step 9) Switch All PHP Handlers over to FCGI

The following will convert all installed PHP Handlers to using FCGI. These handlers are viewalbe through the Handlers tab of WHM’s MultiPHP Manager interface or by running the cPanel rebuild_phpconf script.

/usr/local/cpanel/bin/rebuild_phpconf --current | awk 'NR>1{x="/usr/local/cpanel/bin/rebuild_phpconf --"$1"=fcgi"; print x; system(x);
close(x)}'

To confirm the changes, run:

/usr/local/cpanel/bin/rebuild_phpconf --current

Example Output:

DEFAULT PHP: ea-php71
ea-php54 SAPI: fcgi
ea-php55 SAPI: fcgi
ea-php56 SAPI: fcgi
ea-php70 SAPI: fcgi
ea-php71 SAPI: fcgi
ea-php72 SAPI: fcgi

Step 10) Perform a Full Stop & Restart of Apache

The following script will stop Apache (gracefully if possible), and kill any unresponsive Apache & PHP processes before starting the Apache service again. It will also verify the Apache configuration syntax and will only perform the restart procedure if the syntax returns ok. This technique is handy as it is common for Apache processes to get stuck from time to time on busy servers.  This snippet deals with those scenarios after performing the humane stop request first.

httpd -t && (/scripts/restartsrv_apache stop; sleep 3; killall httpd php lsphp php-cgi; sleep 3; killall -9 httpd php lsphp php-cgi; /scripts/restartsrv_apache start) || echo Fix Apache Config and try again.

Note
Toss this snippet into an alias called apache_rescue which you can add to your ~/.bashrc for easy access to this code. Below is a one-liner that will create this alias for you and load the modified profile in your current session. Once this alias is installed, it will always be available on that  server by typing apache_rescue.

cat <<'EOF'>>~/.bashrc && source ~/.bashrc
alias apache_rescue='httpd -t && (/scripts/restartsrv_apache stop; sleep 3; killall httpd php lsphp php-cgi; sleep 3; killall -9 httpd php lsphp php-cgi; /scripts/restartsrv_apache start) || echo Fix Apache Config and try again.'
EOF

This concludes our ten step process for installing mod_fcgid onto your cPanel system.  It’s recommended to adjust FCGI settings from their default settings. Tune into our next tutorial where we’ll be advising on how to optimize FCGI for various environments.

How to Install Nextcloud 15 on Ubuntu 18.04

Reading Time: 2 minutes

Similar to Dropbox and Google Drive, Nextcloud is self-hosting software that allows you to share files, contacts, and calendars. But, unlike Dropbox and Google Drive, your files will be private and stored on your server instead of a third party server. Nextcloud is HIPAA and GDPR compliant, so your files will be encrypted along with the ability to audit. For this tutorial, we’ll be installing our Nextcloud instance on our Ubuntu 18.04 LTS server. Continue reading “How to Install Nextcloud 15 on Ubuntu 18.04”

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. Continue reading “How to Install phpMyAdmin on Ubuntu 18.04”

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! Continue reading “How to Setup Let’s Encrypt on Ubuntu 18.04”

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. Continue reading “Install and Configure Mod_Security on Ubuntu 16.04 Server”