Dovrei modificare / etc / crontab o eseguire crontab -e come root?

43

Sto impostando regolari attività di manutenzione del sistema che devono essere eseguite come root. Ho intenzione di utilizzare il sapore di cron che viene fornito con Ubuntu 14.04 LTS come predefinito.

Vedo l'amministratore precedente (che da allora ha lasciato l'azienda) modificato direttamente / etc / crontab. Tuttavia capisco che un altro possibile approccio sarebbe usare crontab -ecome root. Ci sono argomenti convincenti da usare l'uno o l'altro o dipende dalle preferenze?

linux cron ubuntu-14.04

— marcv81
fonte

9

Per me, questa sembra una domanda legittima sulle migliori pratiche e spero che non venga chiusa. Vedo già punti rilevanti e concreti nelle risposte e commenti relativi.

— MadHatter supporta Monica il

1

Una volta sono andato a digitare crontab -l (per elencare il crontab) ma ho digitato crontab -; per errore che ha invece eliminato il mio crontab. Ho imparato molto quel giorno.

— Boscaiolo

64

Potrebbe essere utile notare che i lavori in un crontab personale ( crontab -e) vengono sempre eseguiti come proprietario, dove /etc/crontabcontiene un <user>campo obbligatorio aggiuntivo che consente all'amministratore di configurare il lavoro in modo che venga eseguito come utente non root.

La modifica del crontab di sistema o l'impostazione di un crontab personale per root sono probabilmente un po 'più portabili, non specifici per alcune distribuzioni Linux e probabilmente più convenienti da mantenere per una persona , con tutti i lavori in un singolo file ma:

Personalmente preferisco una terza opzione : per ogni operazione programmata, rilasciare

un file /etc/cron.d/con uno snippet cron
un eseguibile (script) nella relativa /etc/cron.[hourly |daily |weekly |monthly]directory.

È più facile da scrivere (puoi semplicemente creare / sovrascrivere / eliminare tali file e non devi preoccuparti del contenuto di un singolo file crontab) e funziona bene con gli strumenti di gestione della configurazione ed è quello che i gestori di pacchetti sono già facendo comunque.

I lavori / script in /etc/cron.[hourly |daily |weekly |monthly]vengono sempre eseguiti come root, in cui i frammenti di cron /etc/cron.d/consentono sia di impostare una pianificazione personalizzata sia di essere eseguiti come un altro utente con lo stesso <user>campo obbligatorio trovato in /etc/crontab.

— HBruijn
fonte

18

Uno svantaggio della modifica /etc/crontabè che sarà richiesta un'unione ogni volta che aggiorni il cronpacchetto. Non hai questo problema se aggiungi semplicemente un nuovo file a una delle /etc/cron.*directory.

— Kasperd,

1

Dovresti aggiungere che nella maggior parte delle distribuzioni /etc/cron.[hourly |daily |weekly |monthly]contiene eseguibili mentre /etc/cron.dcontiene crontab. A parte questo, +1.

— GnP,

Sono sicuramente un fan delle directory cron. [Timing], raramente ho bisogno di qualcosa di più granulare delle opzioni comuni. Tuttavia, tieni presente che alcune distro, in particolare Ubuntu, ignoreranno silenziosamente gli script con estensioni di file in queste cartelle (un bug abbastanza offensivo di Internet, considerando che la maggior parte delle persone aggiungerebbe .sh, che potrebbe essere stato corretto nelle recenti distro). È molto difficile capire perché gli script non funzionassero in quella situazione - almeno l'aggiunta al crontab è garantita per l'esecuzione.

— gargravarr

15

Come meglio ricordo, crontab -eha l'ulteriore vantaggio di verificare la sintassi di crontab prima di installarlo e, se commetterai un errore, sbaglierà e ripristinerà il precedente. In questo modo, tutto ciò che precedentemente funzionava non si interromperà improvvisamente se sbagli la sintassi. Penso che la migliore pratica sia quella di usare le utility, come eseguire visudoinvece di modificare /etc/sudoersdirettamente.

— gargravarr
fonte

2

+1 Un buon punto sulla convalida della sintassi, sebbene riconosca alcuni errori di sintassi, è anche tutt'altro che infallibile (cioè ti permetterà felicemente di inserire una /etc/crontabriga con un nome utente nella sesta colonna). - Anche se vorrei sostenere che l'uso degli strumenti interattivi non è una "buona pratica" , dovresti automatizzare con strumenti come Puppet / Salt / Ansible ecc. E non dovresti più configurare i server a mano in primo luogo. D'altra parte, se sei una vecchia scuola, allora effettivamente usa i tuoi strumenti.

— HBruijn,

Ansible e altri sono buoni se configuri 5+ server, ma non ne vale la pena per solo 1. Potresti sostenere che con solo 1 server uno script Ansible ti dà la possibilità di ricostruirlo in modo identico quando fallisce 2 anni lungo la linea, ma a quel punto è probabile che lo script non funzioni più a causa di modifiche di distro / repository.

— marcv81

Questa è la ragione per cui non sono d'accordo con veemenza con la risposta accettata. Qualunque modifica venga apportata, è necessario eseguire questo processo di convalida almeno una volta. Se uno quindi copia una linea dal nuovo crontab e lo fornisce a uno strumento automatizzato per propagarsi ad altri server, allora è il migliore dei due mondi.

— Monty Harder,

Né di aiuto se si avvia uno script e ci sono errori nello script, quindi è richiesto il test di funzionamento a secco in entrambi i modi.

— mckenzm,

@mckenzm è d'accordo, ma c'è solo così tanta prova dell'idiota che puoi applicare :)

— Gargravarr

2

È davvero una domanda di stile, c'è una ragione per cui il sistema operativo offre diversi metodi. Sii coerente e non mescolare e abbinare se non vuoi confondere qualcun altro (o te stesso dopo un po 'di tempo in cui non hai a che fare con il sistema) - se è difficile vedere quali attività sono effettivamente programmate nell'intero host, tende per finire in brutte sorprese.

— rackandboneman
fonte

2

Per essere sicuro di aggiungere un cron job che richiede i diritti di un utente specifico, uso personalmente il seguente comando:

 # crontab -u <user> -e

Puoi sudoanche aggiungere .

Come affermato da @rackandboneman, non è necessario pasticciare con i file /etc/cron.d/. Se la questione riguarda i lavori cron dell'utente, utilizzare le funzionalità del crontabcomando.

— aesnak
fonte

3

-1 Il grande svantaggio di fare quanto sopra è che l'utente è ora in grado di modificare / cancellare / rompere anche il cronjob, che in genere non è desiderabile quando tu come amministratore hai trascorso il tuo prezioso tempo a configurare le cose ... Anche quando il L'utente è un account di servizio e quell'account è bloccato / scaduto, il servizio continuerà a essere eseguito, ma le schede cron personali per gli account bloccati verranno generalmente disabilitate.

— HBruijn,

Se l'utente specificato qui è un utente pubblico come membro di un ambiente di servizio di terminale pubblico, hai ragione. Tuttavia, se la questione riguarda l'utente di un servizio / agente ... ripensandoci, si tratta davvero di stile.

— aesnak,