Install Multiple PHP Versions Using EasyApache 4

Posted on by Kurtis Foley
Category: Tutorials, WHM + cPanel | Tags: , , , , ,

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.  

Note:
If you are still using EasyApache 3, please contact our support for assistance upgrading your server to EasyApache 4. EasyApache 3 is no longer being supported as of December 31st, 2018. This means there will be no further updates for this service. This can create security risks and should be addressed. Also, cPanel will not allow you to update to version 78 or newer using EasyApache 3. Before considering upgrading, please be sure you meet the following requirements.

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

          

Note:
If you are still running CentOS 5 or older “due to the security risks” we would highly recommend migrating to a newer operating system as soon as possible. More than likely your current server’s hardware is also obsolete. Due to the complexities of our packages, we would recommend migrating to a new server. If you need any assistance choosing a new server, please reach out to us. Our team will gladly assist you in selecting the perfect package that will provide you with the best performance possible.

  • 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/)
  1. 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.

Note:
By default EasyApache 4 comes with additional profiles that help minimize setup up time as there are a few options tailored to the end users’ needs. If needed you still have the ability to create your own profiles for even further customization. For more information on EasyApache 4 profiles, you can view this documentation from cPanel.

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.

Note:
If possible we would highly recommend using the most recent version of PHP as PHP version 5.6 and 7.0 will no longer have security updates as of January 1, 2019. For more information on supported PHP versions visit this link.

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.
  1. Click Edit under System PHP Versions.
  1. 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.
  1. 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. 

Whitelisting in ModSecurity

Posted on by Cameron Paxton | Updated:
Category: Tutorials | Tags: , , , , , , , , , ,

Broken down into two parts our article’s first section hits on “how to whitelist IPs or URIs,” for people who are somewhat familiar with ModSecurity but want to know further about the process. Our second section examines why we configure ModSecurity and how to prevent the security of the server from getting in the way of our work. If you have a Fully Managed Liquid Web server reach out to our Heroic Support team for assistance with whitelisting!

How to Whitelist IPs or URIs

“ModSecurity is a toolkit for real-time web application monitoring, logging, and access control.” (modsecurity.org).  In simple terms, this means that ModSec, also called mod_security or ModSecurity, is a web application firewall that can actively look for attacks to the system and stop malicious activity. However, sometimes these rules trigger when legitimate work is taking place, blocking your IP and stopping you or your developer’s until you can remove the IP block. The way around for being blocked is known as whitelisting, which essentially allows for a specific IP to access the server.   There are a few ways to whitelist a request in ModSec, either by IP or by URI (URIs are specific pages on the website). 

Getting Started

  1. Find your IP or ask your developer for theirs. (You can find this by going to ip.liquidweb.com)If you or your developer have a static IP (one that will not change), one way you can whitelist the ModSec rules is by IP.
  2. Find the ModSec error in the Apache error logs with the following command (Be sure to modify the command with your IP in place of “IP here.”):
    grep ModSec /usr/local/apache/logs/error_log | grep “IP here”.
  3. The output of this command will give you a list of hits for ModSecurity from you or your developer’s IP, which you can see below. While this looks intimidating, you will only want to pay attention to 3 bits of information highlighted.  Please note, the output will not show these colors when you are viewing the files.
Note
Blue = client, the IP which tripped the rule
Red = ID number of tripped rule within ModSec
Green = URI, the location where the error started from

[Fri May 25 23:07:04.178701 2018] [:error] [pid 78007:tid 139708457686784] [client 61.14.210.4:30095] [client 61.14.210.4] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "20000221"] [hostname "67.227.209.163"] [uri "/db/index.php"] [unique_id "WwjPWChxvG1CO4kz-D55eQAAACU"]

 

Whitelist By IP:

1. Once you have the correct ModSec error, you will need to edit the ModSec configuration. If you are using Easy Apache 4 you will find the configuration file with this path:
/etc/apache2/conf.d/modsec2/whitelist.conf

2. Open the file with your favorite text editor, such as vim, nano, or file manager like so:

vim /etc/apache2/conf.d/whitelist.conf

3.  The blue text above will be the IP address that you are whitelisting from the original error. You must keep the backslashes (\) and up-carrot (^) in order for the IP to be read correctly. Thus it will always look something like:

“^192\.168\.896\.321”

For for the id, noted in red, you will change the number after the colon, which will be the Apache error log like we saw above. This will look similar to:

Id:2000221

Add the following code with the colored sections edited to match your intended IP.SecRule REMOTE_ADDR "^64\.14\.210\.4" "phase:1,nolog,allow,ctl:ruleEngine=off,id:20000221"

 

Whitelist By URI:

If your IP is dynamic (changing) and you keep getting blocked in the firewall, it is best to whitelist it via URI, the yellow item in the ModSec error.

1. Begin by opening the Easy Apache 4 configuration file:

vim /etc/apache2/conf.d/whitelist.conf

2. Add the following text to the configuration. Remember to pay attention to the highlighted parts.  Change the yellow “/db/index.php” to match your URI and the red id to match the id of your error (Do not use the colon in this one).

<LocationMatch "/db/index.php">
SecRuleRemoveById 20000221
</LocationMatch>

3. The final step for whitelisting, before you finalize the process, is to ensure you have correctly set up the whitelist. For Easy Apache 4 you will run the command:
apachectl -t

As long as the command returns “Syntax Ok” you are safe to make the whitelist active by restarting Apache. Otherwise, review the whitelists to make sure the syntax matches up correctly with the above directions.

4. Lastly, restart Apache with the following command.

/scripts/restartsrv_httpd

You have successfully whitelisted yourself in ModSec!

 

Using ModSec

