Skip to content
Running Chive with Nginx
Failed to load latest commit information.
sites-available * IPv6 setup and Redmine config redmine reference on README. Apr 15, 2012
.gitignore * Added .gitignore. Improved README. Jan 29, 2011 * IPv6 setup and Redmine config redmine reference on README. Apr 14, 2012
fastcgi_params * Config updated. Fidelix helped with report. Feb 2, 2012
koi-utf * Initial commit. Jan 24, 2011
koi-win * Initial commit. Jan 24, 2011
mime.types * Initial commit. Jan 24, 2011
nginx.conf * Config updated. Fidelix helped with report. Feb 2, 2012
upstream_phpapache.conf * Removed images from gzip_types. Added reverse proxy setup. PHP uses Mar 1, 2011
upstream_phpcgi.conf * Added setup for php-fpm and info about securing PHP to the README. Apr 3, 2011

Nginx configuration for Chive


This is a nginx configuration for running Chive.

Chive is a next generation tool for managing a MySQL database through a web interface.

It's much better than phpMyAdmin, be it in terms of functionality and user experience, no to mention security. phpMyAdmin it's problably one of the most insecure web apps out there.

It assumes that the domain affect to Chive is

Change accordingly to reflect your server setup.

The configuration is splitted in secure (https) and standard (http).

The first is given in the file The second in of the sites-available directory


  1. Filtering of invalid HTTP Host headers.

  2. Access to Chive is protected using HTTP Basic Auth.

  3. Protection of all directories emulating the .htaccess files that come with Chive.

  4. Faster and more secure handling of PHP FastCGI by Nginx using named groups in regular expressions instead of using fastcgi_split_path_info. Requires Nginx version ≥ 0.8.25.

  5. Expire header for static assets set to the maximum.

  6. SSL/TLS configuration makes use of Strict Transport Security for protecting against MiTM attacks like sslstrip.

  7. IPv6 and IPv4 support.

  8. Possibility of using Apache as a backend for dealing with PHP. Meaning using Nginx as reverse proxy.

Basic Auth and HTTPS

The recommended way to run Chive is using https. Basic Auth is insecure because the password can be sniffed on the wire.

Ideally you should use approved Certificate Authorities issued TLS certificates. But if not then self signed certificates are fine. You just have to accept the exception in your browser.

If you're on Debian there's a make-ssl-cert(8) command for creating self signed certificates. It's included in the ssl-cert package.

If you're on Debian or any of its derivatives like Ubuntu you need either the thttpd-util or apache2-utils package installed.

With thttpd-util create your password file by issuing:

      thtpasswd -c .htpasswd-users <user> <password>

With apache2-utils create your password file by issuing:

      htpasswd -d -b -c .htpasswd-users <user> <password>

You should delete this command from your shell history afterwards with history -d <command number> or alternatively omit the -b switch, then you'll be prompted for the password.

