Erro semanal de Cron / Logrotate / Denyhosts

Question

Estou recebendo o seguinte e-mail de erro toda semana. Parece ser um problema com cron, logrotate ou denyhosts. Não tenho certeza de qual.

Subject: Cron <root@vps> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

/etc/cron.daily/logrotate:
test: 91: /etc/hosts.deny: unexpected operator

Alguma sugestão?

    

Answer 1

/etc/logrotate.d/denyhosts is very short and doesn't seem to me to use test:

Sim, mas tem isto:

postrotate
/etc/init.d/denyhosts restart > /dev/null
endscript

e esse script faz coisas como

    HOSTS_DENY=$(grep ^HOSTS_DENY $CONFIG  | cut -d = -f 2)
    test -e $HOSTS_DENY || touch $HOSTS_DENY

supondo que o script esteja correto, se eu tivesse que adivinhar, eu diria que sua linha HOSTS_DENY no seu arquivo de configuração está malformada de alguma forma.

Felizmente, não precisamos adivinhar, esse comando mostrará exatamente de onde o erro está vindo:

/bin/sh -x /etc/init.d/denyhosts restart

    

Answer 2

Para mim, parece que há um erro na linha 91 do /etc/hosts.deny ou /etc/cron.daily/logrotate.

Certifique-se de que as entradas em hosts.deny estejam formatadas de forma válida.

    

Answer 3

Minha aposta é que em algum lugar há um script sh com um sinal de igual duplo ("==") em um comando test em vez de um único ("="). O test do Bash permite == ou = , mas o shell Bourne (pelo menos dash no Ubuntu) permite apenas = . Além disso, meu /usr/bin/test permite apenas o único igual. Mas veja a parte inferior desta resposta para outros exemplos que produzem esse mesmo erro.

Eu procuraria em logrotate.conf e veria se tem uma linha 91 que possa ter esse problema.

Se, por algum motivo, você quiser recriar a mensagem de erro para teste:

Crie um arquivo, vamos chamá-lo de "a", com o seguinte conteúdo:

echo 'In script "a"'
f="/etc/hosts.deny"
test $f == "foo"

Agora faça:

sh a

Você deve receber:

In script "a"
test: 3: /etc/hosts.deny: unexpected operator

Você também pode reproduzir um erro semelhante usando um dos itens a seguir:

sh -c "test /etc/hosts.deny +"
sh -c "test /etc/hosts.deny -"
sh -c "test /etc/hosts.deny /"
sh -c "test /etc/hosts.deny *"

Editar : tente o seguinte para restringir sua pesquisa:

$ su -
$ find /etc -type f | xargs awk 'FNR==91 && /test/ {print FILENAME, $0}'

Você irá su para root e, em seguida, executará o comando find / awk . Ele mostrará os nomes dos arquivos e a linha 91 do arquivo se a palavra "test" aparecer nessa linha, para cada arquivo em /etc . Então você pode procurar operadores que estão incorretos.

    

Answer 4

Que tal em /etc/logrotate.d/denyhosts?

    

Answer 5

/etd/logrotate.d/denyhosts é muito curto e parece não usar teste:

/var/log/denyhosts {
create 0640 root root
missingok e weekly
rotate 7 e compress e postrotate e /etc/init.d/denyhosts restart > /dev/null
endscript
}

A única instância de "teste" na linha 91 de um arquivo em / etc está em um arquivo não relacionado.

O ponto de trabalho cron.daily / logrotate em / usr / sbin / logrotate (um arquivo binário) - se o bug estiver lá, onde posso verificar o código-fonte?

    

Answer 6

Apenas por sanidade você pode querer usar:

foo:~# which test
/usr/bin/test

para ver se o programa de teste é o que você acha que é. Um método de programação defensiva é usar o caminho completo para comandos em tarefas agendadas. Isso garante que o binário adequado seja chamado e impede que um invasor substitua outro comando com nome semelhante anteriormente em seu PATH.

    

Answer 7

Veja algumas dicas de solução de problemas. Eu acho que Justin está absolutamente no caminho certo. O problema provavelmente está na configuração do seu denyhosts. Mas vamos rastrear isso.

Você está recebendo o erro originalmente do logrotate. Então corra logrotate:

logrotate /etc/logrotate.conf

Supondo que você tenha um erro, pelo menos você tem um caso reproduzível. Agora vamos ver se o problema está em logrotate ou denyhosts. Vamos usar o comando denyhosts que vimos no logrotate:

/etc/init.d/denyhosts restart > /dev/null

Se isso lhe der um erro, você está realmente perto de rastrear isso. Tente retirar o "> / dev / null" do final da linha para obter mais informações. Poste a saída aqui para ajuda.

No entanto, se nenhum dos dois truques acima causou um erro, mas você ainda está recebendo o erro das tarefas do cron, você tem um problema. Esperar uma semana entre tentativas de depurar algo é uma droga.

Adicione outra linha ao seu / etc / crontab. Copie a linha cron.weekly e cole-a abaixo de todas as outras linhas. Em seguida, edite-o para que todas as entradas "when" sejam asteriscos.

47  6   *   *   7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )

Altere para:

*   *   *   *   *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )

Em seguida, ele será executado uma vez por minuto durante todo o dia, durante toda a semana. Isso é obviamente não algo que você gostaria de deixar lá, mas pode ser útil na solução de problemas.

Nos casos em que você vê erros nos cron jobs que você não vê ao executar os scripts a partir da linha de comando, é quase sempre uma diferença em seu ambiente. Verifique o caminho primeiro.

    

Answer 8

Eu tive esse mesmo problema depois de desinstalar o pacote denyhosts. Confirme se você realmente tem o pacote instalado:

mlambie@prime:~$ dpkg -l | grep denyhosts
rc  denyhosts                              2.6-6.1ubuntu1                    a utility to help sys admins thwart SSH crac

Você terá "ii" como os dois primeiros caracteres, se o pacote estiver instalado. Por exemplo, eu tenho o openssh-server instalado e obtenho este resultado:

mlambie@prime:~$ dpkg -l | grep openssh-server
ii  openssh-server                         1:5.3p1-3ubuntu7                  secure shell (SSH) server, for secure access

No meu caso, acho que a configuração do logrotate não foi removida com sucesso quando o pacote foi removido, então eu o rm'd manualmente.