Programming/Nginx - Revision history

Brodriguez: Brodriguez moved page Nginx to Programming/Nginx

2021-01-14T03:28:12Z

Brodriguez moved page Nginx to Programming/Nginx

← Older revision

Revision as of 03:28, 14 January 2021

Brodriguez: Change note to a warn

2021-01-14T03:24:26Z

Change note to a warn

← Older revision		Revision as of 03:24, 14 January 2021
Line 24:		Line 24:
	To disable a config file, delete the sym link at {{ ic\|/etc/nginx/sites-enabled/<project>.conf}}. Then restart the Nginx server.		To disable a config file, delete the sym link at {{ ic\|/etc/nginx/sites-enabled/<project>.conf}}. Then restart the Nginx server.

	{{ ~~note~~ \| By default, there is probably a "default" config file under {{ ic \|/etc/nginx/sites-enabled/}}. You can safely remove this file, as it's effectively being replaced by your own config. Furthermore, leaving this default may cause issues and override values in any config you create.}}		{{ warn \| By default, there is probably a "default" config file under {{ ic \|/etc/nginx/sites-enabled/}}. You can safely remove this file, as it's effectively being replaced by your own config. Furthermore, leaving this default may cause issues and override values in any config you create.}}

	=== Snippet Files ===		=== Snippet Files ===

Brodriguez: Add a few todo's and notes

2021-01-14T03:24:08Z

Add a few todo's and notes

← Older revision		Revision as of 03:24, 14 January 2021
Line 3:		Line 3:
	As far as being used as a web server, Nginx is generally comparable to [[Programming/Apache \| Apache]].		As far as being used as a web server, Nginx is generally comparable to [[Programming/Apache \| Apache]].

	~~Note that documentation~~ on this page is primarily for using Nginx as a web server.		Documentation on this page is primarily for using Nginx as a web server.

			{{ note \| For the following page, make sure to replace all values in pointy brackets. Ex: Every instance of <project_name> should be replaced with your project's actual name. }}


Line 10:		Line 12:
	sudo systemctl restart nginx		sudo systemctl restart nginx

	If any errors occur ~~on restart~~, then it might be helpful to run {{ ic \|journalctl -xe}} ~~for~~ possibly more detailed output.		Check for errors with:
			sudo nginx -t

			If any errors occur, then it might be helpful to run {{ ic \|journalctl -xe}} which may possibly give more detailed output (depending on the error).

	=== Config Files ===		=== Config Files ===
Line 18:		Line 23:

	To disable a config file, delete the sym link at {{ ic\|/etc/nginx/sites-enabled/<project>.conf}}. Then restart the Nginx server.		To disable a config file, delete the sym link at {{ ic\|/etc/nginx/sites-enabled/<project>.conf}}. Then restart the Nginx server.

			{{ note \| By default, there is probably a "default" config file under {{ ic \|/etc/nginx/sites-enabled/}}. You can safely remove this file, as it's effectively being replaced by your own config. Furthermore, leaving this default may cause issues and override values in any config you create.}}

	=== Snippet Files ===		=== Snippet Files ===
Line 35:		Line 42:
	=== Comments ===		=== Comments ===
	# This is an inline comment.		# This is an inline comment.


	=== Server Block ===		=== Server Block ===
Line 119:		Line 125:
	}}		}}

	Then for our url handling, we can ~~include~~ this ~~snippet~~ with the following:		Then for our url handling, we can reference this code with the following:
	{{ hc \|/etc/nginx/sites-available/<project_name>.conf\|		{{ hc \|/etc/nginx/sites-available/<project_name>.conf\|
	<nowiki> # Grab urls for Django Project.		<nowiki> # Grab urls for Django Project.
Line 134:		Line 140:

	== HTTPS and SSL ==		== HTTPS and SSL ==
			{{ todo \| Document making server more secure with possible SSL params. }}
	Generally speaking, one of the first things to configure on an Nginx server should be SSL and secure connections.		Generally speaking, one of the first things to configure on an Nginx server should be SSL and secure connections.

Line 144:		Line 151:
	ssl_certificate_key <ssl_certificate_key_location>;</nowiki>		ssl_certificate_key <ssl_certificate_key_location>;</nowiki>
	}}		}}

			Note that these values should be the absolute path on the server for the SSL certificate and SSL key, respectively.

	=== Redirecting HTTP to HTTPS ===		=== Redirecting HTTP to HTTPS ===

