Soluzione 1:
Potrebbe essere utile notare che i job in un crontab personale (crontab -e ) vengono sempre eseguiti come proprietario, dove /etc/crontab contiene un ulteriore <user> obbligatorio campo che consente a un 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 per una persona da mantenere, con tutti i lavori in un unico file ma:
Personalmente preferisco una terza opzione :per ogni attività pianificata rilasciare
- un file in
/etc/cron.d/con uno snippet cron - un eseguibile (script) nel relativo
/etc/cron.[hourly |daily |weekly |monthly]cartella.
È più facile da scrivere (puoi semplicemente creare/sovrascrivere/eliminare tali file e non devi confondere il contenuto di un singolo file crontab) e funziona bene con gli strumenti di gestione della configurazione ed è ciò che i gestori di pacchetti sono già facendo comunque.
Lavori/script in /etc/cron.[hourly |daily |weekly |monthly] vengono sempre eseguiti come root, dove i cron snippet in /etc/cron.d/ consentire sia l'impostazione di una pianificazione personalizzata sia l'esecuzione come utente diverso con lo stesso <user> obbligatorio campo trovato in /etc/crontab .
Soluzione 2:
Come meglio ricordo, crontab -e ha l'ulteriore vantaggio di verificare la sintassi di crontab prima di installarlo e, in caso di errore, commetterà errori e ripristinerà la precedente. In questo modo, tutto ciò che funzionava in precedenza non si fermerà improvvisamente se si sbaglia la sintassi. Penso che la migliore pratica sia usare le utilità, come eseguire visudo piuttosto che modificare /etc/sudoers direttamente.
Soluzione 3:
È davvero una domanda di stile, c'è un motivo per cui il sistema operativo offre più metodi. Sii coerente e non mescolare e abbinare se non vuoi confondere nessun 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 pianificate nell'intero host, tende per finire con brutte sorprese.
Soluzione 4:
Per essere sicuro di aggiungere un cron job che richiede i diritti di un utente specifico, utilizzo personalmente il seguente comando:
# crontab -u <user> -e
Puoi aggiungere sudo anche.
Come affermato da @rackandboneman, non è necessario fare confusione con i file /etc/cron.d/. Se la questione riguarda i cron job dell' utente, usa le funzionalità di crontab comando.