Onde aplicativo web não-root deve gravar seu log no Ubuntu?

Question

Eu tenho um aplicativo python que é executado sob www-data para fins de segurança (não em root ). Em seus processos pode gerar arquivo de log específico do aplicativo, e eu quero colocar esse arquivo em algum lugar. Como percebo, /var/log tem root owner e drwxr-xr-x rights, então meu aplicativo não root não pode gravar log aqui. Qual é o lugar correto para escrever log nesse caso? Preciso lixeira www-data home folder com logs (como ~/.myapp.log ) ou alguma solução idiomática disponível?

    

Answer 1

É para isso que serve o /dev/log . Você pode configurar o daemon syslog para redirecionar as mensagens do seu aplicativo para qualquer arquivo que desejar.

De python, isso deve ser tão fácil quanto chamar syslog.syslog .

    

Answer 2

Seu aplicativo provavelmente não deve estar em execução como www-data . Crie um novo usuário do sistema para ele - --system se estiver usando adduser - e coloque seus arquivos em /srv/yourapp . Em seguida, você pode criar um diretório de log para ele, como /var/log/yourapp , ou manter os logs em /srv/yourapp/logs .

Dessa forma, seu servidor da Web é executado como www-data , seu aplicativo é executado como yourapp e você pode iniciar ambos do root. Por exemplo, usando nginx com a opção user www-data; em sua configuração e executando seu aplicativo como um aplicativo uWSGI (é um servidor de contêiner de aplicativo) com o apropriado

uid = yourapp
gid = yourapp

na configuração do .ini para yourapp em /etc/uwsgi/apps-enabled/ . A configuração do uWSGI espelha o estilo da configuração do nginx. Crie perfis de aplicativos em /etc/uwsgi/apps-available/ e crie links simbólicos para /etc/uwsgi/apps-enabled/ . Todo o resto deve ser tratado pela sua distribuição.

Tanto quanto eu posso dizer, esta é a abordagem canônica. Pelo menos para webapps do Ubuntu e python. E isso torna a administração geral mais simples: os scripts de inicialização devem funcionar como planejado sem nenhuma edição especial personalizada, as atualizações não devem quebrar nada ... os benefícios usuais.

Como um exemplo ainda mais específico, eu tenho um wiki MoinMoin rodando como um aplicativo uWSGI por trás do nginx no Ubuntu.

Do site nginx:

location = /wiki { return 301 /wiki/; }
location /wiki/ {
    gzip off;
    include uwsgi_params;
    uwsgi_param SCRIPT_NAME /wiki;
    uwsgi_modifier1 30;
    uwsgi_pass unix:/run/uwsgi/app/moin/socket;
}

De uWSGI moin.ini:

[uwsgi]
uid = moin
gid = moin

plugins = python
wsgi-file = /usr/share/moin/server/moin.wsgi
master = true

chmod-socket = 666
processes = 1

com todas as outras configurações completamente padrão ( usr/share/uwsgi/conf/default.ini para mim)

O MoinMoin tem seu próprio usuário separado

# grep moin /etc/passwd
moin:x:109:111::/srv/moin:/bin/false

e, como foi instalado do repositório como todo o resto (nginx, uwsgi), a configuração restante está em /etc/moin/ .