'tail -n 40 /var/log/apache2/error.log' sem 'sudo'

2

Muitas vezes durante o dia, preciso inspecionar meu log do Apache:

sudo tail -n 40 /var/log/apache2/error.log

Eu então tenho que fornecer minha senha.

É um fluxo de trabalho desajeitado, por isso estou adicionando PATH=$HOME/shortcuts:$PATH ao meu ~/.profile e criando ~/shortcuts/1 para isso.

No entanto, eu preciso de alguma forma contornar ter que digitar a senha a cada vez. (quase sempre, parece haver uma memória de 10 minutos).

Não posso apenas chmod u+r /var/log/apache2/error.log - acho que alguma pasta intermediária deve ter permissões restritivas definidas.

Qual é o caminho certo para resolver isso?

    
por P i 25.07.2015 / 15:02

3 respostas

4

Posso pensar em muitas soluções para esse problema específico:

(A) Configure o acesso sudo de modo que seu nome de usuário não exija senha para o comando tail (ou para todos os comandos, se assim for necessário)
Indique sudo e sudoers Documentação para isto.

(B) Configure o acesso sudo com tempo limite negativo. O tempo limite padrão é de 5 minutos, depois disso você terá que redigitar a senha.
Ao definir o tempo limite para valores negativos, você pode ter que digitar a senha apenas uma vez, e o sudo não irá importuná-lo depois disso.

(C) Use tmux (ou screen) e execute o comando tail em um painel (ou uma janela).
Sempre que você quiser ver os logs, você pode ver o painel (ou janela).

(D) Execute um processo de back ground que envia a saída "tail -f" para um arquivo em / tmp / ApacheError, que é uma cópia exata do log que você deseja acessar. Com base nas configurações do seu sistema, "tee" também pode ser necessário.
Agora acesse o log em / tmp / ApacheError que tem permissão de leitura para todos os usuários.

(E) Considere o uso de filtros de log do apache, que podem ser usados para enviar saída Duplicada para / tmp / ApacheError, o que exigirá a referência à Documentação do Apache.
Agora acesse o log em / tmp / ApacheError que tem permissão de leitura para todos os usuários.

(A) e (B) são riscos de segurança. (C) requer o tmux (ou tela), que pode não estar disponível. (D) é seguro. (E) pode exigir mais pesquisas.

    
por 25.07.2015 / 15:32
4

chmod u+r não faz o que você aparentemente acha que faz; o que realmente faz é tornar o arquivo legível pelo seu proprietário . O que, eu acho, já foi.

chmod o+r (tornar o arquivo legível por "outros", ou seja, não proprietário / grupo) provavelmente funcionaria, mas a segurança argumenta contra isso.

Escolha um:

  1. ls -l /var/log/apache2/error.log ... no meu sistema (Debian), seu grupo é adm e é g+r . O grupo adm existe basicamente para permitir a leitura de arquivos de log. Então, adicionando-me a esse grupo, vou ler (e outros logs). No Debian, isso seria sudo adduser anthony adm (onde, é claro, anthony é meu nome de usuário). OBSERVAÇÃO: você terá que sair e voltar para o novo grupo entrar em vigor. Em um terminal, newgrp adm deve funcionar.

  2. Use uma ACL POSIX para conceder acesso de leitura a esse arquivo específico. sudo setfacl -m u:anthony:r /var/log/apache2/error.log (use seu nome de usuário no lugar de anthony ). Embora dependa de como a rotação de logs funciona em seu sistema, pode ser necessário executar novamente isso após a rotação (mas você pode configurar, por exemplo, taxa de registro para fazer isso para você).

  3. As várias formas de reconfigurar o sudo na resposta do Prem.

por 25.07.2015 / 17:38
3

Execute sudo visudo e adicione esta linha:

Defaults    timestamp_timeout=-1

-1 = nunca tempo limite da senha

Veja também man 5 sudoers

Embora a solução acima atraia preocupações de segurança. Por favor, siga este link link para configurar sudo para executar sem senha para comandos específicos.

    
por 25.07.2015 / 15:34