nginx dynamic settings – part 2

In my previous post re. nginx dynamic settings, I’ve put an example of using variables in the index directive for serving a dynamic main file. This time I want to talk about try_files directive.

In the official examples, linked above, there is a one showing how to provide default place holder image, which is nice, and useful for hard set configurations. Most of the other examples are around internal rewrites to language interpreters.

Now say you host a Drupal multi-site, or WordPress multi-site and want to provide different favicon.ico files or robots.txt per domain, this can come handy. Here is an example:

location /favicon.ico {
    try_files $http_host.favicon.ico favicon.ico =404;
    log_not_found off;
    access_log off;
}

This way you can provide a default file for all, and specify a unique one for some.

Notice that for favicon.ico this doesn’t really cover it, since themes provide “shortcut icon” tags that override the default favicon. But for robots.txt this is very useful.

How to set dynamic nginx settings using variables

Looking through solutions on the internet, I found that for nginx there are plenty solution for dynamic root directories, headers and environment variables out there.

Today I was asked about using the same application directory with various cached index files, in this case, the determination is based on the domain accessed.

The previous solution used was to create spearate root directories with copies of the same system, which is wrong, just a waste of deployment time and configuration.

A more elegant solution, is to use the $http_host variable, and define a dynamic index file, like this:

index index.$http_host.php index.php index.html;

Now, be aware, this might not always be the best solution. also, most of the times, this will not be the specific setting or variable to use, but the idea is there.

Gitlab / Github set custom branch as default

When using Gitlab / Github for development with large development groups, with or without branch per feature, you probably would want to use a development branch, and setting it as a default is a good idea. so when making a new clone you will automatically be in the development branch.

You need to keep in mind that deploying will now require the usage of -b master in the clone command (unless you are using tags, which is really a better idea, but just to be fair, in old installations you can’t clone into tags, so you can… no, just upgrade)

I attached screenshots from both Gitlab and Github’s settings page, just change the “Default branch”.

Gitlab:

Github:

Apache and mime types

A few days ago I started a project of upgrading a CRM system written in PHP.

Now, the current server is using Apache 1.3.33 and PHP 5.1.6, old, right?, and, hold on, the server has a dual core x86 CPU, 4Gb of memory, which holds it for day to day use, but starts to squeak every now and then.

The new server has 8 cores, 8Gb of memory which can be upgraded since it is a Virtual Machine, a 64bit version of gentoo linux installed, and it runs Apache 2.2.24 with PHP 5.4.13 as a mod and is constantly updated.

I thought that the PHP syntax and function changes would be a pain, apparently that was nothing, Apache upgrade and non-planned configurations in the php code and file namings, they made the transfer more difficult.

The problem was that one specific file, a JS dictionary file with the name dict.hebrew.utf-8.js was being served with the encoding iso-8859-8 (Visual Hebrew), what made all the content seem like gibberish, funny, hu?

Snooping and searching the web, I tried simply setting the AddDefaultCharset UTF-8, but that did nothing, so I looked at my wall and saw the page saying RTFM, and so I did…

http://httpd.apache.org/docs/2.2/mod/mod_mime.html

Then it hit me, the setting AddCharset iso-8859-8 .hebrew is set before AddCharset UTF-8 .utf8 .utf-8 (I added the last one for compatibility) so I commented out the utf8 line and copied it to be the first AddCharset line, and WALLA, it did it.

So, to conclude my messy post… Remember Remember

  • First come first served
  • Name static files with language or encoding names thoughtfully
  • Try and read what the plans are for the technologies you are using for the system you are building
  • If your system has some hiccups, try to RTFM
  • The fifth of November

Yehuda