We have collected some of the most common questions that customers ask about our Managed WordPress Hosting platform and housed them in one place.

1. How Can I Access the File Manager?

You can access the File manager by following this article. It will show you where to obtain your FTP and SSH credentials to log in to the server.

https://help.liquidweb.com/s/article/Finding-Your-SFTP-SSH-Credentials-in-Managed-WordPress-and-Managed-Woo-Commerce-Hosting

2. How Do I Make a Site Live?

Follow our helpful article on how to launch your site for the world to see!

https://help.liquidweb.com/s/article/Going-Live-with-Your-Site-in-Managed-WordPress-and-Managed-Woo-Commerce-Hosting

If you are using Cloudflare for your DNS, please note that CloudFlare needs to be paused for the issuance of the SSL.

You can temporarily pause Cloudflare by:

1. Going to the Overview tab in the Cloudflare dashboard.
2. Expand the Advanced > section.
3. Click Pause.
4. Once the site is live you can Unpause Cloudflare.

Pausing Cloudflare will cause your origin IP address to be returned by Cloudflare’s nameservers, sending traffic directly to our servers rather than through Cloudflare’s reverse proxy.
Pausing Cloudflare will allow us to install the Let’s Encrypt SSL certificate on your Managed WordPress site. Once the site is live and has been renamed then you can resume Cloudflare.

3. How do I Make a Staging/Development Site?

Creating a staging/development site can help to create a site on a newer PHP technology or produce new content without making any changes to your production site. If you would like to create a staging/development site before you make any changes to your live site, you can follow the steps in this article:

https://help.liquidweb.com/s/article/Creating-a-Staging-Site-in-Managed-WordPress-and-Managed-Woo-Commerce-Hosting

4. How do I Take the Staging/Development Site Live?

To make your staging site the live site you will need to use our Migrate to Liquid Web Managed WordPress plugin. The plugin will take your staging site and replace your current live site with the staging site. This will take a few minutes to complete; while your files are transferring, your site will be temporarily inaccessible. To limit the downtime, you will want to do this outside of peak hours.

https://help.liquidweb.com/s/article/Migrating-to-Liquid-Web-with-Managed-WordPress-and-Managed-Woo-Commerce-Hosting

5. What is a Stencil and How Can I Use It?

A stencil will allow you to create a copy of any site you have and save it for another deployment without having to redo all the hard work you’ve put into customizing the site. Click on the following article to learn how to create a stencil site:

https://help.liquidweb.com/s/article/Creating-Stencil-Sites-in-Managed-WordPress-and-Managed-Woo-Commerce-Hosting

6. How Can I Increase My PHP Limits?

For an increase in PHP values, you will need to create a php.ini file. (Managed WordPress utilizes NGINX which does not read .htaccess files) To do so, you’ll first log in to your server with your SSH credentials. Once you are logged into the terminal you will type

cd /home/s#/html/

and replace s# with the user listed for the website.

Type

vim .user.ini

press i for insert and then paste these values into the file:

# Begin PHP Memory Limit
php_value memory_limit = 128M
php_value post_max_size 64M
php_value upload_max_filesize 64M
php_value max_file_uploads 64M
php_value max_execution_time= 300M
php_value max_input_vars = 259200M
php_value max_input_time = 259200M
php_value max_input_vars 9999M
# End PHP Memory Limit

Type Esc, and type

:wq to save your edits and exit.

These values are just an example of what you can put — you can increase or decrease the values for what you feel is appropriate for your website.

7. Why Didn’t My Plugins Update?

If your plugins didn’t update, you will want to login to the Managed WordPress dashboard and make sure that plugin updates are enabled. If the updates are enabled and your plugins are still not updated, please contact your Managed WordPress support team.

8. I Migrated My Site, But I Only See the Default Install. What’s Going On?

This usually happens when the PHP version is set too high for your site. You can adjust PHP versions by going into in the Managed WordPress Dashboard and under SITE DETAILS.

9. What Cache Plugin Should I Use To Speed Up My Site?

We include caching, so none are really needed, but these three plugins are the most frequently used by our customers and have seen the best results.

Free plugins:
https://wordpress.org/plugins/cache-enabler/
https://wordpress.org/plugins/wp-super-cache/

Paid plugins:
https://wp-rocket.me/

The post Managed WordPress – Frequently Asked Questions appeared first on Liquid Web Knowledge Base.

Nginx is an open source Linux web server that accelerates content while utilizing low resources. Known for its performance and stability Nginx has many other uses such as load balancing, reverse proxy, mail proxy, and HTTP cache. Nginx, by default, does not execute PHP scripts and must be configured to do so.  In this tutorial, we will show you how to enable and test PHP capabilities with your server.

Pre-Flight Check

• This article assumes you are logged in as root and using Ubuntu 16.04 LTS server. If not logged in as root, please add sudo before each command or login as root user.
• This article also assumes you have installed Nginx. If you have not yet installed Nginx or are unsure how to do so, please reference this easy to follow article. 
• This article is tested using NGINX 1.10.3+,  older versions should work, but it’s a good idea to update to the latest version if available before you try to configure PHP.
• This article will be running php7.0-fpm or later  (as of Dec 31, 2018, PHP 5.6 will be approaching “end of life” and no longer supported.)

Step 1a: Give Me the Packages!

First, we want to make sure our manager is up-to-date. Run the following command
sudo apt-get update && apt-get upgrade
You also want to make sure that your Nginx is up-to-date. You can check the current version by running this command. nginx -v
The result should return something like this.

You can test your NGINX configuration file for syntax errors with the following command

nginx -t

If successful you should get something similar to the following
Using nginx -t should also give you a starting point to look for errors if for some reason this was unsuccessful it will return an error.

Step 1b: PHP Version Check

Now it is time to check that your PHP version is running and using the correct version. You can do so with the following:

sudo systemctl status php7.0-fpm
You will see something similar to this if working properly:

Step 2:Time for Some NGINX Configuration

Once you have verified that both PHP and Nginx are running on your system, it’s time to configure your PHP settings!

From home cd into your NGINX folder

cd ~

cd /etc/nginx
To configure your NGINX PHP settings. Cd into the etc/php folder.
cd etc/php/
Depending on which PHP version you are using the following folders may differ. This article is using PHP 7.0. You can replace the 7.0 with the version of PHP you are using. We are looking for a file called the php.ini file.

On PHP 7.0 and 7.1 that is located at :
vim 7.0/fpm/php.ini

Or
vim 7.1/fpm/php.ini
The php.ini  is a giant file but it’s where you can customize your environment. If this is your first time, it might be a good idea to make a copy of this file BEFORE you make any changes.
cp php.ini php.ini_copy
However, if you are pro and just like to read articles for the warm fuzzies you feel inside, then go ahead and edit away!

max_execution_time = 300

max_input_time = 60

memory_limit = 256M

upload_max_filesize = 100M

Simply find these variables in the file and update the values.

Before Edit :

After edit:

Step 2b: Default Sites Configuration

We are almost done!  Now it is time to set your default sites environment. Open your sites configuration file. It should be stored by default at the following path.

/etc/nginx/sites-available/default

You can cd there or open it right up with vim.

You want to remove the following commented out lines. Here is an example for both PHP7.0 and PHP 7.1

