《Nginx HTTP Server》

Chapter 2: Downloading and Installing Nginx

In this chapter, we will proceed with the necessary steps towards establishing a functional setup of Nginx. This moment is crucial for the smooth functioning of your web server—there are some required libraries and tools for installing the web server, some parameters that you will have to decide upon when compiling the binaries, and some extra configuration to do on your system.

This chapter covers:

  1. Downloading and installing the prerequisites for compiling the Nginx binaries
  2. Downloading a suitable version of the Nginx source code
  3. Configuring Nginx compile time options
  4. Controlling the application with an init script
  5. Configuring the system to launch Nginx automatically on startup

Setting up the prerequisites

As you can see, we have chosen to download the source code of the application and compile it manually, as opposed to installing it using a package manager such as Yum, Aptitude, or Yast. There are two reasons behind this choice—first, the package may not be available in the enabled repositories of your Linux distribution. On top of that, the rare repositories that offer to download and install Nginx automatically mostly contain outdated versions. More importantly, there is the fact that we need to configure a variety of significant compile time options. As a result of this choice, your system will require some tools and libraries for the compilation process.

Depending on the optional modules that you select at compile time, you will perhaps need different prerequisites. We will guide you through the process of installing the most common one such as GCC, PCRE, zlib, and OpenSSL.

GCC — GNU Compiler Collection

Nginx is a program written in C, so you will first need to install a compiler tool such as the GNU Compiler Collection (GCC) on your system. GCC usually comes with most distributions, but if, for some reason, you do not already have it, this step will be required.

GCC is a collection of free open source compilers for various languages—C, C++, Java, Ada, FORTRAN, and so on. It is the most commonly-used compiler suite in Linux world, and Windows versions are also available. A vast amount of processors are supported such as x86, AMD64, PowerPC, ARM, MIPS, and more.

First, make sure it isn't already installed on your system:

[alex@example.com ~]$ gcc

If you get the following output, GCC is correctly installed on your system and you can skip to the next section:

gcc: no input files

If you receive the following message, you will have to proceed with the installation of the compiler:

~bash: gcc: command not found

GCC can be installed using the default repositories of your package manager. Depending on your distribution, the package manager will vary—yum for Red Hat-based distribution, apt for Debian and Ubuntu, yast for SuSE Linux, and so on. Here is the typical way to proceed with the download and installation of the GCC package:

[root@example.com ~]# yum install gcc

If you use apt-get:

[root@example.com ~]# apt-get install gcc

If you use another package manager with a different syntax, you will probably find the documentation with the man utility. Either way, your package manager should be able to download and install GCC correctly, after having solved the dependencies automatically.

PCRE library

The Perl Compatible Regular Expression (PCRE) library is required for compiling Nginx. The Rewrite and HTTP Core modules of Nginx use PCRE for the syntax of their regular expressions, as we will discover in later chapters. You will need to install two packages—pcre and pcre-devel. The first one provides the compiled version of the library, whereas the second one provides development headers and source for compiling projects, which are required in our case.

Here are example commands that you can run in order to install both the packages.

Using yum:

[root@example.com ~]# yum install pcre pcre-devel

Or install all PCRE-related packages:

[root@example.com ~]# yum install pcre*

If you use apt-get:

[root@example.com ~]# apt-get install libpcre3 libpcre3-dev

If these packages are already installed on your system, you will receive a message saying something like Nothing to do, in other words, the package manager did not install or update any component.

zlib library

The zlib library provides developers with compression algorithms. It is required for the use of gzip compression in various modules of Nginx. Again, you can use your package manager to install this component as it is part of the default repositories. Similar to PCRE, you will need both the library and its source—zlib and zlib-devel.

Using yum:

[root@example.com ~]# yum install zlib zlib-devel

Using apt-get:

[root@example.com ~]# apt-get install zlib1g zlib1g-dev

These packages install quickly and have no known dependency issues.


The OpenSSL project is a collaborative effort to develop a robust, commercial-grade, full-featured, and open source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation—http://www.openssl.org

The OpenSSL library will be used by Nginx to serve secure web pages. We thus need to install the library and its development package. The process remains the same here—you install openssl and openssl-devel:

[root@example.com ~]# yum install openssl openssl-devel

Using apt-get:

