F20 System Wide Change: No Default Sendmail

[Jaroslav Reznik]

= Proposed System Wide Change: No Default Sendmail =
https://fedoraproject.org/wiki/Changes/NoDefaultSendmail

Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew 
Miller <mattdm at fedoraproject org>

No longer install an MTA by default. (Specifically let's remove sendmail from 
@core and @standard comps groups.)

== Detailed description ==
Let's change the default install to no longer install an MTA by default. 
Specifically, let's remove sendmail from the @standard and @core group.

On today's Internet most SMTP hosts do not accept mail from a server which is 
not configured as a mail exchange for a real domain, hence the default 
configuration of sendmail is seldom useful. Even if the server is not tied to a 
real mail domain, it can be configured to authenticate as a user on the target 
server, but again, this requires explicit configuration on both ends and is 
fairly awkward. Something that doesn't work without manual configuration should 
not be in the default install.

Most MUAs we ship (especially those we install by default) do not deliver to a 
local MTA anyway but rather include an SMTP client. Usually, they will not 
pick up mail delivered to local users. This means that unless the user knows 
about local mail and takes steps to receive local mail addressed to root, such 
messages are likely to be ignored.

On top of that, sendmail has always been a quite surprising choice for an MTA, 
as most administrators tend to prefer mail systems such as Postfix or Exim 
these days, and Sendmail appears to be quite arcane to most.

Administrators should install the MTA of their choice after installation (or 
via kickstart) and sendmail should not be the default anymore.

Many other distributions do not install an MTA by default anymore, and so 
should we. Running systems without MTA is already widely tested.

The various tools (such as cron) which previously required a local MTA for 
operation have been updated already to deliver their job output to syslog 
rather than sendmail, which is a good default.

Also see the previous attempt: 
https://fedoraproject.org/wiki/Features/NoDefaultMTA 

== Scope ==
Simply remove "sendmail" from all default install groups in "comps".

Packages which strictly require a MTA to run might need updating to gain 
dependencies on "server(smtp)" (but they needed that before too, so this is 
mostly just bugfixing that's useful anyway). If any of the packages in the 
default install is one of those, we need to look at it in detail, and find a 
solution. However, currently no package of the default install is requiring an 
MTA.

Proposal owners: Commit a change to "comps" to remove "sendmail" from
it. 

Other developers: logwatch/logcheck might need updating to not require an MTA 
for delivering log changes. Some packages might need a dependency on 
"server(smtp)" added. 

Release engineering: nothing really. 

Policies and guidelines: nothing really. Maybe the guidelines should clarify 
that /usr/bin/sendmail doesn't exist on many systems, but that was already the 
case before -- so little changes.  
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Florian Weimer]

>  The various tools (such as cron) which previously required a local
> MTA for
>  operation have been updated already to deliver their job output to syslog
>  rather than sendmail, which is a good default. 
syslog or the journal?  Wouldn't the journal make more sense because of 
spoof protection and and the amount of the data that cron can write?

-- 
Florian Weimer / Red Hat Product Security Team

[Lennart Poettering]

On Mon, 15.07.13 10:52, Florian Weimer (fweimer(a)redhat.com) wrote:

>  >The various tools (such as cron) which previously required a
> local MTA for
>  >operation have been updated already to deliver their job output to syslog
>  >rather than sendmail, which is a good default.
>  
>  syslog or the journal?  Wouldn't the journal make more sense because
>  of spoof protection and and the amount of the data that cron can
>  write? 
Whatever is written to syslog these days ends up in the journal first
and is then forwarded to a syslog implementation that might be running.

So you do get the spoof protection this way.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Sérgio Basto]

On Seg, 2013-07-15 at 10:36 +0200, Jaroslav Reznik wrote: 
>  = Proposed System Wide Change: No Default Sendmail =
>  https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
>  
>  Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew 
>  Miller <mattdm at fedoraproject org>
>  
>  No longer install an MTA by default. (Specifically let's remove sendmail from 
>  @core and @standard comps groups.)
>  
>  == Detailed description ==
>  Let's change the default install to no longer install an MTA by default. 
>  Specifically, let's remove sendmail from the @standard and @core group.
>  
>  On today's Internet most SMTP hosts do not accept mail from a server which is 
>  not configured as a mail exchange for a real domain, hence the default 
>  configuration of sendmail is seldom useful. Even if the server is not tied to a 
>  real mail domain, it can be configured to authenticate as a user on the target 
>  server, but again, this requires explicit configuration on both ends and is 
>  fairly awkward. Something that doesn't work without manual configuration should 
>  not be in the default install.
>  
>  Most MUAs we ship (especially those we install by default) do not deliver to a 
>  local MTA anyway but rather include an SMTP client. Usually, they will not 
>  pick up mail delivered to local users. This means that unless the user knows 
>  about local mail and takes steps to receive local mail addressed to root, such 
>  messages are likely to be ignored.
>  
>  On top of that, sendmail has always been a quite surprising choice for an MTA, 
>  as most administrators tend to prefer mail systems such as Postfix or Exim 
>  these days, and Sendmail appears to be quite arcane to most.
>  
>  Administrators should install the MTA of their choice after installation (or 
>  via kickstart) and sendmail should not be the default anymore.
>  
>  Many other distributions do not install an MTA by default anymore, and so 
>  should we. Running systems without MTA is already widely tested.
>  
>  The various tools (such as cron) which previously required a local MTA for 
>  operation have been updated already to deliver their job output to syslog 
>  rather than sendmail, which is a good default.
>  
>  Also see the previous attempt: 
>  https://fedoraproject.org/wiki/Features/NoDefaultMTA 
>  
>  == Scope ==
>  Simply remove "sendmail" from all default install groups in "comps".
>  
>  Packages which strictly require a MTA to run might need updating to gain 
>  dependencies on "server(smtp)" (but they needed that before too, so this is 
>  mostly just bugfixing that's useful anyway). If any of the packages in the 
>  default install is one of those, we need to look at it in detail, and find a 
>  solution. However, currently no package of the default install is requiring an 
>  MTA.
>  
>  Proposal owners: Commit a change to "comps" to remove "sendmail" from
> it. 
>  
>  Other developers: logwatch/logcheck might need updating to not require an MTA 
>  for delivering log changes. Some packages might need a dependency on 
>  "server(smtp)" added.  
I'd like understand how cronjobs deliver his emails , to root user ? 


>  Release engineering: nothing really. 
>  
>  Policies and guidelines: nothing really. Maybe the guidelines should clarify 
>  that /usr/bin/sendmail doesn't exist on many systems, but that was already the 
>  case before -- so little changes.  
>  _______________________________________________
>  devel-announce mailing list
>  devel-announce(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel-announce 
-- 
Sérgio M. B.

[Peter Robinson]

On Mon, Jul 15, 2013 at 2:45 PM, Sérgio Basto <sergio(a)serjux.com&gt; wrote:
>  On Seg, 2013-07-15 at 10:36 +0200, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: No Default Sendmail =
> > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
> >
> > Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
> > Miller <mattdm at fedoraproject org>
> >
> > No longer install an MTA by default. (Specifically let's remove sendmail from
> > @core and @standard comps groups.)
> >
> > == Detailed description ==
> > Let's change the default install to no longer install an MTA by default.
> > Specifically, let's remove sendmail from the @standard and @core group.
> >
> > On today's Internet most SMTP hosts do not accept mail from a server which is
> > not configured as a mail exchange for a real domain, hence the default
> > configuration of sendmail is seldom useful. Even if the server is not tied to a
> > real mail domain, it can be configured to authenticate as a user on the target
> > server, but again, this requires explicit configuration on both ends and is
> > fairly awkward. Something that doesn't work without manual configuration should
> > not be in the default install.
> >
> > Most MUAs we ship (especially those we install by default) do not deliver to a
> > local MTA anyway but rather include an SMTP client. Usually, they will not
> > pick up mail delivered to local users. This means that unless the user knows
> > about local mail and takes steps to receive local mail addressed to root, such
> > messages are likely to be ignored.
> >
> > On top of that, sendmail has always been a quite surprising choice for an MTA,
> > as most administrators tend to prefer mail systems such as Postfix or Exim
> > these days, and Sendmail appears to be quite arcane to most.
> >
> > Administrators should install the MTA of their choice after installation (or
> > via kickstart) and sendmail should not be the default anymore.
> >
> > Many other distributions do not install an MTA by default anymore, and so
> > should we. Running systems without MTA is already widely tested.
> >
> > The various tools (such as cron) which previously required a local MTA for
> > operation have been updated already to deliver their job output to syslog
> > rather than sendmail, which is a good default.
> >
> > Also see the previous attempt:
> > https://fedoraproject.org/wiki/Features/NoDefaultMTA
> >
> > == Scope ==
> > Simply remove "sendmail" from all default install groups in
> "comps".
> >
> > Packages which strictly require a MTA to run might need updating to gain
> > dependencies on "server(smtp)" (but they needed that before too, so this
> is
> > mostly just bugfixing that's useful anyway). If any of the packages in the
> > default install is one of those, we need to look at it in detail, and find a
> > solution. However, currently no package of the default install is requiring an
> > MTA.
> >
> > Proposal owners: Commit a change to "comps" to remove "sendmail"
> from it.
> >
> > Other developers: logwatch/logcheck might need updating to not require an MTA
> > for delivering log changes. Some packages might need a dependency on
> > "server(smtp)" added.
>
>  I'd like understand how cronjobs deliver his emails , to root user ? 

By default the mail is sent to the local user and that will be with
the local MDA which is procmail (even used by sendmail) and I don't
believe that's being removed as part of this.

Peter

[Lennart Poettering]

On Mon, 15.07.13 15:05, Peter Robinson (pbrobinson(a)gmail.com) wrote:

>  >> Proposal owners: Commit a change to "comps" to
> remove "sendmail" from it.
>  >>
>  >> Other developers: logwatch/logcheck might need updating to not require an MTA
>  >> for delivering log changes. Some packages might need a dependency on
>  >> "server(smtp)" added.
>  >
>  > I'd like understand how cronjobs deliver his emails , to root user ?
>  
>  By default the mail is sent to the local user and that will be with
>  the local MDA which is procmail (even used by sendmail) and I don't
>  believe that's being removed as part of this. 
Humm, no. MDAs are invoked by the local MTA. If you have no local MTA,
then the local MDA is never invoked.

This feature is about not doign local mail delivery by default, by not
installing any MTA. Instead you find the log output of cronjobs at the
same place as you find any other log output, the journal/syslog, for
example accessible via:

journalctl -u crond

or

systemctl status crond

(the latter will only show you 10 log lines by default, the former all
of them. You can pass "-n 100" to either to see the 100 latest ones)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Till Maas]

On Mon, Jul 15, 2013 at 04:14:35PM +0200, Lennart Poettering wrote:

>  This feature is about not doign local mail delivery by default, by
> not
>  installing any MTA. Instead you find the log output of cronjobs at the
>  same place as you find any other log output, the journal/syslog, for
>  example accessible via:
>  
>  journalctl -u crond 
But the information cron sends via email is usually more important than
the regular log entries, because output in cron jobs usually means there
is an error. It seems wrong to store the important data hidden among
less important data.

Regards
Till

[Eric Smith]

On Mon, Jul 15, 2013 at 3:14 PM, Till Maas <opensource(a)till.name&gt; wrote:
>  But the information cron sends via email is usually more important
> than
>  the regular log entries, because output in cron jobs usually means there
>  is an error. It seems wrong to store the important data hidden among
>  less important data. 
Then the syslog severities are configured wrong.  That's not a good
justification for using email rather than syslog.

Eric

[Robert Nichols]

On 07/15/2013 04:17 PM, Eric Smith wrote:
>  On Mon, Jul 15, 2013 at 3:14 PM, Till Maas
> <opensource(a)till.name&gt; wrote:
> > But the information cron sends via email is usually more important than
> > the regular log entries, because output in cron jobs usually means there
> > is an error. It seems wrong to store the important data hidden among
> > less important data.
>
>  Then the syslog severities are configured wrong.  That's not a good
>  justification for using email rather than syslog. 
So, all users on a multi-user system are now expected to dig through
syslog output to see the output from their cron jobs?

And of course, syslog output will now be stored somewhere that is, by
default, world readable, right?

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Eric Smith]

On Mon, Jul 15, 2013 at 3:31 PM, Robert Nichols
<rnicholsNOSPAM(a)comcast.net&gt; wrote:
>  So, all users on a multi-user system are now expected to dig through
>  syslog output to see the output from their cron jobs? 
A fair point, but in my experience the most common case is a
single-user system where the user doesn't even use cron.  I'm not sure
whether that's most common in general, but if it is, I think it's
acceptable to have installing an MTA as a manual step on a multiuser
system where there are user cron jobs.

Having the MTA installed by default on end-user systems I administer
has always been problematic, which is why I always remove it.  The
users I've supported have never gained any benefit from having a local
MTA, and normally their MUA points to a remote IMAP server, so they
wouldn't ever see local email.

Eric

[Matthew Miller]

On Mon, Jul 15, 2013 at 04:31:38PM -0500, Robert Nichols wrote:
>  So, all users on a multi-user system are now expected to dig through
>  syslog output to see the output from their cron jobs? 
What? No. If you have a traditional multiuser system you probably want to
install and configure an MTA. Note that this feature is no _default_
sendmail, not "die all MTAs die".


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Lennart Poettering]

On Mon, 15.07.13 23:14, Till Maas (opensource(a)till.name) wrote:

>  On Mon, Jul 15, 2013 at 04:14:35PM +0200, Lennart Poettering wrote:
>  
>  > This feature is about not doign local mail delivery by default, by not
>  > installing any MTA. Instead you find the log output of cronjobs at the
>  > same place as you find any other log output, the journal/syslog, for
>  > example accessible via:
>  > 
>  > journalctl -u crond
>  
>  But the information cron sends via email is usually more important than
>  the regular log entries, because output in cron jobs usually means there
>  is an error. It seems wrong to store the important data hidden among
>  less important data. 
journalctl helps you with that too:

"journalctl -p notice" will output all messages of log level "notice"
and higher, which is the stuff that matters, and what you really should
look at. And even if you do not pass this to journalctl you will get the
important lines highlighted bold and the really important ones red, so
it should be really easy to find the output that matters.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Robert Nichols]

On 07/15/2013 09:14 AM, Lennart Poettering wrote:
>  This feature is about not doign local mail delivery by default, by
> not
>  installing any MTA. Instead you find the log output of cronjobs at the
>  same place as you find any other log output, the journal/syslog, for
>  example accessible via:
>
>  journalctl -u crond
>
>  or
>
>  systemctl status crond
>
>  (the latter will only show you 10 log lines by default, the former all
>  of them. You can pass "-n 100" to either to see the 100 latest ones) 
You are thinking only about error output from cron jobs.  Regular
output from cron jobs can be quite voluminous. Is it reasonable to send
15 to 20 Kilobytes to the journal (root's logwatch job currently sends
that much every day)? How about a couple of JPGs (graphs of resource
usage)?

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Matthew Miller]

On Sat, Jul 20, 2013 at 09:00:36AM -0500, Robert Nichols wrote:
>  You are thinking only about error output from cron jobs.  Regular
>  output from cron jobs can be quite voluminous. Is it reasonable to send
>  15 to 20 Kilobytes to the journal (root's logwatch job currently sends
>  that much every day)? How about a couple of JPGs (graphs of resource
>  usage)? 
Sending logwatch to the log seems a little bit.. circular. But in any case,
logwatch does not use the "dump to stdout and hope it goes somewhere"
approach -- it actually uses e-mail directly. So, logwatch should have a
requirement on an MTA.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Lennart Poettering]

On Sat, 20.07.13 09:00, Robert Nichols (rnicholsNOSPAM(a)comcast.net) wrote:

>  On 07/15/2013 09:14 AM, Lennart Poettering wrote:
>  >This feature is about not doign local mail delivery by default, by not
>  >installing any MTA. Instead you find the log output of cronjobs at the
>  >same place as you find any other log output, the journal/syslog, for
>  >example accessible via:
>  >
>  >journalctl -u crond
>  >
>  >or
>  >
>  >systemctl status crond
>  >
>  >(the latter will only show you 10 log lines by default, the former all
>  >of them. You can pass "-n 100" to either to see the 100 latest ones)
>  
>  You are thinking only about error output from cron jobs.  Regular
>  output from cron jobs can be quite voluminous. Is it reasonable to send
>  15 to 20 Kilobytes to the journal (root's logwatch job currently sends
>  that much every day)? How about a couple of JPGs (graphs of resource
>  usage)? 
The journal supports 2^64 sized binary objects to be stored in it. It
currently will get a bit slow if you actually send a lot of data sind it
first needs to XZ compress the blobs before writing them to disk and
that will stall operation for that time, but a few 100K (or even MB) in
a single message should be no problem.

(Note that the way cron's mail support works you cannot use it directly
to send JPEGs...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Lennart Poettering]

On Mon, 15.07.13 14:45, Sérgio Basto (sergio(a)serjux.com) wrote:

>  > Other developers: logwatch/logcheck might need updating to not
> require an MTA 
>  > for delivering log changes. Some packages might need a dependency on 
>  > "server(smtp)" added. 
>  
>  I'd like understand how cronjobs deliver his emails , to root user ?  
Not sure I grok the question. But the logic is:

If an MTA is installed then the output of cronjobs is sent to the local
user that owns the cron job in question. If no MTA is installed (which
we want to make the default with this feature) the output is written to
syslog instead (which means it ends up in the journal and you can view
it with "journalctl -u crond").

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Marcela Mašláňová]

