DjangoBB LoFi version

Полная версия: Django+Supervisor+NGINX on Ubuntu server 18.04. Проблемы с динамическим содержимым.

Начало » Python для новичков » Django+Supervisor+NGINX on Ubuntu server 18.04. Проблемы с динамическим содержимым.

gtlhbkkj

Апрель 18, 2020 16:25:46

Пытаюсь настроить свой вебсайт на рабочем сервере.
1. при простом запуске Джанго без Гуникорна и НГИНХа на 0.0.0.0:80 все функционирует.
2. при настроенных НГИНХе и Гуникорне, веб сайт также работает как положено

 Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)
(venv) root@t-20200417:~/dj/ako# gunicorn --bind 0.0.0.0:8000 ako.wsgi 
[2020-04-18 13:44:15 +0200] [1768] [INFO] Starting gunicorn 20.0.4
[2020-04-18 13:44:15 +0200] [1768] [INFO] Listening at: http://0.0.0.0:8000 (1768)
[2020-04-18 13:44:15 +0200] [1768] [INFO] Using worker: sync
[2020-04-18 13:44:15 +0200] [1771] [INFO] Booting worker with pid: 1771

Когда запускаю супервизора

 sudo service supervisor start

вебсайт все еще доступен http://95.217.187.37/rsf/f_size_water/ из броузера, статические линки все еще работают, но динамическое содержание на работает.

То есть когда в менюшке “поменять язык” меняю язык, броузер неожиданно идет на несуществующую страницу http://95.217.187.37/i18n/setlang/ и выдает Bad Request (400)

Или когда пытаюсь отправить вебформу то получаю Server Error (500)

Прошу профессионального совета.
Спасибо

VadimK

Апрель 18, 2020 22:23:55

Как минимум посмотреть логи джанги, плюс включить в ней DEBUG=True.

supervisor - это просто сервис для автозапуска чего угодно. Как минимум в данном случае должен быть отдальный конфиг в котором указывается, как супервизору запускать джанговский проект.

Так что смотреть как описан процесс запуска в этом конфиге и сравнить его с запуском вручную.

gtlhbkkj

Апрель 19, 2020 00:42:48

VadimK
Как минимум посмотреть логи джанги, плюс включить в ней DEBUG=True.

ошибка при смене языка в меню

 SuspiciousOperation at /i18n/setlang/
The request's session was deleted before the request completed. The user may have logged out in a concurrent request, for example.
Request Method: 	POST
Request URL: 	http://95.217.187.37/i18n/setlang/
Django Version: 	3.0.3
Exception Type: 	SuspiciousOperation
Exception Value: 	
The request's session was deleted before the request completed. The user may have logged out in a concurrent request, for example.
Exception Location: 	/home/oleg/dj/venv/lib/python3.6/site-packages/django/contrib/sessions/middleware.py in process_response, line 61
Python Executable: 	/home/oleg/dj/venv/bin/python
Python Version: 	3.6.9
Python Path: 	
['/home/oleg/dj/ako',
 '/home/oleg/dj/venv/bin',
 '/usr/lib/python36.zip',
 '/usr/lib/python3.6',
 '/usr/lib/python3.6/lib-dynload',
 '/home/oleg/dj/venv/lib/python3.6/site-packages']
Server time: 	Sat, 18 Apr 2020 20:53:12 +0000
 The above exception (attempt to write a readonly database) was the direct cause of the following exception:
/home/oleg/dj/venv/lib/python3.6/site-packages/django/contrib/sessions/backends/db.py in save
 During handling of the above exception (attempt to write a readonly database), another exception occurred:
/home/oleg/dj/venv/lib/python3.6/site-packages/django/contrib/sessions/middleware.py in process_response
                            request.session.save()

ошибка при отправке формы и записи в базу

 OperationalError at /rsf/f_size_water/
attempt to write a readonly database
Request Method: 	POST
Request URL: 	http://95.217.187.37/rsf/f_size_water/
Django Version: 	3.0.3
Exception Type: 	OperationalError
Exception Value: 	
attempt to write a readonly database
Exception Location: 	/home/oleg/dj/venv/lib/python3.6/site-packages/django/db/backends/sqlite3/base.py in execute, line 396
Python Executable: 	/home/oleg/dj/venv/bin/python
Python Version: 	3.6.9
Python Path: 	
['/home/oleg/dj/ako',
 '/home/oleg/dj/venv/bin',
 '/usr/lib/python36.zip',
 '/usr/lib/python3.6',
 '/usr/lib/python3.6/lib-dynload',
 '/home/oleg/dj/venv/lib/python3.6/site-packages']
