Archive for the ‘Web servers’ Category

OpenLiteSpeed WordPress cache mysteriously not working

Monday, September 17th, 2018

The OpenLiteSpeed web server (OLS) and LiteSpeed Cache for WordPress (LSCWP) plugin provide a great way of both speeding up WordPress and handing large numbers of visitors.

OLS is an open source derivative of the LiteSpeed Web Server (LSWS), which delivers most many of the key features, including the high performance LiteSpeed Cache (LSCache). Whilst it can’t read  Apache configuration files like its bigger brother LSWS (and thus can’t be used with a hosting control panel like cPanel or Plesk), it’s great for working with a handful of sites configured manually

Whilst the LSCWP plugin has a lot of useful features which can be used even without the LSCache from OLS/LSWS, the main selling point is the integration with LSCache to deliver blazing fast page load times along with massive scalability under load.

I recently ran into a bizarre issue where the cache just completely stopped working for no obvious reason, which led to hours of pulling apart WordPress and OLS to try and work out why.

Aside from pages loading very slowly, the main clue was that the X-Litespeed-Cache header was completely missing, although the X-Litespeed-Cache-Control header was present as normal. This would normally mean some kind of issue with the cache storage location (/usr/local/lsws/cachedata/ by default, unless override by the storagePath configuration option in the cache module settings).
I couldn’t see any issues with the cache storage location, but tried adjusting it elsewhere anyway without any luck.

I verified that all of the settings for the cache module were configured as per those listed on the OLS wiki and eventually out of frustration deleted the whole cache module definition from the server configuration and added it back, at which point the cache started working again!

I’ve absolutely no idea why removing and re-adding the exact same configuration should make any difference whatsoever, but I have now verified identical behaviour on two different servers with completely independent configurations.

OpenLiteSpeed OCSP stapling with Comodo PositiveSSL

Sunday, September 13th, 2015

OpenLiteSpeed supports OCSP stapling, which helps web browsers check the revocation status of an SSL certificate without having to connect to the Certificate Authority’s OCSP servers and so can speed up the SSL connection process.

In order to enable OCSP stapling, first we need to construct the intermediate certificate chain which OpenLiteSpeed will use to cryptographically verify the response from the CA’s OCSP server.

Take the COMODORSADomainValidationSecureServerCA.crt and COMODORSAAddTrustCA.crt files provided by Comodo when your certificate was issued and concatenate them into a single file

cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt > /etc/pki/tls/certs/PositiveSSL_chain.pem

Now log in to the OpenLiteSpeed WebAdmin console and perform the following steps:

  1. Click on “Configuration” on the navigation bar and then select “Listeners” from the drop down menu
  2. Click “View/Edit” on your HTTPS listener
  3. Click on the “SSL” tab
  4. Click “Edit” on the “OCSP Stapling” section
  5. Set “Enable OCSP Stapling” to “Yes”
  6. Set “OCSP Responder” to “”
  7. Set “OCSP CA Certificates” to the file containing the chained intermediate certificates created earlier (“/etc/pki/tls/certs/PositiveSSL_chain.pem” in my case).
  8. Click “Save”
  9. Perform a “Graceful Restart” of the OpenLiteSpeed server

If all has gone well, you now have OCSP stapling working. Click on “Actions” on the navigation bar and then select “Server Log Viewer” from the drop down menu or look in /usr/local/lsws/logs/error.log and check that you have a line saying “Enable OCSP Stapling successful!

You can also use the excellent SSL Server Test by Qualys’ SSL Labs at to check many attributes of your server’s SSL setup, including whether or not OCSP stapling is working.

Building httpd 2.4.6

Sunday, July 28th, 2013

When trying to build an RPM from the Apache source tarball, rpmbuild bails with:

RPM build errors:
Installed (but unpackaged) file(s) found:

The problem is that the file has been omitted from the httpd.spec file used to build the RPM.

Extract the tarball, open up httpd.spec in your favourite text editor and scroll down until you find a section that looks like:

%dir %{_libdir}/httpd
%dir %{_libdir}/httpd/modules


%dir %{contentdir}

This should start at line 308. Add in the following line:


You can now run rpmbuild again. You will either need to rebuild the tarball or change to using “rpmbuild -bb httpd.spec” instead of “rpmbuild -tb httpd-2.4.6.tar.bz2”.

SolusVM Nginx PHP bug

Monday, February 20th, 2012

It looks like there is a bug in the SolusVM Nginx installer which means that the php_cgi service doesn’t start on a reboot.

It seems that the installer sets the unused “spwan-fcgi” process to start, but not the “php_cgi” service that is actually used to handle SolusVM.

Luckily, this is easy enough to fix by running two commands on any of the master and slave servers which have Nginx installed:

chkconfig –add php_cgi
chkconfig php_cgi on

Commercial SSL certificates with SolusVM

Monday, February 6th, 2012

When you install SolusVM it generates a self signed SSL certificate for use with the end user control panel and admin interface, however it would be wise to purchase a certificate from a commercial certificate authority to prevent man in the middle attacks (and get rid of annoying browser warning messages).

There are two different methods of installing SSL certificates in SoluSVM depending on if you are using the original Lighttpd web-server or the new Nginx option.

For Lighttpd, you need to place the Base64 encoded DER form of both the private key and the x509 certificate in /usr/local/solusvm/ssl/solusvm.pem and then restart the Lighttpd web-server.

You may need to edit /etc/lighttpd/lighttpd.conf and set “” to be the path to the Base64 encoded DER form of the x509 certificate intermediate certificate for your Certificate Authority.

For Nginx, you place the Base64 encoded DER form of both the private key in /usr/local/solusvm/ssl/nginxcert.key and the Base64 encoded DER form of x509 certificate in /usr/local/solusvm/ssl/nginxcert.pem then restart the Nginx web-server.

If you need to include an intermediate certificate for your Certificate Authority, then this also goes in the /usr/local/solusvm/ssl/nginxcert.pem file in Base64 encoded DER form.

Convert SolusVM from Lighttpd to Nginx

Saturday, February 4th, 2012

Historically the brilliant SolusVM VPS control panel have used the Lighttpd web server on their master and slave nodes, however it is now possible to use the popular Nginx as an alternative web-server.

I’m a big fan of the performance and flexibly of Nginx, not to mention that in my opinion the Nginx configuration files are just much easier to write and maintain than Lighttpd.

Thanks to a nice, easy to use installation script, the process of converting the SolusVM master server/node from Lighttpd to Nginx, just requires running the following commands:

chmod 755 nginx-master-el5-x86_64

And to convert each of your SolusVM slave servers/nodes from Lighttpd to Nginx, it’s just as simple:

chmod 755 nginx-slave-el5-x86_64

Both of these examples assume that you are running your SolusVM master and slave servers/nodes on a 64-bit CentOS 5.x system, however if you are using CentOS 6.x then just substitute “el6” for “el5” in each of these commands.

As part of the installation process, a new self signed SSL certificate will be generated for Nginx, leaving the original SSL certificate used by Lighttpd in it’s place in case you need to roll back for any reason. The roll back is simply a case of stopping and disabling the Nginx and Spawn-FCGI services before re-enabling and starting the Lighttpd service:

chkconfig nginx off
chkconfig spawn-fcgi off
chkconfig lighttpd on
service nginx stop
service lighttpd start