Re: F20 System Wide Change: No Default Sendmail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Monday 22 July 2013 20:33:32 Lennart Poettering wrote:
> On Sun, 21.07.13 01:50, Oron Peled (oron@xxxxxxxxxxxx) wrote:
> > OK, I won't count mailx and mutt because we talk about different audience,
> > should we open bug-reports for the rest? (kmail? evolution?)
> 
> Goog luck filing bugs against Thunderbird, GMail and Zimbra to add
> support for local mail queue reading...

Hmmm... I didn't know any of them was installed by *default*.
After all, the issue is *default* setup, isn't it?

[bit-off-topic: unlike the others you mentioned, Thunderbird is a local MUA.
 Not being able to process any local mailbox (mbox/maildir/whatever)
 was the primary reason I never used it -- I cannot afford loosing
 almost 20 years of email history, much less convert it to some HTML
 based private format]

> > Cron was already mentioned, but every one seem to ignore the fact that
> > regular users don't have permission to read system logs.
> 
> journald actually splits out user logs and use filesystem ACLs to ensure
> that the user gets read access to his own logs. This doesn't work for
> syslog (and also not if cron first collects all logs and then logs them
> as root).

[thanks for referring to this issue. In a separate sub-thread I complained
 about not being addressed before seeing this mail]

There are two issues however:
 * The log-splitting of journald is really nice feature. But it doesn't
   work for cron:
        $ echo '* * * * * /bin/echo "Test output from cron"' | \
             crontab '-'    # than wait a minute
        $ journalctl        # only shows crontab, not the cron output
        $ su -
        # journalctl        # Cron output is properly shown.

   So this issue is still outstanding (but I'll bet you knew that)

 * Logs are inherently line-oriented (which is very good for their
   intended use case). However, many cron-jobs produce various reports
   which are multi-line in their nature -- not a very good fit.

IMO a reasonable path may be:
 * Not installing MTA at all for the *minimal* case.

 * Install MTA for the default case (especially desktops).

 * In that case, no SMTP port listening is needed. The default use
   case is about the ability to deliver messages by piping them
   to the MTA. No application/tool that I know of, tries to notify
   by sending to STMP on localhost (am I wrong here?)

 * Automatic mail-alias of root to the installing user will go a long
   way to make it more visible/useful.

 * Adding local mailbox as default configuration of MUA's (at least
   those installed by default for desktops) is even better.

Bye,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron@xxxxxxxxxxxx                  http://users.actcom.co.il/~oron
Linux:  If you're not careful, you might actually learn something.
                -- Allen Wong

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux