Le Lun 22 juillet 2013 19:28, Matthew Miller a écrit :
> On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote:
>> What makes cron and smtpd work well together is that they both perform
>> async background computing. And many cron messages are not "logs"
>> they're
>> notifications of an event the cron is polling for, or submission of job
>> results.
>
> Honest, non-loaded question here. Do you really find them default cron
> output mode helpful?
I think sending all cron output by email is useful, in the sense that it
pushes errors for the user to fix instead of failing silently (or with
another line in the system logs no one will read since they're swamped by
gdm, networkmanager and a few other chatty system services). I do not
think cron jobs that output something every time they are run just in case
are nice.
I do not think the way we let systems install without a configured smtp
backend is good. If cron mails were actually pushed by default the bad
crons would be fixed before doing any real damage. A lot of the problems
people complain of here are the direct product of not configuring the smtp
backend a install time for years.
I do not think the default cron message envelope is any good. It does not
make enough effort to identify the system and cron job which is failing,
and is not localized.
I do think neither the transient GNOME notifications, nor burying events
in logs only root can consult are appropriate except for the most routine
and uninteresting events.
I do not think that for regular output (ie job results, intended
notifications not script crashes) direct cron to smtpd is ideal. The best
path should be
app/cron/script → backend notification center (evaluation of all system
notifications, standard formatting, localization, triaging)
→ (routing)
→ consumer (DE notification center, logs, specialized
apps, human in MUA)
with in many cases routing = smtpd → imap box → remote consumer. There can
be different imap boxes for each human user of the system, for the
operator of the system (operator can be it-knowledgeable nephew,
it-slave-boyfriend, helpdesk or central monitoring/alert system). Some of
them can be consulted via the DE notification GUI, not necessarily by a
MUA (just requires defining how you serialize notifications in mail
attachment, and teaching the notification center to read an imap box and
remove each message when the user confirms he's done with it, and leave it
in the remote mailbox for future processing otherwise)
A lot of notifications do not require immediate action. What they do
require is some action in the future. For those I do want them to hang out
on an imap server till I take care of them, and I definitely do not want
to be only able to see them when I log in on the exact system they
originated from, or only at the notification time.
I do think the only widely deployed vendor-agnostic remote messaging
infrastructure is the mail infrastructure. All the other solutions require
always-on receiving nodes, that end-users can not afford.
I do think the notification infrastructure needs to be able to handle the
results produced by user crontabs, and the entry points need to be simple
enough the crontab user does not have to think about them.
I do think the basic app (something) smtp architecture is sound, even if
it does need some refreshing and formatting cleanup. I do think that
commodisation will result in multiple computing nodes in every home, and
that being able to push notifications to a machine-agnostic store will
prove just as compelling end-user-side as it was in university campuses
when cron was first wed with sendmail.
--
Nicolas Mailhot
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
