Devrais-je éditer / etc / crontab ou exécuter crontab -e en tant que root?

43

Je configure des tâches de maintenance système régulières qui doivent s'exécuter en tant que root. Je prévois d'utiliser la version de cron fournie avec Ubuntu 14.04 LTS par défaut.

Je vois l’administrateur précédent (qui a depuis quitté la société) a édité directement / etc / crontab. Cependant, je comprends qu'une autre approche possible serait d'utiliser crontab -ecomme racine. Existe-t-il des arguments convaincants pour utiliser l'un ou l'autre, ou est-ce une préférence?

linux cron ubuntu-14.04

— Marcv81
source

9

Pour moi, cela ressemble à une question légitime de meilleure pratique, et j'espère que cela ne se fermera pas. Je vois déjà des points factuels pertinents dans les réponses et des commentaires y relatifs.

— MadHatter soutient Monica le

1

Une fois, j’ai tapé crontab -l (pour lister la crontab) mais j’ai tapé crontab -; par erreur qui a supprimé ma crontab à la place. J'ai beaucoup appris ce jour-là.

— Lumberjack

64

Il peut être utile de noter que les travaux d'une crontab ( crontab -e) personnelle sont toujours exécutés en tant que propriétaire, /etc/crontabcontenant un <user>champ obligatoire supplémentaire permettant à un administrateur de configurer le travail pour qu'il s'exécute en tant qu'utilisateur non root.

L'édition de la crontab système ou la configuration d'une crontab personnelle pour root sont probablement un peu plus portables, non spécifiques à certaines distributions Linux et sans doute plus faciles à gérer pour une personne , avec tous les travaux dans un seul fichier mais:

Personnellement, je privilégie une troisième option : pour chaque tâche planifiée, supprimez soit

un fichier /etc/cron.d/avec un extrait de cron
un exécutable (script) dans le /etc/cron.[hourly |daily |weekly |monthly]répertoire approprié .

C'est plus facile à écrire (vous pouvez simplement créer / écraser / supprimer de tels fichiers sans avoir à vous soucier du contenu d'un seul fichier crontab) et cela fonctionne bien avec les outils de gestion de la configuration et c'est ce que les gestionnaires de paquets sont déjà faire quand même.

Les travaux / scripts dans /etc/cron.[hourly |daily |weekly |monthly]sont toujours exécutés en tant que root, les extraits cron /etc/cron.d/autorisant à la fois la définition d’un calendrier personnalisé et l’exécution en tant qu’utilisateur différent avec le même <user>champ obligatoire trouvé dans /etc/crontab.

— HBruijn
source

18

Un inconvénient de l'édition /etc/crontabest qu'une fusion sera nécessaire à chaque mise à jour du cronpackage. Vous n'avez pas ce problème si vous ajoutez simplement un nouveau fichier à l'un des /etc/cron.*répertoires.

— kasperd

1

Vous devriez ajouter que dans la plupart des distributions, /etc/cron.[hourly |daily |weekly |monthly]contient les exécutables et les /etc/cron.dcrontabs. Autre que cela, +1.

— GnP

Je suis définitivement un fan des répertoires cron. [Timing], j’ai rarement besoin de quelque chose de plus granulaire que les options communes. Cependant, veuillez noter que certaines distributions, en particulier Ubuntu, ignoreront silencieusement les scripts avec des extensions de fichiers dans ces dossiers (un bogue assez scandaleux pour Internet, considérant que la plupart des gens ajouteraient .sh, qui pourrait avoir été corrigé dans les distributions récentes). Il est très difficile de comprendre pourquoi les scripts ne fonctionnent pas dans cette situation. Au moins, ajouter à la crontab est garanti pour l'exécution.

— Gargravarr

15

Autant que je me souvienne, elle crontab -eprésente l’avantage supplémentaire de vérifier la syntaxe de la crontab avant de l’installer, d’erreur et de restaurer la précédente si vous faites une erreur. De cette façon, tout ce qui fonctionnait auparavant ne s'arrêtera pas brusquement si la syntaxe est incorrecte. Je pense que la meilleure pratique consiste à utiliser les utilitaires, comme exécuter visudoplutôt que d’éditer /etc/sudoersdirectement.

— Gargravarr
source

2

+1 Bon point à propos de la validation de la syntaxe, bien qu'il reconnaisse certaines erreurs de syntaxe, il est également loin d'être infaillible (c.-à-d. Qu'il vous permettra d'entrer une /etc/crontabligne avec un nom d'utilisateur dans la 6ème colonne). - Bien que je voudrais dire que l'utilisation d'outils interactifs n'est pas une "bonne pratique" , vous devez l'automatiser avec des outils tels que Puppet / Salt / Ansible, etc., et ne devez plus configurer les serveurs à la main. Par contre, si vous êtes à l’école, utilisez bien vos outils.

— HBruijn

Ansible et d'autres sont bons si vous configurez plus de 5 serveurs, mais ne valent pas la peine pour seulement un. Vous pouvez dire qu'avec un seul serveur, un script Ansible vous donne la possibilité de le reconstruire à l'identique lorsqu'il échoue deux ans plus tard, mais à ce stade, le script risque de ne plus fonctionner en raison de modifications de la distribution / mise en pension.

— marcv81

C'est la raison pour laquelle je suis en désaccord véhément avec la réponse acceptée. Quelles que soient les modifications apportées, elles doivent être exécutées au moins une fois dans ce processus de validation. Si l'on copie ensuite une ligne de la nouvelle crontab et la fournit à un outil automatisé pour qu'il se propage sur d'autres serveurs, c'est le meilleur des deux mondes.

— Monty Harder

Aucune aide si vous lancez un script et que celui-ci contient des erreurs. Par conséquent, des essais à blanc sont nécessaires dans les deux cas.

— mckenzm

@mckenzm est d'accord, mais il n'y a que très peu de tests anti-imbéciles à appliquer :)

— Gargravarr le

2

C'est vraiment une question de style, il y a une raison pour laquelle plusieurs méthodes sont offertes par le système d'exploitation. Soyez juste cohérent et ne mélangez pas si vous ne voulez pas confondre qui que ce soit (ou vous-même après un certain temps d'inactivité avec le système) - s'il est difficile de voir quelles tâches sont réellement planifiées sur tout l'hôte, pour finir par de mauvaises surprises.

— rackandboneman
source

2

Afin d’être sûr d’ajouter un travail cron qui requiert des droits d’utilisateur spécifiques, j’utilise personnellement la commande suivante:

 # crontab -u <user> -e

Vous pouvez ajouter sudoaussi.

Comme @rackandboneman l'a déclaré, il n'est pas nécessaire de jouer avec les fichiers /etc/cron.d/. Si le problème concerne les tâches cron de l'utilisateur, utilisez les fonctionnalités de crontabcommande.

— Aesnak
source

3

-1 Le gros inconvénient de ce qui précède est que l'utilisateur est désormais capable de modifier / supprimer / supprimer le travail cron, ce qui n'est généralement pas souhaitable lorsque vous, en tant qu'administrateur, passez votre temps précieux à configurer ... L'utilisateur est un compte de service et ce compte est verrouillé / expiré, le service continue de fonctionner, mais les onglets cron personnels des comptes verrouillés sont généralement désactivés.

— HBruijn

Si l'utilisateur spécifié ici est un utilisateur public tel qu'un membre d'un environnement de service de terminal public, vous avez raison. Cependant, s’il s’agit d’un utilisateur de service / agent ... à bien y penser, c’est vraiment une question de style.

— aesnak