[root@example.com ~]# apt-get install openssl openssl-dev

Please be aware of the laws and regulations in your own country. Some countries do not allow usage of strong cryptography. The author, publisher, and developers of the OpenSSL and Nginx projects will not be held liable for any violations or law infringements on your part.

Now that you have installed all the prerequisites, you are ready to download and compile the Nginx source code.

Downloading Nginx

This approach of the download process will lead us to discover the various resources at the disposal of server administrators—websites, communities, and wikis all relating to Nginx. We will also quickly discuss the different version branches available to you, and eventually select the most appropriate one for your setup.

Websites and resources

Although Nginx is a relatively new and growing project, there are already a good number of resources available on the World Wide Web (WWW) and an active community of administrators and developers.

The official website, which is at www.nginx.net, is rather simple and does not provide much information or documentation, other than links for downloading the latest versions. On the contrary, you will find a lot of interesting documentation and examples on the official wiki—wiki.nginx.org.

The wiki provides a large variety of documentation and configuration examples—it may prove very useful to you in many situations. If you have specific questions though, you might as well use the forums—forum.nginx.org. An active community of users will answer your questions in no time. Additionally, the Nginx mailing list, which is relayed on the Nginx forum, will also prove to be an excellent resource for any question you may have. And if you need direct assistance, there is always a bunch of regulars helping each other out on the IRC channel #Nginx on Freenode.

Another interesting source of information—the blogosphere. A simple query on your favorite search engine should return a good amount of blog articles documenting Nginx, its configuration, and modules.

It's now time to head over to the official website and get started with downloading the source code for compiling and installing Nginx. Before you do so, let us have a quick summary of the available versions and the features that come with them.

A recurrent question regarding development versions is "are they stable enough to be used on production servers?" Cliff Wells, founder and maintainer of the nginx.org wiki website and community, believes so—"I generally use and recommend the latest development version. It's only bit me once!". Early adopters rarely report critical problems. It is up to you to select the version you will be using on your server, knowing that the instructions given in this book should be valid regardless of the release as the Nginx developers have decided to maintain backwards compatibility in new versions. You can find more information on version changes, new additions, and bug fixes in the dedicated change log page on the official website.

Version branches

Igor Sysoev, a talented Russian developer and server administrator, initiated this open source project early in 2002. Between the first release in 2004 and the current version, which now serves over 6.55 percent of websites on the Internet, steady progress was made. The features are plenty and render the application both powerful and flexible at the same time.

There are currently three version branches on the project:

  • Stable version: This version is usually recommended, as it is approved by both developers and users, but is usually a little behind the development version above. The current latest stable version is 0.7.66, released on June 07, 2010.
  • Development version: This is the the latest version available for download. Although it is generally solid enough to be installed on production servers, you may run into the occasional bug. As such, the stable version is recommended, even though you do not get to use the latest features. The current latest development version is 0.8.40, released on June 07, 2010.
  • Legacy version: If for some reason you are interested in looking at the older versions, you will find two of them. There's a legacy version and a legacy stable version, respectively coming as 0.5.38 and 0.6.39 releases.


As of the stable version 0.7.66, Nginx offers an impressive variety of features, which, contrary to what you may think, are not all related to serving HTTP content. Here is a list of the main features of the web branch, quoted from the official website nginx.net:

  • Handling of static files, index files, and autoindexing; open file descriptor cache.
  • Accelerated reverse proxying with caching; simple load balancing and fault tolerance.
  • Accelerated support with caching of remote FastCGI servers; simple load balancing and fault tolerance.
  • Modular architecture. Filters include Gzipping, byte ranges, chunked responses, XSLT, SSI, and image resizing filter. Multiple SSI inclusions within a single page can be processed in parallel if they are handled by FastCGI or proxied servers.
  • SSL and TLS SNI support (TLS with Server Name Indication (SNI), required for using TLS on a server doing virtual hosting).

Nginx can also be used as a mail proxy server, although this aspect is not closely documented in the book:

  • User redirection to IMAP/POP3 backend using an external HTTP authentication server
  • User authentication using an external HTTP authentication server and connection redirection to an internal SMTP backend
  • Authentication methods:
  • SSL support
  • STARTTLS and STLS support

