I have a Django application (droplet) on DigitalOcean but I have an issue showing information in a table.
Everything works on my local server but when I deploy to the server on DigitalOcean I don't know where I can see the activity of the server like print outputs. I can see the gunicorn and nginx logs but none of those logs show the Django activity.
What should I do?
Create your Log directory
mkdir logs in your-app directory
To get your django requests and error log; you'd have to create your indicate the log directory in your nginx server config file.
/etc/nginx/sites-available/your-app-config:
server {
...
access_log /directory/to/your-app/logs/access.log;
error_log /directory/to/your-app/logs/error.log;
...
}
Ensure you have a symbolic link to the sites-enabled folder:
sudo ln -s /etc/nginx/sites-available/your-app /etc/nginx/sites-enabled/your-app
Check that your configuration settings are okay
sudo nginx -t
Reload Nginx
sudo systemctl reload nginx
Check your log files to read requests & error logs
Related
trying to run django app "mysite" through uwsgi with nginx on Ubuntu 16.04, but when I start uwsgi and check in my browser, it just hangs.
i set django upstream socket to on port 8002 and nginx to listen on 8003. In the browser i visit 192.168.0.17:8003 prior to running uwsgi and it throws 502 which is expected, so I start uwsgi with
uwsgi --http :8002 --module mysite.wsgi --logto /tmp/uwsgi.log --master
and 8003 now hangs when I reload in the browser. I looked through /var/log/nginx/error.log but it's blank (so is access.log).
Here is nginx config, which is symlinked to /etc/nginx/sites-enabled:
sudo nano /etc/nginx/sites-available/mysite_nginx.conf
# mysite_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
# server unix:///path/to/your/mysite/mysite.sock; # for a file socket
server 127.0.0.1:8002; # for a web port socket (we'll use this first)
}
# configuration of the server
server {
# the port your site will be served on
listen 8003;
# the domain name it will serve for
server_name 192.168.0.17; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Django media
location /media {
alias /home/myusername/uwsgi-tutorial/mysite/media; # your Django project's media files - amend as required
}
location /static {
alias /home/myusername/uwsgi-tutorial/mysite/static; # your Django project's static files - amend as required
}
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /home/myusername/uwsgi-tutorial/mysite/uwsgi_params; # the uwsgi_params file you installed
}
}
I know that Django is running because in my app's settings.py I have ALLOWED_HOSTS = ['192.168.0.17','localhost','127.0.0.1'] and when I visit port 8002 in the browser I get the django "Congratulations!" page. And when I remove 192.168.0.17 from ALLOWED_HOSTS, django still runs on that machine from localhost or 127.0.0.1, so this seems that it must be something to do with how ngnix and uwsgi are talking to each other.
Any ideas??
It turns out systemd does not like lines in config files to be too long. I removed a couple long comments in /etc/systemd/system/uwsgi.service, restarted uwgsi service and all is well.
I found this out by running sudo journalctl -u uwsgi and finding the following error:
[/etc/systemd/system/uwsgi.service:5] Unbalanced quoting, ignoring: "/bin/bash -c 'mkdir -p /run/uwsgi; chown myusername:myusern
In researching Unbalanced quoting, found this git issue regarding maximum file line length.
I'm working in a Django project deployment. I'm working in a CentOS 7 server provided ma EC2 (AWS). I have tried to fix this bug by many ways but I cant understand what am I missing.
I'm using ningx and gunicorn to deploy my project. I have created my /etc/systemd/system/myproject.servicefile with the following content:
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=centos
Group=nginx
WorkingDirectory=/home/centos/myproject_app
ExecStart=/home/centos/myproject_app/django_env/bin/gunicorn --workers 3 --bind unix:/home/centos/myproject_app/django.sock app.wsgi:application
[Install]
WantedBy=multi-user.target
When I run sudo systemctl restart myproject.serviceand sudo systemctl enable myproject.service, the django.sock file is correctly generated into /home/centos/myproject_app/.
I have created my nginx conf flie in the folder /etc/nginx/sites-available/ with the following content:
server {
listen 80;
server_name my_ip;
charset utf-8;
client_max_body_size 10m;
client_body_buffer_size 128k;
# serve static files
location /static/ {
alias /home/centos/myproject_app/app/static/;
}
location / {
include proxy_params;
proxy_pass http://unix:/home/centos/myproject_app/django.sock;
}
}
After, I restart nginx with the following command:
sudo systemctl restart nginx
If I run the command sudo nginx -t, the reponse is:
nginx: configuration file /etc/nginx/nginx.conf test is successful
When I visit my_ip in a web browser, I'm getting a 502 bad gateway response.
If I check the nginx error log, I see the following message:
1 connect() to unix:/home/centos/myproject_app/django.sock failed (13: Permission denied) while connecting to upstream
I really have tried a lot of solutions changing the sock file permissions. But I cant understand how to fix it. How can I fix this permissions bug?... Thank you so much
If all the permissions under the myproject_app folder are correct, and centos user or nginx group have access to the files, I would say it looks like a Security Enhanced Linux (SELinux) issue.
I had a similar problem, but with RHEL 7. I managed to solve it by executing the following command:
sudo semanage permissive -a httpd_t
It's related to the security policies of SELinux, you have to add the httpd_t to the list of permissive domains.
This post from the NGINX blog may be helpful: NGINX: SELinux Changes when Upgrading to RHEL 6.6 / CentOS 6.6
Motivated by a similar issue, I wrote a tutorial a while ago on How to Deploy a Django Application on RHEL 7. It should be very similar for CentOS 7.
Most probably one of two
1- the directory is not accessible to nginx /home/centos/myproject_app/
$ ls -la /home/centos/myproject_app/
if it is not accessible try to change the path to /etc/nginx
if not then try the command
$ /home/centos/myproject_app/django_env/bin/gunicorn --workers 3 --bind unix:/home/centos/myproject_app/django.sock app.wsgi:application
if still not working then activate the environment and python manage.py runserver 0.0.0.0:8000 go to the browser and go to http://ip:8000 the problem may be here, but it the command of gunicorn worked well, then the problem in directory access for nginx user
Exact same problem here.
Removing Group=www-data fixed the issue for me
We have a dev server with the internal hostname dev1.internal.blah.com running nginx. I'm trying to create a test Django project testproject from the Django tutorial on this server. I access this server by ssh-ing into it.
So on this server I installed Django, created a new directory, issued django-admin startproject mysite within it, then issued python manage.py runserver 8765 and got the
success message Starting development server at http://127.0.0.1:8765/
Now how would I access the http://127.0.0.1:8765 site from a browser? I tried using http://dev1.internal.blah.com:8765 but got a This site can't be reached error message.
If I try curl http://127.0.0.1:8765 from the terminal, I see the correct html being rendered.
The nginx www directory is located at /usr/share/nginx/html if it helps.
By default, Django development server runs on port 8000 on the IP address 127.0.0.1, but note that that IP address is accessible only from your own server.
To make the runserver viewable to others, use either its own IP address or 0.0.0.0. or :: with IPv6 enabled.
So, you should probably run it like this:
python manage.py runserver 0.0.0.0:8765
I'm trying to set up my Django app with uWSGI and nginx by following this guide. I'm able to run my app with Django's development server, as well as being served directly from uWSGI.
I'm running everything on a university managed Ubuntu 16.04 virtual machine, and my user has sudo access.
My problem:
When getting to this bit of the tutorial, and try to fetch an image, I get a 403 error from nginx.
The next section results in a 502.
/var/log/nginx/error.log shows
connect() to unix:///me/myproject/media/image.jpg failed (13: Permission denied) while connecting to upstream
connect() to unix:///me/myproject/project.sock failed (13: Permission denied) while connecting to upstream
for the 403 and 502, respectively.
I have read multiple questions and guides (one here, another here and yet another one, and this is not all of them), changed my permissions and even moved my .sock to another folder (one of the SO answers recommended that).
What else can I try?
Update:
I mentioned it in a comment, but I've gotten a bit further. A part of the problem was that, apparently, the /home directory on my VM is NFS, which messes up a good many permissions.
What I've done:
I've set up my project in /var/www/myproject/
Run chown -R me:www-data myproject
Run chmod -R 764 myproject
My new results:
Without nginx running:
uwsgi --http :8000 --module myproject.wsgi
works perfectly
With nginx running:
uwsgi --socket myproject.sock --module myproject.wsgi --chmod-socket=664
gives me a 502
uwsgi --ini myproject.ini
gives me a 502
So now it's not a general permission issue, it's definitely an issue with nginx...
Update #2:
For the moment, everything is working when other has read-write permissions on the socket, and read-execute permissions on the rest of the project.
So nginx is not recognized as it should... I've double-checked, and nginx is running as the www-data user, which is the group-owner of my entire project, and which has read-execute permissions, just as other now has.
Here's my (updated) nginx.conf
# myproject_nginx.conf
# the upstream component nginx needs to connect to
upstream django {
# server unix:///path/to/your/mysite/mysite.sock; # for a file socket
server unix:///var/www/myproject/myproject.sock;
# server 127.0.0.1:8001; # for a web port socket (we'll use this first)
}
# configuration of the server
server {
# the port your site will be served on
listen 8000;
# the domain name it will serve for
server_name my.ip.goes.here; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 75M; # adjust to taste
# Django media
location /media {
alias /var/www/myproject/media; # your Django project's media files - amend as required
}
location /static {
alias /var/www/myproject/static; # your Django project's static files - amend as required
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /var/www/myproject/uwsgi_params; # the uwsgi_params file you installed
}
}
And here's my (updated) uwsgi.ini
# myproject_uwsgi.ini file
[uwsgi]
# Django-related settings
# the base directory (full path)
chdir = /var/www/myproject
# Django's wsgi file
module = myproject.wsgi
# the virtualenv (full path)
home = /var/www/myenv
# process-related settings
master = true
# maximum number of worker processes
processes = 10
# the socket (full path)
socket = /var/www/myproject/myproject.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
uid = me
gid = www-data
# clear environment on exit
vacuum = true
From my experience, most of the permission problems around web server are by accessing file which is owned by root, but Apache (nginx) is running under www-data user.
Try running sudo chown www-data -R /path/to/your/data/folder.
As the tutorial said:
You may also have to add your user to nginx’s group (which is probably
www-data), or vice-versa, so that nginx can read and write to your
socket properly.
Try that and see what happens.
As well I wouldn't recommend you doing things with sudo or as root, do it as a normal user and place the permission as it get necessary, otherwise you might end up in a situation that Nginx or uWSGI need to do something with the files and they are owned by root.
I've a Debian WebServer running Apache2.
How can I disable directory listing, globally, for all websites?
Note: This should also overwrite possible settings of virtual hosts.
Issue the following in you server terminal:
sudo a2dismod autoindex
service apache2 reload
After this all websites will have directory listing disabled.