I'm new to nginx and I have a given nginx config.
There is a mapping like:
map $http_host $my_customer {
default "default";
"~*cust1" "cust1";
"~*cust2" "cust2";
}
And there is the access_log line:
access_log /my/log/path/access.log
Now I want to have separate log-directories and log-files for each customer, so I changed the access_log line into:
access_log /my/log/path/$my_customer/access.log
This works fine if the $my_customer-directory already exists. But if it doesn't exist, then nginx does not log. I know how I can check if the directory exists:
if (!-d /my/log/path/$my_customer) {}
But how is it possible to create a directory inside the nginx config file?
In order to start nginx process all directories have to be created in advance.
The owner of dir should be the user used by worker processes defined in nginx configuration file (/etc/nginx/nginx.conf by default).
The user should have write permissions to this directory.
As #Alexey Ten noticed, it is a good practice to use default logs location:
/var/log/nginx/$my_customer.access.log
Otherwise, you have to do something like that:
mkdir -p -m 755 /my/log/path/$my_customer
Related
I am running into a file upload error with files > 10M. I have followed the advice here: http://meteor-up.com/docs.html#advanced-configuration which says how to set it in the nginx proxy by setting the clientUploadLimit: '50M'
I pushed the changes using mup proxy reconfig-shared, and it told me it had restarted the proxy. It didn't work, I still get the 413 (Request Entity Too Large) error.
I checked inside the nginx-proxy docker instance, and the file /etc/nginx/conf.d/my_proxy.conf has the correct entry client_max_body_size 50M. I restarted the EC2 box to make sure, but it's still not working.
This article https://www.tecmint.com/limit-file-upload-size-in-nginx/ suggests that the setting needs to go inside a http block, like this:
By default, Nginx has a limit of 1MB on file uploads. To set file upload size, you can use the client_max_body_size directive, which is part of Nginx’s ngx_http_core_module module. This directive can be set in the http, server or location context.
http {
client_max_body_size 100M;
}
I can't see how to achieve this, as the .conf file is read only and somehow locked.
Any ideas on how to proceed?
I suppose I could try a custom nginx.conf file, but I'm not sure what should go in there, and in fact whether it will even improve the situation.
Any help is appreciated :)
I'm happy to report that I solved it... I will explain how.
I was setting the limit in the nginx reverse proxy in the mup.js file
proxy: {
domains: 'website.com,www.website.com',
shared: { clientUploadLimit: '50M' }
}
But it turns out that there is an option to set it for each independent server like this:
proxy: {
domains: 'website.com,www.website.com',
clientUploadLimit: '50M'
}
The limit was being set to 10M by default. I found it by shelling into the nginx-proxy docker image and doing a search with the command grep -R client_max_body_size /etc/nginx and it showed me all the places where it was set (for each vhost)
So I changed the mup.js file for my server, did a mup stop, and a mup setup (to re-do the settings) and then a mup deploy
Now this is speculation but have you tried going to the docker container's root shell changed the permissions to give write permission to root or your user chmod 760 /etc/nginx/nginx.conf and edit the nginx file there?
I need for development purpose (not for production of course), to serve my logs that are in my folder /app/logs/.
So I've setup a configuration like this :
server {
listen 80;
server_name server-name.com;
error_log /app/logs/error.log warn;
access_log /app/logs/access.log compression;
root /var/www;
location /info/logs/ {
alias /app/logs/;
autoindex on;
}
location / {
// others route working
}
}
But everytimes i try to access to something like /app/logs/django.log using http://server-name.com/info/logs/django.log, I get a 404 and not the file I asked for.
I've tried many things like chmod -R 755 the entire folder or setting the folder to the user nginx use (in my case for now root, I know it's bad), tried root or try_files but I just can't access it...
I've seen many topics here and there but can't find a clue...
Can you help me with this please ?
PS : I need the root /var/www at the beginning for others locations.
PS2 : I'm using a Docker based on Debian 9.
If you are using the standard NGINX Docker container, then the default configuration is to send the Access and Error logs to the Docker log collector. Not the standard log output for NGINX.
The result is that your log files are most likely going to:
file/var/lib/docker/containers/<container id>/<container id>-json.logon the Docker Host. Where <container id> is the long-form version of the Container Id specified when the container was setup in the first place.
To get to the default log files you can do: docker logs <container name>
To find the <container id> you can do: docker inspect --format '{{ .Id }}' <container name>
If you want to customize where the log files go, then you need to create a helper Docker container that the log files can be written too.
Ok, I've found my problem, I had a route like this :
# Any route containing a file extension (e.g. /devicesfile.js)
location ~ ^.+\..+$ {
try_files $uri =404;
}
And I didn't know that despite the fact it was after the first location, it would be choosen over the other location...
Thanks for your help anyway !
I am new to nginx and trying to serve static contents with nginx and getting 403 error.I have server config like this:
server {
listen 8000;
server_name localhost;
root /Users/ismayilmalik/Documents/github/nginx-express;
location / {
index index.html;
}
I have executed commands below:
chmod -R 755 /nginx-express
chmod -R 644 /nginx-express/*.*
And the folder has drwxr-xr-x rigt.What's wrong here?
Please go to your nginx error logs to get details.
Run this command to show last errors:
tail -20 /var/log/nginx/error.log
It's good to go through error logs located /var/log/nginx/***.error. I had problems similar to this once. The solution was the user nginx was running as.
If nginx is running as www then www will not have access to ismayilmalik folders unless you also grant access to /Users/ismayilmalik home folder, but that is not secure. The best solution would be to allow nginx to run as ismayilmalik if you want to access your home folder through nginx.
I solved it finally.Actually nginx had all permission to serve static content from:
/Users/ismayilmalik/Documents/github/nginx-express;
The reason was when started nginx could not create error.log file in it'sroot directory. After manually creating the file it worked fine. I am using macOs and to find logs folder executed the command below to find all enironment variables for nginx:
nginx -V
BTW before this I had changed nginx user to from nobody to admin in main config file like below.
user [username] [usergroup]
By default nginx master process runs under root and child process under nobody.
What I have:
I have a Pyramid application that is built from a Paste ini, served by uWSGI and proxied by nginx. It works great. Here is the nginx config:
server {
listen 80;
server_name localhost;
access_log /var/log/myapp/nginx.access.log;
error_log /var/log/myapp/nginx.error.log warn;
location / {
uwsgi_pass localhost:8080;
include uwsgi_params;
}
}
Here is the uWSGI ini configuration:
[uwsgi]
socket = 127.0.0.1:8080
virtualenv = /srv/myapp/venv
die-on-term = 1
master = 1
logto = /var/log/myapp/uwsgi.log
This configuration is located inside Pyramid's production.ini, such that I serve the application with this command:
uwsgi --ini-paste-logged production.ini
All of this works just fine.
What I want to do:
One simple change. I want to serve this application as a subfolder, rather than as the root. Rather than serving it from http://localhost, I want to serve it from http://localhost/myapp.
And now everything is broken.
If I change the nginx location directive from / to /myapp or /myapp/, I get 404s, because the WSGI application receives uris that are all prepended with /myapp.
The uWSGI solution appears to be to mount the WSGI callable on the subfolder, and then pass the --manage-script-name option, at which point uWSGI should magically strip the subfolder prefix from the uri and fix the issue.
However, the documentation and every other resource I've found have only given examples of the form:
mount = /myapp=myapp.py
I don't have a myapp.py that contains a WSGI callable, because my callable is being built by PasteDeploy.
So, is it possible to mount the WSGI callable from within the Paste ini? Or am I going to have to split the uwsgi configuration out of the Paste ini and also define a separate wsgi.py with a call to paste.deploy.loadapp to generate a wsgi callable that I can mount?
Or is there another way to serve this app as a subfolder from nginx while not messing up the url reversing?
Yes, it's definitely possible to mount your Pyramid as a subdirectory with Nginx. What you'll need to use is the Modifier1 option from uWSGI like so:
location /myapp {
include uwsgi_params;
uwsgi_param SCRIPT_NAME /myapp;
uwsgi_modifier1 30;
uwsgi_pass localhost:8080;
}
The magic value of 30 tells uWSGI to remove the parameter of SCRIPT_NAME from the start of PATH_INFO in the request. Pyramid receives the request and processes it correctly.
As long as you're using the standard Pyramid machinery to generate URLs or paths within your application, SCRIPT_NAME will automatically be incorporated, meaning all URLs for links/resources etc are correct.
The documentation isn't the clearest, but there's more on the modifiers available at: https://uwsgi-docs.readthedocs.org/en/latest/Protocol.html
I wanted to do what you suggest but this is the closest solution I could find: if you are willing to modify your PasteDeploy configuration, you can follow the steps at: http://docs.pylonsproject.org/docs/pyramid/en/1.0-branch/narr/vhosting.html
Rename [app:main] to [app:mypyramidapp] and add a section reading:
[composite:main]
use = egg:Paste#urlmap
/myapp = mypyramidapp
I also had to add this to my nginx configuration:
uwsgi_param SCRIPT_NAME '';
and install the paste module
sudo pip3 install paste
I wonder if there is a way to "mount" a PasteDeploy as to original question asked...
I've hit this very problem with my deployment after switching from Python2 to Python3.
with Python2 I used the uwsgi_modifier1 30; trick, but it doesn't work anymore with Python3, as described here: https://github.com/unbit/uwsgi/issues/876
It is very badly documented (not at all? I know it from reading the uWSGI source code), but --mount option accepts the following syntax:
--mount=/app=config:/path/to/app.ini
Please note: with --mount you also need --manage-script-name option.
There are other problems with it: https://github.com/unbit/uwsgi/issues/2172
It's trivial to write a wrapper script around Paste-Deploy app, which is the way I deploy now:
from paste.script.util.logging_config import fileConfig as configure_logging
from paste.deploy import loadapp as load_app
from os import environ
config_file = environ['INI_FILE']
configure_logging(config_file)
application = load_app('config:' + config_file)
Save it to e.g. app.py and you can use it with --mount /app=app.py, the INI_FILE environment var should point to your .ini file.
As a side note - I consider moving away from uWSGI, it's buggy and documentation lacks a lot.
I have nginx installed with PHP-FPM on a CentOS 5 box, but am struggling to get it to serve any of my files - whether PHP or not.
Nginx is running as www-data:www-data, and the default "Welcome to nginx on EPEL" site (owned by root:root with 644 permissions) loads fine.
The nginx configuration file has an include directive for /etc/nginx/sites-enabled/*.conf, and I have a configuration file example.com.conf, thus:
server {
listen 80;
Virtual Host Name
server_name www.example.com example.com;
location / {
root /home/demo/sites/example.com/public_html;
index index.php index.htm index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME /home/demo/sites/example.com/public_html$fastcgi_script_name;
include fastcgi_params;
}
}
Despite public_html being owned by www-data:www-data with 2777 file permissions, this site fails to serve any content -
[error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"
I've found numerous other posts with users getting 403s from nginx, but most that I have seen involve either more complex setups with Ruby/Passenger (which in the past I've actually succeeded with) or are only receiving errors when the upstream PHP-FPM is involved, so they seem to be of little help.
Have I done something silly here?
One permission requirement that is often overlooked is a user needs x permissions in every parent directory of a file to access that file. Check the permissions on /, /home, /home/demo, etc. for www-data x access. My guess is that /home is probably 770 and www-data can't chdir through it to get to any subdir. If it is, try chmod o+x /home (or whatever dir is denying the request).
EDIT: To easily display all the permissions on a path, you can use namei -om /path/to/check
If you still see permission denied after verifying the permissions of the parent folders, it may be SELinux restricting access.
To check if SELinux is running:
# getenforce
To disable SELinux until next reboot:
# setenforce Permissive
Restart Nginx and see if the problem persists. To allow nginx to serve your www directory (make sure you turn SELinux back on before testing this. i.e, setenforce Enforcing)
# chcon -Rt httpd_sys_content_t /path/to/www
See my answer here for more details
I solved this problem by adding user settings.
in nginx.conf
worker_processes 4;
user username;
change the 'username' with linux user name.
I've got this error and I finally solved it with the command below.
restorecon -r /var/www/html
The issue is caused when you mv something from one place to another. It preserves the selinux context of the original when you move it, so if you untar something in /home or /tmp it gets given an selinux context that matches its location. Now you mv that to /var/www/html and it takes the context saying it belongs in /tmp or /home with it and httpd is not allowed by policy to access those files.
If you cp the files instead of mv them, the selinux context gets assigned according to the location you're copying to, not where it's coming from. Running restorecon puts the context back to its default and fixes it too.
I've tried different cases and only when owner was set to nginx (chown -R nginx:nginx "/var/www/myfolder") - it started to work as expected.
If you're using SELinux, just type:
sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/
This will fix permission issue.
Old question, but I had the same issue. I tried every answer above, nothing worked. What fixed it for me though was removing the domain, and adding it again. I'm using Plesk, and I installed Nginx AFTER the domain was already there.
Did a local backup to /var/www/backups first though. So I could easily copy back the files.
Strange problem....
We had the same issue, using Plesk Onyx 17. Instead of messing up with rights etc., solution was to add nginx user into psacln group, in which all the other domain owners (users) were:
usermod -aG psacln nginx
Now nginx has rights to access .htaccess or any other file necessary to properly show the content.
On the other hand, also make sure that Apache is in psaserv group, to serve static content:
usermod -aG psaserv apache
And don't forget to restart both Apache and Nginx in Plesk after! (and reload pages with Ctrl-F5)
I was facing the same issue but above solutions did not help.
So, after lot of struggle I found out that sestatus was set to enforce which blocks all the ports and by setting it to permissive all the issues were resolved.
sudo setenforce 0
Hope this helps someone like me.
I dug myself into a slight variant on this problem by mistakenly running the setfacl command. I ran:
sudo setfacl -m user:nginx:r /home/foo/bar
I abandoned this route in favor of adding nginx to the foo group, but that custom ACL was foiling nginx's attempts to access the file. I cleared it by running:
sudo setfacl -b /home/foo/bar
And then nginx was able to access the files.
If you are using PHP, make sure the index NGINX directive in the server block contains a index.php:
index index.php index.html;
For more info checkout the index directive in the official documentation.