Nginx is compatible with many computer architectures and operating systems like Windows, Linux, Mac OS, FreeBSD, and Solaris. The application runs fine on 32 and 64 bit architectures.

Downloading and extracting

Once you have made your choice as to which version you will be using, head over to nginx.net and find the URL of the file you wish to download. Position yourself in your home directory, which will contain the source code to be compiled, and download the file using wget.

[alex@example.com ~]$ mkdir src && cd src
[alex@example.com src]$ wget http://nginx.org/download/nginx-0.7.66.tar.gz

We will be using version 0.7.66, the latest stable version as of June 07, 2010. Once downloaded, extract the archive contents in the current folder:

[alex@example.com src]$ tar zxf nginx-0.7.66.tar.gz

You have successfully downloaded and extracted Nginx. Now, the next step will be to configure the compilation process in order to obtain a binary that perfectly fits your operating system.

Configure options

There are usually three steps when building an application from source—the configuration, the compilation, and the installation. The configuration step allows you to select a number of options that will not be editable after the program is built, as it has a direct impact on the project binaries. Consequently, it is a very important stage that you need to follow carefully if you want to avoid surprises later, such as the lack of a specific module or files being located in a random folder.

The process consists of appending certain switches to the configure script that come with the source code. We will discover the three types of switches that you can activate; but let us first study the easiest way to proceed.

The easy way

If, for some reason, you do not want to bother with the configuration step, such as, for testing purposes or simply because you will be recompiling the application in the future, you may simply use the configure command with no switches. Execute the following three commands to build and install a working version of Nginx:

[alex@example.com nginx-0.7.66]# ./configure

Running this command should initiate a long procedure of verifications to ensure that your system contains all the necessary components. If the configuration process fails, please make sure to check the prerequisites section again, as it is the most common cause of errors. For information about why the command failed, you may also refer to the objs/autoconf.err file, which provides a more detailed report.

[alex@example.com nginx-0.7.66]# make

The make command will compile the application; this step should not cause any errors as long as the configuration went fine.

[root@example.com nginx-0.7.66]# make install

This last step will copy the compiled files as well as other resources to the installation directory, by default, /usr/local/nginx. You may need to be logged in as root to perform this operation depending on permissions granted to the /usr/local directory.

Again, if you build the application without configuring it, you take the risk to miss out on a lot of features, such as the optional modules and others that we are about to discover.

Path options

When running the configure command, you have the possibility to enable some switches that let you specify directory or file paths for a variety of elements. Please note that the options offered by the configuration switches may change according to the version you downloaded. The options listed below are valid with the stable version, release 0.7.66. If you use another version, run the configure --help command to list the available switches for your setup.

Using a switch typically consists of appending some text to the command line. For instance, using the --conf-path switch:

[alex@example.com nginx-0.7.66]# ./configure --conf-path=/etc/nginx/nginx.conf

Here is an exhaustive list of the configuration switches for configuring paths:

SwitchUsageDefault Value
--prefix=...The base folder in which Nginx will be installed./usr/local/nginx.
Note: If you configure other switches using relative paths, they will connect to the base folder.
For example: Specifying --conf- path=conf/nginx.conf will result in your configuration file being found at /usr/local/ nginx/conf/nginx.conf.
--sbin-path=...The path where the nginx binary file should be installed./sbin/nginx.
--conf-path=...The path of the main configuration file./conf/nginx.conf.
--error-log- path=...The location of your error log. Error logs can be configured very accurately in the configuration files.
This path only applies in case you do not specify any error logging directive in your configuration.
--pid-path=...The path of the Nginx pid file. You can specify the pid file path in the configuration file; if it's not the case, the value you specify for this switch will be used./logs/nginx.pid.
Note: The pid file is a simple text file containing the process identifier. It is placed in a well- defined location so that other applications can easily find the pid of a running program.
--lock-path=...The location of the lock file. Again, it can be specified in the configuration file, but if it isn't, this value will be used./logs/nginx.lock.
Note: The lock file allows other applications to determine whether or not the program is running. In the case of Nginx, it is used to make sure that the process is not started twice.
--with-perl_modules_path=...Defines the path to the Perl modules. This switch must be defined if you want to include additional Perl modules. 
--with-perl=...Path to the Perl binary file; used for executing Perl scripts. This path must be set if you want to allow execution of Perl scripts. 
--http-log-path=...Defines the location of the access logs. This path is used only if the access log directive is unspecified in the configuration files./logs/access.log.
--http-client-body-temp-path=...Directory used for storing temporary files generated by client requests./client_body_temp.
--http-proxy-temp-path=...Location of the temporary files used by the proxy./proxy_temp.
--http-fastcgi-temp-path=...Location of the temporary files used by the HTTP FastCGI module./fastcgi_temp.
--builddir=...Location of the application build. 

