Re: F20 System Wide Change: No Default Sendmail
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.fc19updates 910 k cifs-utils x86_64 6.1-3.fc19updates 87 k libsmbclientx86_64 2:4.0.7-2.fc19updates 109 k libtirpcx86_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.fc19updates 78 k netpbm x86_64 10.61.02-5.fc19 updates 177 k netpbm-progsx86_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-clientx86_64 2:4.0.7-2.fc19updates 454 k samba-commonx86_64 2:4.0.7-2.fc19updates 695 k samba-libs x86_64 2:4.0.7-2.fc19updates 4.1 M Transaction Summary Upgrade 19 Packages The updates were successfully applied -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 6:52 PM, Billy Crook billycr...@gmail.com wrote: On Tue, Jul 23, 2013 at 10:51 AM, Matthew Miller mat...@fedoraproject.org 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 ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Le Mer 24 juillet 2013 08:30, drago01 a écrit : On Tue, Jul 23, 2013 at 6:52 PM, Billy Crook billycr...@gmail.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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: +972-4-8228492 o...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tuesday 23 July 2013 02:34:25 Lennart Poettering wrote: On Tue, 23.07.13 03:14, Oron Peled (o...@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 QA. 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: +972-4-8228492 o...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 19:33, Reindl Harald (h.rei...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, 23.07.13 04:03, Oron Peled (o...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, 23.07.13 11:52, Billy Crook (billycr...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Wed, Jul 24, 2013 at 8:58 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Lennart Poettering mzerq...@0pointer.de 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Am 24.07.2013 13:11, schrieb Lennart Poettering: On Mon, 22.07.13 19:33, Reindl Harald (h.rei...@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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Wed, Jul 24, 2013 at 9:10 AM, Frank Ch. Eigler f...@redhat.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Wed, 2013-07-24 at 11:14 -0500, Billy Crook wrote: On Wed, Jul 24, 2013 at 9:10 AM, Frank Ch. Eigler f...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Wed, 24 Jul 2013 15:10:05 -0700 Adam Williamson awill...@redhat.com 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 f...@redhat.com 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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote: On Tue, 23.07.13 04:03, Oron Peled (o...@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
Re: F20 System Wide Change: No Default Sendmail
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 (o...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
+1 Sent from my Verizon Wireless BlackBerry -Original Message- From: Kevin Fenzi ke...@scrye.com Sender: devel-boun...@lists.fedoraproject.org Date: Wed, 24 Jul 2013 16:12:03 To: devel@lists.fedoraproject.org Reply-To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: F20 System Wide Change: No Default Sendmail -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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-annou...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 2013-07-22 at 12:25 -0600, Chris Murphy wrote: On Jul 22, 2013, at 10:25 AM, Adam Williamson awill...@redhat.com 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.Drive.Ata.html#gdbus-method-org-freedesktop-UDisks2-Drive-Ata.SmartUpdate that lets you test this without taking a hammer to your disk. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Am 22.07.2013 18:51, schrieb Lennart Poettering:
On Fri, 19.07.13 14:47, Frank Ch. Eigler (f...@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 CP 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;
}
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 7:32 AM, Olav Vitters o...@vitters.nl 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 10:10 AM, Billy Crook billycr...@gmail.com 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.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 10:19 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Jul 23, 2013 at 10:10 AM, Billy Crook billycr...@gmail.com 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 billycr...@gmail.com... 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 9:56 AM, Matthew Miller mat...@fedoraproject.org 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 10:57:15AM -0400, Fulko Hew wrote: But, personally, I agree with billycr...@gmail.com... 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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 10:57:15AM -0400, Fulko Hew wrote: But, personally, I agree with billycr...@gmail.com... 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 10:06 AM, Matthew Miller mat...@fedoraproject.org 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 o...@vitters.nl 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, Jul 23, 2013 at 10:51 AM, Matthew Miller
mat...@fedoraproject.org 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.mail...@laposte.net 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Once upon a time, Matthew Miller mat...@fedoraproject.org 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, 2013-07-23 at 11:52 -0500, Billy Crook wrote: On Tue, Jul 23, 2013 at 10:51 AM, Matthew Miller mat...@fedoraproject.org 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Sun, Jul 21, 2013 at 9:20 PM, Matthew Miller mat...@mattdm.org 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, 19.07.13 19:37, Miloslav Trmač (m...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, 19.07.13 13:17, Billy Crook (billycr...@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 +1s, as it is posting sarcastic comments about their pointlessness... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote: On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller mat...@fedoraproject.org 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, 19.07.13 14:47, Frank Ch. Eigler (f...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote: On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller mat...@fedoraproject.org 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering mzerq...@0pointer.de 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote: On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller mat...@fedoraproject.org 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Sat, 20.07.13 09:00, Robert Nichols (rnicholsnos...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote: On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller mat...@fedoraproject.org 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 AnacronAnacron job 'cron.daily' on bigcomputer.home. Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@wumpus ionice -c3 run-parts /etc/ Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@resonance /opt/seas/sbin/sync-NIS Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron masher@releng03 TMPDIR=`mktemp -d /tmp Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 Cron DaemonCron root@hpc /etc/15m.local Jul 02 Cron DaemonCron root@hpc /etc/15m.local Jul 02 Cron DaemonCron root@hpc /etc/15m.local Jul 02 Cron DaemonCron root@hpc /etc/15m.local Jul 02 Cron DaemonCron 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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 2013-07-22 at 19:09 +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering mzerq...@0pointer.de 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Jul 22, 2013, at 10:25 AM, Adam Williamson awill...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Sat, 20.07.13 18:05, Lars E. Pettersson (l...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Sun, 21.07.13 01:50, Oron Peled (o...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 18:50, Nicolas Mailhot (nicolas.mail...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Sun, 21.07.13 16:09, Reindl Harald (h.rei...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Le Lun 22 juillet 2013 19:28, Matthew Miller a écrit : On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote: What makes cron and smtpd work well together is that they both perform async background computing. And many cron messages are not logs they're notifications of an event the cron is polling for, or submission of job results. Honest, non-loaded question here. Do you really find them default cron output mode helpful? I think sending all cron output by email is useful, in the sense that it pushes errors for the user to fix instead of failing silently (or with another line in the system logs no one will read since they're swamped by gdm, networkmanager and a few other chatty system services). I do not think cron jobs that output something every time they are run just in case are nice. I do not think the way we let systems install without a configured smtp backend is good. If cron mails were actually pushed by default the bad crons would be fixed before doing any real damage. A lot of the problems people complain of here are the direct product of not configuring the smtp backend a install time for years. I do not think the default cron message envelope is any good. It does not make enough effort to identify the system and cron job which is failing, and is not localized. I do think neither the transient GNOME notifications, nor burying events in logs only root can consult are appropriate except for the most routine and uninteresting events. I do not think that for regular output (ie job results, intended notifications not script crashes) direct cron to smtpd is ideal. The best path should be app/cron/script → backend notification center (evaluation of all system notifications, standard formatting, localization, triaging) → (routing) → consumer (DE notification center, logs, specialized apps, human in MUA) with in many cases routing = smtpd → imap box → remote consumer. There can be different imap boxes for each human user of the system, for the operator of the system (operator can be it-knowledgeable nephew, it-slave-boyfriend, helpdesk or central monitoring/alert system). Some of them can be consulted via the DE notification GUI, not necessarily by a MUA (just requires defining how you serialize notifications in mail attachment, and teaching the notification center to read an imap box and remove each message when the user confirms he's done with it, and leave it in the remote mailbox for future processing otherwise) A lot of notifications do not require immediate action. What they do require is some action in the future. For those I do want them to hang out on an imap server till I take care of them, and I definitely do not want to be only able to see them when I log in on the exact system they originated from, or only at the notification time. I do think the only widely deployed vendor-agnostic remote messaging infrastructure is the mail infrastructure. All the other solutions require always-on receiving nodes, that end-users can not afford. I do think the notification infrastructure needs to be able to handle the results produced by user crontabs, and the entry points need to be simple enough the crontab user does not have to think about them. I do think the basic app (something) smtp architecture is sound, even if it does need some refreshing and formatting cleanup. I do think that commodisation will result in multiple computing nodes in every home, and that being able to push notifications to a machine-agnostic store will prove just as compelling end-user-side as it was in university campuses when cron was first wed with sendmail. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 16:04, Miloslav Trmač (m...@volny.cz) wrote: On Sun, Jul 21, 2013 at 9:20 PM, Matthew Miller mat...@mattdm.org 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 19:19, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 22.07.13 18:43, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 19.07.13 20:22, Miloslav Trmač (m...@volny.cz) wrote: On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller mat...@fedoraproject.org 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 22, 2013 at 11:41 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 19.07.13 13:17, Billy Crook (billycr...@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 +1s, 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 mat...@fedoraproject.org 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 DaemonCron root@hpc ionice -c3 run-parts /etc/cro Jul 02 AnacronAnacron job 'cron.daily' on bigcomputer.home. ... Jul 02 Cron DaemonCron 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.mail...@laposte.net 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.
Re: F20 System Wide Change: No Default Sendmail
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 15:26, Robert Nichols (rnicholsnos...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 22.07.13 19:29, Matthew Miller (mat...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron write your own operating system. It has worked every time for me -- Linus Thorvalds -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tue, 23.07.13 03:14, Oron Peled (o...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Hi, On Monday 22 July 2013 20:33:32 Lennart Poettering wrote: On Sun, 21.07.13 01:50, Oron Peled (o...@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: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Linux: If you're not careful, you might actually learn something. -- Allen Wong -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Linux: like the air you breathe, ubiquitous and free -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot nicolas.mail...@laposte.net 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Le Dim 21 juillet 2013 09:17, drago01 a écrit : On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot nicolas.mail...@laposte.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On 07/21/2013 03:17 AM, drago01 wrote: On Sun, Jul 21, 2013 at 8:58 AM, Nicolas Mailhot nicolas.mail...@laposte.net 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: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Jul 21, 2013, at 10:55 AM, Nicolas Mailhot nicolas.mail...@laposte.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
