Pourquoi cron nécessite-t-il un MTA pour la journalisation?


11

Pourquoi cron nécessite-t-il un MTA pour la journalisation? Y a-t-il un avantage particulier à cela? Pourquoi ne peut-il pas créer un fichier journal comme la plupart des autres utilitaires?


Un peu compliqué, mais je suis sûr que cron n'a pas besoin d'un MTA; à moins que vous expédiiez des courriers cron à un autre hôte, tout ce dont il aurait besoin est un MDA ( agent de distribution du courrier ).
un CVn

Réponses:


19

Considérez que la manière traditionnelle "standard" de consigner les données est syslog , où les métadonnées incluses dans les messages sont le "code d'installation" et le niveau de priorité. Le code d'installation peut être utilisé pour séparer les flux de journaux de différents services afin qu'ils puissent être divisés en différents fichiers journaux, etc. (même si les codes d'installation sont quelque peu limités en ce sens qu'ils ont des significations traditionnelles fixes.)

Ce que Syslog n'a pas, c'est un moyen de séparer les messages pour ou à partir d'utilisateurs différents, et c'est quelque chose qui a cronbesoin sur un système multi-utilisateur traditionnel. Il est inutile de collecter les messages des tâches cron de tous les utilisateurs dans un fichier journal commun où seul l'administrateur système peut les voir. D'un autre côté, le courrier électronique permet naturellement d'envoyer des messages à différents utilisateurs, c'est donc un choix logique ici. L'alternative serait que cron fasse le travail manuellement et crée des fichiers journaux dans le répertoire personnel de chaque utilisateur, mais un système Unix traditionnel multi-utilisateurs serait supposé avoir un MTA fonctionnel, donc l'implémenter dans cron aurait été principalement un exercice futile.

Sur les systèmes modernes, il pourrait bien sûr y avoir des choix alternatifs.


13

Je suppose que par «journalisation», vous entendez le stockage de la sortie réelle des travaux. L' exécution des travaux est déjà enregistrée dans la connexion cron /var/cron/log(le chemin peut différer d'un système à l'autre). Aucun MTA n'est requis pour ce journal.

Un travail cron est exécuté en tant qu'utilisateur dont le travail crontab fait partie.

Dans le cas général, il n'y a aucune garantie que cet utilisateur est capable de créer des fichiers sur le système (un utilisateur peut ne pas être un utilisateur interactif), en particulier pas sous la /varhiérarchie où les journaux sont généralement créés. Le moyen le plus sûr de signaler à l'utilisateur des erreurs et autres sorties d'un travail est donc de les collecter et de les envoyer par e-mail à l'utilisateur. Cela permettrait également à l'utilisateur de configurer la redirection des e-mails pour que le compte puisse voir, par exemple, des erreurs dans leur emplacement préféré.

Si l'utilisateur souhaite enregistrer la sortie d'un travail dans un fichier, il peut le faire avec une simple redirection dans la crontab:

0 */2 * * * "$HOME/scripts/myscript" >"$HOME/logs/myscript.log" 2>&1

Cela s'exécuterait "$HOME/scripts/myscript"toutes les deux heures, à l'heure, et enregistrerait toutes les sorties dans "$HOME/logs/myscript.log". Aucun e-mail ne serait créé en exécutant ce travail car toutes les sorties sont redirigées. Sans cela 2>&1, les messages d'erreur seraient toujours envoyés par e-mail.

Cela permet à l'utilisateur de choisir où va la sortie.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.