LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsFedora keeps sendmail — for nowThe Fedora distribution prides itself on its image as a leading-edge Linux distribution where new stuff shows up first. But, as some developers recently discovered to their chagrin, that image does not necessarily extend to deleting features first. After an extensive debate, the Fedora project has decided, for now, to retain the sendmail mail transfer agent — a program that is many years older than Linux — in the default installation. Whether this outcome is a victory for Fedora's "stone age faction" or a careful defense of Fedora's Unix tradition is very much in the eye of the beholder.The no default sendmail proposal, intended for the Fedora 20 development cycle, had a simple goal: remove sendmail from the "core" and "standard" package groups, so that sendmail would not be installed by default in Fedora's minimal or desktop configurations. Sendmail would, of course, remain as an option for anybody who wanted to install it separately. The simplest ideas are often those most subject to discussion, though; in this case, the proposal set off an email thread that was epic even by the standards of the Fedora development list. The proponents of the change (Lennart Poettering and Matthew Miller) argued that there was little use for a mail transfer agent (MTA) installed by default. On today's Internet, there is no way to configure an MTA so that it comes up in a working configuration by default. Many or most Fedora users run in a situation where mail cannot be sent directly from (or to) their systems anyway, due to Internet service provider blocking policies and anti-spam measures taken at remote sites. Sendmail is set up to deliver mail into /var/spool/mail — a location that no mail user agent in the default Fedora install reads. So, it is said, there is little value in having sendmail around. Going on, they argue that there are some costs to installing sendmail by default. Sendmail's time as a constant source of severe security problems is long past, but it is still a privileged program that need not be installed much of the time. Removing sendmail would reduce the distribution's disk space requirements and decrease system boot time. Ubuntu has not installed an MTA by default for years; systems like Mac OS X also install without an MTA. And in the end, Lennart and Matthew argued, even if Fedora were to install an MTA by default, sendmail is a bit of a peculiar choice. The opposition to the proposal is a bit harder to summarize. A number of participants cited the fact that cron jobs send email if they produce unexpected output. In the absence of an MTA, that output goes instead to the system log which, for some, is a place where it can get lost in the noise. Miloslav Trmač suggested that the /usr/sbin/sendmail binary forms a sort of API by which applications can reliably send email; in its absence, those applications would have to grow their own SMTP implementations, which might not lead to a better system overall. Some of the arguments against the removal of sendmail expressed a vague feeling that an MTA is an important and traditional component of a Unix system. Removing sendmail would take Fedora (further) away from that tradition, making some people uncomfortable. Having sendmail in the mix does not bother people who are not using it, they said, and anybody who really objects to its presence can always uninstall it. So, rather than making such a fundamental change to the system, it would be better to come up with a better set of default configurations for the mail transfer and user agents installed with the distribution. The discussion went back and forth for some time while, seemingly, convincing few of the participants. Some Fedora users evidently value getting cron output in email, while others point out that, on most systems, it piles up unnoticed in /var/spool/mail and might as well be discarded. For the latter camp, the logging subsystem is clearly a better way for system daemons to communicate results to users or administrators, but discussions around the logging system tend to turn into an even bigger can of worms in short order. Arguments based on tradition almost never get anywhere with those who are determined to change that tradition — or leave it behind altogether. The Fedora Engineering Steering Committee (FESCo) met on July 24 to (among other agenda items) make a decision on this issue. The discussion there was rather shorter; it can be found in the IRC log. In the end, the board voted unanimously to remove sendmail from the minimal "core" group. When it came to the "standard" group (which is what matters for most installations), though, the proposal faltered, eventually failing on a 4-4 vote after Matthew, despite having proposed the change, abstained from the actual vote as a gesture of respect for those who wanted to take a slower, more careful approach. So a Fedora 20 desktop installation will include sendmail. It is fair to say that Lennart did not react well to the decision:
If FESCO decides that Fedora's home is the stone age, then that's
fine, I don't think I have to care anymore. They should really
drop the "F" for "First" though from their 4-F motto, it's a blunt
lie. Fedora is seldom first on anything non-trivial, anymore. It is
just another conservative distribution. Sendmail is just the
pinnacle of it. I mean, really? sendmail???
In truth, some progress has been made toward Lennart's goal, and some developers have expressed an interest in trying again for the Fedora 21 development cycle. Fedora, as a Linux distribution, does have a lot of roots in the Unix tradition. It also has a number of users who have been with the distribution (and its predecessor, Red Hat Linux) for a very long time. Ways of working that have been established over decades can be awfully hard to change, especially when the people involved see no reason why they should change. It is, thus, unsurprising that the people who are trying to drive significant changes run into a certain type of conservatism at times. What matters is how the system evolves over the long term. There are few who would say that Unix (or Linux) in any of its forms is the pinnacle of computing. The Linux systems we use ten years from now will certainly look quite different from what we have now — either that, or we'll not be using Linux at all. Chances are that distant-future Linux distributions will not have sendmail installed by default. In the meantime, though, proponents of change can expect to have to work through some resistance at times; that is, after all, how human communities work.
Brief items Distribution quotes of the week
But if they have a vested interest in Fedora, RHEL, CentOS and other
downstreams using some bit of technology, if they have a vested interest in
getting their code and ideas out to that userbase... participate. Convince.
Collaborate. To do otherwise, and just assume someone else will do that for
them, seems foolish to me.
-- Bill Nottingham
Differentiation is key... floppy support is a key differentiator and a really smart move. Someone is going to kickstart a retro-computing tablet that looks just like a 5 1/4 inch floppy, with a slot for a 3 1/2 inch not-so-floppy disk.. and we will be there on day one..and it will be glorious.
-- Jef
Spaleta (in the comments)
Distribution News Fedora Fedora 17 End of LifeFedora 17 has reached its end-of-life. There will be no further updates, including security updates. See this page for instructions on upgrading to Fedora 18 or later using FedUp.
Red Hat Enterprise Linux Red Hat Enterprise Linux 3 Extended Lifecycle Support 6-Month NoticeRed Hat has sent out a notice that Red Hat Enterprise Linux 3 Extended Lifecycle Support will end in six months.
Newsletters and articles of interest Distribution newsletters
Kondik: The death of rootOne significant change in the Android 4.3 release is that it has become harder to obtain and make use of root privileges. Steve "Cyanogen" Kondik ponders how CyanogenMod will respond to this change; it may not involve restoring easy root access. "+Koushik Dutta and +Chainfire are working hard to permit root in some way on 4.3, but I feel that anything done at this point might severely compromise the security of the system and we should start considering better options. Going forward, I'm interested in building framework extensions and APIs into CM to continue to abolish the root requirement."
Page editor: Rebecca Sobol |
|||||||||||||