Devo editar o arquivo / etc / crontab ou executar o crontab -e como root?

43

Estou configurando tarefas regulares de manutenção do sistema que precisam ser executadas como root. Eu pretendo usar o sabor do cron, que vem com o Ubuntu 14.04 LTS como padrão.

Eu vejo o administrador anterior (que deixou a empresa) editado o / etc / crontab diretamente. No entanto, eu entendo que outra abordagem possível seria usar crontab -ecomo root. Existe algum argumento convincente para usar um ou outro, ou é preferível?

linux cron ubuntu-14.04

— marcv81
fonte

9

Para mim, isso parece uma pergunta legítima de boas práticas e espero que não seja fechada. Eu já posso ver pontos relevantes relevantes nas respostas e comentários.

— MadHatter suporta Monica

1

Uma vez fui digitar crontab -l (para listar o crontab), mas digitei crontab -; por engano, que excluiu meu crontab. Eu aprendi muito naquele dia.

— Lumberjack

64

Pode ser útil observar que os trabalhos em um crontab pessoal ( crontab -e) são sempre executados como seus proprietários, onde /etc/crontabcontém um <user>campo obrigatório adicional , permitindo que um administrador configure o trabalho para ser executado como um usuário não raiz.

Editar o crontab do sistema ou configurar um crontab pessoal para root provavelmente é um pouco mais portátil, não específico para determinadas distribuições Linux e sem dúvida mais conveniente para uma pessoa manter, com todos os trabalhos em um único arquivo, mas:

Pessoalmente, sou a favor de uma terceira opção : para cada tarefa agendada, solte

um arquivo /etc/cron.d/com um trecho de cron
um executável (script) no /etc/cron.[hourly |daily |weekly |monthly]diretório relevante .

É mais fácil criar scripts (você pode simplesmente criar / sobrescrever / excluir esses arquivos e não precisa mexer no conteúdo de um único arquivo crontab) e isso funciona bem com as ferramentas de gerenciamento de configuração e é isso que os gerenciadores de pacotes já estão fazendo assim mesmo.

Os trabalhos / scripts /etc/cron.[hourly |daily |weekly |monthly]são sempre executados como raiz, onde os trechos do cron /etc/cron.d/permitem definir um agendamento personalizado e também executar como um usuário diferente com o mesmo <user>campo obrigatório encontrado em /etc/crontab.

— HBruijn
fonte

18

Uma desvantagem da edição /etc/crontabé que uma mesclagem será necessária sempre que você atualizar o cronpacote. Você não tem esse problema se apenas adicionar um novo arquivo a um dos /etc/cron.*diretórios.

— kasperd 6/09/16

1

Você deve adicionar que, na maioria das distros, /etc/cron.[hourly |daily |weekly |monthly]mantém executáveis, enquanto /etc/cron.dmantém crontabs. Fora isso, +1.

— GnP 12/09

Eu sou definitivamente um fã dos diretórios cron. [Timing], raramente preciso de algo mais granular do que as opções de comunicação. Embora observe que algumas distros, particularmente o Ubuntu, ignoram silenciosamente scripts com extensões de arquivo nessas pastas (um bug bastante revoltante da Internet, considerando que a maioria das pessoas adicionaria .sh, que pode ter sido corrigido em distros recentes). É muito difícil descobrir por que os scripts não estavam funcionando nessa situação - pelo menos a adição ao crontab é garantida para execução.

— 21816 Gargravarr #

15

Pelo que me lembro, crontab -etem a vantagem adicional de verificar a sintaxe do crontab antes de instalá-lo, e irá errar e restaurar a anterior se você cometer um erro. Dessa forma, tudo o que estava funcionando anteriormente não será interrompido repentinamente se você errar a sintaxe. Eu acho que a melhor prática é usar os utilitários, como executar em visudovez de editar /etc/sudoersdiretamente.

— Gargravarr
fonte

2

+1 Um bom argumento sobre a validação da sintaxe, embora reconheça alguns erros de sintaxe, também está longe de ser à prova de falhas (isto é, permitirá que você digite uma /etc/crontablinha com um nome de usuário na 6a coluna). - Embora eu queira argumentar que o uso de ferramentas interativas não é uma "prática recomendada" , você deve automatizar com ferramentas como Puppet / Salt / Ansible etc. e, em primeiro lugar, não deve mais configurar servidores manualmente. Por outro lado, se você é da velha escola, use suas ferramentas.

— HBruijn 6/09/16

Ansible e outros são bons se você configurar mais de 5 servidores, mas não vale a pena por apenas 1. Você pode argumentar que, com apenas 1 servidor, um script Ansible oferece a capacidade de reconstruí-lo de forma idêntica quando falha dois anos depois, mas Nesse ponto, é provável que o script não funcione mais devido a alterações nas distribuições / repositórios.

— Marcv81

Esta é a razão pela qual discordo veementemente da resposta aceita. Quaisquer que sejam as alterações que estão sendo feitas, devem ser executadas nesse processo de validação pelo menos uma vez. Se alguém copiar uma linha do novo crontab e fornecê-la a uma ferramenta automatizada para propagar para outros servidores, é o melhor dos dois mundos.

— perfil completo de Monty Harder

Não ajuda em caso de lançamento de um script e há erros no script; portanto, o teste de execução a seco é necessário de qualquer maneira.

— Mckenzm #

@mckenzm concordou, mas há tanta coisa que você pode aplicar à prova de idiotas :)

— Gargravarr

2

É realmente uma questão de estilo, há uma razão pela qual vários métodos são oferecidos pelo sistema operacional. Apenas seja consistente e não misture e combine, se você não quiser confundir mais ninguém (ou você mesmo depois de algum tempo sem lidar com o sistema) - se for difícil ver quais tarefas são realmente agendadas em todo o host, isso tende a para terminar em surpresas desagradáveis.

— rackandboneman
fonte

2

Para ter certeza de adicionar um trabalho cron que exija direitos de um usuário específico, eu pessoalmente uso o seguinte comando:

 # crontab -u <user> -e

Você pode adicionar sudotambém.

Como @rackandboneman afirmou, não há necessidade de mexer nos arquivos /etc/cron.d/. Se o assunto é sobre tarefas agendadas pelo usuário, use os recursos de crontabcomando.

— aesnak
fonte

3

-1 A grande desvantagem de fazer o exposto acima é que agora o usuário também pode modificar / excluir / interromper o cronjob, o que normalmente não é desejável quando você, como administrador, gasta seu tempo precioso configurando as coisas ... user é uma conta de serviço e essa conta está bloqueada / expirada, o serviço continuará sendo executado, mas as guias cron pessoais para contas bloqueadas geralmente serão desativadas.

— HBruijn 6/09/16

Se o usuário especificado aqui for um usuário público, como membro de um ambiente de serviço de terminal público, você está certo. No entanto, se o assunto é sobre o usuário de um serviço / agente ... pensando bem, é realmente sobre estilo.

— aesnak