nginx
nginx (pronounced "engine X"), is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server, written by Igor Sysoev in 2005. According to Netcraft's April 2015 Web Server Survey, nginx now hosts 14.48% of all domains worldwide, while Apache hosts about 38.39%. nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.
Contents
- 1 Installation
- 2 Running
- 3 Configuration
- 4 Installation in a chroot
- 5 Tips and tricks
-
6 Troubleshooting
- 6.1 Configuration validation
- 6.2 Accessing local IP redirects to localhost
- 6.3 Error: The page you are looking for is temporarily unavailable. Please try again later. (502 Bad Gateway)
- 6.4 Error: No input file specified
- 6.5 Error: "File not found" in browser or "Primary script unknown" in log file
- 6.6 Error: chroot: '/usr/sbin/nginx' No such file or directory
- 6.7 Alternative script for systemd
- 7 See also
Installation
Install the package nginx-mainline (mainline branch : new features, updates, bugfixes) or nginx (stable branch : major bufixes only). Using the mainline branch is recommended.
The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the inadvertent introduction of bugs in new features[1].
For a Ruby on Rails setup with nginx, see Ruby on Rails#The Perfect Rails Setup.
For a chroot-based installation for additional security, see #Installation in a chroot.
Running
Start/enable nginx.service
using systemd.
The default served page at http://127.0.0.1 is /usr/share/nginx/html/index.html
.
Configuration
First steps with nginx are described in the Beginner’s Guide. You can modify the configuration by editing the files in /etc/nginx/
The main configuration file is located at /etc/nginx/nginx.conf
.
More details and examples can be found in http://wiki.nginx.org/Configuration and the official documentation.
The examples below cover the most common use cases. It is assumed that you use the default location for documents (/usr/share/nginx/html
). If that is not the case, substitute your path instead.
Configuration Example
/etc/nginx/nginx.conf
user http; worker_processes auto; pcre_jit on; events { worker_connections 2048; } http { include mime.types; default_type application/octet-stream; # include servers-enabled/*; # See Server blocks }
General configuration
Processes and connections
You should choose a fitting value for worker_processes
. This settings ultimately defines how many connection nginx will accept and how many processors it will be able to make use of. Generally, making it the number of hardware threads in your system is a good start. Alternatively, worker_processes
accepts the auto
value since versions 1.3.8 and 1.2.5, which will try to autodetect the optimal value (source).
The maximum connections nginx will accept is given by max_clients = worker_processes * worker_connections
.
Running under different user
By default, nginx runs the master process as root
and worker processes as user http
. To run worker processes as another user, change the user
directive in nginx.conf
:
/etc/nginx/nginx.conf
user user [group];
If the group is omitted, a group whose name equals that of user is used.
Server blocks
It is possible to serve multiple domains using server
blocks. It may be referred as "VirtualHosts", however this is an Apache term. The usage of server
blocks also differs to Apache.
In the example below the server listens for incoming connections for two domains: domainname1.dom
and domainname2.dom
:
/etc/nginx/nginx.conf
... server { listen 80; server_name domainname1.dom; root /usr/share/nginx/domainname1.dom/html; location / { index index.php index.html index.htm; } } server { listen 80; server_name domainname2.dom; root /usr/share/nginx/domainname2.dom/html; ... } ...
Restart the nginx
service to apply any changes.
You should configure a DNS-server like BIND or dnsmasq so that these domain names could be resolved for connecting clients.
For now you can just add them manually in /etc/hosts
replacing 192.168.0.101
with the actual IP address of server:
192.168.0.101 domainname1.dom 192.168.0.101 domainname2.dom
Managing server entries
It may be easier to use an Apache like Virtual hosts system.
Create the following directories:
# mkdir /etc/nginx/servers-available # mkdir /etc/nginx/servers-enabled
Create a file inside the servers-available
directory that contains one or more server blocks:
/etc/nginx/servers-available/example
server { .. }
Append the following line at the end of the http
block in /etc/nginx/nginx.conf:
include servers-enabled/*;
To enable a server
, simple create a symlink:
# ln -s /etc/nginx/servers-available/example /etc/nginx/servers-enabled/example
To remove a server
, delete the symlink:
# rm -rf /etc/nginx/servers-enabled/example
Reload or restart nginx
service to enable the new configuration.
TLS/SSL
OpenSSL provides TLS/SSL support and is installed by default on Arch installations.
Create a private key and self-signed certificate. This is adequate for most installations that do not require a CSR:
# mkdir /etc/nginx/ssl # cd /etc/nginx/ssl # openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 1095 # chmod 400 server.key # chmod 444 server.crt
If you need to create a CSR, follow these instructions instead of the above:
# mkdir /etc/nginx/ssl # cd /etc/nginx/ssl # openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key # chmod 400 server.key # openssl req -new -sha256 -key server.key -out server.csr # openssl x509 -req -days 1095 -in server.csr -signkey server.key -out server.crt
Example of a nginx.conf
using SSL:
/etc/nginx/nginx.conf
http { ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; # Google DNS Servers resolver_timeout 5s; server { #listen 80; # Uncomment to also listen for HTTP requests listen 443 ssl; server_name localhost; ssl_certificate ssl/server.crt; ssl_certificate_key ssl/server.key; root /usr/share/nginx/html; location / { index index.html index.htm; } }
Restart the nginx
service to apply any changes.
FastCGI
FastCGI, also FCGI, is a protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier CGI (Common Gateway Interface); FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more web page requests at once.
FastCGI technology is introduced into nginx to work with many external tools, i.e.: Perl, PHP and Python.
PHP implementation
PHP-FPM is the recommended solution to run as FastCGI server for PHP.
PHP configuration
Install the php and php-fpm packages.
Make sure open_basedir allows the directories containing PHP files to be accessed (starting with PHP 7.0 it is unset by default, so no change is required).
After that let us configure modules you need. For example to use sqlite3 you should install php-sqlite. Then enable it in /etc/php/php.ini
by uncommenting following line:
extension=sqlite3.so
The main configuration file of PHP-FPM is /etc/php/php-fpm.conf
. Enable and start the php-fpm
service.
MariaDB
Configure MySQL/MariaDB as described in MariaDB.
Uncomment at least one of the following lines in /etc/php/php.ini
:
extension=pdo_mysql.so extension=mysqli.so
You can add minor privileged MySQL users for your web scripts. You might also want to edit /etc/mysql/my.cnf
and uncomment the skip-networking
line so the MySQL server is only accessible by the localhost. You have to restart MySQL for changes to take effect.
nginx configuration
Adding to main configuration
Inside each server
block serving a PHP web application should appear a location
block similar to:
location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi.conf; }
If it is needed to process other extensions with PHP (e.g. .html and .htm):
location ~ \.(php|html|htm)$ { fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi.conf; }
Non .php extension processing in php-fpm should be explicitly added in /etc/php/php-fpm.d/www.conf
:
security.limit_extensions = .php .html .htm
The example shown below is a copy of a working configuration. Notice that in this example the root
path in specified directly under server
, and not inside location
(as it is in the default config).
server { listen 80; server_name localhost; root /usr/share/nginx/html; location / { index index.html index.htm index.php; } location ~ \.php$ { #fastcgi_pass 127.0.0.1:9000; (depending on your php-fpm socket configuration) fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi.conf; } }
PHP configuration file
If using multiple server
blocks with enabled PHP support, it might be easier to create a PHP config file instead:
/etc/nginx/conf/php.conf
location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi.conf; }
To enable PHP support for a particular server, simple include php.conf
:
/etc/nginx/nginx.conf
server = { server_name example.com; ... include php.conf; }
Test configuration
You need to restart the php-fpm
and nginx
daemons if the configuration has been changed in order to apply changes.
To test the FastCGI implementation, create a new PHP file inside the root
folder containing:
<?php phpinfo(); ?>
Navigate this file inside a browser and you will see the informational page with the current PHP configuration.
See #Troubleshooting section if you are experiencing problems with your configuration.
CGI implementation
This implementation is needed for CGI applications.
fcgiwrap
Install the fcgiwrap. The configuration file is /usr/lib/systemd/system/fcgiwrap.socket
. Enable and start the fcgiwrap.socket
.
Multiple worker threads
If you want to spawn multiple worker threads, it is recommended that you use multiwatchAUR, which will take care of restarting crashed children. You will need to use spawn-fcgi
to create the unix socket, as multiwatch seems unable to handle the systemd-created socket, even though fcgiwrap itself does not have any trouble if invoked directly in the unit file.
Copy the unit file from /usr/lib/systemd/system/fcgiwrap.service
to /etc/systemd/system/fcgiwrap.service
(and the fcgiwrap.socket
unit, if present), and modify the ExecStart
line to suit your needs. Here is a unit file that uses multiwatchAUR. Make sure fcgiwrap.socket
is not started or enabled, because it will conflict with this unit:
/etc/systemd/system/fcgiwrap.service
[Unit] Description=Simple CGI Server After=nss-user-lookup.target [Service] ExecStartPre=/bin/rm -f /run/fcgiwrap.socket ExecStart=/usr/bin/spawn-fcgi -u http -g http -s /run/fcgiwrap.sock -n -- /usr/bin/multiwatch -f 10 -- /usr/sbin/fcgiwrap ExecStartPost=/usr/bin/chmod 660 /run/fcgiwrap.sock PrivateTmp=true Restart=on-failure [Install] WantedBy=multi-user.target
Tweak -f 10
to change the number of children that are spawned.
nginx configuration
Inside each server
block serving a CGI web application should appear a location
block similar to:
location ~ \.cgi$ { root /path/to/server/cgi-bin; fastcgi_pass unix:/run/fcgiwrap.sock; include fastcgi.conf; }
The default socket file for fcgiwrap
is /run/fcgiwrap.sock
.
If you keep getting a 502 - bad Gateway
error, you should check if your CGI-application first announces the mime-type of the following content. For html this needs to be Content-type: text/html
.
Installation in a chroot
Installing nginx in a chroot adds an additional layer of security. For maximum security the chroot should include only the files needed to run the nginx server and all files should have the most restrictive permissions possible, e.g., as much as possible should be owned by root, directories such as /usr/bin
should be unreadable and unwriteable, etc.
Arch comes with an http
user and group by default which will run the server. The chroot will be in /srv/http
.
A perl script to create this jail is available at jail.pl gist. You can either use that or follow the instructions in this article. It expects to be run as root. You will need to uncomment a line before it makes any changes.
Create necessary devices
nginx needs /dev/null
, /dev/random
, and /dev/urandom
. To install these in the chroot create the /dev/
directory and add the devices with mknod. Avoid mounting all of /dev/
to ensure that, even if the chroot is compromised, an attacker must break out of the chroot to access important devices like /dev/sda1
.
# export JAIL=/srv/http # mkdir $JAIL/dev # mknod -m 0666 $JAIL/dev/null c 1 3 # mknod -m 0666 $JAIL/dev/random c 1 8 # mknod -m 0444 $JAIL/dev/urandom c 1 9
Create necessary directories
nginx requires a bunch of files to run properly. Before copying them over, create the folders to store them. This assumes your nginx document root will be /srv/http/www
.
# mkdir -p $JAIL/etc/nginx/logs # mkdir -p $JAIL/usr/{lib,bin} # mkdir -p $JAIL/usr/share/nginx # mkdir -p $JAIL/var/{log,lib}/nginx # mkdir -p $JAIL/www/cgi-bin # mkdir -p $JAIL/{run,tmp} # cd $JAIL; ln -s usr/lib lib
Then mount $JAIL/tmp
and $JAIL/run
as tmpfs's. The size should be limited to ensure an attacker cannot eat all the RAM.
# mount -t tmpfs none $JAIL/run -o 'noexec,size=1M' # mount -t tmpfs none $JAIL/tmp -o 'noexec,size=100M'
In order to preserve the mounts across reboots, the following entries should be added to /etc/fstab
:
/etc/fstab
tmpfs /srv/http/run tmpfs rw,noexec,relatime,size=1024k 0 0 tmpfs /srv/http/tmp tmpfs rw,noexec,relatime,size=102400k 0 0
Populate the chroot
First copy over the easy files.
# cp -r /usr/share/nginx/* $JAIL/usr/share/nginx # cp -r /usr/share/nginx/html/* $JAIL/www # cp /usr/bin/nginx $JAIL/usr/bin/ # cp -r /var/lib/nginx $JAIL/var/lib/nginx
Now copy over required libraries. Use ldd to list them and then copy them all to the correct location. Copying is preferred over hardlinks to ensure that even if an attacker gains write access to the files they cannot destroy or alter the true system files.
$ ldd /usr/bin/nginx
linux-vdso.so.1 (0x00007fffc41fe000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000) libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f57ec1b1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57ebead000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f57ebbaf000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57eb94c000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57eb6e0000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57eb2d6000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57eb0d2000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f57eaebc000) libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f57eac8d000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000) /lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000)
# cp /lib64/ld-linux-x86-64.so.2 $JAIL/lib
For files residing in /usr/lib
you may try the following one-liner:
# cp $(ldd /usr/bin/nginx | grep /usr/lib | sed -sre 's/(.+)(\/usr\/lib\/\S+).+/\2/g') $JAIL/usr/lib
Copy over some miscellaneous but necessary libraries and system files.
# cp /usr/lib/libnss_* $JAIL/usr/lib # cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc
Create restricted user/group files for the chroot. This way only the users needed for the chroot to function exist as far as the chroot knows, and none of the system users/groups are leaked to attackers should they gain access to the chroot.
$JAIL/etc/group
http:x:33: nobody:x:99:
$JAIL/etc/passwd
http:x:33:33:http:/:/bin/false nobody:x:99:99:nobody:/:/bin/false
$JAIL/etc/shadow
http:x:14871:::::: nobody:x:14871::::::
$JAIL/etc/gshadow
http::: nobody:::
# touch $JAIL/etc/shells # touch $JAIL/run/nginx.pid
Finally make set very restrictive permissions. As much as possible should be owned by root and set unwritable.
# chown -R root:root $JAIL/ # chown -R http:http $JAIL/www # chown -R http:http $JAIL/etc/nginx # chown -R http:http $JAIL/var/{log,lib}/nginx # chown http:http $JAIL/run/nginx.pid # find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod -rw # find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod +x # find $JAIL/etc -gid 0 -uid 0 -type f -print | xargs chmod -x # find $JAIL/usr/bin -type f -print | xargs chmod ug+rx # find $JAIL/ -group http -user http -print | xargs chmod o-rwx # chmod +rw $JAIL/tmp # chmod +rw $JAIL/run
If your server will bind port 80 (or any other port in range [1-1023]), give the chrooted executable permission to bind these ports without root.
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx
Modify nginx.service to start chroot
Before modifying the nginx.service
unit file, it may be a good idea to copy it to /etc/systemd/system/
since the unit files there take priority over those in /usr/lib/systemd/system/
. This means upgrading nginx would not modify your custom .service file.
# cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service
The systemd unit must be changed to start up nginx in the chroot, as the http user, and store the pid file in the chroot.
/etc/systemd/system/nginx.service
[Unit] Description=A high performance web server and a reverse proxy server After=syslog.target network.target [Service] Type=forking PIDFile=/srv/http/run/nginx.pid ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;' ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit [Install] WantedBy=multi-user.target
You can now safely get rid of the non-chrooted nginx installation.
# pacman -Rsc nginx
If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where /proc/PID/root
symmlinks to. If should link to /srv/http
instead of /
.
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done
Tips and tricks
Running unprivileged using systemd
Edit nginx.service and set the User
and optionally Group
options under [Service]
:
/etc/systemd/system/nginx.service.d/user.conf
[Service] User=user Group=group
We can harden the service against ever elevating privileges:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... NoNewPrivileges=yes
Then we need to ensure that user
has access to everything it needs:
- Port
-
Linux does not permit non-
root
processes to bind to ports below 1024 by default. A port above 1024 can be used:/etc/nginx/nginx.conf
server { listen 8080; }
-
Or you may grant the nginx process the CAP_NET_BIND_SERVICE capability which will allow it to bind to ports below 1024:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... CapabilityBoundingSet= CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities= AmbientCapabilities=CAP_NET_BIND_SERVICE
- PID file
-
nginx uses
/run/nginx.pid
by default. We can create a directory that user has write access to and place our PID file in there. An example using systemd-tmpfiles:/etc/tmpfiles.d/nginx.conf
d /run/nginx 0775 root group - -
Run the configuration:
# systemd-tmpfiles --create
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... PIDFile=/run/nginx/nginx.pid ExecStart= ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;' # copied from nginx.service
/var/lib/nginx/*
-
Some directories under
/var/lib/nginx
need to be bootstrapped by nginx running asroot
. It is not necessary to start the whole server to do that, nginx will do it on a simple configuration test. So just run one of those and you're good to go. - Remove logs
-
The step of running a configuration test will create a dangling
root
-owned log. Remove logs in/var/log/nginx
to start fresh.
Now we should be good to go. Go ahead and start nginx, and enjoy your completely rootless nginx.
Nginx Beautifier
Nginx beautifier is a commandline tool used to beautify and format nginx configuration files, it is available on AUR nginxbeautifierAUR
Troubleshooting
Configuration validation
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Accessing local IP redirects to localhost
Solution from the Arch Linux forum.
In /etc/nginx/nginx.conf
locate the server_name localhost
line without a #
in front of it, and add below:
server_name_in_redirect off;
Default behavior is that nginx redirects any requests to the value given as server_name
in the config.
This is because the FastCGI server has not been started, or the socket used has wrong permissions.
Try out this answer to fix the 502 error.
In Archlinux, the configure file mentioned in above link is /etc/php/php-fpm.conf
.
On some condition, fcgiwrap.socket
may not start properly and create a useless unix domain socket /run/fcgiwrap.sock
.
Try stop the fcgiwrap.socket
service, and remove the default unix domain socket file:
# rm /run/fcgiwrap.sock
Then start fcgiwrap.service
instead.
Check the status of fcgiwrap.service
and the new unix domain socket /run/fcgiwrap.sock
:
$ systemctl status fcgiwrap.service $ ls /run/fcgiwrap.sock
If it work, disable fcgiwrap.socket
and enable fcgiwrap.service
.
Error: No input file specified
1. Verify that variable open_basedir
in /etc/php/php.ini
contains the correct path specified as root
argument in nginx.conf
(usually /usr/share/nginx/
). When using PHP-FPM as FastCGI server for PHP, you may add fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";
in the location
block which aims for processing php file in nginx.conf
.
2. Another occasion is that, wrong root
argument in the location ~ \.php$
section in nginx.conf
. Make sure the root
points to the same directory as it in location /
in the same server. Or you may just set root as global, do not define it in any location section.
3. Check permissions: e.g. http
for user/group, 755
for directories and 644
for files. Remember the entire path to the html
directory should have the correct permissions. See File permissions and attributes#Bulk chmod to bulk modify a directory tree.
4. You do not have the SCRIPT_FILENAME
containing the full path to your scripts. If the configuration of nginx (fastcgi_param SCRIPT_FILENAME
) is correct, this kind of error means php failed to load the requested script. Usually it is simply a permissions issue, you can just run php-cgi as root:
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi
or you should create a group and user to start the php-cgi:
# groupadd www # useradd -g www www # chmod +w /srv/www/nginx/html # chown -R www:www /srv/www/nginx/html # spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi
5. If you are running php-fpm with chrooted nginx ensure chroot
is set correctly within /etc/php-fpm/php-fpm.d/www.conf
(or /etc/php-fpm/php-fpm.conf
if working on older version)
Error: "File not found" in browser or "Primary script unknown" in log file
Ensure you have specified a root
and index
in your server
or location
directive:
location ~ \.php$ { root /srv/http/root_dir; index index.php; fastcgi_pass unix:/run/php-fpm/php-fpm.sock; include fastcgi.conf; }
Error: chroot: '/usr/sbin/nginx' No such file or directory
If you encounter this error when running the nginx daemon using chroot, this is likely due to missing 64 bit libraries in the jailed environment.
If you are running chroot in /srv/http
you need to add the required 64-bit libraries.
First, set up the directories:
# mkdir /srv/http/usr/lib64 # cd /srv/http; ln -s usr/lib64 lib64
Then copy the required 64 bit libraries listed with ldd /usr/sbin/nginx
to /srv/http/usr/lib64
.
If run as root, permissions for the libraries should be read and executable for all users, so no modification is required.
Alternative script for systemd
On pure systemd you can get advantages of chroot + systemd. [2] Based on set user group an pid on:
/etc/nginx/nginx.conf
user http; pid /run/nginx.pid;
the absolute path of file is /srv/http/etc/nginx/nginx.conf
.
/etc/systemd/system/nginx.service
[Unit] Description=nginx (Chroot) After=syslog.target network.target [Service] Type=forking PIDFile=/srv/http/run/nginx.pid RootDirectory=/srv/http ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf ExecReload=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s reload ExecStop=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s stop [Install] WantedBy=multi-user.target
It is not necesary to set the default location, nginx loads at default -c /etc/nginx/nginx.conf
, but it is a good idea though.
Alternatively you can run only ExecStart
as chroot with parameter RootDirectoryStartOnly
set as yes
man systemd service or start it before mount point as effective or a systemd path is available.
/etc/systemd/system/nginx.path
[Unit] Description=nginx (Chroot) path [Path] PathExists=/srv/http/site/Public_html [Install] WantedBy=default.target
Enable the created nginx.path
and change the WantedBy=default.target
to WantedBy=nginx.path
in /etc/systemd/system/nginx.service
.
The PIDFile
in unit file allows systemd to monitor process (absolute path required). If it is undesired, you can change to default one-shoot type, and delete the reference from the unit file.