Prerequisites options

Prerequisites come in the form of libraries and binaries. You should by now have them all installed on your system. Yet, even though they are present on your system, there may be occasions where the configuration script cannot locate them. The reasons might be diverse, for example, if they were installed in nonstandard directories. In order to fix this problem, you are given the option to specify the path of prerequisites using the following switches. Miscellaneous prerequisite-related options are grouped together.

Compiler options 
--with-cc=...Specifies an alternate location for the C compiler.
--with-cpp=...Specifies an alternate location for the C preprocessor.
--with-cc-opt=...Defines additional options to be passed to the C compiler command line.
--with-ld-opt=...Defines additional options to be passed to the C linker command line.
--with-cpu-opt=...Specifies a different target processor architecture, among the following values: pentium, pentiumpro, pentium3, pentium4, athlon, opteron, sparc32, sparc64, and ppc64.
PCRE options 
--without-pcreDisables usage of the PCRE library. This setting is not recommended, as it will remove support for regular expressions, consequently disabling the Rewrite module.
--with-pcreForces usage of the PCRE library.
--with-pcre=...Allows you to specify the path of the PCRE library source code.
--with-pcre-opt=...Additional options for building the PCRE library.
MD5 options 
--with-md5=...Specifies the path to the MD5 library sources.
--with-md5-opt=...Additional options for building the MD5 library.
--with-md5-asmUses assembler sources for the MD5 library.
SHA1 options 
--with-sha1=...Specifies the path to the SHA1 library sources.
--with-sha1-opt=...Additional options for building the SHA1 library.
--with-sha1-asmUses assembler sources for the SHA1 library.
zlib options 
--with-zlib=...Specifies the path to the zlib library sources.
--with-zlib-opt=...Additional options for building the zlib library.
--with-zlib-asm=...Uses assembler optimizations for the following target architectures: pentium, pentiumpro.
OpenSSL options 
--with-openssl=...Specifies the path of the OpenSSL library sources.
--with-openssl-opt=...Additional options for building the OpenSSL library.

Module options

Modules, which will be discussed in Chapter 4 and further, need to be selected before compiling the application. Some are enabled by default and some need to be enabled manually, as you will see in the table below.

Modules enabled by default

The following switches allow you to disable modules that are enabled by default.

Modules enabled by defaultDescription
--without-http_charset_moduleDisables the Charset module for re-encoding web pages.
--without-http_gzip_moduleDisables the Gzip compression module. Disables the Server Side Include module.
--without-http_ssi_moduleDisables the Server Side Include module.
--without-http_userid_moduleDisables the User ID module providing user identification via cookies.
--without-http_access_moduleDisables the Access module allowing access configuration for IP address ranges.
--without-http_auth_basic_moduleDisables the Basic Authentication module.
--without-http_autoindex_moduleDisables the Automatic Index module.
--without-http_geo_moduleDisables the Geo module allowing you to define variables depending on IP address ranges.
--without-http_map_moduleDisables the Map module that allows you to declare map blocks.
--without-http_referer_moduleDisables the Referer control module.
--without-http_rewrite_moduleDisables the Rewrite module.
--without-http_proxy_moduleDisables the Proxy module for transferring requests to other servers.
--without-http_fastcgi_moduleDisables the FastCGI module for interacting with a FastCGI process.
--without-http_memcached_moduleDisables the Memcached module for interacting with the memcache daemon.
--without-http_limit_zone_moduleDisables the Limit Zone module for restricting resource usage according to defined zones.
--without-http_limit_req_moduleDisables the Limit Requests module allowing you to limit the amount of requests per user.
--without-http_empty_gif_moduleDisables the Empty Gif module for serving a blank GIF image from memory.
--without-http_browser_moduleDisables the Browser module for interpreting the User Agent string.
--without-http_upstream_ip_hash_moduleDisables the Upstream module for configuring load-balanced architectures.
Modules disabled by default

