WPCD supports two web servers:
There are many differences between the two servers. The biggest differences are:
Based on these differences you might find the need to use one or the other for certain installations.
All else being equal, if you’re looking for stability and Security, use NGINX.
NGINX has the most developers working on it, orders of magnitude more installations and has been around far far longer than OLS. Many of its edge cases & security issues have been revealed and fixed.
And if something goes wrong it will be far far easier to research and find solutions as well as find engineers familiar with it.
OLS is the new kid on the block and still has teething pains. There is far less consistency in how it does things, have fewer resources to call on when researching issues and have very few engineers available who can help resolve issues. It generally will exhibit weird behavior on an ongoing basis. It is growing rapidly but still has a way to go before it can be considered fully mature and has the same level of stability and consistency as NGINX.
Additionally, OLS has been inconsistent with how it’s handled security issues and is NOT recommended for shared servers at this time (see our note about OLS and shared servers later in this document).
Not Applicable – OLS cannot be installed at all on Ubuntu 18.04
Note the absence of PHP 5.6 and PHP 7.0
Note the absence of support for any PHP version earlier than 7.4.
The following broad areas of functions are available on NGINX servers but not OLS servers:
The following broad areas of functions are available on OLS servers but not NGINX servers:
The following are small functional differences between NGINX and OLS servers:
OLS will automatically handle HTTP2 when enabling and disabling SSL. NGINX requires a separate step.
For some operations, NGINX will require that HTTP2 be disabled while OLS will not have the requirement.
Using the INCLUDE functionality inherent in NGINX, we’re able to offer the admins the ability to add override directives to the WPCD NGINX configuration – without directly modifying our files. This can make it easier to keep you on the upgrade path if you wish to make web server configuration changes
With OpenLiteSpeed, there is no such functionality so changes you might wish to make to your OLS server configuration will need to be done directly to the WPCD OLS configuration files.
Security updates will automatically be applied for NGINX.
Security updates will not always be automatically applied for OLS. There are two reasons for this.
If an OLS package is properly tagged as a security update, we will automatically apply the update using the background updates process used for all other security updates.
Unfortunately you cannot depend on OLS to always tag the updates properly. So you must periodically check and compare the OLS version you’re running with that listed on their release pages.
You can check your OLS version by running this on the command line:
/usr/local/lsws/bin/openlitespeed -v
You can view the list of OLS versions here: https://github.com/litespeedtech/openlitespeed/releases
But, as we mentioned above, sometimes a version can be re-released with a later date but it will not necessarily show up on the releases page as such. You should compare the release date with the date of the assets. If they are different then you know that fixes were snuck into a release without changing the 3 digit version number. This is how they will sneak in security updates they don’t want to fully acknowledge.
There are two ways to force an OLS update:
apt-get upgrade openlitespeed
We hope that as the OLS product and development team matures that they start to handle security updates in the way the rest of the industry expects.
We cannot recommend using OpenLiteSpeed on shared servers at this time.
The reason is because what they say about how PHP should behave is not how it actually behaves under OLS.
PHP has a number of functions that are unsafe to use on shared servers. You can turn off these functions and, in OLS, you should be able to do it on two levels – the MASTER level or the SITE level. View more in their documentation.
Unfortunately, with a recent OLS update, this behavior is a bit broken. You cannot specify these functions on the site level so they have to be specified globally which affects all sites on the server.
Additionally, two functions, proc_open and proc_close cannot be restricted – otherwise WordPress sites cannot be installed. These functions can potentially give any user able to upload plugins and themes access to other areas of the server. This makes it dangerous to share multiple sites on a server with untrusted users.
Until these bugs are fixed, it is unsafe to run OLS in a shared server environment – you can only do so with containers (which WPCD does not use).
If you use OLS, you need to restrict it to one site or one customer per server.
While not recommended, you might want to do this for troubleshooting purposes.
Use this command to downgrade:
/usr/local/lsws/admin/misc/lsup.sh -v 1.7.15
Replace the 1.7.15 shown in the command above with the version number you want to downgrade to.