Server time: 	Sat, 18 Apr 2020 20:56:02 +0000
 The above exception (attempt to write a readonly database) was the direct cause of the following exception:
/home/oleg/dj/venv/lib/python3.6/site-packages/django/core/handlers/exception.py in inner
                response = get_response(request)

поменял владельца папки и базы

 root@t-20200417:~/dj# chown www-data:www-data /home/oleg/dj/ako
root@t-20200417:~/dj# chown www-data:www-data /home/oleg/dj/ako/db.sqlite3
root@t-20200417:~/dj# ls -la /home/oleg/dj/ako/
drwxr-xr-x 4 www-data www-data    4096 Apr 18 16:40 .
drwxr-xr-x 4 root     root        4096 Apr 16 22:59 ..
drwxr-xr-x 3 root     root        4096 Apr 18 22:57 ako
-rw-r--r-- 1 root     root       16387 Apr 18 22:57 ako_supervisor.log
-rw-r--r-- 1 www-data www-data 2625536 Apr 18 14:30 db.sqlite3
-rw-r--r-- 1 root     root         761 Apr 18 12:05 log.txt
-rwxr-xr-x 1 root     root         623 Apr 16 22:49 manage.py
drwxr-xr-x 9 root     root        4096 Apr 17 18:41 rsf

ошибка остается прежней

VadimK

Апрель 19, 2020 02:30:56

>attempt to write a readonly database
supervisor по видимости запускает проект под другим юзером. Соответственно проект не может записать в файл.

>-rw-r–r– 1 www-data www-data 2625536 Apr 18 14:30 db.sqlite3
права отданы юзеру под которым работает nginx . А надо отдать тому, под которым супервизор запускает джангу.
Ну или “chmod 0666 db.sqlite3” - но потом такой же косяк возможно будет /media и прочим.

Раз проект работает от “oleg” юзера, то ему и отдать права.
В обещем найти ini файл супервизора именно для этого проекта (не путать с конфигом самого супервизора) и добавить туда “user=oleg”

gtlhbkkj

Апрель 19, 2020 11:34:00

VadimK
Раз проект работает от “oleg” юзера, то ему и отдать права.

поменял юзера в обоих конфигах c “nobody” на “oleg”. Правильно ли это? когда менял юзера только в супервизоре не работало.

 nano gunicorn.conf.py

 bind = '127.0.0.1:8000'
workers = 3
user = "oleg"

 cd /etc/supervisor/conf.d/
nano ako.conf

 [program:ako]
command=/home/oleg/dj/venv/bin/gunicorn ako.wsgi:application -c /home/oleg/dj/ako/ako/gunicorn.conf.py
directory=/home/oleg/dj/ako
user=oleg
autorestart=true
redirect_stderr=true
stdout_logfile=/home/oleg/dj/ako/ako_supervisor.log
stderr_logfile=/home/oleg/dj/ako/ako_supervisor.log
autostart=true
autorestart=true
startsecs=10

.
всё заработало.
благодарю за помощь.
-
Кстати по вашей профессиональной рекомендации на хетцнере сделал на минимальном облачном сервере за 2,99 Евро.

VadimK

Апрель 19, 2020 15:48:38

supervisor запускает процесс под указанным юзером. Т.е. дополнительно указывать юзера в gunicorn смысла уже нет, так он будет уже как oleg запущен и переключиться на другого юзера уже не будет иметь возможности.
Хотя если так ранее не работало, то оставить так, как работает. Или в свободное время искать причину, почему не под указанным юзером запускается.

gtlhbkkj

Апрель 19, 2020 15:55:02

VadimK
Или в свободное время искать причину, почему не под указанным юзером запускается.

раньше на обоих - на гуникорне и на супервизоре было user=nobody
и пока на обоих не поменял юзера не работало
мне непросто диагностировать причину, потому что у меня опыт работы с юниксами одна неделя.