The following switches allow you to enable modules that are disabled by default.

Modules disabled by defaultDescription
--with-http_ssl_moduleEnables the SSL module for serving pages using HTTPS.
--with-http_realip_moduleEnables the Real IP module for reading the real IP address from the request header data.
--with-http_addition_moduleEnables the Addition module which lets you append or prepend data to the response body.
--with-http_xslt_moduleEnables the XSLT module for applying XSL transformations to XML documents.
Note: You will need to install the libxml2 and libxslt libraries on your system if you wish to compile these modules.
--with-http_image_filter_moduleEnables the Image Filter module that lets you apply modification to images.
Note: You will need to install the libgd library on your system if you wish to compile this module.
--with-http_geoip_moduleEnables the GeoIP module for achieving geographic localization using MaxMind's GeoIP binary database.
Note: You will need to install the libgeoip library on your system if you wish to compile this module.
--with-http_sub_moduleEnables the Substitution module for replacing text in web pages.
--with-http_dav_moduleEnables the WebDAV module (Distributed Authoring and Versioning via Web).
--with-http_flv_moduleEnables the FLV module for special handling of .flv (flash video) files.
--with-http_gzip_static_moduleEnables the Gzip Static module for sending pre-compressed files.
--with-http_random_index_moduleEnables the Random Index module for picking a random file as the directory index.
--with-http_secure_link_moduleEnables the Secure Link module to check the presence of a keyword in the URL.
--with-http_stub_status_moduleEnables the Stub Status module, which generates a server statistics and information page.
--with-google_perftools_moduleEnables the Google Performance Tools module.

Miscellaneous options

Other options are available in the configuration script, for example, regarding the mail server proxy feature or event management.

Mail server proxy options 
--with-mailEnables mail server proxy module. Supports POP3, IMAP4, SMTP. It is disabled by default.
--with-mail_ssl_moduleEnables SSL support for the mail server proxy. It is disabled by default.
--without-mail_pop3_moduleDisables the POP3 module for the mail server proxy. It is enabled by default when the mail server proxy module is enabled.
--without-mail_imap_moduleDisables the IMAP4 module for the mail server proxy. It is enabled by default when the mail server proxy module is enabled.
--without-mail_smtp_moduleDisables the SMTP module for the mail server proxy. It is enabled by default when the mail server proxy module is enabled.
Event management:
Allows you to select the event notification system for the Nginx sequencer. For advanced users only.
--with-rtsig_moduleEnables the rtsig module to use rtsig as event notification mechanism.
--with-select_moduleEnables the select module to use select as event notification mechanism. By default, this module is enabled unless a better method is found on the system—kqueue, epoll, rtsig, or poll.
--without-select_moduleDisables the select module.
--with-poll_moduleEnables the poll module to use poll as event notification mechanism. By default, this module is enabled if available, unless a better method is found on the system—kqueue, epoll, or rtsig.
--without-poll_moduleDisables the poll module.
User and group options 
--user=...Default user account for starting the Nginx worker processes. This setting is used only if you omit to specify the user directive in the configuration file.
--group=...Default user group for starting the Nginx worker processes. This setting is used only if you omit to specify the group directive in the configuration file.
Other options 
--with-ipv6Enables IPv6 support.
--without-httpDisables the HTTP server.
--without-http-cacheDisables HTTP caching features.
--add-module=PATHAdds a third-party module to the compile process by specifying its path. This switch can be repeated indefinitely if you wish to compile multiple modules.
--with-debugEnables additional debugging information to be logged.

Configuration examples

Here are a few examples of configuration commands that may be used for various cases. In these examples, the path switches were omitted as they are specific to each system and leaving the default values may simply function correctly.

Be aware that these configurations do not include additional third-party modules. Please refer to Chapter 5 for more information about installing add-ons.

About the prefix switch

During the configuration, you should take particular care over the --prefix switch. Many of the future configuration directives (we will approach in further chapters) will be based on the path you selected at this point. While it is not a definitive problem since absolute paths can still be employed, you should know that the prefix cannot be changed once the binaries have been compiled.