This creates the file (there's a -c switch). For adding additional users omit the -c.

Of course you can rename the password file to whatever you want, then accordingly change its name in the virtual host config file, or

Nginx as a Reverse Proxy: Proxying to Apache for PHP

If you absolutely need to use the rather bad habit of deploying web apps relying on .htaccess, or you just want to use Nginx as a reverse proxy. The config allows you to do so. Note that this provides some benefits over using only Apache, since Nginx is much faster than Apache. Furthermore you can use the proxy cache and/or use Nginx as a load balancer.

IPv6 and IPv4

The configuration of the example vhosts uses separate sockets for IPv6 and IPv4. This way is simpler for those not (yet) having IPv6 support to disable it by commenting out the listen directive with the ipv6only=on parameter.

Note that the IPv6 address uses an IP stolen from the IPv6 Wikipedia page. You must replace the indicated address by your address.


  1. Move the old /etc/nginx directory to /etc/nginx.old.

  2. Clone the git repository from github:

    git clone

  3. Edit the sites-available/ or sites-available/ configuration file to suit your requirements. Namely replacing with your domain.

  4. Setup the PHP handling method. It can be:

    • Upstream HTTP server like Apache with mod_php. To use this method comment out the include upstream_phpcgi.conf; line in nginx.conf and uncomment the lines:

      include reverse_proxy.conf;
      include upstream_phpapache.conf;

      Now you must set the proper address and port for your backend(s) in the upstream_phpapache.conf. By default it assumes the loopback interface on port 8080. Adjust accordingly to reflect your setup.

      Comment out all fastcgi_pass directives in either drupal_boost.conf or drupal_boost_drush.conf, depending which config layout you're using. Uncomment out all the proxy_pass directives. They have a comment around them, stating these instructions.

    • FastCGI process using php-cgi. In this case an init script is required. This is how the server is configured out of the box. It uses UNIX sockets. You can use TCP sockets if you prefer.

    • PHP FPM, this requires you to configure your fpm setup, in Debian/Ubuntu this is done in the /etc/php5/fpm directory.

      Look here for an example configuration of php-fpm.

      Check that the socket is properly created and is listening. This can be done with netstat, like this for UNIX sockets:

      netstat --unix -l

      or like this for TCP sockets:

      netstat -t -l

      It should display the PHP CGI socket.

      Note that the default socket type is UNIX and the config assumes it to be listening on unix:/tmp/php-cgi/php-cgi.socket, if using the php-cgi, or in unix:/var/run/php-fpm.sock using php-fpm and that you should change to reflect your setup by editing upstream_phpcgi.conf.

  5. Create the /etc/nginx/sites-enabled directory and enable the virtual host using one of the methods described below.

    Note that if you're using the nginx_ensite script described below it creates the /etc/nginx/sites-enabled directory if it doesn't exist the first time you run it for enabling a site.

  6. Reload Nginx:

    /etc/init.d/nginx reload

  7. Check that Chive is working by visiting the configured site in your browser.

  8. Remove the /etc/nginx.old directory.

  9. Done.

Enabling and Disabling Virtual Hosts

I've created a shell script nginx_ensite that lives here on github for quick enabling and disabling of virtual hosts.

If you're not using that script then you have to manually create the symlinks from sites-enabled to sites-available. Only the virtual hosts configured in sites-enabled will be available for Nginx to serve.

Getting the latest Nginx packaged for Debian or Ubuntu

I maintain a debian repository with the latest version of Nginx. This is packaged for Debian unstable or testing. The instructions for using the repository are presented on this page.

It may work or not on Ubuntu. Since Ubuntu seems to appreciate more finding semi-witty names for their releases instead of making clear what's the status of the software included. Is it stable? Is it testing? Is it unstable? The package may work with your currently installed environment or not. I don't have the faintest idea which release to advise. So you're on your own. Generally the APT machinery will sort out for you any dependencies issues that might exist.

Running Chive in a subdirectory instead of a subdomain

You can run Chive in a subdirectory instead of a subdomain. Suppose that you run Chive in priv/chive. The config is:

   location /priv {
      ## Access is restricted using Basic Auth.
      auth_basic "Restricted Access"; # auth realm  
      auth_basic_user_file .htpasswd-users; # htpasswd file

      ## Chive configuration.
      location /priv/chive {

         ## Use PATH_INFO for translating the requests to the
         ## FastCGI. This config follows Igor's suggestion here:
         ## This is preferable to using:
         ## fastcgi_split_path_info ^(.+\.php)(.*)$
         ## It saves one regex in the location. Hence it's faster.
         location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
            include fastcgi.conf;
            ## The fastcgi_params must be redefined from the ones
            ## given in fastcgi.conf. No longer standard names
            ## but arbitrary: named patterns in regex.
            fastcgi_param SCRIPT_FILENAME $document_root$script;
            fastcgi_param SCRIPT_NAME $script;
            fastcgi_param PATH_INFO $path_info;
            ## Passing the request upstream to the FastCGI
            ## listener.
            fastcgi_pass unix:/tmp/php-cgi/php-cgi.socket;

         ## Protect these locations. Replicating the .htaccess
         ## rules throughout the chive distro.
         location /priv/chive/protected {

         location /priv/chive/yii {

My other Nginx configs on github

Securing your PHP configuration

I have created a small shell script that parses your php.ini and sets a sane environment, be it for development or production settings.

Grab it here.

Something went wrong with that request. Please try again.