




















































Today, most softwares are designed to be modular and extensible. Nginx, with its great community, has an amazing set of modules out there that lets it do some pretty interesting things. Although most operating system distributions have Nginx binaries in their repositories, it is a necessary skill to be able to compile new, bleeding edge modules, and try them out. Now we will outline how one can go about compiling and installing Nginx with its numerous third-party modules.
tar -xvzf nginx-0.7.67.tar.gz
./configure --with-debug --with-http_ssl_module --with-http_realip_module --with-http_ssl_module --with-http_perl_module --with-http_stub_status_module
You can figure out more about what other modules and configuration flags use:
./configure --help
apt-get build-dep nginx
This will install all the required build dependencies, like PCRE and TLS libraries.
sudo make install
./configure ..... --add-module=/path/to/module
The important part is to point the –add-module flag to the right module path. The rest is handled by the Nginx configuration script.
sudo make install
If you have followed steps 1 to 10, it will be really easy for you to install any Nginx module.
If you want to check that the module is installed correctly, you can enter the following command:
nginx -V
A sample output is something as shown in the following screenshot:
This basically gives you the compilation flags that were used to install this particular binary of Nginx, indirectly listing the various modules that were compiled into it.
Nginx is a fairly stable piece of software which has been running in production for over a decade and has built a very strong developer community around it. But, like all software there are issues and bugs which crop up under the most critical of situations. When that happens, it's usually best to reload Nginx with higher levels of error logging and if possible, in the debug mode.
If you want the debug mode, then you will need to compile Nginx with the debug flag (--with-debug). In most cases, most of the distributions have packages where Nginx is precompiled with debug flag. Here are the various levels of debugging that you can utilize:
error_log LOGFILE [debug | info | notice | warn | error | crit | debug_core | debug_alloc | debug_mutex | debug_event | debug_http | debug_imap];
Downloading the example code
You can download the example code files here
If you do not set the error log location, it will log to a compiled-in default log location. This logging is in addition to the normal error logging that you can do per site. Here is what the various specific debug flags do:
Nginx allows us to log errors for specific IP addresses. Here is a sample configuration that will log errors from 192.168.1.1 and the IP range of 192.168.10.0/24:
error_log logs/error.log;
events {
debug_connection 192.168.1.1;
debug_connection 192.168.10.0/24;
}
This is extremely useful when you want to debug in the production environment, as logging for all cases has unnecessary performance overheads. This feature allows you to not set a global debug on the error_log, while being able to see the debug output for specific matched IP blocks based on the user's IP address.
Depending on the system that you have, it will offer one clean way of reloading your Nginx setup
All the preceding commands reload Nginx; they send a HUP signal to the main Nginx process. You can send quite a few control signals to the Nginx master process, as outlined in the following table. These let you manage some of the basic administrative tasks:
Let me run you through the simple steps of how you can reload Nginx from the command line.
If nothing comes, then it means that Nginx is not running on your system.
This is very useful while writing scripts, which control Nginx configuration. A good example is when you are deploying code on production; you will temporarily point the site to a static landing page.