There is also another issue that you may run into if you plan to keep up with the times and update Nginx as new versions are released. The default prefix (if you do not override the setting by using the --prefix switch) is /usr/local/nginx—a path that does not include the version number. Consequently, when you upgrade Nginx, if you do not specify a different prefix, the new install files will override the previous ones, which among other problems, could potentially erase your configuration files and running binaries.

It is thus recommended to use a different prefix for each version you will be using:

./configure --prefix=/usr/local/nginx-0.7.66

Additionally, to make future changes simpler, you may create a symbolic link /usr/local/nginx pointing to /usr/local/nginx-0.7.66. Once you upgrade, you can update the link to make it point to /usr/local/nginx-newer.version. This will (for example) allow the init script to always make use of the latest installed version of Nginx.

Regular HTTP and HTTPS servers

The first example describes a situation where the most important features and modules for serving HTTP and HTTPS content are enabled, and the mail-related options are disabled.

./configure --user=www-data --group=www-data --with-http_ssl_module \

As you can see, the command is rather simple and most switches were left out. The reason being: the default configuration is rather efficient and most of the important modules are enabled. You will only need to include the http_ssl module for serving HTTPS content, and optionally, the "real IP" module for retrieving your visitors' IP addresses in case you are running Nginx as backend server.

All modules enabled

The next situation: the whole package. All modules are enabled and it is up to you whether you want to use them or not at runtime.

./configure --user=www-data --group=www-data \ 
    --with-http_ssl_module --with-http_realip_module \ 
    --with-http_addition_module --with-http_xslt_module \
    --with-http_image_filter_module --with-http_geoip_module \ 
    --with-http_sub_module --with-http_dav_module \
    --with-http_flv_module --with-http_gzip_static_module \ 
    --with-http_random_index_module \ 
    --with-http_secure_link_module --with-http_stub_status_module

This configuration opens up a wide range of possible configuration options. Chapters 4 to 7 provide more detailed information on module configuration.

With this setup, all optional modules are enabled, thus requiring additional libraries to be installed—libgeoip for the Geo IP module, libgd for the Image Filter module, libxml2, and libxslt for the XSLT module. You may install those prerequisites using your system package manager such as running yum install libxml2 or apt-get install libxml2.

Mail server proxy

This last build configuration is somewhat special as it is dedicated to enabling mail server proxy features—a darker side of Nginx. The related features and modules are all enabled.

./configure --user=www-data --group=www-data \ 
    --with-mail --with-mail_ssl_module

If you wish to completely disable the HTTP serving features and only dedicate Nginx to mail proxying, you can add the --without-http switch.

Note that in the commands listed above, the user and group used for running the Nginx worker processes will be www-data which implies that this user and group must exist on your system. Please refer to Chapter 1 for more information on adding users and groups to your system.

Build configuration issues

In some cases, the configure command may fail—after a long list of checks, you may receive a few error messages on your terminal. In most (if not all) cases, these errors are related to missing prerequisites or unspecified paths.

In such cases, proceed with the following verifications carefully to make sure you have all it takes to compile the application, and optionally consult the objs/autoconf.err file for more details about the compilation problem. This file is generated during the configure process and will tell you exactly where the process failed.

Make sure you installed the prerequisites

There are basically four main prerequisites: GCC, PCRE, zlib, and OpenSSL. The last three are libraries that must be installed in two packages: the library itself and its development sources. Make sure you have installed both for each of them. Please refer to the prerequisites section at the beginning of this chapter. Note that other prerequisites such as LibXML2 or LibXSLT might be required for enabling extra modules, for example, in the case of the HTTP XSLT module.

If you are positive that all prerequisites were installed correctly, perhaps the issue comes from the fact that the configure script is unable to locate the prerequisite files. In that case, make sure that you include the switches related to file paths, as described earlier.

For example, the following switch allows you to specify the location of the OpenSSL library files:

./configure [...] --with-openssl=/usr/lib64

The OpenSSL library file will be looked for in the specified folder.

Directories exist and are writable

Always remember to check the obvious; everyone makes even the simplest of mistakes sooner or later. Make sure the directory you placed the Nginx files in has read and write permissions for the user running the configuration and compilation scripts. Also ensure that all paths specified in the configure script switches are existing, valid paths.

Eventually, when all your issues are solved, you should be seeing a configuration summary more or less similar to the image below:

