Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Le Mar 21 mai 2013 00:12, Kevin Fenzi a écrit : Lots of things use /etc/aliases... In fact, /etc/aliases should be set up by anaconda or firstboot with the main user mail. We've been hearing for years from desktop people a MTA was bad, heavy and difficult to use but after years of rants they've still *not* managed to supply a suitable replacement for remote notification and even sendmail is less a configuration hell than GNOME these days. Better a legacy system that works well than endless experiments scraped before they reach the usable stage. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, 20 May 2013 20:20:56 -0400 Nico Kadel-Garcia nka...@gmail.com wrote: The only MTA I've seen handlie both SMARTHOST and /etc/aliases correctly was exim,. which is no longer included by default and for which the necessary configuration is not widely published nor in the default documentation. http://www.uit.co.uk/BK-EOGR4/HomePage -- Regards, Frank - I check for new mail app. 20min www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Tue, May 21, 2013 at 10:10:33AM +0200, Nicolas Mailhot wrote: Le Mar 21 mai 2013 00:12, Kevin Fenzi a écrit : Lots of things use /etc/aliases... In fact, /etc/aliases should be set up by anaconda or firstboot with the main user mail. We did this in BU Linux. Specificially, we made an alias which directed root mail to all members of the wheel group. We had this related RFE in bugzilla a few (heh) years ago: https://bugzilla.redhat.com/show_bug.cgi?id=135592 And also, related: https://bugzilla.redhat.com/show_bug.cgi?id=143437 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, 20.05.13 21:36, Reindl Harald (h.rei...@thelounge.net) wrote: by default all mail messages go to root which you need root permissions to access them so it's not really an argument and on most setups i know /etc/aliases contains root: whoe...@domain.tld and the *main* difference is that you have to search in your logs manually and mails are coming if whatever event happened directly to your inbox if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time until you watched the event in the syslog other people have replaced the drive long ago, where i work it takes 3-5 hours to get a spare drive You know, I never doubted that delivering this by mail is very useful. However, the discussion is about defaults, and doing what you suggest above is already a departure from defaults (after all you edited /etc/aliases). But if you change configuration then you can also do yum install sendmail as part of your configuration change... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, 20.05.13 22:33, Reindl Harald (h.rei...@thelounge.net) wrote: You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. you have *ntohing* to configure you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this Well, that's quite contradictory, no? At least in my eyes /etc/aliases is configuration. Anyway, I filed this bug against rawhide now: https://bugzilla.redhat.com/show_bug.cgi?id=965728 Let's see where this goes... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, May 15, 2013 at 4:24 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, May 15, 2013 at 09:11:32AM -0600, Kevin Fenzi wrote: Perhaps interested parties could get behind/revive: https://fedoraproject.org/wiki/Features/NoMTA and finish it out for f20? *nod* Hmmm -- Percentage of completion: 98% seems optimistic. :) In fact it's been like that for most of the standard desktop spins where there's not a hard requitement for a MTA for quite some time with the only requirement to remove it to change sendmail from default to optional. In fact some of the desktops explicitly -sendmail in the live images to remove it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Thu, May 16, 2013 at 12:17 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Wed, May 15, 2013 at 10:30 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 15.05.13 09:08, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Dan Mashal dan.mas...@gmail.com said: Sanity: Switching to postfix? That's a long-time sore point, but the general idea is that sanity is not switching desktops/non-mail-servers from one full-featured MTA to another. The right move is to either remove a local MTA from the default install (which I think has been worked on), or switch to a light-weight daemon that is a local queue-and-forward mail handler. The downside of that would be that configuration of an upstream mail server (possibly requiring SSL and/or authentication) would be required for it to work, while sendmail/postfix/etc. can actually deliver messages (modulo other servers' spam filtering) in the default config. I am pretty sure that the big majority of mail servers on the internet still accept mails from servers in this default mode. Look again. The recent defaults for postfix and sendmail accept mail from localhost only. It may actually be another MTA sending to localhost, but that's usually above and beyond the call of weirdness. An unconfigured mail server doesn't really do anything good. And stuff that needs configuration before being useful shouldn't be in the default install. Except that it is configured. It accepts and delivers email locally, and accepts mail from other tools (such as Nagios, Hypermail, or nightly cron jobs) that expect to be able to send mail using the local daemon, by default. I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. The convention now is to use /usr/lib/sendmail, which is an old, old hardcoded standard in a lot of software and which the update-alternatives tool activates for any installed SMTP server in Fedora's configurations. It works, and there is a *lot* of software that tacitly assumes a locally available SMTP server for error reporting. That would allow people who want everything via logs to get everything via logs. It would make our basic installed set smaller, and boot-up faster. And people who want a mail server can just install one and configure it and things will be magically hooked up with everything else. Lennart I suggest not, because in most cases reviewing syslogs requires local root privilege. Alert or warning emails are easily configured with aliases or MAILTO settings for cron jobs to go somewhere safer and less security sensitive, even somewhere offsite, with much less work. by default all mail messages go to root which you need root permissions to access them so it's not really an argument. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Am 20.05.2013 21:30, schrieb Peter Robinson: I suggest not, because in most cases reviewing syslogs requires local root privilege. Alert or warning emails are easily configured with aliases or MAILTO settings for cron jobs to go somewhere safer and less security sensitive, even somewhere offsite, with much less work. by default all mail messages go to root which you need root permissions to access them so it's not really an argument and on most setups i know /etc/aliases contains root: whoe...@domain.tld and the *main* difference is that you have to search in your logs manually and mails are coming if whatever event happened directly to your inbox if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time until you watched the event in the syslog other people have replaced the drive long ago, where i work it takes 3-5 hours to get a spare drive signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, May 20, 2013 at 8:36 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 20.05.2013 21:30, schrieb Peter Robinson: I suggest not, because in most cases reviewing syslogs requires local root privilege. Alert or warning emails are easily configured with aliases or MAILTO settings for cron jobs to go somewhere safer and less security sensitive, even somewhere offsite, with much less work. by default all mail messages go to root which you need root permissions to access them so it's not really an argument and on most setups i know /etc/aliases contains root: whoe...@domain.tld and the *main* difference is that you have to search in your logs manually and mails are coming if whatever event happened directly to your inbox You still have to configure it so doing a yum install your-mta-of-choice isn't hard and in fact in all environments I know of that have auto monitoring and alerting of drive failures configure it automatically as part of a kickstart or puppet deployment and use snmp rather than email to deal with that and have active alert systems. if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. until you watched the event in the syslog other people have replaced the drive long ago, where i work it takes 3-5 hours to get a spare drive Where I work the manufacturer ships a person with the new drive and they deal with it. It's a mute point though, auto alerting whether by mail or snmp needs other configuration of which a yum install MTA or adding of a MTA into a kickstart isn't exactly a hard task. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Am 20.05.2013 22:27, schrieb Peter Robinson: You still have to configure it so doing a yum install your-mta-of-choice isn't hard and in fact in all environments I know of that have auto monitoring and alerting of drive failures configure it automatically as part of a kickstart or puppet deployment and use snmp rather than email to deal with that and have active alert systems you refer to enterprise environments i live in both, real enterprise and SOHO if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. you have *ntohing* to configure you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this until you watched the event in the syslog other people have replaced the drive long ago, where i work it takes 3-5 hours to get a spare drive Where I work the manufacturer ships a person with the new drive and they deal with it. It's a mute point though, auto alerting whether by mail or snmp needs other configuration of which a yum install MTA or adding of a MTA into a kickstart isn't exactly a hard task. nobody needs kickstart on single machines in a SOHO environment signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, May 20, 2013 at 9:33 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 20.05.2013 22:27, schrieb Peter Robinson: You still have to configure it so doing a yum install your-mta-of-choice isn't hard and in fact in all environments I know of that have auto monitoring and alerting of drive failures configure it automatically as part of a kickstart or puppet deployment and use snmp rather than email to deal with that and have active alert systems you refer to enterprise environments i live in both, real enterprise and SOHO if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. you have *ntohing* to configure you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this So your telling me your still using sendmail? until you watched the event in the syslog other people have replaced the drive long ago, where i work it takes 3-5 hours to get a spare drive Where I work the manufacturer ships a person with the new drive and they deal with it. It's a mute point though, auto alerting whether by mail or snmp needs other configuration of which a yum install MTA or adding of a MTA into a kickstart isn't exactly a hard task. nobody needs kickstart on single machines in a SOHO environment And if that's the case it's not hard to do yum install MTA either Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Am 20.05.2013 22:43, schrieb Peter Robinson: you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this So your telling me your still using sendmail? what the hell has /etc/aliases with sendmail to do? And if that's the case it's not hard to do yum install MTA either it would not be hard to do a lot of things manually if they are needed but the *make it idiot proof attitude* which makes me crazy in so many cases is more important for Fedora and when it comes to well known unix principles it does not matter? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Hi On Mon, May 20, 2013 at 4:46 PM, Reindl Harald wrote: Am 20.05.2013 22:43, schrieb Peter Robinson: you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this So your telling me your still using sendmail? what the hell has /etc/aliases with sendmail to do? As you have been told from time to time, there is really no need to swear. Can you pay attention to that? If you using a different MTA anyway, it doesn't matter to you whether sendmail is installed by default or not. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Am 20.05.2013 23:55, schrieb Rahul Sundaram: On Mon, May 20, 2013 at 4:46 PM, Reindl Harald wrote: Am 20.05.2013 22:43, schrieb Peter Robinson: you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this So your telling me your still using sendmail? what the hell has /etc/aliases with sendmail to do? As you have been told from time to time, there is really no need to swear. Can you pay attention to that? If you using a different MTA anyway, it doesn't matter to you whether sendmail is installed by default or not. read again the provocation i answered hint1: /etc/aliases is valid even for people who *never* used sendmail and no indication that someone *still* uses sendmail and if Peter likes to punish anybody because sendmail he better should ask why fedora still ships this antique piece of code hint2: postfix is using /etc/aliases signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Lots of things use /etc/aliases... I think we are drifting off point here. 1. If we ship no mta then things would be logged only and people would have to know to look there. 2. If we ship a non local delivery mta (ssmtp/esmtp, etc), then we need a way to ask the user 'what email address should get root emails from this machine'. 3. If we ship sendmail/postfix/exim we can keep on as we are now, since they can do local delivery out of the box. However, user needs to login as root or otherwise check emails for root or configure it to send to another email address they check or they are basically in the same boat as log only. However, people already might be expecting this behavior. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, May 20, 2013 at 11:12 PM, Kevin Fenzi ke...@scrye.com wrote: Lots of things use /etc/aliases... I think we are drifting off point here. 1. If we ship no mta then things would be logged only and people would have to know to look there. 2. If we ship a non local delivery mta (ssmtp/esmtp, etc), then we need a way to ask the user 'what email address should get root emails from this machine'. 3. If we ship sendmail/postfix/exim we can keep on as we are now, since they can do local delivery out of the box. However, user needs to login as root or otherwise check emails for root or configure it to send to another email address they check or they are basically in the same boat as log only. However, people already might be expecting this behavior. My point was never ever about /etc/aliases and what uses it, I'm aware that a lot uses it. My point was always that even with a default MTA whether that be sendmail or any of others the standard user currently has to do, and know they have to do, a manual configuration as the root user so as it stands even though we ship a MTA by default it is of no use to identify to the local users of the system that something is wrong with the system without further configuration and as a result we may as well not ship one. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, 2013-05-20 at 21:27 +0100, Peter Robinson wrote: if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. For basic local delivery, configuration is not required. Mail to root, any default aliases of root, and any existing local user is delivered with sendmail's OOTB configuration, to /var/spool/mail where you can read it. -- 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: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, 20 May 2013 15:55:24 -0700 Adam Williamson awill...@redhat.com wrote: On Mon, 2013-05-20 at 21:27 +0100, Peter Robinson wrote: if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. For basic local delivery, configuration is not required. Mail to root, any default aliases of root, and any existing local user is delivered with sendmail's OOTB configuration, to /var/spool/mail where you can read it. Sure, but do many users do? Or does it sit there until the end of time? Would more or less folks read logs? It seems kinda a toss up to me. On one hand folks who have been around a while might well read root emails. On the other hand, anyone seeing problems would probably be more likely to check logs than know they should read root emails off hand. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, 2013-05-20 at 16:12 -0600, Kevin Fenzi wrote: 3. If we ship sendmail/postfix/exim we can keep on as we are now, since they can do local delivery out of the box. However, user needs to login as root or otherwise check emails for root or configure it to send to another email address they check or they are basically in the same boat as log only. However, people already might be expecting this behavior. There is a notable distinction here: for the case of any kind of notification system set up to work by delivering mails locally, if we install a local-delivery capable MTA out of the box, you only have to anything 'special' in order to *consume* the notifications. They are always at least generated and delivered; at any point you perform the configuration, you find all the notifications that have previously been delivered. If we were to ship a relay-only MTA, or no MTA, by default, then this would not be the case. Until you performed the 'special configuration' (install an MTA or configure the relay-only MTA), the messages would be lost. Well, the relay-only MTA might queue them for a while, but I doubt it would forever. Without an MTA, anything that tries to send mail will just get a fatal error. So you would lose all the messages that tried to be sent up until the point you actually configured your MTA. I don't necessarily think these points are significant enough to merit shipping a full MTA by default still, but I think it's important that we have as accurate as possible a picture of all the scenarios. -- 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: Default-installed MTA (was Re: MTA virtual provides craziness)
Le lundi 20 mai 2013 à 17:01 -0600, Kevin Fenzi a écrit : On Mon, 20 May 2013 15:55:24 -0700 Adam Williamson awill...@redhat.com wrote: On Mon, 2013-05-20 at 21:27 +0100, Peter Robinson wrote: if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. For basic local delivery, configuration is not required. Mail to root, any default aliases of root, and any existing local user is delivered with sendmail's OOTB configuration, to /var/spool/mail where you can read it. Sure, but do many users do? Or does it sit there until the end of time? I think it may not be rotated, so in the long run, with enough verbose cronjob, you will fill your hard drive. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Mon, May 20, 2013 at 4:33 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 20.05.2013 22:27, schrieb Peter Robinson: You still have to configure it so doing a yum install your-mta-of-choice isn't hard and in fact in all environments I know of that have auto monitoring and alerting of drive failures configure it automatically as part of a kickstart or puppet deployment and use snmp rather than email to deal with that and have active alert systems you refer to enterprise environments i live in both, real enterprise and SOHO if a disk dies it is nice to have it in syslog but it is useless if you see it days later while a mail from crond is more or less real time You still have to configure all of that and whether a MTA is installed automatically or not doesn't really make it work out of the box. you have *ntohing* to configure you only need to edit *one line* in /etc/aliases everybody who knows unix-like systems knows this I'm afraid not. You have to make some other choices. If your envornment uses outbound port 25 blocking, and particularly enforces a SMARTHOST, either you allow /etc/aliases (with sendmail) but give up auto-forwarding of local email to the SMARTHOST, or you use Postfix and /etc/aliases and $HOME/.forward are ignored. The only MTA I've seen handlie both SMARTHOST and /etc/aliases correctly was exim,. which is no longer included by default and for which the necessary configuration is not widely published nor in the default documentation. There's also the sendmail problem of having the system's output of hostname --fqdn be listed in /etc/hosts as the first entry, or reliably available in DNS at boot time, in order to start the sendmail daemon without a galling 5 minute wait that is just nasty in a production environment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
On 15 May 2013 06:49, Dan Mashal dan.mas...@gmail.com wrote: On Tue, May 14, 2013 at 6:10 PM, Adam Williamson awill...@redhat.com wrote: We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) This seems a tad excessive. exim and postfix provide all four. sendmail provides MTA, smtpdaemon and server(smtp). Nothing else provides any of them (though if we could just agree on what any of them meant or what they were for, probably esmtp and ssmtp might want to). Nothing requires 'smtpd'. One thing each requires each of the others, just to make things nice and complicated: [root@adam blivet (master %)]# repoquery --whatrequires MTA ratbox-services-0:1.2.1-8.fc19.x86_64 [root@adam blivet (master %)]# repoquery --whatrequires server(smtp) sagator-core-0:1.2.3-6.fc19.noarch [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon vacation-0:1.2.7.1-3.fc19.x86_64 Good lord. Anyone feel like injecting any sanity? Anyone have a long enough memory to know what the hell each of the different provides is meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were meant to express subtly different things, but I can't remember any details. Sanity: Switching to postfix? That's a matter of opinion and completely unhelpful to this discussion. Adam, like you I seem to remember a subtle difference between MTA and the others. I think its because some MTAs only do local delivery, some do remote and some can do both. Eg sendmail needs procmail to handle the local part from distant memory. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
Le mercredi 15 mai 2013 à 07:45 +0100, Peter Robinson a écrit : Adam, like you I seem to remember a subtle difference between MTA and the others. I think its because some MTAs only do local delivery, some do remote and some can do both. Eg sendmail needs procmail to handle the local part from distant memory. The way I see the issue, a software would likely need a interface, ie something that provides /usr/bin/sendmail with this set of supported option. We cannot requires directly this file due to alternative ( I think ), so we may need a Requires/Provides for that. I do not see why a rpm would need to express I need to have something listening on port 25 or anything like that ( and so pull smtpd or anything like this ), from a network point of view ( since anything using the network could use a different host, so this mean a Requires is not the good way to express this dependency ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default-installed MTA (was Re: MTA virtual provides craziness)
Once upon a time, Dan Mashal dan.mas...@gmail.com said: Sanity: Switching to postfix? That's a long-time sore point, but the general idea is that sanity is not switching desktops/non-mail-servers from one full-featured MTA to another. The right move is to either remove a local MTA from the default install (which I think has been worked on), or switch to a light-weight daemon that is a local queue-and-forward mail handler. The downside of that would be that configuration of an upstream mail server (possibly requiring SSL and/or authentication) would be required for it to work, while sendmail/postfix/etc. can actually deliver messages (modulo other servers' spam filtering) in the default config. The core problem is that there's a general long-time Unix assumption that piping something to /usr/sbin/sendmail and/or connecting a TCP socket to localhost:smtp can send email, and so many things don't explicitly specify that need. The idea is that /usr/sbin/sendmail handles connecting to the right host, aliasing, etc. Just to pick an example: mdadm (for Linux software RAID) has a monitor mode to notify somebody of disk failures. Failures would already go in the system log (from the kernel); running mdadm --monitor is for sending a more active notice. It is possible for mdadm to run an external alert program; on a desktop, that could use the system bus to notify the logged-in user. How do you handle a headless system, a desktop with nobody logged in, etc.? The only standard way to notifiy somebody off the box is SMTP (I suppose mdadm could use SNMP traps, but that's even more work to configure correctly). You could have mdadm implement a full SMTP client (and hope the network isn't down), but that's what /usr/sbin/sendmail is for. I'm not saying that these are insurmountable issues, just that that's where things stand today (to my knowledge). -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, 15.05.13 09:08, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Dan Mashal dan.mas...@gmail.com said: Sanity: Switching to postfix? That's a long-time sore point, but the general idea is that sanity is not switching desktops/non-mail-servers from one full-featured MTA to another. The right move is to either remove a local MTA from the default install (which I think has been worked on), or switch to a light-weight daemon that is a local queue-and-forward mail handler. The downside of that would be that configuration of an upstream mail server (possibly requiring SSL and/or authentication) would be required for it to work, while sendmail/postfix/etc. can actually deliver messages (modulo other servers' spam filtering) in the default config. I am pretty sure that the big majority of mail servers on the internet still accept mails from servers in this default mode. An unconfigured mail server doesn't really do anything good. And stuff that needs configuration before being useful shouldn't be in the default install. The core problem is that there's a general long-time Unix assumption that piping something to /usr/sbin/sendmail and/or connecting a TCP socket to localhost:smtp can send email, and so many things don't explicitly specify that need. The idea is that /usr/sbin/sendmail handles connecting to the right host, aliasing, etc. Just to pick an example: mdadm (for Linux software RAID) has a monitor mode to notify somebody of disk failures. Failures would already go in the system log (from the kernel); running mdadm --monitor is for sending a more active notice. It is possible for mdadm to run an external alert program; on a desktop, that could use the system bus to notify the logged-in user. How do you handle a headless system, a desktop with nobody logged in, etc.? The only standard way to notifiy somebody off the box is SMTP (I suppose mdadm could use SNMP traps, but that's even more work to configure correctly). I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. That would allow people who want everything via logs to get everything via logs. It would make our basic installed set smaller, and boot-up faster. And people who want a mail server can just install one and configure it and things will be magically hooked up with everything else. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, May 15, 2013 at 04:30:35PM +0200, Lennart Poettering wrote: I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. I'm in support of this general idea, but I think it's a big enough change that we should probably do it as a feature -- mdadm is a key example but probably not the only thing. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, 15 May 2013 10:56:39 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, May 15, 2013 at 04:30:35PM +0200, Lennart Poettering wrote: I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. I'm in support of this general idea, but I think it's a big enough change that we should probably do it as a feature -- mdadm is a key example but probably not the only thing. Perhaps interested parties could get behind/revive: https://fedoraproject.org/wiki/Features/NoMTA and finish it out for f20? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Am 15.05.2013 16:08, schrieb Chris Adams: The core problem is that there's a general long-time Unix assumption that piping something to /usr/sbin/sendmail and/or connecting a TCP socket to localhost:smtp can send email, and so many things don't explicitly specify that need. The idea is that /usr/sbin/sendmail handles connecting to the right host, aliasing, etc. and the assumption is fine as it comnes to more than a desktop hence that is why you can simply write any script in any language run it as cronjob and if it spits out anything you get a mail notify cronjobs like rkhunter use this assumption this behavior is *perfect* a sane script in this context is silent until errors warnings signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, May 15, 2013 at 09:11:32AM -0600, Kevin Fenzi wrote: Perhaps interested parties could get behind/revive: https://fedoraproject.org/wiki/Features/NoMTA and finish it out for f20? *nod* Hmmm -- Percentage of completion: 98% seems optimistic. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
Adam Williamson (awill...@redhat.com) said: We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) smtpdaemon's the oldest one, dating back to at least 1997, so should be standard. smtpd and MTA came along in 2000 when postfix and exim were imported into powertools, so likely came from Simon Mudd (who did the original package before it was imported.) So... accident? server(smtp) was added in 2007 for https://bugzilla.redhat.com/show_bug.cgi?id=380621, as part of a Fedora proposed feature/packaging standard. I don't know that this standard was ever accepted - if it was, we should nuke the rest. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, May 15, 2013 at 10:30 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 15.05.13 09:08, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Dan Mashal dan.mas...@gmail.com said: Sanity: Switching to postfix? That's a long-time sore point, but the general idea is that sanity is not switching desktops/non-mail-servers from one full-featured MTA to another. The right move is to either remove a local MTA from the default install (which I think has been worked on), or switch to a light-weight daemon that is a local queue-and-forward mail handler. The downside of that would be that configuration of an upstream mail server (possibly requiring SSL and/or authentication) would be required for it to work, while sendmail/postfix/etc. can actually deliver messages (modulo other servers' spam filtering) in the default config. I am pretty sure that the big majority of mail servers on the internet still accept mails from servers in this default mode. Look again. The recent defaults for postfix and sendmail accept mail from localhost only. It may actually be another MTA sending to localhost, but that's usually above and beyond the call of weirdness. An unconfigured mail server doesn't really do anything good. And stuff that needs configuration before being useful shouldn't be in the default install. Except that it is configured. It accepts and delivers email locally, and accepts mail from other tools (such as Nagios, Hypermail, or nightly cron jobs) that expect to be able to send mail using the local daemon, by default. I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. The convention now is to use /usr/lib/sendmail, which is an old, old hardcoded standard in a lot of software and which the update-alternatives tool activates for any installed SMTP server in Fedora's configurations. It works, and there is a *lot* of software that tacitly assumes a locally available SMTP server for error reporting. That would allow people who want everything via logs to get everything via logs. It would make our basic installed set smaller, and boot-up faster. And people who want a mail server can just install one and configure it and things will be magically hooked up with everything else. Lennart I suggest not, because in most cases reviewing syslogs requires local root privilege. Alert or warning emails are easily configured with aliases or MAILTO settings for cron jobs to go somewhere safer and less security sensitive, even somewhere offsite, with much less work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
MTA virtual provides craziness
We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) This seems a tad excessive. exim and postfix provide all four. sendmail provides MTA, smtpdaemon and server(smtp). Nothing else provides any of them (though if we could just agree on what any of them meant or what they were for, probably esmtp and ssmtp might want to). Nothing requires 'smtpd'. One thing each requires each of the others, just to make things nice and complicated: [root@adam blivet (master %)]# repoquery --whatrequires MTA ratbox-services-0:1.2.1-8.fc19.x86_64 [root@adam blivet (master %)]# repoquery --whatrequires server(smtp) sagator-core-0:1.2.3-6.fc19.noarch [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon vacation-0:1.2.7.1-3.fc19.x86_64 Good lord. Anyone feel like injecting any sanity? Anyone have a long enough memory to know what the hell each of the different provides is meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were meant to express subtly different things, but I can't remember any details. -- 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: MTA virtual provides craziness
On Tue, May 14, 2013 at 6:10 PM, Adam Williamson awill...@redhat.com wrote: We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) This seems a tad excessive. exim and postfix provide all four. sendmail provides MTA, smtpdaemon and server(smtp). Nothing else provides any of them (though if we could just agree on what any of them meant or what they were for, probably esmtp and ssmtp might want to). Nothing requires 'smtpd'. One thing each requires each of the others, just to make things nice and complicated: [root@adam blivet (master %)]# repoquery --whatrequires MTA ratbox-services-0:1.2.1-8.fc19.x86_64 [root@adam blivet (master %)]# repoquery --whatrequires server(smtp) sagator-core-0:1.2.3-6.fc19.noarch [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon vacation-0:1.2.7.1-3.fc19.x86_64 Good lord. Anyone feel like injecting any sanity? Anyone have a long enough memory to know what the hell each of the different provides is meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were meant to express subtly different things, but I can't remember any details. Sanity: Switching to postfix? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