Brodriguez: Add another location block example

2021-01-14T03:01:39Z

Add another location block example

← Older revision		Revision as of 03:01, 14 January 2021
Line 84:		Line 84:
	}}		}}

	==== Example 2: Passing Requests to UWSGI ====		==== Example 2: Redirecting Specific Requests ====
			To redirect a specific request url to a different url, use the following:
			{{ hc \|/etc/nginx/sites-available/<project_name>.conf\|
			<nowiki> # Redirect url.
			location /some_url_to_redirect {
			return 302 <full_url_to_redirect_to>;
			}</nowiki>
			}}

			==== Example 3: Passing Requests to UWSGI ====
	To pass request handling off to UWSGI, such as for serving a [[Programming/Django]].		To pass request handling off to UWSGI, such as for serving a [[Programming/Django]].

Line 99:		Line 108:

	==== Reusable Location Blocks ====		==== Reusable Location Blocks ====
	Consider the above [[#Example 2: Passing Requests to UWSGI \| Example 2]]. Consider if you have a Django project where you want to handle multiple unique URLS with the same UWSGI socket.		Consider the above [[#Example 3: Passing Requests to UWSGI \| Example 3]]. Consider if you have a Django project where you want to handle multiple unique URLS with the same UWSGI socket.

	We can reduce redundancy by defining this location handler once:		We can reduce redundancy by defining this location handler once:

Brodriguez: Correct page links

2021-01-14T02:56:43Z

Correct page links

← Older revision		Revision as of 02:56, 14 January 2021
Line 20:		Line 20:

	=== Snippet Files ===		=== Snippet Files ===
	Snippets are files that contain smaller chunks of reusable code, and are meant to be included in the [[#Config ~~files~~ \| config files]]. Snippet files are (generally) stored at {{ ic \|/etc/nginx/snippets/}}.		Snippets are files that contain smaller chunks of reusable code, and are meant to be included in the [[#Config Files \| config files]]. Snippet files are (generally) stored at {{ ic \|/etc/nginx/snippets/}}.

	Nearly anything can go into a snippet, so there's no hard rule on what should go into the file itself. One common use is to put the server's SSL certificate information in a snippet, then include that snippet in all config files.		Nearly anything can go into a snippet, so there's no hard rule on what should go into the file itself. One common use is to put the server's SSL certificate information in a snippet, then include that snippet in all config files.
Line 56:		Line 56:

	=== Location Blocks ===		=== Location Blocks ===
	A location block is put within a [[#~~server block~~ \| server block]]. Essentially, a location block specifies how to handle the respective url.		A location block is put within a [[#Server Block \| server block]]. Essentially, a location block specifies how to handle the respective url.

	General syntax is as follows:		General syntax is as follows:

Brodriguez: Create page

2021-01-14T02:54:47Z

Create page

New page

[https://www.nginx.com/ Nginx] started off as a lightweight [https://en.wikipedia.org/wiki/Web_server Web Server] that has since grown to be suitable for more use cases.

As far as being used as a web server, Nginx is generally comparable to [[Programming/Apache | Apache]].

Note that documentation on this page is primarily for using Nginx as a web server.

== Nginx Files & Management ==
Note that any time a config file is added, remove, changed, or the Nginx server is otherwise updated, the Nginx server will need to be restarted via:
sudo systemctl restart nginx

If any errors occur on restart, then it might be helpful to run {{ ic |journalctl -xe}} for possibly more detailed output.

=== Config Files ===
Generally speaking, each project (or group of related projects) will have it's own {{ ic |.conf}} file, located at {{ ic |/etc/nginx/sites-availabile}}.

To enable a config file, create a [[Linux/Hard Drive Management#Sym Links | Sym Link]] from {{ ic|/etc/nginx/sites-available/<project>.conf}} to {{ ic|/etc/nginx/sites-enabled/<project>.conf}}. Then restart the Nginx server.

To disable a config file, delete the sym link at {{ ic|/etc/nginx/sites-enabled/<project>.conf}}. Then restart the Nginx server.

=== Snippet Files ===
Snippets are files that contain smaller chunks of reusable code, and are meant to be included in the [[#Config files | config files]]. Snippet files are (generally) stored at {{ ic |/etc/nginx/snippets/}}.

Nearly anything can go into a snippet, so there's no hard rule on what should go into the file itself. One common use is to put the server's SSL certificate information in a snippet, then include that snippet in all config files.

The syntax to include a snippet file is as follows:
include <path_to_snippet_from_nginx_folder>;

For example, for a SSL cert snippet, we may have:
include snippets/ssl_certs.conf;

== General Config Syntax ==

=== Comments ===
# This is an inline comment.

=== Server Block ===
The "core" of Nginx syntax is the {{ ic |server}} block.

At their simplest, these blocks essentially specify the incoming server name (or IP address), the port to listen on, and then how to handle requests.

{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki>server {

# Base settings.
server_name <server_name>;
listen <port_number>;

# Put request handling here.

}</nowiki>
}}

=== Location Blocks ===
A location block is put within a [[#server block | server block]]. Essentially, a location block specifies how to handle the respective url.

General syntax is as follows:
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki>server {

...

location /<url_to_handle> {
# Logic here for given url.
}

...

}</nowiki>
}}

==== Example 1: Serving static ====
To serve "static" content, such as CSS or images.

This example will handle anything with a website url of {{ ic |example.com/static}}:
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki> # Serve static files.
location /static {
alias <path_to_static_file_location>;
}</nowiki>
}}

==== Example 2: Passing Requests to UWSGI ====
To pass request handling off to UWSGI, such as for serving a [[Programming/Django]].

This example will handle anything with a website url of {{ ic |example.com/stuff}}:
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki> # Serve Django project request.
location /stuff {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/<project_name>.sock;
}</nowiki>
}}

See [[Programming/Django]] for more details on setting up UWSGI.

==== Reusable Location Blocks ====
Consider the above [[#Example 2: Passing Requests to UWSGI | Example 2]]. Consider if you have a Django project where you want to handle multiple unique URLS with the same UWSGI socket.

We can reduce redundancy by defining this location handler once:
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki> # Define logic for serving Django project.
location @<project_name> {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/<project_name>.sock;
}</nowiki>
}}

Then for our url handling, we can include this snippet with the following:
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki> # Grab urls for Django Project.
location /my_location_1 {
try_files $uri @<project_name>;
}
location /my_location_2 {
try_files $uri @<project_name>;
}</nowiki>
}}

{{ note | For this to work, it seems that the "try_files" syntax definitions need to be placed before the @<project_name> syntax definition. }}

== HTTPS and SSL ==
Generally speaking, one of the first things to configure on an Nginx server should be SSL and secure connections.

As long as the server has a domain name, then SSL certificates are easy and free to acquire through [https://letsencrypt.org/ LetsEncrypt].

=== Create SSL Snippet for Nginx ===
Create a snippet for easy including in all Nginx config files.:
{{ hc |/etc/nginx/snippets/ssl_certs.conf|
<nowiki>ssl_certificate <ssl_certificate_location>;
ssl_certificate_key <ssl_certificate_key_location>;</nowiki>
}}

=== Redirecting HTTP to HTTPS ===
Once certificates are created, Nginx should probably be configured to redirect all HTTP to HTTPS.

Note that the below code is all that's needed for SSL redirecting. It unconditionally redirects all requests to use HTTPS, which are then handled by a different server block.
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki># Insecure connection configuration.
server {

# Base settings.
server_name <server_name>;
listen 80;

# Redirect all requests.
return 302 https://$host$request_uri;

}</nowiki>
}}

=== Serving with HTTPS ===
When serving with SSL, you'll need a server block to specifically handle the HTTPS requests:
{{ hc |/etc/nginx/sites-available/<project_name>.conf|
<nowiki># Secure connection configuration.
server {

# Base settings.
server_name <server_name>;
listen 443 ssl;

# SSL settings.
include snippets/ssl_certs.conf;

# Put request handling here.

}</nowiki>
}}