On 07/15/2013 03:45 PM, Sérgio Basto wrote:
>  On Seg, 2013-07-15 at 10:36 +0200, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: No Default Sendmail =
> > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
> >
> > Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
> > Miller <mattdm at fedoraproject org>
> >
> > No longer install an MTA by default. (Specifically let's remove sendmail from
> > @core and @standard comps groups.)
> >
> > == Detailed description ==
> > Let's change the default install to no longer install an MTA by default.
> > Specifically, let's remove sendmail from the @standard and @core group.
> >
> > On today's Internet most SMTP hosts do not accept mail from a server which is
> > not configured as a mail exchange for a real domain, hence the default
> > configuration of sendmail is seldom useful. Even if the server is not tied to a
> > real mail domain, it can be configured to authenticate as a user on the target
> > server, but again, this requires explicit configuration on both ends and is
> > fairly awkward. Something that doesn't work without manual configuration should
> > not be in the default install.
> >
> > Most MUAs we ship (especially those we install by default) do not deliver to a
> > local MTA anyway but rather include an SMTP client. Usually, they will not
> > pick up mail delivered to local users. This means that unless the user knows
> > about local mail and takes steps to receive local mail addressed to root, such
> > messages are likely to be ignored.
> >
> > On top of that, sendmail has always been a quite surprising choice for an MTA,
> > as most administrators tend to prefer mail systems such as Postfix or Exim
> > these days, and Sendmail appears to be quite arcane to most.
> >
> > Administrators should install the MTA of their choice after installation (or
> > via kickstart) and sendmail should not be the default anymore.
> >
> > Many other distributions do not install an MTA by default anymore, and so
> > should we. Running systems without MTA is already widely tested.
> >
> > The various tools (such as cron) which previously required a local MTA for
> > operation have been updated already to deliver their job output to syslog
> > rather than sendmail, which is a good default.
> >
> > Also see the previous attempt:
> > https://fedoraproject.org/wiki/Features/NoDefaultMTA
> >
> > == Scope ==
> > Simply remove "sendmail" from all default install groups in
> "comps".
> >
> > Packages which strictly require a MTA to run might need updating to gain
> > dependencies on "server(smtp)" (but they needed that before too, so this
> is
> > mostly just bugfixing that's useful anyway). If any of the packages in the
> > default install is one of those, we need to look at it in detail, and find a
> > solution. However, currently no package of the default install is requiring an
> > MTA.
> >
> > Proposal owners: Commit a change to "comps" to remove "sendmail"
> from it.
> >
> > Other developers: logwatch/logcheck might need updating to not require an MTA
> > for delivering log changes. Some packages might need a dependency on
> > "server(smtp)" added.
>
>  I'd like understand how cronjobs deliver his emails , to root user ?
>
>
> > Release engineering: nothing really.
> >
> > Policies and guidelines: nothing really. Maybe the guidelines should clarify
> > that /usr/bin/sendmail doesn't exist on many systems, but that was already the
> > case before -- so little changes.
> > _______________________________________________
> > devel-announce mailing list
> > devel-announce(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel-announce
>  
As a part of cronie upstream I should probably answer. Cron was patched 
long time ago to log into syslog if mail can't be send. There is also 
option for using syslog by default.

Marcela

[Jóhann B. Guðmundsson]

On 07/23/2013 10:18 AM, Marcela Mašláňová wrote:
> >
>  As a part of cronie upstream I should probably answer. Cron was 
>  patched long time ago to log into syslog if mail can't be send. There 
>  is also option for using syslog by default. 
Should we change cron to be using syslog by default if this feature gets 
approved?

JBG

[Marcela Mašláňová]

On 07/24/2013 01:11 PM, "Jóhann B. Guðmundsson" wrote:
>  On 07/23/2013 10:18 AM, Marcela Mašláňová wrote:
> >>
> > As a part of cronie upstream I should probably answer. Cron was
> > patched long time ago to log into syslog if mail can't be send. There
> > is also option for using syslog by default.
>
>  Should we change cron to be using syslog by default if this feature gets
>  approved?
>
>  JBG 
Why? If you don't have MTA, it doesn't try to send email. I won't plan 
change anything.

Marcela

[Matthew Miller]

On Wed, Jul 24, 2013 at 02:09:53PM +0200, Marcela Mašláňová wrote:
>  >Should we change cron to be using syslog by default if this
> feature gets
>  >approved?
>  Why? If you don't have MTA, it doesn't try to send email. I won't
>  plan change anything. 
It might be nice for it to be able to do both.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Sérgio Basto]

On Seg, 2013-07-15 at 10:36 +0200, Jaroslav Reznik wrote:
>  Most MUAs we ship (especially those we install by default) do not
>  deliver to a 
>  local MTA anyway but rather include an SMTP client. Usually, they will
>  not 
>  pick up mail delivered to local users. This means that unless the user
>  knows 
>  about local mail and takes steps to receive local mail addressed to
>  root, such 
>  messages are likely to be ignored. 

>  On top of that, sendmail has always been a quite surprising choice
> for
>  an MTA,  
not for me , my choice is qmail (which now is FOSS)  

>  as most administrators tend to prefer mail systems such as Postfix
> or
>  Exim 
>  these days, and Sendmail appears to be quite arcane to most.
>   
not for me,  

>  Administrators should install the MTA of their choice after
>  installation (or 
>  via kickstart) and sendmail should not be the default anymore. 
and what is the benefit ?

I also don't agree with state: many distros already change or don't have
any. Debian change to exmin , which, in my opinion, is a much worse
choice. 

Sendmail rocks since 90s :) 

Sorry for my weak English , I don't write well even in my own language. 

-- 
Sérgio M. B.

[Matthew Miller]

On Mon, Jul 15, 2013 at 03:59:02PM +0100, Sérgio Basto wrote:
>  not for me , my choice is qmail (which now is FOSS)   
...
>  > Administrators should install the MTA of their choice after
>  > installation (or 
>  > via kickstart) and sendmail should not be the default anymore.
>  and what is the benefit ? 
So, with this change, you don't have to remove sendmail first. That's not a
huge benefit, but there you go. :)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Sérgio Basto]

On Seg, 2013-07-15 at 12:11 -0400, Matthew Miller wrote: 
>  On Mon, Jul 15, 2013 at 03:59:02PM +0100, Sérgio Basto wrote:
>  > not for me , my choice is qmail (which now is FOSS)  
>  ...
>  > > Administrators should install the MTA of their choice after
>  > > installation (or 
>  > > via kickstart) and sendmail should not be the default anymore.
>  > and what is the benefit ?
>  
>  So, with this change, you don't have to remove sendmail first. That's not a
>  huge benefit, but there you go. :) 
In others words , NONE ! 


-- 
Sérgio M. B.

[Rahul Sundaram]

Hi


On Mon, Jul 15, 2013 at 2:11 PM, Sérgio Basto wrote:

>  On Seg, 2013-07-15 at 12:11 -0400, Matthew Miller wrote:
>
>  > So, with this change, you don't have to remove sendmail first. That's
>  not a
>  > huge benefit, but there you go. :)
>
>  In others words , NONE !
>  
Not true.  Sendmail by default isn't something that is useful for Fedora
users in general and those who need a MTA can install it later.   Less
resource usage, less disk space wasted (yes, this does matter for various
users still including but not limited to cloud and minimal servers) and
users wouldn't have to deal with long term sendmail issues like severe
bootup delay to a minor network misconfiguration

[Sérgio Basto]

On Seg, 2013-07-15 at 14:17 -0400, Rahul Sundaram wrote: 
>  Hi
>  
>  
>  On Mon, Jul 15, 2013 at 2:11 PM, Sérgio Basto wrote:
>          On Seg, 2013-07-15 at 12:11 -0400, Matthew Miller wrote:
>          
>          > So, with this change, you don't have to remove sendmail
>          first. That's not a
>          > huge benefit, but there you go. :)
>          
>          
>          In others words , NONE ! 
>  
>  Not true.  Sendmail by default isn't something that is useful for
>  Fedora users in general and those who need a MTA can install it
>  later.   
Is useful to deliver mails send by cronjobs , as discussed in others
emails of this thread and or we have a good replace for cronjobs ,
logwatch etc , or I not agree with remove sendmail of defaults. 

>  Less resource usage, less disk space wasted (yes, this does matter
> for
>  various users still including but not limited to cloud and minimal
>  servers)  
Like many others things , I don't think is a valid argument. 

>  and  users wouldn't have to deal with long term sendmail issues
> like
>  severe bootup delay to a minor network misconfiguration 
>   
As you state when we have network misconfiguration , so at least is
useful to detect this problem ;-) 
Best regards, 
-- 
Sérgio M. B.

[Rahul Sundaram]

Hi


On Mon, Jul 15, 2013 at 3:47 PM, Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  On Seg, 2013-07-15 at 14:17 -0400, Rahul Sundaram wrote:
>
>  Is useful to deliver mails send by cronjobs , as discussed in others
>  emails of this thread and or we have a good replace for cronjobs
>  
This has already been answered.  Logging to syslog is a far more usable
default than mails to root where no default mail client is reading them.



>  > Less resource usage, less disk space wasted (yes, this does
> matter for
>  > various users still including but not limited to cloud and minimal
>  > servers)
>  Like many others things , I don't think is a valid argument.
>  
Why not?  You have offered no counter point.


>  > and  users wouldn't have to deal with long term sendmail issues like
>  > severe bootup delay to a minor network misconfiguration
>  >
>  As you state when we have network misconfiguration , so at least is
>  useful to detect this problem ;-)
>  
Unreasonably slowing down boot is hardly the right way to detect it.

Rahul

[Matthew Miller]

On Mon, Jul 15, 2013 at 07:11:15PM +0100, Sérgio Basto wrote:
>  > > > Administrators should install the MTA of their choice
> after
>  > > > installation (or 
>  > > > via kickstart) and sendmail should not be the default anymore.
>  > > and what is the benefit ?
>  > So, with this change, you don't have to remove sendmail first. That's not a
>  > huge benefit, but there you go. :)
>  In others words , NONE !  
A small benefit to _you_ and your use case, with no downside, and a large
benefit to other cases. I'm not seeing this as a capital-letter negative
situation.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[DJ Delorie]

I worry about the security implications of mail that would have gone
to root@ being either silently discarded or unknowingly ignored.

If there is no other way to send mail to local users, we should have a
local MTA configured for such.

[Lennart Poettering]

On Mon, 15.07.13 13:50, DJ Delorie (dj(a)redhat.com) wrote:

>  
>  I worry about the security implications of mail that would have gone
>  to root@ being either silently discarded or unknowingly ignored.
>  
>  If there is no other way to send mail to local users, we should have a
>  local MTA configured for such. 
Well, we don't even install any MUA by default currently that would read
local mail spools. Effectively, this means that currently the log output
of cronjobs is more or less lost. By ensuring all logs go to the normal
log stream there's a much better chance of not losing messages...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Lars E. Pettersson]

On 07/15/2013 07:54 PM, Lennart Poettering wrote:
>  Well, we don't even install any MUA by default currently that
> would read
>  local mail spools.  Effectively, this means that currently the log output
>  of cronjobs is more or less lost. 
A user normally installs a MUA of their choice as one of the first 
things they do, so that a MUA is not installed by default should not be 
an issue. I.e. the output is not lost.

>  By ensuring all logs go to the normal
>  log stream there's a much better chance of not losing messages... 
The problem is that this data can be quite voluminous. Perhaps a bad 
thing to clog up the logs with that?

Lars
-- 
Lars E. Pettersson <lars(a)homer.se&gt;
http://www.sm6rpz.se/

[Lennart Poettering]

On Sat, 20.07.13 18:05, Lars E. Pettersson (lars(a)homer.se) wrote:

>  On 07/15/2013 07:54 PM, Lennart Poettering wrote:
>  >Well, we don't even install any MUA by default currently that would read
>  >local mail spools.  Effectively, this means that currently the log output
>  >of cronjobs is more or less lost.
>  
>  A user normally installs a MUA of their choice as one of the first
>  things they do, so that a MUA is not installed by default should not
>  be an issue. I.e. the output is not lost. 
Well, assuming people use the local machine for reading their mails, and
not Thunderbird or so and not GMail and so on, or Zimbra or whatever
else people actually read mails with these days... None of these even do
local message reading.

>  >By ensuring all logs go to the normal
>  >log stream there's a much better chance of not losing messages...
>  
>  The problem is that this data can be quite voluminous. Perhaps a bad
>  thing to clog up the logs with that? 
Emails due to base64 encoding usually increase everything by 4/3, which
is certainly worse.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Lars E. Pettersson]

On 07/22/2013 08:30 PM, Lennart Poettering wrote:
>  Well, assuming people use the local machine for reading their mails,
> and
>  not Thunderbird or so and not GMail and so on, or Zimbra or whatever
>  else people actually read mails with these days... None of these even do
>  local message reading. 
Thunderbird reads spool mail. You also have mailx for those that really 
want it that way.

I am not sure of other MUA but doesn't they also read spool mail? 
Evolution did last I used it.

And if you use a web based MUA, you simply change the line starting with 
root in /etc/aliases and run mewaliases, and the mail turns up in the 
web mail system.

Again, the output is not lost.

One thing though, /etc/aliases ought to be updated with information on 
who should get "system mail" during installation. This part is missing, 
which creates the illusion that the output is lost.

> >> By ensuring all logs go to the normal
> >> log stream there's a much better chance of not losing messages...
> >
> > The problem is that this data can be quite voluminous. Perhaps a bad
> > thing to clog up the logs with that?
>
>  Emails due to base64 encoding usually increase everything by 4/3, which
>  is certainly worse. 
But those emails does not end up in the log, do they? What I am hinting 
on is the voluminous messages normally sent to root, that you want to 
deliver to the logs instead.

The mail messages sent to root, or whoever you send it to, can be quite 
voluminous. I use yum-cron and today got the following message. How 
would this be handled by the log/journal/whatever?

Lars

----
/etc/cron.hourly/0yum-hourly.cron:

Delta RPMs reduced 8.9 M of updates to 2.6 M (71% saved)
Finishing delta rebuilds of 8 package(s) (8.5 M)
The following updates will be applied on xxx.yyy.zzz.se:
================================================================================
  Package                 Arch         Version               Repository 
     Size
================================================================================
Updating:
  brlapi                  x86_64       0.6.0-6.fc19          updates 
    110 k
  brltty                  x86_64       4.5-6.fc19            updates 
    910 k
  cifs-utils              x86_64       6.1-3.fc19            updates 
     87 k
  libsmbclient            x86_64       2:4.0.7-2.fc19        updates 
    109 k
  libtirpc                x86_64       0.2.3-3.fc19          updates 
     81 k
  libwayland-client       x86_64       1.2.0-1.fc19          updates 
     24 k
  libwayland-cursor       x86_64       1.2.0-1.fc19          updates 
     15 k
  libwayland-server       x86_64       1.2.0-1.fc19          updates 
     29 k
  libwbclient             x86_64       2:4.0.7-2.fc19        updates 
     78 k
  netpbm                  x86_64       10.61.02-5.fc19       updates 
    177 k
  netpbm-progs            x86_64       10.61.02-5.fc19       updates 
    1.7 M
  pygobject3              x86_64       3.8.3-1.fc19          updates 
     12 k
  pygobject3-base         x86_64       3.8.3-1.fc19          updates 
    295 k
  python-brlapi           x86_64       0.6.0-6.fc19          updates 
     57 k
  python3-brlapi          x86_64       0.6.0-6.fc19          updates 
     56 k
  python3-gobject         x86_64       3.8.3-1.fc19          updates 
    304 k
  samba-client            x86_64       2:4.0.7-2.fc19        updates 
    454 k
  samba-common            x86_64       2:4.0.7-2.fc19        updates 
    695 k
  samba-libs              x86_64       2:4.0.7-2.fc19        updates 
    4.1 M

Transaction Summary
================================================================================
Upgrade  19 Packages
The updates were successfully applied
----

-- 
Lars E. Pettersson <lars(a)homer.se&gt;
http://www.sm6rpz.se/

[Matthew Miller]

On Mon, Jul 15, 2013 at 01:50:47PM -0400, DJ Delorie wrote:
>  I worry about the security implications of mail that would have gone
>  to root@ being either silently discarded or unknowingly ignored. 
That *is* the current case on these systems. The mail happens to live in
/var/spool/mail/root, where it accumulates silenty, but the difference
between that and /dev/null is practically small.

On my own systems, I usually alias root to a special account (off system) I
have configured for that purpose -- but that requires configuration, and
it's no pain to install an MTA on systems where I want that.

Without configuration, it's better to fail in a way which might generate an
error than than to "succeed" in a way which buries the real failure.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Till Maas]

On Mon, Jul 15, 2013 at 01:57:37PM -0400, Matthew Miller wrote:
>  On Mon, Jul 15, 2013 at 01:50:47PM -0400, DJ Delorie wrote:
>  > I worry about the security implications of mail that would have gone
>  > to root@ being either silently discarded or unknowingly ignored.
>  
>  That *is* the current case on these systems. The mail happens to live in
>  /var/spool/mail/root, where it accumulates silenty, but the difference
>  between that and /dev/null is practically small. 
Bash usually tells you when there is mail in the spool, which is IMHO a
big difference to /dev/null.

Regards
Till

[Eric Smith]

On Mon, Jul 15, 2013 at 3:12 PM, Till Maas <opensource(a)till.name&gt; wrote:
>  Bash usually tells you when there is mail in the spool, which is IMHO
> a
>  big difference to /dev/null. 
Funny, I just ssh'd into my machine, and it didn't tell me anything
about mail being in the spool, but when I do an ls on the spool
directory, there it is.

Maybe it has something to do with that users don't often log in as root.

Eric

[Till Maas]

On Mon, Jul 15, 2013 at 03:15:54PM -0600, Eric Smith wrote:
>  On Mon, Jul 15, 2013 at 3:12 PM, Till Maas
> <opensource(a)till.name&gt; wrote:
>  > Bash usually tells you when there is mail in the spool, which is IMHO a
>  > big difference to /dev/null.
>  
>  Funny, I just ssh'd into my machine, and it didn't tell me anything
>  about mail being in the spool, but when I do an ls on the spool
>  directory, there it is.
>  
>  Maybe it has something to do with that users don't often log in as root. 
Oh, sorry, I was imprecise. Bash actually tells you when new mail is put
into the spool. E.g. if you log in as root, touch /var/spool/root and
wait up to 60 seconds and run e.g. ls, bash should tell you that there
is new mail before the next prompt.

Regards
Till

[Eric Smith]

On Mon, Jul 15, 2013 at 3:45 PM, Till Maas <opensource(a)till.name&gt; wrote:
>  Oh, sorry, I was imprecise. Bash actually tells you when new mail is
> put
>  into the spool. E.g. if you log in as root, touch /var/spool/root and
>  wait up to 60 seconds and run e.g. ls, bash should tell you that there
>  is new mail before the next prompt. 
Sure. And how often does a typical user log in as root to discover that email?

Even on systems I administer myself, I don't log in as root, or su,
all that often.

Eric

[Eric Smith]

On Mon, Jul 15, 2013 at 11:50 AM, DJ Delorie <dj(a)redhat.com&gt; wrote:
>  I worry about the security implications of mail that would have gone
>  to root@ being either silently discarded or unknowingly ignored.
>
>  If there is no other way to send mail to local users, we should have a
>  local MTA configured for such. 
Even with an MTA installed, the default was for mail to root was to be
unknowingly ignored.  With no MTA installed, at least a program that
tries to send mail to root can discover that it failed, and log
something to syslog (or systemd journal, or something), though that's
arguably what it should have been doing in the first place rather than
sending mail to root.  In my experience it is far more common for a
sysadmin to look at the syslog on a machine than to mail delivered to
root on that machine.

Eric

[Lars E. Pettersson]

On 07/15/2013 08:00 PM, Eric Smith wrote:
>  Even with an MTA installed, the default was for mail to root was to
> be
>  unknowingly ignored. 
One of the first things I do on new installs is to change the line 
"Person who should get root's mail" in /etc/aliases so that root mail 
goes to the person in charge on that computer. Perhaps this should be 
mentioned in the installation guide or something, or even done in anaconda?

Lars
-- 
Lars E. Pettersson <lars(a)homer.se&gt;
http://www.sm6rpz.se/

[Miloslav Trmač]

On Mon, Jul 15, 2013 at 10:36 AM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  = Proposed System Wide Change: No Default Sendmail =
>  https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
>
>  Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
>  Miller <mattdm at fedoraproject org>
>
>  No longer install an MTA by default. (Specifically let's remove sendmail from
>  @core and @standard comps groups.)
>
>  == Detailed description ==
>  Let's change the default install to no longer install an MTA by default.
>  Specifically, let's remove sendmail from the @standard and @core group.
>
>  On today's Internet most SMTP hosts do not accept mail from a server which is
>  not configured as a mail exchange for a real domain, hence the default
>  configuration of sendmail is seldom useful. 
We don't necessarily have to have a MTA always running, or listening on port 25.

However, having the /usr/sbin/sendmail API available to applications
is valuable - it brings a significant system administration benefit of
centralizing the SMTP configuration.

Every application[1] can be rewritten to have its own SMTP client and
configuration instead of calling /usr/sbin/sendmail, sure, but the
system administrators are much better off if the applications call
/usr/sbin/sendmail and $whatever implementation handles that.

This is not a packaging matter of adding Requires:/usr/sbin/sendmail -
we get the benefit of centralization only if applications support
/usr/sbin/sendmail , and have it configured as the default.  Removing
a provider of /usr/sbin/sendmail from the default installation
entirely makes both of these application design choices problematic
and unlikely.
     Mirek


[1] GUIs and similar things targeted at people who don't want to deal
with strings like "/etc" are probably excluded; think of servers,
daemons and the like instead.

[Matthew Miller]

On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
>  However, having the /usr/sbin/sendmail API available to applications
>  is valuable - it brings a significant system administration benefit of
>  centralizing the SMTP configuration. 
What does it mean to "have available"? As discussed earlier, I think it's
significantly better for applications to get errors (which they can handle)
than to think they've sent a message which really gets buried forever.

And it's just not possible to automatically configure e-mail. It might have
been in 1997, when every system was directly connected to the Internet,
every network allowed port 25 out, and everyone accepted mail from
everywhere. None of those things are true now -- not just not true in some
cases, but not true in the common case.

I think the way forward is to encourage applications to _log_ rather than to
send e-mail, via this or any other API. That can be configured for e-mail
alerts if the admin really wants. But without configuration, nothing is
going to happen _anyway_.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Miloslav Trmač]

On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
> > However, having the /usr/sbin/sendmail API available to applications
> > is valuable - it brings a significant system administration benefit of
> > centralizing the SMTP configuration.
>
>  What does it mean to "have available"? 
Just that.  The binary exists and
does what it is expected to do.

