Re: VHost Not Serving
Hi there.
I used:
curl alpha.local
It returned hq3.local source.
Here’s the main nginx.conf then the included domain.conf:
worker_processesauto;
load_module
/opt/homebrew/opt/passenger/libexec/modules/ngx_http_passenger_module.so;
error_log
/opt/homebrew/var/log/error.log notice ;
pid
/opt/homebrew/var/run/nginx.pid;
events { worker_connections 256;}
http {
server_names_hash_bucket_size 64;
access_log
/opt/homebrew/var/log/access.log;
error_log
/opt/homebrew/var/log/error_gen.log;
passenger_root
/opt/homebrew/opt/passenger/libexec/src/ruby_supportlib/phusion_passenger/locations.ini;
passenger_ruby /Users/rich/.rbenv/shims/ruby;
# pass_info in terminal
passenger_friendly_error_pages on;
server {
listen 80 default_server;
server_name hq3.local;
# hq.local
include
/opt/homebrew/etc/nginx/mime.types;
access_log
/opt/homebrew/var/log/access_HQ.log;
error_log
/opt/homebrew/var/log/error_HQ.log warn;
error_page 404 /Users/rich/Sites/HQ/public/404.html;
root
/Users/rich/Sites/HQ/public;
passenger_enabled on;
passenger_base_uri /;
location / {
autoindex off;
# try_files $uri $uri/ /index.html?$query_string;
index index.html;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
sendfileoff;
}
server {
listen 80;
server_name charlie.local;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
server_name charlie.local;
# charlie.local
ssl_certificate
/Users/rich/Sites/charlie/charlie.local.pem;
ssl_certificate_key /Users/rich/Sites/charlie/charlie.local-key.pem;
ssl_ciphers
ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
include
/opt/homebrew/etc/nginx/mime.types;
access_log
/opt/homebrew/var/log/access_charlie.log;
error_log
/opt/homebrew/var/log/error_charlie.log warn;
error_page 404 /404.html;
root
/Users/rich/Sites/charlie/public;
passenger_enabled on;
passenger_base_uri /;
}
server {
listen 80;
server_name vp.local;
# vp.local
include
/opt/homebrew/etc/nginx/mime.types;
access_log
/opt/homebrew/var/log/access_VP.log;
error_log
/opt/homebrew/var/log/error_VP.log warn;
error_page 404 /404.html;
root
/Users/rich/Sites/VP6/public;
passenger_enabled on;
passenger_base_uri /;
location / {
autoindex off;
index index.html;
}
location = /img/favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
sendfileoff;
}
include /opt/homebrew/etc/nginx/servers/*.conf;
# resolution problem here
# include /opt/homebrew/etc/nginx/servers/alpha.conf;
# include /opt/homebrew/etc/nginx/servers/bravo.conf;
}
alpha.conf:
server {
server_name alpha.local
listen 80;
include
/opt/homebrew/etc/nginx/mime.types;
access_log
Re: File Upload Permissions Issues
> On Jun 27, 2018, at 2:02 AM, Maxim Dounin wrote: > > Hello! Hello again! > On Wed, Jun 27, 2018 at 12:56:09AM -0400, VP Lists wrote: > > [...] > >> OK, here’s where things get interesting: >> >> On MacOS El Capitan: >> --http-client-body-temp-path=/usr/local/var/run/nginx/client_body_temp >> /usr drwxr-xr-x@ 13 root wheel >> 442B May 26 2017 usr >> /usr/local drwxr-xr-x28 rich admin >> 952B Mar 30 16:12 local >> /usr/local/var drwx--36 rich >> admin 1.2K May 7 21:01 var > > Clearly "nobody" has no rights to work with anything in > /usr/local/var. That's what causes the error you've faced. You > have to fix it for things to work. I changed it to 755. Works now. > [...] > >> On two different boxes, two different OSes, showing variable >> eXecution permissions within the path. Not only that, but in >> both instances, the client_body_temp permissions show “drwx- - - >> - - -“, and for two different owner:group combinations. >> >> Why would nginx allow this to happen? Is it not thinkable that >> either nginx would state that a clear path to the directory >> responsible for receiving file uploads be permitted? Or maybe >> the maintainers receiving this as a criteria for installation? >> I find this quite odd. >> >> Running around patching up path permissions to installed >> directories, specific to nginx, is truly strange. > > Permissions on FreeBSD are perfectly fine. > > Permissions on macOS are broken due to incorrect permissions on > /usr/local/var, and it's clearly not nginx business to do anything > with permissions on the system-wide directory. > > If you think packaging system you've used to install things into > /usr/local/ could be better at maintaining correct permissions on > various folders under /usr/local/ - you may want to contact > authors of the packaging system. With regards to system-wide directories and nginx choosing this as the target directory, I’m not versed in who has what right to do what during installation, with regards to chmod, chown, chgrp, etc. As well, the same goes for package managers vs nginx. I was just under the assumption it would all have a collective agreement that a sticky permission (t) would apply so that there could be some kind of installation functionality happening. But I guess not, so the /usr/local/var permissions, even though a system-wide directory, needed to be changed. Cheers _ Rich in Toronto @ VP ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: File Upload Permissions Issues
> On Jun 26, 2018, at 10:51 PM, Maxim Dounin wrote: > > Hello! Hello there. Thanks for the reply. > On Tue, Jun 26, 2018 at 04:56:55PM -0400, VP Lists wrote: > >> I’m having a problem uploading any files of any significant size to a test >> site on my workstation. >> >> 2018/06/26 16:50:20 [crit] 36196#0: *1099 open() >> "/usr/local/var/run/nginx/client_body_temp/18" failed (13: >> Permission denied), client: 127.0.0.1, server: pass1.local, request: "POST >> /upload HTTP/1.1", host: "pass1.local:8080", referrer: >> "http://pass1.local:8080/upload"; > > The error message speaks for itself: nginx has no permissions to > write temporary files to the directory it was configured to write > temporary files to. You have to fix this. > > [...] > >> My nginx.conf has no set ‘user’ > > This means that nginx will use the default user for worker > processes as long as it is started as root. Usually this is > nobody:nogroup, or whatever is set via configure arguments (see > "nginx -V”). That command didn’t lend itself to anything. No user mentioned anywhere in that result. It’s running as root, with the workers being run as nobody. >> and here are the permissions set on the temp file upload folder for nginx: >> >> $ ll /usr/local/var/run/nginx/ >> drwxr-xr-x 7 richadmin 238B Dec 8 2016 . >> drwxr-xr-x 4 richadmin 136B Jun 19 15:19 .. >> drwx-- 2 nobody admin68B Dec 8 2016 client_body_temp > > You have to check all path compontents. That is, check that nginx > has at least "x" on "/", "/usr", "/usr/local", "/usr/local/var", > "/usr/local/var/run”. OK, here’s where things get interesting: On MacOS El Capitan: --http-client-body-temp-path=/usr/local/var/run/nginx/client_body_temp /usrdrwxr-xr-x@ 13 root wheel 442B May 26 2017 usr /usr/local drwxr-xr-x28 rich admin 952B Mar 30 16:12 local /usr/local/var drwx--36 rich admin 1.2K May 7 21:01 var /usr/local/var/run drwxr-xr-x 4 rich admin 136B Jun 19 15:19 run /usr/local/var/run/nginxdrwxr-xr-x 7 rich admin 238B Dec 8 2016 nginx /usr/local/var/run/nginx/client_body_temp drwx-- 2 nobody admin 68B Dec 8 2016 client_body_temp On FreeBSD 11.1-RELEASE: --http-client-body-temp-path=/var/tmp/nginx/client_body_temp /vardrwxr-xr-x 25 root wheel25 May 7 08:48 var /var/tmpdrwxrwxrwt 4 root wheel 4 Jul 7 2017 tmp /var/tmp/nginx drwxr-xr-x 7 root wheel 7 Jul 13 2017 nginx /var/tmp/nginx/client_body_temp drwx-- 2 www wheel 2 Jul 7 2017 client_body_temp On two different boxes, two different OSes, showing variable eXecution permissions within the path. Not only that, but in both instances, the client_body_temp permissions show “drwx- - - - - -“, and for two different owner:group combinations. Why would nginx allow this to happen? Is it not thinkable that either nginx would state that a clear path to the directory responsible for receiving file uploads be permitted? Or maybe the maintainers receiving this as a criteria for installation? I find this quite odd. Running around patching up path permissions to installed directories, specific to nginx, is truly strange. > Additionally, if you have SELinux or equivalent enabled, you > should check it as well. > >> I have 4 workers owned by nobody:admin, and nginx is run as >> default, as root:admin. >> >> Now this topic of permissions and “what user should run nginx” >> has come up before. Some say run as root, others say not. It’s >> my workstation, so it doesn’t really matter. It’s my dev box. >> The issue comes down to production. >> >> Is there one way all of this should be run without the worried >> security devs out there from losing it? Since I’m here at >> another security issue with who runs what, maybe it’s a good >> time to get a consensus on how all this should be set up. > > You should never run nginx worker processes as root unless you > understand what you are doing and possible consequences. I don’t. I don’t even set nginx master to run as root, but it does. nginx.conf: # user root admin; # commented out > On the other hand, nginx master process can't do many required > things - like binding to port 80 - without being root. As such, > you have to ru
Re: 413 Request Entity Too Large
I am guessing it’s the permissions issue on the incoming temp folder. I just posted the same on the list, not published yet. 2018/06/26 16:50:20 [crit] 36196#0: *1099 open() "/usr/local/var/run/nginx/client_body_temp/18" failed (13: Permission denied), client: 127.0.0.1, server: pass1.local, request: "POST /upload HTTP/1.1", host: "pass1.local:8080", referrer: "http://pass1.local:8080/upload"; 2018/06/26 16:50:20 [debug] 36196#0: *1099 http finalize request: 500, "/upload?" a:1, c:1 2018/06/26 16:50:20 [debug] 36196#0: *1099 event timer del: 16: 1530046280299 2018/06/26 16:50:20 [debug] 36196#0: *1099 http special response: 500, "/upload?" 2018/06/26 16:50:20 [debug] 36196#0: *1099 HTTP/1.1 500 Internal Server Error Kaushal, your nginx is running as whom? Both your user and your workers. Second, what are the permissions on the following: $ ll /usr/local/var/run/nginx/ drwxr-xr-x 7 richadmin 238B Dec 8 2016 . drwxr-xr-x 4 richadmin 136B Jun 19 15:19 .. drwx-- 2 nobody admin68B Dec 8 2016 client_body_temp > On Jun 19, 2018, at 3:26 AM, Aleksandar Lazic wrote: > > What's in the nginx error logs file? > > There should be more informations about the reason of the 413 as you can > see in the source. > > https://github.com/nginx/nginx/search?q=Request+Entity+Too+Large&unscoped_q=Request+Entity+Too+Large > >> Best Regards, > > Best regards > Aleks Cheers _ Rich in Toronto @ VP ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
File Upload Permissions Issues
Hi folks. I’m having a problem uploading any files of any significant size to a test site on my workstation. 2018/06/26 16:50:20 [crit] 36196#0: *1099 open() "/usr/local/var/run/nginx/client_body_temp/18" failed (13: Permission denied), client: 127.0.0.1, server: pass1.local, request: "POST /upload HTTP/1.1", host: "pass1.local:8080", referrer: "http://pass1.local:8080/upload"; 2018/06/26 16:50:20 [debug] 36196#0: *1099 http finalize request: 500, "/upload?" a:1, c:1 2018/06/26 16:50:20 [debug] 36196#0: *1099 event timer del: 16: 1530046280299 2018/06/26 16:50:20 [debug] 36196#0: *1099 http special response: 500, "/upload?" 2018/06/26 16:50:20 [debug] 36196#0: *1099 HTTP/1.1 500 Internal Server Error Server: nginx/1.15.0 Date: Tue, 26 Jun 2018 20:50:20 GMT Content-Type: text/html Content-Length: 595 Connection: close 2018/06/26 16:50:20 [debug] 36196#0: *1099 write new buf t:1 f:0 7FACB10021A0, pos 7FACB10021A0, size: 162 file: 0, size: 0 2018/06/26 16:50:20 [debug] 36196#0: *1099 http write filter: l:0 f:0 s:162 2018/06/26 16:50:20 [debug] 36196#0: *1099 http output filter "/upload?" 2018/06/26 16:50:20 [debug] 36196#0: *1099 http copy filter: "/upload?" 2018/06/26 16:50:20 [debug] 36196#0: *1099 http postpone filter "/upload?" 7FACB10023C0 2018/06/26 16:50:20 [debug] 36196#0: *1099 write old buf t:1 f:0 7FACB10021A0, pos 7FACB10021A0, size: 162 file: 0, size: 0 2018/06/26 16:50:20 [debug] 36196#0: *1099 write new buf t:0 f:0 , pos 00010A332120, size: 140 file: 0, size: 0 2018/06/26 16:50:20 [debug] 36196#0: *1099 write new buf t:0 f:0 , pos 00010A330F20, size: 53 file: 0, size: 0 2018/06/26 16:50:20 [debug] 36196#0: *1099 write new buf t:0 f:0 , pos 00010A330FD0, size: 402 file: 0, size: 0 2018/06/26 16:50:20 [debug] 36196#0: *1099 http write filter: l:1 f:0 s:757 2018/06/26 16:50:20 [debug] 36196#0: *1099 http write filter limit 0 2018/06/26 16:50:20 [debug] 36196#0: *1099 writev: 757 of 757 2018/06/26 16:50:20 [debug] 36196#0: *1099 http write filter 2018/06/26 16:50:20 [debug] 36196#0: *1099 http copy filter: 0 "/upload?" 2018/06/26 16:50:20 [debug] 36196#0: *1099 http finalize request: 0, "/upload?" a:1, c:1 2018/06/26 16:50:20 [debug] 36196#0: *1099 event timer add: 16: 5000:1530046225299 2018/06/26 16:50:20 [debug] 36196#0: *1099 http lingering close handler 2018/06/26 16:50:20 [debug] 36196#0: *1099 recv: eof:0, avail:73728, err:0 My nginx.conf has no set ‘user’ and here are the permissions set on the temp file upload folder for nginx: $ ll /usr/local/var/run/nginx/ drwxr-xr-x 7 richadmin 238B Dec 8 2016 . drwxr-xr-x 4 richadmin 136B Jun 19 15:19 .. drwx-- 2 nobody admin68B Dec 8 2016 client_body_temp I have 4 workers owned by nobody:admin, and nginx is run as default, as root:admin. Now this topic of permissions and “what user should run nginx” has come up before. Some say run as root, others say not. It’s my workstation, so it doesn’t really matter. It’s my dev box. The issue comes down to production. Is there one way all of this should be run without the worried security devs out there from losing it? Since I’m here at another security issue with who runs what, maybe it’s a good time to get a consensus on how all this should be set up. Cheers _ Rich in Toronto @ VP ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
