cloudlinux – Reclaim Hosting https://www.reclaimhosting.com Take Control of your Digital Identity Thu, 08 Sep 2022 18:43:37 +0000 en-US hourly 1 https://wordpress.org/?v=6.5.4 https://www.reclaimhosting.com/wp-content/uploads/2018/09/RHprofilelogo-100x100.png cloudlinux – Reclaim Hosting https://www.reclaimhosting.com 32 32 Removing Advanced CloudLinux Apps in cPanel https://www.reclaimhosting.com/removing-advanced-cloudlinux-apps-in-cpanel/ https://www.reclaimhosting.com/removing-advanced-cloudlinux-apps-in-cpanel/#respond Tue, 07 Dec 2021 18:35:50 +0000 https://www.reclaimhosting.com/?p=36112 Continue reading "Removing Advanced CloudLinux Apps in cPanel"

]]>
Starting in January 2022, Reclaim Hosting is removing support for advanced CloudLinux applications in cPanel dashboards, as well as removing the ability to install these applications. Going forward, all advanced applications like Ruby, Python and Node.js should be managed in Reclaim Cloud.

You might be impacted by this change if you are currently using one of these advanced applications under the Software Section of your cPanel account. If you are interested in keeping these advanced applications, we strongly recommend they be moved to Reclaim Cloud. For those who aren’t familiar with Reclaim Cloud and would like a chance to look around prior to migrating, you can sign up for a free trial account with your .edu email address. (If you don’t have a .edu email, no problem, just let us know!) We also have a collection of Reclaim Cloud guides, including a Getting Started in Reclaim Cloud article that covers the basics.

Our team is in the process of reaching out directly to folks that are using Python, Ruby, and Node.js, both in Shared Hosting and Domain of One’s Own. If you are not inclined to move to a Reclaim Cloud environment, please note that your existing applications will no longer be compatible in Shared Hosting cPanels starting January 17, 2022. If you are a Domain of One’s Own school and would like keep CloudLinux installed on your server, please let us know so it is not automatically removed on 1/17/22.

Moving these advanced tools to Reclaim Cloud will let us focus our support and resources on environments where they are better suited to live. Please reach out to Reclaim Hosting Support if you have any questions, and do let us know how we can best support you and your work when this transition begins in January.

]]>
https://www.reclaimhosting.com/removing-advanced-cloudlinux-apps-in-cpanel/feed/ 0
Notes: LiteSpeed Certification Part 2 https://laurenhanks.com/notes-litespeed-certification-part-2/ Wed, 04 Aug 2021 21:46:45 +0000 https://laurenhanks.com/?p=5047 Picking up from yesterday, you can find my notes here: LiteSpeed Certification Part 1.

Understanding OPCache

By enabling OPCache, you can speed up PHP that cannot be cached. As with anything, this comes with pros and cons:

  • Pro: PHP is served faster by caching internal calls
  • Con: OPCache is cleared when restarting server or PHP services; increased RAM requirements because of the increased demand of OPCache’s cache storage handling // Update: newer versions of LSWS (starting with LSWS 5.3) were updated so OPCache no longer gets cleared upon restart– PHP remains in a detached state and is unaffected from server restarts

To enable OPCache, you either install the EasyApache package or enable it in CloudLinux PHP Selector, and then add the appropriate ‘on’ directive within the active php.ini file. Documentation on this can be found here and here.

Optimizations: Per-user INI Files

Users can enable specific, PHP-related .ini files for a single domain, multiple users, or all users by doing one of the following:

  1. Creating a .conf file in the appropriate include path for a domain; (single or multiple users)
  2. Modifying the appropriate .user.ini file (all users)

More info on this here.

Setting PHP Versions Per-Directory

This can be done using EasyApache (cPanel & WHM) or an alt-php (CloudLinux) version. The following line would be added to the .htaccess file of the directory that you’d like the PHP version to be altered:

AddType application/x-httpd-ea-php70___lsphp .php .php7 .phtml

^In this example, PHP 7.0 would be utilized, regardless of what the global version is. More info here. As a note, Cloudlinux PHP selector works with Apache but does not work with LSWS.

Troubleshooting LSPHP

Common issues might include 503 errors, timeouts, max connection issues, and missing script handlers.

503 Errors

When these errors arise, check the following:

  1. LVE Settings (if applicable) to see if there are limitations or restrictions at play
  2. for a potential attack occurring on the site in question
  3. LSWS Documentation on troubleshooting 503 errors

If none of the above works, add the following to the External Application Environment Variables, which will allow your server to provide debugging info:

LSAPI_ALLOW_CORE_DUMP=1

^This will also create dumps of the crash to be created for further analyzing.

Timeouts

When frequent timeouts are occurring, try the following:

  1. Turning off Abort Globally or at the site level
  2. Timeout override, allowing scripts to run longer

Max Connections- “Resource Limit Reached”

High Traffic sites can sometimes reach a max connection limit and will be put in a WaitQ state. When this happens, users will need to wait to get out of the WaitQ state, leading to higher page loading times and eventually timeout. A temporary fix:

  1. WebAdmin Console > Configuration > Server > General > Apache Configuration, then change PHP SuExec Max Connections to a higher number than the WaitQ value

Missing Script Handlers

The following screenshot from a LSWS Interface may be interpreted as errors given the level column:

What’s actually happening here is that these entries do not have the version of PHP required and installed from EasyApache. These messages can be safely ignored, and they should go away when the users installs the correct PHP versions.

Cloudlinux Integration

Helpful doc here. Not sure how relevant this section will be to Reclaim given our use of Reclaim Cloud, but will work through the possibilities anyway.

Ruby Python Selector

  • included with Cloudlinux as up LSWS 5.2, and recommended to get that everything is running properly with Apache before attempting to work in a LSWS environment. Info on switching to LSWS here.

