<insert witty comment that I'm up far too early to generate myself here>
Fedora 12 "Constantine" Alpha release is available! What's next for the free operating system that shows off the best new technology of tomorrow? You can see the future now at:
http://fedoraproject.org/get-prerelease
What's an Alpha release? The Alpha release contains all the features of Fedora 12 in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete, and bears a very strong resemblance to the third and final release. The final release of Fedora 12 is due in November.
We need your help to make Fedora 12 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it - every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution.
Among the top features for end users, we have:
Better webcam support - Out of the box support for a lot of new webcams has been extended further than ever.
Empathy as default IM client - Empathy is an instant messenger client replacing Pidgin, featuring better integration with the GNOME Desktop.
GNOME 2.27.90 beta and KDE 4.3 - The latest code from the two main desktop environments and their many bundled supporting applications are part of this release. GNOME 2.27.90 is the latest GNOME version as of the Alpha release; GNOME 2.28 is planned for the final release.
Network Manager Mobile Broadband - By providing a database of preconfigured mobile broadband providers, supporting more hardware and permit to scan GSM networks, NetworkManager makes the use of mobile broadband much easier.
Better Free Video Codec - The latest technology is found in the improved, free Ogg Theora video encoder, codenamed "Thusnelda." Encoded video at very high definition now can meet or exceed the expectations of the most demanding viewer and material.
PackageKit improvements - PackageKit now has plugins to install applications from a web browser, and from the command line if a user tries a command from a package not yet installed.
PulseAudio improvements - The PulseAudio volume control applet has been extended to support profiles, input switching and easy speaker setup.
Better power management - This release offers better power management features regarding CPU, disk and network I/O.
For developers there are all sorts of additional goodies:
NetBeans 6.7 - NetBeans 6.7 is the most recent version of Sun's IDE.
PHP 5.3 - PHP 5.3 has been integrated as the popular web language.
Eclipse 3.5.0 - The latest release of the popular, open, and extensible development platform is included.
SystemTap - Updates to this debugging capability include better documentation, tools, and examples; support for kernel tracepoint and modern gcc debuginfo ("dwarf") output; and Eclipse support for launching traces and graphing results.
Peek under the hood and there is still more:
Better IPv6 in NetworkManager - NetworkManager has been extended to fully support IPv6 configurations through the GUI.
Automatic Bug Reporting Tool - This release provides ABRT, a service that automatically reports application crashed to Fedora, without requiring the end user to have any special knowledge on error reporting.
RPM XZ payload - All the software packages in Fedora have been switched from Gzip to the more efficient XZ (LZMA) compression method, to save space on mirrors and reduce download times.
x86 optimized for Atom - The 32 bit version of this release will be compiled for i686 with a specific optimization for Intel Atom processors used in many netbooks.
GRUB ext4 support - Fedora 11 included Ext4 by default, however GRUB in that version did not support Ext4 and hence required a separate boot partition formatted as Ext3 or Ext2. This release includes an updated version of GRUB with Ext4 support.
Bluetooth Service On Demand - In order to support Bluetooth devices, the Bluetooth background service was started by default in previous versions of Fedora. In this release, the Bluetooth service is started on demand when needed, and automatically stops 30 seconds after last device use, reducing initial startup time and resources.
KVM improvements - Many improvements in KVM virtualization are found in this release: reduced memory consumption and improved performance, NIC hotplug, better disk I/O, modern PXE booting, support for flexible network configurations, and much more.
And that is only the beginning. A more complete list and details of each new cited feature is available here:
http://fedoraproject.org/wiki/Releases/12/FeatureList
For more information including common and known bugs, tips on how to report bugs, and the official release schedule, please refer to the release notes:
http://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes
Thank you, and we hope to see you in the Fedora project!
On Tue, Aug 25, 2009 at 07:56:00AM -0700, Jesse Keating wrote:
<insert witty comment that I'm up far too early to generate myself here>
We need your help to make Fedora 12 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it - every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution.
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
There are still many people on dialup. There are many more who suffer from bandwidth quotas. (My guess is that we victims of Time Warner were only saved because some politician probably has them as ISP.) :)
I don't know how many people this affects anymore, since it seems the majority do go for the DVD (or use a torrent or possibly jigdo) but I've always been able to just get the first CD, put it on a USB, and install that way.
I see boot.iso still doesn't allow to specify a method, (from the bug report, seems it'll be the next iteration of anaconda that fixes that) and haven't yet tried the net.iso. Going to try that one next, again doing my minimal install, and see how it goes.
Thanks.
On Tue, Aug 25, 2009 at 11:28 AM, Scott Robbinsscottro@nyc.rr.com wrote:
On Tue, Aug 25, 2009 at 07:56:00AM -0700, Jesse Keating wrote:
We need your help to make Fedora 12 the best release yet
I see boot.iso still doesn't allow to specify a method, (from the bug report, seems it'll be the next iteration of anaconda that fixes that) and haven't yet tried the net.iso. Going to try that one next, again doing my minimal install, and see how it goes.
The size issue I'm having is that my Mini CD-R discs are rated at 185MB, but actually hold about 200MB. Still, the net install ISO is just a tiny bit too large to fit on one of these discs. Believe me, it's the last time I'll buy them, but if it's easy to leave a thing or two out to make these discs work, life would be a tiny bit easier for me.
Chris
On Tue, Aug 25, 2009 at 11:37:15AM -0500, Chris Schumann wrote:
On Tue, Aug 25, 2009 at 11:28 AM, Scott Robbinsscottro@nyc.rr.com wrote:
On Tue, Aug 25, 2009 at 07:56:00AM -0700, Jesse Keating wrote:
We need your help to make Fedora 12 the best release yet
I see boot.iso still doesn't allow to specify a method, (from the bug report, seems it'll be the next iteration of anaconda that fixes that) and haven't yet tried the net.iso. Going to try that one next, again doing my minimal install, and see how it goes.
The size issue I'm having is that my Mini CD-R discs are rated at 185MB, but actually hold about 200MB. Still, the net install ISO is just a tiny bit too large to fit on one of these discs. Believe me, it's the last time I'll buy them, but if it's easy to leave a thing or two out to make these discs work, life would be a tiny bit easier for me.
See my other post--netinstall isn't (a net install) again, unless I've missed some change in the way one tells it to offer the option of network installation. Right now, the only way that's worked for me is to use Unetbootin, choose Fedora rawhide netinstall from the choices and boot off of that--it's the only thing offering me NFS or a URL.
On Tue, Aug 25, 2009 at 12:28:49PM -0400, Scott Robbins wrote:
On Tue, Aug 25, 2009 at 07:56:00AM -0700, Jesse Keating wrote:
We need your help to make Fedora 12 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it - every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution.
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
Unless the askmethod option has changed and I missed this? I hit tab and added askmethod at the end of the kernel line.
On Tue, 2009-08-25 at 12:45 -0400, Scott Robbins wrote:
On Tue, Aug 25, 2009 at 12:28:49PM -0400, Scott Robbins wrote:
On Tue, Aug 25, 2009 at 07:56:00AM -0700, Jesse Keating wrote:
We need your help to make Fedora 12 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it - every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution.
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
I believe this is bug#516973 - installer ignores askmethod
Thanks, James
On Tue, Aug 25, 2009 at 12:57:28PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 12:45 -0400, Scott Robbins wrote:
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
I believe this is bug#516973 - installer ignores askmethod
Hrrm, marked as fixed. Errm, it's not. :)
There is another still open however, 518194 Looking at the bug, it seems it was supposd to be fixed with this version of anaconda. :-( (Grumble, grumble).
On Tue, 2009-08-25 at 13:06 -0400, Scott Robbins wrote:
On Tue, Aug 25, 2009 at 12:57:28PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 12:45 -0400, Scott Robbins wrote:
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
I believe this is bug#516973 - installer ignores askmethod
Hrrm, marked as fixed. Errm, it's not. :)
There is another still open however, 518194
That issue is in MODIFIED (and likely very related to bug#516973).
Looking at the bug, it seems it was supposd to be fixed with this version of anaconda. :-( (Grumble, grumble).
Typically the anaconda bugs note a version number that the fix will be included in. In this case, the fix is noted in the anaconda git log (see http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=1fbf3c9d8d550fc01...). This will be addressed in anaconda-12.16 or newer. Fedora 12 Alpha ships with anaconda-12.15.
Thanks, James
On Tue, Aug 25, 2009 at 01:42:48PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 13:06 -0400, Scott Robbins wrote:
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
I believe this is bug#516973 - installer ignores askmethod
Hrrm, marked as fixed. Errm, it's not. :)
There is another still open however, 518194
That issue is in MODIFIED (and likely very related to bug#516973).
Looking at the bug, it seems it was supposd to be fixed with this version of anaconda. :-( (Grumble, grumble).
Typically the anaconda bugs note a version number that the fix will be included in. In this case, the fix is noted in the anaconda git log (see http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=1fbf3c9d8d550fc01...). This will be addressed in anaconda-12.16 or newer. Fedora 12 Alpha ships with anaconda-12.15.
When I tried installing after just downloading CD1, it said 12.16. (I didn't try with boot or net.iso, is it possible they're running with 12.15?
Thanks for the quick updates.
On Tue, 2009-08-25 at 13:53 -0400, Scott Robbins wrote:
On Tue, Aug 25, 2009 at 01:42:48PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 13:06 -0400, Scott Robbins wrote:
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
I believe this is bug#516973 - installer ignores askmethod
Hrrm, marked as fixed. Errm, it's not. :)
There is another still open however, 518194
That issue is in MODIFIED (and likely very related to bug#516973).
Looking at the bug, it seems it was supposd to be fixed with this version of anaconda. :-( (Grumble, grumble).
Typically the anaconda bugs note a version number that the fix will be included in. In this case, the fix is noted in the anaconda git log (see http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=1fbf3c9d8d550fc01...). This will be addressed in anaconda-12.16 or newer. Fedora 12 Alpha ships with anaconda-12.15.
When I tried installing after just downloading CD1, it said 12.16. (I didn't try with boot or net.iso, is it possible they're running with 12.15?
Very odd. I've repeated the same on the i386 and x86_64 disc1.iso and see anaconda-12.15.
Can you confirm the sha256sum for the disc1 media you are using? Does it match the official checksums [1]? Are you booting and installing from the physical media (not booting the media, and installing from rawhide)?
Thanks, James
[1] http://download.fedora.devel.redhat.com/pub/fedora/linux/releases/test/12-Al...
On Tue, Aug 25, 2009 at 02:04:31PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 13:53 -0400, Scott Robbins wrote:
On Tue, Aug 25, 2009 at 01:42:48PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 13:06 -0400, Scott Robbins wrote:
When I tried installing after just downloading CD1, it said 12.16. (I didn't try with boot or net.iso, is it possible they're running with 12.15?
Very odd. I've repeated the same on the i386 and x86_64 disc1.iso and see anaconda-12.15.
See my other post and post on bugzilla. Thanks very much for catching the error, or I'd have been whining to myself all day. :)
Now, I'll just whine to myself about my bad eyesight.
On Tue, Aug 25, 2009 at 01:42:48PM -0400, James Laska wrote:
On Tue, 2009-08-25 at 13:06 -0400, Scott Robbins wrote:
Ok, and netinstall.iso also only offers the choice of existing hard drives. I believe this bug has already been filed, I know it has for boot.iso.
I believe this is bug#516973 - installer ignores askmethod
Hrrm, marked as fixed. Errm, it's not. :)
There is another still open however, 518194
That issue is in MODIFIED (and likely very related to bug#516973).
Looking at the bug, it seems it was supposd to be fixed with this version of anaconda. :-( (Grumble, grumble).
As I added to the bug report, I had misread what I saw on the screen, when installing from CD1 (vs boot/net.iso). You are quite correct, still 12.15, not, as I erroneously wrote earlier, 12.16.
On Tue, 2009-08-25 at 12:28 -0400, Scott Robbins wrote:
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
Jesse Keating (jkeating@redhat.com) said:
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
The best solution is to define a default, and put it in that group. (postfix?)
Bill
On Tue, Aug 25, 2009 at 7:51 PM, Bill Nottinghamnotting@redhat.com wrote:
Jesse Keating (jkeating@redhat.com) said:
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
The best solution is to define a default, and put it in that group. (postfix?)
ssmtp is about the smallest at 50K or so.
Peter
On Tue, 25 Aug 2009 20:06:24 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Aug 25, 2009 at 7:51 PM, Bill Nottinghamnotting@redhat.com wrote:
Jesse Keating (jkeating@redhat.com) said:
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
The best solution is to define a default, and put it in that group. (postfix?)
ssmtp is about the smallest at 50K or so.
Note that ssmtp is NOT a replacement here. It does not do local delivery. So, if you need mail to go to a local user, it won't do the trick.
Peter
kevin
Jesse Keating (jkeating@redhat.com) said:
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
The best solution is to define a default, and put it in that group. (postfix?)
ssmtp is about the smallest at 50K or so.
Note that ssmtp is NOT a replacement here. It does not do local delivery. So, if you need mail to go to a local user, it won't do the trick.
esmtp? I believe most desktop users don't care about local emails from their system and enterprise/server/power users know how to install a decent mail server.
Peter
On Tue, 25 Aug 2009 20:22:39 +0100 Peter Robinson pbrobinson@gmail.com wrote:
Jesse Keating (jkeating@redhat.com) said:
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
The best solution is to define a default, and put it in that group. (postfix?)
ssmtp is about the smallest at 50K or so.
Note that ssmtp is NOT a replacement here. It does not do local delivery. So, if you need mail to go to a local user, it won't do the trick.
esmtp? I believe most desktop users don't care about local emails from their system and enterprise/server/power users know how to install a decent mail server.
If people don't care to get the local emails, perhaps a better solution would be coming up with a way to get that information to the user without email (rss? popup?).
Peter
kevin
On 08/26/2009 07:21 AM, Kevin Fenzi wrote:
If people don't care to get the local emails, perhaps a better solution would be coming up with a way to get that information to the user without email (rss? popup?).
Yes, perhaps. Meanwhile ssmtp is a better default IMO. It saves space, reduces boot time and those who need a mail server can easily install one. Sendmail won't be the one that everyone chooses. Just document it in the release notes. Any problem?
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
If people don't care to get the local emails, perhaps a better solution would be coming up with a way to get that information to the user without email (rss? popup?).
Yes, perhaps. Meanwhile ssmtp is a better default IMO.
I don't necessarily think so. If you're doing a minimal install, you're more likely installing a server, in which case you expect more a mail infrastructure.
Bill
On Wed, Aug 26, 2009 at 7:28 PM, Bill Nottinghamnotting@redhat.com wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
If people don't care to get the local emails, perhaps a better solution would be coming up with a way to get that information to the user without email (rss? popup?).
Yes, perhaps. Meanwhile ssmtp is a better default IMO.
I don't necessarily think so. If you're doing a minimal install, you're more likely installing a server, in which case you expect more a mail infrastructure.
I somewhat disagree. A lot of the stuff I work on uses small installs (live cd about 300 meg) and isn't a server. If your doing a server install your also likely to know how to install a smtp server too.
Peter
On Wed, Aug 26, 2009 at 1:28 PM, Bill Nottinghamnotting@redhat.com wrote:
I don't necessarily think so. If you're doing a minimal install, you're more likely installing a server, in which case you expect more a mail infrastructure.
Lately the minimal installs I do are from net install media, so the install (for me) is just to get up and running.
Chris
On 08/26/2009 11:58 PM, Bill Nottingham wrote:
Rahul Sundaram said:
If people don't care to get the local emails, perhaps a better solution would be coming up with a way to get that information to the user without email (rss? popup?).
Yes, perhaps. Meanwhile ssmtp is a better default IMO.
I don't necessarily think so. If you're doing a minimal install, you're more likely installing a server, in which case you expect more a mail infrastructure.
This is not the only use case or even the most common one. Live CD's for example don't need a mail server. You can't expect desktop users to go and read root mail anyway. Unless there is something better, mail server just add to the startup time. A completely waste.
Net installs don't necessarily need a mail server at all.
Fedora users installing it on a server (they do exist), especially as a a mail server are going to be way less than desktop users. We are just following a legacy here. It doesn't provide any real benefit at all to the large majority of users. Since some of the packages expect a mta, shove in ssmtp and be done with it.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
This is not the only use case or even the most common one. Live CD's for example don't need a mail server. You can't expect desktop users to go and read root mail anyway. Unless there is something better, mail server just add to the startup time. A completely waste.
That's a lovely argument, and if we were talking about the live cd or th desktop, it might actually have a point in this discussion. LiveCDs and the desktop already include the base group, which defines a MTA. Changing the core group does not change this.
The orginal question was that you get exim as the MTA if you only install the Core group (uncheck everything).
Fedora users installing it on a server (they do exist), especially as a a mail server are going to be way less than desktop users. We are just following a legacy here. It doesn't provide any real benefit at all to the large majority of users. Since some of the packages expect a mta, shove in ssmtp and be done with it.
Congratulations, you've now installed TWO mtas on every livecd install. Happy?
Bill
On 08/27/2009 01:35 AM, Bill Nottingham wrote:
Congratulations, you've now installed TWO mtas on every livecd install. Happy?
Nah. Once you add ssmtp to the core group, you can very well remove any mta's from the base group. This will solve the original problem being raised in the discussion as well.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
Congratulations, you've now installed TWO mtas on every livecd install. Happy?
Nah. Once you add ssmtp to the core group, you can very well remove any mta's from the base group. This will solve the original problem being raised in the discussion as well.
Except it changes the default for everyone to something with less functionality, which I'm fairly sure we don't want to do after feature freeze. Notably, ssmtp won't queue if you're offline, if I'm reading the docs right.)
(Honestly, if we're going to move an MTA from base to core, I'd suggest we should just do s/sendmail/postfix/, and let those who need less change it.)
Bill
On 08/27/2009 02:18 AM, Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Congratulations, you've now installed TWO mtas on every livecd install. Happy?
Nah. Once you add ssmtp to the core group, you can very well remove any mta's from the base group. This will solve the original problem being raised in the discussion as well.
Except it changes the default for everyone to something with less functionality, which I'm fairly sure we don't want to do after feature freeze. Notably, ssmtp won't queue if you're offline, if I'm reading the docs right.)
If feature freeze is the only consideration preventing it from happening, then queue it for Fedora 13. Less functionality is perfectly fine unless there is a strong case that more of those features is actually being used by a majority in order to satisfy the nominal requirements of being a default package.
(Honestly, if we're going to move an MTA from base to core, I'd suggest we should just do s/sendmail/postfix/, and let those who need less change it.)
My point is simply that most users in Fedora users are bound to use it on a desktop and wouldn't need a MTA and we should let people just install their mta of choice, be it exim, postfix or sendmail if they really need one. On the other hand, even if do a more full featured mta, I agree it is really high time we moved away from sendmail. SUSE, Ubuntu and Mandriva? is using postfix and Debian is using exim.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
Except it changes the default for everyone to something with less functionality, which I'm fairly sure we don't want to do after feature freeze. Notably, ssmtp won't queue if you're offline, if I'm reading the docs right.)
If feature freeze is the only consideration preventing it from happening, then queue it for Fedora 13. Less functionality is perfectly fine unless there is a strong case that more of those features is actually being used by a majority in order to satisfy the nominal requirements of being a default package.
The entire reason that a MTA is dragged into the core group is for things like cron. In the base group, at (and up until recently, logwatch.)
If you replace that with ssmtp, *out of the box all that mail is dropped on the floor*. I don't think that's a reasonable position to take by default.
(There are solutions here, of course - asking for an e-mail address for each user, and asking which user is the admin. But we don't do that now.)
Bill
On 08/27/2009 02:38 AM, Bill Nottingham wrote:
The entire reason that a MTA is dragged into the core group is for things like cron. In the base group, at (and up until recently, logwatch.)
If you replace that with ssmtp, *out of the box all that mail is dropped on the floor*. I don't think that's a reasonable position to take by default.
(There are solutions here, of course - asking for an e-mail address for each user, and asking which user is the admin. But we don't do that now.)
If mails from cron are the reason why we are installing a mta, that is a very weak one considering that a typical desktop user isn't seeing them at all.
The mails I care about as a desktop user doesn't require a local mta on my system. All other mails that the local mta is queuing up is effectively dropped on the floor since it is not exposed at all to me from my desktop. Instead of exposing them in one of the many ways suggested, we are just pretending that are still somehow useful. If the installer asks for my email address and configures my system to automatically send me mail to my mail client of choice once I login, *then*, it is marginally useful. I am not sure what am I supposed with mails from cron in the desktop still.
Rahul
On Thu, 27 Aug 2009 02:48:04 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
If mails from cron are the reason why we are installing a mta, that is a very weak one considering that a typical desktop user isn't seeing them at all.
The mails I care about as a desktop user doesn't require a local mta on my system. All other mails that the local mta is queuing up is effectively dropped on the floor since it is not exposed at all to me from my desktop. Instead of exposing them in one of the many ways suggested, we are just pretending that are still somehow useful. If the installer asks for my email address and configures my system to automatically send me mail to my mail client of choice once I login, *then*, it is marginally useful. I am not sure what am I supposed with mails from cron in the desktop still.
Then IMHO the solution is to get this information to the user via some other method so we don't require a MTA in the first place, not replace it with something that silently drops the email under the rug.
I think despite that many people won't care about this or need it it would be very very anoying for us to change it so this doesn't work without fixing the delivery in the first place.
Perhaps as an easy step, cron (or cronnie or whatever) could just write this stuff to a log?
Rahul
kevin
On 08/27/2009 03:13 AM, Kevin Fenzi wrote:
Then IMHO the solution is to get this information to the user via some other method so we don't require a MTA in the first place, not replace it with something that silently drops the email under the rug.
What are those mails and why should I care about them as a desktop user? They are for all practical purposes under the rug already.
I think despite that many people won't care about this or need it it would be very very anoying for us to change it so this doesn't work without fixing the delivery in the first place.
If you know enough to care, you are likely not going to be reading the mails directly as root user but reconfiguring to send mails to the email account of choice and a single package to flip over is hardly going to take a few mins. If you are doing it for more than one system, kickstart is going to take care of them. The people who are going to be doing this just have to accept that the majority is going to benefit from not running a mta and the tradeoff has to favor them instead.
Perhaps as an easy step, cron (or cronnie or whatever) could just write this stuff to a log?
Yeah, anything is better than what we have now which is just very sub optimal for everyone involved.
Rahul
On Thu, 27 Aug 2009 03:54:00 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
On 08/27/2009 03:13 AM, Kevin Fenzi wrote:
Then IMHO the solution is to get this information to the user via some other method so we don't require a MTA in the first place, not replace it with something that silently drops the email under the rug.
What are those mails and why should I care about them as a desktop user? They are for all practical purposes under the rug already.
Out of the box? Not much. If they provide no value, why don't we disable them?
On the other hand if you have a friend or read from a howto how to setup a backup cron job and it starts failing after a while, it would sure be nice to get those emails before you need to use your backups.
I think changing something like this that has behaved this way since cron existed needs: a) loud trumpeting b) assurance that if the data is not in an email, it is _somewhere_ for people expecting it to exist.
I think despite that many people won't care about this or need it it would be very very anoying for us to change it so this doesn't work without fixing the delivery in the first place.
If you know enough to care, you are likely not going to be reading the mails directly as root user but reconfiguring to send mails to the email account of choice and a single package to flip over is hardly going to take a few mins. If you are doing it for more than one system, kickstart is going to take care of them. The people who are going to be doing this just have to accept that the majority is going to benefit from not running a mta and the tradeoff has to favor them instead.
But why can't we fix it at the 'needs an mta' step instead of 'we generate emails no one cares about and sometimes silently drop them' ?
The solution of ssmtp seems a band aid to me, that will also annoy some people who don't expect it's behavior.
Perhaps as an easy step, cron (or cronnie or whatever) could just write this stuff to a log?
Yeah, anything is better than what we have now which is just very sub optimal for everyone involved.
Sure, so possible solutions IMHO:
- cron uses a /var/log/cron/ whatever log file area for it's output.
- logwatch not enabled by default?
or
- Some mta that has simple local delivery ability
or
- Some way to take cron output and stuff it into a rss feed or something thats available from a System Admin menu.
or
Something else here thats not 'use ssmtp'.
:)
kevin
On 08/27/2009 04:59 AM, Kevin Fenzi wrote:
On Thu, 27 Aug 2009 03:54:00 +0530 Rahul Sundaram wrote:
On 08/27/2009 03:13 AM, Kevin Fenzi wrote:
Then IMHO the solution is to get this information to the user via some other method so we don't require a MTA in the first place, not replace it with something that silently drops the email under the rug.
What are those mails and why should I care about them as a desktop user? They are for all practical purposes under the rug already.
Out of the box? Not much. If they provide no value, why don't we disable them?
Good question.
Sure, so possible solutions IMHO:
cron uses a /var/log/cron/ whatever log file area for it's output.
logwatch not enabled by default?
or
- Some mta that has simple local delivery ability
or
- Some way to take cron output and stuff it into a rss feed or something thats available from a System Admin menu.
or
Something else here thats not 'use ssmtp'.
All of these are fine solutions. I can only hope someone implements them.
Rahul
On 08/26/2009 05:24 PM, Rahul Sundaram wrote:
What are those mails and why should I care about them as a desktop user? They are for all practical purposes under the rug already.
I've brought this fact up a year or so ago and my e-mail was swept under the rug. I suspect this thread will also be forgotten about and the issue will resurface in F13>F14>etc.
Once upon a time, Michael Cronenworth mike@cchtml.com said:
On 08/26/2009 05:24 PM, Rahul Sundaram wrote:
What are those mails and why should I care about them as a desktop user? They are for all practical purposes under the rug already.
I've brought this fact up a year or so ago and my e-mail was swept under the rug. I suspect this thread will also be forgotten about and the issue will resurface in F13>F14>etc.
I doubt it was "swept under the rug." Did you provide a solution that was ignored?
The problem:
- some daemons may generate output that needs to be displayed to the user; this output should be stored somewhere if it can't be displayed to the user immediately, or if there is a designated admin user and another user is logged in
The current solution:
- send email to root, using a local MTA that can handle local delivery (sendmail is the current default for historical reasons, postfix and exim should also work)
Every time this comes up (and it has come up repeatedly), the end result is that there's no compelling reason to switch between MTAs in the default install, since the current default works as expected. End users that actually want to configure an MTA are free to install what they want. The other possibility (ssmtp) is not a solution to the above problem, since it can't deliver locally (which is the only sane default out-of-the-box).
The only reason to change is if there is a better solution to the above problem than "email root". However, despite people saying that is a bad solution, there hasn't been anybody step up and implement a better solution.
Me, I just keep using sendmail because it's what I know (I've been managing mail servers for 13+ years). The cool thing about sendmail is that, once you learn it, you can make it do just about anything, without having to change any source code (the configuration syntax is really a basic programming language).
I understand that the vast majority of people can't do that, but the postfix/exim people need to also understand that the vast majority of Fedora users/"admins" can't configure postfix or exim either, except by Google-cut-and-paste (which works just as well or as poorly for any MTA that an end-user doesn't really understand). I don't think there are any system-config-MTA (for any of the available MTAs) configuration tools in Fedora.
On Thu, 2009-08-27 at 08:29 -0500, Chris Adams wrote:
I understand that the vast majority of people can't do that, but the postfix/exim people need to also understand that the vast majority of Fedora users/"admins" can't configure postfix or exim either, except by Google-cut-and-paste (which works just as well or as poorly for any MTA that an end-user doesn't really understand). I don't think there are any system-config-MTA (for any of the available MTAs) configuration tools in Fedora.
As I said, I was literally unable to get sendmail working despite spending an entire weekend on it, and in general I'm pretty good at bluffing my way through stuff based on Google results (you could call it my specialist subject :>). postfix only took me several hours to get going, and I at least vaguely understand what the hell was going on. It's a really significant difference, in my experience anyway.
On Thu, Aug 27, 2009 at 08:45:42AM -0700, Adam Williamson wrote:
As I said, I was literally unable to get sendmail working despite spending an entire weekend on it,
It would be really interesting to know what you were attempting to do and how you "over-thought" that installation. For years on most of Fedora installations sendmail requires really _nothing_ in order to work locally. If you want to receive mail from an outside world you need to follow these instructions in /etc/mail/sendmail.mc
dnl # The following causes sendmail to only listen on the IPv4 loopback address dnl # 127.0.0.1 and not on any other network devices. Remove the loopback dnl # address restriction to accept email from the internet or intranet. DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
So you have to comment out one line and do 'service sendmail restart'. That rewrites for you /etc/mail/sendmail.cf. Various other things are also done easily and quickly by editing /etc/mail/sendmail.mc and for more popular options you do not even need to read documentation as comments in that file are often enough. Usually takes few short minutes if you do not desire something "exotic".
Michal
On Thu, 2009-08-27 at 10:51 -0600, Michal Jaegermann wrote:
On Thu, Aug 27, 2009 at 08:45:42AM -0700, Adam Williamson wrote:
As I said, I was literally unable to get sendmail working despite spending an entire weekend on it,
It would be really interesting to know what you were attempting to do and how you "over-thought" that installation. For years on most of Fedora installations sendmail requires really _nothing_ in order to work locally. If you want to receive mail from an outside world you need to follow these instructions in /etc/mail/sendmail.mc
dnl # The following causes sendmail to only listen on the IPv4 loopback address dnl # 127.0.0.1 and not on any other network devices. Remove the loopback dnl # address restriction to accept email from the internet or intranet. DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
So you have to comment out one line and do 'service sendmail restart'. That rewrites for you /etc/mail/sendmail.cf. Various other things are also done easily and quickly by editing /etc/mail/sendmail.mc and for more popular options you do not even need to read documentation as comments in that file are often enough. Usually takes few short minutes if you do not desire something "exotic".
It was quite a while back, I don't recall exactly what I was trying to set it up to do and what problems I ran into. I just remember it being a complete nightmare, and postfix being far far easier.
On Thu, Aug 27, 2009 at 10:06:51AM -0700, Adam Williamson wrote:
On Thu, 2009-08-27 at 10:51 -0600, Michal Jaegermann wrote:
On Thu, Aug 27, 2009 at 08:45:42AM -0700, Adam Williamson wrote:
As I said, I was literally unable to get sendmail working despite spending an entire weekend on it,
It would be really interesting to know what you were attempting to do and how you "over-thought" that installation.
It was quite a while back, I don't recall exactly what I was trying to set it up to do and what problems I ran into.
Hm, sounds like some fifteen years, or so, back. There were indeed times when configuring sendmail required messing directly with sendmail.cf and that borders on a "black magic". :-) Only you do not have to do that longer that I care to remember.
I just remember it being a complete nightmare, and postfix being far far easier.
Setting postfix to do somethig "unusual" can be actually quite a bit harder than doing that with sendmail. In "not an outside accesible mail server" situation what comes with Fedora for sendmail AFAIK "just works".
Michal
As I said, I was literally unable to get sendmail working despite spending an entire weekend on it,
It would be really interesting to know what you were attempting to do and how you "over-thought" that installation.
It was quite a while back, I don't recall exactly what I was trying to set it up to do and what problems I ran into.
Hm, sounds like some fifteen years, or so, back. There were indeed times when configuring sendmail required messing directly with sendmail.cf and that borders on a "black magic". :-) Only you do not have to do that longer that I care to remember.
Yes, black magic it was, but for 10 years or so its had sendmail.m4 to allow you to configure it relatively simply (simply being a relative term to what it was prviously) with macros but its still has issues. I would think postfix is a reasonable medium, its relatively modern and lightweight (exim needs perl) and if someone particularly wants sendmail I think they would also be able to work out how to do a 'yum install sendmail'. If they know how to configure a particular mta they can certainly work out how to use yum to or packagekit to install it.
Peter
On Thu, 27 Aug 2009 23:24:58 +0100 Peter Robinson wrote:
but for 10 years or so its had sendmail.m4
As far as I'm concerned, the m4 stuff makes it even more obscure :-).
But if anyone is smart enough to install sendmail if they want it, they are probably also smart enough to install postfix.
On Thu, Aug 27, 2009 at 11:24:58PM +0100, Peter Robinson wrote:
I would think postfix is a reasonable medium, its relatively modern and lightweight (exim needs perl) and if someone particularly wants sendmail I think they would also be able to work out how to do a 'yum install sendmail'.
It is really not that important which MTA is present. If somebody would bring that mythical "simple, small, lightweight, local delivery" MTA, and "you know where to look for full fledged servers if you need them", then I would not mind this as an installation default. Only that such thing is so far appears to be missing (or esmtp can play here? I do not know). Maybe it is not that hard to expand on an existing stuff but MTAs are famously devious beasts with serious security implications.
Michal
On Thu, Aug 27, 2009 at 04:56:00PM -0600, Michal Jaegermann wrote:
If somebody would bring that mythical "simple, small, lightweight, local delivery" MTA, and "you know where to look for full fledged servers if you need them", then I would not mind this as an installation default. Only that such thing is so far appears to be missing (or esmtp can play here? I do not know).
I was looking at that too last night. I don't *think* so, but the documentation wasn't all that clear, at least late at night.
I think that had the guy who was going to evolve ssmtp into bsmtp, or perhaps bssmtp?, kept up with it, we would have had it.
Maybe it is not that hard
to expand on an existing stuff but MTAs are famously devious beasts with serious security implications.
Yuppers. As the old joke goes in IRC.
personX: (angry at something) God !!! %#(#@)(%*#@$@#(!@
personY: Please don't post your sendmail configuration in channel.
On Thu, 27 Aug 2009 02:48:04 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
If mails from cron are the reason why we are installing a mta, that is a very weak one considering that a typical desktop user isn't seeing them at all.
The mails I care about as a desktop user doesn't require a local mta on my system. All other mails that the local mta is queuing up is effectively dropped on the floor since it is not exposed at all to me from my desktop. Instead of exposing them in one of the many ways suggested, we are just pretending that are still somehow useful. If the installer asks for my email address and configures my system to automatically send me mail to my mail client of choice once I login, *then*, it is marginally useful. I am not sure what am I supposed with mails from cron in the desktop still.
As a desktop user, I disagree. The mails go to the root account, and I read them there. They don't go anywhere if there is no mail agent. I am both a user (most of the time), and the admin. As a user, I don't care about those emails. As the admin, I do. I would expect most linux desktop users to have this dual role. Are you dumbing down Fedora to be a thin client, net installed, administered by someone besides the user? Then why is the user installing it?
Is it possible to ask the question, "Do you want system messages sent to the root account?". Yes, set up an mta, No, throw them away.
On 08/27/2009 03:36 AM, stan wrote:
As a desktop user, I disagree. The mails go to the root account, and I read them there. They don't go anywhere if there is no mail agent.
If you are reading root mails as a desktop user, you belong in a very very tiny niche and probably should be classified as a more workstation type user. If it was not clear already, I am talking about desktop users in general who will not read any such mails unless there is a more direct way to configure them as part of the installation process and even then will not necessarily know what the heck to do with those mails and not just the geeks. The fact that I or you will doesn't change it. There is another Unix system on the desktop to learn from: Mac OS X.
Rahul
On Thu, 27 Aug 2009 03:44:06 +0530 Rahul Sundaram sundaram@fedoraproject.org wrote:
If you are reading root mails as a desktop user, you belong in a very very tiny niche and probably should be classified as a more workstation type user. If it was not clear already, I am talking about desktop users in general who will not read any such mails unless there is a more direct way to configure them as part of the installation process and even then will not necessarily know what the heck to do with those mails and not just the geeks. The fact that I or you will doesn't change it. There is another Unix system on the desktop to learn from: Mac OS X.
The only time I ever used a mac was in a programming course. Learning it was harder than the course. :-) That was a long time ago, maybe it has changed. What exactly is it we should be learning from the Mac? A closed source system, developed by paid developers, with system architects and patent lawyers maintaining rigid control of development and turf. I just don't see their model working in open source. But I would like to hear what you consider that they do better.
And what is gained by dropping the mta, in particular, and generally making Fedora less geekish in general? The mta already exists and is working. You are right, if it is dropped, I'll write myself notes on how to set this up so that every time I install a new version of Fedora, I do it after the install. But I would much rather it stayed as system knowledge so I don't have to spend time working on it.
I can see your point for the live CD. That is designed for naive users. Drop not only any system messages or jobs in cron beyond the obvious like updates, but also drop SELinux (just a PITA for naive users), turn off all logging, updatedb, because they only take cycles away from user experience and those users won't ever use the product of them. Only a single application to do everything, no confusing choices. As a very involved insider, you can probably come up with a dozen things that aren't really required for the LiveCD.
In fact, to compete in that market, maybe we should give the user root privileges so they can talk directly to the hardware. Those users don't care about security, only performance and golly gee. I'm partly joking, but if linux really wants to be appealing to them, it has to give the same ease of use that the alternatives give. If that means compromising security a little, so be it. And it needs to provide closed source drivers out of the box. Those users don't want to be bothered with having to find offshore repositories and downloading things. They just want it to work. Make the hardware api the same as windows, so hardware vendors can develop just one driver and have it run on both windows and linux.
I'm curious about the rationale for your stance? What benefit does it give Fedora? What outcome does it provide that is preferable to the outcome now?
And I'm curious if, in your opinion, your stance reflects the general consensus within Fedora about where the distro should go? Is this how the people who do all the work want Fedora to be?
Thanks for putting your ideas out here in the public forum.
On 08/27/2009 04:50 AM, stan wrote:
And what is gained by dropping the mta, in particular, and generally making Fedora less geekish in general? The mta already exists and is working.
I will just focus on this instead of replying to a whole lot of other things in your mail since it is just a distraction from the real conversation.
I have actually already answered this point but I will repeat it once more but briefly. There is no real justification for a MTA to be enabled by default on a large majority of systems for Fedora users and it reduces startup time and hogs resources unnecessarily. For users who understand how to use a mta, installing it takes only a few minutes.
Rahul
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
There is no real justification for a MTA to be enabled by default on a large majority of systems for Fedora users and it reduces startup time and hogs resources unnecessarily.
If _any_ MTA is increasing startup time by a significant amount or hogging resources unnecessarily, that's a bug in the MTA. What are the open BZ numbers for sendmail hogging resources?
Tossing out random BS doesn't exactly help your argument.
On Thu, 27 Aug 2009, Chris Adams wrote:
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
There is no real justification for a MTA to be enabled by default on a large majority of systems for Fedora users and it reduces startup time and hogs resources unnecessarily.
If _any_ MTA is increasing startup time by a significant amount or hogging resources unnecessarily, that's a bug in the MTA. What are the open BZ numbers for sendmail hogging resources?
Tossing out random BS doesn't exactly help your argument.
Everyone, We're not really getting anywhere in this thread.
Why don't we cool it.
good.
-sv
On 08/27/2009 07:02 PM, Chris Adams wrote:
Once upon a time, Rahul Sundaram said:
There is no real justification for a MTA to be enabled by default on a large majority of systems for Fedora users and it reduces startup time and hogs resources unnecessarily.
If _any_ MTA is increasing startup time by a significant amount or hogging resources unnecessarily, that's a bug in the MTA. What are the open BZ numbers for sendmail hogging resources?
Tossing out random BS doesn't exactly help your argument.
If you want to disagree, I think you can find better ways to do that but my point is simply that any daemon by default where it is not necessary for majority of users = resource waste. Incidentally, there *are* distributions including cron but not a mta by default.
Anyway a feature proposal has been made at
https://fedoraproject.org/wiki/Features/NoMTA
We will get off inertia and do something about it now.
Rahul
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
Anyway a feature proposal has been made at
"Delete and ignore the messages" seems like a bad idea; typically, only error messages come from cron jobs, so dropping the output is bad. Ignoring errors is a recipie for later problems.
Also, there are more things in the base install that use mail (although they may not be currently requiring it). For example, mdmonitor and smartd both email error messages to root.
If you don't want email to root, a better solution would be to set up something else to store such messages somewhere. Then there should be a desktop applet that can display the messages to the desktop user (or possibly only an admin user).
mdmonitor and smartd can easily be changed, since they can be configured with a program instead of an email address. I don't know about cron.
"CA" == Chris Adams cmadams@hiwaay.net writes:
CA> If you don't want email to root, a better solution would be to set CA> up something else to store such messages somewhere. Then there CA> should be a desktop applet that can display the messages to the CA> desktop user (or possibly only an admin user).
Cool, so instead of a daemon that runs accepting messages and storing them somewhere for access by a mail client, we end up with... a daemon that runs accepting messages and storing them somewhere for access by some non-mail client that doesn't exist yet.
- J<
On Thu, Aug 27, 2009 at 11:13:30AM -0500, Chris Adams wrote:
mdmonitor and smartd can easily be changed, since they can be configured with a program instead of an email address. I don't know about cron.
cron can be changed to. 'man 5 crontab', see MAILTO. The only problem is that in such way there should be something else sending mail to root you forgot about (say - logwatch, or something else or something which you are going to install in the future). That is why in /etc/aliases you can see the following example:
# Person who should get root's mail #root: marc
'firstboot' could have something which would allow to edit that if so desired.
Dropping these mails to root, or displaying them with something "clicky-pointy" on a desktop to which you may not be even logged to and which can be far away is the worst possible "solution" one can come up with. Is this happens _only_ if a suitable MTA is not available such thing could be acceptable. Not sure how to do that without supplying some kind of "pretend MTA" (which probably end up bigger and more resource hungry than alternatives).
Michal
Once upon a time, Michal Jaegermann michal@harddata.com said:
On Thu, Aug 27, 2009 at 11:13:30AM -0500, Chris Adams wrote:
mdmonitor and smartd can easily be changed, since they can be configured with a program instead of an email address. I don't know about cron.
cron can be changed to. 'man 5 crontab', see MAILTO.
That's a little different; mdmonitor and smartd can use an alternate program (rather than /bin/mail or /usr/sbin/sendmail) that could do something other than send email, while cron can just specify another email address (which still requires email infrastructure).
On 08/27/2009 09:43 PM, Chris Adams wrote:
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
Anyway a feature proposal has been made at
"Delete and ignore the messages" seems like a bad idea; typically, only error messages come from cron jobs, so dropping the output is bad. Ignoring errors is a recipie for later problems.
What problem would that be, really? People keep claiming that without adding any details. The Xfce Spin which I used to maintain is already not running sendmail by default ever since it was first released. Nobody noticed or complained yet. The LXDE Spin is doing the same thing for Fedora 12.
The proposal doesn't really suggest that we drop everything on the floor however. Read the proposal a little bit more.
"Required changes:
1. Change any cron job that emits output to send its output to syslog or a log file
2. Remove Requires: /usr/sbin/sendmail from cronie's spec file "
If you have a custom cron job running email you want, you just yum install the mta of your choice.
Rahul
On Thu, Aug 27, 2009 at 10:38 AM, Rahul Sundaramsundaram@fedoraproject.org wrote:
On 08/27/2009 09:43 PM, Chris Adams wrote:
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
Anyway a feature proposal has been made at
"Delete and ignore the messages" seems like a bad idea; typically, only error messages come from cron jobs, so dropping the output is bad. Ignoring errors is a recipie for later problems.
What problem would that be, really? People keep claiming that without adding any details. The Xfce Spin which I used to maintain is already not running sendmail by default ever since it was first released. Nobody noticed or complained yet. The LXDE Spin is doing the same thing for Fedora 12.
How hard would it be to add something to firstboot that asks for an email address to send emails from the system to? If the person does not want to use that then it defaults to the created account and runs newaliases on that. I realize I am really really old school here, but the reason I use it even as a desktop is that I can get email sent to somewhere without a lot of licensed or extra software added.
[A group I worked at previously had this in their firstboot so that logging and email could be sent to a system administrator so they knew what was going. ]
On Thu, Aug 27, 2009 at 10:08:13PM +0530, Rahul Sundaram wrote:
On 08/27/2009 09:43 PM, Chris Adams wrote:
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
Anyway a feature proposal has been made at
"Delete and ignore the messages" seems like a bad idea; typically, only error messages come from cron jobs, so dropping the output is bad. Ignoring errors is a recipie for later problems.
What problem would that be, really? People keep claiming that without adding any details.
As shocking as it may be to you there are still around people with computers who care about their data and about machines which do not misbehave without warnings. So messages, say, from smartd or mdadm or other things that something goes haywire are in such situations rather appreciated. logwatch also has some uses (even if it need some care sometimes). Also error output from cron, where no tty and/or console is available, is something good to know. Maybe your cron scripts are always perfect but I managed to screw up from time to time (most often forgetting that PATH in cron will be not the same like the one for an interactive shell). Sending that in some or another form to some desktop is not enough.
Reinstalling a system from scratch is usually a quick job; restoring local customizations could be a substantial bother; users data is something really important. Yes, backups is also a good thing.
"Required changes:
- Change any cron job that emits output to send its output to syslog
or a log file
So now you claim that people who cannot be bothered with looking at mail will go and dig through log files? I would like to see that. Or maybe logwatch will do that for them but then what it will happen with a collected information?
- Remove Requires: /usr/sbin/sendmail from cronie's spec file "
MTA is needed by more things that one particular daemon. Sure, if you have something minimal for a local delivery which can replace existing alternatives then I do not see a problem; only would like to see that "something" first.
Michal
On 08/28/2009 02:39 AM, Michal Jaegermann wrote:
As shocking as it may be to you there are still around people with computers who care about their data and about machines which do not misbehave without warnings. So messages, say, from smartd or mdadm or other things that something goes haywire are in such situations rather appreciated.
If you read the previous discussions, you will notice that I didn't say that the messages are never useful but it isn't useful for the majority of users. If you know where to look for those messages, go ahead and use the MTA of your choice. None of them are going away from the repository.
For a desktop, something like Palimpsest which is the default in GNOME for Fedora 11 gives you notifications on the desktop about the disk problems instead of relying on dropping to a root shell and running a mail command works way better.
So now you claim that people who cannot be bothered with looking at mail will go and dig through log files? I would like to see that.
If you read the proposal, you will notice that it is not from me. So redirect your concerns to the discussion page.
Rahul
Once upon a time, Rahul Sundaram sundaram@fedoraproject.org said:
For a desktop, something like Palimpsest which is the default in GNOME for Fedora 11 gives you notifications on the desktop about the disk problems instead of relying on dropping to a root shell and running a mail command works way better.
However, if the proposal goes through as currently stated, the messages will be lost. Right now, even if somebody doesn't normally read the mail, it is easy enough for them to go looking (e.g. instructions from Google) and find them.
The messages going to root are errors. Errors should never be silently thrown away.
On 08/28/2009 02:52 AM, Chris Adams wrote:
Once upon a time, Rahul Sundaram said:
For a desktop, something like Palimpsest which is the default in GNOME for Fedora 11 gives you notifications on the desktop about the disk problems instead of relying on dropping to a root shell and running a mail command works way better.
However, if the proposal goes through as currently stated, the messages will be lost.
It won't be lost. It will be logged. I already explained that and pointed out the specific approach in the proposal.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
Anyway a feature proposal has been made at
https://fedoraproject.org/wiki/Features/NoMTA
We will get off inertia and do something about it now.
In the meantime, I've added sendmail to the core group, so we're at least pulling in a consistent MTA (instead of shortest-name-wins), and minimal installs should go back to only needing one CD.
Bill
Well personally, I find it very convenient that my broken cron jobs and system problems do actively send root email. I always configure my system so that I actually receive those emails. For the masses, I do agree that almost everyone is missing these, which could be a problem if something important is going haywire. There is an outstanding request to fix this:
https://bugzilla.redhat.com/show_bug.cgi?id=135592 setup /etc/aliases so that useful email gets to someone
A lot of stuff that gets sent to root's inbox (or /var/log/messages, for that matter) is just noise from normal operation, which I'm generally in favor of quieting unless debugging is explicitly requested. Perhaps once more people start getting all of root's mail, this sort of thing will get more attention. Certainly since I started getting kerneloops popups on my Gnome desktop, kernel burps have gotten a lot more attention from me. "clicky-pointy" is certainly helpful if you want to encourage desktop users to report bugs, even if they don't understand what they are reporting. In the case of kernel oopses, these messages are still logged so the headless sysadmin use case is also satisfied. "Send mail to root that is actually read" does seem like a nice way to satisfy both cases at once, and a desktop pop-up doesn't help all that much if there's no semi-automatic action to be taken (like filing a bug). I do worry that most people will give a remote email address (like their gmail or something). This will not work well when there is no network connectivity, and it seems to have some security/privacy implications. And there would need to be some GUI way to change that address for Fedora in case the user changes email providers.
I wonder if it would be a good idea for desktop users to get some sort of notification that they have local mail waiting to be read, even if they don't have an email client running. Then firstboot would strongly recommend sending mail locally, so it would work more reliably (at the cost of not being co-mingled with all of your other email, though hopefully it would only get sent if something was malfunctioning).
-B.
On Fri, Aug 28, 2009 at 9:15 AM, Christopher Belandbeland@alum.mit.edu wrote:
I wonder if it would be a good idea for desktop users to get some sort of notification that they have local mail waiting to be read, even if they don't have an email client running. Then firstboot would strongly recommend sending mail locally, so it would work more reliably (at the cost of not being co-mingled with all of your other email, though hopefully it would only get sent if something was malfunctioning).
How would you suggest that these users read this email? Should evolution be setup with the default local account? What if they never open evolution?
On Fri, Aug 28, 2009 at 8:54 AM, James Hubbardjameshubbard@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:15 AM, Christopher Belandbeland@alum.mit.edu wrote:
I wonder if it would be a good idea for desktop users to get some sort of notification that they have local mail waiting to be read, even if they don't have an email client running. Then firstboot would strongly recommend sending mail locally, so it would work more reliably (at the cost of not being co-mingled with all of your other email, though hopefully it would only get sent if something was malfunctioning).
How would you suggest that these users read this email? Should evolution be setup with the default local account? What if they never open evolution?
What if they never install Fedora? OMG What if they never turn on the computer? [Ok I think I have covered hyperbole enough here]
Please there is only a limit to what people can assume the user will or will not do. The issue is to make it easier for that user to know whats going on.
On Fri, Aug 28, 2009 at 11:21 AM, Stephen John Smoogensmooge@gmail.com wrote:
On Fri, Aug 28, 2009 at 8:54 AM, James Hubbardjameshubbard@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:15 AM, Christopher Belandbeland@alum.mit.edu wrote:
I wonder if it would be a good idea for desktop users to get some sort of notification that they have local mail waiting to be read, even if they don't have an email client running. Then firstboot would strongly recommend sending mail locally, so it would work more reliably (at the cost of not being co-mingled with all of your other email, though hopefully it would only get sent if something was malfunctioning).
How would you suggest that these users read this email? Should evolution be setup with the default local account? What if they never open evolution?
What if they never install Fedora? OMG What if they never turn on the computer? [Ok I think I have covered hyperbole enough here]
Please there is only a limit to what people can assume the user will or will not do. The issue is to make it easier for that user to know whats going on.
From what I've seen, all of the current notifications provide the user
with a way to act on them. Update/security notifications allow the user to update the system or view. SELinux has something similar. If there is to be a notification to the user about local email, a method of displaying that email should be provided that is automatically configured. It should open a list of messages and provide a way of reading them. There should be consistency for the end user.
Cron should drop it's logs into a directory with a name like ~/cronlog, if it can't find a local mta. Any user using cron should be competent enough to check the logs, configure the mta, or be able to do a google search as to how to do those things.
On Wed, Aug 26, 2009 at 3:56 PM, Rahul Sundaramsundaram@fedoraproject.org wrote: <snip>
My point is simply that most users in Fedora users are bound to use it on a desktop and wouldn't need a MTA and we should let people just install their mta of choice, be it exim, postfix or sendmail if they really need one. On the other hand, even if do a more full featured mta, I agree it is really high time we moved away from sendmail. SUSE, Ubuntu and Mandriva? is using postfix and Debian is using exim.
<snip>
1) We're not SUSE, Ubuntu, Mandriva or Debian so I don't see how their choice of MTA is relevant. 2) What exactly is the case for moving away from sendmail? Did it magically stop sending mail all the sudden?
-Adam
On 08/27/2009 03:32 AM, Adam Miller wrote:
- We're not SUSE, Ubuntu, Mandriva or Debian so I don't see how their
choice of MTA is relevant.
What other distributions and operating systems are doing is always going to be relevant. We can learn from the positives but beyond that if pretty much every other major distribution has moved away from sendmail, we have less to share on bug fixes and other improvements. This is ok for areas we are leading the development of, say PackageKit or NetworkManager but we don't have major developers working on any mta, so using what everyone else uses - in this case postfix wins by a large margin is a good choice.
- What exactly is the case for moving away from sendmail? Did it
magically stop sending mail all the sudden?
It has never started sending mails for people who got lost in arcane m4 macros. I suffered through that brain damage for 2 years as a sys admin in my previous job and I still think some of my nightmares are associated with it. Both Postfix and Exim is way more easier for system administration. The only real advantage for Sendmail is its legacy and the fact that it was for atleast for a while a better known beast.
Rahul
On Wed, 2009-08-26 at 17:02 -0500, Adam Miller wrote:
- What exactly is the case for moving away from sendmail? Did it
magically stop sending mail all the sudden?
it's a horrible ball of pain. I once spent a weekend trying to learn to drive sendmail. Got nothing but severe headaches to show for it. Postfix only took me four hours and six Tylenol to get my noodle around :)
On Wed, Aug 26, 2009 at 04:48:53PM -0400, Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Congratulations, you've now installed TWO mtas on every livecd install. Happy?
Nah. Once you add ssmtp to the core group, you can very well remove any mta's from the base group. This will solve the original problem being raised in the discussion as well.
Except it changes the default for everyone to something with less functionality, which I'm fairly sure we don't want to do after feature freeze. Notably, ssmtp won't queue if you're offline, if I'm reading the docs right.)
Yes, but the point Rahul is making here, if I understand correctly, is that 99 percent of the users (and I suspect he's right, judging from the forums) don't NEED it or want it. :)
(And those of us who do know what it is, prefer postfix. Exim is for Ubuntu people) <With ninja like speed, ducks the rotten fruit speeding at his head. OUCH--hrrm, that ninja speed decreases with age, apparently.>
Seriously, ssmtp will, as Rahul says, provide a (semi) functional server. Mention it in the release notes, and immediately after installation, the experienced can install Exim, postfix, or sendmail. (Listed alphabetically).
I understand Bill's point, but I think, in this case, Rahul's idea makes more sense. Yeah, ssmtp doesn't do very much--I think if you set default to localhost it *might* deliver locally, I'd have to check an ancient article of mine, but for most users, (again, making a general judgement from the sort who appear on the forums,) more logical in this case, in my most humble opinion. (Not being sarcastic with that, both of you are not only far more knowledgeable than I am, but also both quite receptive and understanding of users' input.)
On Tue, 2009-08-25 at 12:28 -0400, Scott Robbins wrote:
I don't know if this would be considered an issue or not. However, in this case, unchecking everything, that is, including everything in base, still tells me that I require CD1 and CD3.
This is because a select nothing install still requires a smtpd for cron jobs, and when no other smtpd is selected "exim" wins as it has the shortest name. However due to package ordering, exim winds up on disc3 (since the default smtp, sendmail, is picked if you actually add the group). I'm not entirely sure how I'm going to fix this that doesn't involve hard coding things for exim :/
I always specify ssmtp in this case within the .ks file. I use it for olpc related stuff and everything else. It doesn't do a lot of things like aliases or anything else but it gets past the issue in about 50K so I've long stopped caring. I've long had the bug below open since it changed.
There's a similar situation with perl within the defaults as well. I need to review the recent syslinux change with that and file bugs :)
https://bugzilla.redhat.com/show_bug.cgi?id=472710
Peter
Oh! The fdisk/parted compatibility conflict has finally hit me during installation. :)
Anaconda complains about being unable to process drive sda. No detailed error message. Just the options to either ignore the drive or reinitialise it. Made me scratch my head for a bit, because that drive is used for running Fedora 11 and 10 just fine.
$ parted /dev/sda print Error: Unable to satisfy all constraints on the partition.
Ah yes, at some point I had reordered the partition table with fdisk. And parted now refuses to access it. Full denial of service. Great error message, too. Isn't it really not possible to print the partition number, at least?
On Tue, Aug 25, 2009 at 7:56 AM, Jesse Keating wrote:
<insert witty comment that I'm up far too early to generate myself here>
Fedora 12 "Constantine" Alpha release is available! What's next for the free operating system that shows off the best new technology of tomorrow? You can see the future now at:
<snip>
We need your help to make Fedora 12 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it - every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution.
I tried out the F12 Alpha Live USB on two systems, an IBM thinkpad and a Dell Precision desktop (both with ATI).
On the thinkpad, the graphics was a bit garbled. The f11 smolt profile for that system is here:
http://www.smolts.org/client/show/pub_2c5ae01e-2458-4117-8e8d-1156d68c3815
On the Dell, the graphics looked OK, but the system hung in a manner consistent with what I've seen with graphics driver bugs. (unresponsive keyboard and mouse... had to power cycle). The graphics chip for this system was:
01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)] (rev 80)
After power cycling, the Live USB wouldn't boot ... instead, I got this message:
mknod: `/dev/mapper/control': File exists mount: you must specify the filesystem type Bug in initramfs /init detected. Dropping to a shell. Good luck!
bash: no job control in this shell bash-4.0#
I should mention that I did a yum update before the crash. Incidentally, I noticed there were a lot of updates and I didn't see any delta rpms although I might have missed that.
The only other problem I noticed in my limited testing before the crash was that NetworkManager pptp vpn didn't work for me. I'm pretty sure I had it configured identically to f11 where it does work.
David
On Wed, Aug 26, 2009 at 07:32:15AM -0700, David L wrote:
I should mention that I did a yum update before the crash. Incidentally, I noticed there were a lot of updates and I didn't see any delta rpms although I might have missed that.
Deltarpms were disabled in rawhide for quite a while due to a bug in mash dealing with unsigned->signed RPMs (which I think is fixed) and due to the change to an XZ payload (which I thin is also fixed).
josh
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
Automatic Bug Reporting Tool - This release provides ABRT, a service that automatically reports application crashed to Fedora, without requiring the end user to have any special knowledge on error reporting.
Unfortunately, on first GNOME login I only got the typical bug buddy crash dialog that failed to generate any backtrace.
---- Critical and fatal warnings logged during execution ----
** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
----------- .xsession-errors (12 sec old) --------------------- (gdu-notification-daemon:1490): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gdu-notification-daemon:1490): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gdu-notification-daemon:1490): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gdu-notification-daemon:1490): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gdu-notification-daemon:1490): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gdu-notification-daemon:1490): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gdu-notification-daemon:1490): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed Initializing nautilus-gdu extension
On Thu, Aug 27, 2009 at 4:01 PM, Michael Schwendtmschwendt.tmp0701.nospam@arcor.de wrote:
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
It has been in a 'not for testing' state since alpha-1. At most you can check up the wireless part. (But my install was updated 3 days ago)
Best
A. Mani
On Thu, Aug 27, 2009 at 7:33 AM, Mani A wrote:
On Thu, Aug 27, 2009 at 4:01 PM, Michael Schwendt wrote:
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
It has been in a 'not for testing' state since alpha-1.
Hmmm... didn't see that in the release notes. ;)
I have had NM work with both ethernet and wifi, but pptp vpn fails with a popup like this:
The VPN connection 'work' failed because the VPN service stopped unexpectedly.
I see a similar closed bug report from a year ago against nm openvpn:
https://bugzilla.redhat.com/show_bug.cgi?id=446335
But I'm having the problem with pptp. I see some old Ubuntu reports that look the same. But for me, the problem is new with f12. f11 works fine with the same setup. So I filed a new bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=519723
Regards,
David
On Thu, 2009-08-27 at 20:03 +0530, Mani A wrote:
On Thu, Aug 27, 2009 at 4:01 PM, Michael Schwendtmschwendt.tmp0701.nospam@arcor.de wrote:
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
It has been in a 'not for testing' state since alpha-1. At most you can check up the wireless part.
I don't know where you got that idea... NetworkManager has been working fine for me all through the F12 cycle, including wireless, wired and vpn.
On Thu, 2009-08-27 at 11:22 -0400, Matthias Clasen wrote:
On Thu, 2009-08-27 at 20:03 +0530, Mani A wrote:
On Thu, Aug 27, 2009 at 4:01 PM, Michael Schwendtmschwendt.tmp0701.nospam@arcor.de wrote:
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
It has been in a 'not for testing' state since alpha-1. At most you can check up the wireless part.
I don't know where you got that idea... NetworkManager has been working fine for me all through the F12 cycle, including wireless, wired and vpn.
Works fine for me too, as of today's Rawhide, managing a wireless connection and vpnc-type VPN connection.
On Thu, 27 Aug 2009 08:47:13 -0700, Adam wrote:
On Thu, 2009-08-27 at 11:22 -0400, Matthias Clasen wrote:
On Thu, 2009-08-27 at 20:03 +0530, Mani A wrote:
On Thu, Aug 27, 2009 at 4:01 PM, Michael Schwendt wrote:
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
It has been in a 'not for testing' state since alpha-1. At most you can check up the wireless part.
I don't know where you got that idea... NetworkManager has been working fine for me all through the F12 cycle, including wireless, wired and vpn.
Works fine for me too, as of today's Rawhide, managing a wireless connection and vpnc-type VPN connection.
F12 Alpha without updates, fresh install: None of NM's buttons work for me. Tried "Edit" and "Delete". Tried with eth1 (LAN) and eth0. Then gave up.
Meanwhile, I've disabled NM and set up networking with system-config-network instead. Updated to Rawhide, but that broke GNOME login. gconf-sanity-check- something exits with error code and drops me back to GDM.
On Thu, Aug 27, 2009 at 7:03 PM, Michael Schwendtmschwendt.tmp0701.nospam@arcor.de wrote:
On Thu, 27 Aug 2009 08:47:13 -0700, Adam wrote:
On Thu, 2009-08-27 at 11:22 -0400, Matthias Clasen wrote:
On Thu, 2009-08-27 at 20:03 +0530, Mani A wrote:
On Thu, Aug 27, 2009 at 4:01 PM, Michael Schwendt wrote:
What should I expect from NetworkManager? If doesn't do anything useful by default. Knows about eth0 and eth1, but they aren't active. Clicking "Edit" doesn't do anything either, regardless of whether I choose eth1 or eth0.
It has been in a 'not for testing' state since alpha-1. At most you can check up the wireless part.
I don't know where you got that idea... NetworkManager has been working fine for me all through the F12 cycle, including wireless, wired and vpn.
Works fine for me too, as of today's Rawhide, managing a wireless connection and vpnc-type VPN connection.
F12 Alpha without updates, fresh install: None of NM's buttons work for me. Tried "Edit" and "Delete". Tried with eth1 (LAN) and eth0. Then gave up.
Update policykit-gnome (needed if you want to edit system connections)