Continue reading “How to Start and Enable Firewalld on CentOS 7”
In this article and related video, we will be discussing how to check the kernel version in both Ubuntu and CentOS Linux. The following command works with all Linux distributions, such as Red Hat, CentOS, Debian, and Ubuntu. It also works on other UNIX-like operating systems such as HPUX, FreeBSD, OpenBSD, Solaris, etc. Use the following command to check which kernel version your server is currently running:
Continue reading “How To Check the Kernel Version in Linux / Ubuntu / CentOS”
cPanel is a server control panel which allows users the ability to access and automate server tasks and, provides the tools needed to manage the overall server, their applications, and websites. 
Some features include the capability to modify php versions, creating individual cPanel accounts, adding FTP users, installing SSL’s, configuring security settings, and installing packages to name a few. cPanel and WHM have a vast range of customizations and configurations that can be completed to further personalize your platform specifically for your needs. It also includes 24/7 support from cPanel as well.
When purchasing a server from Liquid Web, we offer several images your server can be built from. We offer these images on most of our hosting products, including, dedicated servers, cloud dedicated servers, and our VPS offerings. Another bonus is that cPanel is supported out of the box on our fully managed servers. Our staff is well versed in providing assistance as well. Our automated install process will install and setup cPanel on your server. If you happen to have a cPanel license or are utilizing cPanel’s free trial, then please continue reading as we will be discussing how to install and setup cPanel on a CentOS 6 or 7 Linux box.
Today we will be reviewing the major differences between CentOS and Ubuntu in a web hosting environment. Although this is not a fully comprehensive analysis of every single aspect of the numerous in-depth features of each operating system, it should provide a solid overview which will allow you to choose which system is best suited for your needs. Without further ado, let’s jump right in…
Continue reading “CentOS vs Ubuntu: 15 Factors to Consider!”
While managing your server, you’ll sometimes need to check on which software (or packages) you have installed on your system. You’ll need to know package names, version numbers, dates of installation, etc. In this Liquid Web tutorial, we’re going to be discussing how to inspect packages installed on your CentOS system. There are several ways to accomplish this, and we’ll discuss a few of them. Let’s dig in! To use these commands, you’ll need to log in to your server via SSH. For more information, see Logging into Your Server via Secure Shell (SSH).
Continue reading “How to Check for Installed Packages on CentOS”
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!
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
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/
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.
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
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.
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!
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!
Have other thoughts or questions about this topic? Our Sales and Support teams are available 24 hours a day and can be reached via phone or e-mail to assist. Open a support ticket with us today at support@liquidweb.com, giving us a call at 1-800-580-4985 or, open a chat with us and we’ll be happy to answer any questions you may have!
With the shortage of available address space in IPv4, IPs are becoming increasingly difficult to come by, and in some cases, increasingly expensive. However, in most instances, this is not a drawback. Servers are perfectly capable of hosting multiple websites on one IP address, as they have for years.
But, there was a time when using an SSL certificate to secure traffic to your site required having a separate IPv4 address for each secured domain. This is not because SSLs were bound to IPs, or even to servers, but because the request for SSL certificate information did not specify what domain was being loaded, and thus the server was forced to respond with only one certificate. A name mismatch caused an insecure certificate warning, and therefore, a server owner was required to have unique IPs for all SSL hosts.
Luckily, IPv4 limitations have brought new technologies and usability to the forefront, most notably, Server Name Indication (SNI).
Secure Socket Layer (SSL) certificates allow two-way encrypted communication between a client and a server. This allows any data protection from prying eyes, including sensitive information like credit card numbers or passwords. SSLs are optionally signed by a well-known, third-party signing authority, such as GlobalSign. The most common use of such certificates are to secure web traffic over HTTPS.
When browsing an HTTPS site, rather than displaying a positive indicator, modern browsers show a negative indicator for a site that is not using an SSL. So, websites that don’t have an SSL will have a red flag right off the bat for any new visitors. Sites that want to maintain reputation are therefore forced to get an SSL.
Luckily, it is so easy to get and install an SSL, even for free, that this is reduced to a basic formality. We’ll cover the specifics of this below.
Server Name Indication is a browser and web server capability in which an HTTPS request includes an extra header, server_name, to which the server can respond with the appropriate SSL certificate. This allows a single IP address to host hundreds or thousands of domains, each with their own SSL!
SNI technology is available on all modern browsers and web server software, so some 98+% of web users, according to W3, will be able to support it.
We’ll be working on a CentOS 7 server that uses Nginx and PHP-FPM to host websites without any control panel (cPanel, Plesk, etc.). This is commonly referred to as a “LEMP” stack, which substitutes Nginx for Apache in the “LAMP” stack. These instructions will be similar to most other flavors of Linux, though the installation of Let’s Encrypt for Ubuntu 18.04 will be different. I’ll include side-by-side instructions for both CentOS 7 and Ubuntu 18.04.
For the remainder of the instructions, we’ll assume you have Nginx installed and set up to host multiple websites, including firewall configuration to open necessary ports (80 and 443). We are connected over SSH to a shell on our server as root.
Our first step is already complete! Modern repository versions of Nginx will be compiled with OpenSSL support to server SNI information by default. We can confirm this on the command line with:
nginx -V
This will output a bunch of text, but we are interested in just this line:
...
TLS SNI support enabled
...
If you do not have a line like this one, then Nginx will have to be re-compiled manually to include this support. This would be a very rare instance, such as in an outdated version of Nginx, one already manually compiled from source with a different OpenSSL library. The Nginx version installed by the CentOS 7 EPEL repository (1.12.2) and the one included with Ubuntu 18.04 (1.14.0) will support SNI.
Since you have already set up more than one domain in Nginx, you likely have server configuration blocks set up for each site in a separate file. Just in case you don’t, let’s first ensure that our domains are set up for non-SSL traffic. If they are, you can skip this step. We’ll be working on domain.com and example.com.
vim /etc/nginx/sites-available/domain.com
include /etc/nginx/sites-enabled/*;
Otherwise, you can make your configurations in /etc/nginx/conf.d/*.conf.
At the very least, insert the following options, replacing the document root with the real path to your site files, and adding any other variables you require for your sites:
server {
listen 80;
server_name domain.com;
root /var/www/domain.com;
...
}
A similar file should be set up for example.com, and any other domains you wish to host. Once these files are created, we can enable them with a symbolic link:
ln -s /etc/nginx/sites-available/domain.com /etc/nginx/sites-enabled/
ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
Now, we restart Nginx…
systemctl reload nginx
This reloads the configuration files without restarting the application. We can confirm that the two we just made are loaded using:
nginx -T
You should see your server_name line for both domain.com and example.com.
server {
listen 123.45.67.89:80;
...
}
Now that we have valid running configurations, we can add the SSLs we have for these domains as new server blocks in Nginx. First, save your SSL certificate and the (private) key to a global folder on the server, with names that indicate the relevant domain. Let’s say that you chose the global folder of /etc/ssl/. Our names, in this case, will be /etc/ssl/domain.com.crt (which contains the certificate itself and any chain certificates from the signing authority), and /etc/ssl/domain.com.key, which contains the private key. Edit the configuration files we created:
vim /etc/nginx/sites-available/domain.com
Add a brand new server block underneath the end of the existing one (outside of the last curly brace) with the following information:
server {
listen 443;
server_name domain.com;
root /var/www/domain.com;
ssl_certificate /etc/ssl/domain.com.crt;
ssl_certificate_key /etc/ssl/domain.com.key;
...
}
Note the change of the listening port to 443 (for HTTPS) and the addition of the ssl_certificate and ssl_certificate_key lines. Instead of rewriting the whole block, you could copy the original server block and then add these extra lines, while changing the listen port. Save this file and reload the Nginx configuration.
systemctl reload nginx
We again confirm the change is in place using:
nginx -T
For some setups you’ll see two server_name lines each for domain.com and example.com, one using port 80 and one using port 443. If you do, you can skip to Step 4, otherwise continue to the next step.
Let’s next set up the free SSL provider Let’s Encrypt to automatically sign certificates for all of the domains we just set up in Nginx. On Ubuntu 18.04, add the PPA and install the certificate scripts with aptitude:
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install certbot python-certbot-nginx
In CentOS 7, we install the EPEL repository and install the certificate helper from there.
yum install epel-release
yum install certbot python2-certbot-nginx
On both systems, we can now read the Nginx configuration and ask the Certbot to assign us some certificates.
certbot --nginx
This will ask you some questions about which domains you would like to use (you can leave the option blank to select all domains) and whether you would like Nginx to redirect traffic to your new SSL (we would!). After it finishes it’s signing process, Nginx should automatically reload its configuration, but in case it doesn’t, reload it manually:
systemctl reload nginx
You can now check the running configuration with:
nginx -T
You should now instead see two server_name lines each for domain.com and example.com, one using port 80 and one using port 443.
Let’s Encrypt certificates are only valid for 90 days from issuance, so we want to ensure that they are automatically renewed. Edit the cron file for the root user by running:
crontab -e
The cron should look like this:
45 2 * * 3,6 certbot renew && systemctl reload nginx
Once you save this file, every Wednesday and Saturday at 2:45 AM, the certbot command will check for any needed renewals, automatically download and install the certs, followed by a reload of the Nginx configuration.
We should now check the validity of our SSLs and ensure that browsers see the certificates properly. Visit https://sslcheck.liquidweb.com/ and type in your domain names to check the site’s SSL on your server. You should see four green checkmarks, indicatating SSL protection.
We hope you’ve enjoyed our tutorial on how to install SSLs on multiple sites within one server. Liquid Web customers have access to our support team 24/7. We can help with signed SSL or ordering a new server for an easy transfer over to Liquid Web.
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)”
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.
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.
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.
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.
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
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
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)
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
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.
screen -dmS fixperms; screen -x fixperms
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.
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.
screen -dmS fixhtaccess; screen -x fixhtaccess
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
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
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.
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)}'
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
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
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.
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.
You may find the “can’t resolve hostname” or “temporary failure in name resolution” error when using retrieval command like wget, cURL, ping or nslookup. There are many reasons why these commands can cause an error, including file corruption. For the sake of brevity, we look towards commonalities between these commands to solve the issue.
These commands connect to the Internet using gateways to communicate and provide information. If the connection from your local machine, in this case, a CentOS server, is disconnected you’ll likely run into issues trying to access the world wide web. In this troubleshooting tutorial, we’ll show you some common solutions to connectivity issues.
Step 1: Amongst many other configuration tasks, the resolv.conf file is used to resolve DNS requests. Manually editing the resolv.conf file to configure name resolution will only do so temporarily. The Network Manager controls this essential /etc/resolv.conf file to create permanent changes. So, we’ll first stop and disable the Network Manager:
chkconfig NetworkManager off; service NetworkManager stop
Step 2: The method for permanent changes is to edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file instead of resolv.conf file. Open the file:
vim /etc/sysconfig/network-scripts/ifcfg-eth0
Next, we’ll set our DNS IP’s to use Google’s Public DNS (8.8.8.8 & 8.8.4.4).
DEVICE="em1"
BOOTPROTO="static"
DNS1="127.0.0.1"
DNS2="8.8.8.8"
DNS3="8.8.4.4"
GATEWAY="some_ip"
HWADDR="hwid"
IPADDR="some_ip"
IPV6INIT="yes"
NETMASK="255.255.255.0"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
Save and quit the file using ESC and :wq.
Step 3: Enable and restart your network, using the commands associated with your server version.
CentOS 6, CloudLinux 6, RHEL 6:
chkconfig network on
service network start
CentOS 7, CloudLinux 7, RHEL 7:
systemctl enable network.service
systemctl start network.service
Step 4: Test the reachability of a host by using ping, curl, wget or any testing tool of your choice. In our example, we’ve successfully ping’d Google!
ping google.com
PING google.com (172.217.4.46) 56(84) bytes of data.
64 bytes from lga15s46-in-f14.1e100.net (172.217.4.46): icmp_seq=1 ttl=57 time=6.65 ms
64 bytes from lga15s46-in-f14.1e100.net (172.217.4.46): icmp_seq=2 ttl=57 time=6.68 ms
64 bytes from lga15s46-in-f14.1e100.net (172.217.4.46): icmp_seq=3 ttl=57 time=6.68 ms
You don’t have to rack your brain over connectivity issues! Liquid Web customers enjoy 24/7 support for our Managed products. Our knowledgable team of support techs have experience with solving errors of this nature. Access our support team through a ticket, chat or phone call!