Node.JS Selector

  • Included with Cloudlinux in version LSWS 5.3; if it works on Apache you should be good to go. No extra install script necessary

Finally, resources for troubleshooting the Cloudlinux integration can be found here. This may involve making sure that suEXEC is enabled and perhaps increasing the amount of Max Connections to a number higher than the default 10. Note that the Max Connection setting should be less than or equal to EP limit to avoid 500 or 503 errors. Use the following equation to determine the correct Max Connection setting:

SuExec_MaxConn = CloudLinux EP / #CPU License

ModSec Integration Overview

Items of note for ModSecurity’s integration with LiteSpeed:

  1. Custom ModSecurity engine
  2. Good integration with vendors such as Imunify360 and LiteSpeedspecific rules
  3. Rules only execute for dynamic requests and not static (Performance boost)
  4. Does not support audit logging mode event-driven architecture

QUIC and HTTP/2

QUIC and HTTP/2 are enabled by default with LSWS.

To disable QUIC, learn more here. To disable HTTP/2 or HTTP/3 learn more here. Its recommended to keep them on globally and then disable on a per-account basis fir the speed improvements they give.

General Troubleshooting

.htaccess-related issues

As a good rule of thumb, LSWS generally supports all the same rewrite and .htaccess rules that Apache does. That said, LiteSpeed can be a bit more strict in some instances, or may behave differently in others. For example:

If there is garbage or spam text in .htaccess, Apache would through a 500 error whereas LiteSpeed will typically ignore it. Also, the L last tag on Apache will continue processing, whereas LiteSpeed reads this as the last rule to run, so it would stop processing the rules for the request.

If you ever want to run rules on LiteSpeed only, not Apache, you can use the following tags:

<IfModule litespeed>
#Rules Here
</IfModule>

Cloudflare

Cloudflare enabled + 522 errors may mean that LSWS Anti-DDOS settings are causing connections to be blocked. From there you’d want to whitelist IPs as needed in LiteSpeed’s Allowed List (Server>Security>Allowed List.) More info here.

CSF Integration issues

CSF/other firewalls can cause issues with accessing the WebAdmin Console area. Make sure port 7080 is open inside of TCP IN/OUT. More info about open firewall ports here.

Log Locations for Debugging

  1. Error log: /usr/local/apache/logs/error_log
  2. stderr.log: /usr/local/apache/logs/stderr.log
  3. Rewrite log: /usr/local/apache/logs/error_log
  4. PHP error log: error_log under user account document root

And with that, I’m certified!

]]>
Patching Meltdown and Spectre https://blog.timowens.io/patching-meltdown-and-spectre/ Tue, 09 Jan 2018 20:50:20 +0000 https://www.reclaimhosting.com/?guid=2d0479bc877adde771243e11d0d20a65

Seems like every 1-2 years we get a major security scare in the form of a global exploit that effects server infrastructure in some fashion and requires a response. We've had Heartbleed, Poodle, Shellshock (who comes up with these names anyway?). 2018 didn't wait long to bring us that gift

]]>
Patching Meltdown and Spectre

Seems like every 1-2 years we get a major security scare in the form of a global exploit that effects server infrastructure in some fashion and requires a response. We’ve had Heartbleed, Poodle, Shellshock (who comes up with these names anyway?). 2018 didn’t wait long to bring us that gift in the form of Meltdown and Spectre. https://meltdownattack.com/ has a lot of great information about these two exploits but the short story is that rather than taking advantage of any particular software configuration, these exploits expose vulnerabilities in pretty much all modern CPUs. That means not only does this require patching for server admins like me at Reclaim Hosting and across the web, but every operating system from all computers including mobile devices and personal computers are vulnerable. The vulnerability takes advantage of exploits at the hardware as well as software layer to leak data into memory that can then be read by the attacker. It’s not a question of whether or not you are affected, you are affected.

Antivirus can’t block it either, only patching the underlying systems will resolve it and thankfully companies have been hard at work at getting these patches developed since long before the news became public. Intel became aware of the exploit last fall and many major companies have been under an NDA as they developed patches to secure their systems. Due to the complexity of this exploit however, we are still awaiting patches for some systems and now it is public (which will hopefully light a fire under certain groups to get these patches out).

Thankfully when we at Reclaim became aware of the issue last week CentOS, the distribution of Linux that powers over 90% of our server infrastructure and the only supported distribution for cPanel, was already releasing patches. We had to do some testing as well as await patches by Cloudlinux which is a third party that we use for our kernel software, but by Monday we felt confident the patches were safe and we set to work to patch our entire fleet. Normally with maintenance that involves downtime we like to give customers a heads up and with this kernel update requiring a reboot sites would indeed be offline for a few minutes, however we made the judgement call to rip the bandaid off and favor getting these patches in place as soon as possible rather than risk data being exposed as a result of the vulnerability. By 6PM Monday our entire infrastructure that runs cPanel and all CentOS servers were patched for these exploits with minimal downtime across the majority of our servers.

We have a small number of Ubuntu servers that we are still awaiting a production patch on and hope to receive that sometime this week. If you want to make sure you are secure, the best thing you can do is run all updates for your operating system and browser to make sure you’re running the absolute latest version. Due to the nature of the exploit there is no way to trace whether the vulnerability has been taken advantage of (it does not log any of its actions) so it’s particular important to be proactive. I’m proud of the capacity of Reclaim Hosting as a small operation to remain aware of these events and to stay on top of them in a timely manner.

Now can we take a nice long vacation from these major exploits? My spidey sense tells me that’s likely not to be the case as we come to rely more and more on computers and specifically internet-connected devices in our lives. It’s the new normal and the best security we can hope to have is proactive patching and awareness.

]]>