Features/NoMTA

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Scope: add run-parts modification plan, reduce package list to things that don't get run through run-parts)
(Update TODO/Done)
 
(11 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
== Summary ==
 
== Summary ==
Don't ship a MTA by default for the desktop.
+
Make the MTA (i.e. <code>/usr/sbin/sendmail</code>) optional.
  
 
== Owner ==
 
== Owner ==
Line 8: Line 8:
  
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
* email: maxamillion [AT] gmail.com
+
* email: maxamillion [AT] fedoraproject.org
  
 
== Current status ==
 
== Current status ==
 
* Targeted release: [[Releases/13 | Fedora 13 ]]  
 
* Targeted release: [[Releases/13 | Fedora 13 ]]  
* Last updated: 2009-08-27
+
* Last updated: 12 April 2011
* Percentage of completion: 0%
+
* Percentage of completion: 98%
  
Working:
+
=== Done ===
  
* Everything as designed
+
* Patch {{package|cronie}} to redirect messages that would be sent to a MTA to syslog in the event a MTA is not present.
 +
** Patch submitted in {{bz|548843}}, applied to cronie-1.4.4, currently in F13.
 +
* Add sendmail to comps to ensure it is still installed by default, as expected
 +
** <code>sendmail</code> is listed in the <code>base</code> group.
 +
** This is for compatibility purposes and may be removed in a future release
 +
* Remove cronie's hard requirement on <code>/usr/sbin/sendmail</code>
  
TODO:
+
=== To-do ===
* Verify there are no packages that will require a patch to function without a MTA
+
 
 +
* Patch the default configuration for logwatch to not send mail, but to send messages to stdout and then verify the patch to cronie is reporting logwatch messages to syslog accordingly.
 +
 
 +
=== Extra credit ===
 +
 
 +
* Add comment to <code>/etc/sysconfig/crond</code> that shows how to use syslog instead of sendmail:
 +
# To send cron output to syslog instead of local mail, set CRONDARGS to:
 +
#CRONDARGS="-s -m off"
 +
* Verify there are no other packages that will require a patch to function without a MTA
  
 
== Detailed Description ==
 
== Detailed Description ==
The shipping of a default MTA has long been the de facto standard, but for the vast majority of users this is simply wasted resources and wasted disk space for the packages installed. Without an MTA the utilities that would have previously delivered local mail will just simply silently not deliver mail. Instead we can redirect the output to a log and those users who need a MTA are free to install any one they so choose.
+
The presence of a Mail Transfer Agent (MTA) like <code>sendmail</code> has long been the de facto standard. But most systems that aren't mail servers do not specifically need to keep local mail queues or transfer mail to other systems. For the vast majority of users this is simply wasted resources and wasted disk space for the packages installed.  
 +
 
 +
<code>cron</code> is the only thing in a default Fedora install that still uses local mail to report its status. The <code>cron</code> syslog facility exists for this purpose, and our current <code>cron</code> setup already uses it<ref><code>/usr/bin/run-parts</code> runs all the cron jobs in <code>/etc/cron.{hourly,daily,weekly,monthly}</code> - see <code>/etc/cron.d/0hourly</code> (which runs the jobs in <code>/etc/cron.hourly</code>) and <code>/etc/anacrontab</code> (which launches the daily/weekly/monthly jobs.)</ref> to log ''some'' messages<ref>In fact, our current setup does ''not'' log the output of cron jobs to <code>/var/log/cron</code> - this feature would fix that.</ref> to <code>/var/log/cron</code>.
 +
 
 +
This feature allows <code>cron</code> to optionally use syslog instead of email to report job status, thus making the presence of an MTA completely optional.
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
Less used disk space for default install, less used resources, stopping of the MTA madness.
+
One less required package in the critical path, and we clear the way for removing the MTA from the default install.
  
 
== Scope ==
 
== Scope ==
MTAs are not a necessary daemon on a desktop system, so we need not include one by default.
 
  
{{package|cronie}} is the only package in a default Fedora install that requests the use of an MTA. If <code>/usr/sbin/sendmail</code> is not present, it will simply stop sending mail. Therefore, if the existing cron jobs are modified so they don't need to send mail, we can remove the requirement for an MTA with no loss of functionality.
+
Packages that may require changes:
 +
* {{package|cronie}} - {{bz|472710}}
 +
* {{package|crontabs}}
 +
* {{package|logwatch}}
  
All cron jobs launched by files in <code>/etc/cron.{hourly,daily,weekly,monthly}</code> are run through the <code>/usr/bin/run-parts</code> script<ref>You can verify this by tracing how the jobs are launched - <code>/etc/cron.d/0hourly</code> runs the jobs in <code>/etc/cron.hourly</code> and <code>/etc/anacrontab</code> launches the daily/weekly/monthly jobs.</ref>. Therefore ''we can fix all these cron jobs by modifying <code>run-parts</code> to send stdout to syslog''.
+
=== cronie ===
  
The remaining cron jobs are launched by placing a file in <code>/etc/cron.d/</code>. These cron jobs will have to be examined and modified individually.
+
<code>cronie</code> is the only package in a default Fedora install that requests the use of an MTA. If <code>/usr/sbin/sendmail</code> is not present, it will simply stop sending mail. Therefore, if we modify <code>cronie</code> to send job output to a log file, we can remove the requirement for an MTA with no loss of functionality.
  
 
Required changes:
 
Required changes:
# Modify <code>run-parts</code> to send stdout to syslog (<code>/var/log/cron</code>)
+
# Modify <code>cronie</code> to send job output to the <code>cron</code> syslog facility if <code>sendmail</code> is missing
#* Add something like: <code>| logger -p cron.notice -t "$(basename $i)"</code>
+
# Change any <code>/etc/cron.d/</code> cron job that emits output to send its output to syslog or a log file
+
 
# Remove <code>Requires: /usr/sbin/sendmail</code> from {{package|cronie}}'s spec file
 
# Remove <code>Requires: /usr/sbin/sendmail</code> from {{package|cronie}}'s spec file
  
Packages that may require changes:
+
=== crontabs ===
* {{package|cronie}} - [https://bugzilla.redhat.com/show_bug.cgi?id=472710 RHBZ 472710]
+
 
* {{package|crontabs}}
+
<code>crontabs</code> need to be examined to be sure none of them depend on local mail being sent.
* Any package that places files in <code>/etc/cron.d</code> (see <code>repoquery --source -qf '/etc/cron.d/*'</code>)
+
 
** {{package|atop}}
+
=== logwatch ===
** {{package|cacti}}
+
 
** {{package|checkdns}}
+
<code>logwatch</code> needs to be examine to see if it actually depends on cron sending email, and patched to use stdout/syslog if so.
** {{package|clamav}}
+
** {{package|denyhosts}}
+
** {{package|dmraid}}
+
** {{package|dwatch}}
+
** {{package|glpi}}
+
** {{package|glpi-mass-ocs-import}}
+
** {{package|leafnode}}
+
** {{package|mailman}}
+
** {{package|mldonkey}}
+
** {{package|moodle}}
+
** {{package|mrepo}}
+
** {{package|mrtg}}
+
** {{package|munin}}
+
** {{package|nssbackup}}
+
** {{package|olpc-update}}
+
** {{package|olpc-utils}}
+
** {{package|ovirt-server}}
+
** {{package|queuegraph}}
+
** {{package|rancid}}
+
** {{package|sagator}}
+
** {{package|sbackup}}
+
** {{package|smolt}}
+
** {{package|spamassassin}}
+
** {{package|sysstat}}
+
** {{package|sysusage}}
+
** {{package|tiger}}
+
** {{package|vnstat}}
+
  
 
== How To Test ==
 
== How To Test ==
  
Uninstall sendmail on your current machine and enjoy the "no warning messages, no crashing, just blissful MTA-free silence" - wwoods
+
# Ensure you have <code>cronie-1.4.4-1.fc13</code> or higher installed.
 +
# Edit <code>/etc/sysconfig/crond</code> and set <code>CRONDARGS="-s -m off"</code>
 +
# <code>service crond restart</code>
 +
# Remove sendmail (or whichever package is providing your <code>/usr/sbin/sendmail</code>)
 +
#* e.g.: <code>yum remove $(rpm -qf /usr/sbin/sendmail)</code>
 +
# Verify that all output from cron jobs shows up in <code>/var/log/cron</code>
  
 
== User Experience ==
 
== User Experience ==
 
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
Transparent to majority of users, will add a 'yum install <insert-MTA-here>' step to advanced users who have an actual use case for a MTA on their machines.
+
Transparent to most users. System administrators or integrators who were relying on the implicit dependency on <code>/usr/bin/sendmail</code> may need to update their kickstart files etc. to explicitly install their chosen MTA.
  
 
== Dependencies ==
 
== Dependencies ==
 
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
 
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
none
+
* None
  
 
== Contingency Plan ==
 
== Contingency Plan ==
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
Do Nothing.
+
* None needed
  
 
== Documentation ==
 
== Documentation ==
Line 102: Line 97:
 
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
 
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
 
* None
 
* None
 +
 +
== References ==
 +
<references/>
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==
 
* See [[Talk:Features/NoMTA]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
 
* See [[Talk:Features/NoMTA]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
 
  
 
[[Category:FeaturePageIncomplete]]
 
[[Category:FeaturePageIncomplete]]

Latest revision as of 16:18, 12 April 2011

Contents

[edit] No MTA

[edit] Summary

Make the MTA (i.e. /usr/sbin/sendmail) optional.

[edit] Owner

  • email: maxamillion [AT] fedoraproject.org

[edit] Current status

  • Targeted release: Fedora 13
  • Last updated: 12 April 2011
  • Percentage of completion: 98%

[edit] Done

  • Patch Package-x-generic-16.pngcronie to redirect messages that would be sent to a MTA to syslog in the event a MTA is not present.
    • Patch submitted in RHBZ #548843, applied to cronie-1.4.4, currently in F13.
  • Add sendmail to comps to ensure it is still installed by default, as expected
    • sendmail is listed in the base group.
    • This is for compatibility purposes and may be removed in a future release
  • Remove cronie's hard requirement on /usr/sbin/sendmail

[edit] To-do

  • Patch the default configuration for logwatch to not send mail, but to send messages to stdout and then verify the patch to cronie is reporting logwatch messages to syslog accordingly.

[edit] Extra credit

  • Add comment to /etc/sysconfig/crond that shows how to use syslog instead of sendmail:
# To send cron output to syslog instead of local mail, set CRONDARGS to:
#CRONDARGS="-s -m off"
  • Verify there are no other packages that will require a patch to function without a MTA

[edit] Detailed Description

The presence of a Mail Transfer Agent (MTA) like sendmail has long been the de facto standard. But most systems that aren't mail servers do not specifically need to keep local mail queues or transfer mail to other systems. For the vast majority of users this is simply wasted resources and wasted disk space for the packages installed.

cron is the only thing in a default Fedora install that still uses local mail to report its status. The cron syslog facility exists for this purpose, and our current cron setup already uses it[1] to log some messages[2] to /var/log/cron.

This feature allows cron to optionally use syslog instead of email to report job status, thus making the presence of an MTA completely optional.

[edit] Benefit to Fedora

One less required package in the critical path, and we clear the way for removing the MTA from the default install.

[edit] Scope

Packages that may require changes:

[edit] cronie

cronie is the only package in a default Fedora install that requests the use of an MTA. If /usr/sbin/sendmail is not present, it will simply stop sending mail. Therefore, if we modify cronie to send job output to a log file, we can remove the requirement for an MTA with no loss of functionality.

Required changes:

  1. Modify cronie to send job output to the cron syslog facility if sendmail is missing
  2. Remove Requires: /usr/sbin/sendmail from Package-x-generic-16.pngcronie's spec file

[edit] crontabs

crontabs need to be examined to be sure none of them depend on local mail being sent.

[edit] logwatch

logwatch needs to be examine to see if it actually depends on cron sending email, and patched to use stdout/syslog if so.

[edit] How To Test

  1. Ensure you have cronie-1.4.4-1.fc13 or higher installed.
  2. Edit /etc/sysconfig/crond and set CRONDARGS="-s -m off"
  3. service crond restart
  4. Remove sendmail (or whichever package is providing your /usr/sbin/sendmail)
    • e.g.: yum remove $(rpm -qf /usr/sbin/sendmail)
  5. Verify that all output from cron jobs shows up in /var/log/cron

[edit] User Experience

Transparent to most users. System administrators or integrators who were relying on the implicit dependency on /usr/bin/sendmail may need to update their kickstart files etc. to explicitly install their chosen MTA.

[edit] Dependencies

  • None

[edit] Contingency Plan

  • None needed

[edit] Documentation

  • None

[edit] Release Notes

  • None

[edit] References

  1. /usr/bin/run-parts runs all the cron jobs in /etc/cron.{hourly,daily,weekly,monthly} - see /etc/cron.d/0hourly (which runs the jobs in /etc/cron.hourly) and /etc/anacrontab (which launches the daily/weekly/monthly jobs.)
  2. In fact, our current setup does not log the output of cron jobs to /var/log/cron - this feature would fix that.

[edit] Comments and Discussion