F20 - Unintended consequences of no default MTA - How best to fix

Fri Jan 3 23:17:43 UTC 2014

On Jan 3, 2014 4:12 PM, "Lars E. Pettersson" <lars at homer.se> wrote:
>
> On 01/03/2014 06:31 PM, Pete Travis wrote:
>>
>> On Jan 3, 2014 4:08 AM, "Lars E. Pettersson" <lars at homer.se
>> <mailto:lars at homer.se>> wrote:
>>  >
>>  > On 01/03/2014 05:07 AM, Pete Travis wrote:
>>  >>
>>  >> I think there was some misunderstanding here. If you can't find your
>>  >> cronjob output in the journal, *your* cron is broken.
>>  >
>>  >
>>  > Default installation:
>>  >
>>  > [root at tux ~]# rpm -V cronie
>>  > [root at tux ~]# rpm -q cronie
>>  > cronie-1.4.11-4.fc20.x86_64
>>  > [root at tux ~]# rpm -V crontabs
>>  > [root at tux ~]# rpm -q crontabs
>>  > crontabs-1.11-7.20130830git.fc20.noarch
>
>
> Pete, you did not answer this part. As seen cron is untouched, i.e. not
broken. I can not find any output from cron in the journal (you only see
the trigger part in the journal). So please, how do I read the output from
cron with journalctl?
>
>
>>  > Mail has no problem handling voluminous content. It is also very easy
>> to retrieve without knowing quite a lot of strange options to a command
>> that you have to print in a terminal.
>>  >
>>
>> Yes, we know you prefer mail... Mail on the command line is exactly what
>> you describe - it requires knowing esoteric command line options to an
>> awkward terminal application.  Two unfamiliar and clunky terminal
>> applications for the purpose would be redundant, so one is gone.
>
>
> What I prefer is not the discussion, the discussion is how to make sure
that information is not lost for a user of Fedora. In Fedora we have some
applications that do send mail. These mails will be lost on a system
without an MTA. That is not a good thing, and that is what the discussion
is about.
>
> Mail on command line was an example of the most simplistic way to read
mail. Most of us use full blow mail clients, I use Thunderbird, to read
mail. Thunderbird can read spool mail without a problem. And spool mail can
also easily be forwarded to gmail etc, if so wanted (as long as we have a
MTA). Mail is easy to understand and grasp for most users.
>
> The journalctl commands are way more esoteric than the mail command, and
beyond what most normal users can/want to comprehend. So what the journal
really need is a graphical frontend to help the non technically oriented
users. But that is probably better discussed in another thread.
>
>
>>  > Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1)
>>  > Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
>>  >
>>
>> I see " CMD (run-parts /etc/cron.hourly", that could be where the magic
>> happens.  Maybe the output will show up with other filters, or it could
>> be rewritten to use systemd-cat.
>
>
> What you see here is when cron is triggered. But I con not find any
information on how to read the output that these triggered cron jobs (may)
produce. How are those retrieved using journalctl? I have no clue, do you?
(Or any other?)
>
>
>>  > How is non technical user supposed to understand this? What command
>> sequence did you use to get that output?
>>  >
>>
>> A non-technical user would either understand by example - the part you
>> cut out - or, they are a nontechnical user and have no interest in such
>> things .
>
>
> As I said before, a non technically oriented user should not be (forced)
to use these esoteric commands to find information on how the system
behaves. It is good and dandy for us that like to understand the system,
but this has to be made way more easy to use, as I mentioned before.
>
> Compare receiving a mail of the output from a cron job, with the
journalctl commands you have shown. What do you think a non technically
oriented user will find most easy to understand?
>
>
>>  >> $ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b
>>  >
>>  >
>>  > How do you find out the _AUDIT_SESSION to use?
>>  >
>> I didn't guess. There was a straightforward and easy to follow example,
>> but you removed it.
>
>
> Yes, but that part was just put into your mail (I removed the middle
part), but were did it come from? How did you produce that output? Or, to
have a perhaps more useful question, how do I find out what _AUDIT_SESSION
is relevant for a certain log line?
>
>
>>  > How am I notified that I should look in the journal when things go
>> wrong? (With mail I am notified and also get the "log" lines all at once)
>>  >
>>
>> How is a nontechnical desktop user notified of new mail? That's
>> rhetorical, don't answer. They aren't .
>
>
> It shows up in their inbox.
>
> How is non technical user notified to look in the journal?
>
>
>> OK, then, your argument is late and pointless. Appeal to fesco if you
>> feel strongly about adding sendmail to the default installation, such
>> decisions are not made on the user support list.
>
>
> That does not stop us from discussing it. We now have a situation were
certain applications do produce mail, and without an MTA those mails will
be lost. That is not a good situation. This should have been taken care of
*before* removing the MTA, so that information from the system is not lost.
Why FESCO did not make sure of this is beyond me.
>
>
>>  > I have to as long as some applications use that path to send messages
>> to me. The same thing goes for all others installing these applications.
>> Without a MTA these messages are lost in bit space.
>>  >
>>  >
>>  > Lars
>>  > --
>>
>> More "I like using mail" ranting here. That's fine, use mail.  I just
>> wanted to point out how to use the journal, so I'm done here.
>
>
> It is not about liking mail (or not), please read the last paragraph
above (above Lars), that paragraph explains the situation.
>
> I also asked you if there exist a "journal for dummies" text where we can
find out how to become journal experts. The man page is a bit sparse on
information. Do such a text exist, if so were?
>
>
> Lars
> --

The debate on default policy is best left to my betters, but as I said
earlier today, I will write something about the journal and journalctl in
the near future.

--Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140103/f77f18c0/attachment.html>