On Mon, Jul 22, 2013 at 11:41 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Fri, 19.07.13 13:17, Billy Crook (billycrook@xxxxxxxxx) wrote: >> Sendmail stays in Default unless there is compelling reason to switch to >> postfix, exim, meta1, etc. Those users who wish to remove it are welcome >> to do so. Nobody is stopping them. The default configuration of sendmail >> poses no problem to users who are unaware of it. > > Not true. I eats my cron logs and other stuff and I have no way to get > the stuff out of it again with the core install... If that's not hyperbole, then please clarify what "eats" refers to. Or just take the 30 seconds or so to setup the MTA correctly, and all of that stuff will be waiting for you in your inbox. If you don't want it mixed with human-originated mail, as some have complained, then use filters to auto sort your mail. >> Please voice yourself at meetings in #fedora-devel if this is important to >> you. > > Yes, please, post a lot of "+1" messages. They contribute so positively > (I mean, literally!) to any discussion. "+1" messages are really good > for making a point as they contain so much additional arguments nobody > has heard or read before. It's almost as constructive posting "+1"s, as > it is posting sarcastic comments about their pointlessness... There's not much else to do when it seems a lot of otherwise very intelligent people still don't get it. I'm certain that you are all aware of how useful an MTA can be. Choosing to cut it off rather than properly configuring it, is rather un-fedora-like. Why not remove ipv6 support, since gosh it's hard too and who configures it? And it doesn't work for most people without explicit configuration. Removing it (even just from the Default install) is wrong. On Mon, Jul 22, 2013 at 12:28 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote: >> What makes cron and smtpd work well together is that they both perform >> async background computing. And many cron messages are not "logs" they're >> notifications of an event the cron is polling for, or submission of job >> results. > > Honest, non-loaded question here. Do you really find them default cron > output mode helpful? You suggested earlier that I dislike cron's e-mail > output, and while I hadn't brought up likes or dislikes before, I really > don't find it so great. To me, it just fills up my mailbox with: > > Jul 02 Cron Daemon Cron <root@hpc> ionice -c3 run-parts /etc/cro > Jul 02 Anacron Anacron job 'cron.daily' on bigcomputer.home. ... > Jul 02 Cron Daemon Cron <root@hpc> ionice -c3 run-parts /etc/cro > > If I did want e-mail output -- which I used to, before I had proper alerting > set up, so as I mentioned before I totally recognize that use case -- I > really would like it with a meaningful subject line, which means even when > running out of cron, the jobs should actually call sendmail or /usr/bin/mail > directly with pretty-formatted output. (And thus, have an explicit > dependency on an MTA, and also basically have the expectation that they're > running on a system which will be properly configured for its environment, > however that happens.) If you are getting a message from a cronjob, it is a pretty good indicator that something went wrong, and you need to take action to correct it. So yes. It's pretty important. Depending on cronjobs to send notifications on their own failures, is poor design because if they have failed, they could easily fail to notify. This is why cron's (albeit ugly) notifications when a job turns up stdout/err, are valuable. On Mon, Jul 22, 2013 at 1:58 PM, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > I do not > think cron jobs that output something every time they are run just in case > are nice. I agree. Those are usually, crappy cronjobs and should be fixed to work like most unix tools, and output only on failure. > I do not think the way we let systems install without a configured smtp > backend is good. If cron mails were actually pushed by default the bad > crons would be fixed before doing any real damage. A lot of the problems > people complain of here are the direct product of not configuring the smtp > backend a install time for years. EXACTLY. Improving the INSTALLER and firstlogin experience is what is needed here, NOT removing MTA. > I do not think the default cron message envelope is any good. It does not > make enough effort to identify the system and cron job which is failing, > and is not localized. This is another area to improve. Again NOT removing MTA, but using it smarter. > I do think the only widely deployed vendor-agnostic remote messaging > infrastructure is the mail infrastructure. All the other solutions require > always-on receiving nodes, that end-users can not afford. > https://admin.fedoraproject.org/mailman/listinfo/devel Mail has its faults, but is the best option that is universally available. Let's build upon it rather than abandoning it. i.e.: If message authentication is a concern, the system should sign the messages before sending. On Mon, Jul 22, 2013 at 2:00 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > If you argue from the viewpoint of how universially available an API is > to make it "standard", then I would like to remind you that there are > probably more Ubuntu installations in the world thatn Fedora > installations, and they haven't included any MTA by default in 6 years > or so. Good to know. I see not how that is relevant. If anything, knowing that only further demonstrates what a horrific idea No Default MTA is. On Mon, Jul 22, 2013 at 2:15 PM, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > Le Lun 22 juillet 2013 20:52, Lennart Poettering a écrit : > >> This is not a valid argument. We cannot keep extending the core all the >> time by adding more and more redundant components to them, just because >> we believe this will cause APIs to be tested. > > No one is asking to extend the core. You are asking to redefine it that's > not the same. > >> Also, what kind of a picture does this paint of the Fedora project >> anyway? Only stuff we install by default matters and is tested? > > Not configuring what we install does not paint a good image of the > project. OTOH, the MTAs themselves are several orders of magnitude more > robust than all the other bits we install (including, right now, systemd). I would love to see the day systemd is as polished, ubiquitous, and robust as smtp. But until that happens, nobody is helped by removing MTA from the default install. We're not there yet, and theres no guarantee we ever will be. Init systems come and go every few years. Sendmail and MTAs in general have been around to witness them all. SMTP has been around longer than Linux, and it will still be in use when systemd is obsoleted by the next big thing. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
