O aplicativo Bottle.py não pode ser encontrado por nginx + uwsgi

2

Eu tenho um aplicativo do python 3 bottle.py que eu instalo em um ambiente virtual (permitindo que o pip busque automaticamente as dependências). Eu estou tentando fazê-lo funcionar sob nginx e uwsgi no meu pi de framboesa.

Quando eu tenho nginx e uwsgi em execução, visitando http://localhost/icecrate resulta em "uWSGI Error Python application not found". Eu suponho que isso significa que o nginx está se conectando corretamente ao uwsgi, e é o uwsgi que não consegue encontrar o aplicativo.

No entanto, se eu executar o aplicativo com uwsgi --http 0.0.0.0:8080 /etc/uwsgi/apps-enabled/icecrate.ini , então http://localhost:8080 me fornecerá o aplicativo, o que sugere que a configuração do uwsgi é pelo menos adequada.

Estou procurando no Google e nos documentos por algumas horas por uma solução. Eu não sei o que estou fazendo errado aqui.

/ etc / nginx / sites-disponíveis / icecrate

server {
  listen      80;
  server_name raspberrypi;

  access_log  /home/icecrate/logs/access.log;
  error_log   /home/icecrate/logs/error.log;

  location /icecrate {
    uwsgi_pass unix:///tmp/icecrate.sock;
    include    uwsgi_params;
  }
}

/etc/uwsgi/apps-available/icecrate.ini

[uwsgi]
vhost = true
plugins = python3
socket = /tmp/icecrate.sock
master = true
enable-threads = false
processes = 1

# this just imports the app callable and renames it to application
wsgi-file = /home/icecrate/nginx.py

# I get the same results using this method
#module = icecrate.web
#callable = app

virtualenv = /home/icecrate/env
touch-reload = /home/icecrate/reload

O código da aplicação está no GitHub .

    
por Erik Youngren 25.09.2013 / 02:20

1 resposta

2

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.

    
por 25.09.2013 / 10:37