Eu acabei nuking a tentativa e todas as configurações e começar de novo, mas eu acho que eu entendi isso. Estou razoavelmente certo de que foi um problema de permissões.
Por padrão, o nginx.conf especificou www-data
como o usuário que executa, e a tentativa anterior não fez nenhum esforço para lidar com isso. Todos os arquivos eram de minha propriedade. Em vez de alterar o usuário padrão, criei uma pasta pessoal para www-data
, que agora contém o virtualenv icecrate. Ao configurar o aplicativo, usei sudo -s -u www-data
para fazer toda a criação do arquivo, para que todos os arquivos tenham o proprietário e as permissões adequadas.
A configuração do Nginx é essencialmente a mesma, exceto que a pasta virtualenv agora é reproduzida no soquete e nos logs:
server {
listen 80;
server_name = raspberrypi;
access_log /home/www-data/icecrate/logs/access.log;
error_log /home/www-data/icecrate/logs/error.log;
location /icecrate {
uwsgi_pass unix:///home/www-data/icecrate/icecrate.sock;
include uwsgi_params;
}
}
Eu pulei algumas coisas que não pareciam importantes para o problema enquanto reconstruía o aplicativo uwsgi ini, mas ele também é essencialmente o mesmo:
[uwsgi]
plugins = python3
socket = /home/www-data/icecrate/icecrate.sock
module = icecrate.web:app
virtualenv = /home/www-data/icecrate
touch-reload = /home/www-data/icecrate/reload
# like ngnix, uwsgi should be www-data.
uid = www-data
gid = www-data
# don't think this works, though
logto = /home/www-data/icecrate/logs/uwsgi.log
Depois de colocar os arquivos de configuração em sites-enabled
e apps-enabled
, respectivamente, iniciei nginx
e uwsgi
e apontei meu navegador para http://localhost/icecrate
e recebi um erro bottle.py 404. Eu não acho que eu tenha sido tão feliz na minha vida para ver um 404.