(Oct 10, 2017 08:07 PM)datguy.dev Wrote:  With Nginx, often more than not, the directory index is not properly defined in the config. Especially, when you go changing directories. Though if you use sudo to mv the files the permissions are broken as well.

(Oct 10, 2017 08:54 PM)Not Your Average Orange Wrote:  What do you mean? They lose superuser permissions? How would I reapply those permissions?

(Oct 10, 2017 09:29 PM)datguy.dev Wrote:  No. That applies to anything you do under super user. You'll lose permissions of the files if you do so. /etc ...

Whereas you should have a user for web based tasks that are not root. If Nignx is running under the www-data user, then your not going to make any progress until that is addressed.

Permissions; sudo chown www-data:www-data && sudo chmod -R 755 ${files}.

Secondly, for multiple sites you'll need to address the config. Because to locate multiple sites it requires a regex. It's a bit late here. I'd be glad to look into it in the morning.

(Oct 11, 2017 05:18 AM)Not Your Average Orange Wrote:  Ok, thanks. I will create a user for that doesn't have root perms by default and adjust perms.

Maybe I should just reinstall nginx as a regular user?

(Oct 11, 2017 09:32 AM)datguy.dev Wrote:  It shouldn't matter that you installed nginx as root. In many cases that is normal. There is a difference in the permissions required to install and run nginx and those needed to serve or modify server files. You can run everything nginx as root. But it is not advisable for security and it is potentially destructive for the system as you have experienced with permissions.

In your nginx configuration, you have "user www-data;" specified. Therefore, if any of the www related files only have root permissions set, than the user www-data or group will not be able to serve or merely read those files. Does that make sense?

You just need to check them with "ls -l" and make sure the www-data user and it's group has access. Afterwards, you can add your normal user account to the www group. Logout and back in for the changes to take affect.

The guide you followed is good. Try following it again, but first check the default and working directories of Nginx for your OS.

(Oct 11, 2017 10:13 AM)Not Your Average Orange Wrote:  Thanks, I think I understand (more) now.
I can do this later when I get to my laptop. I have to edit perms for config files as well, right?

(Oct 11, 2017 11:07 AM)datguy.dev Wrote:  Nginx should fail to start if it cannot access the config files.

By default, the main nginx process runs as root. The children as www-data. Therefore, it would be best to leave them for root. They should at least be readable and writable. (664) Whereas, www-data needs your site's files.

It's possible you don't have www users or groups. In that situation, you just need to create them. Here are the defaults:

PHP Code


<?php 
sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-10-11 13:46:15 EDT; 5min ago
 Main PID: 15838 (nginx)
   CGroup: /system.slice/nginx.service
           ├─15838 nginx: master process /usr/sbin/nginx -g daemon on; master_process on
           ├─15839 nginx: worker process                           
           ├─15840 nginx: worker process                           
           ├─15841 nginx: worker process                           
           ├─15842 nginx: worker process                           
           ├─15843 nginx: worker process                           
           └─15844 nginx: worker process                           


ps -p 15838 o pid,user,group,command
  PID USER     GROUP    COMMAND
15838 root     root     nginx: master process /usr/sbin/nginx -g daemon on; master_process on;

ps aux|grep nginx|grep -v grep
root     15838  0.0  0.0 124972  1436 ?        Ss   13:46   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 15839  0.0  0.0 125336  3200 ?        S    13:46   0:00 nginx: worker process
www-data 15840  0.0  0.0 125336  3200 ?        S    13:46   0:00 nginx: worker process
www-data 15841  0.0  0.0 125336  3200 ?        S    13:46   0:00 nginx: worker process
www-data 15842  0.0  0.0 125336  3200 ?        S    13:46   0:00 nginx: worker process
www-data 15843  0.0  0.0 125336  3200 ?        S    13:46   0:00 nginx: worker process
www-data 15844  0.0  0.0 125336  3200 ?        S    13:46   0:00 nginx: worker process