>  As discussed earlier, I think it's
>  significantly better for applications to get errors (which they can handle)
>  than to think they've sent a message which really gets buried forever. 
In the case I'm thinking about, application installation instructions
just say "make sure $sendmail works" instead of "configure SMTP (and
TLS! and SMTP auth!) in this application-specific configuration file".

>  And it's just not possible to automatically configure e-mail.
My claim that it is useful to have /usr/sbin/sendmail does not at all
depend on having an automatic configuration that works for everyone.

>  I think the way forward is to encourage applications to _log_ rather
> than to
>  send e-mail, via this or any other API. 
Application that want to log shoud log. 
Applications that want to
send e-mail should send e-mail.  My bank's monthly statement would be
rather useless in the bank's splunk archive.
    Mirek

[Matthew Miller]

On Fri, Jul 19, 2013 at 08:22:28PM +0200, Miloslav Trmač wrote:
>  > What does it mean to "have available"?
>  Just that.  The binary exists and does what it is expected to do. 
We can do part 1. Part 2 is impossible.


>  > As discussed earlier, I think it's
>  > significantly better for applications to get errors (which they can handle)
>  > than to think they've sent a message which really gets buried forever.
>  In the case I'm thinking about, application installation instructions
>  just say "make sure $sendmail works" instead of "configure SMTP (and
>  TLS! and SMTP auth!) in this application-specific configuration file". 
I'm absolutely not suggesting we drop having an MTA. That would be silly.

>  > And it's just not possible to automatically configure
> e-mail.
>  My claim that it is useful to have /usr/sbin/sendmail does not at all
>  depend on having an automatic configuration that works for everyone. 
Sure. So then it's just down to a matter of whether it's good to have it
installed but unconfigured. I think it isn't. I'm _certain_ that it isn't in
in @core and in the cloud use case. I can be convinced that there is some
better default configuration we can ship in the desktop case, but I'd be
surprised -- it's not like Mac users and developers are clamouring for local
mail to work. And in the server case, we're not going be able to
auto-configure anything, because the local sysadmins will _always_ want the
right local thing, which will be different -- so best to leave a blank
slate.


>  Application that want to log shoud log.  Applications that want to
>  send e-mail should send e-mail.  My bank's monthly statement would be
>  rather useless in the bank's splunk archive. 
Well, sure. But if we're talking about this kind of application, I think
it's entirely irrelevant to the change proposal at hand. Unless we're
planning to install your bank on eveyone's Fedora system by default. :)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Lennart Poettering]

On Fri, 19.07.13 20:22, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
>  <mattdm(a)fedoraproject.org&gt; wrote:
>  > On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
>  >> However, having the /usr/sbin/sendmail API available to applications
>  >> is valuable - it brings a significant system administration benefit of
>  >> centralizing the SMTP configuration.
>  >
>  > What does it mean to "have available"?
>  Just that.  The binary exists and does what it is expected to do. 
Where "expected to do" means effectively route it to /dev/null?

>  > As discussed earlier, I think it's
>  > significantly better for applications to get errors (which they can handle)
>  > than to think they've sent a message which really gets buried forever.
>  
>  In the case I'm thinking about, application installation instructions
>  just say "make sure $sendmail works" instead of "configure SMTP (and
>  TLS! and SMTP auth!) in this application-specific configuration file". 
If features only work after configuration (in articular non-trivial
configuration like this case) then it should not be part of the default
install. Because it is code, that claims to just work, but doesn't. That
is ver hard on the users, and simply is broken.

>  > I think the way forward is to encourage applications to _log_
> rather than to
>  > send e-mail, via this or any other API.
>  Application that want to log shoud log.  Applications that want to
>  send e-mail should send e-mail.  My bank's monthly statement would be
>  rather useless in the bank's splunk archive. 
Sure, but your bank web site probably doesn't send its mails out with
only tools of the default install? They do with a heavily configured
installation of some OS, where they manually configured an SMTP server
and such. Only if they did this is it becomes useful. 

Let's not forget: this is not about removing software from the
distro. This is just about removing it from the default install, since
the current way it is set up by default it just eats up messages
silently, with not indication of error and no useful tools installed to
actually get the messages out of it again.

Despite that I am pretty sure that most of the stuff we currently mail
(like the log output of cron jobs) simply makes no sense as mail, and
should much rather be treated exactly like all other log output. There's
nothing special really about cron that would make it so much better
suitable for sending out its logs per mail, rather then just log them.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Fri, 19.07.13 20:22, Miloslav Trmač (mitr(a)volny.cz) wrote:
>
> > On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
> > <mattdm(a)fedoraproject.org&gt; wrote:
> > > On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
> > >> However, having the /usr/sbin/sendmail API available to applications
> > >> is valuable - it brings a significant system administration benefit of
> > >> centralizing the SMTP configuration.
> > >
> > > What does it mean to "have available"?
> > Just that.  The binary exists and does what it is expected to do.
>
>  Where "expected to do" means effectively route it to /dev/null? 
It's actually less similar to /dev/null than log files are - log files
are rotated and deleted, mail stays in the mail boxes until explicitly
deleted (or space runs out).


> > > As discussed earlier, I think it's
> > > significantly better for applications to get errors (which they can handle)
> > > than to think they've sent a message which really gets buried forever.
> >
> > In the case I'm thinking about, application installation instructions
> > just say "make sure $sendmail works" instead of "configure SMTP (and
> > TLS! and SMTP auth!) in this application-specific configuration file".
>
>  If features only work after configuration (in articular non-trivial
>  configuration like this case) then it should not be part of the default
>  install. 
That a feature needs configuration does not automatically exclude it
from the default installation - removing a package from the default
installation and telling users to install it back is just window
dressing and asking them to do unnecessary extra work.


> > > I think the way forward is to encourage applications to
> _log_ rather than to
> > > send e-mail, via this or any other API.
> > Application that want to log shoud log.  Applications that want to
> > send e-mail should send e-mail.  My bank's monthly statement would be
> > rather useless in the bank's splunk archive.
>
>  Sure, but your bank web site probably doesn't send its mails out with
>  only tools of the default install? 
"What is in the default install" is, as argued elsewhere, also an
implicit documentation of "how things are done".
    Mirek

[Lennart Poettering]

On Mon, 22.07.13 18:43, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  > On Fri, 19.07.13 20:22, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  >
>  >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
>  >> <mattdm(a)fedoraproject.org&gt; wrote:
>  >> > On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
>  >> >> However, having the /usr/sbin/sendmail API available to applications
>  >> >> is valuable - it brings a significant system administration benefit of
>  >> >> centralizing the SMTP configuration.
>  >> >
>  >> > What does it mean to "have available"?
>  >> Just that.  The binary exists and does what it is expected to do.
>  >
>  > Where "expected to do" means effectively route it to /dev/null?
>  
>  It's actually less similar to /dev/null than log files are - log files
>  are rotated and deleted, mail stays in the mail boxes until explicitly
>  deleted (or space runs out). 
Well, so it's even a DoS... Just find some trigger to generate a lot of
mails to root and /var will eventually fill up, even beyond those 10%
reserved for root, since well, mail to root is accounted to root...

This is not helping your case. It just makes it worse.

>  > If features only work after configuration (in articular
> non-trivial
>  > configuration like this case) then it should not be part of the default
>  > install.
>  
>  That a feature needs configuration does not automatically exclude it
>  from the default installation - removing a package from the default
>  installation and telling users to install it back is just window
>  dressing and asking them to do unnecessary extra work. 
No, because only a smaller fraction of installs would actually end up
installing a local MTA.

>  >> Application that want to log shoud log.  Applications that
> want to
>  >> send e-mail should send e-mail.  My bank's monthly statement would be
>  >> rather useless in the bank's splunk archive.
>  >
>  > Sure, but your bank web site probably doesn't send its mails out with
>  > only tools of the default install?
>  
>  "What is in the default install" is, as argued elsewhere, also an
>  implicit documentation of "how things are done". 
But it is totally bogus to claim that banks would suddenly stop sending
you notifcations by email just because Fedora doesn't install sendmail
by default. I mean, come on, you are not trying to be honest here, and
you know it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Mon, 22.07.13 18:43, Miloslav Trmač (mitr(a)volny.cz) wrote:
>
> > On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
> > <mzerqung(a)0pointer.de&gt; wrote:
> > >> Application that want to log shoud log.  Applications that want to
> > >> send e-mail should send e-mail.  My bank's monthly statement would be
> > >> rather useless in the bank's splunk archive.
> > >
> > > Sure, but your bank web site probably doesn't send its mails out with
> > > only tools of the default install?
> >
> > "What is in the default install" is, as argued elsewhere, also an
> > implicit documentation of "how things are done".
>
>  But it is totally bogus to claim that banks would suddenly stop sending
>  you notifcations by email just because Fedora doesn't install sendmail
>  by default. I mean, come on, you are not trying to be honest here, and
>  you know it. 
Sure, if you twist my words into saying something I didn't say...  "I
mean, come on, you are not trying to be honest here, and you know it."

The question is _how_ to send the e-mail, not _whether_.
    Mirek

[Adam Williamson]

On Mon, 2013-07-22 at 19:09 +0200, Miloslav Trmač wrote:
>  On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  > On Mon, 22.07.13 18:43, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  >
>  >> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>  >> <mzerqung(a)0pointer.de&gt; wrote:
>  >> >> Application that want to log shoud log.  Applications that want to
>  >> >> send e-mail should send e-mail.  My bank's monthly statement would
> be
>  >> >> rather useless in the bank's splunk archive.
>  >> >
>  >> > Sure, but your bank web site probably doesn't send its mails out with
>  >> > only tools of the default install?
>  >>
>  >> "What is in the default install" is, as argued elsewhere, also an
>  >> implicit documentation of "how things are done".
>  >
>  > But it is totally bogus to claim that banks would suddenly stop sending
>  > you notifcations by email just because Fedora doesn't install sendmail
>  > by default. I mean, come on, you are not trying to be honest here, and
>  > you know it.
>  
>  Sure, if you twist my words into saying something I didn't say...  "I
>  mean, come on, you are not trying to be honest here, and you know it."
>  
>  The question is _how_ to send the e-mail, not _whether_. 
Just before this one gets any worse: it was Nicolas Mailhot who started
talking about banks sending email for some reason, not Miloslav.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Nicolas Mailhot]

Le Lun 22 juillet 2013 20:23, Adam Williamson a écrit :

>  Just before this one gets any worse: it was Nicolas Mailhot who
> started
>  talking about banks sending email for some reason, not Miloslav. 
Please do not attribute me what I didn't write. I didn't bring banks in
the discussion.

-- 
Nicolas Mailhot

[Adam Williamson]

On Mon, 2013-07-22 at 21:10 +0200, Nicolas Mailhot wrote:
>  Le Lun 22 juillet 2013 20:23, Adam Williamson a écrit :
>  
>  > Just before this one gets any worse: it was Nicolas Mailhot who started
>  > talking about banks sending email for some reason, not Miloslav.
>  
>  Please do not attribute me what I didn't write. I didn't bring banks in
>  the discussion. 
Oh, sorry, that's right - you cited 'Google and Amazon', and someone
extended the example later.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Miloslav Trmač]

On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Mon, 22.07.13 18:43, Miloslav Trmač (mitr(a)volny.cz) wrote:
>
> > On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
> > <mzerqung(a)0pointer.de&gt; wrote:
> > > On Fri, 19.07.13 20:22, Miloslav Trmač (mitr(a)volny.cz) wrote:
> > >
> > >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
> > >> <mattdm(a)fedoraproject.org&gt; wrote:
> > > Where "expected to do" means effectively route it to /dev/null?
> >
> > It's actually less similar to /dev/null than log files are - log files
> > are rotated and deleted, mail stays in the mail boxes until explicitly
> > deleted (or space runs out).
>
>  Well, so it's even a DoS... Just find some trigger to generate a lot of
>  mails to root and /var will eventually fill up, even beyond those 10%
>  reserved for root, since well, mail to root is accounted to root... 
My concern about this proposal doesn't actually depend on local
delivery, it _could_ go to /dev/null by default for all I care.

I'll note, however, that "this is a DoS" is rarely a convincing
argument - the only practical way to combat a DoS is to impose some
kind of limit, which is just a DoS of a different kind.  You get to
choose _what_ kinds of DoS your computer will be subject to, but with
finite CPU power and storage you can't avoid DoS situations.

And, philosophically, silently losing data is generally much worse
than requiring manual intervention for the system to run when space
runs out.  (Not that the mails we sent by default are _that_ valuable,
though.)
    Mirek

[Lennart Poettering]

On Mon, 22.07.13 19:19, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  > On Mon, 22.07.13 18:43, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  >
>  >> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
>  >> <mzerqung(a)0pointer.de&gt; wrote:
>  >> > On Fri, 19.07.13 20:22, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  >> >
>  >> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
>  >> >> <mattdm(a)fedoraproject.org&gt; wrote:
>  >> > Where "expected to do" means effectively route it to /dev/null?
>  >>
>  >> It's actually less similar to /dev/null than log files are - log files
>  >> are rotated and deleted, mail stays in the mail boxes until explicitly
>  >> deleted (or space runs out).
>  >
>  > Well, so it's even a DoS... Just find some trigger to generate a lot of
>  > mails to root and /var will eventually fill up, even beyond those 10%
>  > reserved for root, since well, mail to root is accounted to root...
>  
>  My concern about this proposal doesn't actually depend on local
>  delivery, it _could_ go to /dev/null by default for all I care. 
What a crappy API is that?

>  I'll note, however, that "this is a DoS" is rarely a
> convincing
>  argument - the only practical way to combat a DoS is to impose some
>  kind of limit, which is just a DoS of a different kind.  You get to
>  choose _what_ kinds of DoS your computer will be subject to, but with
>  finite CPU power and storage you can't avoid DoS situations. 
The point I am trying to make is that if you have something that is
vulnerable to a DoS attack you need to have a strategy to handle
that. You need to keep the attack local, isolated as much as you can
from the rest of the system and other clients. A strategy of "hey, yeah,
let's queue this all up and allow unprivileged clients to bring down the
entire system by easily flooding /var" is a bad strategy, an
embarrassingly bad one. It's a DoS that is the opposite of local.

>  And, philosophically, silently losing data is generally much worse
>  than requiring manual intervention for the system to run when space
>  runs out.  (Not that the mails we sent by default are _that_ valuable,
>  though.)
>      Mirek 
If we drop data we definitely always need to keep track of that and
account it, no doubt. (journald does keep track of messages dropped via
per-service/per-priority ratelimit, and it will tell you how far back
history in the logs reach)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Oron Peled]

Hi,

On Monday 22 July 2013 21:15:14 Lennart Poettering wrote:
>  The point I am trying to make is that if you have something that is
>  vulnerable to a DoS attack you need to have a strategy to handle
>  that. 
A very simple strategy exists -- alias root's mail to a regular user.

I previously said it should be done during installation for usability
reasons -- now you've just added another good reason.

Please note that this is relevant even for the suggested world
of "non-MTA-by-default", because some people (horror, shock, awe)
may actually install one.
(unless DoS traps are OK for non-default installed packages...)

Bye,

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"Linux: like the air you breathe, ubiquitous and free"

[Nicolas Mailhot]

Le Lun 22 juillet 2013 18:36, Lennart Poettering a écrit :
>   There's
>  nothing special really about cron that would make it so much better
>  suitable for sending out its logs per mail, rather then just log them. 
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.

-- 
Nicolas Mailhot

