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.
Related
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 have a domain (let it be example.com). Also, I have a configured nginx web server, where example.com is pointed to the root directory /var/www/example.
Then, I wanted to point service.example.com to /var/www/example, and then point the original example.com to /var/www/service
Fisrt lines of nginx config for service.example.com look like this:
server {
server_name service.example.com;
root /var/www/example;
......
It works, and when I try to access service.example.com, I'm being redirected to the index file in /var/www/example.
Then, I made a config for example.com:
server {
server_name example.com www.example.com;
root /var/www/service;
......
,but when I'm trying to access example.com, I see the index file of /var/www/exampleโ as if I tried to access service.example.com.
So, how can I solve this problem, and see index file of /var/www/service when I'm trying to access example.com?
Problem was in symlinks.
Some of them was not the symlinks in sites-enabled, but archive. So, nginx didn't handled them.
Problem was solved!
server {
root /var/www/service;
server_name service.example.com;
}
reference: https://hackprogramming.com/how-to-setup-subdomain-or-host-multiple-domains-using-nginx-in-linux-server/
I have a website which is an app containing other apps.
In the main app, I'll load the other apps with iframes.
The main app is served at the domain root: http://example.com
The other apps are served under the /apps path:
http://example.com/apps/app-a
http://example.com/apps/app-b
Also the apps are developed in Polymer so there is client side navigation. I make sure the /apps path is not used on the client side to hit the NGINX server correctly but it also means that for url such as http://example.com/view1 it should redirect to the index.html of the main app. And for url like http://example.com/apps/app-b/view1 it should redirect to the index.html of app-b.
I'm trying to configure NGINX to serve those static apps.
server {
listen 80;
server_name example.com;
root /var/www/example.com/main-app;
index index.html;
try_files $uri $uri/index.html /index.html;
location ~ /apps/([a-z-]+) {
alias /var/www/example.com/apps/$1;
}
}
With the above config I have the main app working with the correct redirection to the index.html for the /view1 path for example.
But I have a 403 forbidden error for the sub apps.
directory index of "/var/www/example.com/apps/app-b" is forbidden,
client: 127.0.0.1, server: example.com, request: "GET /apps/app-b/
I've tried other configurations with no success (infinite redirection leading to /index.html/index.html/index.html...).
I'm sure about the filesystem permissions all directories are 755 and files are 644.
I don't know why it is trying to do a directory index.
Any help is appreciated.
When using alias with a regular expression location, you need to build the entire path to the file. Currently, you are only capturing the second path element.
Having said that, you do not actually need to use an alias here, as the root directive can be use instead.
location /apps/ {
root /var/www/example.com;
}
See this document for details.
With the Synology DSM6 update, we have now to use Nginx instead of Apache. By default Nginx configuration don't allow wordpress permalinks (generate 404).
I read the idea was to transform the /uri in /?p=$uri and put this configuration in the "location" section of the server nginx config.
Where to put this configuration in DSM6 exactly ?
Have you tried the user config? Just copy your working:
/etc/nginx/app.d/server.webstation-vhost.conf
to:
/usr/local/etc/nginx/sites-enabled/httpd-vhost.conf-user
and rename the server.webstation-vhost.conf to server.webstation-vhost.conf.old or something and restart nginx (nginx -s reload)
Or better yet, remove your virtual host(s) from webstation. Only thing is you need to manually update your SSL certs when they expire instead of using the web interface.
Actually, you can add custom directives easily, without modifying the DSM behavior.
Take a look at the content of /usr/local/etc/nginx/sites-enabled/httpd-vhost.conf-user, to see where the custom configuration has to be stored:
server {
[...]
server_name NAME
[...]
include /usr/local/etc/nginx/conf.d/778943ad-0dc4-40ae-bb7f-7b2285e3203b/user.conf*;
}
Then, you just have to create the file /usr/local/etc/nginx/conf.d/778943ad-0dc4-40ae-bb7f-7b2285e3203b/user.conf.wordpress-permalink with the following content:
location /{
try_files $uri $uri/ /index.php?$args;
}
and restart nginx:
synoservicecfg --restart nginx
It will not break the future DSM update (since it is a supported customization)
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