ls -lR /etc/nginx/
/etc/nginx/:
total 56
drwxr-xr-x 2 root root 4096 Jul 12 06:34 conf.d
-rw-r--r-- 1 root root 1077 Feb 11  2017 fastcgi.conf
-rw-r--r-- 1 root root 1007 Feb 11  2017 fastcgi_params
-rw-r--r-- 1 root root 2837 Feb 11  2017 koi-utf
-rw-r--r-- 1 root root 2223 Feb 11  2017 koi-win
-rw-r--r-- 1 root root 3957 Feb 11  2017 mime.types
-rw-r--r-- 1 root root 1462 Feb 11  2017 nginx.conf
-rw-r--r-- 1 root root  180 Feb 11  2017 proxy_params
-rw-r--r-- 1 root root  636 Feb 11  2017 scgi_params
drwxr-xr-x 2 root root 4096 Oct 11 13:46 sites-available
drwxr-xr-x 2 root root 4096 Oct 11 13:46 sites-enabled
drwxr-xr-x 2 root root 4096 Oct 11 13:46 snippets
-rw-r--r-- 1 root root  664 Feb 11  2017 uwsgi_params
-rw-r--r-- 1 root root 3071 Feb 11  2017 win-utf

/etc/nginx/conf.d:
total 0

/etc/nginx/sites-available:
total 4
-rw-r--r-- 1 root root 2074 Feb 11  2017 default

/etc/nginx/sites-enabled:
total 0
lrwxrwxrwx 1 root root 34 Oct 11 13:46 default -> /etc/nginx/sites-available/default

/etc/nginx/snippets:
total 8
-rw-r--r-- 1 root root 422 Feb 11  2017 fastcgi-php.conf
-rw-r--r-- 1 root root 217 Feb 11  2017 snakeoil.conf 


Quote:● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2017-10-10 19:31:51 EST; 21h ago
Docs: man:nginx(8)
Process: 9959 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)
Main PID: 1218 (nginx)
Tasks: 2 (limit: 4915)
Memory: 8.5M
CPU: 384ms
CGroup: /system.slice/nginx.service
├─1218 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─9961 nginx: worker process

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

(Oct 11, 2017 11:07 PM)datguy.dev Wrote:  Any luck? Not sure where you stand.

In my opinion, nginx is great for a lightweight web server. I've seen it used for some of the best websites on the internet. Although, I have found it to be not as easily to configure as compared to other options when it comes to complex setups such as hosting multiple sites. Apache is overall good. Look into it and see if you have different results. Alternatively, you could also do something as simple a python flask web server and run two instances.

(Oct 12, 2017 09:18 AM)SuckySucky Wrote:  just a hunch I have... comment out all PHP include parts in sites-available, restart nginx and see what happens

(Oct 12, 2017 05:23 AM)Not Your Average Orange Wrote:  Well, my files are all in the www-data group, but I'm still getting a 404. I think I'll just go Flask & Apache. This tutorial look good?

(Oct 12, 2017 01:04 PM)datguy.dev Wrote:  You went from 403 to 404. 403 Forbidden: meaning something like the requests for resources are not permitted. (Your config's root site directory does not permit access to / or /index.html) Whereas, 404 Not Found, means the requested resource does not exists. (/does_not_exist.html) Their different errors with different causes.

I've done apache and flask. But not apache+flask. I'm not really sure of the benefit of doing that, but I'd like to try it personally. I'd just use Apache... The flask app I was talking about is a few lines of code for the app, then you allow firewall traffic through to the port you've specified. Not all that configuring and enabling modules.

Not to suggest too much too soon, but you really should consider a plan for how you would migrate your site. It really sucks once you have a complicated and working site, then having to move it to a new machine or host, where your system packages and configs will most likely be broken. Instead, you could develop everything in Docker right now which will produce a "container." (They have basic pre-made containers btw.) Then to migrate, you just ship the container over and that is really it. You can kind of do this with virtualenv, but it is a bit flaky when it comes to directories.