Compiling and installing

The configuration process is of utmost importance—it generates a makefile for the application depending on the selected switches and performs a long list of requirement checks on your system. Once the configure script is successfully executed, you can proceed with compiling Nginx.

Compiling the project equates to executing the make command in the project source directory:

[alex@example.com nginx-0.7.66]$ make

A successful build should result in a final message appearing: make[1]: leaving directory followed by the project source path.

Again, problems might occur at compile time. Most of these problems can originate in missing prerequisites or invalid paths specified. If this occurs, run the configure script again and triple-check the switches and all the prerequisite options. It may also occur that you downloaded a too recent version of the prerequisites that might not be backwards compatible. In such cases, the best option is to visit the official website of the missing component and download an older version.

If the compilation process was successful, you are ready for the next step: installing the application.

[alex@example.com nginx-0.7.66]$ make install

The make install command executes the install section of the makefile. In other words, it performs a few simple operations such as copying binaries and configuration files to the specified install folder. It also creates directories for storing log and HTML files if these do not already exist. The make install step is not generally a source of problems, unless your system encounters some exceptional error such as a lack of storage space or memory.

You might require root privileges for installing the application in the /usr/local/ folder, depending on the folder permissions.

Controlling the Nginx service

At this stage, you should have successfully built and installed Nginx. The default location for the output files is /usr/local/nginx, so we will be basing future examples on this.

Daemons and services

The next step is obviously to execute Nginx. However, before doing so, it's important to understand the nature of this application. There are two types of computer applications—those that require immediate user input thus running on the foreground and those that do not, thus running in the background. Nginx is of the latter type, often referred to as daemon. Daemon names usually come with a trailing 'd' and a couple of examples can be mentioned here—httpd the HTTP server daemon, named the name server daemon, or crond the task scheduler—although, as you will notice, it is not the case for Nginx. When started from the command line, a daemon immediately returns the prompt, and in most cases, does not even bother outputting data to the terminal.

Consequently, when starting Nginx you will not see any text appear on the screen and the prompt will return immediately. While this might seem startling, it is on the contrary a good sign; it means the daemon was started correctly and the configuration did not contain any errors.

User and group

It is of utmost importance to understand the process architecture of Nginx and particularly the user and groups its various processes run under. A very common source of troubles when setting up Nginx is invalid file access permissions—due to a user or group misconfiguration, you often end up getting 403 Forbidden HTTP errors because Nginx cannot access the requested files.

There are two levels of processes with possibly different permission sets:

  1. The Nginx master process, which should be started as root. In most Unix-like systems, processes started with the root account are allowed to open TCP sockets on any port, whereas other users can only open listening sockets on a port above 1024. If you do not start Nginx as root, standard ports such as 80 or 443 will not be accessible. Additionally, the user directive that allows you to specify a different user and group for the worker processes will not be taken into consideration.
  2. The Nginx worker processes, which are started under the account you specified in the configuration file with the user directive (detailed in Chapter 3). The configuration setting takes precedence over the configure switch you may have entered at compile time. If you did not specify any of those, the worker processes will be started as user nobody, and group nobody (or nogroup depending on your OS).

Nginx command-line switches

The Nginx binary accepts command-line arguments for performing various operations, among which is controlling the background processes. To get the full list of commands, you may invoke the help screen using the following commands:

[alex@example.com ~]$ cd /usr/local/nginx/sbin
[alex@example.com sbin]$ ./nginx -h

The next few sections will describe the purpose of these switches. Some allow you to control the daemon, some let you perform various operations on the application configuration.

Starting and stopping the daemon

You can start Nginx by running the Nginx binary without any switches. If the daemon is already running, a message will show up indicating that a socket is already listening on the specified port:

[emerg]: bind() to failed (98: Address already in use) [...]
[emerg]: still could not bind().

Beyond this point, you may control the daemon by stopping it, restarting it, or simply reloading its configuration. Controlling is done by sending signals to the process using the nginx –s command.

nginx -s stopStops the daemon immediately (using the TERM signal)
nginx –s quitStops the daemon gracefully (using the QUIT signal)
nginx –s reopenReopens the log files
nginx –s reloadReloads the configuration
评论 X

      Copyright 2011-2014. YiiBook.com