O Logrotate não lê mais o arquivo de configuração vinculado por causa da propriedade não-raiz

Question

No momento, estamos atualizando do Ubuntu 12.04 LTS para o 14.04 LTS em nossos servidores de aplicativos Ruby on Rails e notamos que os arquivos de log não estão mais sendo rotacionados.

Em ambas as máquinas, temos um arquivo /var/app-name/config/logrotate de propriedade de nosso usuário unix deployer que contém um arquivo logrotate válido da seguinte forma:

/var/app-name/log/*.log {
  daily
  rotate 365
  delaycompress
  compress
  dateext
  dateformat -%Y%m%d
  missingok
  copytruncate
}

Isso é então vinculado a um erro no diretório /etc/logrotate.d/ como app-name

Em nosso servidor Ubuntu 12.04, temos o logrotate 3.7.8, que funciona muito bem. Ele vai para o diretório var/app-name/log/ e rotaciona todos os arquivos de log

Mas no servidor Ubuntu 14.04 nós temos o logrotate 3.8.7 que não roda os arquivos de log para a nossa aplicação.

Quando eu depurar isso via sudo logrotate -d -f /etc/logrotate/.conf , recebo a seguinte saída:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

Perseguindo isso no código, parece que essa alteração foi adicionada para o fluxo de versão 3.8.x: link

Se eu alterar a propriedade do arquivo linkado como symlinked para /var/app-name/config/logrotate to root , ele começará a funcionar novamente. Mas, como esse arquivo faz parte do meu aplicativo e é criado pela estrutura de implantação do capistrano que usamos nesse estado, prefiro não alterar a propriedade, quando costumava funcionar muito bem.

Então, os arquivos de configuração com links simbólicos são recomendados / suportados pelo logrotate?

Em caso afirmativo, se a recusa em usar o meu arquivo (de propriedade de deployer ), que é linkado como symlink no diretório /etc/logrotate.d , seja visto como um bug?

Ou existe outra abordagem recomendada para a rotação de logs específica de aplicativos?

(também solicitado em unix StackExchange )

    

Answer 1

O problema é que um arquivo de configuração logrotate pode executar qualquer comando como root (usando sub-rotinas prerotate / postrotate). Portanto, você estaria efetivamente concedendo privilégios de usuário root deployer , concedendo acesso de gravação aos arquivos em /etc/logrotate.d/ . Então não, não é um bug.

Se você confia no seu usuário do implantador, então você pode resolver o problema dando a ele o direito de sudo para copiar os arquivos para /etc/logrotate.d/ . Assumindo, claro, que o usuário do implantador não é o mesmo usuário em que o aplicativo da Web está sendo executado.

    

Answer 2

Percebo que estou meio atrasado para a festa, mas estava tendo um problema semelhante e pensei em compartilhar minha solução.

Meus problemas começaram quando logrotate não leu a configuração que eu havia escrito. Eu não queria implantar novas configurações em uma pasta de propriedade do root porque eu não queria que o usuário de implantação tivesse acesso root a qualquer coisa .

Primeiro, tentei executar logrotate como o usuário de implementação, mas ele reclamou de ter acesso ao arquivo de estado em /var/lib/logrotate/state . Então eu li a man page. Você pode especificar o arquivo de estado que logrotate usa! Então, pareceu-me uma solução melhor configurar um cron diário para executar logrotate como o usuário de implantação com um arquivo de estado personalizado. Dessa forma, nenhum acesso root é necessário para o usuário de implementação ou o aplicativo.

Veja como você especifica o arquivo de estado:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

Agora você pode rodar o logrotate como qualquer usuário e proprietário da configuração que você goste!