I have a somedomain.com.conf file under /etc/nginx/sites-available in linux (RHEL). if i want to host a web app/site, do i just edit the same file or create a new configuration file for nginx? I edited this file and it works, but trying to find the right way to do this. is the convention , create a new config file for each site/app, you host?
server {
listen 80;
server_name mysite.com;
charset utf-8;
root /var/www/mysite-folder;
index index.html index.htm;
location / {
root /var/www/mysite-folder;
try_files $uri /index.html;
}
}
I thought the RHEL-based systems doesn't make use of that sites-enabled/sites-available mechanism at all (in opposite to Debian-based distros). Of course, the most common approach is to use a separate files for each hosted domain name (maybe including the subdomains). All those files are being included from the top level configuration file /etc/nginx/nginx.conf at the http context level; the Debian packages usually have
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
lines in that file while RHEL packages usually have only the single
include /etc/nginx/conf.d/*.conf;
line. As you can see files in the sites-enabled directory may be named any way while files in the conf.d directory should have the .conf extension to be included (and you can rename it so something like <donain>.off to temporary exclude from nginx configuration). What directory to use for your vhost configuration is up to you (I personally prefer to use /etc/nginx/conf.d/ since it is a more universal way). There is a big Difference in sites-available vs sites-enabled vs conf.d directories thread on this subject on ServerFault (the whole question is more suited for ServerFault rather that StackOverflow; please next time ask this kind of question there).
Related
I have a VPS that was serving static files using Apache. After covering some mileage in Django, I decided to change from Apache to Nginx. I thought it would be a simple matter (e.g. specifying the root folder for the domain, that settles it). I see that my expectations were unrealistic because now I am getting "404 Not Found" on all paths except the root folder.
mysite.conf:
server {
listen [::]:443 ssl;
listen 443 ssl;
server_name share.mysite.com;
root /var/www/html/share.mysite.com;
location / {
index index.html index.php;
}
}
How do I scale this configuration to serve static files located in different folders in the hierarchy?
1. share.mysite.com/tutorials/a-subject/a.mp4
2. share.mysite.com/tutorials/another-subject/something.jpg
3. share.mysite.com/some-folder/somefile.zip
At the moment, any of the above combinations give me a "404 Not Found", all except "https://share.mysite.com". Yet, the files are there.
I understand that this may involve the "location" keyword but I haven't seen a lucid explanation that translates to my case. I seek understanding. Nginx is new to me.
It is because of the rewritten rules. You had them in place when using Apache as most probably WordPress automatically created a .htaccess file and placed the necessary default rewrite rules for the so-called "pretty" URL ( e.g. accessing /blog /contact etc. ). In order to do that in Nginx, you have to add a few lines in the vhost for your domain there, please refer to the official documentation for that:
https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/
I have setup a Virtual Box guest machine running Ubuntu Server 18.0.4. I am trying to setup a test environment on my local system for a Wordpress website running on the LEMP stack. Followed some articles on the net and set up php7.2-fpm and nginx server alongwith mysql community edition. The LEMP setup seems to be fine as I have validated it with a test file containing phpinfo function. A dummy static ip address has been configured on the virtual box guest for testing purposes.
There are two server blocks in NGINX - default, which points to phpinfo and knowhow.com which points to the intended Wordpress website. The symbolic link is present in the sites-enabled directory and the knowhow.com file is setup in the sites-available directory. However, when I try to access the Wordpress site with /knowhow.com, I get a 404 Not Found error.
Did some digging around and it appears that some of the re-write rules in the knowhow.com config file might not be correct. I have no clue as to what should be the correct format. I want to access my website. Hence, all requests should ideally go to index.php. The contents of the knowhow.com config file are provided below. Can someone please help?
# Default server configuration
#
server {
listen 80;
listen [::]:80;
root /var/www/knowhow.com/html;
# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;
server_name knowhow.com www.knowhow.com;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
#try_files $uri $uri/ =404;
try_files $uri $uri/ /index.php?q=$uri&$args;
}
# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
}
}
I have solved the issue! Actually, it was never an issue in the first place. The configuration file is correctly defined. Only, the means of accessing the website was incorrect. I was trying to access the site as static-ip-address/knowhow.com from my local host machine (outside the vm). I should have simply accessed the site as knowhow.com or www.knowhow.com. Using the ip address was incorrect since the server block file (knowhow.com) shall automatically redirect the web request to the appropriate website root path on the target server. I had already updated my /etc/hosts file to point to the static IP address for knowhow.com and www.knowhow.com. Silly me! 😋
Sorry for all the confusion. My setup is working as intended. Cheers! 🙂🎉
I'm trying to use nginx to serve a static website that was given to me. Its folder structure is like this:
static_website/
index.html
www.example.com/
resources.example.com/
uploads.example.com/
The index.html file in the root is the one generated by httrack and it simply contains a redirect to www.example.com/index.html.
Inside the folder www.example.com are all the html files, in the other two folders are the css, javascript and image files.
Here is the nginx configuration:
server {
index index.php index.html index.htm;
server_name example.com;
location / {
root /var/www/static_website/www.example.com;
try_files $uri $uri/ =404;
index index.html;
}
}
I can navigate through the pages, but the css, javascript and image files are not loaded.
The path to one of the css files inside the html is like this:
href="../resources.example.com/style.css"
The only way I managed to get this working was to have the have the url like this:
example.com/www.example.com/
This way, all the path are correct. I'd like to avoid this and have simply example.com.
Is there a way to do this?
It looks like the site was originally intended to operate with ugly URLs like //example.com/www.example.com/.
But the path-relative URIs for the resources should work just fine relative to /, you just need to provide a location block which matches /resources.example.com/.
For example:
location / {
root /var/www/static_website/www.example.com;
try_files $uri $uri/ =404;
index index.html;
}
location /resources.example.com/ {
root /var/www/static_website;
}
I originally commented that you should try this:
location ~ \.(css|js|jpg|png|svg)$ {
root /var/www/static_website;
}
Which achieves a similar goal, but Nginx will process prefix locations more efficiently that regular expression locations.
I want to share my experience with this problem for others encountering similar issues as the solution was not so obvious to me
My setup and problem in particular had to do with cloudlflare settings which i was using to leverage TLS instead of handling it on the origin server for one of my 2 sites. if you are serving your site from a CDN that supports encryption and you use nginx on your origin consider the following setup:
# static1.conf
{ server_name static1.com; root: /var/www/static1/public; listen 80; listen 443; }
# static2.conf - no tls setup in nginx, figured id let cloudflare handle it
{ server_name static2.com; root: /var/www/static2/public; listen 80; }
static1 was setup at the origin with letsencrypt to handle tls connections
static2 was setup at the origin without any tls configuration
from left to right, here are the appropriate cloudlfare TLS modes which allowed me to access the correct files thru nginx
The distinction between full and flexible is that full mode lets the origin handle the certificate.
Initially I had the static2 site misconfigured as full, which lacked a listen directive for 443 causing nginx to serve static1 instead.
I realize the original question has nothing to do with cdn's or cloudflare but this scheme / protocol mismatch cost me a few hours and I am hoping to save someone else from similar grief
Honestly I am surprised nginx doesn't stick to matching on server_name and that oit implicitly matches on scheme as a fallback (or atleast appears to), even without a default_server specified - and without any meaningful messages in the logs to boot! Debugging nginx is a nightmare sometimes.
I have some slate docs as website and would like to serve them on the internal server, through a subdomain as follows: internal-docs.mysite.com. For the record, accessing mysite.com shows the "nginx is running propertly" page.
I've created a config file with following path and name: /etc/nginx/sites-available/internal-docs.mysite.com:
server {
listen 80;
server_name internal-docs.mysite.com;
root /var/www/docs-internal;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
And of course, I've put the files in /var/www/docs-internal. And then I made a symlink to the uppershown config file in the /etc/nginx/sites-enabled dir:
internal-docs.mysite.com -> ../sites-available/internal-docs.mysite.com
Then I reload nginx -s reload but "this site can't be reached" error is what I get when accessing the URL.
The setup and configuration look correct to me (according to the guidelines I've followed), so that's why I'm in a dead end, sort of...
It seems you forgot the Listen directive. Try the following:
server {
listen 80;
server_name internal-docs.mysite.com;
root /var/www/docs-internal;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
If that does not work, check:
That Nginx user has read permission to the site content. For example if your Nginx user is www and you have root access, do the following:
# su www
$ cat /var/www/docs-internal/index.html
If that fails, ensure the location has correct ownership and permissions. Note that for a user to be able to browser a directory, that directory must have the execute bit for that user or user group.
That Nginx user has read permission on file ../sites-available/internal-docs.mysite.com. For example if your Nginx user is www and you have root access, do the following:
# su www
$ cat /etc/nginx/sites-available/internal-docs.mysite.com
If that fails, ensure that the config files have correct ownership. Note: normally Nginx master process is run by root, and that process spawns sub-processes run as Nginx user, so permissions on config files are unlikely to be the problem.
That maybe your config file name should end with ".conf" (on my server I have the following line: include conf.d/*.conf; so it will NOT load any conf file ending with ".com".
That Nginx tries to load files in ../sites-available/ in its main config file. Maybe it does not and looks instead in the conf.d directory (the default).
That you can do a ping and nslookup on the subdomain. If you cannot, then you have to fix that first (DNS, firewall...).
For the sake of others - the configuration I wrote was correct, and my problem was in 2 things:
I had to remove the listen 80 directive, since there is another configuration file already, that specifies that nginx should listen on port 80. One should not tell nginx twice to listen on the same port, even if it's in two separate configuration files
Permissions on the /var/www/docs-internal folder. Opening a folder requires x (execute) permissions, while opening a file requires r (read) perm. I had to provide the according permissions to all the folders in this hierarchy, so that the content could be open globally (from everyone), which is basically accessing it from the browser.
I have followed instructions and still I cant password protect my site. This is what my app-nginx.config looks like:
server {
listen 80;
server_name Server_Test;
auth_basic "Restricted";
auth_basic_user_file /usr/local/nginx/conf/htpasswd;
...
}
Where am I going wrong? I copied and pasted this right from a tutorial site.
Make sure Nginx can access the password file. Paths for the auth_basic_user_file are relative to the directory of nginx.conf. So if your nginx.conf is located in /usr/local/nginx you can change your directive to:
auth_basic_user_file conf/htpasswd;
and the file must be readable.
This file should be readable by workers, running from unprivileged
user. E. g. when nginx run from www you can set permissions as:
chown root:nobody htpasswd_file
chmod 640 htpasswd_file
-- from http://wiki.nginx.org/HttpAuthBasicModule
Just made my nginx server to work, and even configured it to protect my root folder access. I'd like to share my findings with you and on the way also give a good and working answer to the question in this page.
As a new user to nginx (Version 1.10.0 - Ubuntu).
The first problem I've got was to know the file locations, so here are the critical locations:
Know your locations:
Main folder location: /etc/nginx
Default site location: /var/www/ or even /ver/www/html/ (inside the html folder will be the index.html file - hope you know what to do from there.)
Configuration files:
Main configuration file: /etc/nginx/nginx.conf
Current site server conf: /etc/nginx/sites-enabled (upon first installation there is a single file there that is called default, and you'll need to use sudo to be able to change it (for example:
sudo vi default)
Add password:
So, now that e know the players (for a static out-of-the-box site anyway) let's put some files in the 'html' folder and let's add password protection to it.
To setup a password we need to do 2 things:
create a passwords file (with as many users as we want, but I'll settle with 1).
Configure the current server ('default') to restrict this page and use the file in 1 to enable the password protection.
1. Let's create a password:
The line I'd like to use for this is:
sudo htpasswd -c /etc/nginx/.htpasswd john (you'll get a prompt to enter and re-enter the password) of you can do it in a single line here:
sudo htpasswd -c /etc/nginx/.htpasswd john [your password]
I'll explain each part of the command:
sudo htpasswd - do it using higher permission.
-c - for: create file (to add another user to an existing user skip this argument)
/etc/nginx/.htpasswd - the name of the file created
('.htpsswd' in the folder /etc/nginx)
john is the name of the user (to enter in the prompted 'user' field)
password is the needed password for this specific user name. (when prompted..)
Usually the htpasswd command won't work for you, so you'll have to install it's package:
Use: sudo apt-get install apache2-utils (if it fails try using sudo apt-get update and try again)
2. Let's configure the server to use this file for authentication
Let's use this line to edit the current (default) server conf file:
sudo vi /etc/nginx/sites-enabled/default (You don't have to use 'vi' but I like it..)
The file looks like this after removing most of the comments (#)
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}
We'll need to add two lines inside the block the location ('/' points to the root folder of the site) so it'll look like this:
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
}
I'll explain these new lines:
auth_basic "Restricted Content"; - defines the type of access management
auth_basic_user_file /etc/nginx/.htpasswd; - defines the file we've created (/etc/nginx/.htppasswd) as the passwords file for this authentication.
Let's restart the service and enjoy a password protected site:
sudo service nginx restart
Voila - enjoy...
Here are some more great tutorials for this:
Very good explanation
Another goo tutorial