Nginx can be a bit of a bother to configure, especially since I want to buy in the configuration that my distribution provides.

On my Debian box, this is what the configuration layout looked like when I started. In the rest of this post, I will omit parts of the configuration that are not relevant.

# tree -d /etc/nginx/
/etc/nginx/
├── conf.d
├── modules-available
├── modules-enabled
├── sites-available
└── sites-enabled

The configuration was split into directories, and I would modify a single file in a directory. As an example, I added a notfound configuration file for a catch-all website that would be used for mispellings or mistyped URLs. This prevents nginx from redirecting a request for edoput.it to somethingelse.edoput.it.

# tree  /etc/nginx/
/etc/nginx/
├── sites-available
│   ├── default-server.conf
│   └── notfound.conf
└── sites-enabled
    ├── default-server.conf -> /etc/nginx/sites-available/default-server.conf
    └── notfound.conf -> /etc/nginx/sites-available/notfound.conf

The interesting bit about this layout is that there is an available folder and an enabled folder. Configuration files are stored in the available folder and symlinked from the enabled folder. This makes it easy to enable and disable a website without actually changing it. You can either create or delete a symbolic link in the filesystem but the actual configuration is never touched. This is extremely handy.

# rm /etc/nginx/sites-enabled/default-server.conf # disable default-server
# ln -s /etc/nginx/sites-enabled/default-server.conf /etc/nginx/sites-available/default-server.conf # enable default-server

The problem is that these command are a mouthful and could be abstracted. If you think we should take advantage of the available/enabled split then you should be interested in nginxctl. It is similar in spirit to nginx_ensite 1 but extends to the many kinds of resources that nginx has.

Once copied to /usr/local/bin/nginxctl, you create a new command to manage the resource you are interested in-for example, the configuration files in the sites directory:

# ln -s /usr/local/bin/nginxctl /usr/local/bin/sites

This also means that by replicating the available/enabled pattern for a resource you automatically get the command to work. As an example, I will show my current configuration: I have added directories for maps, streams , and upstreams and created a command for each of them.

# tree -d /etc/nginx
/etc/nginx/
├── conf.d
├── map-available
├── map-enabled
├── modules-available
├── modules-enabled
├── sites-available
├── sites-enabled
├── streams-available
├── streams-enabled
├── upstream-available
└── upstream-enabled
# tree /usr/local/bin
/usr/local/bin/
├── nginxctl
├── maps -> /usr/local/bin/nginxctl
├── sites -> /usr/local/bin/nginxctl
├── streams -> /usr/local/bin/nginxctl
└── upstreams -> /usr/local/bin/nginxctl

I found this extremely helpful for managing the complexity I created for myself. Moreover as you may have intuited by now, these are all commands available to shell scripts, which means you can build upon them to automate even more.

  1. And Apache’s a2ensite a2disite ↩