Another experience with Nginx, Drupal and CentOS

Another experience with Nginx, Drupal and CentOS

I had a chance to try NGINX on a CentOS 6 server with the intention of running Drupal 7 on it a few weeks ago. It was a little less easy than expected so I've decided to run through a few of the more tricky steps that I underwent in case I need to do it again, or indeed they are of help to others!

After running a

yum install nginx

I found that not all modules the NGINX Drupal configuration files required were present. After downloading the latest NGINX source and recompiling a few times to add in dependencies I skipped prior to this I found the following compile options worked for me.

One caveat is that the NGINX upload progress module should be downloaded first and placed in the /root/ directory (for the following compile options as that's the location set for the --add-module option!)

If PCRE is not installed, it should be, to allow URL rewrites:

yum install pcre-devel

Similarly, the compile options will require openssl for SSL support:

yum install openssl-devel

path=/usr/local/sbin --with-http_ssl_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-cc-opt="-I /usr/include/pcre" --pid-path=/var/run/ --lock-path=/var/lock/subsys/nginx --conf-path=/etc/nginx/nginx.conf --with-file-aio --with-http_flv_module --with-http_mp4_module --with-ipv6

After making and installing I moved the existing contents of /etc/nginx to a backup folder and cloned the Drupal settings from perusio's repository into /etc/nginx

git clone git://

I did make a few alterations to suit my system more appropriately but these may be omitted in other usecases:

  • Renamed the user from www-data to NGINX
  • Allowed access to NGINX status to an external IP address (my own)
  • Changed ports for PHP CGI server (as I had another service operating on port 9000)

Other than that, I created the myself a site config file within sites-available by copying the existing and inputting my own values. The most important values to check and/or change are:

  • server name (The vhost NGINX should be listening for ie
  • Log locations (debugging one large error log on a multi-site install is a major pain)
  • root (where the website is installed)

The only caveat with the above is that NGINX will only allow access to index.php as standard. To allow access externally to cron.php and update.php then the line including additional configuration will need to be uncommented:

include sites-available/drupal_cron_update.conf;

I use Drush for cron and update so this was not an issue in my install.

After all the time it took learning about NGINX configuration and after having used apache for years prior I decided to change back to apache for a number of reasons. The primary reason was the site experienced a few random lock ups. I'm unsure whether this was attributable to NGINX or PHP CGI, but having limited knowledge in the two I was unable to do much better than restart both services to clear the issue.

I did, however, find that NGINX config files were a little easier to understand at first glimpse over apache. Simple declarations and not a lot of them mean a site can be raised very easily without a great deal of worrying about

</VirtualHost> without matching <VirtualHost> section


Could not reliably determine the server's fully qualified domain name, using for ServerName

NGINX also seemed a little snappier using default untuned configuration compared to default untuned apache configuration. This may just be due to the server I was using being more suited to those defaults but it sure did seem more responsive from an end user perspective.

My overall conclusions would probably be to try it out, as it may work nicely for differing uses however for the time being I'll stick with apache. It does serve most websites after all!

Show Comments