[Matthew Miller]

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? You suggested earlier that I dislike cron's e-mail
output, and while I hadn't brought up likes or dislikes before, I really
don't find it so great. To me, it just fills up my mailbox with:

   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Anacron            Anacron job 'cron.daily' on bigcomputer.home.
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@wumpus> ionice -c3 run-parts /etc/
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@resonance> /opt/seas/sbin/sync-NIS
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <masher@releng03> TMPDIR=`mktemp -d /tmp
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
   Jul 02 Cron Daemon        Cron <root@hpc> /etc/15m.local
   Jul 02 Cron Daemon        Cron <root@hpc> /etc/15m.local
   Jul 02 Cron Daemon        Cron <root@hpc> /etc/15m.local
   Jul 02 Cron Daemon        Cron <root@hpc> /etc/15m.local
   Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro

If I did want e-mail output -- which I used to, before I had proper alerting
set up, so as I mentioned before I totally recognize that use case -- I
really would like it with a meaningful subject line, which means even when
running out of cron, the jobs should actually call sendmail or /usr/bin/mail
directly with pretty-formatted output. (And thus, have an explicit
dependency on an MTA, and also basically have the expectation that they're
running on a system which will be properly configured for its environment,
however that happens.)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Nicolas Mailhot]

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

[Alexey I. Froloff]

On Mon, Jul 22, 2013 at 06:36:41PM +0200, Lennart Poettering wrote:
>  Let's not forget: this is not about removing software from the
>  distro. This is just about removing it from the default install, since
>  the current way it is set up by default it just eats up messages
>  silently, with not indication of error and no useful tools installed to
>  actually get the messages out of it again. 
Instead of having MTA, I'd rather
have tool that can collect and
show such "mails".  There are machines (like my and wife's
laptops) that are not supposed to send emails.  They doesn't even
have MUA installed.  All these emails are wasted and not being
rotated.

In 2013 you can't just start sending mails around with default
MTA settings, so not installing and MTA by default is a good
solution.

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[Alexander Boström]

mån 2013-07-22 klockan 18:36 +0200 skrev Lennart Poettering:

>  Despite that I am pretty sure that most of the stuff we currently
> mail
>  (like the log output of cron jobs) simply makes no sense as mail, and
>  should much rather be treated exactly like all other log output. There's
>  nothing special really about cron that would make it so much better
>  suitable for sending out its logs per mail, rather then just log them. 
Yeah, as a sysadmin I'm mostly annoyed by services that send mail and
expect someone to have time to read them. Give me a current status that
can be monitored as appropriate (desktop notifications, Nagios etc) and
logs so I can go back and see what went wrong.

Also, I think people who are new to this stuff are much more likely to
look for logs than for mail ("what, computers can have mail on them?")
when they're trying to figure out what's happening.

It is however a bit scary if the behavior of cron changes when someone
installs an MTA. I think -s should be the default, but MAILTO= should
have precedence over -s.

/Alexander

[Robert Nichols]

On 07/22/2013 11:36 AM, Lennart Poettering wrote:
>   I am pretty sure that most of the stuff we currently mail
>  (like the log output of cron jobs) simply makes no sense as mail, and
>  should much rather be treated exactly like all other log output. There's
>  nothing special really about cron that would make it so much better
>  suitable for sending out its logs per mail, rather then just log them. 
How many megabytes can the log system reasonably accept in a single message?
The output from a cron job can be a lot more than what anyone would
consider to be a reasonable log message.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Lennart Poettering]

On Mon, 22.07.13 15:26, Robert Nichols (rnicholsNOSPAM(a)comcast.net) wrote:

>  On 07/22/2013 11:36 AM, Lennart Poettering wrote:
>  > I am pretty sure that most of the stuff we currently mail
>  >(like the log output of cron jobs) simply makes no sense as mail, and
>  >should much rather be treated exactly like all other log output. There's
>  >nothing special really about cron that would make it so much better
>  >suitable for sending out its logs per mail, rather then just log them.
>  
>  How many megabytes can the log system reasonably accept in a single message?
>  The output from a cron job can be a lot more than what anyone would
>  consider to be a reasonable log message. 
journald is in theory fine with 2^64 bytes per message. In practice (due
to the CPU cost of compressing large blobs with XZ while we write it to
disk) a few MB should be fine. Also, cronie will split up the messages
by line anyway if it logs to syslog instead of sendmail.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Matthew Miller]

On Tue, Jul 23, 2013 at 12:36:19AM +0200, Lennart Poettering wrote:
>  journald is in theory fine with 2^64 bytes per message. In practice
> (due
>  to the CPU cost of compressing large blobs with XZ while we write it to
>  disk) a few MB should be fine. Also, cronie will split up the messages
>  by line anyway if it logs to syslog instead of sendmail. 
That seems less good -- is there a way to reassemble the messages.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Lennart Poettering]

On Mon, 22.07.13 19:29, Matthew Miller (mattdm(a)fedoraproject.org) wrote:

>  On Tue, Jul 23, 2013 at 12:36:19AM +0200, Lennart Poettering wrote:
>  > journald is in theory fine with 2^64 bytes per message. In practice (due
>  > to the CPU cost of compressing large blobs with XZ while we write it to
>  > disk) a few MB should be fine. Also, cronie will split up the messages
>  > by line anyway if it logs to syslog instead of sendmail.
>  
>  That seems less good -- is there a way to reassemble the messages. 
It does have clear advantages though: You can get a live view into the
output of a long-running job. If you queue everything up and only submit
it as one blob then the job would be completely opaque until complete.

With systemd's own job handling we generally only use line-by-line
loggin, but provide useful tools to then view them as one continous
stream ("journalctl -u foobar.service -o cat" for example).

But anyway, the journal doesn't make any restrictions. Whatever
philosophy services like cron prefer on this, we handle either.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Robert Nichols]

On 07/22/2013 05:36 PM, Lennart Poettering wrote:
> Also, cronie will split up the messages
>  by line anyway if it logs to syslog instead of sendmail. 
That sounds particularly horrible for concurrent cron jobs that would
thus have their output interleaved in the log.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Frank Ch. Eigler]

mattdm wrote:

>  [...]
>  What does it mean to "have available"? As discussed earlier, I think it's
>  significantly better for applications to get errors (which they can handle)
>  than to think they've sent a message which really gets buried forever. 
There exist /usr/lib/sendmail submission-only imitators (ssmtp, msmtp)
that could be trained to block until mail is delivered, and return
error return codes upon rejection.

>  And it's just not possible to automatically configure e-mail.
> [...] 
As for outgoing SMTP, DHCP packets can identify servers; so can DNS heuristics.

>  I think the way forward is to encourage applications to _log_ rather
> than to
>  send e-mail, via this or any other API. That can be configured for e-mail
>  alerts if the admin really wants. But without configuration, nothing is
>  going to happen _anyway_. 
Such a transition should come along with all the tooling needed to
emulate the status quo - i.e., scraped-log-to-email scripts.


- FChE

[Lennart Poettering]

On Fri, 19.07.13 14:47, Frank Ch. Eigler (fche(a)redhat.com) wrote:

>  > And it's just not possible to automatically configure
> e-mail. [...]
>  
>  As for outgoing SMTP, DHCP packets can identify servers; so can DNS
>  heuristics. 
I have yet to see my first DHCP server in the wild that actually supplies that info...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Reindl Harald]

Am 22.07.2013 18:51, schrieb Lennart Poettering:
>  On Fri, 19.07.13 14:47, Frank Ch. Eigler (fche(a)redhat.com) wrote:
>  
> >> And it's just not possible to automatically configure e-mail. [...]
> >
> > As for outgoing SMTP, DHCP packets can identify servers; so can DNS
> > heuristics.
>  
>  I have yet to see my first DHCP server in the wild that actually supplies that info...
here you have - LAN IP's masked but C&P from production - as well as
https://wiki.mozilla.org/Thunderbird:Autoconfiguration
is not that hard to setup and maintain automatically even
for some hundret of domains

subnet 192.168.196.0 netmask 255.255.255.0 {
 option domain-name "thelounge.net";
 option domain-name-servers 192.168.196.6, 192.168.196.106, 192.168.196.30;
 option routers 192.168.196.1;
 option smtp-server 192.168.196.30;
 option pop-server 192.168.196.30;
 option ntp-servers 192.168.196.107, 192.168.196.112;
 option time-servers 192.168.196.107, 192.168.196.112;
 option subnet-mask 255.255.255.0;
 option broadcast-address 192.168.196.255;
 option interface-mtu 1472;
 range 192.168.196.234 192.168.196.240;
}

[Oron Peled]

Hi,

On Friday 19 July 2013 14:16:57 Matthew Miller wrote:
>  .... As discussed earlier, I think it's
>  significantly better for applications to get errors (which they can handle)
>  than to think they've sent a message which really gets buried forever. 
True, but it doesn't have to be buried forever, at least not for the
default (desktop) install:
 * Default delivery as today (no smart host, deliver to local mailbox)
 * We should add the local inbox to the default configuration of all
   MUA's that can handle it (kmail, evolution, etc.)
 * When Anaconda (or would it be first boot? I lost tracking...) is
   setting the first user, add it to /etc/aliases as a mail alias to root.

With this, on every *default* desktop the installing user start getting
useful system mails from various packages as they are installed (logwatch,
arpwatch, cron-jobs, etc.)

IMO, removing sendmail from the *minimal* install is good idea, but
we should have an MTA for the default install with local delivery.

>  I think the way forward is to encourage applications to _log_ rather
> than to
>  send e-mail, via this or any other API. That can be configured for e-mail
>  alerts if the admin really wants. 
Logging and mail have totally different use-cases. With mail you can send
an extensive multi-line report to a human.

As explained in the previous section, with very basic default configuration
for MUA's and MTA's you get a very high chance that the desktop user who
installed the system would actually see these mails (and any user would
see the output of their cron-jobs).

These same users are very unlikely to know that logs even exist, much
less how to read them.

[and all non-privileged users cannot see the output of their own
 cron-jobs...]

>  But without configuration, nothing is
>  going to happen _anyway_. 
Other use-cases would need configuration anyway. If you install a VM
you may really want remote logging (as well as smart-host mails).
But then such deployments are usually done by knowledgeable people
with appropriate tooling (kickstarts, configuration-management tools, etc.)

To summarize:
 * Remove from minimal install -- so advanced use cases can get rid of MTA.
 * Leave on default install:
   - Adding local mailbox to default configuration of MUA's would be
     an improvement.
   - Adding the installing user as a root alias to /etc/aliases would be
     another improvement.

Bye,

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"It's almost like we're doing Windows users a favor by charging them money
for something they could get for free, because they get confused otherwise."
 - Larry Wall.

[Lars Seipel]

On Fri, Jul 19, 2013 at 11:37:23PM +0300, Oron Peled wrote:
>   * We should add the local inbox to the default configuration of all
>     MUA's that can handle it (kmail, evolution, etc.) 
That'd be really nice.

>   * When Anaconda (or would it be first boot? I lost tracking...) is
>     setting the first user, add it to /etc/aliases as a mail alias to root. 
It's Anaconda or initial-setup these days. Or gnome-initial-setup for
Gnome. :-)

>  IMO, removing sendmail from the *minimal* install is good idea, but
>  we should have an MTA for the default install with local delivery. 
Agreed.

Lars

[Nicolas Mailhot]

Le Ven 19 juillet 2013 20:16, Matthew Miller a écrit :
>  On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
> > However, having the /usr/sbin/sendmail API available to applications
> > is valuable - it brings a significant system administration benefit of
> > centralizing the SMTP configuration.
>
>  What does it mean to "have available"? As discussed earlier, I think it's
>  significantly better for applications to get errors (which they can
>  handle) 
ROTFL. They won't handle anything, they'll just test the "everything is
working" scenario.

Having a standard way to use a real MUA, with actual support for SMTP
intricacies, proofed queuing logic, and single configuration store or
language, is a major reliability and operational boon. Every single time
I've seen an app disdain the local MTA because "it is not available on
non-*nix systems" it ended up badly the first time there was an error to
handle. And I'm quite sure any security audit of their SMTP logic would
have been dreadful.

-- 
Nicolas Mailhot

[Nico Kadel-Garcia]

On Sat, Jul 20, 2013 at 10:50 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Ven 19 juillet 2013 20:16, Matthew Miller a écrit :
> > On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
> >> However, having the /usr/sbin/sendmail API available to applications
> >> is valuable - it brings a significant system administration benefit of
> >> centralizing the SMTP configuration.
> >
> > What does it mean to "have available"? As discussed earlier, I think
> it's
> > significantly better for applications to get errors (which they can
> > handle)
>
>  ROTFL. They won't handle anything, they'll just test the "everything is
>  working" scenario.
>
>  Having a standard way to use a real MUA, with actual support for SMTP
>  intricacies, proofed queuing logic, and single configuration store or
>  language, is a major reliability and operational boon. Every single time
>  I've seen an app disdain the local MTA because "it is not available on
>  non-*nix systems" it ended up badly the first time there was an error to
>  handle. And I'm quite sure any security audit of their SMTP logic would
>  have been dreadful. 
Amen. If I see one more Java based non-RFC compliant,
non-error-reporting piece of "I'll be an MTA when I grow up" debris
shoved into a messaging application......

[Billy Crook]

On Fri, Jul 19, 2013 at 12:37 PM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:

>  On Mon, Jul 15, 2013 at 10:36 AM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt;
>  wrote:
>  > = Proposed System Wide Change: No Default Sendmail =
>  > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
>  >
>  > Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
>  > Miller <mattdm at fedoraproject org>
>  >
>  > No longer install an MTA by default. (Specifically let's remove sendmail
>  from
>  > @core and @standard comps groups.)
>  >
>  > == Detailed description ==
>  > Let's change the default install to no longer install an MTA by default.
>  > Specifically, let's remove sendmail from the @standard and @core group.
>  >
>  > On today's Internet most SMTP hosts do not accept mail from a server
>  which is
>  > not configured as a mail exchange for a real domain, hence the default
>  > configuration of sendmail is seldom useful.
>
>  We don't necessarily have to have a MTA always running, or listening on
>  port 25.
>
>  However, having the /usr/sbin/sendmail API available to applications
>  is valuable - it brings a significant system administration benefit of
>  centralizing the SMTP configuration.
>
>  Every application[1] can be rewritten to have its own SMTP client and
>  configuration instead of calling /usr/sbin/sendmail, sure, but the
>  system administrators are much better off if the applications call
>  /usr/sbin/sendmail and $whatever implementation handles that.
>
>  This is not a packaging matter of adding Requires:/usr/sbin/sendmail -
>  we get the benefit of centralization only if applications support
>  /usr/sbin/sendmail , and have it configured as the default.  Removing
>  a provider of /usr/sbin/sendmail from the default installation
>  entirely makes both of these application design choices problematic
>  and unlikely.
>       Mirek 

Agreed.  An MTA is an important component of *nix systems.

Sendmail stays in Default unless there is compelling reason to switch to
postfix, exim, meta1, etc.  Those users who wish to remove it are welcome
to do so.  Nobody is stopping them. The default configuration of sendmail
poses no problem to users who are unaware of it.

A better option than its removal would be its configuration during install,
which is currently not supported in the installer.  A during-install
installer 'spoke' could be added to support this in the same way root
password is handled today.  Additionally, on a user's first login, they
could be prompted for their preference in how they receive locally
originated messages.

Please voice yourself at meetings in #fedora-devel if this is important to
you.

[Miloslav Trmač]

On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook <billycrook(a)gmail.com&gt; wrote:
>  Please voice yourself at meetings in #fedora-devel if this is
> important to
>  you. 
(Speaking purely for myself and not for other FESCo members,) I do
want to hear from Fedora contributors - but I'd much rather hear on
the mailing list (where messages arrive over the course of a week or
more) rather than during the FESCo meeting (when we have only a few
minutes to agree on a decision, and already frequently have two or
three parallel subconversations).
    Mirek

[Bill Nottingham]

Miloslav Trmač (mitr(a)volny.cz) said: 
>  On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook
> <billycrook(a)gmail.com&gt; wrote:
>  > Please voice yourself at meetings in #fedora-devel if this is important to
>  > you.
>  
>  (Speaking purely for myself and not for other FESCo members,) I do
>  want to hear from Fedora contributors - but I'd much rather hear on
>  the mailing list (where messages arrive over the course of a week or
>  more) rather than during the FESCo meeting (when we have only a few
>  minutes to agree on a decision, and already frequently have two or
>  three parallel subconversations). 
I agree with this statement.

In terms of this feature as presented, I'm not seeing why having $MTA in the
minimal install where you need the installer to have a required configury
step for it is a proper use of everyone's time that's installing it.
Enterprise administrators are almost certainly pushing out their own
configurations directly via puppet/chef/ansible/etc. Desktop users are
primarily doing it as part of their MUA setup, or just using webmail.

It's not as if the default MTA configuration, as I understand it (no smart
host, attempt to send all mail directly with the FQDN) is generally useful
OOTB.

Bill

[Billy Crook]

On Jul 19, 2013 2:16 PM, "Bill Nottingham" <notting(a)redhat.com&gt; wrote:
>  Miloslav Trmač (mitr(a)volny.cz) said:
>  > On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook <billycrook(a)gmail.com&gt;
wrote:
>  > > Please voice yourself at meetings in #fedora-devel if this
> is 
important to
>  > > you.
>  >
>  > (Speaking purely for myself and not for other FESCo members,) I do
>  > want to hear from Fedora contributors - but I'd much rather hear on
>  > the mailing list (where messages arrive over the course of a week or
>  > more) rather than during the FESCo meeting (when we have only a few
>  > minutes to agree on a decision, and already frequently have two or
>  > three parallel subconversations).
>
>  I agree with this statement.
>
>  In terms of this feature as presented, I'm not seeing why having $MTA in 
the
>  minimal install where you need the installer to have a required
> configury
>  step for it is a proper use of everyone's time that's installing it.
>  Enterprise administrators are almost certainly pushing out their own
>  configurations directly via puppet/chef/ansible/etc. Desktop users are
>  primarily doing it as part of their MUA setup, or just using webmail.
>
>  It's not as if the default MTA configuration, as I understand it (no smart
>  host, attempt to send all mail directly with the FQDN) is generally useful
>  OOTB. 
It is to me, and I suspect I am not alone.

[Adam Williamson]

On Fri, 2013-07-19 at 14:23 -0500, Billy Crook wrote:

>  > It's not as if the default MTA configuration, as I
> understand it (no
>  smart
>  > host, attempt to send all mail directly with the FQDN) is generally
>  useful
>  > OOTB.
>  
>  It is to me, and I suspect I am not alone. 
I call bullshit. How is it useful to you? All it can possibly do is
deliver mail to root and users in /var/spool . We don't set up any mail
reader to read this mail out of the box. No app is very likely to know
your user name and send mail to you. The only practical thing you can do
with the OOTB sendmail configuration is manually read or configure an
agent to read the mail in root's /var/spool directory - and that is not
the recommended way to read root's mail _anyway_, the recommended way is
to alias root to a user account.

Sorry, but I am firmly on the 'this is a mechanism from the 1980s' side
of the argument. I run my own mail server, ground up. It makes me feel
all old-school geeky. I am one of a minority of about 0.0001% in the
world these days, and I don't even use sendmail anyway. It's just
ludicrous that we have it in @core. Rip it out, now.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Nicolas Mailhot]

Le Sam 20 juillet 2013 00:46, Adam Williamson a écrit :
>  On Fri, 2013-07-19 at 14:23 -0500, Billy Crook wrote:
>
> > > It's not as if the default MTA configuration, as I understand it (no
> > smart
> > > host, attempt to send all mail directly with the FQDN) is generally
> > useful
> > > OOTB.
> >
> > It is to me, and I suspect I am not alone.
>
>  I call bullshit. How is it useful to you? All it can possibly do is
>  deliver mail to root and users in /var/spool . We don't set up any mail
>  reader to read this mail out of the box. No app is very likely to know
>  your user name and send mail to you. The only practical thing you can do
>  with the OOTB sendmail configuration is manually read or configure an
>  agent to read the mail in root's /var/spool directory - and that is not
>  the recommended way to read root's mail _anyway_, the recommended way is
>  to alias root to a user account. 
And the recommended way is trivial (even though anaconda should really set
up the alias at install time)

What won't be trivial *at* *all* is if you encourage app authors to invent
their own one-of-a-kind not-really-tested communication stack. God knows
they are already leaning towards wheel reinventing without any such system
blessing.

Set up your own replacement. Make it good, secure and easy to operate.
Have it widely adopted. And then you can talk about removing the default
MTA. If it's good enough you have nothing to fear about MTA competition.
If you do need MTA removal to get your stuff adopted, well, that only
tells me your stuff is crap.

-- 
Nicolas Mailhot

[Matthew Miller]

On Sat, Jul 20, 2013 at 04:58:50PM +0200, Nicolas Mailhot wrote:
>  What won't be trivial *at* *all* is if you encourage app authors
> to invent
>  their own one-of-a-kind not-really-tested communication stack. God knows
>  they are already leaning towards wheel reinventing without any such system
>  blessing. 
Fortunately, no one is encouraging any such thing.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Adam Williamson]

On Sat, 2013-07-20 at 16:58 +0200, Nicolas Mailhot wrote:
>  Le Sam 20 juillet 2013 00:46, Adam Williamson a écrit :
>  > On Fri, 2013-07-19 at 14:23 -0500, Billy Crook wrote:
>  >
>  >> > It's not as if the default MTA configuration, as I understand it (no
>  >> smart
>  >> > host, attempt to send all mail directly with the FQDN) is generally
>  >> useful
>  >> > OOTB.
>  >>
>  >> It is to me, and I suspect I am not alone.
>  >
>  > I call bullshit. How is it useful to you? All it can possibly do is
>  > deliver mail to root and users in /var/spool . We don't set up any mail
>  > reader to read this mail out of the box. No app is very likely to know
>  > your user name and send mail to you. The only practical thing you can do
>  > with the OOTB sendmail configuration is manually read or configure an
>  > agent to read the mail in root's /var/spool directory - and that is not
>  > the recommended way to read root's mail _anyway_, the recommended way is
>  > to alias root to a user account.
>  
>  And the recommended way is trivial (even though anaconda should really set
>  up the alias at install time)
>  
>  What won't be trivial *at* *all* is if you encourage app authors to invent
>  their own one-of-a-kind not-really-tested communication stack. God knows
>  they are already leaning towards wheel reinventing without any such system
>  blessing.
>  
>  Set up your own replacement. Make it good, secure and easy to operate.
>  Have it widely adopted. And then you can talk about removing the default
>  MTA. If it's good enough you have nothing to fear about MTA competition.
>  If you do need MTA removal to get your stuff adopted, well, that only
>  tells me your stuff is crap. 
You seem to be chasing an argument I've never seen anyone produce
before, without a single shred of concrete evidence to back it up: that
the presence or absence of a non-functioning MTA by default in a single
Linux distribution will significantly affect the likelihood of an app
choosing to use local mail delivery as a standard notification
mechanism. Could you please, before pushing this line of reasoning any
further, produce some shred of evidence to substantiate it?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Nicolas Mailhot]

Le Sam 20 juillet 2013 17:43, Adam Williamson a écrit :

>  You seem to be chasing an argument I've never seen anyone
> produce
>  before, without a single shred of concrete evidence to back it up: that
>  the presence or absence of a non-functioning MTA by default in a single
>  Linux distribution will significantly affect the likelihood of an app
>  choosing to use local mail delivery as a standard notification
>  mechanism. Could you please, before pushing this line of reasoning any
>  further, produce some shred of evidence to substantiate it? 
Hypothesys 1: developers read the fucking manual
Hypothesys 2: whatever's is in theirs Linux system at any moment
represents their view of the Linux state

Make your choice
-- 
Nicolas Mailhot

[Adam Williamson]

On Sat, 2013-07-20 at 18:28 +0200, Nicolas Mailhot wrote:
>  Le Sam 20 juillet 2013 17:43, Adam Williamson a écrit :
>  
>  > You seem to be chasing an argument I've never seen anyone produce
>  > before, without a single shred of concrete evidence to back it up: that
>  > the presence or absence of a non-functioning MTA by default in a single
>  > Linux distribution will significantly affect the likelihood of an app
>  > choosing to use local mail delivery as a standard notification
>  > mechanism. Could you please, before pushing this line of reasoning any
>  > further, produce some shred of evidence to substantiate it?
>  
>  Hypothesys 1: developers read the fucking manual
>  Hypothesys 2: whatever's is in theirs Linux system at any moment
>  represents their view of the Linux state
>  
>  Make your choice 
I asked for evidence, not hypotheses. All you are currently doing is
making an assertion, over and over and over and over again. New
instances of the assertion do not increase its strength. You have made
your point: either back it up, extend it, or stop repeating it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Nicolas Mailhot]

Le Sam 20 juillet 2013 21:14, Adam Williamson a écrit :

>  I asked for evidence, not hypotheses. All you are currently doing is
>  making an assertion, over and over and over and over again. 
Pot, kettle

I'll add another one: desktop people have complained for years just like
you it was a legacy system and surely "something better" should replace
it. Yet the "something better" never materialized. When I had a disk go
wrong lately I was notified by the big ugly legacy system. I had *zero*
notification by all the "better" systems that were given as
"evidence".
Because the "better" systems do not exist. None of the 'smtpd is
legacy"
complainers have actually tried to solve the (remote) notification
problem, none of them actually understand the reliability and operational
constrains, or that being to define message routing (via aliases,
procmailrc, sieve, etc) and having solid queuing is integral to the
messaging stack fitness. Indeed the sole contribution to the notification
question by our default desktop has been to hide notifications since it
didn't really know what to do with them (and systemd killed the applet
that used to warn users when a service failed at startup)

So please do come back when there is some actual tangible progress on this
front.

-- 
Nicolas Mailhot

[drago01]

On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Sam 20 juillet 2013 21:14, Adam Williamson a écrit :
>
> > I asked for evidence, not hypotheses. All you are currently doing is
> > making an assertion, over and over and over and over again.
>
>  Pot, kettle
>
>  I'll add another one: desktop people have complained for years just like
>  you it was a legacy system and surely "something better" should replace
>  it. Yet the "something better" never materialized. When I had a disk go
>  wrong lately I was notified by the big ugly legacy system. I had *zero*
>  notification by all the "better" systems that were given as
> "evidence". 
That's good for you but most user wouldn't even have noticed the mail.

[Nicolas Mailhot]

Le Dim 21 juillet 2013 09:17, drago01 a écrit :
>  On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> >
> > Le Sam 20 juillet 2013 21:14, Adam Williamson a écrit :
> >
> >> I asked for evidence, not hypotheses. All you are currently doing is
> >> making an assertion, over and over and over and over again.
> >
> > Pot, kettle
> >
> > I'll add another one: desktop people have complained for years just like
> > you it was a legacy system and surely "something better" should replace
> > it. Yet the "something better" never materialized. When I had a disk go
> > wrong lately I was notified by the big ugly legacy system. I had *zero*
> > notification by all the "better" systems that were given as
> "evidence".
>
>  That's good for you but most user wouldn't even have noticed the mail. 
Then make something better. Removing the system you feel is not good
enough is not making something better, it's hoping for someone else to
scratch your hitch.
-- 
Nicolas Mailhot

[Matthew Miller]

On Sun, Jul 21, 2013 at 11:20:27AM +0200, Nicolas Mailhot wrote:
>  Then make something better. Removing the system you feel is not good
>  enough is not making something better, it's hoping for someone else to
>  scratch your hitch. 
I don't think this hyperbole is useful to the conversation. First, no one is
suggesting getting rid of e-mail. Second, the move to remove it sendmail
from default actually _because_ those things exist; "hoping for someone
else" is not part of the motivation.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Steve Clark]

On 07/21/2013 03:17 AM, drago01 wrote:
>  On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> > Le Sam 20 juillet 2013 21:14, Adam Williamson a écrit :
> >
> >> I asked for evidence, not hypotheses. All you are currently doing is
> >> making an assertion, over and over and over and over again.
> > Pot, kettle
> >
> > I'll add another one: desktop people have complained for years just like
> > you it was a legacy system and surely "something better" should replace
> > it. Yet the "something better" never materialized. When I had a disk go
> > wrong lately I was notified by the big ugly legacy system. I had *zero*
> > notification by all the "better" systems that were given as
> "evidence".
>  That's good for you but most user wouldn't even have noticed the mail.
Where are your statistics to back up that wild assertion.

-- 
Stephen Clark
*NetWolves*
Director of Technology
Phone: [phone]
Fax: [phone]
Email: steve.clark(a)netwolves.com
http://www.netwolves.com

[Matthew Miller]

On Sun, Jul 21, 2013 at 08:58:39AM +0200, Nicolas Mailhot wrote:
>  it. Yet the "something better" never materialized. When I
> had a disk go
>  wrong lately I was notified by the big ugly legacy system. I had *zero*
>  notification by all the "better" systems that were given as
> "evidence".
>  Because the "better" systems do not exist. None of the 'smtpd is
> legacy"
>  complainers have actually tried to solve the (remote) notification
>  problem, none of them actually understand the reliability and operational
>  constrains, or that being to define message routing (via aliases, 
Sure they do. I can't imagine an installation of any size (eg more than 2
systems) not using Nagios, Icigna, or some other alerting system.

If you're in the narrow case between a desktop system and an installation
where real monitoring and alerting is worth it, install an MTA.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Reindl Harald]

Am 21.07.2013 16:05, schrieb Matthew Miller:
>  On Sun, Jul 21, 2013 at 08:58:39AM +0200, Nicolas Mailhot wrote:
> > it. Yet the "something better" never materialized. When I had a disk go
> > wrong lately I was notified by the big ugly legacy system. I had *zero*
> > notification by all the "better" systems that were given as
> "evidence".
> > Because the "better" systems do not exist. None of the 'smtpd is
> legacy"
> > complainers have actually tried to solve the (remote) notification
> > problem, none of them actually understand the reliability and operational
> > constrains, or that being to define message routing (via aliases,
>  
>  Sure they do. I can't imagine an installation of any size (eg more than 2
>  systems) not using Nagios, Icigna, or some other alerting system.
>  
>  If you're in the narrow case between a desktop system and an installation
>  where real monitoring and alerting is worth it, install an MTA 
the problem i see is when things like MTA and rsyslog are
removed from the defualt install many pakcgers will less
care about them in the future nor test how well it works

if here is not taken really care over the long the capability
write wahtever shellscript for a cronjob and whatever goes
wrong echo it simply to produce a notify mail may disappear
as well as such outputs can be large and are not for the journal

[Matthew Miller]

On Sun, Jul 21, 2013 at 04:09:32PM +0200, Reindl Harald wrote:
>  the problem i see is when things like MTA and rsyslog are
>  removed from the defualt install many pakcgers will less
>  care about them in the future nor test how well it works 
That's a separate issue. MTAs and syslog are going to be needed for many
very important use cases for years to come. That doesn't mean we need to
install them by default. Apache, PostgresQSL, and may other important
servers aren't installed by default. For that matter, Postfix and Exim
aren't installed by default. We can still care about them -- as Fedora or in
general -- without putting them on every system whether it makes sense or
not.



-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Reindl Harald]

Am 21.07.2013 21:20, schrieb Matthew Miller:
>  On Sun, Jul 21, 2013 at 04:09:32PM +0200, Reindl Harald wrote:
> > the problem i see is when things like MTA and rsyslog are
> > removed from the defualt install many pakcgers will less
> > care about them in the future nor test how well it works
>  
>  That's a separate issue. MTAs and syslog are going to be needed for many
>  very important use cases for years to come 
but it is how things are started

first the are not handeled with care at all
second nobody can rely on that they are there
third they get declared as obsoloete from people which not understand their usefullnes
fourth they are not supported by new applications because they are not always there

[Miloslav Trmač]

On Sun, Jul 21, 2013 at 9:20 PM, Matthew Miller <mattdm(a)mattdm.org&gt; wrote:
>  On Sun, Jul 21, 2013 at 04:09:32PM +0200, Reindl Harald wrote:
> > the problem i see is when things like MTA and rsyslog are
> > removed from the defualt install many pakcgers will less
> > care about them in the future nor test how well it works
>
>  That's a separate issue. MTAs and syslog are going to be needed for many
>  very important use cases for years to come. That doesn't mean we need to
>  install them by default. 
It's not really separate.

We don't have any canonical developer documentation that says what is
or isn't a part of the OS, and "good" Linux applications are expected
to use; we only have traditions, word of mouth, and de-facto
standards. In this situation, what is or isn't enabled by default and
shipped by default matters more than saying "are going to be needed
for years to come" - the actions speak louder than the words.

Think of these debates as attempts to, after all the years, agree on
and write down what the traditions and de-facto standards actually
are.
    Mirek

[Lennart Poettering]

On Mon, 22.07.13 16:04, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  On Sun, Jul 21, 2013 at 9:20 PM, Matthew Miller
> <mattdm(a)mattdm.org&gt; wrote:
>  > On Sun, Jul 21, 2013 at 04:09:32PM +0200, Reindl Harald wrote:
>  >> the problem i see is when things like MTA and rsyslog are
>  >> removed from the defualt install many pakcgers will less
>  >> care about them in the future nor test how well it works
>  >
>  > That's a separate issue. MTAs and syslog are going to be needed for many
>  > very important use cases for years to come. That doesn't mean we need to
>  > install them by default.
>  
>  It's not really separate.
>  
>  We don't have any canonical developer documentation that says what is
>  or isn't a part of the OS, and "good" Linux applications are expected
>  to use; we only have traditions, word of mouth, and de-facto
>  standards. In this situation, what is or isn't enabled by default and
>  shipped by default matters more than saying "are going to be needed
>  for years to come" - the actions speak louder than the words.
>  
>  Think of these debates as attempts to, after all the years, agree on
>  and write down what the traditions and de-facto standards actually
>  are.
>      Mirek 
If you argue from the viewpoint of how universially available an API is
to make it "standard", then I would like to remind you that there are
probably more Ubuntu installations in the world thatn Fedora
installations, and they haven't included any MTA by default in 6 years
or so.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Oron Peled]

On Monday 22 July 2013 21:00:36 Lennart Poettering wrote:
>  If you argue from the viewpoint of how universially available an API
> is
>  to make it "standard", then I would like to remind you that there are
>  probably more Ubuntu installations in the world thatn Fedora
>  installations, and they haven't included any MTA by default in 6 years
>  or so. 
Finally I know what I was missing all these years ;-)

[sorry, it was just too good, though you have a valid point]

BTW: nobody ever answered how desktop users are supposed to read the
     output of their cron-jobs (they don't have permissions to read logs).

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"write your own operating system.  It has worked every time for me"
           -- Linus Thorvalds

[Matthew Miller]

On Tue, Jul 23, 2013 at 03:14:32AM +0300, Oron Peled wrote:
>  BTW: nobody ever answered how desktop users are supposed to read the
>       output of their cron-jobs (they don't have permissions to read logs). 
They do have permissions to read journal entries that come from their
userid. 

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Oron Peled]

On Monday 22 July 2013 20:18:04 Matthew Miller wrote:
>  On Tue, Jul 23, 2013 at 03:14:32AM +0300, Oron Peled wrote:
>  > BTW: nobody ever answered how desktop users are supposed to read the
>  > 
>  >      output of their cron-jobs (they don't have permissions to read logs).
>  
>  They do have permissions to read journal entries that come from their
>  userid. 
1. Thanks, I've seen Lennart's reply regarding this in a separate sub-thread
   (boy, it's getting hard to follow this topic)

2. But as I've shown in my reply to him, cron-jobs output is not logged
   to this "personal" log, but rather to the system-wide log which isn't
   readable by regular users.

So although the "per-user" syslog feature is really good, it doesn't
apply to the case at hand.

Do you have a real (i.e: working) solution for users to read the
output of their own cron-jobs (besides mail of course).

Without this, you propose to cut an important functionality from
almost everyone (default).

Instead, let's remove MTA from *minimal* install, but not from *default*.

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"Normally the saying is: 'Fast, Reliable, Cheap. Pick any two.' But with
Linux you can pick all three!"
        --from a Slashdot post

[Lennart Poettering]

On Tue, 23.07.13 03:14, Oron Peled (oron(a)actcom.co.il) wrote:

>  On Monday 22 July 2013 21:00:36 Lennart Poettering wrote:
>  > If you argue from the viewpoint of how universially available an API is
>  > to make it "standard", then I would like to remind you that there are
>  > probably more Ubuntu installations in the world thatn Fedora
>  > installations, and they haven't included any MTA by default in 6 years
>  > or so.
>  
>  Finally I know what I was missing all these years ;-)
>  
>  [sorry, it was just too good, though you have a valid point]
>  
>  BTW: nobody ever answered how desktop users are supposed to read the
>       output of their cron-jobs (they don't have permissions to read logs). 
Actually, if you'd look closely it has been answered 3 times now,
already, just on this thread.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Oron Peled]

On Tuesday 23 July 2013 02:34:25 Lennart Poettering wrote:
>  On Tue, 23.07.13 03:14, Oron Peled (oron(a)actcom.co.il) wrote:
>  > BTW: nobody ever answered how desktop users are supposed to read the
>  >      output of their cron-jobs (they don't have permissions to read logs).
>  Actually, if you'd look closely it has been answered 3 times now,
>  already, just on this thread. 
This turned out into a huge forest of Q&A. I've read your reply to my other 
mail, just after sending my "BTW:..." reply to another -- sorry.

However, if you've read my response you know the question wasn't really 
answered -- regular users only access to the output of their cron-jobs
is still via email. Cron currently logs the output to the system-wide
syslog which isn't accessible to regular users (just try it yourself
I've tested it on F19).

So as I've replied Matthew Miller few minutes ago: do you have
a real (working) solution for this? If not, it's premature
to remove MTA's from default install.

That's without even touching the totally different use-cases for
logs and email in general.

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"In theory, there is no difference between theory and practice.
 In practice, there is."
        -- Yogi Berra

[Lennart Poettering]

On Sun, 21.07.13 16:09, Reindl Harald (h.reindl(a)thelounge.net) wrote:

>  
>  Am 21.07.2013 16:05, schrieb Matthew Miller:
>  > On Sun, Jul 21, 2013 at 08:58:39AM +0200, Nicolas Mailhot wrote:
>  >> it. Yet the "something better" never materialized. When I had a disk
> go
>  >> wrong lately I was notified by the big ugly legacy system. I had *zero*
>  >> notification by all the "better" systems that were given as
> "evidence".
>  >> Because the "better" systems do not exist. None of the 'smtpd is
> legacy"
>  >> complainers have actually tried to solve the (remote) notification
>  >> problem, none of them actually understand the reliability and operational
>  >> constrains, or that being to define message routing (via aliases,
>  > 
>  > Sure they do. I can't imagine an installation of any size (eg more than 2
>  > systems) not using Nagios, Icigna, or some other alerting system.
>  > 
>  > If you're in the narrow case between a desktop system and an installation
>  > where real monitoring and alerting is worth it, install an MTA
>  
>  the problem i see is when things like MTA and rsyslog are
>  removed from the defualt install many pakcgers will less
>  care about them in the future nor test how well it works 
This is not a valid argument. We cannot keep extending the core all the
time by adding more and more redundant components to them, just because
we believe this will cause APIs to be tested. It's the wrong approach in
every way. As we all know the current sendmail setup means mails are
lost in a /dev/null-like mail spool nobody reads. So we know right now
that the current situation is certainly really broken. What have we done
so far about it? Just ignored it, and continued to let the mail spools
run over with mails that are ignored. The few people who cared didn't
mind because they were the ones who reconfigured the aliases file or the
entire MTA in a way that actually made it useful. But that's a pretty
borked situation and unfair to everybody not in the know...

You get your stuff well-tested by removing redundancy, by making your
stuff interesting to people and by making sure people who care test
it. It's not enough just put on a system where nobody cares about it. It
didn't fix the local MTA situation in the past 10 years and it won't in
the next.

Also, what kind of a picture does this paint of the Fedora project
anyway? Only stuff we install by default matters and is tested? If that
was the case the only answer could be to drop all
non-installed-by-default packages from the dirstro... - but that would
just be so wrong....

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Nicolas Mailhot]

Le Lun 22 juillet 2013 20:52, Lennart Poettering a écrit :

>  This is not a valid argument. We cannot keep extending the core all
> the
>  time by adding more and more redundant components to them, just because
>  we believe this will cause APIs to be tested. 
No one is asking to extend the core. You are asking to redefine it that's
not the same.

>  Also, what kind of a picture does this paint of the Fedora project
>  anyway? Only stuff we install by default matters and is tested? 
Not configuring what we install does not paint a good image of the
project. OTOH, the MTAs themselves are several orders of magnitude more
robust than all the other bits we install (including, right now, systemd).
So the picture is clearly mixed.

-- 
Nicolas Mailhot

[Billy Crook]

On Mon, Jul 22, 2013 at 11:41 AM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Fri, 19.07.13 13:17, Billy Crook (billycrook(a)gmail.com) wrote:
> > Sendmail stays in Default unless there is compelling reason to switch to
> > postfix, exim, meta1, etc.  Those users who wish to remove it are welcome
> > to do so.  Nobody is stopping them. The default configuration of sendmail
> > poses no problem to users who are unaware of it.
>
>  Not true. I eats my cron logs and other stuff and I have no way to get
>  the stuff out of it again with the core install... 
If that's not hyperbole, then please clarify what "eats" refers to.
Or just take the 30 seconds or so to setup the MTA correctly, and all
of that stuff will be waiting for you in your inbox.  If you don't
want it mixed with human-originated mail, as some have complained,
then use filters to auto sort your mail.


> > Please voice yourself at meetings in #fedora-devel if this is
> important to
> > you.
>
>  Yes, please, post a lot of "+1" messages. They contribute so positively
>  (I mean, literally!) to any discussion. "+1" messages are really good
>  for making a point as they contain so much additional arguments nobody
>  has heard or read before. It's almost as constructive posting "+1"s, as
>  it is posting sarcastic comments about their pointlessness... 
There's not much else to do when it seems a lot of otherwise very
intelligent people still don't get it.  I'm certain that you are all
aware of how useful an MTA can be.  Choosing to cut it off rather than
properly configuring it, is rather un-fedora-like.  Why not remove
ipv6 support, since gosh it's hard too and who configures it?  And it
doesn't work for most people without explicit configuration.

Removing it (even just from the Default install) is wrong.


On Mon, Jul 22, 2013 at 12:28 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  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? You suggested earlier that I dislike cron's e-mail
>  output, and while I hadn't brought up likes or dislikes before, I really
>  don't find it so great. To me, it just fills up my mailbox with:
>
>     Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3 run-parts /etc/cro
>     Jul 02 Anacron            Anacron job 'cron.daily' on bigcomputer.home.
...
>     Jul 02 Cron Daemon        Cron <root@hpc> ionice -c3
> run-parts /etc/cro
>
>  If I did want e-mail output -- which I used to, before I had proper alerting
>  set up, so as I mentioned before I totally recognize that use case -- I
>  really would like it with a meaningful subject line, which means even when
>  running out of cron, the jobs should actually call sendmail or /usr/bin/mail
>  directly with pretty-formatted output. (And thus, have an explicit
>  dependency on an MTA, and also basically have the expectation that they're
>  running on a system which will be properly configured for its environment,
>  however that happens.) 
If you are getting a message from a cronjob, it is a pretty good
indicator that something went wrong, and you need to take action to
correct it.  So yes.  It's pretty important.    Depending on cronjobs
to send notifications on their own failures, is poor design because if
they have failed, they could easily fail to notify.  This is why
cron's (albeit ugly) notifications when a job turns up stdout/err, are
valuable.


On Mon, Jul 22, 2013 at 1:58 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  I do not
>  think cron jobs that output something every time they are run just in case
>  are nice. 
I agree.  Those are usually, crappy cronjobs and should be fixed to
work like most unix tools, and output only on failure.

>  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. 
EXACTLY.  Improving the INSTALLER and firstlogin experience is what is
needed here, NOT removing MTA.

>  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. 
This is another area to improve.  Again NOT removing MTA, but using it smarter.

>  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.
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Mail has its faults, but is the best option that is universally
available.  Let's build upon it rather than abandoning it.

i.e.: If message authentication is a concern, the system should sign
the messages before sending.


On Mon, Jul 22, 2013 at 2:00 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  If you argue from the viewpoint of how universially available an API
> is
>  to make it "standard", then I would like to remind you that there are
>  probably more Ubuntu installations in the world thatn Fedora
>  installations, and they haven't included any MTA by default in 6 years
>  or so. 
Good to know.  I see not how that is relevant.  If anything, knowing
that only further demonstrates what a horrific idea No Default MTA is.


On Mon, Jul 22, 2013 at 2:15 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le Lun 22 juillet 2013 20:52, Lennart Poettering a écrit :
>
> > This is not a valid argument. We cannot keep extending the core all the
> > time by adding more and more redundant components to them, just because
> > we believe this will cause APIs to be tested.
>
>  No one is asking to extend the core. You are asking to redefine it that's
>  not the same.
>
> > Also, what kind of a picture does this paint of the Fedora project
> > anyway? Only stuff we install by default matters and is tested?
>
>  Not configuring what we install does not paint a good image of the
>  project. OTOH, the MTAs themselves are several orders of magnitude more
>  robust than all the other bits we install (including, right now, systemd). 
I would love to see the day systemd is as polished, ubiquitous, and
robust as smtp.  But until that happens, nobody is helped by removing
MTA from the default install.  We're not there yet, and theres no
guarantee we ever will be.  Init systems come and go every few years.
Sendmail and MTAs in general have been around to witness them all.
SMTP has been around longer than Linux, and it will still be in use
when systemd is obsoleted by the next big thing.

[Olav Vitters]

On Mon, Jul 22, 2013 at 03:13:28PM -0500, Billy Crook wrote:
>  I would love to see the day systemd is as polished, ubiquitous, and
>  robust as smtp.  But until that happens, nobody is helped by removing
>  MTA from the default install.  We're not there yet, and theres no 
systemd and SMTP are not related. This kind of argument is just stop
energy.

-- 
Regards,
Olav

[Billy Crook]

On Tue, Jul 23, 2013 at 7:32 AM, Olav Vitters <olav(a)vitters.nl&gt; wrote:
>  On Mon, Jul 22, 2013 at 03:13:28PM -0500, Billy Crook wrote:
> > I would love to see the day systemd is as polished, ubiquitous, and
> > robust as smtp.  But until that happens, nobody is helped by removing
> > MTA from the default install.  We're not there yet, and theres no
>
>  systemd and SMTP are not related. This kind of argument is just stop
>  energy. 
No.  You are wrong.  When Sendmail is on the chopping block because
"let's just send anything that should get mailed, to systemd instead,
and let it pop up pretty graphical bubbles because nobody reads mail
anyways", the two are very much related in the context of this thread.

Clever as it was to frame the attempted deprecation of sendmail and
syslog as separate issues, I think most people can see right through
it.  I know I can.

systemd is great, but it's not a golden hammer, and its existence
doesn't render all other software obsolete.

I remain stunned to see this many people in this forum, so desperate
to get rid of them in the default install -- so eager to follow the
latest fad.

This is not the time to remove sendmail.  This is the time to use it
properly.  This is the time for it to get configured properly during
install.  Frankly after so many years of having to set it up by hand
on Fedora, I'm quite ready to see it in the default installer.  It
should always have been there.  It's absence in the installer is why
certain people perceive sendmail to not be useful.  I use it a good
dozen or so times a day NOT even counting cronjobs and automated
sending.  Having a local MTA on every machine enables deeper
asynchronous workflow on an organizational scale.

Sendmail or otherwise, an MTA BELONGS in Default.

[Martin Langhoff]

On Tue, Jul 23, 2013 at 10:10 AM, Billy Crook <billycrook(a)gmail.com&gt; wrote:
>  Sendmail or otherwise, an MTA BELONGS in Default. 
There is no consensus on that, at all. Very successful competitors to
Fedora have removed it, and their users are happy.



m
--
 martin.langhoff(a)gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

[Fulko Hew]

On Tue, Jul 23, 2013 at 10:19 AM, Martin Langhoff <martin.langhoff(a)gmail.com
>  wrote: 
> On Tue, Jul 23, 2013 at 10:10 AM, Billy Crook <billycrook(a)gmail.com&gt;
>  wrote: 
> > Sendmail or otherwise, an MTA BELONGS in
Default.
>
> There is no consensus on that, at all. Very successful competitors to
> Fedora have removed it, and their users are happy.
>

Those 'successful competitors' are probably being used in a
limited-requirement mode; like a 'single-user personal workstation'.
In those environments an MTA probably isn't (really) needed because an
MUA is probably all that's used... or all that the human 'thinks' they need.

But, personally, I agree with  [e-mail]...
On the servers I run, and the server applications I've written,
the use of email is mandatory and the use of an MTA is the
best, most-efficient way to deal with the email.
I say... servers should definitely have a default MTA.

We shouldn't confuse the need/use of an MTA with that of cron, syslog or
journald.
They're purposes do not overlap.

[Matthew Miller]

On Tue, Jul 23, 2013 at 10:57:15AM -0400, Fulko Hew wrote:
>  But, personally, I agree with  [e-mail]...
>  On the servers I run, and the server applications I've written,
>  the use of email is mandatory and the use of an MTA is the
>  best, most-efficient way to deal with the email. 
None of this is in conflict with the proposal to not install sendmail
everywhere.

>  I say... servers should definitely have a default MTA. 
We've never had any luck defining what a Fedora server looks like. That's
why I think it's better to have servers start from minimal and you can build
up in kickstart. There, you _probably_ want Postfix or Exim instead of
Sendmail, and it's easier if we haven't preselected something.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Nicolas Mailhot]

Le Mar 23 juillet 2013 17:05, Matthew Miller a écrit :

> > I say... servers should definitely have a default MTA.
>
>  We've never had any luck defining what a Fedora server looks like. That's
>  why I think it's better to have servers start from minimal and you can
>  build
>  up in kickstart. There, you _probably_ want Postfix or Exim instead of
>  Sendmail, and it's easier if we haven't preselected something. 
Look, the proposal is not calling to replace sendmail, it's calling to
remove any MTA. So "sendmail is a bad MTA" is not a good argument for this
proposal. "sendmail is a bad MTA" is an argument to install Postfix or
Exim by default, not to remove the default MTA. And it's way easier to
replace the MTA in a distro built around an MTA that to add an MTA on a
distro where people stopped caring about MTA compatibility since it became
an optional component

Though anyway, +1 to use postfix by default like Suse

-- 
Nicolas Mailhot

[Billy Crook]

On Tue, Jul 23, 2013 at 10:51 AM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Jul 23, 2013 at 10:18:47AM -0500, Billy Crook wrote:
> > > Since it _isn't_ served via DHCP in any environment I'm aware of,
> that's not
> > > actually useful.
> > Nice to meet you Matt.  As of this morning, it is served via DHCP in
> > mine.  There's also that guy earlier in the thread.  So now you know
> > of two.  Perhaps that dhcp option ought to be in the packaged
> > dhcpd.conf template.
>
>  You've totally removed the context here. Which cloud environment do you run? 
Actually I'm afraid your cloud environment example is just as far out
of context.  I can't imagine many cloud deployments that don't use
kickstarts and have their own individually chosen packageset tuned for
exactly their business case.  They can use core / minimal +  whatever
specific individual packages they need.  I hardly think a cloud
environment is going to base their production on the Default package
set.

Default should include what people 'generally expect of a GNU+Linux
system' -- and that includes an MTA.  It should include a syslog, and
it should include screen too for that matter.

I mentioned DHCP only to demonstrate the fact that you were dismissing
the existence of real environments in which smtp-server is served via
DHCP, _today_.

We should be working towards deterministic, automatic, easy configuration.


On Tue, Jul 23, 2013 at 11:21 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Look, the proposal is not calling to replace sendmail, it's
> calling to
>  remove any MTA. So "sendmail is a bad MTA" is not a good argument for this
>  proposal. "sendmail is a bad MTA" is an argument to install Postfix or
>  Exim by default, not to remove the default MTA. 
I couldn't have said it better.  Most people get it.  If you don't
like ${President}, vote for a better one.  Don't bulldoze the
whitehouse.

[Adam Williamson]

On Tue, 2013-07-23 at 11:52 -0500, Billy Crook wrote:
>  On Tue, Jul 23, 2013 at 10:51 AM, Matthew Miller
>  <mattdm(a)fedoraproject.org&gt; wrote:
>  > On Tue, Jul 23, 2013 at 10:18:47AM -0500, Billy Crook wrote:
>  >> > Since it _isn't_ served via DHCP in any environment I'm aware of,
> that's not
>  >> > actually useful.
>  >> Nice to meet you Matt.  As of this morning, it is served via DHCP in
>  >> mine.  There's also that guy earlier in the thread.  So now you know
>  >> of two.  Perhaps that dhcp option ought to be in the packaged
>  >> dhcpd.conf template.
>  >
>  > You've totally removed the context here. Which cloud environment do you run?
>  
>  Actually I'm afraid your cloud environment example is just as far out
>  of context.  I can't imagine many cloud deployments that don't use
>  kickstarts and have their own individually chosen packageset tuned for
>  exactly their business case.  They can use core / minimal +  whatever
>  specific individual packages they need.  I hardly think a cloud
>  environment is going to base their production on the Default package
>  set. 
sendmail is in @core.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[drago01]

On Tue, Jul 23, 2013 at 6:52 PM, Billy Crook <billycrook(a)gmail.com&gt; wrote:
>  On Tue, Jul 23, 2013 at 10:51 AM, Matthew Miller
>  <mattdm(a)fedoraproject.org&gt; wrote:
> > On Tue, Jul 23, 2013 at 10:18:47AM -0500, Billy Crook wrote:
> >> > Since it _isn't_ served via DHCP in any environment I'm aware of,
> that's not
> >> > actually useful.
> >> Nice to meet you Matt.  As of this morning, it is served via DHCP in
> >> mine.  There's also that guy earlier in the thread.  So now you know
> >> of two.  Perhaps that dhcp option ought to be in the packaged
> >> dhcpd.conf template.
> >
> > You've totally removed the context here. Which cloud environment do you run?
>
>  Actually I'm afraid your cloud environment example is just as far out
>  of context.  I can't imagine many cloud deployments that don't use
>  kickstarts and have their own individually chosen packageset tuned for
>  exactly their business case.  They can use core / minimal +  whatever
>  specific individual packages they need.  I hardly think a cloud
>  environment is going to base their production on the Default package
>  set.
>
>  Default should include what people 'generally expect of a GNU+Linux
>  system' -- and that includes an MTA. 
Citation needed. Given that one very distribution with a very big
userbase don't install an MTA by default ...

[Nicolas Mailhot]

Le Mer 24 juillet 2013 08:30, drago01 a écrit :
>  On Tue, Jul 23, 2013 at 6:52 PM, Billy Crook
> <billycrook(a)gmail.com&gt; wrote: 
> > Default should include what people 'generally expect of a
> GNU+Linux
> > system' -- and that includes an MTA.
>
>  Citation needed. Given that one very distribution with a very big
>  userbase don't install an MTA by default ... 
But does its users expect a GNU+Linux system nowadays?

-- 
Nicolas Mailhot

[Lennart Poettering]

On Tue, 23.07.13 11:52, Billy Crook (billycrook(a)gmail.com) wrote:

>  Default should include what people 'generally expect of a
> GNU+Linux
>  system' -- and that includes an MTA.  It should include a syslog, and
>  it should include screen too for that matter. 
This is the "let's do this out of tradition" argument. It's an awful
argument. Just doing stuff because things were always done that way
essentially boils down to "I hate change". Which is an OK opinion to
have, but certainly not four Fedora, where the four Fs mean "Freedom,
Friends, Features, First". The "First" indicates that we should be
pioneers, and *not* the guys who never change because we are deeply
suspicous of any change that is against "our tradition".

This is particularly a bad argument as most Linux distribution
installations do not include an MTA anymore (Ubuntu is substantially
more popular than Fedora, and not just on the desktop). There's enough
reason to believe that the what people "expect" from a Linux
distribution might be very different these days from what *you* expect
from it. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Nicolas Mailhot]

Le Mer 24 juillet 2013 13:39, Lennart Poettering a écrit :

>  This is particularly a bad argument as most Linux distribution
>  installations do not include an MTA anymore (Ubuntu is substantially
>  more popular than Fedora, and not just on the desktop). There's enough
>  reason to believe that the what people "expect" from a Linux
>  distribution might be very different these days from what *you* expect
>  from it. 
Anyway what people expect is a bad argument fullstop. Microsoft, Google
and Apple didn't grow their userbase by matching their users expectations.
They grew their userbase by exceeding those expectations. So what if in a
traditional windows 3.1 mindset smtp processing had not place on a
desktop? The fact is that mail is a major part of the internet experience
now, and anything that makes mail simpler on Fedora desktops will get us
more marketshare not less.

Just set up mail accounts at install/user creation time and configure our
tools to use the local smtpd server by default. That will make it a
"sending mail just works" distro-wide feature, instead of "we suck so much
at mail we've disabled mail even where it was blatantly useful"
misfeature.

-- 
Nicolas Mailhot

[Frank Ch. Eigler]

Lennart Poettering <mzerqung(a)0pointer.de&gt; writes:

>  [...]  essentially boils down to "I hate change". Which is
> an OK
>  opinion to have, but certainly not four Fedora, where the four Fs
>  mean "Freedom, Friends, Features, First". The "First" indicates that
>  we should be pioneers, and *not* the guys who never change because
>  we are deeply suspicous of any change that is against "our
>  tradition".  [...] 
It's tempting to carry this argument too far.  We can be first with
good new ideas; first with experimental stuff; first with additions.
We need not be first with bad ideas (and discussions here are a way of
figuring out good from bad, let's not beg the question).  We also need
not be first when it comes to subtraction of functionality.

- FChE

[Billy Crook]

On Wed, Jul 24, 2013 at 9:10 AM, Frank Ch. Eigler <fche(a)redhat.com&gt; wrote:
>  It's tempting to carry this argument too far.  We can be first
> with
>  good new ideas; first with experimental stuff; first with additions.
>  We need not be first with bad ideas (and discussions here are a way of
>  figuring out good from bad, let's not beg the question).  We also need
>  not be first when it comes to subtraction of functionality. 
This is exactly, what I'm saying.  Please contribute your vote at the meeting.

[Adam Williamson]

On Wed, 2013-07-24 at 11:14 -0500, Billy Crook wrote:
>  On Wed, Jul 24, 2013 at 9:10 AM, Frank Ch. Eigler
> <fche(a)redhat.com&gt; wrote:
>  > It's tempting to carry this argument too far.  We can be first with
>  > good new ideas; first with experimental stuff; first with additions.
>  > We need not be first with bad ideas (and discussions here are a way of
>  > figuring out good from bad, let's not beg the question).  We also need
>  > not be first when it comes to subtraction of functionality.
>  
>  This is exactly, what I'm saying.  Please contribute your vote at the meeting.
You seem to be operating under a misconception. FESCo members vote.
No-one else does.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Kevin Fenzi]

On Wed, 24 Jul 2013 15:10:05 -0700
Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  On Wed, 2013-07-24 at 11:14 -0500, Billy Crook wrote:
>  > On Wed, Jul 24, 2013 at 9:10 AM, Frank Ch. Eigler <fche(a)redhat.com&gt;
>  > wrote:
>  > > It's tempting to carry this argument too far.  We can be first
>  > > with good new ideas; first with experimental stuff; first with
>  > > additions. We need not be first with bad ideas (and discussions
>  > > here are a way of figuring out good from bad, let's not beg the
>  > > question).  We also need not be first when it comes to
>  > > subtraction of functionality.
>  > 
>  > This is exactly, what I'm saying.  Please contribute your vote at
>  > the meeting.
>  
>  You seem to be operating under a misconception. FESCo members vote.
>  No-one else does. 
To clarify a bit: FESCo members vote, and you vote for FESCo
members. ;) 

kevin

[Dan Mashal]

+1
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Kevin Fenzi <kevin(a)scrye.com&gt;
Sender: devel-bounces(a)lists.fedoraproject.org
Date: Wed, 24 Jul 2013 16:12:03 
To: <devel(a)lists.fedoraproject.org&gt;
Reply-To: Development discussions related to Fedora
	<devel(a)lists.fedoraproject.org&gt;
Subject: Re: F20 System Wide Change: No Default Sendmail

-- 
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Matthew Miller]

On Tue, Jul 23, 2013 at 06:21:45PM +0200, Nicolas Mailhot wrote:
>  Look, the proposal is not calling to replace sendmail, it's
> calling to
>  remove any MTA. So "sendmail is a bad MTA" is not a good argument for this
No, it's *really* not calling to "remove any MTA". It's calling for no
MTA
to be installed by default, or at least not in the minimal install.

The two arguments against this change I hear are:

 * "This is a slipperly slope to the doom of all MTAs". This argument isn't
very
   convincing -- otherwise non-sendmail MTAs would already be dead, as would
   every other server we don't install by default.

 * "An MTA should be part of the base design." This point I'm open to,
   although I think it requires more work than people are willing to
   actually do, and I'd like to see a counter-proposal involving actually
   doing that work.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Chris Adams]

Once upon a time, Matthew Miller <mattdm(a)fedoraproject.org&gt; said:
>  On Tue, Jul 23, 2013 at 06:21:45PM +0200, Nicolas Mailhot wrote:
>  > Look, the proposal is not calling to replace sendmail, it's calling to
>  > remove any MTA. So "sendmail is a bad MTA" is not a good argument for
> this
>  
>  No, it's *really* not calling to "remove any MTA". It's calling for no
> MTA
>  to be installed by default, or at least not in the minimal install.
>  
>  The two arguments against this change I hear are:
>  
>   * "This is a slipperly slope to the doom of all MTAs". This argument isn't
> very
>     convincing -- otherwise non-sendmail MTAs would already be dead, as would
>     every other server we don't install by default.
>  
>   * "An MTA should be part of the base design." This point I'm open to,
>     although I think it requires more work than people are willing to
>     actually do, and I'd like to see a counter-proposal involving actually
>     doing that work. 
I run lots of servers with MTAs, and sendmail in particular (you mean
everybody can't parse and understand lines like this:

R$*+$*@$*	$: $1+$2@$3 $| $>D <$3> <?> <!Spam> <>

without Google? :) ).  I have no problem with no-default-MTA.  An MTA
only works in most cases with additional configuration, and that
configuration will vary widely between setups and MTAs.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Olav Vitters]

On Tue, Jul 23, 2013 at 10:57:15AM -0400, Fulko Hew wrote:
>  But, personally, I agree with  [e-mail]...
>  On the servers I run, and the server applications I've written,
>  the use of email is mandatory and the use of an MTA is the
>  best, most-efficient way to deal with the email.
>  I say... servers should definitely have a default MTA. 
IMO email is terribly crappy way of informing. You get way too many
emails. In any case, as soon as you have more than a few servers, you'll
have some configuration management thing to set things up, e.g. Puppet
or anything similar. I dislike sendmail, prefer Postfix. All of that is
automatic.

-- 
Regards,
Olav

[Billy Crook]

On Tue, Jul 23, 2013 at 10:06 AM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  Since it _isn't_ served via DHCP in any environment I'm aware
> of, that's not
>  actually useful. 
Nice to meet you Matt.  As of this morning, it is served via DHCP in
mine.  There's also that guy earlier in the thread.  So now you know
of two.  Perhaps that dhcp option ought to be in the packaged
dhcpd.conf template.

On Tue, Jul 23, 2013 at 10:09 AM, Olav Vitters <olav(a)vitters.nl&gt; wrote:
>  IMO email is terribly crappy way of informing. You get way too many
>  emails. 
And yet everyone continues to use it.  I bet there's a good reason...

>  In any case, as soon as you have more than a few servers, you'll
>  have some configuration management thing to set things up, e.g. Puppet
>  or anything similar. 
Yes, and it doesn't displace an MTA.

>  I dislike sendmail, prefer Postfix. All of that is
>  automatic. 
I'm much more open to changing the default MTA from sendmail to
something else than just getting rid of the MTA.  I do happen to find
sendmail config particularly sadistic.  I'm sure there are other areas
where more modern MTAs outdo sendmail as well.  dnl:wq

[Matthew Miller]

On Tue, Jul 23, 2013 at 10:18:47AM -0500, Billy Crook wrote:
>  > Since it _isn't_ served via DHCP in any environment I'm
> aware of, that's not
>  > actually useful.
>  Nice to meet you Matt.  As of this morning, it is served via DHCP in
>  mine.  There's also that guy earlier in the thread.  So now you know
>  of two.  Perhaps that dhcp option ought to be in the packaged
>  dhcpd.conf template. 
You've totally removed the context here. Which cloud environment do you run?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Matthew Miller]

On Tue, Jul 23, 2013 at 09:10:00AM -0500, Billy Crook wrote:
>  No.  You are wrong.  When Sendmail is on the chopping block because
>  "let's just send anything that should get mailed, to systemd instead,
>  and let it pop up pretty graphical bubbles because nobody reads mail
>  anyways", the two are very much related in the context of this thread. 
There is no "chopping block", and no proposal to put anything on one if
there were.

>  This is not the time to remove sendmail.  This is the time to use it
>  properly.  This is the time for it to get configured properly during
>  install.  Frankly after so many years of having to set it up by hand 
Okay. I'd be interested in seeing an alternate proposal (including people
lined up to do the work). Proposals like
https://bugzilla.redhat.com/show_bug.cgi?id=143437 (note, from me!) have
been around for years (2004, for that one) but haven't gone anywhere.
Meanwhile, things in the _world_ have gotten worse for this proposal. People
don't read or expect local mail anymore, even on Linux systems. Mail clients
aren't configured to expect it, even when they are local clients rather than
web-based. These things can be solved with some effort, but I don't see
anyone actually working on it. A worse class of problem is that mail from
home broadband providers is likely to just be rejected, and in fact many
networks don't allow unauthenticated outgoing mail at all. That makes the
problem much more complex than it was a decade ago, when any random system
could in fact reasonably be its own mail server.

So, there's some coding to be done to make this alterative proposal work.
Or at the very least, some writing and formalizing of the proposal. That's
good, because it gives an alternative to just being a negative "stop doing
things!" voice.

Also, though, please be aware that "some individual sat down and installed
this system" may not always be our main use case. All of these "configure it
on install" suggestions don't help us with the cloud image at all.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Billy Crook]

On Tue, Jul 23, 2013 at 9:56 AM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  Also, though, please be aware that "some individual sat down and
> installed
>  this system" may not always be our main use case. All of these "configure it
>  on install" suggestions don't help us with the cloud image at all. 
I see no reason at all that it couldn't be configured on install in
the cloud image too.  It'd be handled much the same as timezone, ntp,
dns, gateway, hostname, etc.  As others have shown, it can also be
served via DHCP.

[Matthew Miller]

On Tue, Jul 23, 2013 at 10:03:16AM -0500, Billy Crook wrote:
>  > Also, though, please be aware that "some individual sat
> down and installed
>  > this system" may not always be our main use case. All of these "configure
> it
>  > on install" suggestions don't help us with the cloud image at all.
>  I see no reason at all that it couldn't be configured on install in
>  the cloud image too.  It'd be handled much the same as timezone, ntp,
>  dns, gateway, hostname, etc.  As others have shown, it can also be
>  served via DHCP. 
Since it _isn't_ served via DHCP in any environment I'm aware of, that's not
actually useful.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Nicolas Mailhot]

Le Dim 21 juillet 2013 16:05, Matthew Miller a écrit :
>  On Sun, Jul 21, 2013 at 08:58:39AM +0200, Nicolas Mailhot wrote:
> > it. Yet the "something better" never materialized. When I had a disk go
> > wrong lately I was notified by the big ugly legacy system. I had *zero*
> > notification by all the "better" systems that were given as
> "evidence".
> > Because the "better" systems do not exist. None of the 'smtpd is
> legacy"
> > complainers have actually tried to solve the (remote) notification
> > problem, none of them actually understand the reliability and
> > operational
> > constrains, or that being to define message routing (via aliases,
>
>  Sure they do. I can't imagine an installation of any size (eg more than 2
>  systems) not using Nagios, Icigna, or some other alerting system. 
And none of those is a general solution, they've never agreed to a common
API which has a reasonable chance to be available by default, so no app is
going to target them. They're all an optional overlay to the default
system tools, that processes a very narrow subset of notifications and
requires dedicated tools and people.

>  If you're in the narrow case between a desktop system and an
> installation
>  where real monitoring and alerting is worth it, install an MTA. 
Where is the desktop notification solution in Fedora? There is none able
to even remotely approach the capabilities of the cron + MTA bits you so
dislike. Even running the latest and greatest rawhide nothing desktop-side
caught a very basic event like a failing disk! The only state-of-the-art
part of our notification chain is the smtpd element, everything else is
hacks or unfinished prototypes (state-of-the-art as in, what are Google
and Amazon using to notify their users of events? Mail messages! They
would be ROFL if they were reading this conversation. If it's not done yet
I predict they'll integrate their phones and tablets and notify you of
problems by mail in the next years.)

The limit if there is one is between standalone Fedora and server with
lots of external infrastucture, and this later use-case has never
justified removing built-in capabilities. Fedora is batteries included,
not "can't do anything by default, add third-party tools" Solaris.

-- 
Nicolas Mailhot

[Chris Murphy]

On Jul 21, 2013, at 10:55 AM, "Nicolas Mailhot"
<nicolas.mailhot(a)laposte.net&gt; wrote:
>   (state-of-the-art as in, what are Google
>  and Amazon using to notify their users of events? Mail messages!> 
If you're talking about google calendar events, email is used only because even with
Chrome the pop-up notifications only work 1/2 the time. 


>  They
>  would be ROFL if they were reading this conversation. If it's not done yet
>  I predict they'll integrate their phones and tablets and notify you of
>  problems by mail in the next years.) 
?? So you think it's a good idea to have low battery, critical software updates, maybe
a virus alert, appear to the user in an email? That really makes no sense, but I'm
otherwise not thinking what else you mean by the above.

I think email is craptastic. There's too much of it in all forms. But the worst is the
kind that comes from automated systems. I want less of this, not more of it. The email UA
paradigm is still overwhelmingly chronologically based. The attempts to prioritize emails
still lack sufficient granularity, even with a lot of work (and on-going work). And it
fails miserably on mobile for the typical user with 1-3 email accounts, so an email of a
hard drive failure gets mixed in with Aunt Edna needing her gall bladder removed in
emergency surgery and Sally who just got a new puppy. Email sucks as a notification
system.


Chris Murphy

[Nicolas Mailhot]

Le Dim 21 juillet 2013 20:24, Chris Murphy a écrit :
>  On Jul 21, 2013, at 10:55 AM, "Nicolas Mailhot"
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> >  (state-of-the-art as in, what are Google
> > and Amazon using to notify their users of events? Mail messages!>
>
>  If you're talking about google calendar events, email is used only because
>  even with Chrome the pop-up notifications only work 1/2 the time. 
It's used because it works reliably, sure

> > They
> > would be ROFL if they were reading this conversation. If it's not done
> > yet
> > I predict they'll integrate their phones and tablets and notify you of
> > problems by mail in the next years.)
>
>  ?? So you think it's a good idea to have low battery, critical software
>  updates, maybe a virus alert, appear to the user in an email? That really
>  makes no sense, but I'm otherwise not thinking what else you mean by the
>  above. 
No, I think for *some* notification classes, async + reliable
system-agnostic delivery is better than transient
non-on-seen-it-and-anyway-gnome-suppressed-it popup

>  I think email is craptastic. There's too much of it in all forms.
> But the
>  worst is the kind that comes from automated systems. I want less of this,
>  not more of it. 
But every other system sucks more…
At least most MUAs have built-in filtering/classification capabilities
(under the user, not the designer control).

-- 
Nicolas Mailhot

[Adam Williamson]

On Sun, 2013-07-21 at 18:55 +0200, Nicolas Mailhot wrote:

>  Where is the desktop notification solution in Fedora? There is none
> able
>  to even remotely approach the capabilities of the cron + MTA bits you so
>  dislike.  
You're ascribing emotions to a proposal where none exist. No-one said
they 'so dislike' cron + MTA, what they said was that they believe few
Fedora installations use local mail delivery any more and it increases
the size of the minimal and default install unnecessarily, so they'd
like to take it out of the minimal and default package sets. It's not
about 'liking' or 'disliking' it.

>  Even running the latest and greatest rawhide nothing desktop-side
>  caught a very basic event like a failing disk! 
GNOME Disks is supposed to pop up a notification when SMART reports
pre-fail status for a disk, I think. I suppose it's possible that's
broken on the GNOME side somehow.

>   The only state-of-the-art
>  part of our notification chain is the smtpd element, everything else is
>  hacks or unfinished prototypes (state-of-the-art as in, what are Google
>  and Amazon using to notify their users of events? Mail messages! They
>  would be ROFL if they were reading this conversation. If it's not done yet
>  I predict they'll integrate their phones and tablets and notify you of
>  problems by mail in the next years.) 
Again you're confusing the issue. The Change proposed here is not 'email
is so old LOL LOL noone's allowed to use it any more!' It's 'we don't
need an MTA in the minimal and default Fedora package sets'. You are
attacking a straw man.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Chris Murphy]

On Jul 22, 2013, at 10:25 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  
>  
> > Even running the latest and greatest rawhide nothing desktop-side
> > caught a very basic event like a failing disk!
>  
>  GNOME Disks is supposed to pop up a notification when SMART reports
>  pre-fail status for a disk, I think. I suppose it's possible that's
>  broken on the GNOME side somehow. 
Difficult to test. ;-)

GNOME Disks will poll for SMART info when it's run manually. As for notifications when
the app isn't running, I'm not sure how this would work without a daemon running
that polls on a schedule. Same for mdadm created RAID arrays. Neither mdadm or smartd are
configured out of the box to issue notifications, and when they are so configured, both
depend on email as the mechanism.

I consistently get notifications from Gnome Shell if I use LVM (integrated) RAID, but
presently anaconda doesn't create this form of RAID. Instead it uses mdadm to create
an explicit md device, then creates LVM on that. Whereas the integrated approach, the raid
level is an attribute of the LV (it does use the md driver code, but it doesn't depend
on mdadm for creation or monitoring) with its own LVM monitoring daemon.

Chris Murphy

[Matthias Clasen]

On Mon, 2013-07-22 at 12:25 -0600, Chris Murphy wrote:
>  On Jul 22, 2013, at 10:25 AM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > 
>  > 
>  >> Even running the latest and greatest rawhide nothing desktop-side
>  >> caught a very basic event like a failing disk!
>  > 
>  > GNOME Disks is supposed to pop up a notification when SMART reports
>  > pre-fail status for a disk, I think. I suppose it's possible that's
>  > broken on the GNOME side somehow.
>  
>  Difficult to test. ;-)
>  
>  GNOME Disks will poll for SMART info when it's run manually. As for notifications
> when the app isn't running, I'm not sure how this would work without a daemon
> running that polls on a schedule. Same for mdadm created RAID arrays. Neither mdadm or
> smartd are configured out of the box to issue notifications, and when they are so
> configured, both depend on email as the mechanism.
>  
>  I consistently get notifications from Gnome Shell if I use LVM (integrated) RAID, but
> presently anaconda doesn't create this form of RAID. Instead it uses mdadm to create
> an explicit md device, then creates LVM on that. Whereas the integrated approach, the raid
> level is an attribute of the LV (it does use the md driver code, but it doesn't depend
> on mdadm for creation or monitoring) with its own LVM monitoring daemon. 
I spent 5 minutes reconstructing my old knowledge of how this works:

The udisks system service is monitoring SMART info. GNOME disks installs
a gnome-settings-daemon plugin which is what pops up the notifications.

So no, running GNOME Disks should not be required to get such
notifications. Having it installed should be enough.

udisks even has API
http://udisks.freedesktop.org/docs/1.90.0/gdbus-org.freedesktop.UDisks2.D...
that lets you test this without taking a hammer to your disk.


Matthias

[Oron Peled]

On Friday 19 July 2013 15:46:25 Adam Williamson wrote:
>  ... We don't set up any mail reader to read this mail out of the
> box. 
OK, I won't count mailx and mutt because we talk about different audience,
should we open bug-reports for the rest? (kmail? evolution?)

>  No app is very likely to know your user name and send mail to you.
Cron was already mentioned, but every one seem to ignore the fact that
regular users don't have permission to read system logs.

[or are you suggesting that regular users should not be allowed to use cron?]

>  I run my own mail server, ground up. 
I'm not talking about running an SMTP server, but rather:

 - Programs being able to pipe stuff into /usr/sbin/sendmail (or mailx FWIW)

 - Knowing it would be routed to the correct location (with persistence).

 - The default location (/var/spool/mail) is well-known (and could easily
   become more visible via correct defaults for modern MUA's)

 - An administrator can centrally re-route all this to anywhere they want
   without having to fiddle with settings of individual applications.

>  It's just ludicrous that we have it in @core. Rip it out, now.
I agree about @core, I disagree about default (desktop/server) installs.

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
Linux lasts longer!
                        -- "Kim J. Brand" <kim(a)kimbrand.com&gt;

[Lennart Poettering]

On Sun, 21.07.13 01:50, Oron Peled (oron(a)actcom.co.il) wrote:

>  On Friday 19 July 2013 15:46:25 Adam Williamson wrote:
>  > ... We don't set up any mail reader to read this mail out of the box.
>  
>  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...

>  > No app is very likely to know your user name and send mail to
> you.
>  
>  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).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Oron Peled]

Hi,

On Monday 22 July 2013 20:33:32 Lennart Poettering wrote:
>  On Sun, 21.07.13 01:50, Oron Peled (oron(a)actcom.co.il) 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: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
Linux:  If you're not careful, you might actually learn something.
                -- Allen Wong

[Lennart Poettering]

On Tue, 23.07.13 04:03, Oron Peled (oron(a)actcom.co.il) wrote:

>  > > 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) 
Also as mentioned on this thread, this doesn't work for cron right now
as cron actually collects all log output of a job and then posts it
under its own identity, which is why it is attributed to cron/root.

THis is, if you so will, a misdesign in cronie.

>   * 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. 
The journal is fine with multi-line log messages. In fact, the kernel by
default sends out a couple of multi-line messages.

Cron currently collects all the job's logs in one go and then writes
them under its own identity in one big transaction out. THis means that there's
no way to get "live" access to the logs of current long-running
jobs. Which is certainly suboptimal.

Note that due to the context we collect of messages it should be
preferable these days if logging happens immediately per-line and then
is recombined at display time, rather than collected and done at the
end, simply to make sure latencies are low, and you get a live view into
the system.

But either way, both philosophies (log individual log lines immediately
+ log them all in one) work fine with journald, we can do
both, better than syslog ever could.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Matthew Miller]

On Wed, Jul 24, 2013 at 01:23:08PM +0200, Lennart Poettering wrote:
>  >    So this issue is still outstanding (but I'll bet you knew
> that)
>  Also as mentioned on this thread, this doesn't work for cron right now
>  as cron actually collects all log output of a job and then posts it
>  under its own identity, which is why it is attributed to cron/root.
>  THis is, if you so will, a misdesign in cronie. 
Is there an RFE to fix this?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Oron Peled]

On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote:
>  On Tue, 23.07.13 04:03, Oron Peled (oron(a)actcom.co.il) wrote:
>  > 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.
>  
>  Also as mentioned on this thread, this doesn't work for cron right now
>  as cron actually collects all log output of a job and then posts it
>  under its own identity, which is why it is attributed to cron/root. 
Sounds reasonable, but please look at the result of previous tests:
   # journalctl SYSLOG_IDENTIFIER=CROND --output verbose
   Tue 2013-07-23 03:31:01 IDT ...
        PRIORITY=6
        _UID=0
        _MACHINE_ID=...
        _HOSTNAME=...
        _EXE=/usr/bin/bash
        _TRANSPORT=syslog
        SYSLOG_FACILITY=9
        _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023
        _GID=501
        _AUDIT_LOGINUID=501
        _SYSTEMD_OWNER_UID=501
        _BOOT_ID=...
        SYSLOG_IDENTIFIER=CROND
        _COMM=sh
        MESSAGE=(oron) CMD (/bin/echo "Test output from cron")
        _CMDLINE=/bin/sh -c /bin/echo "Test output from cron"
        SYSLOG_PID=19788
        _PID=19788
        _AUDIT_SESSION=194
        _SYSTEMD_CGROUP=/user/501.user/194.session
        _SYSTEMD_SESSION=194
        _SOURCE_REALTIME_TIMESTAMP=1374539461144186

It seems it was filtered by _UID, but what's the difference between that
and _AUDIT_LOGINUID and _SYSTEMD_OWNER_UID?

>  THis is, if you so will, a misdesign in cronie. 
Maybe:
 * But if it writes to syslog as root (_UID=0), how come _AUDIT_LOGINUID
   is my uid?
 * This "missdesign" cannot exist in the mail interface, since any sane MTA
   delivers local mails as the recipient user.

In any case, this latent bug is triggered by removal of MTA -- so solving
it would drop at least this show-stopper for the suggested feature.

>  >  * 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.
>  
>  Cron currently collects all the job's logs in one go and then writes
>  them under its own identity in one big transaction out. THis means that
>  there's no way to get "live" access to the logs of current long-running
>  jobs. Which is certainly suboptimal. 
Hmmm... you are right that for *some* cron-jobs, logging is better fit
than mailing. However, for *others* it's the reverse. The examples
I gave are reports (e.g: think about HTML report -- is there any
sense in <div...> line without its matching </div>?)

There are obviously orders of magnitude of the "report" case cron-jobs
then the prior -- just due to the fact the default "cron-to-mail"
existed from early 80's on very wide OS range and the "cron-to-log"
is relatively new feature that few heard about (I only heard about
it in this thread -- thanks).

The default mentioned in this thread -- mail and fall back to logging
if there's no MTA sound very reasonable design to me. It would be
*nice-to-have* if there was a way to specify "cron-to-log" per-job
(or even per-crontab) without resorting to "| logger...", but
that's for another mail-thread :-)

>  Note that due to the context we collect of messages it should be
>  preferable these days if logging happens immediately per-line and then
>  is recombined at display time, rather than collected and done at the
>  end, simply to make sure latencies are low, and you get a live view into
>  the system.
>  But either way, both philosophies (log individual log lines immediately
>  + log them all in one) work fine with journald, we can do
>  both, better than syslog ever could. 
Obviously, journald manage its log data better than syslogd.

However, we compare *logging* in general against *mail*:
 * Mail is "pushed" to the user, while the user need to actively read
("pull")
   the log. So mail, by definition is a kind of "notification-system".

 * Unlike desktop notifications which are normally transient, mail can be
   read offline, sorted by arbitrary user criteria ("this mail is
   important *to me* so I put it in that folder"), is normally saved
   long-term (and usually backed-up), can be trivially be forwarded
   (automatically/manually), shared between systems etc.

 * Logging shares most previously mentioned mail attributes (as compared
   to desktop notifications) -- i.e: it's persistent, may be backed-up, may
   be routed. However, it's line-oriented and not message oriented.

 * Obviously, messages may be re-constructed from lines, just like messages
   may be constructed from byte-streams -- do you use SOCK_STREAM for
   SOCK_DGRAM use-cases? (let's talk local-sockets, so we don't drift
   to reliability/ordering issues which are not relevant to my analogy)

I don't bitch on journald because "it-is-not-good-as-an-MTA-replacement":
 * I say a *very* common case for cron is *reports*
 * In these cases mail has many advantages: message-based, pushed, archived
   by user criteria ([subjective] urgency, responsible party, etc.),
   view on any platform/OS (e.g: your smart-phone).
 * It would be nice if we could adapt for other classes of jobs you
   described, where logging is more suitable -- but not by killing
   the more common use-cases (at least currently).

And again, if the feature talked about removing MTA from minimal I would
not have any problem (think chrooted environments, containers, customized
thin VM provisioning, etc.) -- but not from *default* desktops/servers.

Bye,

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"write your own operating system.  It has worked every time for me"
           -- Linus Thorvalds

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 25, 2013 at 03:13:33AM +0300, Oron Peled wrote:
>  On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote:
>  > On Tue, 23.07.13 04:03, Oron Peled (oron(a)actcom.co.il) wrote:
>  > > 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.
>  > 
>  > Also as mentioned on this thread, this doesn't work for cron right now
>  > as cron actually collects all log output of a job and then posts it
>  > under its own identity, which is why it is attributed to cron/root.
>  
>  Sounds reasonable, but please look at the result of previous tests:
>     # journalctl SYSLOG_IDENTIFIER=CROND --output verbose
>     Tue 2013-07-23 03:31:01 IDT ...
>          PRIORITY=6
>          _UID=0
>          _MACHINE_ID=...
>          _HOSTNAME=...
>          _EXE=/usr/bin/bash
>          _TRANSPORT=syslog
>          SYSLOG_FACILITY=9
>          _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023
>          _GID=501
>          _AUDIT_LOGINUID=501
>          _SYSTEMD_OWNER_UID=501
>          _BOOT_ID=...
>          SYSLOG_IDENTIFIER=CROND
>          _COMM=sh
>          MESSAGE=(oron) CMD (/bin/echo "Test output from cron")
>          _CMDLINE=/bin/sh -c /bin/echo "Test output from cron"
>          SYSLOG_PID=19788
>          _PID=19788
>          _AUDIT_SESSION=194
>          _SYSTEMD_CGROUP=/user/501.user/194.session
>          _SYSTEMD_SESSION=194
>          _SOURCE_REALTIME_TIMESTAMP=1374539461144186
>  
>  It seems it was filtered by _UID, but what's the difference between that
>  and _AUDIT_LOGINUID and _SYSTEMD_OWNER_UID? 
Those fields are described in
systemd.journal-fields(7) manpage:
- _UID is the UID of the sender of the messsage
- _AUDIT_LOGINUID comes from the kernel's audit subsystem
- _SYSTEMD_OWNER_UID is derived from the position in systemd cgroup
  hierarchy.
Each one serves a different purpose. The underscore in front signifies that
they were collected by journald itself, and are not controlled by the sender.

>  
>  > THis is, if you so will, a misdesign in cronie.
>  
>  Maybe:
>   * But if it writes to syslog as root (_UID=0), how come _AUDIT_LOGINUID
>     is my uid? 
Cron opens a pam session when running your job, and then login uid
is set.

Zbyszek
-- 
they are not broken. they are refucktored
                           -- alxchk

[Nico Kadel-Garcia]

On Fri, Jul 19, 2013 at 3:23 PM, Billy Crook <billycrook(a)gmail.com&gt; wrote:
>  On Jul 19, 2013 2:16 PM, "Bill Nottingham"
> <notting(a)redhat.com&gt; wrote:
> > 
> > It's not as if the default MTA configuration, as I understand
> it (no smart
> > host, attempt to send all mail directly with the FQDN) is generally useful
> > OOTB.
>
>  It is to me, and I suspect I am not alone. 
Amen. Admittedly, life gets complex when a "root" alias is needed and
you are stuck behind an email SMARTHOST, but the default works just
*fine* for delivering nightly cron jobs and error reports to the local
root account. It's a very handy  config, so system reporting is merely
ignored, and not entirely lost, when setting up bare systems. And
there dozens if not hundreds of critical system tools that would wind
up auto-installing it. Activating such a core resource by surprise,
long after setup, is going to cause surprises.

Mind you, I'm not so fond of sendmail these days, and strongly prefer
postfix for ease of configuration.

[Chris Murphy]

On Jul 19, 2013, at 12:26 PM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:

>  On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook
> <billycrook(a)gmail.com&gt; wrote:
> > Please voice yourself at meetings in #fedora-devel if this is important to
> > you.
>  
>  (Speaking purely for myself and not for other FESCo members,) I do
>  want to hear from Fedora contributors - but I'd much rather hear on
>  the mailing list (where messages arrive over the course of a week or
>  more) rather than during the FESCo meeting (when we have only a few
>  minutes to agree on a decision, and already frequently have two or
>  three parallel subconversations). 
Speaking for myself, I'd like to see sendmail totally dropped from minimal,
infrastructure, and desktop packagesets. But at least I'd like to see it disabled (or
rather masked, since sendmail somehow manages to be started up even when systemctl is used
to disable it) by default.


Chris Murphy

[Lennart Poettering]

On Fri, 19.07.13 13:17, Billy Crook (billycrook(a)gmail.com) wrote:

>  Sendmail stays in Default unless there is compelling reason to switch
> to
>  postfix, exim, meta1, etc.  Those users who wish to remove it are welcome
>  to do so.  Nobody is stopping them. The default configuration of sendmail
>  poses no problem to users who are unaware of it. 
Not true. I eats my cron logs and other stuff and I have no way to get
the stuff out of it again with the core install...

>  Please voice yourself at meetings in #fedora-devel if this is
> important to
>  you. 
Yes, please, post a lot of "+1" messages. They contribute so positively
(I mean, literally!) to any discussion. "+1" messages are really good
for making a point as they contain so much additional arguments nobody
has heard or read before. It's almost as constructive posting "+1"s, as
it is posting sarcastic comments about their pointlessness...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Lennart Poettering]

On Fri, 19.07.13 19:37, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  However, having the /usr/sbin/sendmail API available to applications
>  is valuable - it brings a significant system administration benefit of
>  centralizing the SMTP configuration. 
Sure it is valuable. However, it's also a pretty bad API, since it
currently will accept all messages but in most cases silently eat them
up and devlier to a mailbox that constantly grows and is never
checked. APIs that claim to work but actually don't, and where there's
*no* way to figure that out are just inhrently broken. 

In general, we should work on centralizing things more, we certainly
agree on that. However, I find it really surprising to draw the line
here between logs generated by cron jobs (and similar cases) where
traditionally mails were sent, and the rest were traditionally logfiles
were written. That makes very little sense...

If you want to centralize system configuration, rather then services,
then go ahead and do, that, but actually centralize *the configuration*,
not the service. In particular, because a centralized client-side SMTP
service is a really questionnable thing on today's Internet where SMTP
delivery connections are almost always authenticated by a *user* id. Due
to that they are generally much better configured in the MUA which
actually run in the user context instead of a system service which lacks
all that and where no infrastructure exists for supplying user
authentication information.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Nicolas Mailhot]

Le Lun 22 juillet 2013 18:29, Lennart Poettering a écrit :

>  If you want to centralize system configuration, rather then
> services,
>  then go ahead and do, that, but actually centralize *the configuration*,
>  not the service. In particular, because a centralized client-side SMTP
>  service is a really questionnable thing on today's Internet where SMTP
>  delivery connections are almost always authenticated by a *user* id. Due
>  to that they are generally much better configured in the MUA which
>  actually run in the user context instead of a system service which lacks
>  all that and where no infrastructure exists for supplying user
>  authentication information. 
Actually, with the various Fedora MUAs I've used, it ended up being easier
to configure them to use local MTA as relay than to try to convince them
individually to do anything more complex than 'non-encrypted smtp without
auth' (when the options existed they changed every few MUA versions and I
got tired of re-parametring them all the time). Bonus point is that
changing the relay options fixes all MUAs in one go, I got free logging of
the MUA activity, and a send queue that does not depend on running the MUA
when the network comes back.

To be sure, it would be cleaner it the connexion user when relaying
depended on the system user that emitted the message. I've not checked if
it was possible or easy to do it.

Regards,

-- 
Nicolas Mailhot

[Alexey I. Froloff]

On Mon, Jul 22, 2013 at 06:50:17PM +0200, Nicolas Mailhot wrote:
>  Actually, with the various Fedora MUAs I've used, it ended up
> being easier
>  to configure them to use local MTA as relay 
If you are able to configure the MTA of
your choice, then you
will be able to install that MTA when you need it.  Default
settings are not usable for anything other than local delivery.

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[Lennart Poettering]

On Mon, 22.07.13 18:50, Nicolas Mailhot (nicolas.mailhot(a)laposte.net) wrote:

>  
>  Le Lun 22 juillet 2013 18:29, Lennart Poettering a écrit :
>  
>  > If you want to centralize system configuration, rather then services,
>  > then go ahead and do, that, but actually centralize *the configuration*,
>  > not the service. In particular, because a centralized client-side SMTP
>  > service is a really questionnable thing on today's Internet where SMTP
>  > delivery connections are almost always authenticated by a *user* id. Due
>  > to that they are generally much better configured in the MUA which
>  > actually run in the user context instead of a system service which lacks
>  > all that and where no infrastructure exists for supplying user
>  > authentication information.
>  
>  Actually, with the various Fedora MUAs I've used, it ended up being easier
>  to configure them to use local MTA as relay than to try to convince them
>  individually to do anything more complex than 'non-encrypted smtp without
>  auth' (when the options existed they changed every few MUA versions and I
>  got tired of re-parametring them all the time). Bonus point is that
>  changing the relay options fixes all MUAs in one go, I got free logging of
>  the MUA activity, and a send queue that does not depend on running the MUA
>  when the network comes back. 
I find it quite amazing that you actually use multiple different MUAs in
parallel. I mean, most people stick to one MUA usually, maybe two. But
you make it sound as if you need to access your emails through 5 or 10
or so, so that it is really worth making this kind of low-level
configuration change.

It's also hardly something we can suggest people to actively do. User
credentials should not leak into the system like that. If two users send
emails on the same host, then the SMTP delivery needs to provide proper
authentication to the mail gateway attributing the individual mails to
the right user. You lose that by always going via your local MTA. It
certainly works for single-user systems but this generally not how we do
things on Linux, where user and system configuration in general and
authentication credentials in particular are strictly isolated.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Nicolas Mailhot]

Le Lun 22 juillet 2013 20:40, Lennart Poettering a écrit :

>  I find it quite amazing that you actually use multiple different MUAs
> in
>  parallel. I mean, most people stick to one MUA usually, maybe two. But
>  you make it sound as if you need to access your emails through 5 or 10
>  or so, so that it is really worth making this kind of low-level
>  configuration change. 
Well, if the various MUAs shipped in Fedora didn't periodically suffer
from bugs, I wouldn't need to switch regularly (actually since I installed
squirrelmail I don't need switching anymore. It just works, and does not
think duplicating every mail in a private store to simulate pop3 behaviour
is a requisite. So I just point it to the system maildir)

>  It's also hardly something we can suggest people to actively do.
> User
>  credentials should not leak into the system like that. If two users send
>  emails on the same host, then the SMTP delivery needs to provide proper
>  authentication to the mail gateway attributing the individual mails to
>  the right user. 
I didn't write anything else. What I did write is that, at this point in
time, it's probably easier to add the 'send as different used depending on
the system user' to the central MTA (and make smtp an actual system
service) than to try to fix all the MUAs Fedora ships.

-- 
Nicolas Mailhot

[Reindl Harald]

Am 22.07.2013 18:29, schrieb Lennart Poettering:
>  If you want to centralize system configuration, rather then
> services,
>  then go ahead and do, that, but actually centralize *the configuration*,
>  not the service. In particular, because a centralized client-side SMTP
>  service is a really questionnable thing on today's Internet where SMTP
>  delivery connections are almost always authenticated by a *user* id 
which could be *easy* solved by ask the users SMTP and credentials
at the installation, setup /etc/aliases as default forwarding the
messages to this address and configure SASL authentication

with postfix these are a few lines of config and the problem
of the "never faced root's inbox" would be solved at all

[Matthew Miller]

On Mon, Jul 22, 2013 at 07:33:25PM +0200, Reindl Harald wrote:
>  which could be *easy* solved by ask the users SMTP and credentials
>  at the installation, setup /etc/aliases as default forwarding the
>  messages to this address and configure SASL authentication 
That really is only useful on a single user system. If there's an effort to
write the code that does this when Fedora is used in this way, I think
that's reasonably interesting.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Reindl Harald]

Am 23.07.2013 16:37, schrieb Matthew Miller:
>  On Mon, Jul 22, 2013 at 07:33:25PM +0200, Reindl Harald wrote:
> > which could be *easy* solved by ask the users SMTP and credentials
> > at the installation, setup /etc/aliases as default forwarding the
> > messages to this address and configure SASL authentication
>  
>  That really is only useful on a single user system 
and most systems are and they which are not have usually
one person who calls himself and/or is called admin and
this is the right address for root-cron

[Lennart Poettering]

On Mon, 22.07.13 19:33, Reindl Harald (h.reindl(a)thelounge.net) wrote:

>  Am 22.07.2013 18:29, schrieb Lennart Poettering:
>  > If you want to centralize system configuration, rather then services,
>  > then go ahead and do, that, but actually centralize *the configuration*,
>  > not the service. In particular, because a centralized client-side SMTP
>  > service is a really questionnable thing on today's Internet where SMTP
>  > delivery connections are almost always authenticated by a *user* id
>  
>  which could be *easy* solved by ask the users SMTP and credentials
>  at the installation, setup /etc/aliases as default forwarding the
>  messages to this address and configure SASL authentication 
The second part of my mail that you conveniently removed actually
explains why that doesn't work: because the SASL auth is inherently
per-user configuration but in sendmail you can configure it only
globally for the client side.

There is a major mismatch between per-user credentials which you need
for SMTP SASL and the per-system instance of sendmail.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Reindl Harald]

Am 24.07.2013 13:11, schrieb Lennart Poettering:
>  On Mon, 22.07.13 19:33, Reindl Harald (h.reindl(a)thelounge.net)
> wrote:
>  
> > Am 22.07.2013 18:29, schrieb Lennart Poettering:
> >> If you want to centralize system configuration, rather then services,
> >> then go ahead and do, that, but actually centralize *the configuration*,
> >> not the service. In particular, because a centralized client-side SMTP
> >> service is a really questionnable thing on today's Internet where SMTP
> >> delivery connections are almost always authenticated by a *user* id
> >
> > which could be *easy* solved by ask the users SMTP and credentials
> > at the installation, setup /etc/aliases as default forwarding the
> > messages to this address and configure SASL authentication
>  
>  The second part of my mail that you conveniently removed actually
>  explains why that doesn't work: because the SASL auth is inherently
>  per-user configuration but in sendmail you can configure it only
>  globally for the client side.
>  
>  There is a major mismatch between per-user credentials which you need
>  for SMTP SASL and the per-system instance of sendmail 
says who?

i doubt that sendmail can not do the same as postfix
if it is so the proposal should be switch to postfix as default MTA

hence i have *infrastructure wide* SASL-sender/relayhost-maps
in a global mysql-database feeded with a simple self developed
php interface and each single sender can be configured to
use a specific realyhost with specific credentials

http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
http://www.postfix.org/postconf.5.html#smtp_sasl_password_maps

[Nicolas Mailhot]

Le Mer 24 juillet 2013 13:11, Lennart Poettering a écrit :

>  The second part of my mail that you conveniently removed actually
>  explains why that doesn't work: because the SASL auth is inherently
>  per-user configuration but in sendmail you can configure it only
>  globally for the client side. 
Then replace sendmail with something better.

http://www.postfix.org/postconf.5.html#smtp_sender_dependent_authentication

Here, done, time elapsed: 1 min googling.

-- 
Nicolas Mailhot

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 24, 2013 at 02:11:18PM +0200, Nicolas Mailhot wrote:
>  
>  Le Mer 24 juillet 2013 13:11, Lennart Poettering a écrit :
>  
>  > The second part of my mail that you conveniently removed actually
>  > explains why that doesn't work: because the SASL auth is inherently
>  > per-user configuration but in sendmail you can configure it only
>  > globally for the client side.
>  
>  Then replace sendmail with something better.
>  
>  http://www.postfix.org/postconf.5.html#smtp_sender_dependent_authentication
Doesn't this require creating an account on the server for those
administrative jobs and either turning off authentication when sending
mail, or storing authentication credentials for each of those mail
accounts in the postfix config file?

>  Here, done, time elapsed: 1 min googling. 
Great. But does this
really solve anything except refuting the most
immediate statement by Lennart, taken out of context?

Zbyszek
-- 
they are not broken. they are refucktored
                           -- alxchk

[Reindl Harald]

Am 24.07.2013 15:58, schrieb Zbigniew Jędrzejewski-Szmek:
>  On Wed, Jul 24, 2013 at 02:11:18PM +0200, Nicolas Mailhot wrote:
> >
> > Le Mer 24 juillet 2013 13:11, Lennart Poettering a écrit :
> >
> >> The second part of my mail that you conveniently removed actually
> >> explains why that doesn't work: because the SASL auth is inherently
> >> per-user configuration but in sendmail you can configure it only
> >> globally for the client side.
> >
> > Then replace sendmail with something better.
> >
> > http://www.postfix.org/postconf.5.html#smtp_sender_dependent_authentication
>  Doesn't this require creating an account on the server 
on which server?

on the target server which you relay to you have the account
postfix does only buffer in /var/spool and relay to your
existing account with the credentials

>  for those administrative jobs and either turning off authentication 
>  when sending mail, or storing authentication credentials for each 
>  of those mail accounts in the postfix config file? 
/etc/aliases
http://www.postfix.org/ADDRESS_REWRITING_README.html#canonical

it is not that hard to configure it for *most* setups where
one admin exists which sould get all the system mails and
the complexer setups would always need manual interaction

the current proposal is more like "we do not ship a useable
sendmail configuration nowaydays and instead to fix this
issue in the installer with a few inputs we remove the MTA"

[Billy Crook]

On Wed, Jul 24, 2013 at 8:58 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
> > Here, done, time elapsed: 1 min googling.
>  Great. But does this really solve anything except refuting the most
>  immediate statement by Lennart, taken out of context? 
'Context' does not ameliorate a foundation of false statements,
however 'immediate' they are.

Anyway, this issue (and syslog) are up for vote, today, in
#fedora-meeting on freenode at 1800 UTC, right?

[Nicolas Mailhot]

Le Mer 24 juillet 2013 15:58, Zbigniew Jędrzejewski-Szmek a écrit :
>  On Wed, Jul 24, 2013 at 02:11:18PM +0200, Nicolas Mailhot wrote:
> >
> > Le Mer 24 juillet 2013 13:11, Lennart Poettering a écrit :
> >
> > > The second part of my mail that you conveniently removed actually
> > > explains why that doesn't work: because the SASL auth is inherently
> > > per-user configuration but in sendmail you can configure it only
> > > globally for the client side.
> >
> > Then replace sendmail with something better.
> >
> > http://www.postfix.org/postconf.5.html#smtp_sender_dependent_authentication
>  Doesn't this require creating an account on the server for those
>  administrative jobs and either turning off authentication when sending
>  mail, or storing authentication credentials for each of those mail
>  accounts in the postfix config file? 
It requires obviously giving postfix the credentials to use with every
different smtp entry point you wish to configure (which is more secure
than having each MUA keep a copy in its own config file)

http://www.postfix.org/SOHO_README.html#client_sasl_sender

> > Here, done, time elapsed: 1 min googling.
>  Great. But does this really solve anything except refuting the most
>  immediate statement by Lennart, 
It refutes the given argument

>  taken out of context? 
Why out of context? Lennart wrote "but you can not do xxx with the system
MTA". I pointed out that actually xxx has been possible for quite a long
time. The "sendmail sucks therefore Fedora should not ship a system MTA"
had been answered before.

-- 
Nicolas Mailhot

[Subhendu Ghosh]

On Fri, Jul 19, 2013 at 1:37 PM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:

>  However, having the /usr/sbin/sendmail API available to applications
>  is valuable - it brings a significant system administration benefit of
>  centralizing the SMTP configuration.
>  

Then the app packaging can have a dependency on sendmail.

But it doesn't not require sendmail to be in the _default_ installation.

[Kalev Lember]

On 07/15/2013 10:36 AM, Jaroslav Reznik wrote:
>  = Proposed System Wide Change: No Default Sendmail =
>  https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
>  
>  Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew 
>  Miller <mattdm at fedoraproject org>
>  
>  No longer install an MTA by default. (Specifically let's remove sendmail from 
>  @core and @standard comps groups.) 
Good change, thanks for doing this.

I think it makes sense to keep the minimal installation groups truly
minimal. Those who need an MTA can always install it afterwards; and my
server admin friends say that _not_ installing sendmail by default makes
their life easier, because that way they have full control over what
services get installed and enabled.

And with my desktop user hat on, I welcome removal of bloat that I don't
need.

Thanks again!

-- 
Kalev