PHP 7.0
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
     location ~ \.php$ {
include snippets/fastcgi-php.conf;
#
#     # With php7.0-cgi alone:
#     fastcgi_pass 127.0.0.1:9000;
#     # With php7.0-fpm:
            fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

PHP 7.1
server {
listen 80;
listen [::]:80;
root /var/www/html;
index  index.php index.html index.htm;
server_name  example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
     location ~ \.php$ {
             include snippets/fastcgi-php.conf;
  #
#     # With php-fpm (or other unix sockets):
            fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
#     # With php-cgi (or other tcp sockets):
#     fastcgi_pass 127.0.0.1:9000;
}
}

Step 3: Testing PHP on NGINX

Once you have made the necessary edits go ahead and restart NGINX and PHP with the following lines.
sudo systemctl restart nginx.service
To test your PHP configuration by creating a  phpinfo.php file in the /var/www/html file path.
sudo vim /var/www/html/phpinfo.phpAdd the following inside the file and save :
<?php phpinfo( ); ?>
To test your setup go to your server IP followed by /phpinfo.php in your web browser.

http://localhost/phpinfo.php

If you see the following then kick back and relax because you are all done! Congrats you deserve it!

The post Configure Nginx to Read PHP on Ubuntu 16.04 appeared first on Liquid Web Knowledge Base.

Let’s face it. At some point, while running your WordPress site, you will run into issues and errors and may ultimately have to ask yourself…

A backup & restore may not resolve your issue, and a plugin may not display itself as the source of your problem, at least, not immediately. It’s hard to tell exactly what is causing your site issues just by looking at it. This can get pretty serious in some cases and can range from a large variety of issues. In this tutorial we will cover the basics on troubleshooting problems with your WordPress installation to try and correct common issues seen with WordPress. The first place you need to look for the source of your problem is within the error log.

The most common or likely seen error log used within WordPress investigations does not actually stem from WordPress but rather from your PHP installation on the server. The php.ini file used to control PHP settings for your site will determine if and where the error log is reporting. If this is enabled you can usually find the error log in the directory (or folder) of your WordPress installation. In most cases, this file is titled error_log but is dependent on the setting in the php.ini file. You can also find the WordPress PHP error log (if enabled) within the wp-content folder in a file called php.error_log. If you see neither of these and your site is not loading properly, you need to enable debugging mode or enable PHP logging in your php.ini.

You can enable debugging for WordPress within the wp-config.php file. This is essential when trying to determine why a site is no longer loading or is erroring. You may never understand why a site does not load without seeing the errors generated. To better see what is occurring simply edit the following line within your wp-config.php file:

define('WP_DEBUG', false);

And change the false to true:

define('WP_DEBUG', true);

Changing the value to true enables debug mode and will display any errors site code directly on the page. This can be useful when trying to track down site issues or to see if upgrades have created any new issues. If you change PHP versions and the site no longer loads this method  will tell you why. Wp-config.php is also the location where you can enable the WordPress PHP error log and log directly to a file rather than printing to the screen. You can do this by adding the following code to the wp-config file:

define('WP_DEBUG_LOG', true);This code creates the WordPress PHP error log (php.error_log) if errors are present and are being generated. You can find this file within the wp-content folder of your WordPress installation. You may not see this error file if errors are not being generated so the lack of presence, after enabling this setting, may mean no errors are being reported. For instance, if your .htaccess file has a syntax error the php.error_log will not show the error because it is not a PHP related error.

If you would rather enable PHP error logging you can add values to the php.ini for the domain or via .htaccess if your configuration supports them:

Open your site’s php.ini file. If you are unsure where this is located, you can use a phpinfo page to show the location or you can also run the following in command line:

cpUser=`pwd | cut -d/ -f3`; for i in `pwd`; do touch $i/phpinfo.php; chown $cpUser. $i/phpinfo.php ; echo "<?php phpinfo(); ?>" > $i/phpinfo.php; done

Manually create a phpinfo.php file within your sites public_html folder with the following code.

<?php
// Show all information
phpinfo();
?>Afterwards, access this file via a browser at the location you created it. You will find the php.ini path under Loaded Configuration File:

Once you find this location, edit the file and add the following code if it does not exist:

;;; log php errors
display_startup_errors = false
display_errors = false
html_errors = false
log_errors = true
track_errors = true
error_log = /home/USER/logs/error_log
error_reporting = E_ALL | E_STRICT

You can change the path for error_log to wherever you want this to be stored within your users home directory. The WordPress install is bound to the same access rights as the user installing it so it will not have the permissions to write outside their home directory.

On older setups you can change the logging information via .htaccess if your configuration supports php_flags (using DSO aka as Data Source Object)

# log php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_flag  log_errors on
php_value error_log /home/path/logs/error_logMost likely newer and up-to-date configurations are not using DSO and you will need to modify this via the php.ini file.

To understand how to read the output of these logs look at the following entry:

[09-Sep-2018 22:57:20 UTC] PHP Fatal error:  Allowed memory size of 41943040 bytes exhausted (tried to allocate 32768 bytes) in home/USERNAME/public_html/wp-content/plugins/wordpress-seo/inc/class-wpseo-meta.php on line 477

You can see the date and timestamp followed by the general message and path this stems from. This tells you most of the details you will need to determine where the problem lies. You can see from the timestamp of this error when the error is occurring and if that relates to the current issue or if it was a different error. The path will usually show if this stems from a plugin or theme and the location of the software generating the error. This will even display the line in the document or file that triggered the error which can be further reviewed by your sites developer.

The “fatal error” is the most common type of error seen and the cause can vary from coding, like “undefined function”, indicate the function and problematic line of code to memory errors (like the one used in the above example). This usually occurs when the server has run out of memory or the PHP memory limit is not set high enough to run the code’s requirements. To fix these errors you may need to update software (themes and plugins usually) as it may be using deprecated code and or functions. You may also need to increase the PHP memory limit or locate any heavy resource usage on the server that may be consuming memory.

This generally means there is an issue with the database in use or the configuration of your WordPress setup. This could mean your database is corrupt or the configuration settings used in your wp-config are not correct or have been modified. Check your wp-config file has the correct credentials and syntax to ensure your database can communicate with your WordPress files. You may also see this error when the server has heavy load or the MySQL service is down. You’ll need to investigate resource usage on the server to determine why.

A standard 404 error means your server could not locate the file being called by the software in use on the domain. This usually occurs when ownership or permissions are incorrect, the file path is called incorrectly or the file is completely missing.

WordPress can sometimes run for a while without issue but some common errors can be solved with a little bit of background. As always our helpful support experts are here to assist with any WordPress related errors. Should you need assistance with troubleshooting your WordPress installation and we even offer a Managed WordPress hosting platform with WordPress error experts to investigate many issues.

The post Fixing WordPress Errors appeared first on Liquid Web Knowledge Base.

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.

Prerequisites

If you don’t already have PHP, Apache, and Mycrypt installed on your Ubuntu 16.4 server you will need to install them now.

First, add the repository for the most recent versions of PHP.

sudo add-apt-repository ppa:ondrej/php

Then update your repo cache and install.

sudo apt-get update
sudo apt-get install apache2 libapache2-mod-php php php-common php-curl php-dev php-gd php-pear php-imap php-mcrypt php-mysql php-xmlrpc gettext libmcrypt-dev

Then install Mcrypt for PHP and Apache.

sudo pecl install mcrypt-1.0.2
sudo bash -c "echo extension=/usr/lib/php/20170718/mcrypt.so > /etc/php/7.2/cli/conf.d/mcrypt.ini"
sudo bash -c "echo extension=/usr/lib/php/20170718/mcrypt.so > /etc/php/7.2/apache2/conf.d/mcrypt.ini"
sudo systemctl restart apache2.service

Installing Poweradmin

Now that we have the prerequisites out of the way we can install Poweradmin. First, start by going to the document root of the site where you want to install Poweradmin. For these purposes, I am going to use the default document root in /var/www/html.

cd /var/www/html

Then download and extract Poweradmin.

sudo wget https://newcontinuum.dl.sourceforge.net/project/poweradmin/poweradmin-2.1.7.tgz
sudo tar xf poweradmin-2.1.7.tgz
sudo mv poweradmin-2.1.7 poweradmin

Now go to your domain.tld/poweradmin/install to complete the full installation of Poweradmin.

Step 1. Select your language.

Step 2. Acknowledge warning.

Step 3. Fill in database information and set the password for the admin user.

The database and user are “pdns”. The password was automatically generated password that was set when installing PowerDNS. You can find the password by catting the pdns config file.

sudo cat /etc/powerdns/pdns.d/pdns.local.gmysql.conf

The password will be the string of letters and numbers after”gmysql-password=”. You will also be asked to set the admin user’s password.

Step 4. Create a pdns user and set some default configurations.

Put in a username and password for the non-admin pnds user. Set the default Hostmaster and nameservers.

Step 5. Create the database user in MySQL.

Log in to MySQL and then copy and paste the command to setup the database user in MySQL.

Step 6. Set up the PHP configuration file.

Create the PHP configuration file and copy and paste the output into the file.

cd poweradmin

sudo vim inc/config.inc.php

Step 7. Create the .htaccess and remove the install directory

sudo cp install/htaccess.dist .htaccess

sudo rm -rf install

Now you can browse to the poweradmin homepage domain.tdl/poweradmin. You should now see the login screen.

Using Poweradmin

When you first log in you will be greeted with the main page and a list of available options.

The first thing you are likely to want to do is set up your domain with an A record. To do so simply click on “Add master zone”.

Now you will see a box to enter in the domain name. In this case, we’re using example.com as the domain. There are a couple of other options you can choose from. We left them as their defaults, but this would be a good time to set the zone’s owner (i.e., which Poweradmin user can modify the zone file) and also set the template to create the zone with specified DNS records already in place. Click “Add zone”.

Now click list zones again, and you will see your newly created zone. Since we didn’t set up a template with our new zone file, it will not have any A records yet. To change that click the edit icon.

Now we can add the A record for the domain. We changed the type to A, fill in the IP address under “Content”, set the priority and the TTL then click “Add record”.

That’s all there is to it. With the record set up for example.com, we can now do a domain name lookup with dig on the server to get the IP address I just set up.

dig example.com @127.0.0.1

This request should now show something like this.

;; ANSWER SECTION:
example.com.       1440    IN A  127.0.0.1

This can, of course, be accomplished as we pointed out earlier with MySQL but Poweradmin is much more user-friendly and does not require knowledge of MySQL. Poweradmin is required to be installed separately from PowerDNS and has more requirements than PowerDNS (i.e., PHP, Apache, and Mycrypt).

In this Knowledge Base, we have shown you how to install Poweradmin on a server running Ubuntu 16.04. Be sure to check out our other Ubuntu related articles.

Cloud Spectator, an industry leader in laaS Marketplace Analysis, confirms Liquid Web’s VPS servers outperform Rackspace, Amazon, and Digital Ocean across the board.

The post Install Poweradmin on Ubuntu 16.04 appeared first on Liquid Web Knowledge Base.

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.

Pre-flight: Check the Server Environment

• Correct Permissions: First, make sure you have proper root or sudo permissions to be able to manage the system and applications on the server. If you only have access to a non-root user on the system, then you may have to get more permissions from the server admin.
• Existing PHP Versions: Check for an existing version of PHP. If you selected the default LAMP stack when first installing the Ubuntu image onto the server, it defaults to PHP 7.0. If you used a different image or did a plain install, then you may not have any version of PHP on the server. To check the PHP version access the terminal and run:

user@test:~# php -v
PHP 7.0.30-0ubuntu0.16.04.1 (cli) ( NTS )

If you see an older PHP version, then you will have to install the new version and switch the version Apache connects to later. If it shows “Command php not found” then there is no PHP version currently installed.

• Creating a Quick Backup: If you do have an existing PHP version, you may want to make a backup of any configurations before doing the upgrade in case there are issues (like if your site code wasn’t compatible) and you need to downgrade again. You can check on the current configuration directory by running:

user@test:~# php --ini
Configuration File (php.ini) Path: /etc/php/7.0/cli
Loaded Configuration File:         /etc/php/7.0/cli/php.ini
Scan for additional .ini files in: /etc/php/7.0/cli/conf.d

This shows the configurations are all in the /etc/php/7.0/ directory. So if you want to make a quick backup, you can run a command like:

user@test:~# sudo cp -a /etc/php/7.0/ /etc/php/7.0.backup

Also, you can save a list of existing PHP modules by running:

user@test:~# php -m > /tmp/7.0.modulelist.txt

This can help when comparing the existing modules to the modules in PHP 7.2.

Installing PHP 7.2

The official repository for PHP on Ubuntu is from Ondřej Surý on launchpad. To add it to your system, you need to run the following command:

user@test:~# sudo add-apt-repository ppa:ondrej/php

Press enter when it prompts you to. This allows your system to use the repository as a source for new software. The next command grabs the list of available software packages for your system:

user@test:~# sudo apt-get update

After that you can proceed with the install:

user@test:~# sudo apt-get install php7.2

It should show several different packages that it will install and how much total disk space they will use. When it prompts you, type ‘Y’ and submit it. After a few moments the install should be complete, check the PHP version with:

user@test:~# php -v
PHP 7.2.13-1+ubuntu16.04.1+deb.sury.org+1

It should now show PHP 7.2, but now we need to have Apache configured to use the newer version.

Configuring Apache to Use PHP 7.2

Ubuntu 16.04 uses a few different commands to help manage Apache modules so the way it utilizes a specific PHP version depends on which module is loaded. You can view the list of available modules by running:

user@test:~# ls /etc/apache2/mods-available/php*
/etc/apache2/mods-available/php7.0.conf
/etc/apache2/mods-available/php7.0.load
/etc/apache2/mods-available/php7.2.conf
/etc/apache2/mods-available/php7.2.load

You may have other modules as well, the default LAMP stack install would have 7.0 and the new 7.2 install we just made, but running the next command shows that 7.0 is still active:

user@test:~# ls /etc/apache2/mods-enabled/php*
/etc/apache2/mods-enabled/php7.0.conf
/etc/apache2/mods-enabled/php7.0.load

To switch that to the newer 7.2 version, first disable older PHP version:

user@test:~# sudo a2dismod php7.0

Then enable PHP 7.2:

user@test:~# sudo a2enmod php7.2

Before restarting Apache, check the Apache configuration syntax by running:

user@test:~# apachectl -t
Syntax OK

If it says the syntax is OK, then restart Apache:

user@test:~# sudo service apache2 restart

Verifying Apache’s PHP Version

Now to check your work, run the previous command again to see which module is loaded and it should show the PHP 7.2 version:

user@test:~# ls /etc/apache2/mods-enabled/php*
/etc/apache2/mods-enabled/php7.2.conf
/etc/apache2/mods-enabled/php7.2.load

If you do not see the same results as shown in the last few commands, recheck the spelling and syntax of the last few commands and make sure sudo was entered if you are not running as the root user.

Then to test it on your site, we recommend making a phpinfo file you can view on your domain. This shows the PHP version as well as information about current configurations, variables, and all the added modules. Create a new .php file in your site’s home folder or in Apache’s document root (/var/www/html by default) and include this code:

<?php phpinfo(); ?>

Then if you visit the page in the browser it should look something like this:

If you had a site already up and running on the previous PHP version, test it out now and see if there are any issues. If your code isn’t compatible or showing errors, you can try to diagnose further or if you need the site back up right away you can downgrade the PHP version again by running the a2dismod and a2enmod commands to disable PHP 7.2 and then enable 7.0 or whichever previous version you had on the server then restart Apache again.

Some sites may now show an error saying a module is missing and can’t run, or if you are developing a new site and have a list of modules that are needed, then the next section can help you add new modules.

Adding Modules to PHP 7.2

The switch to PHP 7.2 doesn’t automatically keep all the same modules from previous PHP versions. If you don’t need to compare the list to a previous PHP version then to install any basic modules you do need, first type the comannd below. But don’t press enter, if you press the TAB key twice you should get a list of available modules specific to 7.2::

@test:~# sudo apt-get install php7.2[tab][tab]

Example Output:
php7.2 php7.2-enchant php7.2-mbstring php7.2-snmp
php7.2-bcmath php7.2-fpm php7.2-mysql php7.2-soap
php7.2-bz2 php7.2-gd php7.2-odbc php7.2-sqlite3
php7.2-cgi php7.2-gmp php7.2-opcache php7.2-sybase
php7.2-cli php7.2-imap php7.2-pgsql php7.2-tidy
php7.2-common php7.2-interbase php7.2-phpdbg php7.2-xml
php7.2-curl php7.2-intl php7.2-pspell php7.2-xmlrpc
php7.2-dba php7.2-json php7.2-readline php7.2-xsl
php7.2-dev php7.2-ldap php7.2-recode php7.2-zip
This is not a complete list so you may need to look up how to install other modules you may need. You can type the modules you want, and you can add multiple in the same install command, like:

user@test:~# sudo apt-get install php7.2-opcache php7.2-mbstring php-memcached

If you did save the list of modules from a previous PHP version with the command earlier in the guide, you can save a list of the modules in PHP 7.2 and compare them with the previous version. Run:

php -m > /tmp/7.2.modulelist.txt

Then to compare it to the list that was created before, run:

user@test:~# diff  /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.txt
15,16d14
< mysqli
< mysqlnd
21d18
< pdo_mysql
28d24
< soap
29a26
> sodium

Or if you want a more visual way to compare the two lists, run:

user@test:~# vimdiff  /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.txt

Which will show a page like this in the terminal:

In this example, the various MySQL modules and soap show up on the list of 7.0 modules on the left but are missing from the 7.2 version on the right, and the sodium module is on 7.2 but wasn’t in 7.0.

So for this example, we can install the missing modules with:

user@test:~# sudo apt-get install php7.2-mysql php7.2-soap

After that installs, we can save an updated list of modules and can compare it again:

user@test:~# php -m > /tmp/7.2.modulelist.updated.txt
diff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.updated.txt
29a30
> sodium

Only the sodium module is different between the module lists, so it is now ready for development! Hopefully, this guide helped with your upgrade to PHP 7.2! If you had any issues or need further help with your Liquid Web Ubuntu Server, please let our Linux Support Team know!

The post How to Install PHP 7.2 on Ubuntu 16.04 appeared first on Liquid Web Knowledge Base.

EasyApache 4 installs, configures, updates, and validates your Apache, PHP and other services on your server. EasyApache 4 also supports multiple versions of PHP.  This allows you to assign different versions of PHP to each of your domains. There are great tools that have been implemented with EasyApache 4 that makes managing PHP versions simple. Two of these are the MultiPHP Manager and MultiPHP INI Editor. These can be found within the Web Host Manager, or “WHM” for short.  With the addition of these tools in cPanel/WHM, users can now complete most of these tasks from the Graphical User Interface. However, it is worth mentioning, attempting these tasks from the command line is recommended as we have seen better performance when compiling Apache builds.  

EasyApache 4 requirements

• Utilize Apache 2.4 or newer, updating Apache from 2.2 to 2.4 can be done from WHM using EasyApache 3, but it is recommended to run from the command line.  You can read more about this here.

• It is recommended for the system to use suPHP as the default PHP handler.  More information on handlers can be found here.

• CentOS 6, CloudLinux 6, Red Hat Linux 6 or higher

• PHP versions 5.4 or higher. If your site is using PHP 5.3 or older, you will need to update and confirm your site is compatible with PHP Versions 5.4 or higher.  

• MySQL/MariaDB are using updated hashes. The older versions of MySQL use an incompatible hashing algorithm.  Mysql 5.6 and later use an updated secured hash.  Since EasyApache 4 uses mysqlnd “the MySQL Native Driver” this will need to be addressed before upgrading since mysqlnd does not support older hash.  

Once you have met these requirements, your server is ready to upgrade EasyApache 3 to EasyApache 4.  When upgrading EasyApache we would recommend beginning this task at a time your server is not expecting much traffic as the process can take 20 minutes to a few hours.  This depends on your specific server’s performance and overhead. If you require any assistance with meeting the requirements needed to upgrade or would like to schedule an upgrade.  Please call, start a chat or submit a ticket with our support team.

Other than the requirements there are a few other obstacles you may need to check.

1. Be sure the suPHP_ConfigPath directive is not being used in any .htaccess file as unexpected behavior may occur. You can correct this by removing or commenting this directive out within the .htaccess file. (The .htaccess can be found in /home/$cpaneluser/public_html  or /home/$cpaneluser/)

2. Find any php.ini or .user.ini that will try to reference the old environment variable,  extension_dir, either the line will need to be removed or corrected. (The .php.ini/.user.ini can be found in /home/$cpaneluser/public_html  or /home/$cpaneluser/)

Upgrading EasyApache 3 to EasyApache 4 Script

Access your server via SSH and insert the following command:  

/scripts/migrate_ea3_to_ea4 –run 

To revert back to EasyApache 3

/scripts/migrate_ea3_to_ea4 –revert –run

Once EasyApache 4 is installed, please be sure to test your sites for any errors and confirm that WHM/cPanel is up to date.

Configuring Apache and PHP Using EasyApache 4 

1. Login to WHM and access EasyApache 4 by using the search bar.

       WHM >> Software >> EasyApache 4

2. Once you have navigated to EasyApache 4 you can view, customize and provision available EasyApache profiles.  Click the  button under Currently Installed Packages.

3. From the “Apache MPM” menu you can select which Multi–Processing Module, or “MPM” you would like to use.  This will determine how Apache will handle incoming requests and how it processes them. You can select which MPM you would like to use by clicking the toggle button to the right of the module. If you are unsure on which MPM to use, check our tutorial to help you decide. Once selected click Next.

4. The “Apache Modules” section will allow you to select and install needed Apache Modules.  Once the needed modules are selected, click Next. Apache Modules can add extra functionality to Apache.  For example, the mod_ssl module can be selected from this interface.  This allows Apache to process traffic using the Secure Sockets Layer “SSL v2/3” and TLS “Transport Layer Security”. For more Information on Apache Modules visit this link, which details more specific information on Apache Modules.

5. From the PHP Versions menu, you can select which versions of PHP you wish to install.  WHM will automatically check for extensions currently being used by other versions of PHP on your server.  More than likely these extensions are currently being used by one of your domains, and because of this, we recommend selecting the PHP X.X and Extensions button when selecting a version.  After you have selected the versions you want to install, click Next.

6. From the next menu, the PHP Extensions menu, you can select all PHP extensions you require.  PHP extensions enable particular functions used in your PHP code, an example of this would be if your PHP code communicates with MySQL you will need to utilize the “mysqlnd” extension.  EasyApache 4 has already selected recommended extensions that existed on previously installed versions of PHP on your server by default.   A good tip is to limit the selection view to only the version of PHP you are installing.  You can do so at the top of this page by deselecting the boxes next to Filter by PHP Version.  Once you have selected your PHP extensions click Next.

7.  The next two sections are not commonly used, however, they are included for those that require these functions.  Ruby via Passenger allows you to integrate Ruby, Node.js, and Python applications on your server.  Within this menu, you can install/select which Ruby modules you would like to use.  More information on this can be found in this link. 

Within the Additional Packages menu, you can select custom packages to be installed on your server.  Currently, by default, the only option available is Tomcat 8.5.  Tomcat is a Java Servlet Container that allows you to run Java–based application on your server. You can save the profile to be used for later by clicking Save as profile button on the bottom-right corner of the page.

Once you have finished your selections, click Next or Review.   You should see a notification like the one we have included below.  This can take a few minutes to complete so allow it some time to poll your results.

8.  Please be sure to review this next page to make sure you have selected the desired configuration. If you notice anything is missing or should be changed, you may return to the relevant menu to adjust the selections. Once reviewed, scroll down to the bottom of the page and click the “Provision” button.Once you have begun provisioning, please allow EasyApache some time to finish.  You will be prompted once the process has finished.

Congratulations, you have selected an MPM, installed additional Apache Modules, PHP versions, and PHP extensions using EasyApache 4.

Using the MutliPHP Manager from WHM

cPanel’s MultiPHP Manager allows users to manage cPanel accounts PHP configuration on a per domain basis.  This feature is only available on EasyApache 4.  You can also set the system’s default global PHP version for all accounts, enable PHP-FPM globally or per domain, and adjust PHP-FPM pool options.

Selecting System default PHP Version 

1. Navigate to the MultiPHP Manager (WHM >> Software >> MultiPHP Manager)
   Note:

   Setting the system default PHP version will not change the PHP version for all domains. Your cPanel account “if not defined” is set to inherit by default. If the inherit option is enabled, the account will use the system’s default PHP version.

2. Click Edit under System PHP Versions.

3. Select the desired PHP version and click Apply. You should see a Success notification at the top right of the page if the change was successful.  It will also display any errors that may have occurred. 

Define PHP Versions per Domain

Within the MultiPHP Manager, you also can set the desired PHP version on a per domain basis.  

1. Select the domain or accounts you wish to alter.
2. Click the drop–down menu located in the PHP column.
3. Select your desired PHP version. The interface will prompt you once the change has completed.

Changing PHP Versions on Multiple Accounts

1. Select which accounts you would like to alter by clicking the check boxes next to the domain.
2. Click the drop–down located in the type right.
3. Select the desired PHP version and click Apply.  The interface will prompt you once the change has completed.

MultiPHP INI Editor

MultiPHP INI Editor is a great tool that allows you to manage PHP settings per version.  You can quickly edit the most commonly adjusted PHP directives from within the Basic Mode or for more advanced users you can edit the configuration files directly using the Editor Mode.   For information on directives, please read PHP’s documentation which can be found here.

To access the MultiPHP INI Editor login into WHM. (WHM >> Home >> Software >> MultiPHP INI Editor)

Basic Mode allows you to view and edit directive values for your selected PHP version.  WHM will save changes to the PHP configuration file.  Also, directives will only show if the version of PHP you are editing supports that directive. With WHM assistance this greatly helps minimize errors as the syntax within these files are sensitive.  

Edit PHP Configuration Using MultiPHP INI Editor in Basic Mode

1. Select a PHP version from the drop–down menu.
2. Adjust directives as needed.  For example, you can increase upload_max_filesize by editing the field to the right of the directive.
3.  Click Apply to submit changes.  If the edit was submitted successfully WHM will notify you at the top right of the page.  It will also inform you if any errors have occurred.
4. Adjust directives as needed.  For example, you can increase upload_max_filesize by editing the field to the right of the directive. 
5.  Click Apply to submit changes.  If the edit was submitted successfully WHM will notify you at the top right of the page.  It will also inform you if any errors have occurred.

Edit PHP Configuration Using MultiPHP INI Editor in Editor Mode

Editor Mode allows you to modify additional directives and PHP configurations that are not available in Basic Mode.  Please note, errors within this interface can result in errors causing PHP scripts not to function correctly.  Unlike Basic Mode which loads directives available to that version of PHP, Editor Mode loads the contents from the .ini file for the selected PHP version.  If the file does not exist then, the interface will load a blank editor.  When saving values or configurations to a blank editor, the systems will create a new file. 

1. From within MultiPHP INI Editor click the Editor Mode tab. 
2. Click the drop–down menu to select PHP Version.
3. The Editor will open the file as a text document. From here you can simply edit the configuration to your needs.

4. Click Save to submit your changes.  If the changes were successful WHM will display a success notification in the top right of the screen as well as any errors that may have occurred.  

EasyApache 4 makes adjustments and server tuning a breeze.  However, there is still a chance the end user can make a fatal mistake.  A quick call to our support staff could bring a quick resolution to your issue.  There are some cases where the best solution possible, is the fastest the end user can apply themselves.  For cases such as these, we would highly recommend utilizing our Cloud Backups.  Cloud Backups offer an extra layer of protection as your backups are stored on a remote device we manage here at Liquid Web.  This ensures full restoration in the unlikely event of a total system failure. The end user can manage and restore easily from our manage page.  For more information on how Cloud Backups can work for you visit products page. 

The post Install Multiple PHP Versions Using EasyApache 4 appeared first on Liquid Web Knowledge Base.

What is Webmin?

Webmin is a browser-based graphical interface to help you administrate your Linux server.  Much like cPanel or Plesk, Webmin allows you to set up and manage accounts, Apache, DNS zones, users and configurations.  As these configurations can get somewhat complicated Webmin works to simplify this process. The result is fewer issues during server and domain setup.  Which results in a stable server and a pleasant administration experience. Unlike Plesk or cPanel, Webmin is completely free and open to the public. Unfortunately, here at Liquid Web, we do not offer managed support for Webmin, but we are always willing to assist as much as possible when issues arise.   You can download Webmin from their site. Also, you can find some excellent documentation on this interface.

Installing Webmin

Before beginning “if you have not already” you will need to install Webmin on your server.  For this article, we will mainly be working with Webmin installed on a Ubuntu server. However, it is very similar to CentOS therefore we have included instructions for both operating systems below.

• First, you will need to access your server SSH. If you are not sure how to SSH into your server, please visit our link on the subject.  
• Once you are logged into your server SSH, please run the following commands in order or copy and paste the entire syntax.

Debian/Ubuntu

sudo sh -c 'echo "deb http://download.webmin.com/download/repository sarge contrib" > /etc/apt/sources.list.d/webmin.list'wget -qO - http://www.webmin.com/jcameron-key.asc | sudo apt-key add -
sudo apt-get updatesudo apt-get install webmin

CentOS/RedHat/Fedora

(echo "[Webmin] name=Webmin Distribution Neutral
baseurl=http://download.webmin.com/download/yum
enabled=1
gpgcheck=1
gpgkey=http://www.webmin.com/jcameron-key.asc" >/etc/yum.repos.d/webmin.repo;
yum -y install webmin)

Accessing Webmin

Webmin is a web-based application.  So once Webmin is installed, you can access Webmin by using a browser of your choice.   Be sure to make sure port 10000 is open on your server as Webmin utilizes this port to function.  We have included steps below to ensure the correct port is open for iptables and firewalld.

IPTABLES

iptables-save > /tmp/tabsav
vi /tmp/tabsav
iptables-restore < /tmp/tabsavYou should be able to use the command above to alter you iptables to look something like what we have included below.
# Generated by iptables-save v1.4.7 on Thu Jan 3 00:02:49 2019
*filter
:INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [3044:1198306] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Thu Jan 3 00:02:49 2019

FirewallD

firewall-cmd --zone=public --add-port=10000/tcp --permanent
firewall-cmd --reload
Once you have made sure port 10000 is open, you should be able to access the Webmin interface by entering in your servers IP address followed by the port number “10000”

Example:   https://192.168.1.100:10000             <—— 192.168.1.100 should be replaced with your server IP.

Installing PHP Versions in Webmin

There is a lot of situations where we may need to use multiple PHP versions.  For example, you may have multiple domains or applications on your server that require an older version of PHP while at the same time you may have newer domains that are configured for newer versions of PHP.   For this article, we will be installing PHP7 and PHP5.6 on Debian.

Step 1: First, you will want to SSH into your server and run the following command.
apt-get install php7.0-cli php7.0-fpmYou can check the installation after it has completed by running php –v in your terminal.

Step 2: Now here is where things tend to get tricky.  By default, Debian only offers a single PHP version in the official repository. So, we will have to add an additional repository for Debian. While adding this repository, it is good practice to enable HTTPS for APT and register the APT key. You can accomplish this by executing the commands we have included below.

apt-get install apt-transport-https
curl https://packages.sury.org/php/apt.gpg | apt-key add -
echo 'deb https://packages.sury.org/php/ stretch main' > /etc/apt/sources.list.d/deb.sury.org.list
apt-get update

Once the repository is added, we can go ahead and add our second PHP version to the server.

apt-get install php5.6-cli php5.6-fpmWe can now check both PHP versions on the server by running these commands.

php7.0 -V

Output:

php5.6 -V

Output:

Now that we have confirmed both PHP versions are installed you can access their configuration files in the following directories.

• /etc/php/5.6/cli/php.ini
• /etc/php/7.0./cli/php.ini

Step 3: To make things easier, later on, we will want to add the location of the configuration files to Webmin.  This can be done from within the Webmin interface.

1. Log into Webmin
2. Navigate to Others >> PHP Configuration
3. Add the PHP configuration file location
4. Click Save

You can use this tool to add and edit directives for different PHP versions. For example, you’ll be able to edit PHP’s memory limit, timeout length, extensions and more.  This simply helps consolidate configurations within one interface. From here we can just use a .htaccess file to specify what version of PHP a site should use.

Step 4: If you do not have this file already within your document root you can add this file by navigating to /var/www/exampledomain/  and running the following command to indicate which PHP version you are going to use.

echo "AddHandler application/x-httpd-php56 .php" >  .htaccess  | chown exampleuser. .htaccess

echo "AddHandler application/x-httpd-php70.php" >  .htaccess  | chown exampleuser. .htaccess

Step 5: Once you have completed this, you can test to see if your site is running on the desired PHP version.  You can accomplish this by creating a PHP information page. by making a file in your document root, usually in the path of /var/www/html/

You will want to insert the code below and save the file.

<? phpinfo(); ?>   After you have created this file, you can view the page by visiting your domain followed by the name of the file you created.  For example, www.example.com/phpinfo.php.

Congratulations you can now use Webmin to accomplish your daily admin tasks!  Take a look at our Cloud VPS servers for 24/7 support and lightening speed servers!

The post How To Set Up Multiple PHP Versions in Webmin appeared first on Liquid Web Knowledge Base.

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.

Pre-flight

• Apache Installation and PHP enabled
• MariaDB Installation
• Log in as root or have sudo privledges

Step 1: You’ll first log in to your server.

ssh root@hostname.com

Step 2: Then log in to your MySQL/MariaDB instance by typing:

mysql

You’ll see the prompt change, and you’ll then be able to use MySQL commands to make a database and grant permissions.

MariaDB [(none)]>

Replace the highlighted password below, with a secure password.  You can tell the commands were accepted because it’ll show a “Query OK, 0 rows affected (0.00 sec)” message after each command.  Be sure to have the password for the Nextcloud user handy; we’ll be using it later in this tutorial.

CREATE DATABASE nextcloud;

CREATE USER nextcloud IDENTIFIED BY 'password';

GRANT USAGE ON *.* TO nextcloud@localhost IDENTIFIED BY 'password';

GRANT ALL privileges ON nextcloud.*  TO nextcloud@localhost;

FLUSH PRIVILEGES;

quit;

Install Nextcloud Modules

You’ll need specific modules installed for NextCloud to work, within your terminal, install the modules using the apt install command.  Press Y to continue when prompted.

apt install php-gd php-json php-mysql php-curl php-mbstring

apt install php-intl php-imagick php-xml php-zip

Install NextCloud

Finally, we’ll download and extract NextCloud’s files.  You can then move it over to the destination of your choice, for our tutorial, we’ll move it to our default document root, /var/www/html.

Step 1: Download the Nextcloud package.

wget https://download.nextcloud.com/server/releases/nextcloud-15.0.7.tar.bz2

Step 2: Extract the Nextcloud package.

tar -xvf nextcloud-15.0.7.tar.bz2

Step 3: Move Nextcloud core files over to Apache’s root directories.

cd nextcloud

mv ./* /var/www/html

mv ./.htaccess /var/www/html

mv ./.user.ini /var/www/html

cd /var/www/html

Step 4: Make a directory within the /var/www/html folder for Nextcloud storage.

mkdir /nextcloud-data

Step 5: Nextcloud is run by Apache and uses www-data as the user, therefore, you’ll need to change over the permissions and ownership.

chown -R www-data:www-data ./*

chown -R www-data:www-data .htaccess

chown -R www-data:www-data .user.ini

chown www-data:www-data /nextcloud-data

Step 6: Restart Apache for the changes to take effect.

systemctl restart apache2Step 7: Verify Nextcloud is working by visiting it in your browser at http://your_ip/index.php.    Creation of the admin account is necessary, as well as setting the folder/directory (nextcloud-data) that NextCloud will store its uploads.

• Create an Account with username; we are using admin.
• Data folder should be /nextcloud-data
• Username and password should be the ones for MySQL that were made earlier, leave the setting on localhost.
• Click Finish
  

You are now in Nextcloud and can start uploading files and folders!

Our lightning-fast VPS and Dedicated servers can run Nextcloud. Along with hardware that kicks, you’ll also enjoy 24/7 technical support.  Find out how our supreme hosting services can help you out!

The post How to Install Nextcloud 15 on Ubuntu 18.04 appeared first on Liquid Web Knowledge Base.

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:

• CentOS 6x/7x
• CloudLinux 6x/7x

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.

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.

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.

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.

The post How to Install mod_fcgid on cPanel’s EasyApache 4 with CloudLinux appeared first on 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.

The default settings for mod_fcgid are often overwhelming to many servers. Due to this, it is not recommended to run mod_fcgid purely on the default settings. To appropriately optimize, the server will require a baseline FCGI configuration. Luckily, after years of working with FCGI, we’ve managed to figure out a baseline configuration template that works well in most situations. This will be the starting configuration, but it is not intended as a “set and forget” configuration as it’ll require some adjustments to perform optimally.

FCGI Baseline Configuration Template

First, let’s look at the template, which has comments (indicated with ##) provided for the understanding of each directive.


## BEGIN - FCGI Baseline Configuration Template
<IfModule mod_fcgid.c>
## Set buffers to 1G to ensure buffered sites are loaded fully.
## Increase if page output may be larger than 1G.
FcgidOutputBufferSize 1073741824
## Match to FcgidOutputBufferSize (ensures large volume input works)
FcgidMaxRequestLen 1073741824
## Disable process termination based on number of requests
## (rely on lifetime for termination not request count)
## Protects against the FCGI random 500 ISE caveat.
FcgidMaxRequestsPerProcess 0
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 0
FcgidInitialEnv PHP_FCGI_CHILDREN 0
## Total allowed active PHP Processes server-wide
## Calculated by: SystemAvailableMemory/PHP memory_limit
FcgidMaxProcesses 100
## Total allowed active PHP Processes per user
##     Dedicated Servers should Match FcgidMaxProcesses
##     Shared Servers use a fraction of FcgidMaxProcesses
FcgidMaxProcessesPerClass 50
## Should Match PHP: cgi.fix_pathinfo (which defaults to 1)
FcgidFixPathinfo 1
## How long to wait for I/O processes to complete
## Match Apache: Timeout
FcgidIOTimeout 30
## How long to wait for an active PHP process to finish before forced recycle.
## Should Match PHP: max_execution_time
FcgidBusyTimeout 300
## Kill off idle PHP processes
## Max lifespan of idle process is: FcgidIdleTimeout + FcgidIdleScanInterval
FcgidIdleTimeout 60
FcgidIdleScanInterval 60
## How long an active PHP processes lives before forced recycle.
## Lower this if PHP memory leaks become a problem
FcgidProcessLifeTime 3600
## Prevents idle PHP processes from lingering
FcgidMinProcessesPerClass 0
</IfModule>
## FINISH - FCGI Baseline Configuration Template

FCGI Directive Breakdown

In this sectional we’ll breakdown the FCGI Baseline Configuration, step by step, to explain the logic behind these settings. To address the needs of each server we’ll explain how to attune them to your specific environment. Click on the directive’s box to see the official documentation for each directive.

The output buffer should be large enough to allow even the largest of pages to be fully buffered before FCGI flushes the buffer. This can be set even higher than 1G, but that should not be necessary unless the application/website produces pages with more than 1G of data in the output. Setting the buffer too low can cause only partial page rendering. At minimum, this directive should be as large as the PHP memory_limit directive.

The request length needs to be at least as large as the post_max_size directive being used in PHP. Otherwise, only partial data is passed through FCGI to PHP, resulting in unexpected input. Matching this value to the FcgidOutputBufferSize directive ensures both input and output are large enough for most applications.

To obtain optimal synergy between Apache & PHP processes, we disable the termination of PHP processes based on the number of requests processed. The configuration will rely on PHP lifetime to determine when to recycle a PHP process instead of an arbitrary request limit.

As part of disabling premature termination of PHP processes, we need to set both of the PHP_FCGI_MAX_REQUESTS and PHP_FCGI_CHILDREN environment variables to zero. This is done using the FcgidInitialEnv directive to apply these settings in the environment Apache passes along to FCGI.

This setting is a ceiling limit over the top of all users. The default setting seldom applies to a real setup, unless the server in question is running very beefy hardware with some reasonable limits in place on PHP memory usage. Allowing execution of 1,000 PHP processes at one time is tough for even the largest of multi-core servers. A setting of 100 is a generic ceiling that works well in most situations. However, it is possible to calculate the theoretical upper limit of PHP processes by taking the system’s available memory and dividing it by the PHP memory_limit setting (rounding down).

This setting is the per-user limitation setting. When running on a Dedicated server, where only a few domains exist, it’s generally okay to match this directive to the FcgidMaxProcesses setting. This way all sites on the server have access to all authorized PHP processing slots. However, on a shared hosting environment, in general, one user should not be allowed to monopolize all available PHP processing slots. In a shared environment, the FcgidMaxProcesses directive should be a reasonable fraction of the spawn processes for a single user.

In older versions of PHP, the default setting of 0 is no longer supported in the cgi.fix_pathinfo directive. All modern versions of PHP now default this setting to 1. This means that the default value of the FcgidFixPathinfo directive no longer matches that of the default PHP setting. To remedy the problem, we need to set cgi.fix_pathinfo to 1 as well. However, if site/application software requires the cgi.fix_pathinfo setting of 0, then it will be necessary to match FcgidFixPathinfo to it as well.

This directive is the equivalent of and should match the Apache Timeout directive. It’s good practice to keep both of these as low as possible. However, some more demanding applications require extra time to complete their execution, and if this is lower than your Apache Timeout directive, the execution will not be able to finish.

The busy timeout equals the length of time FCGI will wait on PHP execution. This directly relates to the PHP max_execution_time settings. If FcgidBusyTimeout is lower than your max_execution_time, longer running scripts will be prematurely terminated after the allocated time.

Determining the idle timeout differs from dedicated to shared setups. In a dedicated environment, allowing PHP processes to linger during traffic surges can reduce the server’s load. It accomplishes this by having PHP processes available without the overhead of spinning up new ones. However, on a shared setup it becomes a problem because every PHP processing slot needs to remain open for all users. Thus, leaving processes  to linger as they are bound to the owner that created them. In these cases, a lower idle timeout is desired.

It becomes necessary to reduce FcgididleScanInterval when the idle timeout or lifetime timeout are smaller than the default FcgididleScanInterval. Since the checks run on this interval setting,  the max FcgidIdleTimeout and FcgidProcessLifeTime durations are their configured timeout settings plus the scan interval. So with an idle timeout of 60 seconds and an idle scan interval of 60 seconds, the longest an idle process could live is 120 seconds.

The longer a process runs without being terminated, the more susceptible it is to memory leakage. For this reason, a suitable amount of time should be allotted before a process is terminated. A setting of 1 hour (3600) is an excellent general setting to keep memory leaks under control.

There is a known caveat that when this directive is positive, it will supersede the related FcgidIdleScanInterval timeout directives. This allows processes to live indefinitely, undermining the reliance on FcgidProcessLifeTime and FcgidIdleTimeout for memory leak protection. Thus, FcgidMinProcessesPerClass should always remain 0 on any shared server.

The information outlined in this article should not only help you to install mod_fcgid onto your cPanel server but also give you a basic understanding of module configuration. Each server may face some unique issues that are not addressed in this article. However, these are usually resolved by observing the fcgid related error and warning messages printed in the Apache error log file: /etc/apache2/logs/error_log. Let us not forget that these settings are examples, and you should adjust them as your needs dictate. Optimization is an ongoing process, what works for you now, may not work for you in six months. Remember to check your system’s average processes and consider expanding or upgrading your hardware when hitting it’s limits.

The post The Best Settings for Configuring FastCGI (mod_fcgid) appeared first on Liquid Web.

Whether you’re new to hosting websites or a seasoned developer, you’ve more than likely heard of a LAMP stack. The LAMP stack is the base set of applications that most websites running on a Linux server are served from and is commonly referred to as “Lamp”. Rather than a single program that interacts with the website being served, LAMP is actually a number of independent programs that operate in tandem: Linux, Apache, MySQL/MariaDB, and PHP. Throughout this article, we’ll walk through installing the LAMP stack on your CentOS 7 server so you can run a website from any Dedicated Server or Virtual Private Server. Although we’re focusing on installing LAMP on a CentOS 7 server, the steps that we’ll cover are very similar across multiple Linux distributions.

Each environment differs slightly, so let’s discuss the environment that we will use throughout this tutorial. We’ll start with a clean installation of the latest version of CentOS 7 (version 7.6) on a virtual machine installed on a workstation. For ease of installation, we’ll use the root user to install the services. You can use an alternate system user if you choose, but you will need to prepend sudo to the following commands in order for them to install or interact with the software. For any environment that you choose, it is important that you are connected to the internet to access the yum repositories to download the packages to install.

Once the server is started and you are accessing the server via console or SSH terminal, we can start running through the next steps. If you need assistance with interacting with a server via terminal, please see our article on SSH.

Pre-flight Checks

To find out which Linux distribution you are running, use this command:
cat /etc/redhat-release
It’s now time to verify that our yum environment is clean and up to date, we’ll do this by cleaning all of the yum cache, and update yum using:
yum clean all
yum update

Installing LAMP

Now that we know what environment we’re working in let’s get started on installing the LAMP stack on CentOS 7:

L – Linux

The first part of the stack is Linux. This is your operating system and since it is already installed there no need to worry about installing it or make any modifications. Installing CentOS 7 is easy to download and install using the image files that are provided from centos.org. CentOS has a helpful installation guide if you need to reference it for additional installation instructions.

A – Apache

Apache is the next piece of the LAMP stack. Apache is the webserver software that is responsible for serving the content to your web browser from the server. It takes the requests that it receives and sends back the HTML code for your browser to interpret.
Install Apache using Yum:
yum -y install httpd

Open ports in the FW:
firewall-cmd --permanent -add-service=http -add-service=https
firewall-cmd --reload

Start and enable apache to run when the server starts:
systemctl start httpd
systemctl enable httpd

Default Apache installation locations:

Some important server locations to remember for Apache are listed below. These are out-of-the-box defaults and can be changed as you see fit:
httpd binary: /sbin/httpd
Apache configuration file: /etc/httpd/conf/httpd.conf
Website files: /var/www/html/
Apache logs: /var/log/httpd/

M – MySQL/MariaDB

MySQL and MariaDB are what handle your website’s database. In most of today’s websites, data is not stored in flat or static files. Instead, the base of the site is coded in PHP which can pull information from your website’s database to deliver more dynamic content. MySQL and MariaDB are popular database servers that help house that information. MariaDB is becoming more widely used, so we’ll use for installation. Both are very similar in setting up and configuring.

Install MariaDB:
yum -y install mariadb-server
systemctl start mariadb

Although securing mysql is optional, it is strongly recommended:
mysql_secure_installation
**Run through the steps on screen to secure your Mysql/MariaDB environment

Enable MariaDB to start when the server starts:
systemctl enable mariadb

Default installation locations:

Some important server locations to remember for MySQL/MariaDB are listed below. These are out-of-the-box defaults and can be changed as you see fit:
MariaDB binary: /bin/mysql
MariaDB Configuration file: /etc/my.cnf
Database location: /var/lib/mysql
MariaDB logs: /var/log/mariadb/mariadb.log

P – PHP

Most websites that exist today are built using PHP coding. PHP provides the programmer with more options for dynamic content compared to flat html code. Several PHP versions are available for use depending on what PHP version the website was built in. We’ll install the latest version of PHP.

In order to install the latest PHP version, we first need to install CentOS’s Software Collection repository (SCL):
yum -y install centos-release-scl.noarch

We’ll now have access to install PHP 7.2 :
yum -y install rh-php72

Now we’ll fix the symbolic link for the binary:
ln -s /opt/rh/rh-php72/root/usr/bin/php /usr/bin/php

Install the updated PHP Module for Mysql/MariaDB:
yum -y install rh-php72-php-mysqlnd

Restart apache to work with the newly installed PHP:
systemctl restart httpd

If your website’s code requires additional PHP and Apache modules, they can be installed using yum . If you need to verify what exactly your website is using for PHP, you can set up a PHP info page. For more information, see Setting up a PHP info page.

The LAMP stack is the minimum that is required in order for any modern website to run on a Linux server. There are many variations to these environments that can be tailored to suit your needs. Luckily, our Fully Managed Server and Core Managed servers come with the LAMP stack pre-installed and ready for you to install your website on. For more information about ordering your new server, contact our Solutions Team. Our support teams are also trained in handling issues that may arise with each component of the LAMP stack and are able to answer any questions that you might have.

The post How To Install the LAMP Stack on CentOS 7 appeared first on Liquid Web.

A new vulnerability in PHP-FPM has been noted which could lead to remote code execution on nginx. An earlier message on Twitter exposed the CVE-2019-11043 bug:

According to Tenable:

CVE-2019-11043 is an env_path_info underflow flaw in PHP-FPM’s fpm_main.c. The vulnerability was first reported to the PHP bug-tracker by security researcher Emil Lerner on September 26, 2019.

On October 24, PHP 7.3.11 (current stable) and PHP 7.2.24 (old stable) were released to address this vulnerability along with other scheduled bug fixes. Those using nginx with PHP-FPM are encouraged to upgrade to a patched version as soon as possible.

According to Lerner, under certain configurations where a web server is using nginx and PHP-FPM, the vulnerability can be exploited to gain remote code execution. These configurations require a certain set of preconditions in order for it to be exploitable.

These preconditions include:
* The nginx location directive forwards requests to PHP-FPM
* The fastcgi_split_path_info directive is present and includes a regular expression beginning with a ‘^’ symbol and ending with a ‘$’ symbol
* The fastcgi_param directive is used to assign the PATH_INFO variable

There are no checks in place to determine whether or not a file exists (e.g., using try_files or an if statement) but it appears such configurations and preconditions are not uncommon.

https://lqwb.us/33ZvifR

It was also pointed out that on line 1140 in the file sapi/fpm/fpm/fpm_main.c (https://github.com/php/php-src/blob/master/sapi/fpm/fpm/fpm_main.c#L1140) contained pointer arithmetics that assumed that env_path_info has a prefix equal to the path to the php script. However, the code does not check to see if this assumption is satisfied. The absence of this check can lead to an invalid pointer in the “path_info” variable. Such conditions can be achieved in a standard Nginx configuration. If there is an Nginx config setup like this:

```
   location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        fastcgi_param PATH_INFO       $fastcgi_path_info;
        fastcgi_pass   php:9000;
        ...
  }
}
```

The regexp in the

fastcgi_split_path_info
directive can be broken using the newline character (in encoded form, %0a). This broken regexp leads to an empty PATH_INFO, setting which triggers the bug. This issue leads to the remote code execution.

Later in the code, the value of path_info[0] is set to zero (https://github.com/php/php-src/blob/master/sapi/fpm/fpm/fpm_main.c#L1150); then FCGI_PUTENV is called.

Using a carefully chosen length in the URL path and query string, an attacker can make path_info point precisely to the first byte of the _fcgi_data_seg structure.

Putting a zero into it moves the

char* pos
field backward, and following FCGI_PUTENV overwrites some data (including other fast cgi variables) with the script path. Using this technique, a researcher was able to create a fake PHP_VALUE fcgi variable and then use a chain of carefully chosen config values to get code execution.

Test Script

To reproduce the issue, take take the following steps:

1. Build php with –enable-fpm and ASAN enabled.
2. Download https://www.dropbox.com/s/eio9zikkg1juuj7/reproducer.tar.xz?dl=0. (The following steps assume you’re in the reproducerdirectory from the archive.)
3. Run nginx using sudo /usr/sbin/nginx -p $PWD -c nginx.conf
4. Run php-fpm using path/to/php-fpm -y ./php-fpm.conf -F
5. Visit a (pretty long) link from the crash_link.txt using another tool, like curl $(cat crash_link.txt).

Expected Result

No crash should happen.

Actual Result

You will get a crash. Here is the output error:

==6629==ERROR: AddressSanitizer: SEGV on unknown address 0x620000005203 (pc 0x7efd1341a47f bp 0x7ffe980574e0 sp 0x7ffe98056c98 T0)
==6629==The signal is caused by a WRITE memory access.
    #0 0x7efd1341a47e in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:140
    #1 0x4b7c57 in __asan_memcpy /home/emil/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
    #2 0x13a88df in fcgi_hash_strndup /home/emil/php-src/main/fastcgi.c:322:2
    #3 0x13a88df in fcgi_hash_set /home/emil/php-src/main/fastcgi.c:359:11
    #4 0x13c4121 in init_request_info /home/emil/php-src/sapi/fpm/fpm/fpm_main.c:1154:12
    #5 0x13c4121 in main /home/emil/php-src/sapi/fpm/fpm/fpm_main.c:1864:4
    #6 0x7efd13380b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #7 0x440219 in _start (/home/emil/php-src/builded/sbin/php-fpm+0x440219)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:140 in memcpy

Patch/Fix

Current Stable PHP 7.3.11 & Old Stable PHP 7.2.24 have been released to address this issue. Please update as soon as possible. For further information, please visit the links below.

• https://www.php.net/downloads.php
• https://lqwb.us/33Uf1sC
• https://lqwb.us/2Jkj4GU

Learn More!

Having a patched system is a priority when trying to upgrade to the latest version of PHP or nginx, especially when issues like this occur. Still have questions, concerns or issues with upgrading? Allow our Level 3 system administrators to assist in resolving this issue for you.

Give us a call today at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Hosting advisors today!

The post PHP-FPM/Nginx Vulnerability – CVE-2019-11043 appeared first on Liquid Web.

WordPress has a great GUI-based installation process however some use cases call for CLI! Or, maybe you just feel more at home in a terminal, either way this article will show you how to get your WordPress site setup with just a terminal, using WP-CLI, and maybe a sprinkle of SSH.

In order to be able to install WordPress manually using WP-CLI you will first need to create a new database for the WordPress install. You will need to know how to find your SSH credentials as well as being used to using Terminal or Putty and WP-CLI.

Using WP-CLI to install WordPress

In this tutorial we’ll learn how to install WordPress using the WP-CLI command line tool. WP-CLI is a tool using in a terminal for interacting with and managing WordPress sites. WP-CLI is similar in functionality to what Drush provides Drupal. If you are already familiar with using cli tools then this will be an easy installation. Using WP-CLI, we can complete common maintenance tasks, automate processes, and even take backups.

Prerequisites

• The latest version of WP-CLI Installed.
• SSH Credentials to log into the server as the root user or a user with sudo privileges

Install WordPress

First, we will need to cd into the public_html folder where the WordPress install is going to reside.

root@host:~# cd ~/public_html/wpdev

Next, we will need to run the following WP-CLI command which will download the WordPress core files from the WordPress.org and then extract them into the public_html folder.

root@host:~# wp core download 

Now that we have the WordPress core files installed, the next task is to create our MySQL database. There are multiple ways to accomplish this, so we need to ensure we are doing what our server needs.

Do not copy the commands below directly!
These are only examples used for this tutorial.
Substitute your settings for these entries.

mysql -e "create database wpdev;";

Next, we will need to create a wp-config.php file for the site we just added which will contain the database name, database user and database password.

wp config create --dbname=cli1_wp_ --dbuser=cli1_wp --dbpass=Hippi3Pik3r5Ha1rDr@ms --locale=ro_RO

Now that we have created a valid wp-config.php file, it is time to go through the 5 second install process using WP-CLI’s core installation command.

wp core install --url=wordpress.dev --title="WordPress Dev" --admin_user=wpadmin --admin_password=p@55w0ord! --admin_email=you@myemail.com 

Success: WordPress installed successfully.

Make sure that you update all the info for the arguments here. If you’ll notice above, we change the URL for the domain, replacing it with the actual domain URL that is needed. We also changed the site’s title, the admin username, the admin password, and finally, we set our email address for the admin user. Make sure the email is correct since WordPress will email you if your PHP can send email. We now have a working WordPress install.

To verify which version of WordPress we are running, we can run this WP-CLI command.

wp core version

Next, we need to create an appropriate Apache/Nginx vhost entry (if running in an unmanaged environment) and the needed PHP configuration changes, and then we are ready to go the new with WordPress setup.

If you’re on a cPanel, InterWorx, or Plesk server, chances are you already have these settings created for you. If you create a cPanel, InterWorx or Plesk account for the WordPress install in advance. These tasks are performed automatically when you create the new account in the servers control panel. If you’re on a traditional unmanaged server, we will need to create and modify the config files.

Things to Watch Out For!

Database related

One major item to be aware of when running through the process. If you forget to make the database and run the WP-CLI install, you will get an error. This also applies when you have entered the wrong credentials also. The errors will vary slightly depending on the situation, but they are both similar. For example, when you provide the proper User and password for MySQL but didn’t make the database you’ll see:

Error: Can’t select database. We were able to connect to the database server (which means your username and password is okay) but not able to select the `wpdev` database.

Installing WordPress For an existing WordPress database

Another thing to keep in mind is that if you employ this process using an existing WordPress database, we need to use the following command instead of the one used above.

wp config create --dbname=YourDB_Name --dbuser=WP_MYSQL --dbpass=WPDB_PASS

Success: Generated 'wp-config.php' file.

A few examples of when this would be applicable. If you are rebuilding a site or fixing an account after a security breach, or for any other situation where you already have an existing database.

One last thing to keep in mind is that if you have a custom database prefix, or are using a remote MySQL server, you will have to add additional flags for those. You can see the full list of commands flags by running the following command.

wp core config --help

If you are experiencing problems installing WordPress this way, our support team can help. Simply give us a call today at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable System administrators!

The post Installing WordPress using WP-CLI appeared first on Liquid Web.

PECL, the PHP Extension Community Library, is a repository of C extensions that are loaded directly into PHP. PHP Extensions expand the functionality of PHP. PECL extensions can be installed via the use of the pecl command. There are also PHP extensions provided by package repositories. The decision of which to utilize typically depends on how PHP was installed.

This tutorial covers the installation of the PHP extension phpredis via the default CentOS 8 package manager DNF. It will also cover the installation of both PHP 7.4 and Redis on CentOS 8.

Preflight Check

• These instructions are intended specifically for installing phpredis via DNF on a CentOS 8 server.
• This tutorial was performed on a Liquid Web Self Managed CentOS 8 server as the root user.

Step #1: Install PHP 7.4

CentOS 8 provides PHP 7.2 and PHP 7.3 for installation in the default repository. PHP 7.2 is approaching EOL in 6 months and PHP 7.3 in about 18 months. Installing PHP 7.4 provides gains in the speed department and ensures a longer period of support going forward.

1. First, run the following command to set up the Remi repository, which will provide the PHP 7.4 and phpredis packages we want to install along with some handy package management utilities.

[root@centos8 ~]# dnf install dnf-utils http://rpms.remirepo.net/enterprise/remi-release-8.rpm -y

2. Next, take a look at the available PHP modules by running.

[root@centos8 ~]# dnf module list php

The output should look something like this.

[root@centos8 ~]# dnf module list php
Extra Packages for Enterprise Linux Modular 8 - x86_64 208 kB/s | 117 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64 3.8 MB/s | 6.6 MB 00:01
Remi's Modular repository for Enterprise Linux 8 - x86_64 456 kB/s | 567 kB 00:01
Safe Remi's RPM repository for Enterprise Linux 8 - x86_64 1.1 MB/s | 1.5 MB 00:01
CentOS-8 - AppStream
Name Stream Profiles Summary
php 7.2 [d] common [d], devel, minimal PHP scripting language
php 7.3 common, devel, minimal PHP scripting language
Remi's Modular repository for Enterprise Linux 8 - x86_64
Name Stream Profiles Summary
php remi-7.2 common [d], devel, minimal PHP scripting language
php remi-7.3 common [d], devel, minimal PHP scripting language
php remi-7.4 common [d], devel, minimal PHP scripting language
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

3. Next, in order to enable the PHP remi-7.4 stream run the following dnf commands.

[root@centos8 ~]# dnf module reset php -y
[root@centos8 ~]# dnf module enable php:remi-7.4 -y

4. Finally, in order to install PHP, run the command.

[root@centos8 ~]# dnf install php -y

To verify that PHP 7.4 is available, check the version by running this command.

[root@centos8 ~]# php -v
PHP 7.4.6 (cli) (built: May 12 2020 08:09:15) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies

Step #2: Install, Start, and Enable Redis

In order to make use of the phpredis extension, Redis must be installed on the system. To install Redis run.

[root@centos8 ~]# dnf install redis -y

Next, in order to start and enable Redis to start on system boot, run the following command.

[root@centos8 ~]# systemctl enable --now redis

Verify Redis is running by running this command.

[root@centos8 ~]# systemctl enable --now redis.service
Created symlink /etc/systemd/system/multi-user.target.wants/redis.service → /usr/lib/systemd/system/redis.service.
[root@centos8 ~]# systemctl status redis
● redis.service - Redis persistent key-value database
Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/redis.service.d
└─limit.conf
Active: active (running) since Thu 2020-05-14 00:15:43 EDT; 4s ago
Main PID: 3606 (redis-server)
Tasks: 4 (limit: 8969)
Memory: 6.5M
CGroup: /system.slice/redis.service
└─3606 /usr/bin/redis-server 127.0.0.1:6379
May 14 00:15:43 centos8.awesome.com systemd[1]: Starting Redis persistent key-value database...
May 14 00:15:43 centos8.awesome.com systemd[1]: Started Redis persistent key-value database.

Step #3: Install phpredis

The Remi repo set up at the beginning of this tutorial provides a packaged version of the phpredis extension. This is convenient because it eliminates some steps that would be required if it were installed with pecl.

1. In order to install phpredis, run the following command.

[root@centos8 ~]# dnf install -y php-pecl-redis5

Run the following command to list the currently installed PHP extensions and search for Redis among them.

[root@centos8 ~]# php -m | grep redis
redis

2. Last, as a good measure, restart php-fpm.

[root@centos8 ~]# systemctl restart php-fpm.service

PHP’s extensions are extremely useful in extending PHP capabilities. Installing them via package managers like DNF is convenient and in most cases will minimize the amount of additional effort in getting them off and running.

Want to know more? Give us a call at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Experienced Hosting advisors to learn how you can take advantage of these techniques today!

The post How to Install PHP Extensions on CentOS 8 appeared first on Liquid Web.

The Action Scheduler is a background processing, queue job runner which is built into WooCommerce core. A number of plugins use the Action Scheduler, WooCommerce Subscriptions and WooCommerce Follow-Ups being two of the best known.

WP-CLI makes it easy to delete posts and comments which have been created by the Action Scheduler in WooCommerce. There may be cases where the Action Scheduler might create a large number of posts and comments on your live site, and you want to clear up the data from the site’s database.

Delete Comments from Action Scheduler

To delete comments created by the Action Scheduler, you can run this wp-cli command:

wp comment list --field=comment_ID --'comment_author'='ActionScheduler' --number=1000 | xargs wp comment delete --force

The number can be increased if you have more comments that need to be deleted to 2000 or higher.

Delete Bulk Posts from Action Scheduler

To delete all the scheduled-action posts, you can run this wp-cli command:

wp post list --field=ID --post_type=scheduled-action --posts_per_page=1000 | xargs wp post delete --force

The number can be increased if you have more posts that need to be deleted to say 2000 or higher.

Delete Scheduled Action Posts

To delete all the scheduled-action posts with a post status of trash, you can run this wp-cli command:

wp post list --field=ID --post_type=scheduled-action --posts_per_page=1000 --post_status=trash | xargs wp post delete --force

Delete Bulk Scheduled Actions

To delete all the scheduled-action posts with a post status of cancel,  you can run this wp-cli command:

wp post list --field=ID --post_type=scheduled-action --posts_per_page=1000 --post_status=cancel | xargs wp post delete --force

Conclusion

Using a mix of these commands, you will be able to delete posts and comments easily, using WP-CLI on your site. It will also keep your site database clean, allowing it to run more efficiently.  Take the work out of maintaining your WordPress site with our Managed WooCommerce product.  Our WooCommerce platform comes with free iThemes plugins curated especially for online stores.

Give us a call at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Experienced Hosting advisors to learn how you can take advantage of these techniques today!

The post Delete Posts and Comments from Action Scheduler appeared first on Liquid Web.

More and more these days, a high search engine page rank is imperative. The ideal website load time for mobile sites now should be under 3 seconds, and honestly, the faster, the better! The average time it takes to load an entire mobile landing page is approximately 22 seconds, but 53% of visits are abandoned if a mobile site takes longer than 3 seconds to load.

This means that a slow loading website can lead to a substantial NEGATIVE impact on ranking factors in Google. These rankings are a nuanced process by which Google evaluates more than 200 signals, and now, the mobile page speed load time is one of the significant factors. 

This article will review some of those factors that can be controlled and improved upon to address a slow loading website. 

Prerequisites

When troubleshooting a slow loading website, the first thing we should do is run a baseline, so we have a future reference to which we can refer. We do this to see how much of a difference our changes have made. This measurement allows us to compare and contrast increases or decreases in load time.

To accomplish this, we can use several online tools that provide an excellent method to obtain that data. Here are three sites that provide superior feedback on performance affecting issues. 

• Pagespeed Insights
• Websitetest
• GTMetrics

Other Factors

As a side note, it should be mentioned that distance, network speed, routing issues, computer speed, and multiple other factors can come into play here as well. This is why selecting a standard timing budget we want to aim for is so important. Eliminating as many variables in our testing framework will provide an increase in accuracy when testing.

Metrics

Metrics are the measurements we employ to determine the optimal load and performance times of a site. The type of metrics will vary with the tool used, but most of the primary measurements used are based on two main areas; Performance Metrics and Browser Timings. Typically, performance scores and timings are weighted as some factors are more critical to usability than others. 

Performance Metrics

Each of these metrics is weighted at anywhere from 5% to 25%. 

• First Contentful Paint — FCP determines how long it takes a browser to render the first piece of DOM content that loads after a client hits your page. The lower the FCP score, the better the results.
• Speed Index: The speed Index determines how quickly visual content is displayed when a page loads.
• Largest Contentful Paint: LCP measures the time it takes for the largest image or text block.
• Time to Interactive: The TTI measurement notes how long it takes a webpage to become completely interactive.
• Total Blocking Time: The TBT measurement is defined as the entire time a page blocks user input. This includes mouse clicks, screen taps, keyboard presses, or other input methods. 
• Cumulative Layout Shift: CLS measures the totals of every single layout shift score for any unexpected shift in a website’s layout, which happens during the full life of the webpage.

We can see these results in several online tests which provide the results of our scans. Additionally, some online calculators provide a more in-depth means to identify how each score affects our website. It also allows us to choose either the mobile or desktop version of a website. From experience, your mobile site is more important to site rankings to Google.

Browser Timings

• Redirect Duration — The total time used redirecting URLs before the full page load
• Connection Duration — The time spent connecting to the server
• Backend Duration — The time take to generate a server response
• Time to First Byte (TTFB) — The total time consumed receiving the first byte
• First Paint — The point at which the browser begins page rendering
• DOM  (Document Object Model) Interactive Time — This measures the time it takes for the browser to finish loading and parsing the HTML
• DOM Content Loaded Time —  The point at which the DOM tree is loaded
• Onload Time — This measurement indicates when the page has finished downloading.
• Fully Loaded Time — The point when the following conditions have occurred
  • First Contentful Paint has happened
  • Onload has happened
  • The Network and CPU are idle

These metrics are used to gauge a website’s overall usability, speed, and performance.

Areas of Issue or Concern

The following recommendations are typically used to ensure a website is optimized fully. We have divided the concerns up into multiple categories to try to be as granular as possible. These areas include:

• Website code
• CMS related optimizations
• Website concerns
• OS/Server problems
• Hosting issues

Website Code 

• A website’s code size can be considerable — Limit objects to 20-30 per page
• JavaScript — Large JS elements can delay page load times
• Minimize/Optimize Code, CSS, and Javascript — Removing unneeded characters from code reduces its size, which improves load times. 
• Limit CSS expressions — These are evaluated when a page is rendered, resized, scrolled, and the user moves their mouse over the page. 
• Use gZIP Compression — Using gzip reduces the overall response times by reducing the HTTP response size.
• Load stylesheets first
• Load scripts last
• Limit DOM objects — The more complex the page, the longer the load time.
• JavaScript & CSS External — There are two proper ways of accessing them
  • Inline (i.e., within the HTML code)
  • External (i.e., in external files cached/stored by the browser, e.g., Firefox)
• Limit ETag usage — If not using the ETag validation model, it’s better to remove them altogether. 

CMS Related Optimizations

• Keep CMS updated 
• Keep all plugins, add-ons, and themes updated
• Remove/Replace resource-intensive plugins, add-ons, and themes
• Avoid Heavy Plugin usage 
• Limit large graphics and media files
• Compress/resize/optimize large images to less than 100k
• Flash is dead — reduce or eliminate this multimedia software
• Keep all page components small — 50k-100k max
• Use a modal window to push videos or large pictures
• Limit the number of external page elements  
• Minify all files
• Avoid empty src or href tags — the browser makes more requests when this occurs
• Consider using the AMP HTML framework
• Enable CMS specific optimizations (WordPress, Joomla, Drupal, and WooCommerce)

Website Concerns

• Conflicting scripts can cause slowdowns
• Avoid or limit the use of external advertisers
• Add Expires or Cache-Control Header
  • Implement “Never expire” for static components
  • Use appropriate Cache-Control header for dynamic components
• Place stylesheets at top of page
• Avoid redirects if possible — a redirect slows the user experience
• Minimize cookie file size and eliminate unnecessary cookies
• Enable lazy loading of images and videos
• Combine files if possible
• Disable hotlinking
• Combine Google fonts

OS/Server Problems

Internal Issues

• Keep server software updated/upgrade
  • Apache/nginx
  • Database software
  • CMS
  • PHP
  • Python
  • Perl
• Add and enable caching
• Check server response times
• Use a CDN
• Limit API calls to external services
• Excessive overhead in the database can slow a site
• Clean and optimize the database often
• Hosting provider platform should be stable and with minimal downtime
• Reduce DNS Lookups — This takes 20-120 milliseconds for DNS to lookups to complete. Implement DNS prefetching.
• Excessive load can cause a slow server, increasing load time
• Server Location — the farther the server is from the user, the longer it can take to load a site.
• Monitor server health regularly.

External Issues

• Optimize external resources being pulled from an outside website
• High HTTP requests — Reduce the number of rendered page components
• Network issues — Latency or network congestion can impact load times
• ISP issues — Network performance can vary greatly by provider.
• Browser issues — Incompatibility, limited functionality, or other factors can play a part in a website loading slowly.

Hosting Issues

• Choose The Right Host — Check uptime, support models, reliability, and other factors.
• Use a reputable developer who understands how all these issues can affect performance.

Diagnostic Tools

Multiple online tools have an established reputation for providing reliable information when reviewing all these aspects. Some of these tools include:

• Google Analytics
• GTmetrix
• Google Page Speed Insights
• YSlow
• Webpagetest.org 

Users can employ these tools in tandem to provide a complete image of what steps should be taken to troubleshoot a slow loading website. 

Conclusion

Lastly, do not let the good become the enemy of the perfect. A solid score might be improved upon, but you should ask yourself these questions before running down this rabbit hole.

• Will users notice an improvement? Optimizations may minimally improve speed but, is it worth investing your time and money on a developer for a small decrease in load time?
• Is investing in the changes worth the trouble? Optimization can require many changes and can include drawbacks that could require many hours of work.
• Is the cost defensible? Is a developer needed to do the work for you? Does his cost justify the necessary improvements?

Website speed is important because it usually improves a sites search engine rankings. Using the above information can reduce overall load times and increase customer retention. Additionally, fast sites typically receive more traffic and have better conversion rates. It is well worth your time to investigate these issues and correct or eliminate any problems that slow down the speed of your website.

Talk To An Expert Today!

Our Support Teams are filled with experienced Linux technicians and talented system administrators who have intimate knowledge of multiple web hosting technologies, especially those discussed in this article.

Should you have any questions regarding this information, we are always available to answer any inquiries with issues related to this article, 24 hours a day, 7 days a week 365 days a year.

We pride ourselves on being The Most Helpful Humans In Hosting™!

If you are a Fully Managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server, Managed Cloud Servers, or a Dedicated server owner and you are uncomfortable with performing any of the steps outlined, we can be reached via phone at @800.580.4985, a chat or support ticket to assisting you with this process.

The post How to Troubleshoot A Slow Loading Website appeared first on Liquid Web.

Introduction

In this two-part series, we outline the steps to take when investigating where server load originates or causing your server to become overloaded. When running a server that hosts multiple websites, high load issues often crop up. To find out how and why this occurs, read on. 

What is Server Load? 

Server load is a measure of work that a server is experiencing. The load averages represent the average system load over a period of time. Servers calculate load averages as the exponentially damped/weighted moving average of the load numbers. The three values of load average refer to the past one, five, and fifteen minutes of system operation. If you have a single CPU, the load average is a percentage of the system utilization for a specific time period. If you have multiple CPU’s, you must divide by the number of processors to get a comparable percentage. To find the number of processors on the server, run the following command.

root@host [~]# grep processor /proc/cpuinfo | wc -l
4
root@host [~]#

Addressing Load Issues

The first step in addressing any load issue on a server is having a benchmark in place for the server to determine its resting performance. While this may seem like an inopportune time to try and run a benchmark, we need to establish a baseline to see how well our adjustments are working. Often we see performance improvements using proper configuration and caching. We recommend running this benchmark when the server is at its least busy point. The main command used for benchmarking is shown below. 

root@host:~ # ab -lt 10  -c3 -H "Accept-Encoding: gzip,deflate,br" "http://www.domain.com/"

The apachebench (or ab) command is used here to provide a standard we can judge performance against.

Load Average

Now that we have completed our benchmark, the next item we want to look at is how many processes are waiting for CPU resources. This measurement is expressed as an average over a period of time. The top command measures load in increments over time. The term “high load” is relative based on the amount of resources the CPU has available. 

An experienced Linux admin had this to say.

“The server load should not be higher than the total number of cores the server has. If the server has eight cores, and it is running at a load of eight, all eight cores are working at 100%.”

A dedicated server with a one-minute load average of eight and uses an octa-core processor does not necessarily have what would be defined as a “high load.” However, a VPS server with a one-minute load average of 8.0 and using a quad-core processor is likely experiencing a “high load” as all CPU cores are operating at 200% capacity. 

We must also take into account the server’s responsiveness. If one of a Managed Cloud duo-core servers has a one-minute load average of 4.0, keeps up with incoming requests, and is responsive, the server is most likely not experiencing “high load.”

We can see the one-minute, five-minute, and fifteen-minute load averages using the w command or the top command.

root@host [~]# w
 17:17:40 up 6 days,  8:13,  0 users,  load average: 0.00, 0.03, 0.07

USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root@host [~]#

root@host [~]# top
top - 17:18:30 up 6 days,  8:13,  0 users,  load average: 0.00, 0.02, 0.06
Tasks: 159 total,   1 running, 157 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.2 us,  0.1 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.4 st
KiB Mem :  3766984 total,   195752 free,  1307504 used,  2263728 buff/cache
KiB Swap:  2047996 total,   763476 free,  1284520 used.  2004704 avail Mem

Load Types

Generally, server load is caused by one or more services or their related applications. Here are four main resources that ordinarily cause an overloaded server: 

• CPU 
• RAM
• Disk I/O 
• Networking

CPU

The type of load a server experiences is found using one of several commands. The top command should be our first choice when evaluating server load as it prints a system summary using the three load averages, system task stats, system CPU stats, system RAM stats, and system swap stats.

While the top command is running, we can press the “1” key, which shows the CPU stats for every CPU core on the system. These stats are broken down into eight percentages and are considered the percentage of time each CPU is engaged with tasks. 

top - 17:21:36 up 6 days,  8:16,  0 users,  load average: 0.09, 0.08, 0.08
Tasks: 158 total,   1 running, 156 sleeping,   0 stopped,   1 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.3 us,  0.0 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.7 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.7 st
%Cpu3  :  0.3 us,  0.0 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.3 st
KiB Mem :  3766984 total,   346856 free,  1283940 used,  2136188 buff/cache
KiB Swap:  2047996 total,   761516 free,  1286480 used.  2028524 avail Mem

The table below defines the identifiers above.

The number of CPU resources is measured by the percentage of time the CPU spends processing actual workloads. If the largest CPU percentage time is spent on user processes or system processes, this indicates the server is tasked with too many resource-intensive processes. Here are a few examples of processes that cause an overload of a CPU(s) on a server:

• PHP Scripts
• Multiple background processes
• Malformed MySQL queries
• Apache processes
• Malware scanning

RAM

RAM, also known as Random Access Memory, is measured at the server level using the free -m command. This command shows us the total memory, used memory, free memory, shared memory, buffers/cache memory, and finally, available memory.

root@host [~]# free -m
              total        used        free      shared  buff/cache   available
Mem:        3678        1415         403      125     1859        1869
Swap:        1999        1271         728
root@host [~]#

The used memory accounts for the memory used by all running processes, including the kernel, and includes the buffers/cache memory. The available memory estimates how much memory is available for starting new processes without swapping. 

Memory usage by a process is viewed using the ps command. The %MEM column is a percentage or ratio of the process’s Resident Set Size compared to the machine’s physical memory. The Resident Set Size (or RSS) is the amount of memory used by the process occupied by physical RAM. To put it another way, %MEM is the percentage of physical RAM used by the processes. 

A few examples are of things that can max out the RAM of a server:

• PHP/Apache – If the PHP (memory_limit * PHP-FPM’s Max_children) or FCGI’s (FCGIdMaxProcesses) requests exceed the amount of RAM on the server, a crash is possible due to memory exhaustion.
• MySQL – If MySQL’s maximum configured memory limit exceeds the amount of RAM available on a server, a crash is possible due to memory exhaustion.

Disk I/O

Disk I/O refers to the operational transfer of data on a physical disk to and from a destination. If we read data from files on a disk, the CPU requires time to read the files. The same applies to writing. Disk I/O can contribute to an increase in load in multiple ways. Here are a few examples that can exceed the Disk I/O of a server:

• Running out of RAM and swapping memory to a disk.
• MySQL queries writing temporary tables to a disk.
• A substantial amount of email is sending from the server.
• Large backups running over a long period of time.

Using the iotop command can show the actual amount of disk I/O being utilized.

root@host [~]# iotop

Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
     1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd --switched-root --system --deserialize 22
     2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
     4 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]
     6 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
     7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
     8 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_bh]
     9 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_sched]
    10 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [lru-add-drain]
    11 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    12 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/1]

Networking

Ethernet performance can affect the overall load on the server. If a significant amount of traffic is received, network bottlenecks can occur. Typically, this happens when communication between devices lacks the necessary bandwidth or processing power to complete a task quickly. During high traffic periods, DDOS attacks, or slow loris attacks, the network throughput needed to fulfill requests to the server can exceed capacity or lock open. When this occurs, server load can increase. An optimized website usually does not encounter this type of load. 

Using a command line tool like iftop provides an solid overview of network usage.

root@host [~]# iftop
interface: eth0
IP address is: 68.228.87.126
MAC address is: 52:54:00:91:87:6f

                                    12.5Kb                              25.0Kb                               37.5Kb                              50.0Kb                         62.5Kb
└───────────────────────────────────┴───────────────────────────────────┴────────────────────────────────────┴───────────────────────────────────┴────────────────────────────────────
host.domain.com                                                             => 430461.cloudwaysapps.com                                                      40.1Kb  15.1Kb  12.5Kb
                                                                              <=                                                                               7.12Kb  1.99Kb  1.65Kb
host.domain.com                                                             => dc2-176.vpn.domain.com                                                     1.39Kb  6.24Kb  5.46Kb
                                                                              <=                                                                                160b   1.49Kb  1.29Kb
host.domain.com                                                             => 151.139.128.11                                                                   0b   1.14Kb   973b
                                                                              <=                                                                                  0b   5.34Kb  4.45Kb
host.domain.com                                                             => lvps87-230-15-219.dedicated.hosteurope.de                                        0b   1.23Kb  1.02Kb
                                                                              <=                                                                                  0b   3.77Kb  3.14Kb
host.domain.com                                                             => 10.10.10.10                                                                      0b   1.50Kb  1.33Kb
                                                                              <=                                                                                  0b   2.78Kb  2.44Kb
host.domain.com                                                             => 10.30.9.124                                                                      0b   1.40Kb  1.17Kb
                                                                              <=                                                                                  0b    920b    767b
host.domain.com                                                             => 10.30.9.125                                                                      0b   1.40Kb  1.16Kb
                                                                              <=                                                                                  0b    920b    767b
host.domain.com                                                             => 10.30.9.122                                                                   2.91Kb   640b    656b
                                                                              <=                                                                               1.50Kb   353b    473b
host.domain.com                                                             => 10.30.9.138                                                                      0b    468b    427b
                                                                              <=                                                                                  0b    310b    295b
───────────────────────────────────────────────────────────────────────────────────────────
TX:             cum:   48.8KB   peak:   46.7Kb                                                                                                        rates:   46.7Kb  30.3Kb  32.5Kb
RX:                    24.6KB           56.6Kb                                                                                                                 11.3Kb  18.8Kb  16.4Kb
TOTAL:                 73.3KB           81.9Kb 

Conclusion

This ends part one of our two-part article series on investigating server load. Server load is the measure of work that a server experiences. When issues arise with CPU usage, RAM deficits, increased Disk I/O, or network congestion, load issues will manifest. In part two of this series, we will explore the means and methods to locate and address load issues on the server. 

We pride ourselves on being The Most Helpful Humans In Hosting™!

Our Support Teams are filled with experienced Linux technicians and talented system administrators who have intimate knowledge of multiple web hosting technologies, especially those discussed in this article. Should you have any questions regarding this information, we are always available to answer any inquiries with issues related to this article, 24 hours a day, 7 days a week 365 days a year.

If you are a Fully Managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server, Managed Cloud Servers, or a Dedicated server owner and you are uncomfortable with performing any of the steps outlined, we can be reached via phone at @800.580.4985, a chat or support ticket to assisting you with this process.

The post How to Investigate Server Load: Part 1 appeared first on Liquid Web.

Introduction

In this second tutorial on server load, we outline the steps that should be taken when investigating where server load originates and what may be causing your server to become overloaded. As noted in Part 1 of our series, excessive use of any apps or services can typically cause load issues. Here are the four main areas of concern:

• CPU
• Memory (including swap)
• Disk I/O
• Networking

Historical Load

Typically, when troubleshooting server load, we are notified of a high load error or receive an email informing us about an event that has already passed. Unless an admin can log in while the load is occurring, trying to pin down where the load originated is difficult. With that being said, there are several tools we can use to identify the timeframe and load averages that occurred during a load occurrence. The first step uses the sar -q command to locate the timeframe in which the load occurred. 

SAR Command

Using the sar command specifically, we can review the past load history to pin down when it experienced an elevated server load. If we see a pattern of high load times, say between 1:00 am, and 2:00 am on the 22nd of the month, we can move forward and use the sar command to view load between the times noted. Below is the example output of the sar command using the – q flag.

root@host [~]# sar -q -f /var/log/sa/sa22
Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com) 01/22/2021 _x86_64_  (4 CPU)

12:00:01 AM runq-sz  plist-sz ldavg-1   ldavg-5  ldavg-15   blocked
12:10:01 AM  5        567      0.06      0.11      0.12         0
12:20:01 AM  9        567      0.03      0.04      0.08         0
12:30:01 AM   4       576      0.24      0.14      0.11         8
12:40:01 AM   7       576      0.04      0.07      0.11         0
12:50:01 AM   7       570      0.08      0.06      0.09         0
01:00:02 AM   8       578      0.03      0.07      0.08         0
01:10:01 AM   5       570      0.00      0.04      0.05         0
01:20:01 AM   7       577      0.00      0.02      0.05         1
01:30:02 AM   3       573      0.06      0.03      0.05         0
01:40:01 AM   6       566      0.06      0.05      0.05         0
01:50:01 AM   6       563      0.07      0.08      0.05         0
02:00:01 AM   16      589      0.14      0.06      0.06         2
02:10:02 AM   1       577      1.10      1.16      0.69         4
02:20:01 AM   10      581      1.87      1.76      1.27         2
02:30:01 AM   6       571      0.04      0.40      0.81         1
02:40:01 AM   4       567      0.03      0.10      0.46         2
02:50:01 AM   8       568      0.10      0.08      0.27         1
03:00:01 AM   10      647      0.14      0.11      0.20         0
03:10:01 AM   4       638      0.04      0.09      0.16         0
03:20:01 AM   8       640      0.06      0.09      0.13         0
03:30:01 AM   9       651      0.04      0.25      0.22         0
03:40:01 AM   8       629      0.10      0.16      0.20         1

The command’s full output is shown from 12:00:01 AM to 11:50:01 PM for the 22nd of January. It should be noted that the sar logs rotate out each month and overwrite the log from a month prior. The sar command also can review CPU, memory, swap, and I/O data using various flags. 

Current Load

If an admin can log in right away, several of the tools noted below are excellent at deducing high server load.

HTOP 

This command is an interactive process-viewer, process-manager, and system-monitor designed as an alternative to the top command. To install it, we use the command below.

root@host [~]# yum install htop

To view the current statistics, simply run the htop command.

Using the menu, we can sort, filter, and search for information broken down by multiple factors, including PID, user, priority, state, time, and the percentage of CPU and memory being used. Assuming the load is not too high, this is an excellent tool we can use to locate and stop a high load in its tracks. 

PCP/Dstat

In a prior knowledge base article, we reviewed PCP or Performance Co-Pilot. PCP is an assessment and evaluation tool previously known as Dstat. It is used to collect a wide range of server metrics while examining current and prior operational data. As a side note, Dstat was renamed to PCP after RedHat took it over. Dstat was a versatile replacement for the following Linux toolsets:

• vmstat
• Iostat
• netstat 
• ifstat

RedHat also added additional features like more counters and increased flexibility over those older tools. To install PCP, visit the PCP homepage tool. An additional feature of dstat is the ability to run a cron of a dstat command to take a snapshot of your server’s processes every X seconds/minutes. It then allows us to record that info into a .csv format, which we can download and import later into excel or google sheets for review.

Solving High Load Issues

We can break down the high server load issue once we determine where the load originates.

CPU

Typically, issues revolving around a high CPU load indicate that we need additional cores to handle the system’s extra workload. The other cause we can address is working with the application to either optimize or reduce the application usage or horizontally scale the application. As noted in Part 1, some of the common causes of increased CPU usage are as follows:

• PHP scripts
• Multiple background processes
• Malformed MySQL queries
• Apache processes

Here is a command we can use to gather information about CPU processes and queue usage.

root@host [~]# resize; clear; date; echo "Top 10 Processes";echo "";ps -eo user,%cpu,%mem,\
rsz,args|sort -rnk2|awk 'BEGIN {printf "%s\t%s\t%s\t%s\t%s\n","USER","%CPU",\
"%MEM","RSZ","COMMAND"}{printf "%s\t%g'%'\t%g'%'\t%d MB\t%-10s\n",$1,$2,$3,\
$4/1024,$5}'|head -n10;echo "";sar -u 2 5;echo "";sar -q 2 5

This command provides output like so.

Wed Jan 27 14:26:50 EST 2021
Top 10 Processes

USER    %CPU    %MEM    RSZ     COMMAND
mysql   0.3%    3.9%    146 MB  /usr/sbin/mysqld
cpanelc+        0.2%    0%      2 MB    /usr/local/cpanel/3rdparty/sbin/p0f
wp-tool+        0%      0.1%    5 MB    /usr/bin/sw-engine
wp-tool+        0%      0.1%    4 MB    /usr/bin/sw-engine
USER    0%      0%      0 MB    COMMAND
systuser        0%      0.5%    20 MB   Sonar

Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com)   01/27/2021      _x86_64_        (4 CPU)

02:26:50 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:26:52 PM     all      0.12      0.00      0.12      0.00      0.37     99.38
02:26:54 PM     all      0.00      0.00      0.00      0.00      0.25     99.75
02:26:56 PM     all      0.00      0.00      0.12      0.00      0.50     99.38
02:26:58 PM     all      0.00      0.00      0.00      0.00      0.37     99.63
02:27:00 PM     all      0.37      0.00      0.25      0.00      1.36     98.01
Average:        all      0.10      0.00      0.10      0.00      0.57     99.23

PHP

If a PHP script is over-utilized or not coded well, it will cause an excessive CPU load. The script should be reviewed and optimized by a web developer. Generally, these scripts perform a specific function on a website like file manipulation, content management, handling multimedia duties, or other utility roles used to improve the website’s usability or functionality. 

Apache/Background Processes

Background processes like malware scans or increased Apache processes can have a severe impact on available resources. If enough of these processes occur simultaneously, the available RAM is consumed, and the server begins running into swap issues. To solve this, a user should identify the specific processes related to the increased load using a command like this to find Apache’s top requests.

root@host [~]# cut -d' ' -f7 /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20
2886972 /
   1107 /.env
   1016 /robots.txt
    688 /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
    582 /index.php
    470 /favicon.ico
    453 /TP/public/index.php
    449 /config/getuser?index=0
    427 /manager/html
    424 /TP/index.php
    411 /thinkphp/html/public/index.php
    410 /public/index.php
    398 /html/public/index.php
root@host [~]#

Next, we can also check if the website is being hit by too many requests from an IP address.

root@host [~]# cut -d' ' -f1 /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -25 | column -t

985      77.229.244.46
978      189.236.73.159
963      125.25.205.227
963      103.229.183.192
950      115.75.104.128
903      185.239.242.215
840      193.239.147.178
724      193.239.147.186
691      76.74.148.29
641      94.102.50.143
583      195.54.160.21
548      123.206.50.168
530      5.101.0.209
474      91.241.19.84
408      59.127.45.109
389      103.95.8.190
378      114.35.68.107
363      103.92.25.78
357      92.126.211.33
355      41.175.155.78
347      45.134.82.253
332      195.54.160.135
root@host [~]#

Too many connections may indicate a bot, web scraper, or someone just hitting the site too often. 

Lastly, here is a command which shows us the top ten memory utilization processes (with children aggregate).

root@host [~]# ps axo rss,comm,pid | awk '{ proc_list[$2]++; proc_list[$2 "," 1] += $1; } END { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc "," 1],proc); }}' | sort -n | tail -n 10
13796   dockerd
21520   SonarPush
25512   lfd
39888   python3
44220   php-fpm
51128   cpsrvd
56232   php
106356  httpd
156492  mysqld
523904  clamd
root@host [~]#

MySQL

Malformed MySQL queries can also have a significant impact on load. If a user is interacting with a website trying to pull specific information from an existing database, backed up MySQL processes will delay that data’s return. If enough of those processes run concurrently, it will force the load higher. Using the mysqladmin processlist command will help identify the current workload of MySQL.

root@host [~]# mysqladmin processlist
+--------+----------------+-----------+----------------+---------+---
| Id  | User | Host | db | Command | Time | State | Info | Progress |
+--------+----------------+-----------+----------------+---------+---
| 1   | system user |    | Daemon  | InnoDB purge worker      | 0.000    |
| 2   | system user |    | Daemon  | InnoDB purge coordinator | 0.000    |
| 4   | system user |    | Daemon  | InnoDB purge worker      | 0.000    |
| 3   | system user |    | Daemon  | InnoDB purge worker      | 0.000    |
| 5   | system user |    | Daemon  | InnoDB shutdown handler  | 0.000    |

Another tool that is useful for identifying load from MySQL is Mytop. Mytop is an open-source, command-line tool used for monitoring MySQL performance. It is a clone of the top command and features a terminal-based interface to monitor the overall performance of MySQL. Using this method, we can see how queries from a database are performing. 

Once the malformed queries are located, we can then have a developer adjust them to run more efficiently. Otherwise, they should be rewritten or removed if they are a primary cause of load. 

Memory

Locating the cause of high load related to memory or RAM consumption can be difficult without the proper tools and information. Luckily, we can use commands like this to identify a memory usage overview using the terminal.

The output of this command looks like this. 

Wed Jan 27 14:43:31 EST 2021
awk: cmd. line:1: BEGIN {FS=" "}{printf \"\nAvail\tActive\tTotal\tPercent Avail\n%sMB\t%sMB\t%sMB\t%s\n\n",$4+$5,$6,\$4+$5+$6,($4+$5)/($4+$5+$6)*100}
awk: cmd. line:1:                       ^ backslash not last character on line
awk: cmd. line:1: BEGIN {FS=" "}{printf \"\nAvail\tActive\tTotal\tPercent Avail\n%sMB\t%sMB\t%sMB\t%s\n\n",$4+$5,$6,\$4+$5+$6,($4+$5)/($4+$5+$6)*100}
awk: cmd. line:1:                       ^ syntax error    USER   %CPU   %MEM      RSZ COMMAND
    root    0.0   15.1   555.68 MB /usr/local/cpanel/3rdparty/bin/clamd
   mysql    0.3    3.9  146.953 MB /usr/sbin/mysqld
g33kinfo    9.7    2.1  77.5586 MB php-fpm:
g33kinfo    4.6    1.5  58.4375 MB php-fpm:
    root    1.0    1.4  54.9141 MB /opt/alt/php74-imunify/usr/bin/php
    root    2.4    1.0  39.1133 MB /opt/alt/python35/bin/python3
    root    1.7    0.9  36.0352 MB /opt/alt/python35/bin/python3
    root    0.0    0.7   26.918 MB cpsrvd
    root    0.0    0.6  25.3125 MB lfd

Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com)   01/27/2021      _x86_64_        (4 CPU)

02:43:31 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
02:43:33 PM    309532   3457452     91.78    215880   1616540   5070160     87.19   1404328   1709384       344
02:43:35 PM    390092   3376892     89.64    215880   1620340   4951008     85.14   1362512   1669656       412
02:43:37 PM    388080   3378904     89.70    215880   1621152   4973132     85.52   1364784   1670468       420
^C
02:43:38 PM    361204   3405780     90.41    215892   1622888   4999824     85.98   1390580   1672156       484
Average:       362227   3404757     90.38    215883   1620230   4998531     85.96   1380551   1680416       415

Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com)   01/27/2021      _x86_64_        (4 CPU)

02:43:38 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:43:40 PM     all      1.13      0.00      0.13     24.69      0.63     73.43
02:43:42 PM     all      3.99      0.00      2.58     23.07      2.32     68.04
02:43:44 PM     all      5.06      0.00      1.17     22.70      1.82     69.26
02:43:46 PM     all      0.12      0.00      0.25     24.72      0.50     74.41
02:43:48 PM     all      3.82      0.00      0.51     25.19      0.89     69.59
Average:        all      2.80      0.00      0.92     24.08      1.22     70.98

A more exhaustive command that shows memory usage can be seen here.

The nicely formatted output is below. 

== Server Time: ==
2021-01-27 02:50:06 PM

== Memory Utilization Information: ==
Total Memory    Active Memory   Percentage Used
3678M           0M              0.00%

== Current Swap Usage: ==
DEVICE               USED              TOTAL    PERCENT USED
/dev/vda2  1499.74M  2000.00M  74.99%
== Top 10 Processes by Memory Usage: ==
USER    PID    %MEM  RSZ     COMMANDroot    2215   14.9  563148  /usr/local/cpanel/3rdparty/bin/clamdmysql   1191   3.9   150480  /usr/sbin/mysqldroot    15187  1.4   56232   /opt/alt/php74-imunify/usr/bin/phproot    12576  1.0   40084   /opt/alt/python35/bin/python3root    13002  0.7   27564   cpsrvdroot    47801  0.6   25920   lfdnobody  99176  0.6   25212   /usr/sbin/httpdnobody  99324  0.6   25080   /usr/sbin/httpdnobody  40054  0.6   24152   /usr/sbin/httpd
root    15420  0.6   23912   /usr/local/cpanel/3rdparty/bin/perl

== Top 10 Processes By Swap Usage: ==
PID    PROCESS     SWAP
2215   clamd       633.36M
1364   named       292.50M
977    rsyslogd    149.05M
1191   mysqld      109.23M
52159  php-fpm     72.66M
1360   dockerd     35.03M
52164  php-fpm     28.88M
1025   containerd  28.64M
939    tuned       12.85M
1056   run-script  12.51M

== Top 10 Kernel Slab Caches: ==
SIZE     NAME
106.41M  ext4_inode_cache
51.34M   radix_tree_node
21.59M   kmalloc-2048
14.27M   dentry
12.16M   inode_cache
9.45M    buffer_head
9.06M    kmalloc-512
6.25M    kmalloc-192
5.88M    kmalloc-256
3.84M    kmalloc-1024

== Last 30 Minutes Memory Usage: ==
02:10:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
02:20:01 PM    394892   3372092     89.52    186972   1791996   4502996     77.44   1702664   1330604       140
02:30:01 PM    278952   3488032     92.59    182660   1844708   4583800     78.83   1763660   1382000      1072
02:40:01 PM    478732   3288252     87.29    211216   1584016   4980100     85.64   1468992   1467576       144
02:50:01 PM    516000   3250984     86.30    260268   1414912   5030872     86.52   1259140   1617076       828
Average:       417144   3349840     88.93    210279   1658908   4774442     82.11   1548614   1449314       546

== Last 30 Minutes Paging/Swap Statistics: ==
02:10:01 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
02:20:01 PM    293.67     82.92   5881.40      4.30   3205.94     50.32      0.00     48.36     96.09
02:30:01 PM    183.14     60.00   4211.40      3.46   2441.86     27.97      0.00     27.47     98.21
02:40:01 PM    886.77    109.05   4756.09      1.31   3219.39     54.63      0.00     51.24     93.79
02:50:01 PM   1987.77    146.82   9831.37      5.97   7140.46    173.18     48.66    218.12     98.33
Average:       838.22     99.71   6171.33      3.76   4002.99     76.56     12.18     86.34     97.30

== Current 1 Second Memory Usage Statistics (10 Count): ==
02:50:10 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
02:50:11 PM    561296   3205688     85.10    260344   1436072   4820100     82.89   1210256   1630628       396
02:50:12 PM    581888   3185096     84.55    260356   1444944   4769172     82.02   1180624   1639364       644
02:50:13 PM    578084   3188900     84.65    260356   1449008   4769176     82.02   1180404   1643412       828
02:50:14 PM    577960   3189024     84.66    260356   1449164   4769176     82.02   1180404   1643504       848
02:50:15 PM    573992   3192992     84.76    260356   1453148   4769176     82.02   1180412   1647512       872
02:50:16 PM    550716   3216268     85.38    260356   1453304   4813672     82.78   1204252   1647616       892
02:50:17 PM    569768   3197216     84.87    260356   1457372   4769168     82.02   1180928   1651716       916
02:50:18 PM    569752   3197232     84.88    260364   1457448   4769168     82.02   1180448   1651752       940
02:50:19 PM    567892   3199092     84.92    260364   1459156   4769168     82.02   1180456   1653500       960
02:50:20 PM    567892   3199092     84.92    260364   1459272   4769168     82.02   1180492   1653556       984
Average:       569924   3197060     84.87    260357   1451889   4778714     82.18   1185868   1646256       828

== Current 1 Second Paging/Swap Statistics (10 Count): ==
02:50:10 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
02:50:11 PM   4096.00      0.00  11152.00      0.00    372.00      0.00      0.00      0.00      0.00
02:50:12 PM   8852.00    476.00  18888.00      3.00  19614.00      0.00      0.00      0.00      0.00
02:50:13 PM   4096.00      0.00   1823.00      0.00   1055.00      0.00      0.00      0.00      0.00
02:50:14 PM      0.00      0.00     34.00      0.00     49.00      0.00      0.00      0.00      0.00
02:50:15 PM   4096.00      0.00     38.00      0.00     54.00      0.00      0.00      0.00      0.00
02:50:16 PM      0.00      0.00  11140.59      0.00   1865.35      0.00      0.00      0.00      0.00
02:50:17 PM   4096.00      0.00  15499.00      0.00  16205.00      0.00      0.00      0.00      0.00
02:50:18 PM      0.00     60.00     34.00      0.00     49.00      0.00      0.00      0.00      0.00
02:50:19 PM   1780.00      0.00     34.00      0.00     50.00      0.00      0.00      0.00      0.00
02:50:20 PM      0.00      0.00     40.00      0.00     66.00      0.00      0.00      0.00      0.00
Average:      2698.90     53.55   5873.53      0.30   3935.86      0.00      0.00      0.00      0.00
root@host [~]#

Granted, this is a massive amount of output data, but having tools like this only serves to bolster our overall memory usage view. 

Disk I/O

In searching for load issues caused by disk I/O, access time is the driving factor. Disk I/O is the input/output operation on a physical disk drive. If the server reads or writes data to or from a disk file, the processor waits for the file to be written or read. Since older hard drives tend to be mechanical, the server waits to rotate to the disk to the required disk sector.

Typically, the easiest method to observe high disk I/O throughput is to use the iotop command. Running this provides an easy readout displaying where disk I/O may be originating. 

Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
     1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd --switched-root --system --deserialize 22
     2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
     4 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]
     6 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
     7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
     8 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_bh]
     9 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_sched]
    10 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [lru-add-drain]
    11 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    12 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/1]
    13 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]

Another commandline tool that can show disk I/O is atop. The command atop provides a more comprehensive view of the hardware.

If looking at the DSK row, we can see the following info.

DSK |  vda |  busy 0% |  read 0 |  write 5 |  KiB/r  0 |  KiB/w  33  | MBr/s 0.0  | MBw/s    0.0  | avq     1.00  | avio 0.20 ms

One final command that indicates I/O usage can be seen here. 

root@host [~]# dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.57465 s, 417 MB/s
root@host [~]#

This command does an actual read/write check of the disk to measure throughput. It sends/receives one GB of data to the disk and then calculates the speed and how fast it was transferred. In this case, it moved 417MB/s.

To address load caused by I/O wait, we must lower the number of read/writes, modify our configurations that utilize I/O (like mysql), or use a faster disk drive. Modern SSD drives reduce this issue significantly. More advanced techniques can be used but require a developer or systems administrator to implement.

Networking

Typically, only a few factors define load caused by networking issues. These include network saturation, incorrectly configured networking protocols, and malicious traffic.

Symptoms of network saturation include, but are not limited to, dropped packets, unreachable websites, and increased server load (from trying to digest the influx of inbound traffic). Additionally, suppose a web application firewall or software firewall is in place, and firewall rules are misconfigured (such as trying to block a significant number of IPs from multiple countries). In that case, the load can occur due to the increased workload from that application.

With the rise in streaming, running multiple large video streams from a site can also cause stress the outbound network connections. This stress can reduce the overall flow of traffic, increasing load considerably. 

IPTraf

One of the tools we can use to examine the amount of traffic we are receiving is IPTraf. 

The iptraf-ng command brings up a graphical interface that allows us to select multiple options for viewing the network connections. In the menu, first, select IP traffic monitor and then All interfaces to show all traffic on eth0, lo, docker, and other available interfaces.

When selecting “General interface statistics,” we see the following info. 

iptraf-ng 1.1.4
┌ Iface ── Total ── IPv4 ── IPv6 ── NonIP ── BadIP ── Activity ──────────┐
│ lo       68       68      0       0        0        6.98 kbps          │
│ eth0     541      507     34      0        0        23.22 kbps         │
│ docker0  0        0       0       0        0        0.00 kbps          │
─────────────────────────────────────────────────────
────────────
─────────

When selecting “Statistical breakdowns,” we see this information. 

iptraf-ng 1.1.4
┌ Proto/Port ─ Pkts ─ Bytes ─ PktsTo ─ BytesTo ─ PktsFrom ─ BytesFrom ─────────────────────────────────────────────────────────────────────┐
│ TCP/443       528    226088  289     109761     239       116327                                                              
│ UDP/53        6      563     3       204        3         359                                                              │
 TCP/80        22     2475    13      1289       9         1186                                                              
│ UDP/546       6      820     0       0          6         820                                                              
│ UDP/547       6      820     6       820        0         0                                                              
│ TCP/21        18     586     10      488        8         1098                                                              
│ TCP/110       16     904     10      536        6         368  

This tool provides a unique view of the amount of traffic moving in and out of the server. It can help us track down networking backups based on the amount of traffic we are receiving on which interface and port. 

To lower the load caused by these issues, we must lower or limit the type or amount of traffic. We must also ensure that our network configurations are not contributing to this issue. 

Conclusion

A server will always have a slight load, which is expected. Linux can control most load concerns, but we must step in when needed to locate and lower high load issues. The tools above provide a solid base for tracking download problems no matter where it originates.

We pride ourselves on being The Most Helpful Humans In Hosting™!

Our technical support staff is always available to assist with any issues related to this article, 24 hours a day, 7 days a week 365 days a year.

We are available, via our ticketing systems at support@liquidweb.com, by phone (at 800-580-4986) or via a LiveChat or whatever method you prefer. We work hard for you so you can relax.

The post How to Investigate Server Load: Part 2 appeared first on Liquid Web.

Introduction

Zabbix is an open-sourced tool used to monitor various IT components such as servers and hardware that they are running, cloud services, whole networks, etc. Zabbix can monitor the network health and integrity of your servers. All monitoring can be done through Zabbix’s web-based frontend. This means that you can quickly check the status of your servers from anywhere! This article describes how to install the Zabbix monitoring tool, create a database, and configure the frontend on Ubuntu 20.04.

Prerequisites

Here is a summary of the requirements needed to complete this tutorial.

• OS: Ubuntu 20.04 (Self Managed)
• User Type: Root/basic Linux user (Typical Linux users will need to add the sudo command)
• Software: Apache, MySQL, Zabbix, PHP version 7.2+ or >

Install the Zabbix Monitoring Tool

First, let’s grab the Zabbix .deb file for adding the repository using the wget command.

root@host:~# wget https://repo.zabbix.com/zabbix/5.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.2-1+ubuntu$(lsb_release -rs)_all.deb

After running this command, we will see a download bar similar to the one below.

zabbix-release_5.2-1+ub 100%[===============================>] 

Add Zabbix Repository

Once the repository is added, install it using the dpkg command.

root@host:~# dpkg -i zabbix-release_5.2-1+ubuntu$(lsb_release -rs)_all.deb

After you run the command above, you will see an output like this.

Selecting previously unselected package zabbix-release.
(Reading database ... 96998 files and directories currently installed.)
Preparing to unpack zabbix-release_5.2-1+ubuntu20.04_all.deb ...
Unpacking zabbix-release (1:5.2-1+ubuntu20.04) ...
Setting up zabbix-release (1:5.2-1+ubuntu20.04) ...

The repository is now ready to use. Next, run an update to refresh the repository information.

root@host:~# apt update

Hit:1 http://syspackages.sourcedns.com/packages/stable/ubuntu focal InRelease 
Hit:2 http://security.ubuntu.com/ubuntu focal-security InRelease
Get:3 http://repo.zabbix.com/zabbix/5.2/ubuntu focal InRelease [4,930 B]
Hit:4 http://us.archive.ubuntu.com/ubuntu focal InRelease
Hit:5 http://us.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:6 http://us.archive.ubuntu.com/ubuntu focal-backports InRelease
Get:7 http://repo.zabbix.com/zabbix/5.2/ubuntu focal/main Sources [1,202 B]
Get:8 http://repo.zabbix.com/zabbix/5.2/ubuntu focal/main amd64 Packages [3,231 B]
Fetched 9,363 B in 0s (19.1 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

Install Zabbix

Now that our server is up to date, we can now proceed with the installation of Zabbix. The next step is to install the Zabbix server, Zabbix frontend, and the Zabbix agent. We can accomplish this using a single command.

root@host:~# apt -y install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-agent

This output of this command will take some time to complete. We show the last few lines out of the output below.

Setting up libapache2-mod-php (2:7.4+75) ...
Setting up php-gd (2:7.4+75) ...
Setting up zabbix-apache-conf (1:5.2.4-1+ubuntu20.04) ...
Enabling conf zabbix.
To activate the new configuration, you need to run:
  systemctl reload apache2
Processing triggers for ufw (0.36-6) ...
Processing triggers for systemd (245.4-4ubuntu3.4) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Processing triggers for php7.4-cli (7.4.3-4ubuntu2.4) ...
Processing triggers for libapache2-mod-php7.4 (7.4.3-4ubuntu2.4) ...

Output like this will indicate a successful installation. Now we proceed to reload Apache as the command output informs us. Now that we installed Zabbix let’s create and configure a database. 

Database Creation and Configuration

Install MariaDB

First, we need to install MariaDB. Use the following command to accomplish this.

root@host:~# apt -y install mariadb-common mariadb-server-10.3 mariadb-client-10.3

Start MariaDB

Again, the output will be lengthy, but MariaDB will be installed successfully without errors if the previous steps are followed. Now, start MariaDB and enable it using the following command.

root@host:~# systemctl start mariadb && systemctl enable mariadb

Create and Configure the Zabbix Database

Now we can create the database for Zabbix. We can accomplish this using two separate commands. The first command will generate the database.

root@host:~# mysql -uroot -p'rootDBpass' -e "create database zabbix character set utf8 collate utf8_bin;"

The second command will grant privileges to the user and allow you to define your password. In this example, the password is YourPassworD1236.

root@host:~# mysql -uroot -p'rootDBpass' -e "grant all privileges on zabbix.* to zabbix@localhost identified by 'YourPassworD1236';"

Now we have to import the database schema. Make sure that we use the password that we set in the previous command. Importing the database schema will not provide any output, but it can take up to 5 minutes to run.

root@host:~# zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p'YourPassworD1236' zabbix

The next step is essential. Use your preferred text editor (we used vi) to edit the zabbix_server.conf file.

root@host:~# vi /etc/zabbix/zabbix_server.conf

Once you are inside the file, scroll down to the line below.

# DBPassword=

Add your previously defined password after the equal sign. You can exit vi by running :wq and then hitting enter. Next, we configure the firewall.

Configure the Firewall

Now, we need to open ports 10050, 10051, and 80 using the commands below. This allows the Zabbix agents to communicate with the server

root@host:~# ufw allow 10050/tcp
root@host:~# ufw allow 10051/tcp 
root@host:~# ufw allow 80/tcp

Then, reload the firewall using the ufw reload command. 

root@host:/# ufw reload 
Firewall reloaded

Enable Zabbix Server

We can now start and enable the Zabbix server and agent.

root@host:~# systemctl restart zabbix-server zabbix-agent
root@host:~# systemctl enable zabbix-server zabbix-agent

The final step in the process is to configure the Zabbix frontend.

Zabbix Frontend Configuration

We begin by editing the /etc/zabbix/apache.conf file.

root@host:~# vi /etc/zabbix/apache.conf

Find the following line and remove the “#” sign from the beginning of it.

php_value date.timezone Europe/Amsterdam

After removing the “#” sign, set the correct timezone for your location. In our case, we used America/Phoenix.
Next, exit the Apache configuration file by typing :wq and then pressing Enter.

Lastly, we restart and enable apache using the commands below.

root@host:~# systemctl restart apache2 && systemctl enable apache2
Synchronizing state of apache2.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apache2

Now we can connect to the Zabbix frontend in our browser using the following URL.

http://server_ip_address/zabbix

Of course, replace server_ip_address with your server’s IP address, like http://143.143.93.75/zabbix. Once entered, the following screen should show in your browser.

Now, click the Next Step button. Zabbix will verify all prerequisites are in place and working as expected. If the software and configurations are correct, everything should be marked with green OK. Click Next Step again to move on. 

Next, inside the Password field, please enter the password that we previously configured, which is YourPassworD1236. Continue to click on Next Step until you reach this screen.

How awesome is this? We have installed the Zabbix monitoring software successfully.
Now click Finish and input the default login information:

• Username: Admin
• Password: Zabbix

Change Default Password

Make sure to secure your account by resetting the default password after your first login. Below are instructions on how to do so through the Zabbix interface.

Click User Settings in the lower left part of the dashboard. 

Then click the Change Password button.

Two empty fields will appear at the top of the screen, where we can input our new password. Once we are done, click Update. We will then be sent back to the main dashboard page, with the message User Updated at the top of the screen. 

Zabbix Agents

The Zabbix agent is a small piece of software that is deployed on servers needing to be monitored. They actively monitor local resources and applications. The agents gather operational information and report back to the Zabbix server on ports 10020 and 10021. Zabbix agents are extremely efficient because of the use of native system calls for gathering statistical information.

Conclusion

And that’s it! Zabbix has been successfully installed. For further information on configuring tasks in the interface, see the quickstart documentation at zabbix.com. We hope this tutorial was easy to follow and that you will explore many of the useful features that Zabbix has at its disposal.

We pride ourselves on being The Most Helpful Humans In Hosting™! Our Support Teams are filled with experienced Linux technicians and talented system administrators who have intimate knowledge of multiple web hosting technologies, including those discussed in this article. Should you have any questions regarding this information, we will always answer any inquiries related to this article, 24 hours a day, 7 days a week, 365 days a year.

If you are a Fully Managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server, Managed Cloud Servers, or a Dedicated server owner, and you are uncomfortable with performing any of the steps outlined, we can be reached via phone at @800.580.4985, a chat or support ticket to assist you in this process.

The post How to Install and Configure Zabbix on Ubuntu 20.04 appeared first on Liquid Web.