Cyber Security is a hydra; once one threat is cut off, two more grow back. While this is not a new analogy, it’s important to understand as we battle threats to our network, computers, and servers. With all the complexities that come with security, I want to talk about adequately configuring ModSec to deter threats while still allowing you to work on your websites. Often, when it comes to server security, too much protection can hinder effectiveness.

For example, say you have the following set up on your server:

  • You do not allow root SSH login to the server
  • utilize dual-factor authentication for any SSH logins
  • use an SSH key for the sudo user and require other security safeguards

While this type of configuration is secure, it takes longer to log into your system to make a quick edit to your settings, a double-edged sword; how can you keep the server safe while not tying your own hands?  A great example of how this plays out is using ModSec.

ModSec can block your IP if it falsely flags your work. While this module improves system security, you’ll need to be aware of properly implementing and “scoping” the technology. Scoping in this sense means to manage risks, the focus of what is important for security while still allowing work on the server with minimal interference. To tune out legitimate requests to your server, such as when you are editing your website’s code via a plugin, ModSec has the options to whitelist rules or IPs and keep your work on track.

Whitelisting an IP from the rules that ModSec follows is a great option so long as the IP never changes (i.e. a static IP, see article here to learn more https://support.google.com/fiber/answer/3547208?hl=en) and is limited to only people you trust. This method prevents ModSec from viewing your requests as malicious and blocking your IP. This practice has the drawback that if someone (say an unhappy employee) has access to your network, they now have a way around ModSec to attack your server.

With non-static (dynamic) IPs the problems of whitelisting an IP are readily apparent. With the continual change of a dynamic IP, it creates the potential of exploiting your server, as someone could use an old IP to access the server. Whitelisting specific rules comes to save the day! When you whitelist by rules, you can edit with granularity and limit the rules to particular domains and URIs, protecting the rest of the server from attacks related to that same rule!

Example of ModSecurity

ModSec reads a series of rules and applies them to incoming requests being made to the web server. An example of what a block looks like is:

[Sat Jun 30 02:21:56.013837 2018] [:error] [pid 79577:tid 139862413879040] [client 120.27.217.223:24397] [client 120.27.217.223] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "2000064"] [hostname "67.227.192.139"] [uri "/mysql/index.php"] [unique_id "WzchhAjuZ6wPAzo9AwW1WwAAAE8"]

This error shows Apache stopped a potential attack on a file at /mysql/index.php. This is an error similar to what appears when the code is being written or edited within programs like Drupal or WordPress.

Evaluating ModSecurity

If you are persistently being blocked in your firewall while working on your code, ModSec is the likely culprit. The ModSec errors can be found in the Apache error log (in cPanel the path is /usr/local/apache/logs/error_log). The phrase “ModSec” can be quickly isolated from the log (via the command ‘grep “ModSec” /usr/local/apache/logs/error_log’). By comparing you or your developer(s) IP to the log, you’ll be able to identify stopped requests that are legitimate. Verify these are valid requests by double-checking that someone in your organization made them. Once you have done so, you can move forward in setting up a whitelist for the error, per the steps above.

Again, we want to scope to allow the least amount of wiggle room for an attack and ensure we can keep working. If you are unable to have a trusted static IP, you’ll need to use the whitelist URI  method, providing the specific page as an exemption. Once completed, remove both whitelisted items from the configuration file, in case of a genuine attack.

On a parting note, I encourage you to explore ModSec and learn more of the ins and outs of the software. Exploring different methods of whitelisting can be a lot of for to learn and most importantly helps to tighten server security. As always, our Fully Supported Customers can contact our Helpful Human Support team for assistance. Check out articles on security in our Knowledge Base, like this one on Maldet! It’s another excellent way to learn about your server and develop an understanding of server security.

What is mod_deflate?

Posted on by Helpful Humans of Liquid Web
Category: Technical Support, Tutorials | Tags: , , , ,

How mod_deflate works

When a visitor accesses a website, a request is made to the web server for a specific kind of data. An example might be a home page of a site. Next, the web server locates that data and delivers it to the client who is requesting that data – basically back to the web browser.

In this example, the speed at which the home page loads can depend on a variety of factors. One of them could be how long it takes to find and deliver the data for that page. This is just one example.

Some of that data – such as javascript files, css files, and php files – can actually be compressed into smaller sizes before they are delivered back to the visiting client or browser at the smaller size. The visitor can now have a more optimized browsing experience.

This is where mod_deflate comes in.

Continue reading “What is mod_deflate?” →

Using Passenger with cPanel on CentOS 7

Posted on by Helpful Humans of Liquid Web
Category: Technical Support | Tags: , , , ,

Phusion Passenger is a web application server that can run Ruby, Node.js, and Python applications on your webserver. It integrates with both Apache and Nginx to serve content to your visitors. Historically, this application was difficult to integrate with cPanel servers, which would combine the power of Ruby applications with the ease of management that cPanel provides, but recent advancements make setting up your Passenger module very simple. This easy walkthrough will show you how to add Passenger, Apache mod_passenger, and the supporting Ruby installation to cPanel. Continue reading “Using Passenger with cPanel on CentOS 7” →

EasyApache 4 & CLI based PHP utilities

Posted on by Dan Pock | Updated:
Category: Common Fixes, Featured Articles, Tutorials | Tags: , , , , ,

With the release of EasyApache 4 in WHM 58 there are various changes to how PHP is managed. The most obvious being that EasyApache 4 brings support for installing multiple PHP versions alongside each other. However with multiple versions of PHP being installed on the server it’s easy to lose track of your command-line based PHP utilities and their PHP requirements. Continue reading “EasyApache 4 & CLI based PHP utilities” →