An unintended consequence of no default MTA in f20 is no local deliver of system mail. It IS possible to just ignore (or leave it to the logs) stuff going on in a desktop system, but services like logwatch are very helpful to maintain a healthy system. Plus there is cron for regular tasks we like to perform.
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
I suppose I should submit a bug report on this as the best way to get the developer's attention.
But does anyone have any good recommendation(s) on how to do this? I kind of like no MTA on resource straped systems, but we need to address local delivery.
On Mon, Dec 30, 2013 at 13:24:07 -0500, Robert Moskowitz rgm@htt-consult.com wrote:
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
It isn't clear you want the mail delivered locally. People aren't likely to be reading local mail.
You might want the info just logged in most cases with an alert done (sort of like selinux does) for important events.
On Mon, 30 Dec 2013 13:24:07 -0500 Robert Moskowitz rgm@htt-consult.com wrote:
An unintended consequence of no default MTA in f20 is no local deliver of system mail. It IS possible to just ignore (or leave it to the logs) stuff going on in a desktop system, but services like logwatch are very helpful to maintain a healthy system. Plus there is cron for regular tasks we like to perform.
If you want logwatch or have cron jobs with output you wish, feel free to install a MTA and configure it.
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
mailx is not a MTA.
I suppose I should submit a bug report on this as the best way to get the developer's attention.
But does anyone have any good recommendation(s) on how to do this? I kind of like no MTA on resource straped systems, but we need to address local delivery.
Those systems that need delivery can install a MTA. ;)
If you just want emails to go to another provider and your machine is connected to the internet, ssmtp is a good option (very simple to configure, just handles remote delivery).
kevin
On 12/30/2013 01:34 PM, Kevin Fenzi wrote:
On Mon, 30 Dec 2013 13:24:07 -0500 Robert Moskowitz rgm@htt-consult.com wrote:
An unintended consequence of no default MTA in f20 is no local deliver of system mail. It IS possible to just ignore (or leave it to the logs) stuff going on in a desktop system, but services like logwatch are very helpful to maintain a healthy system. Plus there is cron for regular tasks we like to perform.
If you want logwatch or have cron jobs with output you wish, feel free to install a MTA and configure it.
been there done that. Looking to follow the flow of no MTA. See if it can be done.
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
mailx is not a MTA.
It is a mail sender, typically to an MTA, but can it, or something else 'just' append /var/mail/user/ ?
I suppose I should submit a bug report on this as the best way to get the developer's attention.
But does anyone have any good recommendation(s) on how to do this? I kind of like no MTA on resource straped systems, but we need to address local delivery.
Those systems that need delivery can install a MTA. ;)
Local delivery only, so nothing to transfer ;)
If you just want emails to go to another provider and your machine is connected to the internet, ssmtp is a good option (very simple to configure, just handles remote delivery).
No. Local store only. If I want it to go to another server, I will use an MTA. Though thinking about it, if I am building a slim NAS with the arm distro, I might really WANT to use smtp... hmmm. But that is another project.
On 12/30/2013 01:29 PM, Bruno Wolff III wrote:
On Mon, Dec 30, 2013 at 13:24:07 -0500, Robert Moskowitz rgm@htt-consult.com wrote:
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
It isn't clear you want the mail delivered locally. People aren't likely to be reading local mail.
It isn't? Are you saying I was not clear in saying this is for local deliveries only, or are you saying that for some users, they may not want local delivery, as they don't read mail that is locally stored in /var/mail/user?
More so than going through the logs. Plus you probably can configure your mail reader to also process the local store as well as your mail server. Got to look at Thunderbird to see if I can...
You might want the info just logged in most cases with an alert done (sort of like selinux does) for important events.
cron DOES log and it is kind of unreadable. Plus the output of the cron process would be good to have.
And logwatch is all about taking logs and summarizing them. Log that as well? Seems a little convoluted.
Once upon a time, Robert Moskowitz rgm@htt-consult.com said:
On 12/30/2013 01:34 PM, Kevin Fenzi wrote:
On Mon, 30 Dec 2013 13:24:07 -0500 Robert Moskowitz rgm@htt-consult.com wrote: If you want logwatch or have cron jobs with output you wish, feel free to install a MTA and configure it.
been there done that. Looking to follow the flow of no MTA. See if it can be done.
Well, as it has been said, mailx is not an MTA, and it takes an MTA to transfer mail (even locally, because it crosses privilege boundaries). In the "old days", /bin/mail was setuid and could directly write /var/mail, but there were security issues with that and it is no longer supported (it also caused confusion when you actually had a local MTA configured to smart-host to a remote server).
If you want to handle mail in any fashion beyond using a client that sends/receives via network protocols (IMAP/POP3 and SMTP to a remote server, like mutt or Thunderbird), install an MTA. IIRC, at least Postfix and Sendmail will work for local mail handling (and not listening on the network) in a default install, so "yum install <your preferred MTA>" and you should be set.
On Mon, Dec 30, 2013 at 14:00:50 -0500, Robert Moskowitz rgm@htt-consult.com wrote:
It isn't? Are you saying I was not clear in saying this is for local deliveries only, or are you saying that for some users, they may not want local delivery, as they don't read mail that is locally stored in /var/mail/user?
The wording could have been better, but I do think that for many users, they aren't likely to be reading mail from the local machine (and less likely to be reading root's email). So for mail delivery I think it would make more sense to be able to easily send it to remote addresses rather than trying to drop it into /var/mail.
More so than going through the logs. Plus you probably can configure your mail reader to also process the local store as well as your mail server. Got to look at Thunderbird to see if I can...
Some clients can definitely do that, but it isn't going to obvious to people that they should do that. I think it's going to be sysadm types that worry about what's getting sent to root on their machines.
And logwatch is all about taking logs and summarizing them. Log that as well? Seems a little convoluted.
It depends on how much value is added by the short logs.
I think for normal desktop users, desktop alerts of abnormal activity is going to be more useful then log extracts. However, currently logwatch reports a lot of stuff that isn't really important and you wouldn't want generate alerts for everything it currently reports on.
On 12/31/13 02:24, Robert Moskowitz wrote:
An unintended consequence of no default MTA in f20 is no local deliver of system mail. It IS possible to just ignore (or leave it to the logs) stuff going on in a desktop system, but services like logwatch are very helpful to maintain a healthy system. Plus there is cron for regular tasks we like to perform.
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
I suppose I should submit a bug report on this as the best way to get the developer's attention.
But does anyone have any good recommendation(s) on how to do this? I kind of like no MTA on resource straped systems, but we need to address local delivery.
I can't see what the problem is.....
yum install sendmail gets you what was before.
Is this really an insurmountable obstacle?
On Tue, 2013-12-31 at 03:23 +0800, Ed Greshko wrote:
On 12/31/13 02:24, Robert Moskowitz wrote:
An unintended consequence of no default MTA in f20 is no local deliver of system mail. It IS possible to just ignore (or leave it to the logs) stuff going on in a desktop system, but services like logwatch are very helpful to maintain a healthy system. Plus there is cron for regular tasks we like to perform.
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
I suppose I should submit a bug report on this as the best way to get the developer's attention.
But does anyone have any good recommendation(s) on how to do this? I kind of like no MTA on resource straped systems, but we need to address local delivery.
I can't see what the problem is.....
yum install sendmail gets you what was before.
Is this really an insurmountable obstacle?
Agreed. I did when I saw it wasn't installed by default. Works just fine (and always has).
-- Mark C. Allman, PMP, CSM
On 12/30/2013 02:20 PM, Chris Adams wrote:
Once upon a time, Robert Moskowitz rgm@htt-consult.com said:
On 12/30/2013 01:34 PM, Kevin Fenzi wrote:
On Mon, 30 Dec 2013 13:24:07 -0500 Robert Moskowitz rgm@htt-consult.com wrote: If you want logwatch or have cron jobs with output you wish, feel free to install a MTA and configure it.
been there done that. Looking to follow the flow of no MTA. See if it can be done.
Well, as it has been said, mailx is not an MTA, and it takes an MTA to transfer mail (even locally, because it crosses privilege boundaries). In the "old days", /bin/mail was setuid and could directly write /var/mail, but there were security issues with that and it is no longer supported (it also caused confusion when you actually had a local MTA configured to smart-host to a remote server).
If you want to handle mail in any fashion beyond using a client that sends/receives via network protocols (IMAP/POP3 and SMTP to a remote server, like mutt or Thunderbird), install an MTA. IIRC, at least Postfix and Sendmail will work for local mail handling (and not listening on the network) in a default install, so "yum install <your preferred MTA>" and you should be set.
Oh well. It was a thought. Postfix, here it comes.
But I will want to look more into something slimmer for a NAS that would always send to a remote host.
On 12/30/2013 02:23 PM, Ed Greshko wrote:
On 12/31/13 02:24, Robert Moskowitz wrote:
An unintended consequence of no default MTA in f20 is no local deliver of system mail. It IS possible to just ignore (or leave it to the logs) stuff going on in a desktop system, but services like logwatch are very helpful to maintain a healthy system. Plus there is cron for regular tasks we like to perform.
So no MTA seems good IF we can configure mailx to do the local deliveries. I am kind of assuming that some changes to /etc/mail.rc might do part of the job. Probably some /bin/sendmail script that maps sendmail arguments to a mailx call. Plus if you DO install sendmail or postfix, it should undo this setup.
I suppose I should submit a bug report on this as the best way to get the developer's attention.
But does anyone have any good recommendation(s) on how to do this? I kind of like no MTA on resource straped systems, but we need to address local delivery.
I can't see what the problem is.....
yum install sendmail gets you what was before.
Is this really an insurmountable obstacle?
No. Just trying to see what is possible. Given that no sendmail, could local delivery be made to work without an MTA.
Well it got explained to me that, no. Even local delivery needs an MTA.
So I will start with postfix, as that is what I run on my mail server and my other servers.
But which is the kindest to the system resources, sendmail or postfix? Centos switched to postfix a couple releases ago as the default MTA (as I seem to recall).
Hi Chris,
On Mon, Dec 30, 2013 at 01:20:04PM -0600, Chris Adams wrote:
Once upon a time, Robert Moskowitz rgm@htt-consult.com said:
On 12/30/2013 01:34 PM, Kevin Fenzi wrote:
On Mon, 30 Dec 2013 13:24:07 -0500 Robert Moskowitz rgm@htt-consult.com wrote: If you want logwatch or have cron jobs with output you wish, feel free to install a MTA and configure it.
been there done that. Looking to follow the flow of no MTA. See if it can be done.
Well, as it has been said, mailx is not an MTA, and it takes an MTA to transfer mail (even locally, because it crosses privilege boundaries). In the "old days", /bin/mail was setuid and could directly write /var/mail, but there were security issues with that and it is no longer supported (it also caused confusion when you actually had a local MTA configured to smart-host to a remote server).
If you want to handle mail in any fashion beyond using a client that sends/receives via network protocols (IMAP/POP3 and SMTP to a remote server, like mutt or Thunderbird), install an MTA. IIRC, at least Postfix and Sendmail will work for local mail handling (and not listening on the network) in a default install, so "yum install <your preferred MTA>" and you should be set.
I was under the same impression, hence my original thread:
https://lists.fedoraproject.org/pipermail/users/2013-December/443441.html
However I was told (by Frank) that it is possible using mailx.
https://lists.fedoraproject.org/pipermail/users/2013-December/444265.html https://lists.fedoraproject.org/pipermail/users/2013-December/444304.html
So now I'm completely lost as to what is possible and what is not. For now I have sendmail installed, but if possible I would like to remove that (at least on my laptop).
Hope that makes sense. And thanks for any explanations.
Cheers,
On 12/30/2013 07:46 PM, Suvayu Ali wrote:
Hi Chris,
On Mon, Dec 30, 2013 at 01:20:04PM -0600, Chris Adams wrote:
Once upon a time, Robert Moskowitz rgm@htt-consult.com said:
On 12/30/2013 01:34 PM, Kevin Fenzi wrote:
On Mon, 30 Dec 2013 13:24:07 -0500 Robert Moskowitz rgm@htt-consult.com wrote: If you want logwatch or have cron jobs with output you wish, feel free to install a MTA and configure it.
been there done that. Looking to follow the flow of no MTA. See if it can be done.
Well, as it has been said, mailx is not an MTA, and it takes an MTA to transfer mail (even locally, because it crosses privilege boundaries). In the "old days", /bin/mail was setuid and could directly write /var/mail, but there were security issues with that and it is no longer supported (it also caused confusion when you actually had a local MTA configured to smart-host to a remote server).
If you want to handle mail in any fashion beyond using a client that sends/receives via network protocols (IMAP/POP3 and SMTP to a remote server, like mutt or Thunderbird), install an MTA. IIRC, at least Postfix and Sendmail will work for local mail handling (and not listening on the network) in a default install, so "yum install <your preferred MTA>" and you should be set.
I was under the same impression, hence my original thread:
https://lists.fedoraproject.org/pipermail/users/2013-December/443441.html
However I was told (by Frank) that it is possible using mailx.
https://lists.fedoraproject.org/pipermail/users/2013-December/444265.html https://lists.fedoraproject.org/pipermail/users/2013-December/444304.html
So now I'm completely lost as to what is possible and what is not. For now I have sendmail installed, but if possible I would like to remove that (at least on my laptop).
Hope that makes sense. And thanks for any explanations.
I did search, and read your post and made responses before starting this thread.
I can see why the securities boundary issue means that a secure process with elevated privledges has to do the writing to /var/mail, and mailx does not run as such. Thus we need a real MTA for this purpose and choose sendmail or postfix.
On Mon, Dec 30, 2013 at 08:06:37PM -0500, Robert Moskowitz wrote:
I can see why the securities boundary issue means that a secure process with elevated privledges has to do the writing to /var/mail, and mailx does not run as such. Thus we need a real MTA for this purpose and choose sendmail or postfix.
All that is fine, and I follow the reasoning. But saying mailx cannot do the job is contradictory to Frank's experience in the original thread. I would like to know what is the bit that makes Frank's setup work so that I can replicate it on my less powerful machines.
On Tue, 31 Dec 2013 01:46:07 +0100 Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
I was under the same impression, hence my original thread:
https://lists.fedoraproject.org/pipermail/users/2013-December/443441.html
However I was told (by Frank) that it is possible using mailx.
https://lists.fedoraproject.org/pipermail/users/2013-December/444265.html https://lists.fedoraproject.org/pipermail/users/2013-December/444304.html
So now I'm completely lost as to what is possible and what is not. For now I have sendmail installed, but if possible I would like to remove that (at least on my laptop).
Hope that makes sense. And thanks for any explanations.
Cheers,
Apology for delay in answering, away from PC. Saw new thread. Answered here?
With "Claws-Mail" it saves as numbered individual plain text files, mailx will create a dead.letter plain text file for mail it cannot be sent.
sudo crontab -e */5 * * * * /usr/././system_mail cat system_mail mv ~/dead.letter ~/Mail/inbox/Local/2 (root is 3) That't the short of it.
Set up works for my needs.
On Tue, 31 Dec 2013 02:27:06 +0000 Frank Murphy frankly3d@gmail.com wrote:
Apologies for self-reply. Figured a picture == 1000 these things: http://www.zimagez.com/zimage/screenshot-311213-024006.php
Test-Email was: ls -l $HOME | mailx -s "The content of my home directory" frank
On 12/31/13 10:14, Suvayu Ali wrote:
On Mon, Dec 30, 2013 at 08:06:37PM -0500, Robert Moskowitz wrote:
I can see why the securities boundary issue means that a secure process with elevated privledges has to do the writing to /var/mail, and mailx does not run as such. Thus we need a real MTA for this purpose and choose sendmail or postfix.
All that is fine, and I follow the reasoning. But saying mailx cannot do the job is contradictory to Frank's experience in the original thread. I would like to know what is the bit that makes Frank's setup work so that I can replicate it on my less powerful machines.
First of all, let me reiterate one thing. "sendmail" does not do local delivery by itself. It relies on another program to do this. In the default configuration (sendmail.mc) on Fedora it is defined to use procmail for local delivery.
Now, if you (pl) would do a bit of man page reading you'd find in "man crond"....
-m This option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This com‐ mand must accept a fully formatted mail message (with headers) on standard input and send it as a mail message to the recipients specified in the mail headers. Specifying the string off (i.e., crond -m off) will disable the sending of mail.
So, you can edit /etc/sysconfig/crond to contain....
CRONDARGS=-m/bin/procmail
systemctl restart crond.service
Now, the only "problem" is that procmail cannot initially create files in /var/mail. So, to get this to work you'll need to do, as root....
touch /var/mail/username chown username:mail /var/mail/username
I know this works with procmail but not sure about mailx. You can certainly test....
So, you don't need sendmail. procmail will do just fine.
Hi Frank,
On Tue, Dec 31, 2013 at 02:27:06AM +0000, Frank Murphy wrote:
On Tue, 31 Dec 2013 01:46:07 +0100 Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
I was under the same impression, hence my original thread:
https://lists.fedoraproject.org/pipermail/users/2013-December/443441.html
However I was told (by Frank) that it is possible using mailx.
https://lists.fedoraproject.org/pipermail/users/2013-December/444265.html https://lists.fedoraproject.org/pipermail/users/2013-December/444304.html
So now I'm completely lost as to what is possible and what is not. For now I have sendmail installed, but if possible I would like to remove that (at least on my laptop).
Apology for delay in answering, away from PC. Saw new thread. Answered here?
No worries, it is holiday season ... "away from PC" is how it should be ;).
With "Claws-Mail" it saves as numbered individual plain text files, mailx will create a dead.letter plain text file for mail it cannot be sent.
sudo crontab -e */5 * * * * /usr/././system_mail cat system_mail mv ~/dead.letter ~/Mail/inbox/Local/2 (root is 3) That't the short of it.
Okay, now I follow. I did get ~/dead.letter when mail failed during my test. Since in my case system mail is generated both by root and <user> this would be an unworkable solution. I think I will investigate Ed's suggestions further.
Thanks and happy new year,
On 12/31/13 10:50, Ed Greshko wrote:
So, you don't need sendmail. procmail will do just fine.
I should mention one downside to using this approach.....
The mail which crond feeds to the mailer lacks a "Date:" header. So, if you use this, or potentially, another mailer such as mailx the message in your inbox will look similar to this....
From: "(Cron Daemon)" <egreshko> To: egreshko Subject: Cron egreshko@f20f du -h --max-depth=1 /home/egreshko Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated Precedence: bulk X-Cron-Env: <XDG_SESSION_ID=61> X-Cron-Env: <XDG_RUNTIME_DIR=/run/user/1001> X-Cron-Env: <LANG=en_US.UTF-8> X-Cron-Env: <HELL=/bin/bash> X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin> X-Cron-Env: <MAILTO=egreshko> X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/home/egreshko> X-Cron-Env: <LOGNAME=egreshko> X-Cron-Env: <USER=egreshko>
On Tue, Dec 31, 2013 at 10:50:46AM +0800, Ed Greshko wrote:
On 12/31/13 10:14, Suvayu Ali wrote:
On Mon, Dec 30, 2013 at 08:06:37PM -0500, Robert Moskowitz wrote:
I can see why the securities boundary issue means that a secure process with elevated privledges has to do the writing to /var/mail, and mailx does not run as such. Thus we need a real MTA for this purpose and choose sendmail or postfix.
All that is fine, and I follow the reasoning. But saying mailx cannot do the job is contradictory to Frank's experience in the original thread. I would like to know what is the bit that makes Frank's setup work so that I can replicate it on my less powerful machines.
First of all, let me reiterate one thing. "sendmail" does not do local delivery by itself. It relies on another program to do this. In the default configuration (sendmail.mc) on Fedora it is defined to use procmail for local delivery.
Okay, makes sense.
Now, if you (pl) would do a bit of man page reading you'd find in "man crond"....
-m This option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This com‐ mand must accept a fully formatted mail message (with headers) on standard input and send it as a mail message to the recipients specified in the mail headers. Specifying the string off (i.e., crond -m off) will disable the sending of mail.So, you can edit /etc/sysconfig/crond to contain....
CRONDARGS=-m/bin/procmail
systemctl restart crond.service
Now, the only "problem" is that procmail cannot initially create files in /var/mail. So, to get this to work you'll need to do, as root....
touch /var/mail/username chown username:mail /var/mail/username
I know this works with procmail but not sure about mailx. You can certainly test....
So, you don't need sendmail. procmail will do just fine.
Okay I follow, it seems what you propose should work. However cron is not the only thing that sends mail for me. In my post it was just the most frequent example. For example, I want to receive mail from smartd (particularly important!), denyhosts, ddclient, etc. I would then have to setup something like the above for all such use cases.
I guess it is simplest to just use an MTA. Thanks for the response though, I understand the system mail system better now.
And happy new year,
:)
On Tue, 31 Dec 2013 10:50:46 +0800 Ed Greshko Ed.Greshko@greshko.com wrote:
I know this works with procmail but not sure about mailx. You can certainly test....
So, you don't need sendmail. procmail will do just fine.
systemctl status crond.service 4181 /usr/sbin/crond -n -m/usr/bin/mailx Cron-Daemon root
To: root@localhost Subject: rkhunter Daily Run on frank01* Date: Tue, 31 Dec 2013 11:44:02 +0000 User-Agent: Heirloom mailx 12.5 7/5/10
On 12/30/2013 08:20 PM, Bruno Wolff III wrote:
they aren't likely to be reading mail from the local machine (and less likely to be reading root's email).
That's the reason for /etc/aliases Just make an alias for root, sending root mail to a certain user or users.
So for mail delivery I think it would make more sense to be able to easily send it to remote addresses rather than trying to drop it into /var/mail.
/etc/aliases root local_user or root some@where.org
should do it...
This should IMHO be a part of the install process. We then need an MTA of some sort. (I mentioned this when dropping sendmail was discussed on the devel list, but sadly they chose to remove the MTA, thereby loosing mail from cron jobs, logwatch, etc.)
Most mail clients can receive local mail, so it ending up in /var/spool/mail/something is better that it getting lost totally. You can even do 'tail -100 /var/spool/mail/user' to read that mail :)
This change, combined with the syslog removal, will probably lead to more users missing information, as they do not get any mails from the system, and reading logs has become bit harder, as we no longer have plain text files but must use journalctl (that on my systems is quite sluggish).
I think for normal desktop users, desktop alerts of abnormal activity is going to be more useful then log extracts. However, currently logwatch reports a lot of stuff that isn't really important and you wouldn't want generate alerts for everything it currently reports on.
Logwatch watches the logs and report strange things. I find it useful. What would you like removed from it?
Lars
On 12/30/2013 08:23 PM, Ed Greshko wrote:
I can't see what the problem is.....
yum install sendmail gets you what was before.
Is this really an insurmountable obstacle?
No. Not for me. But perhaps for other users. Perhaps not as savvy when it comes to computers. Would it not be nice if these people easily could get information from the system in form of mails?
Removing sendmail and syslog will probably make it harder for an ordinary user to understand problems on their computer, as they not easily can get information about what is happening to their system.
Including sendmail and syslog makes it easier for the ordinary user. And that is a good thing. At least in my book.
Lars
Hi
On Tue, Dec 31, 2013 at 12:15 PM, Lars E. Pettersson wrote:
Including sendmail and syslog makes it easier for the ordinary user. And that is a good thing. At least in my book.
That seems to be made up. "ordinary users" are not reading mails send to root or carefully reading /var/log/messages and to the extend any user is wanting to go through logs, they will find the features of integrated tools like journalctl much much more useful than raw grepping.
Rahul
On Tue, Dec 31, 2013 at 18:05:05 +0100, "Lars E. Pettersson" lars@homer.se wrote:
Logwatch watches the logs and report strange things. I find it useful. What would you like removed from it?
I think for normal people they just need to be alerted to critical things, like low disk storage, hardware errors and strong indications that their machine is compromised. Reporting failed attacks on a machine are generally not going to be of interest. General summaries are also not going to be of interest.
On 12/31/2013 06:27 PM, Rahul Sundaram wrote:
That seems to be made up. "ordinary users" are not reading mails send to root or carefully reading /var/log/messages and to the extend any user is wanting to go through logs, they will find the features of integrated tools like journalctl much much more useful than raw grepping.
"Made up"? No. Rahul, "ordinary users" do read mail, and if they easily can find out how to use journalctl, they could equally easily find out how to get root mail sent to their own local mail spool (I have even proposed that this, adding 'root local_user' to /etc/aliases, should be a part of the install of Fedora).
Reading a text file is easy, fast, and creates no problems for most users. Journalctl has on my systems been sluggish (simple searches have taken a long time, even systemctl status takes long time when showing the log lines), and if you want to get information about a certain event you often have to use grep, the same grep command that you refer to, to find what you are looking for.
Rahul. Mail is sent to root by different parts of the install, it could be outputs from cron, logwatch, etc. Is it not better that this information is sent to the main user on the system, than being lost? Is it not better to include a simple basic form of log, in pure ASCII form, that can be easily read?
Again, for you or me this is no problem. We can set up our computers to do exactly whatever we want, but should we not strive to make the system easy to use, and to get information from, even for an "ordinary user" not as savvy as we?
Lars
On Tue, Dec 31, 2013 at 06:55:34PM +0100, Lars E. Pettersson wrote:
Again, for you or me this is no problem. We can set up our computers to do exactly whatever we want, but should we not strive to make the system easy to use, and to get information from, even for an "ordinary user" not as savvy as we?
Often I find myself trying to help a friend with their technical problem remotely. It really helps when more information is available. This is why I think just saying "a regular user won't need this" is wrong. I would say it is actually even more important for regular users to have sensible defaults so that when things do go wrong (which we all know will happen at some point), an expert has all the information to resolve it.
Anyway, I guess this discussion is moot; as Rahul says, the decision is made. I have used Fedora for a while now, and I will keep on using it for the foreseeable future; but lately I've been less and less likely to recommend it to others, even to tech-savvy persons.
Cheers & happy NY,
HI
On Tue, Dec 31, 2013 at 12:55 PM, Lars E. Pettersson wrote:
On 12/31/2013 06:27 PM, Rahul Sundaram wrote:
That seems to be made up. "ordinary users" are not reading mails send to root or carefully reading /var/log/messages and to the extend any user is wanting to go through logs, they will find the features of integrated tools like journalctl much much more useful than raw grepping.
"Made up"? No. Rahul, "ordinary users" do read mail, and if they easily can find out how to use journalctl, they could equally easily find out how to get root mail sent to their own local mail spool
I don't buy into this argument at all. For one, there are graphical log utilities that a regular user would be a lot more comfortable and then root mail is mostly useless for a regular user. If you think a regular user is spending time reading mails from root or reading /var/log/messages, you got a definition of "normal user" that doesn't look anything close to realistic. Anyone who is interested enough in reading root mails in a Fedora box should be more than capable of installing an MTA.
Rahul
On 12/31/2013 07:28 PM, Rahul Sundaram wrote:
I don't buy into this argument at all. For one, there are graphical log utilities that a regular user would be a lot more comfortable and then root mail is mostly useless for a regular user. If you think a regular user is spending time reading mails from root or reading /var/log/messages, you got a definition of "normal user" that doesn't look anything close to realistic. Anyone who is interested enough in reading root mails in a Fedora box should be more than capable of installing an MTA.
What graphical log utilities are you thinking about?
Yes, regular users do spend time reading mail from root (after they have found out how /etc/aliases work), and they do look at /var/log/messages. Of course there are users that never have done either, but I would bet a majority has (this based on people I know and have met since I started with Linux mid 1990).
We should have sane defaults in the system. And providing a facility to move mail locally is a good one. Why let the mails sent to root get totally lost? As is the case in f20? Would it not be better to use an MTA to move this to the main users mail spool (using /etc/aliases setup at installation of the system)?
Why should we guard the user from seeing mail from the system? Or provide a simple way for them to find out what is happening with the system?
How do you propose that we should make it simple for an ordinary user to get information from and about the system?
Lars
Hi
On Tue, Dec 31, 2013 at 1:58 PM, Lars E. Pettersson wrote:
Yes, regular users do spend time reading mail from root (after they have
found out how /etc/aliases work), and they do look at /var/log/messages. Of course there are users that never have done either, but I would bet a majority has (this based on people I know and have met since I started with Linux mid 1990).
That would be a lousy bet really. You can be aligning yourself with more technical users. Regular uses probably have never heard of /etc/aliases at all and certainly don't read root mail at all.
How do you propose that we should make it simple for an ordinary user to get information from and about the system?
Depends on the information and the use cases. If you are a server user, you pick the MTA you want and you have to configure it anyway. For desktop users, there are several methods to get the information they typically care about ex: desktop notification that disk is failing and it is feasible to extend them to cover more things.
Rahul
On 12/31/2013 08:37 PM, Rahul Sundaram wrote:
That would be a lousy bet really. You can be aligning yourself with more technical users.
On a similar note. What do you base your opinion on?
(Some of them have been "technical users", but by no means all)
Regular uses probably have never heard of /etc/aliases at all and certainly don't read root mail at all.
If a user can read about journalctl and find information about how to use that, he/she could equally well do the same thing regarding /etc/aliases and reading root mail. (Remember that I proposed that /etc/aliases should be setup at install time of Fedora, so that would already be in place, following my proposal)
For desktop users, there are several methods to get the information they typically care about ex: desktop notification that disk is failing and it is feasible to extend them to cover more things.
That was the use case I was thinking about. (In the server case the administrator (hopefully) have knowledge to set up the system the way he/she wants, including/excluding MTA and/or syslog facilities.)
Notifications could be one way for some things. Perhaps output from root mail, cron, logwatch or similar applications could be taken care of that way.
But there must also be a way to look into logs in an easy way.
The user might experience some problems with the installation. He/she contacts a friend. The usual response often is, "what does the log say", or "could you find xyz in the log", or something similar. So whatever one thinks about logs, they are important, even for non technical users. And an ASCII file is often easier for a non technical user to handle than a new and perhaps never used command.
As we do not have a (full-blown) system where mail to root could be shown to the user as notifications. And simple text files actually is easier for non technical users to handle. It still makes sense to include a MTA and syslog. When we have applications that take care of these things, and present them to the user in a good way, then we could remove the MTA and syslog. At the moment the user is left in some sort of limbo loosing mails sent to root, and having problems reading log files.
Off to new year celebrations here. Happy new year to all! Lars
Hi
On Tue, Dec 31, 2013 at 4:04 PM, Lars E. Pettersson wrote:
On 12/31/2013 08:37 PM, Rahul Sundaram wrote:
That would be a lousy bet really. You can be aligning yourself with more technical users.
On a similar note. What do you base your opinion on?
Dozens and dozens of Linux conferences, locally and internationally. About 10 years of experience as a active Fedora contributor and I deal with regular users all the time answering thousands of questions over that period here, in ask.fedoraproject.org and fedoraforum.org among others.
(Some of them have been "technical users", but by no means all)
Regular uses probably have never heard of /etc/aliases
at all and certainly don't read root mail at all.
If a user can read about journalctl and find information about how to use that, he/she could equally well do the same thing regarding /etc/aliases and reading root mail. (Remember that I proposed that /etc/aliases should be setup at install time of Fedora, so that would already be in place, following my proposal
Your proposal is irrelevant when we are talking about current reality. journalctl is not a requirement to read logs. It is just far more easier than grepping through /var/log/messages for the common use cases. As I mentioned before desktop environment have graphical utilities to read log files. gnome-system-log for /var/log/messages for example.
GNOME is also getting a systemd specific log viewer as well
https://mail.gnome.org/archives/gnome-announce-list/2013-September/msg00097....
Other similar utilities are available for other DE's as well. If it is important, the DE should notify the user proactively and not wait on them to read some log file
Rahul
On 12/31/2013 01:20 PM, Rahul Sundaram wrote:
Your proposal is irrelevant when we are talking about current reality. journalctl is not a requirement to read logs. It is just far more easier than grepping through /var/log/messages for the common use cases.
Not always. As an example, I'm getting error messages at boot time on my laptop about [sdb] even though there isn't one. Locating them with journalctl would require me to know exactly what field to look for, instead of just doing this as root:
cat /var/log/messages | grep [sdb]
Of course, if you do know the field name, such as when you're looking for messages from a service started at boot by systemd, journalctl may well be your best bet. It all depends on what you're looking for and what info you already have.
2013/12/31 Joe Zeff joe@zeff.us:
Not always. As an example, I'm getting error messages at boot time on my laptop about [sdb] even though there isn't one. Locating them with journalctl would require me to know exactly what field to look for, instead of just doing this as root:
cat /var/log/messages | grep [sdb]
Of course, if you do know the field name, such as when you're looking for messages from a service started at boot by systemd, journalctl may well be your best bet. It all depends on what you're looking for and what info you already have.
Journalctl does not prevent you from using generic text search tools like grep. For example, this should have pretty same results as your example:
journalctl | grep [sdb]
You would likely want to limit the journalctl command a bit to avoid searching from the entire locally stored history. This can be avoided by using journalctl -b or journalctl --since -7d or some other parameters that limit the search to just the recent logs.
If I was looking for something sdb related problem, my preferred way to start looking for it would be to run maybe journalctl --since -7d and then use the text search of less to point me at the relevant parts of the log. Often it is useful to not immediately trim out all except the lines that match some search. OTOH if you need specifically that, you can use grep like you could with a plaintext syslog file.
-Joonas
Hi
On Tue, Dec 31, 2013 at 4:36 PM, Joe Zeff joe@zeff.us wrote:
On 12/31/2013 01:20 PM, Rahul Sundaram wrote:
Your proposal is irrelevant when we are talking about current reality. journalctl is not a requirement to read logs. It is just far more easier than grepping through /var/log/messages for the common use cases.
Not always. As an example, I'm getting error messages at boot time on my laptop about [sdb] even though there isn't one. Locating them with journalctl would require me to know exactly what field to look for,
No. That's just blatantly wrong. journalctl's output is a pixel perfect match of /var/log/messages.
Rahul
On Mon, Dec 30, 2013 at 6:24 PM, Robert Moskowitz rgm@htt-consult.com wrote:
An unintended consequence of no default MTA in f20 is no local deliver of system mail.
It isn't an unintended consequence.
It was decided that having an MTA wasn't needed in the default install and those who need local delivery of system mail could install one.
On 12/31/2013 10:49 PM, Rahul Sundaram wrote:
No. That's just blatantly wrong. journalctl's output is a pixel perfect match of /var/log/messages.
No, it's not:
journalctl -f contains the following Jan 01 00:10:01 tux systemd[1]: Starting Session 98 of user root. Jan 01 00:10:01 tux systemd[1]: Started Session 98 of user root. Jan 01 00:10:01 tux CROND[9317]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 01 00:20:01 tux systemd[1]: Starting Session 99 of user root. Jan 01 00:20:01 tux systemd[1]: Started Session 99 of user root. Jan 01 00:20:01 tux CROND[9557]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 01 00:30:01 tux systemd[1]: Starting Session 100 of user root. Jan 01 00:30:01 tux systemd[1]: Started Session 100 of user root. Jan 01 00:30:01 tux CROND[9726]: (root) CMD (/usr/lib64/sa/sa1 1 1)
tail /var/log/messages
Jan 1 00:10:01 localhost systemd: Starting Session 98 of user root. Jan 1 00:10:01 localhost systemd: Started Session 98 of user root. Jan 1 00:20:01 localhost systemd: Starting Session 99 of user root. Jan 1 00:20:01 localhost systemd: Started Session 99 of user root. Jan 1 00:30:01 localhost systemd: Starting Session 100 of user root. Jan 1 00:30:01 localhost systemd: Started Session 100 of user root.
tail /var/log/cron
Jan 1 00:10:01 localhost CROND[9317]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 1 00:20:01 localhost CROND[9557]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 1 00:30:01 localhost CROND[9726]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Spot the differences?
Lars
Hi
On Tue, Dec 31, 2013 at 6:40 PM, Lars E. Pettersson wrote:
On 12/31/2013 10:49 PM, Rahul Sundaram wrote:
No. That's just blatantly wrong. journalctl's output is a pixel perfect match of /var/log/messages.
No, it's not:
Sure, it has some improvements controllable via options but nothing that would trip up grep. The point is that you don't need to know any fields to use the journalctl output.
Rahul
On Wed, Jan 1, 2014 at 1:13 AM, Heinz Diehl htd@fritha.org wrote:
On 30.12.2013, Robert Moskowitz wrote:
But which is the kindest to the system resources, sendmail or postfix?
Postfix, definitely.
exim uses even less. If you just want local delivery, then any of these MTA's will work out of the box without config. I used sendmail for many years and postfix for much longer. I now sometimes use exim. Once you want incoming mail then you need to read the docs and set them up. Exim is probably more configurable, but I'd say postfix can handle more load.
On 12/31/2013 11:10 PM, David Beveridge wrote:
On Wed, Jan 1, 2014 at 1:13 AM, Heinz Diehl htd@fritha.org wrote:
On 30.12.2013, Robert Moskowitz wrote:
But which is the kindest to the system resources, sendmail or postfix?
Postfix, definitely.
exim uses even less. If you just want local delivery, then any of these MTA's will work out of the box without config. I used sendmail for many years and postfix for much longer. I now sometimes use exim. Once you want incoming mail then you need to read the docs and set them up. Exim is probably more configurable, but I'd say postfix can handle more load.
I need local delivery on my notebook, but not a lot. Logwatch and cron are all that I ever saw with my f17 install for a year+. So I am looking at what I can do for not using an MTA at all. Looking in part at what Lars was saying, what can be changed in the base install so that these base utilities that are expected to use email, can at least do local delivery as the default behaviour.
We have had a few discussions on cron. So far I have done the procmail, but I will probably change that to mailx. For logwatch, I noticed that
mailer = "/usr/sbin/sendmail -t"
is in the default conf, so I added an override of
mailer = "/usr/bin/mailx -t"
I am looking at going with the flow that a notebook should not need an MTA, but there are services that are written to deliver their output via mail, and local delivery is easy to set up.
I will continue to use mutt, for a while, but look at configuring thunderbird to read in the local mail. I suppose, to follow through, I really should figure out how evolution can do this, but I always uninstall it.
On 01.01.2014, Robert Moskowitz wrote:
I am looking at going with the flow that a notebook should not need an MTA
Any MTA for just one user will do. You won't even notice that it's there. System load and the ability to handle a lot of connections is not relevant in this case.
I will continue to use mutt, for a while, but look at configuring thunderbird to read in the local mail. I suppose, to follow through, I really should figure out how evolution can do this, but I always uninstall it.
I've never found anything better than mutt, in all those years..
On 01/01/2014 04:26 AM, Heinz Diehl wrote:
On 01.01.2014, Robert Moskowitz wrote:
I am looking at going with the flow that a notebook should not need an MTA
Any MTA for just one user will do.
But what's the fun in that? TPTB have decreed no MTA default. But CRON is in by default, so perhaps...
I've thought more about this as I dozed off last night. ;) A person has to be a little informed to use cron, thus they can also be informed about configuring it to email. One way or another. Anyone who installs logwatch does so to get EMAILed logwatches; part of that would be to add email support. One way or another.
You won't even notice that it's there. System load and the ability to handle a lot of connections is not relevant in this case.
I will continue to use mutt, for a while, but look at configuring thunderbird to read in the local mail. I suppose, to follow through, I really should figure out how evolution can do this, but I always uninstall it.
I've never found anything better than mutt, in all those years..
Same here. But if local delivery of stuff is a valid solution, that means there is a person at the system, and typically some email client. It should support reading the local mail store. If there is not person at the system, it is a server of some sort and needs remote delivery of emails which means an MTA along with all the server components.
On 01/01/2014 03:16 AM, Rahul Sundaram wrote:
On 12/31/2013 10:49 PM, Rahul Sundaram wrote: No. That's just blatantly wrong. journalctl's output is a pixel perfect match of /var/log/messages.
...
Sure, it has some improvements controllable via options but nothing that would trip up grep. The point is that you don't need to know any fields to use the journalctl output.
What improvements? Is it possible to get it "a pixel perfect match" using options?
What you do need to know is where the fields differ. This as you might need to update your scripts to handle these differences.
I can not see any reason why the output of journalctl can not to be "a pixel perfect match", so why is it not?
Lars
HI
On Wed, Jan 1, 2014 at 3:40 PM, Lars E. Pettersson wrote:
What improvements? Is it possible to get it "a pixel perfect match" using options?
What you do need to know is where the fields differ. This as you might need to update your scripts to handle these differences.
I can not see any reason why the output of journalctl can not to be "a pixel perfect match", so why is it not?
If you want to find out what journalctl can support, look at the man page. If you have suggestions for improvements, post it in Bugzilla like I did yesterday.
Rahul
On 01/01/2014 10:19 PM, Rahul Sundaram wrote:
If you want to find out what journalctl can support, look at the man page. If you have suggestions for improvements, post it in Bugzilla like I did yesterday.
OK, I thought you meant that you knew an option that did it "pixel perfect". Perhaps I misunderstood you.
Bugzilla 1047700
Lars
On 12/31/2013 10:20 PM, Rahul Sundaram wrote:
Your proposal is irrelevant when we are talking about current reality.
No it is by no means not. By implementing my proposal this mail is not lost (as Lennart Poettering stated it in the devel list) by ending up in /var/spool/mail. If included in the installation process of Fedora, perhaps also mentioning that the user should/could set up their mail client to read spool mail, these message will definitely not be lost.
Sadly messages are lost in F20 as distributed now, read question 1 in the mail from Suvayu Ali titled "Manipulating journalctl output" dated 20:57 Jan 1, as an example.
He states that his journal says "Dec 30 04:36:05 <hostname> rsnapshot[8265]: /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsnapshot daily: completed, but with some errors" but where to find that error? In F19 these errors would have been forwarded to the mail spool via /etc/aliases. Now it is lost.
journalctl is not a requirement to read logs. It is just far more easier than grepping through /var/log/messages for the common use cases.
As always that depends on the use case (see at the end). One nice thing with journalctl though, is the possibility to filter the last 10 minutes and similar, that is a bit awkward to do without using awk or similar on /var/log/messages (is it possible to filter out a time slice with journalctl, man page gives no clue?). But in all, a pure ASCII file is so simple that even a novice can handle it. And for grepping, journalctl is too slow.
As I mentioned before desktop environment have graphical utilities to read log files. gnome-system-log for /var/log/messages for example.
Yes, but it is a bit hard to filter using that. (On a side note, on my system the Date/time field is white text on white background which makes it a bit hard to read. (Do you have a solution for that))
GNOME is also getting a systemd specific log viewer as well
https://mail.gnome.org/archives/gnome-announce-list/2013-September/msg00097....
OK. Tested that but could not get any usable output from it at the moment. Perhaps it is a bit too early to test it yet,
Other similar utilities are available for other DE's as well. If it is important, the DE should notify the user proactively and not wait on them to read some log file
On that I agree. And mail from logwatch is an example of that. Notifications another. But when you get notified, you tend to look up your logs, and then it is good if these are readily available, fast, and easy to handle.
Look at the following use case (Fedora 20). The journal starts in July, /var/log content in September. In this use case using simple text files is extremely faster than journalctl. Also note the differences is size.
(I have not done any changes to the configuration of the journal, so this could be the journal of a normal user (well, perhaps not, in this case it is my home web and mail server and it probably produces more journal data than a desktop user does))
[root@gw ~]# time journalctl | grep xyz ... real 25m31.478s user 11m2.966s sys 2m36.218s [root@gw ~]# time grep -r --exclude-dir=journal xyz /var/log ... real 1m6.362s user 0m2.253s sys 0m1.201s ... [root@gw ~]# du -sh --exclude=journal /var/log 620M /var/log [root@gw ~]# du -sh /var/log/journal 3.7G /var/log/journal [root@gw ~]#
Lars
Hi
On Wed, Jan 1, 2014 at 4:50 PM, Lars E. Pettersson wrote:
On 12/31/2013 10:20 PM, Rahul Sundaram wrote:
Your proposal is irrelevant when we are talking about current reality.
No it is by no means not. By implementing my proposal this mail is not lost (as Lennart Poettering stated it in the devel list) by ending up in /var/spool/mail. If included in the installation process of Fedora, perhaps also mentioning that the user should/could set up their mail client to read spool mail, these message will definitely not be lost.
You are again missing the point that when evaluating changes, you can't do so against a hypothesized change that noone is working on. You will have to evaluate it against status quo vs someone willing to do the work involved. You are not volunteering to work on what you are proposing so it wouldn't get done unless someone else buys into your ideas and so far noone has. You haven't considered all the different use cases which makes it very difficult to make any meaningful decisions during installation time. I won't list them but one quick example: Anaconda doesn't require you to create a user at installation time. Instead you can do so during initial-setup time and that user may not be a local user at all. The current design of the installer is to do the minimum needed during installation time and your proposal doesn't fit with that model either.
As always that depends on the use case (see at the end)
I said common use cases. If you have to fallback to using grep, so be it but what journalctl offers is a supset of what traditional syslog daemons offer for a local user. That is undisputed. Unfiled bugs doesn't fundamentally change that although if you find any, you can file them and get the transition to be smoother.
Rahul
On Wed, Jan 01, 2014 at 10:50:39PM +0100, Lars E. Pettersson wrote:
(I have not done any changes to the configuration of the journal, so this could be the journal of a normal user (well, perhaps not, in this case it is my home web and mail server and it probably produces more journal data than a desktop user does))
[root@gw ~]# time journalctl | grep xyz ... real 25m31.478s user 11m2.966s sys 2m36.218s [root@gw ~]# time grep -r --exclude-dir=journal xyz /var/log ... real 1m6.362s user 0m2.253s sys 0m1.201s ... [root@gw ~]# du -sh --exclude=journal /var/log 620M /var/log [root@gw ~]# du -sh /var/log/journal 3.7G /var/log/journal [root@gw ~]#
I had a similarly huge journal (~1.4G). I had to restrict the size in journald.conf. See:
http://thread.gmane.org/gmane.linux.redhat.fedora.general/440246
Cheers,
On 01/01/2014 11:30 PM, Rahul Sundaram wrote:
You are again missing the point that when evaluating changes, you can't do so against a hypothesized change that noone is working on. You will have to evaluate it against status quo vs someone willing to do the work involved. You are not volunteering to work on what you are proposing so it wouldn't get done unless someone else buys into your ideas and so far noone has.
I think you are missing the point. As I do not have the knowledge about anaconda nor other install related programs to do the change myself (which I would, if I was part of that group and had knowledge of Anaconda and related programs) my proposal could be regarded as a RFE to improve the handling of mail created by different programs and daemons.
Some regard mail sent to /var/spool/mail/root as lost, my proposal make these mails visible to the (chosen) user. This is a good thing. And, as it is now, in a new install of F20, these mail will be totally lost, they will not even end up in /var/spool/root. Which is a bad thing.
This by no means mean that I am not volunteering, it simply states that I do not have the knowledge to do these changes myself, nor am I part of the group working with those programs.
Is not one of the reasons for the these mailing lists to encourage people to discuss things like this (changes to improve Fedora)?
You haven't considered all the different use cases which makes it very difficult to make any meaningful decisions during installation time.
How could adding a user to /etc/aliases create any problems? It just tells the system which user should get the mail now sent to root.
The proposed question could (should) be asked when the system is restarted for the first time, and the first user is created. No implications come to mind.
In a system without users the mail ends up in root mail as now. No implications come to mind.
What use cases do I miss? And in what way would these "makes it very difficult to make any meaningful decisions during installation time". Could you give me any examples.
I won't list them but one quick example: Anaconda doesn't require you to create a user at installation time. Instead you can do so during initial-setup time and that user may not be a local user at all.
user@remote.host added to /etc/aliases is also valid. Not adding anything to /etc/aliases is also valid (mail ends up in /var/spool/mail/root as before). Again, no implications come to mind.
The current design of the installer is to do the minimum needed during installation time and your proposal doesn't fit with that model either.
I have clarified the proposal above. The question about /etc/aliases is supposed to be asked when you create the first user of the system. If you chose not to use /etc/aliases, the mail ends up in root mail as before. It fits the current model without problems.
As always that depends on the use case (see at the end)
I said common use cases. If you have to fallback to using grep, so be it but what journalctl offers is a supset of what traditional syslog daemons offer for a local user. That is undisputed.
A (very) common use case is that you want to find something in the log. The first thing you do then is 'grep /var/log/applicable_log_file'. Yes journalctl has options for some things that you use grep for when looking at the /var/log files, but for many use cases you still need to use grep (and as seen in my earlier post, it can take extremely long time grepping output from journalctl when the journal is big).
If you know a better way to search for a random text segment in the logs (using journalctl) than using grep, please let me know.
Unfiled bugs doesn't fundamentally change that although if you find any, you can file them and get the transition to be smoother.
Do you regard the sluggish journal I have as a bug? I will gladly file a bug if you think so.
Lars
HI
On Wed, Jan 1, 2014 at 6:28 PM, Lars E. Pettersson wrote:
my proposal could be regarded as a RFE to improve the handling of mail created by different programs and daemons.
No. Not unless it is actually filed in bugzilla with the details. Filing a RFE requires no prior knowledge other than how to file it which you already have.
How could adding a user to /etc/aliases create any problems? It just
tells the system > which user should get the mail now sent to root.
When no users are created by the installer, there is nothing to add to /etc/aliases and as I noted before, user creation is an optional step within the installer. I don't see anything in your proposal that addresses this.
Do you regard the sluggish journal I have as a bug? I will gladly file a
bug if you think so.
You don't need my approval and what I think is irrelevant since I am not involved in journald development but for the record, all performance issues are bugs from my perspective and I would assume journald developers would agree with that
Rahul
On 01/02/2014 01:05 AM, Rahul Sundaram wrote:
my proposal could be regarded as a RFE to improve the handling of mail created by different programs and daemons.No. Not unless it is actually filed in bugzilla with the details. Filing a RFE requires no prior knowledge other than how to file it which you already have.
So what do we have these mailing list for if we are not supposed to discuss ways to better Fedora? Rahul, I simply do not understand you on this issue.
How could adding a user to /etc/aliases create any problems? It just
tells the system > which user should get the mail now sent to root.
When no users are created by the installer, there is nothing to add to /etc/aliases and as I noted before, user creation is an optional step within the installer. I don't see anything in your proposal that addresses this.
As I mentioned before, /etc/aliases will in that case be intact and mail will be sent to root, just as it has been done for years.
Lars
On 01/02/2014 12:28 AM, Lars E. Pettersson wrote:
On 01/01/2014 11:30 PM, Rahul Sundaram wrote:
...
Unfiled bugs doesn't fundamentally change that although if you find any, you can file them and get the transition to be smoother.
Do you regard the sluggish journal I have as a bug? I will gladly file a bug if you think so.
1047719
Lars
On 01/02/2014 01:12 AM, Lars E. Pettersson wrote:
On 01/02/2014 01:05 AM, Rahul Sundaram wrote:
...
When no users are created by the installer, there is nothing to add to /etc/aliases and as I noted before, user creation is an optional step within the installer. I don't see anything in your proposal that addresses this.
As I mentioned before, /etc/aliases will in that case be intact and mail will be sent to root, just as it has been done for years.
Let me rephrase that.
* The question should be in that part were you create the first user on the system (and after the user creating step, disregarding if you have added a user or not) * You can chose - keep /etc/aliases as is (this is how it has been for years) - add the newly created user (if you added one) - add a remote user or users (user@somewhere.else) - or add a combination of local user and remote user(s)
If you do an install where this question (add a new user) does not appear, /etc/aliases will be intact and mail will be sent to root, just as it has been done for years. If you do an even more esoteric install, you probably know how to change /etc/aliases yourself, and no action will be taken.
Hope this made it a bit more clearer.
Lars
Hi
On Wed, Jan 1, 2014 at 7:48 PM, Lars E. Pettersson lars@homer.se wrote:
Let me rephrase that.
- The question should be in that part were you create the first user on
the system (and after the user creating step, disregarding if you have added a user or not)
- You can chose
- keep /etc/aliases as is (this is how it has been for years)
- add the newly created user (if you added one)
- add a remote user or users (user@somewhere.else)
- or add a combination of local user and remote user(s)
I don't see the installer developers will agree to this proposal. If you want this amount of control, you are better off using kickstart IMO but feel free to file it if you want to.
Rahul
Hi
On Wed, Jan 1, 2014 at 7:12 PM, Lars E. Pettersson lars@homer.se wrote:
So what do we have these mailing list for if we are not supposed to discuss ways to better Fedora? Rahul, I simply do not understand you on this issue.
This list is for community support for end users.
As I mentioned before, /etc/aliases will in that case be intact and mail
will be sent to >>root, just as it has been done for years.
So in the end you will be adding a complex UI for a optional edge use case. None of this will become part of the default workflow.
Rahul
On 01/02/2014 01:51 AM, Rahul Sundaram wrote:
I don't see the installer developers will agree to this proposal. If you want this amount of control, you are better off using kickstart IMO but feel free to file it if you want to.
The proposal is intended to help the non technical users of Fedora, and I do not see them using kickstart, so that is not a solution.
Lars
On 01/01/2014 04:12 PM, Lars E. Pettersson wrote:
On 01/02/2014 01:05 AM, Rahul Sundaram wrote:
my proposal could be regarded as a RFE to improve the handling of mail created by different programs and daemons.No. Not unless it is actually filed in bugzilla with the details. Filing a RFE requires no prior knowledge other than how to file it which you already have.
So what do we have these mailing list for if we are not supposed to discuss ways to better Fedora? Rahul, I simply do not understand you on this issue.
ICBW, but I think he means that while we can work out exactly what enhancement is needed and what's just re-inventing the wheel, nothing is going to get done unless somebody files the appropriate RFE.
On 01/02/2014 02:01 AM, Joe Zeff wrote:
ICBW, but I think he means that while we can work out exactly what enhancement is needed and what's just re-inventing the wheel, nothing is going to get done unless somebody files the appropriate RFE.
Yes, and at the moment we are in the work out phase. Next step is of course a RFE.
Lars
HI
On Wed, Jan 1, 2014 at 8:01 PM, Lars E. Pettersson wrote:
The proposal is intended to help the non technical users of Fedora, and I do not see them using kickstart, so that is not a solution.
Yes but non technical users wouldn't care to navigate the UI you are proposing either. The entire proposal only satisfies a very small small niche for users receiving root mail and want to control exactly how they get it during installation itself.
Rahul
On Wed, Jan 01, 2014 at 10:50:39PM +0100, Lars E. Pettersson wrote:
He states that his journal says "Dec 30 04:36:05 <hostname> rsnapshot[8265]: /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsnapshot daily: completed, but with some errors" but where to find that error? In F19 these errors would have been forwarded to the mail spool via /etc/aliases. Now it is lost.
rsnapshot should be patched to log those. In the meantime, though, the package could have a dpenedency on an MTA.
On 01/02/2014 02:00 AM, Rahul Sundaram wrote:
As I mentioned before, /etc/aliases will in that case be intact and
mail will be sent to >>root, just as it has been done for years.
So in the end you will be adding a complex UI for a optional edge use case.
"edge use case"? I have to strongly disagree. We have mail from different daemons etc that ends up in mail to root. The normal non technical user does not see this mail, and may even by totally unaware of it. This mail should be sent to the non technical user in an easy way.
One easy way to make the non technical user aware of this, and to set up the system so that he/she receives this mail, is my proposal.
The technical user already knows all this and makes the changes needed manually after installing Fedora. So this proposal is, again, to make the system easier to use for a normal non technical user.
None of this will become part of the default workflow.
Sorry. I do not follow you here. I am not sure what you mean.
Lars
On 01/02/2014 02:17 AM, Rahul Sundaram wrote:
Yes but non technical users wouldn't care to navigate the UI you are proposing either. The entire proposal only satisfies a very small small niche for users receiving root mail and want to control exactly how they get it during installation itself.
Why would they not care? The UI will make them aware of something they probably is not aware of. I can not see that lost emails is a good thing. Better to make the user aware of that that mail exist, and make it easy for them to receive it.
Lars
Hi
On Wed, Jan 1, 2014 at 8:21 PM, Lars E. Pettersson wrote:
"edge use case"? I have to strongly disagree. We have mail from different daemons etc that ends up in mail to root. The normal non technical user does not see this mail, and may even by totally unaware of it. This mail should be sent to the non technical user in an easy way.
Why? Non technical users don't care about daemons. They are not expected to baby sit daemons or diagnose problems with them. What specifically did you expect is important enough in there? Show me an example
None of this will become part of the default workflow.
Sorry. I do not follow you here. I am not sure what you mean.
The default workflow of the installer does not mandate creating a non root user
Rahul
On 01/01/2014 05:31 PM, Rahul Sundaram wrote:
The default workflow of the installer does not mandate creating a non root user
Unless things have changed since the last time I installed Fedora, firstboot is set to run the first time you boot after the installation, and that's where you're prompted to create your first non-root user.
HI
Joe Zeff wrote:
"Unless things have changed since the last time I installed Fedora, firstboot is set to run the first time you boot after the installation, and that's where you're prompted to create your first non-root user"
I don't know when the last time you checked but firstboot is not used in Fedora anymore.
Tom Horsley wrote:
Um... Unless you want to be able to login after the install :-).
You can login just fine without having a local user on the system. c.f "Enterprise Login" support in GNOME.
Rahul
On 01/02/2014 02:31 AM, Rahul Sundaram wrote:
Why? Non technical users don't care about daemons. They are not expected to baby sit daemons or diagnose problems with them. What specifically did you expect is important enough in there? Show me an example
Why? For the same reason we have notifications.
OK, one example:
A user might install yum-cron to update the system. It could be nice to know about errors leading to yum not updating the system.
At the moment I get the following from my yum-cron (due to this yum is not updating):
/etc/cron.hourly/0yum-hourly.cron:
Traceback (most recent call last): [ ... a lot of trace lines removed ...] yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from fedora-chromium-stable: [Errno 256] No more mirrors to try. http://repos.fedorapeople.org/repos/spot/chromium-stable/fedora-20/x86_64/re...: [Errno 14] HTTP Error 404 - Not Found
> None of this will become part of the default workflow. Sorry. I do not follow you here. I am not sure what you mean.The default workflow of the installer does not mandate creating a non root user
Yes. And in my proposal, described earlier, that use case is taken care of (either everything will be as it has been for years, i.e. /etc/aliases is intact and the mail end up in mail to root, or you can chose to send it to a remote user)
Lars
Hi
On Wed, Jan 1, 2014 at 8:51 PM, Lars E. Pettersson wrote:
Why? For the same reason we have notifications.
Notifications aren't the same UI as email. Even a cursory guide on UI would tell you that.
OK, one example:
A user might install yum-cron to update the system
Bad example. Non technical users don't install yum-cron.
Rahul
On 01/01/2014 05:47 PM, Rahul Sundaram wrote:
I don't know when the last time you checked but firstboot is not used in Fedora anymore.
The last time I had to do a clean install was to clean up some major problems in F 16 on my laptop. However, I just checked, and firstboot.19.2-1.fc19.i686 is currently installed on my desktop, running Fedora 19. Unless it was taken out of F 20, I don't understand why the copy on my machine is fc19.
On 01/02/2014 02:55 AM, Rahul Sundaram wrote:
Notifications aren't the same UI as email. Even a cursory guide on UI would tell you that.
We have notifications to notify the user. The mail sent to root is (in most cases) to notify the user. The UI differ, but it is used, in this context, for more or less the same thing, notifying the user.
OK, one example: A user might install yum-cron to update the systemBad example. Non technical users don't install yum-cron.
Why not? The might...
Lars
Hi
On Wed, Jan 1, 2014 at 8:57 PM, Joe Zeff wrote:
The last time I had to do a clean install was to clean up some major problems in F 16 on my laptop. However, I just checked, and firstboot.19.2-1.fc19.i686 is currently installed on my desktop, running Fedora 19. Unless it was taken out of F 20, I don't understand why the copy on my machine is fc19.
Initial setup replaced firstboot in Fedora 19 and user creation is an optional step.
Rahul
HI
On Wed, Jan 1, 2014 at 9:03 PM, Lars E. Pettersson wrote:
We have notifications to notify the user. The mail sent to root is (in most cases) to notify the user. The UI differ, but it is used, in this context, for more or less the same thing, notifying the user.
Sure but context in which they are used are very different. If you really want to know the difference in detail, I recommend you get a good UI book. My suggestion would be "Don't make me think!" by Steve Krug.
Bad example. Non technical users don't install yum-cron.
Why not? The might...
In that case, I wouldn't consider them non technical users. Like I said, your notion of what non technical users seems pretty skewed. Non technical users don't care about automated updates on the command line and certainly don't try to resolve failures in third party repos.
Rahul
On 01/02/2014 03:08 AM, Rahul Sundaram wrote:
Sure but context in which they are used are very different. If you really want to know the difference in detail, I recommend you get a good UI book. My suggestion would be "Don't make me think!" by Steve Krug.
Rahul, I am not talking about the UI, I am talking about the information you get from the two systems, and what that content tells the user. The UI is totally irrelevant in this case.
In that case, I wouldn't consider them non technical users. Like I said, your notion of what non technical users seems pretty skewed. Non technical users don't care about automated updates on the command line and certainly don't try to resolve failures in third party repos.
Even non-technical user do strange things, so I would say that your notion of what non technical users do is pretty skewed.
If they do not care about problems with updates etc, then why do we have notifications? They serve, in this context, the same purpose, informing the user about problems with the system.
Lars
On 01/01/2014 06:03 PM, Rahul Sundaram wrote:
Initial setup replaced firstboot in Fedora 19 and user creation is an optional step.
OK, but there are still two things this doesn't cover. First, I used fedup to go from F17 to F19, meaning that firstboot wasn't needed. Second, if F19 doesn't use firstboot, why is my installed copy listed as being fc19? Why did they put out a new version if it isn't even being used?
HI
On Wed, Jan 1, 2014 at 9:14 PM, Lars E. Pettersson wrote:
Rahul, I am not talking about the UI, I am talking about the information you get from the two systems, and what that content tells the user. The UI is totally irrelevant in this case.
UI always matters especially when we are talking about non technical users. A typical non technical user would click on updates when the DE notifies them and nothing more complicated than that.
Even non-technical user do strange things, so I would say that your
notion of what non > technical users do is pretty skewed.
It is based on real life experiences dealing with them on a regular basis and development of distribution cannot be based on supporting strange choices from users. You cannot expect non technical users to do anything about third party repository failures. Color me unconvinced by your example.
Rahul
On Thu, 02 Jan 2014 03:14:57 +0100 Lars E. Pettersson wrote:
Even non-technical user do strange things, so I would say that your notion of what non technical users do is pretty skewed.
I would say there is no such thing as "typical", "non-technical", "technical", etc. users. They are all fictional constructs imagined by someone looking for an excuse to make some change they want made. It is really easy to justify a change when you can conjure up millions of imaginary users in support of it.
The only actual user I know and understand is me.
That is true for everyone else as well, no matter how much they deny it.
HI
On Wed, Jan 1, 2014 at 9:17 PM, Joe Zeff joe@zeff.us wrote:
OK, but there are still two things this doesn't cover. First, I used fedup to go from F17 to F19, meaning that firstboot wasn't needed.
Everything that is installed is updated by Fedup. Fedup doesn't automatically remove any packages. yum distro-sync and yum list extras can cover that.
Second, if F19 doesn't use firstboot, why is my installed copy listed as
being fc19? Why did they put out a new version if it isn't even being used?
The default UI is provided by initial setup/ GNOME initial setup depending on which desktop environment you use. firstboot had some legacy code that hasn't transitioned over completely to the new model when I checked last but you should be able to safely remove it from your system.
Rahul
Hi
On Wed, Jan 1, 2014 at 9:25 PM, Tom Horsley wrote:
The only actual user I know and understand is me.
That is true for everyone else as well, no matter how much they deny it.
Nah. People do have various ways of finding out what users do and need - customer support tickets, surveys, bug reports, UI studies etc. There are decades of UI research that has conclusive evidence on what type of things users generally prefer. It is not all subjective as you claim although it is not a uncommon myth.
Rahul
On 01/02/2014 03:20 AM, Rahul Sundaram wrote:
UI always matters especially when we are talking about non technical users. A typical non technical user would click on updates when the DE notifies them and nothing more complicated than that.
Again. A notification notifies the user, a mail notifies the user. I.e. two different ways of notifying the user. The UI is totally irrelevant in this case. The relevant part is the text message presented to the user. This text message can come from a notification popping up on the screen, or from a a mail, the UI does not matter at all.
It is based on real life experiences dealing with them on a regular basis and development of distribution cannot be based on supporting strange choices from users.
So you think it is better that these mails, sent to root, is "lost", i.e. never delivered to the user? Why?
You cannot expect non technical users to do anything about third party repository failures. Color me unconvinced by your example.
You missed the point. The point of the example was not fixing third party repository failures. The point was that the user was informed about an error that stopped yum from working.
Lars
On Thu, Jan 02, 2014 at 02:25:01AM +0100, Lars E. Pettersson wrote:
On 01/02/2014 02:17 AM, Rahul Sundaram wrote:
Yes but non technical users wouldn't care to navigate the UI you are proposing either. The entire proposal only satisfies a very small small niche for users receiving root mail and want to control exactly how they get it during installation itself.
Why would they not care? The UI will make them aware of something they probably is not aware of. I can not see that lost emails is a good thing. Better to make the user aware of that that mail exist, and make it easy for them to receive it.
I'm sorry but I do not see the reasoning behind the assumption: non-technical implies "we need to protect them from good practice". What does removing an MTA (IOW system mail) serve? If the argument is saving resources, then one could counter argue a non-technical user is less likely to care about "saving system resources".
More to the point, I find it counter productive to _remove_ important debugging resources/tools irrespective of the technical proficiency of the user of the system. I outlined my issue in this post:
https://lists.fedoraproject.org/pipermail/users/2013-December/444436.html
Anyone care to comment on this?
HI
On Wed, Jan 1, 2014 at 9:31 PM, Lars E. Pettersson wrote:
Again. A notification notifies the user, a mail notifies the user. I.e. two different ways of notifying the user. The UI is totally irrelevant in this case.
We have different perspectives on what consitutes non technical users, whether UI matters or not and your proposed solution seems like a pretty complicated thing to do within an installer and your example is entirely unconvincing to me. Repeating yourself isn't going to convince me. Sorry. I will stop at this point since we are unlikely to agree and it doesn't matter anyway since the change is already done.
Rahul
On Wed, Jan 01, 2014 at 08:19:50PM -0500, Matthew Miller wrote:
On Wed, Jan 01, 2014 at 10:50:39PM +0100, Lars E. Pettersson wrote:
He states that his journal says "Dec 30 04:36:05 <hostname> rsnapshot[8265]: /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsnapshot daily: completed, but with some errors" but where to find that error? In F19 these errors would have been forwarded to the mail spool via /etc/aliases. Now it is lost.
rsnapshot should be patched to log those. In the meantime, though, the package could have a dpenedency on an MTA.
Actually rsnapshot has a separate logfile. What you see there traditionally goes to /var/log/messages (through syslog I think); and the rsnapshot log (in my case /var/log/rsnapshot) looks like this:
[30/Dec/2013:04:30:02] /usr/bin/rsnapshot daily: started [30/Dec/2013:04:30:02] echo 8237 > /var/run/rsnapshot.pid [30/Dec/2013:04:30:02] /bin/rm -rf /backup/daily.6/ [30/Dec/2013:04:30:30] mv /backup/daily.5/ /backup/daily.6/ [30/Dec/2013:04:30:30] mv /backup/daily.4/ /backup/daily.5/ [30/Dec/2013:04:30:30] mv /backup/daily.3/ /backup/daily.4/ [30/Dec/2013:04:30:30] mv /backup/daily.2/ /backup/daily.3/ [30/Dec/2013:04:30:30] mv /backup/daily.1/ /backup/daily.2/ [30/Dec/2013:04:30:30] /bin/cp -al /backup/daily.0 /backup/daily.1 [30/Dec/2013:04:31:35] /usr/bin/rsync -aHFr --delete --numeric-ids --relative --delete-excluded --exclude-from=/etc/rsnapshot-exclude /home/user /backup/daily.0/local/ [30/Dec/2013:04:31:47] /usr/bin/rsync -aHFr --delete --numeric-ids --relative --delete-excluded --exclude-from=/etc/rsnapshot-exclude /etc /backup/daily.0/local/ [30/Dec/2013:04:31:50] /usr/bin/rsync -aHFr --delete --numeric-ids --relative --delete-excluded --exclude-from=/etc/rsnapshot-exclude --rsh=/usr/bin/ssh user@host:/home/user /backup/daily.0/host/ [30/Dec/2013:04:33:58] /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsync returned 255 while processing user@host:/home/user/ [30/Dec/2013:04:33:58] /usr/bin/rsync -aHFr --delete --numeric-ids --relative --delete-excluded --exclude-from=/etc/rsnapshot-exclude --rsh=/usr/bin/ssh user@host:/etc /backup/daily.0/host/ [30/Dec/2013:04:36:05] /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsync returned 255 while processing user@host:/etc/ [30/Dec/2013:04:36:05] touch /backup/daily.0/ [30/Dec/2013:04:36:05] rm -f /var/run/rsnapshot.pid [30/Dec/2013:04:36:05] /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsnapshot daily: completed, but with some errors
As you can see the two lines in /var/log/messages are just the first and last lines of the more detailed version.
Cheers,
On 01/02/2014 03:39 AM, Suvayu Ali wrote:
I'm sorry but I do not see the reasoning behind the assumption: non-technical implies "we need to protect them from good practice".
Perhaps a bad term to use on my part. New Linux user would perhaps be better. The idea was to make it easier for them to discover problems with their system. As the MTA has been removed, they will potentially miss important information.
What does removing an MTA (IOW system mail) serve? If the argument is saving resources, then one could counter argue a non-technical user is less likely to care about "saving system resources".
With current day computers an MTA for local delivery is no problem at all. They have all been locked down for quite a long time (only accepting mail from 127.0.0.1) so they have no big security risk either.
Lennart Poettring mentioned the following reasons (07/22/2013 06:36 PM, "Re: F20 System Wide Change: No Default Sendmail")
"since the current way it is set up by default it just eats up messages silently, with not indication of error and no useful tools installed to actually get the messages out of it again."
I think, based on other writings, that he means that mail is eaten up by being delivered to /var/spool/mail/root where the user can not read it. With no useful tool he means that we have no mail client that can read spool mail.
Spool mail can be read by mutt, Thunderbird, and probably other mail clients. What is needed is an easy way to get the mail to a suitable user. That is where my proposal comes in.
So, in my opinion, removing a local delivery MTA was wrong. It should be added again, and something in the line of my proposal should be added so that root mail is sent to a suitable user.
Lars
On Jan 1, 2014, at 2:47 PM, Lars E. Pettersson lars@homer.se wrote:
On 01/01/2014 10:19 PM, Rahul Sundaram wrote:
If you want to find out what journalctl can support, look at the man page. If you have suggestions for improvements, post it in Bugzilla like I did yesterday.
OK, I thought you meant that you knew an option that did it "pixel perfect". Perhaps I misunderstood you.
Bugzilla 1047700
rsyslog pulls data directly from journal files, so the source data is identical. What's different is how journalctl displays it compared to the message file rsyslog produces from the same journal file. I think this might be more a feature request of rsyslog than systemd, but if you're going to ask two projects to somehow negotiate and coordinate on producing an identical formatting of the journal file, I think it won't go anywhere. If you prefer the formatting of rsyslog then use that. If you prefer the formatting of journalctl use that, it's already available anyway and even has advantages to help you parse it to get what you're looking for.
I think this is the response you're likely to get if you get one at all: https://lists.fedoraproject.org/pipermail/devel/2013-July/185783.html
What improvements? Is it possible to get it "a pixel perfect match" using options?
There are a lot.
The journal is non-optional in systemd, it's available from very early boot unlike syslog so you'll find debugging boot problems actually possible rather than through inference. With some boot options it can produce rather prolific output to console, and if this is a VM you can get all of this information from the 1st nanosecond of boot via virsh console.
journalctl -b to get only the current boot messages, which you can't do with /var/log/messages which dumps every boot into the same file until it get rotated.
Timestamps are UTC and converted by default with the client to local time, and there's other handling possible to make conversions easy, including outputting monotonically. You can also reformat as JSON on the fly, it does not affect the journal file itself.
journalctl can be used to manipulate the logs on any computer. You don't need systemd to use journalctl. And you can merge multiple journals, including remote ones, to show their entries interleaved.
You can use -p to filter by priority, 0 is emergency messages only, 7 is debug level.
It detects corruption of the journal files, and if detected warns, still reads it but won't write to it anymore. Instead it creates a new journal file to write to. Multiple journal files are read from as needed, you don't need to state which file to read from.
Good examples from the megathread on devel@ some months ago. https://lists.fedoraproject.org/pipermail/devel/2013-July/185413.html
https://lists.fedoraproject.org/pipermail/devel/2013-July/185502.html
https://lists.fedoraproject.org/pipermail/devel/2013-July/185782.html
Chris Murphy
On Jan 1, 2014, at 6:17 PM, Rahul Sundaram metherid@gmail.com wrote:
HI
On Wed, Jan 1, 2014 at 8:01 PM, Lars E. Pettersson wrote:
The proposal is intended to help the non technical users of Fedora, and I do not see them using kickstart, so that is not a solution.
Yes but non technical users wouldn't care to navigate the UI you are proposing either. The entire proposal only satisfies a very small small niche for users receiving root mail and want to control exactly how they get it during installation itself.
Why put a feature in the GUI installer to add a user to /etc/aliases for getting system mail messages when there isn't an MTA? Since the MTA will need to be installed, edit /etc/aliases at that time? This seems to add complexity for minimal value.
The installer does indeed already have a massive pile of options that many non-technical users don't care to navigate. It's even so much that technical users who QA the installer don't even have the time to go through all of the permutations to thoroughly test it.
I suggest if you're going to ask the installer team for features that you at least offer to write patches, but I think it's not very likely to be exposed in GUI, to me it sounds like an edge case request.
Chris Murphy
On Jan 1, 2014, at 7:39 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
More to the point, I find it counter productive to _remove_ important debugging resources/tools irrespective of the technical proficiency of the user of the system.
I switched to journalctl when it first appeared as non-persistent logging, by creating /var/log/journal to make it persistent, and disabled rsyslog. I'm not a particularly technical user, I prefer the parsing options in the journal rather than having to look at different files or even different commands.
rsyslog uses the same journal file journalctl does. The only difference is some differences in the formatting. The same exact information is available with both, although you'll find rsyslog drop some things it doesn't care about that will be in journalctl. The other thing is that the journal is available straight way, even if you get dropped to a dracut shell. It's available way sooner than rsyslog was, and the journal is integral to systemctl status messages. So it's simply a better debugging tool.
But if you like messages output better, you're exactly one command from installing it. I don't see what the big deal is.
I outlined my issue in this post:
https://lists.fedoraproject.org/pipermail/users/2013-December/444436.html
Anyone care to comment on this?
I'm a regular user. I don't use rsyslog's /var/log/message, I disable it always for some number of releases now.
Chris Murphy
On Jan 1, 2014, at 8:40 PM, Chris Murphy lists@colorremedies.com wrote:
On Jan 1, 2014, at 6:17 PM, Rahul Sundaram metherid@gmail.com wrote:
HI
On Wed, Jan 1, 2014 at 8:01 PM, Lars E. Pettersson wrote:
The proposal is intended to help the non technical users of Fedora, and I do not see them using kickstart, so that is not a solution.
Yes but non technical users wouldn't care to navigate the UI you are proposing either. The entire proposal only satisfies a very small small niche for users receiving root mail and want to control exactly how they get it during installation itself.
Why put a feature in the GUI installer to add a user to /etc/aliases for getting system mail messages when there isn't an MTA? Since the MTA will need to be installed, edit /etc/aliases at that time? This seems to add complexity for minimal value.
The installer does indeed already have a massive pile of options that many non-technical users don't care to navigate. It's even so much that technical users who QA the installer don't even have the time to go through all of the permutations to thoroughly test it.
I suggest if you're going to ask the installer team for features that you at least offer to write patches, but I think it's not very likely to be exposed in GUI, to me it sounds like an edge case request.
I was saying this to the list at large, it was not explicitly directed to Rahul - that wouldn't make sense considering what he wrote right before my response! Sorry for making it slightly confusing.
Chris Murphy
On Wed, 1 Jan 2014 20:40:35 -0700 Chris Murphy lists@colorremedies.com wrote: ctly how they get it during installation itself.
Why put a feature in the GUI installer to add a user to /etc/aliases for getting system mail messages when there isn't an MTA? Since the MTA will need to be installed, edit /etc/aliases at that time? This seems to add complexity for minimal value.
You don't need an mta to get system mail ;) Then I like experimenting.
___ Regards, Frank www.frankly3d.com
Hi Chris,
On Wed, Jan 01, 2014 at 08:55:46PM -0700, Chris Murphy wrote:
On Jan 1, 2014, at 7:39 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
More to the point, I find it counter productive to _remove_ important debugging resources/tools irrespective of the technical proficiency of the user of the system.
I switched to journalctl when it first appeared as non-persistent logging, by creating /var/log/journal to make it persistent, and disabled rsyslog. I'm not a particularly technical user, I prefer the parsing options in the journal rather than having to look at different files or even different commands.
You misunderstood me. I was questioning the decision to remove an MTA on a default install. The missing "debuging resource/tool" in this case is system mail, not journalctl.
Personally, I do not like journalctl. I understand the motivation behind it, I even see some benefits of an unified logging facility but the way this has been carried out seems a bit unfriendly to me. Using journalctl requires a much more intimate knowledge of the system than the old "view/grep /var/log/ files" method. I also notice performance problems when the journal is big and the documentation is incredibly obscure.
On Thu, Jan 02, 2014 at 04:07:14AM +0100, Lars E. Pettersson wrote:
Spool mail can be read by mutt, Thunderbird, and probably other mail clients. What is needed is an easy way to get the mail to a suitable user. That is where my proposal comes in.
Spool mail is a regular mbox, all email clients I know of can read mbox. In the least, they can read it and convert to it's own format and save.
On 01/02/2014 04:33 AM, Chris Murphy wrote:
rsyslog pulls data directly from journal files, so the source data is identical. What's different is how journalctl displays it compared to the message file rsyslog produces from the same journal file. I think this might be more a feature request of rsyslog than systemd, but if you're going to ask two projects to somehow negotiate and coordinate on producing an identical formatting of the journal file, I think it won't go anywhere. If you prefer the formatting of rsyslog then use that. If you prefer the formatting of journalctl use that, it's already available anyway and even has advantages to help you parse it to get what you're looking for.
If we have something (journal(ctl)) that replaces something else (syslog), it is good thing to be backwards compatible. As seen the differences are minor. Keeping these minor changes is like the saying "standards are good, everyone should have one", in practice this does not work, and the minor changes (may) pose problems to certain scripts. The simple spolution is to make the output the same (which would be easy to do as they are created by the same underlying structure, just as you mention).
I think this is the response you're likely to get if you get one at all: https://lists.fedoraproject.org/pipermail/devel/2013-July/185783.html
Yes, sadly enough...
What improvements? Is it possible to get it "a pixel perfect match" using options?
There are a lot.
I was thinking of Rahuls statement that the output from journalctl and syslog was "pixel perfect", which it is not, and he mentioning options. As I understand it, no options are available to do the outputs "pixel perfect"
Regarding the journal in general, yes, it has many options that make it quite usable, and I do use it from time to time. In my situation, with a journal of about 3.7 GB, it is extremely slow though, which makes the journal hard to use, even "systemctl status <something>" takes time, as it has to go through the journal to output the last lines from the log.
This may all be a bug (I filed bug 1047719 on this).
Anyhow, thanks for the information about options etc. Sadly the man page is somewhat sparse on examples which makes the transition to journalctl a bit hard.
Lars
On 01/02/2014 04:40 AM, Chris Murphy wrote:
Why put a feature in the GUI installer to add a user to /etc/aliases for getting system mail messages when there isn't an MTA? Since the MTA will need to be installed, edit /etc/aliases at that time? This seems to add complexity for minimal value.
My proposal is to keep the MTA, not to loose the messages that we now loose due to not having an MTA (I opposed removing the MTA in the first place). To get these now lost mails to the (main) user the user has to made aware of the mail to root, and instead send it to the applicable user. One way to do this is by making it (setting up /etc/aliases) a part of the installation process, as I described earlier.
The value is great, as the mail now lost is no longer lost, and instead sent to the user of the system.
be exposed in GUI, to me it sounds like an edge case request.
Important mail to/from root is not an "edge case".
Lars
On 01/01/2014 08:47 PM, Rahul Sundaram wrote:
HI
Joe Zeff wrote:
"Unless things have changed since the last time I installed Fedora, firstboot is set to run the first time you boot after the installation, and that's where you're prompted to create your first non-root user"
I don't know when the last time you checked but firstboot is not used in Fedora anymore.
I always do a clean install. Firstboot is still there to do some housekeeping, but the GUI seems to have been moved into the install process. Makes sense. But all the functions that we were use to in the firstboot GUI are still there. So tweaking them to handle mail is a small step. Think about what has to be done if you check that the user you are creating is an administrator. Actually, that is where I think this should go. You want to administrate? Get ready to handle some local mail.
On 01/01/2014 09:39 PM, Suvayu Ali wrote:
On Thu, Jan 02, 2014 at 02:25:01AM +0100, Lars E. Pettersson wrote:
On 01/02/2014 02:17 AM, Rahul Sundaram wrote:
Yes but non technical users wouldn't care to navigate the UI you are proposing either. The entire proposal only satisfies a very small small niche for users receiving root mail and want to control exactly how they get it during installation itself.
Why would they not care? The UI will make them aware of something they probably is not aware of. I can not see that lost emails is a good thing. Better to make the user aware of that that mail exist, and make it easy for them to receive it.
I'm sorry but I do not see the reasoning behind the assumption: non-technical implies "we need to protect them from good practice". What does removing an MTA (IOW system mail) serve? If the argument is saving resources, then one could counter argue a non-technical user is less likely to care about "saving system resources".
Actually, if you look at Fedora now developing on ARM and porting to i386 and x86_64 (well this might be a simplification), "saving system resourses" is very important. Also we are at the point where a single core system behaves erratically (does so on my Asus Eee900); fortunately multicore ARMs are rather common but resources are still an issue.
THe new crop of users are coming from the Android world, not the Windows world and are expecting the OS chiefs to take care of everything.
And to another note, this is why I expect something like cron-yum to be in the base in f21. Users will expect updates to be taken care of for them. At least the download waiting for them to do the install.
On 01/02/2014 04:13 AM, Frank Murphy wrote:
On Wed, 1 Jan 2014 20:40:35 -0700 Chris Murphy lists@colorremedies.com wrote: ctly how they get it during installation itself.
Why put a feature in the GUI installer to add a user to /etc/aliases for getting system mail messages when there isn't an MTA? Since the MTA will need to be installed, edit /etc/aliases at that time? This seems to add complexity for minimal value.
You don't need an mta to get system mail ;) Then I like experimenting.
Which I agree about. We should focus on geting local delivery working and the standard email client reading it.
On Jan 2, 2014, at 3:54 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
You misunderstood me. I was questioning the decision to remove an MTA on a default install. The missing "debuging resource/tool" in this case is system mail, not journalctl.
There is no deficiency in omitting the installation of something that does nothing by default. To gain functionality from sendmail required the user configure it.
Since the user needs to know enough to configure it, for it to do anything useful, there's no meaningful problem with requiring users who were going to have to configure one anyway to now install it.
Chris Murphy
On Thu, 2 Jan 2014 11:30:53 -0700 Chris Murphy wrote:
There is no deficiency in omitting the installation of something that does nothing by default. To gain functionality from sendmail required the user configure it.
Nonsense, both sendmail and postfix make most mail delivery work as expected with no configuration required. At work, for instance, when we install a new system and don't touch anything in sendmail, you can still run mailx on that system to send mail to anyone else on the local LAN and it "just works".
On 01/02/2014 07:30 PM, Chris Murphy wrote:
There is no deficiency in omitting the installation of something that does nothing by default. To gain functionality from sendmail required the user configure it.
It delivers mail, so it certainly does something. It is not an idle process doing nothing.
Since the user needs to know enough to configure it, for it to do anything useful, there's no meaningful problem with requiring users who were going to have to configure one anyway to now install it.
A user only needs to know how to edit /etc/aliases, i.e. add a line 'root: <username>' to it, run newaliases (or something in the line of my proposal earlier), and to setup the mail client to read that mail. Not more esoteric than to setup ordinary mail.
Not having a MTA leads to lost mail, this has to be addressed and solved before the MTA is removed.
Lars
On 01/02/2014 01:30 PM, Chris Murphy wrote:
On Jan 2, 2014, at 3:54 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
You misunderstood me. I was questioning the decision to remove an MTA on a default install. The missing "debuging resource/tool" in this case is system mail, not journalctl.
There is no deficiency in omitting the installation of something that does nothing by default. To gain functionality from sendmail required the user configure it.
Since the user needs to know enough to configure it, for it to do anything useful, there's no meaningful problem with requiring users who were going to have to configure one anyway to now install it.
I dispute this. Out of the box, sendmail could both deliver local and send remote mail from processes like logwatch and cron.
The remote delivery 'only' took changing /etc/aliases.
That is the sort of behaviour, at least with local delivery I would like to see.
On Thu, 2014-01-02 at 13:40 -0500, Tom Horsley wrote:
On Thu, 2 Jan 2014 11:30:53 -0700 Chris Murphy wrote:
There is no deficiency in omitting the installation of something that does nothing by default. To gain functionality from sendmail required the user configure it.
Nonsense, both sendmail and postfix make most mail delivery work as expected with no configuration required. At work, for instance, when we install a new system and don't touch anything in sendmail, you can still run mailx on that system to send mail to anyone else on the local LAN and it "just works".
Yea, for the most part sendmail has "just worked" for me. I had to do some custom stuff recently but that's because I changed my network around.
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson lars@homer.se wrote:
On 01/02/2014 04:40 AM, Chris Murphy wrote:
be exposed in GUI, to me it sounds like an edge case request.
Important mail to/from root is not an "edge case".
So important that by default root isn't informed of these messages?
With sendmail I was not informed of any such messages when logging in as root. Without sendmail, there's been no change in behavior at all. So what am I missing, exactly? How am I missing it?
Chris Murphy
On 01/02/2014 07:52 PM, Chris Murphy wrote:
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson lars@homer.se wrote:
...
Important mail to/from root is not an "edge case".
So important that by default root isn't informed of these messages?
Huh?
With sendmail I was not informed of any such messages when logging in as root. Without sendmail, there's been no change in behavior at all. So what am I missing, exactly? How am I missing it?
Log in as root, write mail, press enter, there you go.
How you miss it?
With an MTA mail is delivered to root until you change /etc/aliases. To read roots mail you have to login as root and run a mail client. With a change of the aliases file you can chose to deliver root mail to a user, on the current system, another system, or a combination of these. The mail is read using a mail client.
Without an MTA these mails are totally lost, they do not appear in /var/spool/mail/root, nor any other user, they are never deliver, and thereby lost.
Lars
On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 07:30 PM, Chris Murphy wrote:
There is no deficiency in omitting the installation of something that does nothing by default. To gain functionality from sendmail required the user configure it.
It delivers mail, so it certainly does something. It is not an idle process doing nothing.
I've never seen it do anything since I started using Fedora, except cause longer boot times.
Since the user needs to know enough to configure it, for it to do anything useful, there's no meaningful problem with requiring users who were going to have to configure one anyway to now install it.
A user only needs to know how to edit /etc/aliases, i.e. add a line 'root: <username>' to it, run newaliases (or something in the line of my proposal earlier), and to setup the mail client to read that mail. Not more esoteric than to setup ordinary mail.
It's a minority use case. This has already been discussed ad nauseum back in July on the devel list. Is there something there that was not brought up that clearly makes the decision wrong? If so, it needs to be brought up on devel. I don't see the point in having the exact same arguments all over again.
Not having a MTA leads to lost mail, this has to be addressed and solved before the MTA is removed.
Presumably if it's that important, an error is generated due to the lack of an MTA? If not, then it's not important. If ithere is an error, then at least it's being logged somewhere where it might be seen, rather than the sendmail by default case which is the silent accumulation of emails in /var/spool/mail/root that most users have *no idea* is happening, and even if you managed to inform a majority of users this is happening, the majority (like me) still have no idea how to retrieve, redirect, or stop them from being unnecessarily generated.
Chris Murphy
On 01/02/2014 08:09 PM, Chris Murphy wrote:
On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson" lars@homer.se wrote:
It delivers mail, so it certainly does something. It is not an idle process doing nothing.
I've never seen it do anything since I started using Fedora, except cause longer boot times.
Strange, what kind of install do you have?
Long boot time would be it waiting for network, otherwise it starts quickly.
9.093s postfix.service (my mailserver) 64ms sendmail.service (my desktop)
A user only needs to know how to edit /etc/aliases, i.e. add a line 'root: <username>' to it, run newaliases (or something in the line of my proposal earlier), and to setup the mail client to read that mail. Not more esoteric than to setup ordinary mail.
It's a minority use case.
How can it be a minority use case?
Not having a MTA leads to lost mail, this has to be addressed and solved before the MTA is removed.
Presumably if it's that important, an error is generated due to the lack of an MTA? If not, then it's not important. If ithere is an error, then at least it's being logged somewhere where it might be seen,
Someone sent a question about how to read mail to root without the MTA delivering it. It was logged that cron had a problem, but the output from cron, usually sent as a mail, was lost.
Exactly this question I asked Lennart Poettering on the devel list, but sadly got no answer.
How do we solve this problem without an MTA? (cron output lost)
rather than the sendmail by default case which is the silent
accumulation of emails in /var/spool/mail/root that most users have *no idea* is happening, and even if you managed to inform a majority of users this is happening,
This was the reason behind my proposal, to make it more obvious to the user that (possible) important mails from the system show up in spool mail.
the majority (like me) still have no idea how to retrieve, redirect, or stop them from being unnecessarily generated.
In what way unnecessary? If cron has problems, do you not want to know the output of that cron job, to be able to solve the problem?
Lars
On Jan 2, 2014, at 12:09 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 07:52 PM, Chris Murphy wrote:
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson lars@homer.se wrote:
...
Important mail to/from root is not an "edge case".
So important that by default root isn't informed of these messages?
Huh?
Right. I wasn't informed they exist, therefore they are not important messages.
With sendmail I was not informed of any such messages when logging in as root. Without sendmail, there's been no change in behavior at all. So what am I missing, exactly? How am I missing it?
Log in as root, write mail, press enter, there you go.
The *overwhelming* use case of Fedora, users login at gdm into gnome-shell. They don't login as root. How are these users informed of silently accumulating emails? Oh, they aren't. Guess they aren't important messages.
And even in the case where I do login as root, why would I type mail? How would that ever occur to me?
How you miss it?
Miss what? Typing a word I have no reason to type?
With an MTA mail is delivered to root until you change /etc/aliases. To read roots mail you have to login as root and run a mail client. With a change of the aliases file you can chose to deliver root mail to a user, on the current system, another system, or a combination of these. The mail is read using a mail client.
Sounds like it's from the pleistocene of computing. It's obsolete for the majority.
But happy days, you can just yum install and get the result you want, it's self-evident for your use case. It's not self-evident how I get rid of useless things that I don't even know exist, so the burden shouldn't be on me. Thanks to FESCO for getting rid of this crusty thing I never used or benefited from in any way shape or form.
Without an MTA these mails are totally lost, they do not appear in /var/spool/mail/root, nor any other user, they are never deliver, and thereby lost.
They were being lost anyway.
When the devel@ mega thread appeared in July, was the first time inyears I went to look for these messages. And I found a pile of utterly useless crap being generated; and without notification, or a good reason for them to be generated in the first place. I'm glad it's gone by default.
Chris Murphy
On Jan 2, 2014 12:26 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:09 PM, Chris Murphy wrote:
On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson" lars@homer.se wrote:
It delivers mail, so it certainly does something. It is not an idle
process doing nothing.
I've never seen it do anything since I started using Fedora, except
cause longer boot times.
Strange, what kind of install do you have?
Long boot time would be it waiting for network, otherwise it starts
quickly.
9.093s postfix.service (my mailserver) 64ms sendmail.service (my desktop)
A user only needs to know how to edit /etc/aliases, i.e. add a line
'root: <username>' to it, run newaliases (or something in the line of my proposal earlier), and to setup the mail client to read that mail. Not more esoteric than to setup ordinary mail.
It's a minority use case.
How can it be a minority use case?
Not having a MTA leads to lost mail, this has to be addressed and
solved before the MTA is removed.
Presumably if it's that important, an error is generated due to the lack
of an MTA? If not, then it's not important. If ithere is an error, then at least it's being logged somewhere where it might be seen,
Someone sent a question about how to read mail to root without the MTA
delivering it. It was logged that cron had a problem, but the output from cron, usually sent as a mail, was lost.
Exactly this question I asked Lennart Poettering on the devel list, but
sadly got no answer.
How do we solve this problem without an MTA? (cron output lost)
rather than the sendmail by default case which is the silent
accumulation of emails in /var/spool/mail/root that most users have *no idea* is happening, and even if you managed to inform a majority of users this is happening,
This was the reason behind my proposal, to make it more obvious to the
user that (possible) important mails from the system show up in spool mail.
the majority (like me) still have no idea how to retrieve, redirect, or
stop them from being unnecessarily generated.
In what way unnecessary? If cron has problems, do you not want to know
the output of that cron job, to be able to solve the problem?
Lars
Before, if you suspected a problem with a crond job, you looked at the user's mail. Now, if you suspect a problem with a cron job, you look at the journal.
Is there something you expect to see that is missing from the journal?
--Pete
On 01/02/2014 08:32 PM, Pete Travis wrote:
Before, if you suspected a problem with a crond job, you looked at the user's mail. Now, if you suspect a problem with a cron job, you look at the journal.
Is there something you expect to see that is missing from the journal?
Yes, the output of cron, that is not a part of the journal output.
Lars
On Jan 2, 2014, at 12:26 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:09 PM, Chris Murphy wrote:
On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson" lars@homer.se wrote:
It delivers mail, so it certainly does something. It is not an idle process doing nothing.
I've never seen it do anything since I started using Fedora, except cause longer boot times.
Strange, what kind of install do you have?
Long boot time would be it waiting for network, otherwise it starts quickly.
9.093s postfix.service (my mailserver) 64ms sendmail.service (my desktop)
In the Fedora 19 era it was ~ 30-60 seconds according to systemd-analyze blame. There was a bug on it in the bugzilla which was blocking the "why we boot so slow" tracker for systemd. I think it's since been fixed, not sure, but now that the glory of no sendmail by default is here with Fedora 20 I don't need to think about that bug anymore.
A user only needs to know how to edit /etc/aliases, i.e. add a line 'root: <username>' to it, run newaliases (or something in the line of my proposal earlier), and to setup the mail client to read that mail. Not more esoteric than to setup ordinary mail.
It's a minority use case.
How can it be a minority use case?
Really? In the whole world of computing you don't see this is a tiny tiny minority use case? It's so small it's not even really an edge case, it fell off the edge years ago. Even if we look at just linux derived systems, no Android system even has root enabled by default, let alone an MTA. It has a modern way of informing me of problems rather than sending me useless spam, without notifications of such.
Not having a MTA leads to lost mail, this has to be addressed and solved before the MTA is removed.
Presumably if it's that important, an error is generated due to the lack of an MTA? If not, then it's not important. If ithere is an error, then at least it's being logged somewhere where it might be seen,
Someone sent a question about how to read mail to root without the MTA delivering it. It was logged that cron had a problem, but the output from cron, usually sent as a mail, was lost.
Exactly this question I asked Lennart Poettering on the devel list, but sadly got no answer.
How do we solve this problem without an MTA? (cron output lost)
yum install sendmail?
So you think a majority of users use cron?
rather than the sendmail by default case which is the silent accumulation of emails in /var/spool/mail/root that most users have *no idea* is happening, and even if you managed to inform a majority of users this is happening,
This was the reason behind my proposal, to make it more obvious to the user that (possible) important mails from the system show up in spool mail.
After quite some time of accumulation of these unnotified emails, I found all of them to be totally useless, and not nearly as entertaining as get rich quick spam.
the majority (like me) still have no idea how to retrieve, redirect, or stop them from being unnecessarily generated.
In what way unnecessary? If cron has problems, do you not want to know the output of that cron job, to be able to solve the problem?
I don't use cron. Probably in five years or so we can have a conversation on it not being installed by default.
Chris Murphy
On Jan 2, 2014, at 12:35 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:32 PM, Pete Travis wrote:
Before, if you suspected a problem with a crond job, you looked at the user's mail. Now, if you suspect a problem with a cron job, you look at the journal.
Is there something you expect to see that is missing from the journal?
Yes, the output of cron, that is not a part of the journal output.
Then cron is broken.
Chris Murphy
On 01/02/2014 08:31 PM, Chris Murphy wrote:
Right. I wasn't informed they exist, therefore they are not important messages.
You not being informed has nothing to do with the importance of the message content.
(My proposal was a direct hit at this, making it clear for the user that potentially important mails are generated on a Linux systems, and giving a way for you to receive them)
The *overwhelming* use case of Fedora, users login at gdm into gnome-shell. They don't login as root. How are these users informed of silently accumulating emails? Oh, they aren't. Guess they aren't important messages.
Again, this was the reason for my earlier proposal to include a setup of /etc/aliases at first bot setup of the system,.
And even in the case where I do login as root, why would I type mail? How would that ever occur to me?
If new mail arrives while you are logged in as root you will be informed. But again, my proposal was to remove this problem by making spool mail visible to the user.
How you miss it?
Miss what? Typing a word I have no reason to type?
Sorry, my bad, I was just repeating your question, the two following paragraphs was the answer to that question.
With an MTA mail is delivered to root until you change /etc/aliases. To read roots mail you have to login as root and run a mail client. With a change of the aliases file you can chose to deliver root mail to a user, on the current system, another system, or a combination of these. The mail is read using a mail client.
Sounds like it's from the pleistocene of computing. It's obsolete for the majority.
In what way is it obsolete?
But happy days, you can just yum install and get the result you want, it's self-evident for your use case. It's not self-evident how I get rid of useless things that I don't even know exist, so the burden shouldn't be on me. Thanks to FESCO for getting rid of this crusty thing I never used or benefited from in any way shape or form.
Well, then you miss potentially important mails from the system.
Without an MTA these mails are totally lost, they do not appear in /var/spool/mail/root, nor any other user, they are never deliver, and thereby lost.
They were being lost anyway.
No.
When the devel@ mega thread appeared in July, was the first time inyears I went to look for these messages. And I found a pile of utterly useless crap being generated; and without notification, or a good reason for them to be generated in the first place. I'm glad it's gone by default.
Please read my proposal again, it addresses the issues you are mentioning.
Lars
On 01/02/2014 01:52 PM, Chris Murphy wrote:
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson lars@homer.se wrote:
On 01/02/2014 04:40 AM, Chris Murphy wrote:
be exposed in GUI, to me it sounds like an edge case request.
Important mail to/from root is not an "edge case".
So important that by default root isn't informed of these messages?
With sendmail I was not informed of any such messages when logging in as root. Without sendmail, there's been no change in behavior at all. So what am I missing, exactly? How am I missing it?
One of my numerous complaints is that you only get the message about mail waiting if you have a terminal open. This should be a system notification.
Now root mail is a separate issue. Again, if you tag that user you set up as an administrator, part of that process SHOULD be adding the appropriate line to /etc/aliases so this admin user gets all the root local mail. Then the GUI should notify of the local mail. Finally, OOTB, Evolution should be set up to read the local mail store. For users like me that erase Evolution, I should be expected to know how to get my local mail.
On 01/02/2014 08:45 PM, Chris Murphy wrote:
Is there something you expect to see that is missing from the journal?
Yes, the output of cron, that is not a part of the journal output.
Then cron is broken.
cron by default sends the output to root
$ head /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
From 'man cron':
"When executing commands, any output is mailed to the owner of the crontab (or to the user specified in the MAILTO environment variable in the crontab, if such exists)."
It also states:
"Any job output can also be sent to syslog by using the -s option."
The problem with that option is that the output from cron can voluminous, and voluminous messages are better suited as mails.
Lars
On 01/02/2014 02:31 PM, Chris Murphy wrote:
On Jan 2, 2014, at 12:09 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 07:52 PM, Chris Murphy wrote:
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson lars@homer.se wrote:
...
Important mail to/from root is not an "edge case".
So important that by default root isn't informed of these messages?
Huh?
Right. I wasn't informed they exist, therefore they are not important messages.
With sendmail I was not informed of any such messages when logging in as root. Without sendmail, there's been no change in behavior at all. So what am I missing, exactly? How am I missing it?
Log in as root, write mail, press enter, there you go.
The *overwhelming* use case of Fedora, users login at gdm into gnome-shell. They don't login as root. How are these users informed of silently accumulating emails? Oh, they aren't. Guess they aren't important messages.
In most cases you are right. But then comes that case where if you had known... That is why root mail should be sent to the admin user via /etc/aliases. Ever since adding the concept of an admin user to get around stopping users for having to be root so much, it could have been easy to do this.
On 01/02/2014 08:45 PM, Chris Murphy wrote:
In the Fedora 19 era it was ~ 30-60 seconds according to systemd-analyze blame. There was a bug on it in the bugzilla which was blocking the "why we boot so slow" tracker for systemd. I think it's since been fixed, not sure, but now that the glory of no sendmail by default is here with Fedora 20 I don't need to think about that bug anymore.
On a Fedora 19 desktop: 27ms sendmail.service
How can 27 or 64 ms to start sendmail be a problem?
Really? In the whole world of computing you don't see this is a tiny tiny minority use case? It's so small it's not even really an edge case, it fell off the edge years ago. Even if we look at just linux derived systems, no Android system even has root enabled by default, let alone an MTA. It has a modern way of informing me of problems rather than sending me useless spam, without notifications of such.
No, loosing important mails is not a minority use case.
How do we solve this problem without an MTA? (cron output lost)
yum install sendmail?
How can we solve the problem without having, or installing, an MTA?
So you think a majority of users use cron?
You do not have cron installed and running?
I don't use cron. Probably in five years or so we can have a conversation on it not being installed by default.
Don't think so.
Lars
On Jan 2, 2014, at 12:49 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:31 PM, Chris Murphy wrote:
Right. I wasn't informed they exist, therefore they are not important messages.
You not being informed has nothing to do with the importance of the message content.
You're right, there's an alternative. The message is important, but the system of informing the user is broken by default. Sort of like being a manager and having an incompetent employee fail to tell me about something important.
(My proposal was a direct hit at this, making it clear for the user that potentially important mails are generated on a Linux systems, and giving a way for you to receive them)
I don't configure a mail client on my Fedora system. So unless it's going to, out of the box start sending mail to my gmail account, these questionably important mails aren't getting to me in any case.
The *overwhelming* use case of Fedora, users login at gdm into gnome-shell. They don't login as root. How are these users informed of silently accumulating emails? Oh, they aren't. Guess they aren't important messages.
Again, this was the reason for my earlier proposal to include a setup of /etc/aliases at first bot setup of the system,.
Seriously, if my computer starts spamming me with these messages, I want to throw a brick at it. This is the WORST most user hostile, irritating as hell, method of informing me of important system issues. If it's that fricking important, put up a banner or alert. Do not send me email. Email is for unimportant low priority bulk crap messages that can be ignored for hours, days, weeks, or even months at a time.
And even in the case where I do login as root, why would I type mail? How would that ever occur to me?
If new mail arrives while you are logged in as root you will be informed. But again, my proposal was to remove this problem by making spool mail visible to the user.
And the spool mail would manifest how? I mean, I'm first refusing the premise that any of these messages are even that important because I looked at them and they were in fact all universally unimportant. I'd rather read advertisements for fishing lures than these emails.
With an MTA mail is delivered to root until you change /etc/aliases. To read roots mail you have to login as root and run a mail client. With a change of the aliases file you can chose to deliver root mail to a user, on the current system, another system, or a combination of these. The mail is read using a mail client.
Sounds like it's from the pleistocene of computing. It's obsolete for the majority.
In what way is it obsolete?
It doesn't notify by default. It doesn't contain any useful information. I do not want to be informed of anything important by email.
Across the board it's simply not efficient or effective. My phones, my other computers, do not use an MTA, do not inform me of problems via email, because there are better ways to do it. And just like was mentioned six months ago, even for servers, especially cloud, real monitoring software exists to do this correctly, e.g. Nagios, Icigna, etc.
But happy days, you can just yum install and get the result you want, it's self-evident for your use case. It's not self-evident how I get rid of useless things that I don't even know exist, so the burden shouldn't be on me. Thanks to FESCO for getting rid of this crusty thing I never used or benefited from in any way shape or form.
Well, then you miss potentially important mails from the system.
Perfectly useless emails from what I've seen on my own system, once discovered and made even more useless because they were so old and outdated. It's a bad system. I didn't work. By default. It utterly failed to meet any goal at all other than to consume resources.
Without an MTA these mails are totally lost, they do not appear in /var/spool/mail/root, nor any other user, they are never deliver, and thereby lost.
They were being lost anyway.
No.
Yes, they were never viewed and the user was never informed of their existence. That method was fundamentally broken, which is why iOS, Android, Windows, OS X do not use such useless methods of informing users of supposedly important things. If it's important, use a banner or alert.
When the devel@ mega thread appeared in July, was the first time inyears I went to look for these messages. And I found a pile of utterly useless crap being generated; and without notification, or a good reason for them to be generated in the first place. I'm glad it's gone by default.
Please read my proposal again, it addresses the issues you are mentioning.
Really? It'll send messages to a gmail account by entering just a few fields of information?
OH but wait, I don't really want more email because I think email in general sucks because of abuse just like this. And on top of it, from my sampling, the messages were useless, so had I been getting them by email, I'd have considered them spam and it would have made me angry that I was receiving them.
I'm glad Fedora caught up with the rest of modern computing and got rid of it by default.
And guess what! You can still install it and get the behavior you want.
Chris Murphy
On Jan 2, 2014, at 12:55 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:45 PM, Chris Murphy wrote:
Is there something you expect to see that is missing from the journal?
Yes, the output of cron, that is not a part of the journal output.
Then cron is broken.
cron by default sends the output to root
$ head /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
From 'man cron':
"When executing commands, any output is mailed to the owner of the crontab (or to the user specified in the MAILTO environment variable in the crontab, if such exists)."
It also states:
"Any job output can also be sent to syslog by using the -s option."
The problem with that option is that the output from cron can voluminous, and voluminous messages are better suited as mails.
It seems that cron could have log levels like most other processes do, with a sensible default, and send that to the journal - while tagging each message sent with a proper priority, so that it can be properly filtered with journalctl -p -u.
The burden is on cron to modernize. Or it's users can stick with its implied workflow and install an MTA manually. I don't see why the majority should have something installed that isn't ever used for any benefit by default, let alone why they should be spammed by their computer by default.
Chris Murphy
On 01/02/2014 09:24 PM, Chris Murphy wrote:
OH but wait, I don't really want more email because I think email in general sucks because of abuse just like this. And on top of it, from my sampling, the messages were useless, so had I been getting them by email, I'd have considered them spam and it would have made me angry that I was receiving them.
Well, then you just skip that question I propose that we ad to the first install/setup program. And you will never ever get any mails and will be happy ever after.
I'm glad Fedora caught up with the rest of modern computing and got rid of it by default.
This has nothing to do with modernity at all.
And guess what! You can still install it and get the behavior you want.
That's not the point. It's about sane defaults so that potential important message are not lost.
Lars
On Jan 2, 2014, at 1:03 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:45 PM, Chris Murphy wrote:
In the Fedora 19 era it was ~ 30-60 seconds according to systemd-analyze blame. There was a bug on it in the bugzilla which was blocking the "why we boot so slow" tracker for systemd. I think it's since been fixed, not sure, but now that the glory of no sendmail by default is here with Fedora 20 I don't need to think about that bug anymore.
On a Fedora 19 desktop: 27ms sendmail.service
How can 27 or 64 ms to start sendmail be a problem?
Like I said, it was 30-60 seconds FOR ME, consistently, except in a VM.
Really? In the whole world of computing you don't see this is a tiny tiny minority use case? It's so small it's not even really an edge case, it fell off the edge years ago. Even if we look at just linux derived systems, no Android system even has root enabled by default, let alone an MTA. It has a modern way of informing me of problems rather than sending me useless spam, without notifications of such.
No, loosing important mails is not a minority use case.
Clearly it is. Most users don't know about this behavior. And it's also not done at all on iOS, Android, Windows, OS X. And it's highly questionable on desktop linux whether it's done or even needed.
How do we solve this problem without an MTA? (cron output lost)
yum install sendmail?
How can we solve the problem without having, or installing, an MTA?
I'm refusing the premise that there is even a problem. 100% of all the messages I found in /var/spool/mail/root were useless. I'd have gotten more use out of a garbage bag (either empty or full).
So you think a majority of users use cron?
You do not have cron installed and running?
No idea. Whatever is the default.
I don't use cron. Probably in five years or so we can have a conversation on it not being installed by default.
Don't think so.
Right. And five years ago the idea of no MTA by default you'd have said the same thing. And it's been six months since this topic was discussed on devel@ and now it's being discussed AGAIN. Except not discussed because it's the exact same conversation, nothing new.
For a while now on OS X, cron is no longer used by default. This is now the job of launch services.
Chris Murphy
On Jan 2, 2014, at 1:32 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 09:24 PM, Chris Murphy wrote:
OH but wait, I don't really want more email because I think email in general sucks because of abuse just like this. And on top of it, from my sampling, the messages were useless, so had I been getting them by email, I'd have considered them spam and it would have made me angry that I was receiving them.
Well, then you just skip that question I propose that we ad to the first install/setup program. And you will never ever get any mails and will be happy ever after.
I'm happy with the way Fedora 20 is behaving now. I see no need to clutter the installer or g-i-s with such questions. If something is really important, the system should put up a banner or alert.
I'm glad Fedora caught up with the rest of modern computing and got rid of it by default.
This has nothing to do with modernity at all.
It does. Email was the only notification option 20 years ago. We have other options today.
And guess what! You can still install it and get the behavior you want.
That's not the point. It's about sane defaults so that potential important message are not lost.
If they're important, they should go in the journal.
Chris Murphy
On Thu, Jan 2, 2014 at 3:37 PM, Chris Murphy wrote:
For a while now on OS X, cron is no longer used by default. This is now the job of launch services.
FYI, systemd has similar capabilities and packages have slowly been using them
http://www.freedesktop.org/software/systemd/man/systemd.timer.html
So it is possible we might not ship cron by default in a future Fedora release. Users of course will be able to install it and use it just like they can use a MTA if they wanted to now.
Rahul
On 01/02/2014 09:45 PM, Chris Murphy wrote:
If they're important, they should go in the journal.
How big files can you send to the journal? The content we are talking about can be everything from oneliners to really long tracebacks.
If it ends up in the journal, how will the user be informed that the content is in the journal and should (perhaps) be acted upon?
Lars
On Jan 2, 2014, at 1:50 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 09:45 PM, Chris Murphy wrote:
If they're important, they should go in the journal.
How big files can you send to the journal? The content we are talking about can be everything from oneliners to really long tracebacks.
By default it is compressed, and set to use 10% of free space. It's configurable, man journald.conf.
If it ends up in the journal, how will the user be informed that the content is in the journal and should (perhaps) be acted upon?
On Fedora 19 and older, when sendmail was the default, I was not ever informed of such things. Therefore the default installation of an MTA is orthogonal to actually successfully informing the user of anything.
If you want to do this correctly, you need a notification API. And I think Gnome at least has something like this now. For things like hard drives that die in a raid5, I see a banner alerting me of this fact, by default, in Gnome Shell. I don't know how that works but I don't think it's smartd that uses this API and informs Gnome. I think Gnome has it's own monitoring of such things. So either the program you want monitored needs to support such an API so it can issue a message for user notification in certain instances. Or maybe you need a configurable journal monitoring service that triggers notifications when certain priority messages appear in the journal.
Chris Murphy
On 01/02/2014 10:08 PM, Chris Murphy wrote:
How big files can you send to the journal? The content we are talking about can be everything from oneliners to really long tracebacks.
By default it is compressed, and set to use 10% of free space. It's configurable, man journald.conf.
I meant how big files, i.e. content, can you send to the journal, not the size of journal itself. The content now sent via mail, that you want to be sent to the journal, can be quite voluminous. So what is the size limit of the content sent to the journal?
If it ends up in the journal, how will the user be informed that the content is in the journal and should (perhaps) be acted upon?
On Fedora 19 and older, when sendmail was the default, I was not ever informed of such things. Therefore the default installation of an MTA is orthogonal to actually successfully informing the user of anything.
Well, to be picky, you was informed, but you did not know were to look for the information you was informed about. This is (was) a lack in the documentation of Fedora. If this had been documented, you could have set up /etc/aliases and gotten informed.
But if this information now instead ends up in the journal, how to inform the user to look there?
If you want to do this correctly, you need a notification API. And I think Gnome at least has something like this now. For things like hard drives that die in a raid5, I see a banner alerting me of this fact, by default, in Gnome Shell. I don't know how that works but I don't think it's smartd that uses this API and informs Gnome. I think Gnome has it's own monitoring of such things. So either the program you want monitored needs to support such an API so it can issue a message for user notification in certain instances. Or maybe you need a configurable journal monitoring service that triggers notifications when certain priority messages appear in the journal.
Yes, that works for the desktop user.
But how do we do this in the use case of a home server? The user may not log into a graphical account that often. So how do we inform the user then?
Lars
On 01/02/2014 01:32 PM, Lars E. Pettersson wrote:
Yes, that works for the desktop user.
Not always. My desktop runs 24/7. Unless a notification stays up until I acknowledge it, it's not going to do me a bit of good if it comes up while I'm sleeping, or otherwise away. One thing I like about both abrt and the SELinux Troubleshooter is that they stay in the notification area until you look at them.
Hi
On Thu, Jan 2, 2014 at 5:03 PM, Joe Zeff wrote:
On 01/02/2014 01:32 PM, Lars E. Pettersson wrote:
Yes, that works for the desktop user.
Not always. My desktop runs 24/7. Unless a notification stays up until I acknowledge it, it's not going to do me a bit of good if it comes up while I'm sleeping, or otherwise away. One thing I like about both abrt and the SELinux Troubleshooter is that they stay in the notification area until you look at them.
Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.
Rahul
On 01/02/2014 11:31 PM, Rahul Sundaram wrote:
Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.
Works OK on a desktop, but how is the home server use case, where the user is not logged in on the computer, supposed to be handled?
Regarding emails. I still have not gotten any response from anyone on how to handle the output from, as an example, cron, logwatch, etc. Hopefully someone could tell how that is supposed top be taken care of now that the MTA is removed. That would involve both adding to the journal, and notify the user, and/or other actions. Shouldn't that have been addressed *before* removing the MTA?
Lars
HI
On Thu, Jan 2, 2014 at 5:42 PM, Lars E. Pettersson wrote:
On 01/02/2014 11:31 PM, Rahul Sundaram wrote:
Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.
Works OK on a desktop, but how is the home server use case, where the user is not logged in on the computer, supposed to be handled?
https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendmail....
"In the interests of paring down services that are generally not used on desktop systems, Fedora 20 removes and replaces some services that many users find unnecessary from the Live Desktop DVD. They will remain available as installable packages for users who might need them."
Rahul
On Jan 2, 2014, at 2:32 PM, Lars E. Pettersson lars@homer.se wrote:
On 01/02/2014 10:08 PM, Chris Murphy wrote:
How big files can you send to the journal? The content we are talking about can be everything from oneliners to really long tracebacks.
By default it is compressed, and set to use 10% of free space. It's configurable, man journald.conf.
I meant how big files, i.e. content, can you send to the journal, not the size of journal itself.
It accepts a stream with a configurable rate limiter.
If it ends up in the journal, how will the user be informed that the content is in the journal and should (perhaps) be acted upon?
On Fedora 19 and older, when sendmail was the default, I was not ever informed of such things. Therefore the default installation of an MTA is orthogonal to actually successfully informing the user of anything.
Well, to be picky, you was informed, but you did not know were to look for the information you was informed about.
No, if I'm informed, by definition, I have the knowledge. What's happened is some informational message was placed in a location that I don't know about, and that is not "being informed" at all.
This is (was) a lack in the documentation of Fedora. If this had been documented, you could have set up /etc/aliases and gotten informed.
Even if I set up /etc/aliases I'm not informed if I don't use the local system to receive emails. And even if I do, it's not going to send those emails to gmail is it?
But if this information now instead ends up in the journal, how to inform the user to look there?
I think if you're a regular user who uses a desktop, anything important needs to feed alerts to the desktop's notification system. If you're a sysadmin, use something like Nagios.
But how do we do this in the use case of a home server? The user may not log into a graphical account that often. So how do we inform the user then?
And for that matter, they may rarely log into that computer, and requiring them to do so to receive "important" messages is a flawed design. So again, something like Nagios. Pretty much anything except emails.
Chris Murphy
On Jan 2, 2014, at 3:42 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 11:31 PM, Rahul Sundaram wrote:
Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.
Works OK on a desktop, but how is the home server use case, where the user is not logged in on the computer, supposed to be handled?
Regarding emails. I still have not gotten any response from anyone on how to handle the output from, as an example, cron, logwatch, etc. Hopefully someone could tell how that is supposed top be taken care of now that the MTA is removed.
If you like the MTA method of being notified, install an MTA. Simple. You have been told this numerous times so don't say you haven't gotten any responses.
That would involve both adding to the journal, and notify the user, and/or other actions. Shouldn't that have been addressed *before* removing the MTA?
No because no one was getting messages with the MTA unless they went looking for them in the first place. And now they merely have one more step which is installing the MTA of their choice, which for a lot of Fedora users wasn't sendmail anyway.
Sendmail was taking up space on the install media, on users computers, for no benefit for the vast majority of users. I don't know how many times this has to be said - look at the number of unique individuals involved in the conversation in this thread? It's less than a dozen. So we're talking thousands of users, and less than 12 give a crap whether an MTA is installed by default or not. It's really close to zero people care about it.
Chris Murphy
On Thu, Jan 2, 2014 at 11:56 PM, Chris Murphy lists@colorremedies.com wrote:
Sendmail was taking up space on the install media, on users computers, for no benefit for the vast majority of users. I don't know how many times this has to be said - look at the number of unique individuals involved in the conversation in this thread? It's less than a dozen. So we're talking thousands of users, and less than 12 give a crap whether an MTA is installed by default or not. It's really close to zero people care about it.
I'd go further than that. It's not that just that people don't care, they wouldn't want to receive any emails from their computers.
If I set up a system for any person I know who isn't a sysadmin to receive local cron mail via thunderbird, they'd have nothing good to say to me or about me for quite a while...
On Thu, Jan 02, 2014 at 01:29:46PM -0700, Chris Murphy wrote:
On Jan 2, 2014, at 12:55 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:45 PM, Chris Murphy wrote:
Is there something you expect to see that is missing from the journal?
Yes, the output of cron, that is not a part of the journal output.
Then cron is broken.
cron by default sends the output to root
$ head /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
From 'man cron':
"When executing commands, any output is mailed to the owner of the crontab (or to the user specified in the MAILTO environment variable in the crontab, if such exists)."
It also states:
"Any job output can also be sent to syslog by using the -s option."
The problem with that option is that the output from cron can voluminous, and voluminous messages are better suited as mails.
It seems that cron could have log levels like most other processes do, with a sensible default, and send that to the journal - while tagging each message sent with a proper priority, so that it can be properly filtered with journalctl -p -u.
Does systemd-journald have capability to notify a user? If not, please do not suggest sending output to the journal as a valid alternative. Other than the contents of the message, system mail is also a form of notification. I have used system mail under many capacities very successfully on a variety of systems to get a variety of notifications very reliably. I see logs/journal as a passive tool, system mail or other forms of notifications are active tools. System mail fills a very unique need, where it can be active and yet be very verbose unlike other notification systems.
Cheers,
On Thu, Jan 02, 2014 at 01:37:28PM -0700, Chris Murphy wrote:
On Jan 2, 2014, at 1:03 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/02/2014 08:45 PM, Chris Murphy wrote:
Really? In the whole world of computing you don't see this is a tiny tiny minority use case? It's so small it's not even really an edge case, it fell off the edge years ago. Even if we look at just linux derived systems, no Android system even has root enabled by default, let alone an MTA. It has a modern way of informing me of problems rather than sending me useless spam, without notifications of such.
No, loosing important mails is not a minority use case.
Clearly it is. Most users don't know about this behavior. And it's also not done at all on iOS, Android, Windows, OS X. And it's highly questionable on desktop linux whether it's done or even needed.
I do not understand your comparison with iOS, OS X, Windows, etc. We are not in a race with any of them. We simply want an operating system that is free (open) and lets us be in control of our computing needs. See the 4 `f's in http://fedoraproject.org/en/about-fedora. None of them mention anything about comparisons with other operating systems. Please do not fall into that hole; if I wanted either of those, I would use them, not Fedora.
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/02/2014 12:55 PM, Lars E. Pettersson wrote:
On 01/02/2014 08:45 PM, Chris Murphy wrote:
Is there something you expect to see that is missing from the journal?
Yes, the output of cron, that is not a part of the journal output.
Then cron is broken.
cron by default sends the output to root
$ head /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
From 'man cron':
"When executing commands, any output is mailed to the owner of the
crontab (or to the user specified in the MAILTO environment variable in the crontab, if such exists)."
It also states:
"Any job output can also be sent to syslog by using the -s option."
The problem with that option is that the output from cron can
voluminous, and voluminous messages are better suited as mails.
Lars
I think there was some misunderstanding here. If you can't find your cronjob output in the journal, *your* cron is broken. Before I get too far in, in my opinion, mails are good for notification, voluminous content should be in the logs that the mail notifies about. The journal is good at logs.
$ su -c 'crontab -l' * * * * * echo "TEST TEST" $ crontab -l * * * * LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e "This isn't the same.\nNew Things are Different.\nSome people like the old thing.";fi
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience Jan 02 20:19:01 ruminant-randomuser-lan CROND[7923]: (pete) CMD (LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e "This isn't the same.\nNew Things are Different.\nSome people like the old thing."; Jan 02 20:19:01 ruminant-randomuser-lan CROND[7922]: (root) CMD (echo "TEST TEST") Jan 02 20:19:01 ruminant-randomuser-lan CROND[7918]: (root) CMDOUT (TEST TEST) Jan 02 20:19:01 ruminant-randomuser-lan CROND[7919]: (pete) CMDOUT (This isn't the same.) Jan 02 20:19:01 ruminant-randomuser-lan CROND[7919]: (pete) CMDOUT (New Things are Different.) Jan 02 20:19:01 ruminant-randomuser-lan CROND[7919]: (pete) CMDOUT (Some people like the old thing.)
But wait! These things could get all mixed up on a busy machine, you say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.) _AUDIT_SESSION=83 _SYSTEMD_CGROUP=/user.slice/user-1000.slice/session-83.scope _SYSTEMD_SESSION=83 _SYSTEMD_UNIT=session-83.scope SYSLOG_PID=8141 _PID=8141 _SOURCE_REALTIME_TIMESTAMP=1388719561402125 Thu 2014-01-02 20:26:01.402133 MST [s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4] PRIORITY=6 _UID=0 _MACHINE_ID=0fb42f5d126e4f4e8b94045b4652c0f2 _HOSTNAME=ruminant-randomuser-lan _CAP_EFFECTIVE=1fffffffff _TRANSPORT=syslog SYSLOG_FACILITY=9 _COMM=crond _EXE=/usr/sbin/crond _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023 _GID=1000 _AUDIT_LOGINUID=1000 _SYSTEMD_OWNER_UID=1000 _SYSTEMD_SLICE=user-1000.slice SYSLOG_IDENTIFIER=CROND _CMDLINE=/usr/sbin/CROND -n _BOOT_ID=0557929cbde247928f945d8b53a6e067
All of that information is available to the user/admin, and to any applications reading the journal. Applications writing to the journal can even provide some extra metadata to aid in filtering - say, the name of a cronjob. Lots of ways to match this message. Let's try _AUDIT_SESSION, that sounds unique-ish:
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b - -- Logs begin at Sun 2013-12-01 03:10:01 MST. -- Jan 02 20:26:01 ruminant-randomuser-lan CROND[8145]: (pete) CMD (LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e "This isn't the same.\nNew Things are Different.\nSome people like ...d thing.";fi) Jan 02 20:26:01 ruminant-randomuser-lan CROND[8141]: (pete) CMDOUT (This isn't the same.) Jan 02 20:26:01 ruminant-randomuser-lan CROND[8141]: (pete) CMDOUT (New Things are Different.) Jan 02 20:26:01 ruminant-randomuser-lan CROND[8141]: (pete) CMDOUT (Some people like the old thing.)
Stop! I don't want all that extra information, you say! `journalctl` should KNOW I'm not interested in the timestamp, or the hostname, or the name and PID of the reporting binary - just give me the message!
journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -o cat (pete) CMD (LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e "<This isn't the same.\nNew Th (pete) CMDOUT (This isn't the same.) (pete) CMDOUT (New Things are Different.) (pete) CMDOUT (Some people like the old thing.)
I'll agree that this isn't as *simple* as banging out a four letter word and reading message, but the journal can provide context, too. If something catastrophic happens, the kind of thing that might lead you frantically searching through root's mail for answers, context can be important. We can grab the cursor from the query above, and broaden the filter to see what else was happening at the time. (timestamp could work to, with --since, I suppose, but it's not quite the same thing.)
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b --show-cursor|tail -1 - -- cursor: s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4
$ journalctl --cursor="s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4" - -- Logs begin at Sun 2013-12-01 03:10:01 MST, end at Thu 2014-01-02 20:36:08 MST. -- Jan 02 20:26:01 ruminant-randomuser-lan CROND[8141]: (pete) CMDOUT (Some people like the old thing.) Jan 02 20:26:43 ruminant-randomuser-lan dhclient[1683]: DHCPREQUEST on em2 to 192.168.1.3 port 67 (xid=0 Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: DHCPREQUEST on em2 to 192.168.1.3 port 67 ( Jan 02 20:26:43 ruminant-randomuser-lan dhclient[1683]: DHCPACK from 192.168.1.3 (xid=0x5ec0b63f) Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: DHCPACK from 192.168.1.3 (xid=0x5ec0b63f) Jan 02 20:26:43 ruminant-randomuser-lan dhclient[1683]: bound to 192.168.1.167 -- renewal in 281 seconds Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> (em2): DHCPv4 state changed renew -> Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> address 192.168.1.167 Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> plen 24 (255.255.255.0) Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> gateway 192.168.1.1 Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> lease time 600 Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> nameserver '192.168.1.3' Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: <info> domain name 'randomuser.lan' Jan 02 20:26:43 ruminant-randomuser-lan NetworkManager[748]: bound to 192.168.1.167 -- renewal in 281 se
You're putting lots of effort into complaining about a hugely useful tool, and apparently little into learning about it. If the complaint is about cronjobs, start here:
http://0pointer.de/blog/projects/journal-submit.html https://git.fedorahosted.org/git/cronie.git
Of course, if you like the old way, you can just install and configure an MTA.
- -- - -- Pete Travis
On Thu, 02 Jan 2014 21:50:51 +0100 "Lars E. Pettersson" lars@homer.se wrote:
If it ends up in the journal, how will the user be informed that the content is in the journal and should (perhaps) be acted upon?
Lars
I hope there is in the cards, something similar to sealert (gui) for journal that would be a boon, that would popup on say: error: dead, (warning?)
___ Regards, Frank www.frankly3d.com
On 01/03/2014 05:07 AM, Pete Travis wrote:
I think there was some misunderstanding here. If you can't find your cronjob output in the journal, *your* cron is broken.
Default installation:
[root@tux ~]# rpm -V cronie [root@tux ~]# rpm -q cronie cronie-1.4.11-4.fc20.x86_64 [root@tux ~]# rpm -V crontabs [root@tux ~]# rpm -q crontabs crontabs-1.11-7.20130830git.fc20.noarch
Before I get too far in, in my opinion, mails are good for notification, voluminous content should be in the logs that the mail notifies about. The journal is good at logs.
Mail has no problem handling voluminous content. It is also very easy to retrieve without knowing quite a lot of strange options to a command that you have to print in a terminal.
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
Where is my output from yum-cron (yum-cron is run hourly and it has a fault at the moment due to spots Chrome repository not yet being up to Fedora 20)?
[root@tux ~]# journalctl SYSLOG_IDENTIFIER=CROND --since=-2h -- Logs begin at Tue 2013-07-02 20:53:56 CEST, end at Fri 2014-01-03 11:40:01 CE Jan 03 09:50:01 tux CROND[3666]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:00:01 tux CROND[3895]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:01:01 tux CROND[4044]: (root) CMD (run-parts /etc/cron.hourly) Jan 03 10:10:01 tux CROND[4358]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:20:01 tux CROND[5345]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:30:01 tux CROND[5521]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:40:01 tux CROND[5790]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:50:01 tux CROND[6135]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:00:01 tux CROND[6388]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:01:01 tux CROND[6541]: (root) CMD (run-parts /etc/cron.hourly) Jan 03 11:10:01 tux CROND[6763]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:20:01 tux CROND[6963]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
But wait! These things could get all mixed up on a busy machine, you say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.)
[lots of lines removed]
SYSLOG_IDENTIFIER=CROND _CMDLINE=/usr/sbin/CROND -n _BOOT_ID=0557929cbde247928f945d8b53a6e067
How is non technical user supposed to understand this? What command sequence did you use to get that output?
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b
How do you find out the _AUDIT_SESSION to use?
Stop! I don't want all that extra information, you say! `journalctl` should KNOW I'm not interested in the timestamp, or the hostname, or the name and PID of the reporting binary - just give me the message!
journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -o cat (pete) CMD (LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e "<This isn't the same.\nNew Th (pete) CMDOUT (This isn't the same.) (pete) CMDOUT (New Things are Different.) (pete) CMDOUT (Some people like the old thing.)
That is several messages. I want only one...
How am I notified that I should look in the journal when things go wrong? (With mail I am notified and also get the "log" lines all at once)
I'll agree that this isn't as *simple* as banging out a four letter word and reading message, but the journal can provide context, too.
I am not arguing whether the journal is good or not, I am arguing whether removing the MTA used to send mail, sent from some applications, is good or bad. As I see it, as long as some applications do send mail, we have to have a MTA. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system. That is my key argument, not that the journal is bad.
The journal is OK, but very hard for a non technical user to use. What is needed is probably a very good graphical frontend that hides all these strange things you show us in your mail. How is a non technical user supposed to understand all this?
You're putting lots of effort into complaining about a hugely useful tool, and apparently little into learning about it. If the complaint is about cronjobs, start here:
I am not complaining about the journal. But please let us know where to find a "journal for dummies" text where we can find out how to become journal experts. The man page is a bit sparse on information.
Of course, if you like the old way, you can just install and configure an MTA.
I have to as long as some applications use that path to send messages to me. The same thing goes for all others installing these applications. Without a MTA these messages are lost in bit space.
Lars
On 01/03/2014 12:01 AM, Rahul Sundaram wrote:
https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendmail....
Rahul, as long as we have applications that do send mail, we need an MTA to take care of these mails, or else they are totally lost. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system.
Lars
On 01/03/2014 12:56 AM, Chris Murphy wrote:
If you like the MTA method of being notified, install an MTA. Simple. You have been told this numerous times so don't say you haven't gotten any responses.
My question was how those, that do not have a MTA installed, is supposed to be notified. Could you perhaps answer that for me?
We do have applications that actually do send messages as mails. Without a MTA installed those messages are lost. How should the user on a non MTA system get notified from those applications?
No because no one was getting messages with the MTA unless they went looking for them in the first place. And now they merely have one more step which is installing the MTA of their choice, which for a lot of Fedora users wasn't sendmail anyway.
"No one"? How do you know that? You not knowing says nothing of all the others.
Sendmail was taking up space on the install media, on users computers, for no benefit for the vast majority of users. I don't know how many times this has to be said - look at the number of unique individuals involved in the conversation in this thread? It's less than a dozen. So we're talking thousands of users, and less than 12 give a crap whether an MTA is installed by default or not. It's really close to zero people care about it.
Sendmail is only a small portion of the install media space, it also starts quickly and should be no problem to handle at all on a normal computer. And as long as we have applications that do send mail we need an MTA to take care of those mails. Fix the mail situation first, *then* remove the MTA, if that is what you want. Now they have removed the MTA without fixing the applications that do need an MTA.
How many that participates in a discussion says nothing about the majority.
Lars
Hi
On Fri, Jan 3, 2014 at 6:10 AM, Lars E. Pettersson wrote:
On 01/03/2014 12:01 AM, Rahul Sundaram wrote:
https://fedoraproject.org/wiki/F20_release_announcement# No_Default_Sendmail.2C_Syslog
Rahul, as long as we have applications that do send mail, we need an MTA to take care of these mails, or else they are totally lost. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system.
You talked about home servers and I pointed out that this change was done only on the desktop live image. Instead of acknowledging that, you are talking about how some people need an MTA which I don't think anyone has denied. If some package that requires an MTA doesn't depend on it, that is a packaging bug.
Rahul
On 01/03/2014 12:48 AM, Chris Murphy wrote:
I meant how big files, i.e. content, can you send to the journal, not the size of journal itself.
It accepts a stream with a configurable rate limiter.
No size limit? How does it show up in the kernel? Say that I have the following data, how is it presented, and how do I retrieve it?
--- start text /etc/cron.hourly/0yum-hourly.cron:
Traceback (most recent call last): File "/usr/sbin/yum-cron", line 721, in <module> main() File "/usr/sbin/yum-cron", line 718, in main base.updatesCheck() File "/usr/sbin/yum-cron", line 606, in updatesCheck self.populateUpdateMetadata() File "/usr/sbin/yum-cron", line 418, in populateUpdateMetadata self.upinfo File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1113, in <lambda> upinfo = property(fget=lambda self: self._getUpdateinfo(), File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1023, in _getUpdateinfo if 'updateinfo' not in repo.repoXML.fileTypes(): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1670, in <lambda> repoXML = property(fget=lambda self: self._getRepoXML(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1666, in _getRepoXML self._loadRepoXML(text=self.ui_id) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1657, in _loadRepoXML return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes()) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1631, in _groupLoadRepoXML if self._commonLoadRepoXML(text): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1456, in _commonLoadRepoXML result = self._getFileRepoXML(local, text) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1234, in _getFileRepoXML size=102400) # setting max size as 100K File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1030, in _getFile raise e yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from fedora-chromium-stable: [Errno 256] No more mirrors to try. http://repos.fedorapeople.org/repos/spot/chromium-stable/fedora-20/x86_64/re...: [Errno 14] HTTP Error 404 - Not Found --- end text
Even if I set up /etc/aliases I'm not informed if I don't use the local system to receive emails. And even if I do, it's not going to send those emails to gmail is it?
OK, the documentation should have let you now how to set up /etc/aliases, *and* also inform you to set up the mail client of your choice to receive that mail.
The following solves the gmail "problem" (/etc/aliases): root: user@gmal.com
Lars
On 01/03/2014 12:35 PM, Rahul Sundaram wrote:
You talked about home servers and I pointed out that this change was done only on the desktop live image. Instead of acknowledging that, you are talking about how some people need an MTA which I don't think anyone has denied. If some package that requires an MTA doesn't depend on it, that is a packaging bug.
Yes, instead of of discussing different levels of users, or different levels of computer systems, I tried to point on the route problem, not getting astray on tangents out of tangents, to steer the discussion onto a more constructive path.
The route problem is what I wrote. That we have applications that actually rely on mail, and that these do need an MTA to communicate with the user.
If this is a packaging problem, it should be addressed, and it would have been good if this had been taken care of before removing the MTA.
Lars
On Fri, Jan 3, 2014 at 6:49 AM, Lars E. Pettersson wrote:
Yes, instead of of discussing different levels of users, or different levels of computer systems, I tried to point on the route problem, not getting astray on tangents out of tangents, to steer the discussion onto a more constructive path.
It was you who brought in the topic of home servers when this change was done only on the desktop live image. It is not clear from your reply whether you were already aware of this fact or not.
The route problem is what I wrote. That we have applications that actually
rely on mail, and that these do need an MTA to communicate with the user.
If this is a packaging problem, it should be addressed, and it would have been good if this had been taken care of before removing the MTA.
If you find out any single package in the desktop live image that requires an MTA to work on the default setup, feel free to file a bug report. Unknown bugs cannot be fixed.
Rahul
On 01/03/2014 12:57 PM, Rahul Sundaram wrote:
It was you who brought in the topic of home servers when this change was done only on the desktop live image. It is not clear from your reply whether you were already aware of this fact or not.
Yes, in response to "Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.".
That (notifications) works on a desktop onto which a user log in, but not on a home server, that you do not log in to that often. So that was more a general comment directed to the use of notifications, pointing toward the fact that mails actually has some merit on some kind of systems.
So that particular comment was perhaps a tad off topic, and was, as I stated above, directed to the desktop notification system, not the "no default MTA" as this thread is (or should) be about. But we should perhaps delay a discussion about that to another thread another day.
If you find out any single package in the desktop live image that requires an MTA to work on the default setup, feel free to file a bug report. Unknown bugs cannot be fixed.
I will make a fresh install in VirtualBox and take a closer look.
Lars
Allegedly, on or about 02 January 2014, Chris Murphy sent:
When the devel@ mega thread appeared in July, was the first time inyears I went to look for these messages. And I found a pile of utterly useless crap being generated; and without notification, or a good reason for them to be generated in the first place. I'm glad it's gone by default.
I can't say that what I see in my logwatch mail is useless...
Notifications that a mailbox is over quota. Notifications that a hard drive / partition is too full. Just to name two of them.
Other things that are useful daily information for an admin, where I get to pick which username is the admin. But, not really good information to pop up on the desktop as a warning to whoever's logged in at the moment. Most users wouldn't know what to do about them, or shouldn't be allowed to attempt to do something about them. Perhaps with the exception that they should clear out their own mailbox, instead of leave everything in the inbox.
On Fri, Jan 03, 2014 at 01:11:39PM +0100, Lars E. Pettersson wrote:
On 01/03/2014 12:57 PM, Rahul Sundaram wrote:
It was you who brought in the topic of home servers when this change was done only on the desktop live image. It is not clear from your reply whether you were already aware of this fact or not.
Yes, in response to "Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.".
That (notifications) works on a desktop onto which a user log in, but not on a home server, that you do not log in to that often. So that was more a general comment directed to the use of notifications, pointing toward the fact that mails actually has some merit on some kind of systems.
My home server doubles as my home desktop too. I use XFCE live images to do clean installs when I need one.
On Jan 3, 2014 4:08 AM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/03/2014 05:07 AM, Pete Travis wrote:
I think there was some misunderstanding here. If you can't find your cronjob output in the journal, *your* cron is broken.
Default installation:
[root@tux ~]# rpm -V cronie [root@tux ~]# rpm -q cronie cronie-1.4.11-4.fc20.x86_64 [root@tux ~]# rpm -V crontabs [root@tux ~]# rpm -q crontabs crontabs-1.11-7.20130830git.fc20.noarch
Before I get too far in, in my opinion, mails are good for notification, voluminous content should be in the logs that the mail notifies about. The journal is good at logs.
Mail has no problem handling voluminous content. It is also very easy to
retrieve without knowing quite a lot of strange options to a command that you have to print in a terminal.
Yes, we know you prefer mail... Mail on the command line is exactly what you describe - it requires knowing esoteric command line options to an awkward terminal application. Two unfamiliar and clunky terminal applications for the purpose would be redundant, so one is gone.
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
Where is my output from yum-cron (yum-cron is run hourly and it has a
fault at the moment due to spots Chrome repository not yet being up to Fedora 20)?
[root@tux ~]# journalctl SYSLOG_IDENTIFIER=CROND --since=-2h -- Logs begin at Tue 2013-07-02 20:53:56 CEST, end at Fri 2014-01-03
11:40:01 CE
Jan 03 09:50:01 tux CROND[3666]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:00:01 tux CROND[3895]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:01:01 tux CROND[4044]: (root) CMD (run-parts /etc/cron.hourly) Jan 03 10:10:01 tux CROND[4358]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:20:01 tux CROND[5345]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:30:01 tux CROND[5521]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:40:01 tux CROND[5790]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 10:50:01 tux CROND[6135]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:00:01 tux CROND[6388]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:01:01 tux CROND[6541]: (root) CMD (run-parts /etc/cron.hourly) Jan 03 11:10:01 tux CROND[6763]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:20:01 tux CROND[6963]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
I see " CMD (run-parts /etc/cron.hourly", that could be where the magic happens. Maybe the output will show up with other filters, or it could be rewritten to use systemd-cat.
But wait! These things could get all mixed up on a busy machine, you say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.)
[lots of lines removed]
SYSLOG_IDENTIFIER=CROND _CMDLINE=/usr/sbin/CROND -n _BOOT_ID=0557929cbde247928f945d8b53a6e067How is non technical user supposed to understand this? What command
sequence did you use to get that output?
A non-technical user would either understand by example - the part you cut out - or, they are a nontechnical user and have no interest in such things .
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b
How do you find out the _AUDIT_SESSION to use?
I didn't guess. There was a straightforward and easy to follow example, but you removed it.
Stop! I don't want all that extra information, you say! `journalctl` should KNOW I'm not interested in the timestamp, or the hostname, or the name and PID of the reporting binary - just give me the message!
journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -o cat (pete) CMD (LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e "<This isn't the same.\nNew Th (pete) CMDOUT (This isn't the same.) (pete) CMDOUT (New Things are Different.) (pete) CMDOUT (Some people like the old thing.)
That is several messages. I want only one...
So what? If your entire complaint is "it isn't a mail" then send the mail and be done.
How am I notified that I should look in the journal when things go wrong?
(With mail I am notified and also get the "log" lines all at once)
How is a nontechnical desktop user notified of new mail? That's rhetorical, don't answer. They aren't .
I'll agree that this isn't as *simple* as banging out a four letter word and reading message, but the journal can provide context, too.
I am not arguing whether the journal is good or not, I am arguing whether
removing the MTA used to send mail, sent from some applications, is good or bad. As I see it, as long as some applications do send mail, we have to have a MTA. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system. That is my key argument, not that the journal is bad.
The journal is OK, but very hard for a non technical user to use. What is
needed is probably a very good graphical frontend that hides all these strange things you show us in your mail. How is a non technical user supposed to understand all this?
OK, then, your argument is late and pointless. Appeal to fesco if you feel strongly about adding sendmail to the default installation, such decisions are not made on the user support list.
You're putting lots of effort into complaining about a hugely useful tool, and apparently little into learning about it. If the complaint is about cronjobs, start here:
I am not complaining about the journal. But please let us know where to
find a "journal for dummies" text where we can find out how to become journal experts. The man page is a bit sparse on information.
Of course, if you like the old way, you can just install and configure an MTA.
I have to as long as some applications use that path to send messages to
me. The same thing goes for all others installing these applications. Without a MTA these messages are lost in bit space.
Lars
More "I like using mail" ranting here. That's fine, use mail. I just wanted to point out how to use the journal, so I'm done here.
--Pete
On Fri, Jan 3, 2014 at 3:05 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Thu, Jan 02, 2014 at 01:37:28PM -0700, Chris Murphy wrote:
Clearly it is. Most users don't know about this behavior. And it's also not done at all on iOS, Android, Windows, OS X. And it's highly questionable on desktop linux whether it's done or even needed.
I do not understand your comparison with iOS, OS X, Windows, etc. We are not in a race with any of them. We simply want an operating system that is free (open) and lets us be in control of our computing needs.
It's a question of looking at what others in this space are doing and evaluating whether their features are appropriate for Fedora and what their users are used and expect. Fedora users (and Linux users in general) most probably use Windows or OS X at work and own an Android or iOS phone, so diverging from them, especially when it comes to some geeky log retrieval mechanism, isn't in the best interest of Fedora.
On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson lars@homer.se wrote:
On 01/03/2014 12:01 AM, Rahul Sundaram wrote:
https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendmail....
Rahul, as long as we have applications that do send mail, we need an MTA to take care of these mails, or else they are totally lost. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system.
The point that Chris has made is that these messages were already lost for most users because they didn't actually exist.
FESCO has to consider the use-case of the majority of Fedora users and it decided that they don't need an MTA by default.
And, as has been said many times already, those who want an MTA, _understand_its_purpose_,_and_use_the_features_that_it_provides_ can install one.
Hi All;
Is there a way to install Fedora 20 and force it to use the old installer, which gave me more control per installing multiple GUI's, etc?
Thanks in advance
Hi Pete,
You seem to be well-versed with journalctl. I hope you don't mind my asking a few questions.
On Thu, Jan 02, 2014 at 09:07:29PM -0700, Pete Travis wrote:
$ su -c 'crontab -l'
- echo "TEST TEST"
$ crontab -l
- LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e
"This isn't the same.\nNew Things are Different.\nSome people like the old thing.";fi
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
How do you know which IDENTIFIER to use? I could guess it should be CROND if I were to look at the output of journalctl in this case; but is there any canonical way to find this out? Or is it just the unit file name?
But wait! These things could get all mixed up on a busy machine, you say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.) _AUDIT_SESSION=83 _SYSTEMD_CGROUP=/user.slice/user-1000.slice/session-83.scope _SYSTEMD_SESSION=83 _SYSTEMD_UNIT=session-83.scope SYSLOG_PID=8141 _PID=8141 _SOURCE_REALTIME_TIMESTAMP=1388719561402125 Thu 2014-01-02 20:26:01.402133 MST [s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4] PRIORITY=6 _UID=0 _MACHINE_ID=0fb42f5d126e4f4e8b94045b4652c0f2 _HOSTNAME=ruminant-randomuser-lan _CAP_EFFECTIVE=1fffffffff _TRANSPORT=syslog SYSLOG_FACILITY=9 _COMM=crond _EXE=/usr/sbin/crond _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023 _GID=1000 _AUDIT_LOGINUID=1000 _SYSTEMD_OWNER_UID=1000 _SYSTEMD_SLICE=user-1000.slice SYSLOG_IDENTIFIER=CROND _CMDLINE=/usr/sbin/CROND -n _BOOT_ID=0557929cbde247928f945d8b53a6e067
How did you get this output; I'm confused.
I'll agree that this isn't as *simple* as banging out a four letter word and reading message, but the journal can provide context, too. If
Could you please point me to some documentation that explains how a user can use this? Some examples beyond SYSTEMD_UNIT=bla would be great. I find it very difficult to use journalctl effectively without knowing any of the internal details you are using in the examples. Is there some discussion on this that I can read for my understanding?
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b --show-cursor|tail -1
- -- cursor:
s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4
It is not clear to me what is meant by cursor here (I read journalctl(1)); moreover I could not find an option to journalctl called `--show-cursor'.
If you don't mind could you share some of your journalctl understanding on another thread I started?
https://lists.fedoraproject.org/pipermail/users/2014-January/444479.html
Thanks a lot for your time.
Cheers,
On Fri, Jan 03, 2014 at 07:27:05PM +0000, Tom H wrote:
On Fri, Jan 3, 2014 at 3:05 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Thu, Jan 02, 2014 at 01:37:28PM -0700, Chris Murphy wrote:
Clearly it is. Most users don't know about this behavior. And it's also not done at all on iOS, Android, Windows, OS X. And it's highly questionable on desktop linux whether it's done or even needed.
I do not understand your comparison with iOS, OS X, Windows, etc. We are not in a race with any of them. We simply want an operating system that is free (open) and lets us be in control of our computing needs.
It's a question of looking at what others in this space are doing and evaluating whether their features are appropriate for Fedora and what their users are used and expect. Fedora users (and Linux users in general) most probably use Windows or OS X at work and own an Android or iOS phone, so diverging from them, especially when it comes to some geeky log retrieval mechanism, isn't in the best interest of Fedora.
Why do they have to be the same? If I wanted what either of those OSes offer, I would be using them, not Fedora. I do not understand why my choices have to be minor variations of each other instead of distinctly different based on needs.
For work, I use Fedora & Scientific Linux. I mostly use Fedora for personal needs; except when I want to play some specific games, I use Windows. And I own an old Android phone.
These are distinct tasks with different needs, where is the need for them to be variations of each other?
On Fri, Jan 03, 2014 at 12:49:46PM -0700, CS DBA wrote:
Is there a way to install Fedora 20 and force it to use the old installer, which gave me more control per installing multiple GUI's, etc?
No -- Fedora installers are tightly linked to the version being installed. I suggest one of two things:
1. For a single system, do a minimal install and build up your system after using yum or yumex.
2. For multiple systems, write a kickstart file, which gives you even more control.
On Jan 3, 2014 1:16 PM, "Suvayu Ali" fatkasuvayu+linux@gmail.com wrote:
Hi Pete,
You seem to be well-versed with journalctl. I hope you don't mind my asking a few questions.
Sure. I rearranged some things when composing, and as I review, I see I did so poorly...
On Thu, Jan 02, 2014 at 09:07:29PM -0700, Pete Travis wrote:
$ su -c 'crontab -l'
- echo "TEST TEST"
$ crontab -l
- LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e
"This isn't the same.\nNew Things are Different.\nSome people like the old thing.";fi
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
How do you know which IDENTIFIER to use? I could guess it should be CROND if I were to look at the output of journalctl in this case; but is there any canonical way to find this out? Or is it just the unit file name?
I picked that by looking at the messages and pairing up the identifier with my messages. It's reasonable to assume this will be consistent for cron jobs, so I didn't demonstrate that part.
The syslog identifier is not the same as the unit file. `journalctl -u crond ` gives only stdout of crond itself, not the jobs. iirc, applications using the journal API can choose the syslog identifier for their messages, and one is chosen for them if not. I don't know the details behind that choice, but I would suspect it comes from the calling binary or service somehow.
But wait! These things could get all mixed up on a busy machine, you say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.) _AUDIT_SESSION=83 _SYSTEMD_CGROUP=/user.slice/user-1000.slice/session-83.scope _SYSTEMD_SESSION=83 _SYSTEMD_UNIT=session-83.scope SYSLOG_PID=8141 _PID=8141 _SOURCE_REALTIME_TIMESTAMP=1388719561402125 Thu 2014-01-02 20:26:01.402133 MST
[s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4]
PRIORITY=6 _UID=0 _MACHINE_ID=0fb42f5d126e4f4e8b94045b4652c0f2 _HOSTNAME=ruminant-randomuser-lan _CAP_EFFECTIVE=1fffffffff _TRANSPORT=syslog SYSLOG_FACILITY=9 _COMM=crond _EXE=/usr/sbin/crond _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023 _GID=1000 _AUDIT_LOGINUID=1000 _SYSTEMD_OWNER_UID=1000 _SYSTEMD_SLICE=user-1000.slice SYSLOG_IDENTIFIER=CROND _CMDLINE=/usr/sbin/CROND -n _BOOT_ID=0557929cbde247928f945d8b53a6e067How did you get this output; I'm confused.
`journalctl -o verbose' gives the extra metadata. There are other output formats, ie json, but this seemed most useful here.
`journalctl --show-cursor` gives the cursor at the end of the query.
I'll agree that this isn't as *simple* as banging out a four letter word and reading message, but the journal can provide context, too. If
Could you please point me to some documentation that explains how a user can use this? Some examples beyond SYSTEMD_UNIT=bla would be great. I find it very difficult to use journalctl effectively without knowing any of the internal details you are using in the examples. Is there some discussion on this that I can read for my understanding?
I pulled all of that from `man journalctl` , /usr/share/doc/ , examining the metadata provided by "-o verbose", and generous mashing of the tab key. There is a section in the System Administrators Guide on the journal, which I will probably update this weekend since the usage is newly fresh in my mind. It won't be published for f20 immediately, but I can push a draft if anyone is interested in reviewing. (Hint, readers, speak up, or I won't do the extra work)
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b --show-cursor|tail -1
- -- cursor:
s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4
It is not clear to me what is meant by cursor here (I read journalctl(1)); moreover I could not find an option to journalctl called `--show-cursor'.
Think of the cursor as a unique key for the entry in a journal - but as I understand it, it references that point in the journal, not the specific entry. I have not read the code, so it is easier to demonstrate usage than explain the internals. In practice, a script or application tracking the journal can stop and resume at a specific point with more granularity and reliability than a timestamp, because timestamps may not be unique.
If you don't mind could you share some of your journalctl understanding on another thread I started?
https://lists.fedoraproject.org/pipermail/users/2014-January/444479.html
Thanks a lot for your time.
Cheers,
-- Suvayu
No problem. I'll dig up that thread and see if I can help.
--Pete
On 01/03/2014 06:31 PM, Pete Travis wrote:
On Jan 3, 2014 4:08 AM, "Lars E. Pettersson" <lars@homer.se mailto:lars@homer.se> wrote:
On 01/03/2014 05:07 AM, Pete Travis wrote:
I think there was some misunderstanding here. If you can't find your cronjob output in the journal, *your* cron is broken.
Default installation:
[root@tux ~]# rpm -V cronie [root@tux ~]# rpm -q cronie cronie-1.4.11-4.fc20.x86_64 [root@tux ~]# rpm -V crontabs [root@tux ~]# rpm -q crontabs crontabs-1.11-7.20130830git.fc20.noarch
Pete, you did not answer this part. As seen cron is untouched, i.e. not broken. I can not find any output from cron in the journal (you only see the trigger part in the journal). So please, how do I read the output from cron with journalctl?
Mail has no problem handling voluminous content. It is also very easy
to retrieve without knowing quite a lot of strange options to a command that you have to print in a terminal.
Yes, we know you prefer mail... Mail on the command line is exactly what you describe - it requires knowing esoteric command line options to an awkward terminal application. Two unfamiliar and clunky terminal applications for the purpose would be redundant, so one is gone.
What I prefer is not the discussion, the discussion is how to make sure that information is not lost for a user of Fedora. In Fedora we have some applications that do send mail. These mails will be lost on a system without an MTA. That is not a good thing, and that is what the discussion is about.
Mail on command line was an example of the most simplistic way to read mail. Most of us use full blow mail clients, I use Thunderbird, to read mail. Thunderbird can read spool mail without a problem. And spool mail can also easily be forwarded to gmail etc, if so wanted (as long as we have a MTA). Mail is easy to understand and grasp for most users.
The journalctl commands are way more esoteric than the mail command, and beyond what most normal users can/want to comprehend. So what the journal really need is a graphical frontend to help the non technically oriented users. But that is probably better discussed in another thread.
Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
I see " CMD (run-parts /etc/cron.hourly", that could be where the magic happens. Maybe the output will show up with other filters, or it could be rewritten to use systemd-cat.
What you see here is when cron is triggered. But I con not find any information on how to read the output that these triggered cron jobs (may) produce. How are those retrieved using journalctl? I have no clue, do you? (Or any other?)
How is non technical user supposed to understand this? What command
sequence did you use to get that output?
A non-technical user would either understand by example - the part you cut out - or, they are a nontechnical user and have no interest in such things .
As I said before, a non technically oriented user should not be (forced) to use these esoteric commands to find information on how the system behaves. It is good and dandy for us that like to understand the system, but this has to be made way more easy to use, as I mentioned before.
Compare receiving a mail of the output from a cron job, with the journalctl commands you have shown. What do you think a non technically oriented user will find most easy to understand?
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b
How do you find out the _AUDIT_SESSION to use?
I didn't guess. There was a straightforward and easy to follow example, but you removed it.
Yes, but that part was just put into your mail (I removed the middle part), but were did it come from? How did you produce that output? Or, to have a perhaps more useful question, how do I find out what _AUDIT_SESSION is relevant for a certain log line?
How am I notified that I should look in the journal when things go
wrong? (With mail I am notified and also get the "log" lines all at once)
How is a nontechnical desktop user notified of new mail? That's rhetorical, don't answer. They aren't .
It shows up in their inbox.
How is non technical user notified to look in the journal?
OK, then, your argument is late and pointless. Appeal to fesco if you feel strongly about adding sendmail to the default installation, such decisions are not made on the user support list.
That does not stop us from discussing it. We now have a situation were certain applications do produce mail, and without an MTA those mails will be lost. That is not a good situation. This should have been taken care of *before* removing the MTA, so that information from the system is not lost. Why FESCO did not make sure of this is beyond me.
I have to as long as some applications use that path to send messages
to me. The same thing goes for all others installing these applications. Without a MTA these messages are lost in bit space.
Lars
More "I like using mail" ranting here. That's fine, use mail. I just wanted to point out how to use the journal, so I'm done here.
It is not about liking mail (or not), please read the last paragraph above (above Lars), that paragraph explains the situation.
I also asked you if there exist a "journal for dummies" text where we can find out how to become journal experts. The man page is a bit sparse on information. Do such a text exist, if so were?
Lars
On Jan 3, 2014 4:12 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/03/2014 06:31 PM, Pete Travis wrote:
On Jan 3, 2014 4:08 AM, "Lars E. Pettersson" <lars@homer.se mailto:lars@homer.se> wrote:
On 01/03/2014 05:07 AM, Pete Travis wrote:
I think there was some misunderstanding here. If you can't find your cronjob output in the journal, *your* cron is broken.
Default installation:
[root@tux ~]# rpm -V cronie [root@tux ~]# rpm -q cronie cronie-1.4.11-4.fc20.x86_64 [root@tux ~]# rpm -V crontabs [root@tux ~]# rpm -q crontabs crontabs-1.11-7.20130830git.fc20.noarch
Pete, you did not answer this part. As seen cron is untouched, i.e. not
broken. I can not find any output from cron in the journal (you only see the trigger part in the journal). So please, how do I read the output from cron with journalctl?
Mail has no problem handling voluminous content. It is also very easy
to retrieve without knowing quite a lot of strange options to a command that you have to print in a terminal.
Yes, we know you prefer mail... Mail on the command line is exactly what you describe - it requires knowing esoteric command line options to an awkward terminal application. Two unfamiliar and clunky terminal applications for the purpose would be redundant, so one is gone.
What I prefer is not the discussion, the discussion is how to make sure
that information is not lost for a user of Fedora. In Fedora we have some applications that do send mail. These mails will be lost on a system without an MTA. That is not a good thing, and that is what the discussion is about.
Mail on command line was an example of the most simplistic way to read
mail. Most of us use full blow mail clients, I use Thunderbird, to read mail. Thunderbird can read spool mail without a problem. And spool mail can also easily be forwarded to gmail etc, if so wanted (as long as we have a MTA). Mail is easy to understand and grasp for most users.
The journalctl commands are way more esoteric than the mail command, and
beyond what most normal users can/want to comprehend. So what the journal really need is a graphical frontend to help the non technically oriented users. But that is probably better discussed in another thread.
Jan 03 11:30:01 tux CROND[7380]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 03 11:40:01 tux CROND[7681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
I see " CMD (run-parts /etc/cron.hourly", that could be where the magic happens. Maybe the output will show up with other filters, or it could be rewritten to use systemd-cat.
What you see here is when cron is triggered. But I con not find any
information on how to read the output that these triggered cron jobs (may) produce. How are those retrieved using journalctl? I have no clue, do you? (Or any other?)
How is non technical user supposed to understand this? What command
sequence did you use to get that output?
A non-technical user would either understand by example - the part you cut out - or, they are a nontechnical user and have no interest in such things .
As I said before, a non technically oriented user should not be (forced)
to use these esoteric commands to find information on how the system behaves. It is good and dandy for us that like to understand the system, but this has to be made way more easy to use, as I mentioned before.
Compare receiving a mail of the output from a cron job, with the
journalctl commands you have shown. What do you think a non technically oriented user will find most easy to understand?
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b
How do you find out the _AUDIT_SESSION to use?
I didn't guess. There was a straightforward and easy to follow example, but you removed it.
Yes, but that part was just put into your mail (I removed the middle
part), but were did it come from? How did you produce that output? Or, to have a perhaps more useful question, how do I find out what _AUDIT_SESSION is relevant for a certain log line?
How am I notified that I should look in the journal when things go
wrong? (With mail I am notified and also get the "log" lines all at once)
How is a nontechnical desktop user notified of new mail? That's rhetorical, don't answer. They aren't .
It shows up in their inbox.
How is non technical user notified to look in the journal?
OK, then, your argument is late and pointless. Appeal to fesco if you feel strongly about adding sendmail to the default installation, such decisions are not made on the user support list.
That does not stop us from discussing it. We now have a situation were
certain applications do produce mail, and without an MTA those mails will be lost. That is not a good situation. This should have been taken care of *before* removing the MTA, so that information from the system is not lost. Why FESCO did not make sure of this is beyond me.
I have to as long as some applications use that path to send messages
to me. The same thing goes for all others installing these applications. Without a MTA these messages are lost in bit space.
Lars
More "I like using mail" ranting here. That's fine, use mail. I just wanted to point out how to use the journal, so I'm done here.
It is not about liking mail (or not), please read the last paragraph
above (above Lars), that paragraph explains the situation.
I also asked you if there exist a "journal for dummies" text where we can
find out how to become journal experts. The man page is a bit sparse on information. Do such a text exist, if so were?
Lars
The debate on default policy is best left to my betters, but as I said earlier today, I will write something about the journal and journalctl in the near future.
--Pete
On 01/03/2014 09:56 PM, Pete Travis wrote:
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
How do you know which IDENTIFIER to use? I could guess it should be CROND if I were to look at the output of journalctl in this case; but is there any canonical way to find this out? Or is it just the unit file name?
I picked that by looking at the messages and pairing up the identifier with my messages. It's reasonable to assume this will be consistent for cron jobs, so I didn't demonstrate that part.
It should perhaps be added that jounralctl has auto completion. Write jounralctl and press tab twice to see what you can use, type 'journalctl SYSLOG_IDENTIFIER=' and press tab twice, and you can see what to use there.
With auto completion I see crond, CROND, and crontab. (None of these will give me the output from cron by the way.) What is the difference between crond and CROND?
`journalctl -o verbose' gives the extra metadata. There are other output formats, ie json, but this seemed most useful here.
Thanks, that answered my question in the earlier mail from me.
key. There is a section in the System Administrators Guide on the journal, which I will probably update this weekend since the usage is newly fresh in my mind. It won't be published for f20 immediately, but I can push a draft if anyone is interested in reviewing. (Hint, readers, speak up, or I won't do the extra work)
OK, count me in... Could be a good way to get to know that system a bit better.
Lars
On 01/03/2014 08:32 PM, Tom H wrote:
On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson lars@homer.se wrote:
Rahul, as long as we have applications that do send mail, we need an MTA to take care of these mails, or else they are totally lost. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system.
The point that Chris has made is that these messages were already lost for most users because they didn't actually exist.
That is not relevant.
(A side note, they [the messages] did exist, in /var/spool/mail/root, that the user was not made aware of this was a documentation error)
FESCO has to consider the use-case of the majority of Fedora users and it decided that they don't need an MTA by default.
As long as some application use mail to inform the user an MTA is needed.
And, as has been said many times already, those who want an MTA, _understand_its_purpose_,_and_use_the_features_that_it_provides_ can install one.
That is not the point. The point is that (potentially) important mails are lost. Read the first paragraph starting with Rahul above.
Lars
On Fri, Jan 03, 2014 at 01:56:33PM -0700, Pete Travis wrote:
On Jan 3, 2014 1:16 PM, "Suvayu Ali" fatkasuvayu+linux@gmail.com wrote:
On Thu, Jan 02, 2014 at 09:07:29PM -0700, Pete Travis wrote:
$ su -c 'crontab -l'
- echo "TEST TEST"
$ crontab -l
- LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e
"This isn't the same.\nNew Things are Different.\nSome people like the old thing.";fi
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
How do you know which IDENTIFIER to use? I could guess it should be CROND if I were to look at the output of journalctl in this case; but is there any canonical way to find this out? Or is it just the unit file name?
I picked that by looking at the messages and pairing up the identifier with my messages. It's reasonable to assume this will be consistent for cron jobs, so I didn't demonstrate that part.
The syslog identifier is not the same as the unit file. `journalctl -u crond ` gives only stdout of crond itself, not the jobs. iirc, applications using the journal API can choose the syslog identifier for their messages, and one is chosen for them if not. I don't know the details behind that choice, but I would suspect it comes from the calling binary or service somehow.
Okay, I think I understand. And if I add Lars's suggestion about relying on completion, I think I can start doing some exploring on my own ;). Although some authoritative documentation on this would be really cool, specially to respond to queries on the mailing list.
say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.)
[...chomp...chomp...chomp...]
_BOOT_ID=0557929cbde247928f945d8b53a6e067How did you get this output; I'm confused.
`journalctl -o verbose' gives the extra metadata. There are other output formats, ie json, but this seemed most useful here.
`journalctl --show-cursor` gives the cursor at the end of the query.
This is an interesting output flag. I will play more with it. I guess this provides a nice interface if I want to parse journalctl output from my own scripts (bash, python, whatever).
I pulled all of that from `man journalctl` , /usr/share/doc/ , examining the metadata provided by "-o verbose", and generous mashing of the tab key. There is a section in the System Administrators Guide on the journal, which I will probably update this weekend since the usage is newly fresh in my mind. It won't be published for f20 immediately, but I can push a draft if anyone is interested in reviewing. (Hint, readers, speak up, or I won't do the extra work)
I would love to read that, and if I can give comments. I usually like doign documentation work :).
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b --show-cursor|tail -1
- -- cursor:
s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4
It is not clear to me what is meant by cursor here (I read journalctl(1)); moreover I could not find an option to journalctl called `--show-cursor'.
Think of the cursor as a unique key for the entry in a journal - but as I understand it, it references that point in the journal, not the specific entry. I have not read the code, so it is easier to demonstrate usage than explain the internals. In practice, a script or application tracking the journal can stop and resume at a specific point with more granularity and reliability than a timestamp, because timestamps may not be unique.
Thank you, I'll play with this myself. Sounds interesting.
If you don't mind could you share some of your journalctl understanding on another thread I started?
https://lists.fedoraproject.org/pipermail/users/2014-January/444479.html
Thanks a lot for your time.
No problem. I'll dig up that thread and see if I can help.
Thanks a lot!
:)
On Jan 3, 2014, at 12:27 PM, Tom H tomh0665@gmail.com wrote:
On Fri, Jan 3, 2014 at 3:05 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Thu, Jan 02, 2014 at 01:37:28PM -0700, Chris Murphy wrote:
Clearly it is. Most users don't know about this behavior. And it's also not done at all on iOS, Android, Windows, OS X. And it's highly questionable on desktop linux whether it's done or even needed.
I do not understand your comparison with iOS, OS X, Windows, etc. We are not in a race with any of them. We simply want an operating system that is free (open) and lets us be in control of our computing needs.
It's a question of looking at what others in this space are doing and evaluating whether their features are appropriate for Fedora and what their users are used and expect.
Exactly, it's about expectations. As an alternative OS, Fedora simply cannot depend on some 30 year old archaic user hostile way of unsuccessfully "delivering" supposedly important system messages. It's just absurd. And that cannot be fixed by somehow figuring out a way to get those emails delivered because it's a hideous way of notification anyway. I wouldn't want it to work. When I talk about the majority, I mean literally everyone using some kind of computing device.
Fedora users (and Linux users in general) most probably use Windows or OS X at work and own an Android or iOS phone, so diverging from them, especially when it comes to some geeky log retrieval mechanism, isn't in the best interest of Fedora.
Right, I don't know why this needs explaining, but thanks for doing it.
Chris Murphy
On Jan 3, 2014, at 12:32 PM, Tom H tomh0665@gmail.com wrote:
On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson lars@homer.se wrote:
On 01/03/2014 12:01 AM, Rahul Sundaram wrote:
https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendmail....
Rahul, as long as we have applications that do send mail, we need an MTA to take care of these mails, or else they are totally lost. Or at least let those applications have a requirement of a MTA so that the MTA is installed when those applications are installed on the system.
The point that Chris has made is that these messages were already lost for most users because they didn't actually exist.
Well…to be more specific I'm suggesting they're functionally equivalent to lost because their existence is obscured. Until this issue came up on devel I didn't know there were messages going to /var/spool/mail/root. I was then reminded of 24 years prior logging into UNIX computers at school and upon text login getting a notification that I had some mails and I'd use some mail program to read them. And I thought, umm, it's 2013 and this ancient mechanism is still in place? Seriously? Let's look at these emails. Oh…it's all junk. Great. How do I turn this craptasticness off?
So the idea there are any useful emails in there for most users is total b.s. as far as I'm concerned. And for anyone who configures something that will produce meaningful messages, they can yum install <mtaofchoice>, nothing prevents that. But I will argue that such programs are broken for contemporary work flow. But such is nice about most things F/OSS you can still run them, and cobble together some other ancient thing so you're getting some notifications from this archaic madness that still works otherwise OK (I assume or why use it?).
And default installation of an MTA does not fix any problem at all, it just means a minority don't have to do yum install <mta> and the majority go on oblivious to uselessly faux-important messages sucking up space on their computer without notification. That is not fixable. Email is the wrong way to do it.
Chris Murphy
On 01/04/2014 02:10 AM, Chris Murphy wrote:
Exactly, it's about expectations. As an alternative OS, Fedora simply cannot depend on some 30 year old archaic user hostile way of unsuccessfully "delivering" supposedly important system messages. It's just absurd. And that cannot be fixed by somehow figuring out a way to get those emails delivered because it's a hideous way of notification anyway. I wouldn't want it to work. When I talk about the majority, I mean literally everyone using some kind of computing device.
So age is a bad thing? Why? If it has worked for 30 years, it is probably because that way of doing things has its merits.
That you despise mail has nothing to do with the problem we have here. We do have applications in Fedora that do send mail. If you are not interested in those mails, well fine, ignore them, and do something else instead, the message will still be created.
Either those applications has to be changed, to use some other sort of communication with the user, a communication that, for the user, works the same way (i.e. that the user is notified in a similar manner, and speed, as before, but via another media). Or the MTA has to stay.
By removing the MTA those mails will be lost, and that has to be resolved.
Again, this has nothing, absolutely nothing, to do with loving or hating mail. It has to do with a way to inform the user that has to be handled in a manner that ensures that the user is informed.
Am I really that bad at explaining what the problem is?
Lars
On Jan 3, 2014, at 1:31 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Fri, Jan 03, 2014 at 07:27:05PM +0000, Tom H wrote:
On Fri, Jan 3, 2014 at 3:05 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Thu, Jan 02, 2014 at 01:37:28PM -0700, Chris Murphy wrote:
Clearly it is. Most users don't know about this behavior. And it's also not done at all on iOS, Android, Windows, OS X. And it's highly questionable on desktop linux whether it's done or even needed.
I do not understand your comparison with iOS, OS X, Windows, etc. We are not in a race with any of them. We simply want an operating system that is free (open) and lets us be in control of our computing needs.
It's a question of looking at what others in this space are doing and evaluating whether their features are appropriate for Fedora and what their users are used and expect. Fedora users (and Linux users in general) most probably use Windows or OS X at work and own an Android or iOS phone, so diverging from them, especially when it comes to some geeky log retrieval mechanism, isn't in the best interest of Fedora.
Why do they have to be the same? If I wanted what either of those OSes offer, I would be using them, not Fedora. I do not understand why my choices have to be minor variations of each other instead of distinctly different based on needs.
Guess what you can yum install <mtaofchoice> and get your user choice. Forcing the default installation of something most people do not make use of is NOT a valid F/OSS argument. The valid argument is that you do have the choice to install it, whereas on OS X when Apple changes things, I often don't have a choice.
So why do I use it? Because some closed applications I need to use for work are only available on it or Windows and I prefer OS X despite how much more closed it is, these days sometimes even more closed than Windows is. So that's a nice lesson that closed vs open isn't a good metric for success. And yes a distro must be successful to survive, there's a critical mass needed for it to be viable. And Fedora is one of the most adaptive distros out there, intentionally. That means constant changes.
Now there will be some additional users talking to upstream developers to incorporate better means of notification rather than depending on emails that obviously aren't being seen by most peopel anyway, but now with Fedora 20 they aren't there by default either. Like using SNMP for smartd rather than emails.
Chris Murphy
On Fri, Jan 03, 2014 at 06:32:43PM -0700, Chris Murphy wrote:
Now there will be some additional users talking to upstream developers to incorporate better means of notification rather than depending on emails that obviously aren't being seen by most peopel anyway, but now with Fedora 20 they aren't there by default either. Like using SNMP for smartd rather than emails.
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
On 01/04/2014 02:40 AM, Suvayu Ali wrote:
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
*Exactly*
Lars
On Jan 3, 2014, at 6:30 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/04/2014 02:10 AM, Chris Murphy wrote:
Exactly, it's about expectations. As an alternative OS, Fedora simply cannot depend on some 30 year old archaic user hostile way of unsuccessfully "delivering" supposedly important system messages. It's just absurd. And that cannot be fixed by somehow figuring out a way to get those emails delivered because it's a hideous way of notification anyway. I wouldn't want it to work. When I talk about the majority, I mean literally everyone using some kind of computing device.
So age is a bad thing? Why? If it has worked for 30 years, it is probably because that way of doing things has its merits.
Maybe. But at least as often or more, it's just becoming decrepit. It refuses to learn new tricks. It doesn't want to learn to write to a journal or use SNMP or Gnome desktop notification services, or anything other than emails that 9 out of 10 people are not aware of exist or read or care to be notified in that fashion.
Look the post office is shrinking because it has a product that has far far fewer use cases than before. Should it die totally? I don't know, probably not. But does it need to contract? Clearly yes. Email is a big reason why. And now there are many other ways to communicate, and abuses of email, that makes it time for email to be supplanted. Maybe not go away entirely, but for particular use cases. And this is not one of them.
That you despise mail has nothing to do with the problem we have here.
It does because this sentiment about email's usefulness is widespread. New applications, and maturity applications with a going concern will need to adapt to this reality and pick one or maybe two newer notification methods. And perhaps someone has built something that converts email from one of these old programs into a text message, or something that generates an alert in Gnome or on Android. That would be a nice bridge between epochs, yes?
We do have applications in Fedora that do send mail. If you are not interested in those mails, well fine, ignore them, and do something else instead, the message will still be created.
Fortunately, it's not created anymore.
Either those applications has to be changed, to use some other sort of communication with the user, a communication that, for the user, works the same way (i.e. that the user is notified in a similar manner, and speed, as before, but via another media).
The applications can change or not. They actually don't have to be changed. They probably should change if they want to survive though.
By removing the MTA those mails will be lost, and that has to be resolved.
Ask those application developers to use a notification system you want to use. And in the meantime you can install an MTA. It's very simple.
You can't say the messages are important as a statement of fact because if it were a fact we'd both agree on it, as well as everyone else. That there isn't widespread agreement on the value of these emails means their importance is a matter of opinion. If a program only used email as notification for truly important messages, I would not use it.
Imagine GIMP having some error and instead of a dialog, it sent an email! Ha! Talk about ridiculous. So yes, this really is about email. If my refrigerator emailed me the door was left open, I'd burn the refrigerator to the ground in public and post a video.
Again, this has nothing, absolutely nothing, to do with loving or hating mail. It has to do with a way to inform the user that has to be handled in a manner that ensures that the user is informed.
Email hate as a lot to do with it. But more than this it has to do with people simply work differently than 20 years ago. Heck they work differently than 5 years ago. And there are new communication technologies appearing that are supplanting email even where there isn't email hate.
Am I really that bad at explaining what the problem is?
Yes because you keep suggesting the MTA shouldn't go away by default as if that solves ONE SINGLE THING. It doesn't solve anything at all. And besides it's already not installed by default so if you want it in F21 by default you need to go make the case on devel@ not here.
Chris Murphy
On Jan 3, 2014, at 6:40 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Fri, Jan 03, 2014 at 06:32:43PM -0700, Chris Murphy wrote:
Now there will be some additional users talking to upstream developers to incorporate better means of notification rather than depending on emails that obviously aren't being seen by most peopel anyway, but now with Fedora 20 they aren't there by default either. Like using SNMP for smartd rather than emails.
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
1. Most people weren't using it.
2. No default MTA does *NOT* break the existing mechanism. It simply requires a minority of users to not be lazy whiners and yum install <blahMTA>.
This whole thread is like someone died. First there's denial, then there's anger, next I wonder if we see more bargaining on the devel@ list to bring back the dead MTA zombie. And when that doesn't work we'll see depression and finally acceptance.
Make it easy, just jump straight to acceptance. Nothing is broken. You can still yum install mta and it works just like F19 did.
Chris Murphy
On Jan 3, 2014, at 6:41 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/04/2014 02:40 AM, Suvayu Ali wrote:
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
*Exactly*
Please, SNMP has been around since 1988. Gnome has had a notification system for several years at least, probably longer. If I did 10 minutes of research there are probably 1/2 dozen other notification systems out there, a few of which are reasonably mature.
So how long do you want for your ancient email only sending program to modernize? They haven't picked an alternative by choice. And it is their choice to not do so. It is inappropriate for Fedora to sit on its laurels waiting for every program to modernize before it makes changes the benefit most users. And it's inappropriate for Fedora to dictate these programs use some other method of notification than email.
So *exactly* what are you two even talking about? Precisely how does waiting and doing NOTHING encourage program devs to change their notification methods? OH right, it doesn't do anything except enhance the stagnation and legitimize the non-working notification by email paradigm.
Guess what? Presumably the programs that you use that only notify by email, do not modernize because their user base doesn't care for any other kind of notification system. In which case you will have to install an MTA to get your important messages. I don't see what's so difficult to understand.
Chris Murphy
Chris Murphy <lists <at> colorremedies.com> writes:
On Jan 2, 2014, at 3:42 PM, "Lars E. Pettersson" <lars <at> homer.se> wrote:
On 01/02/2014 11:31 PM, Rahul Sundaram wrote:
Yes, all critical notifications are supposed to stay persistent. That is the right model to alert desktop users about anything relevant enough to bother them with. Not emails.
Works OK on a desktop, but how is the home server use case, where the
user is not logged in on the computer,
supposed to be handled?
Regarding emails. I still have not gotten any response from anyone on
how to handle the output from, as an
example, cron, logwatch, etc. Hopefully someone could tell how that is
supposed top be taken care of now
that the MTA is removed.
If you like the MTA method of being notified, install an MTA. Simple. You
have been told this numerous times
so don't say you haven't gotten any responses.
That would involve both adding to the journal, and notify the user,
and/or other actions. Shouldn't that
have been addressed *before* removing the MTA?
No because no one was getting messages with the MTA unless they went
looking for them in the first place. And
now they merely have one more step which is installing the MTA of their
choice, which for a lot of Fedora
users wasn't sendmail anyway.
Sendmail was taking up space on the install media, on users computers, for
no benefit for the vast majority
of users. I don't know how many times this has to be said - look at the
number of unique individuals involved
in the conversation in this thread? It's less than a dozen. So we're
talking thousands of users, and less
than 12 give a crap whether an MTA is installed by default or not. It's
really close to zero people care about it.
Chris Murphy
Chris -
This is as close as I can get to the "end" of this discussion since I get the digest so it will have to do. I've seen you claim over and over that "no one" uses e-mail for system notifications. This is the exact opposite of my experience (30+ years with computers, 25+ years with Unix systems and 15+ years with Linux including currently working as a Linux/Unix engineer). Do you have *ANY* independently verifiable numbers to back up your claim?
My experience has been that Linux newbies don't know about root e-mail and go whining on various discussion boards about how they didn't know that there was a problem until someone points them to root e-mail and e-mail aliases. If these are the "no one uses e-mail" people you're claiming is "everyone" then you're listening to the wrong people. Or is it just that these are the people you agree with?
Personally, I find the Windows practice of hiding notifications behind an inscrutable "event log" interface to be far, far worse than getting e-mail notifications. I'll take logwatch e-mails any day over an event log since it also lets me watch for trends or anomalies that may not break a reporting threshold. Likewise, I compare the typical event API notification to being like the "idiot lights" most cars come with. You know, the "over temperature" light that comes one AFTER steam is coming out from under the hood or the tire pressure warning light that comes on as you pull off the road with a flat?
I have not had the displeasure of trying F-20 without an MTA yet. When I do, I will install an MTA so I can monitor the system the same way I monitor my other systems. I just hope I don't have to write a perl script to take output from journalctl and e-mail me when something important happens.
Cheers, Dave
On Fri, 3 Jan 2014 16:17:43 -0700 Pete Travis lists@petetravis.com wrote:
The debate on default policy is best left to my betters, but as I said earlier today, I will write something about the journal and journalctl in the near future.
--Pete
It would be most appreciated, By someone "man dead" like myself
___ Regards, Frank www.frankly3d.com
On 01/04/2014 03:13 AM, Chris Murphy wrote:
On Jan 3, 2014, at 6:41 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/04/2014 02:40 AM, Suvayu Ali wrote:
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
*Exactly*
Please, SNMP has been around since 1988. Gnome has had a notification system for several years at least, probably longer. If I did 10 minutes of research there are probably 1/2 dozen other notification systems out there, a few of which are reasonably mature.
What has this to do with the text you quote?
SNMP and the Gnome notification are two entirely different creatures, and can not be compared.
So how long do you want for your ancient email only sending program to modernize? They haven't picked an alternative by choice. And it is their choice to not do so. It is inappropriate for Fedora to sit on its laurels waiting for every program to modernize before it makes changes the benefit most users. And it's inappropriate for Fedora to dictate these programs use some other method of notification than email.
Why should they modernize? If something been around for 30 years, well, then it probably has so because of a reason. Please try to do some read in on the subject, and perhaps you will understand this very reason.
So *exactly* what are you two even talking about? Precisely how does waiting and doing NOTHING encourage program devs to change their notification methods? OH right, it doesn't do anything except enhance the stagnation and legitimize the non-working notification by email paradigm.
What we are talking about is compressed into the first sentence you quoted in this message. Please read that sentence again.
Guess what? Presumably the programs that you use that only notify by email, do not modernize because their user base doesn't care for any other kind of notification system. In which case you will have to install an MTA to get your important messages. I don't see what's so difficult to understand.
By removing the MTA you remove functionality that exist. That you and others do not use this functionality does not change that fact. If you want top remove that functionality, you first have to change the applications to use some other method of communicating with the user. This should have be done *before* removing the MTA, as removing the MTA remove existing functionality. Is this too hard to comprehend?
Lars
On 01/04/2014 02:59 AM, Chris Murphy wrote:
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
- Most people weren't using it.
How do you know that?
The functionality is there, you not knowing about it is no reason to remove it.
- No default MTA does *NOT* break the existing mechanism. It simply requires a minority of users to not be lazy whiners and yum install <blahMTA>.
It *does* break existing functionality.
Whiners about sendmail could equally well do 'yum remove sendmail' and be over with it. So what is your point? The fact that a user can select to add or remove a certain applications has nothing to do with what we are discussing now.
This whole thread is like someone died.
No.
Make it easy, just jump straight to acceptance. Nothing is broken.
It is broken. Read in on the subject, and you will see.
Please read the question you quoted, the first one in this mail. Try to understand what it says.
Lars
On 01/04/2014 02:54 AM, Chris Murphy wrote:
Maybe. But at least as often or more, it's just becoming decrepit. It refuses to learn new tricks. It doesn't want to learn to write to a journal or use SNMP or Gnome desktop notification services, or anything other than emails that 9 out of 10 people are not aware of exist or read or care to be notified in that fashion.
Then please tell us how this functionality should be moved to Gnome desktop notification, SNMP, etc. (you stated earlier that SNMP started in 1988, that's 26 years ago, isn't that archaic, old, decript, etc. also?), and at the same time retain the information that this functionality provides today. Please let us know how to do that.
Look the post office is shrinking because it has a product that has far far fewer use cases than before. Should it die totally? I don't know, probably not. But does it need to contract? Clearly yes. Email is a big reason why. And now there are many other ways to communicate, and abuses of email, that makes it time for email to be supplanted. Maybe not go away entirely, but for particular use cases. And this is not one of them.
There are more parcels sent around than ever, due to ebay and similar sites where people sell stuff. Does not the US postal service also send parcels?
What should we use instead of email?
We do have applications in Fedora that do send mail. If you are not interested in those mails, well fine, ignore them, and do something else instead, the message will still be created.
Fortunately, it's not created anymore.
Which removes existing functionality leading to lost information, which is a bad thing, and the reason for this little debate.
Imagine GIMP having some error and instead of a dialog, it sent an email! Ha! Talk about ridiculous. So yes, this really is about email. If my refrigerator emailed me the door was left open, I'd burn the refrigerator to the ground in public and post a video.
GIMP is a user level program with a GUI. What we are talking about are mostly system daemons. An entirely different creature.
Lars
On Jan 3, 2014, at 11:24 PM, David G. Miller dave@davenjudy.org wrote:
This is as close as I can get to the "end" of this discussion since I get the digest so it will have to do. I've seen you claim over and over that "no one" uses e-mail for system notifications.
It's hyperbole for me to say "no one" because it's clearly not meant to be literal. But it's true that from a high altitude perspective, it's in the realm of 99%.
This is the exact opposite of my experience (30+ years with computers, 25+ years with Unix systems and 15+ years with Linux including currently working as a Linux/Unix engineer).
Do you have *ANY* independently verifiable numbers to back up your claim?
Yes it's called observation. Windows doesn't inform users of problems by email since never. OS X likewise, in effect has never done this because root was disabled, even though postfix is installed by default even to this day. iOS and Android never have either.
Restricting the context to just Fedora, by default it is a desktop OS with a GUI. That's the default install from live desktop, DVD ISO, and netinst media. That is the primary Fedora deliverable and experience. It is simply inappropriate for such a system, in the year 1999 let alone 2014, to silently produce "important" messages via email as if the user will somehow just magically discover them. And in fact, that's not how it behaves, the user is properly informed of important messages via alerts in gnome-shell (and presumably on KDE), for things like SELinux alerts, crashes, and degraded raid arrays (via udisks). So in fact this is working rather like I expect, whether it's Fedora 19 or Fedora 20. By default I don't have to configure anything to be informed of urgent issues.
My experience has been that Linux newbies don't know about root e-mail and go whining on various discussion boards about how they didn't know that there was a problem until someone points them to root e-mail and e-mail aliases. If these are the "no one uses e-mail" people you're claiming is "everyone" then you're listening to the wrong people. Or is it just that these are the people you agree with?
I definitely agree with them. If it's important they should be logged. If it's critical/urgent then I should get an alert in the GUI. That's actually how it works for some time. Emails are an inadequate and therefore inappropriate default means of communicating because we know they will not be discovered by most users. The RTFM approach obviously isn't working, at all.
And for those who prefer the email notification approach: yum install <mta>. It is possible that with F21's server product this could revert to having an MTA by default if the server working group deems it an important feature to have.
Personally, I find the Windows practice of hiding notifications behind an inscrutable "event log" interface to be far, far worse than getting e-mail notifications. I'll take logwatch e-mails any day over an event log since it also lets me watch for trends or anomalies that may not break a reporting threshold. Likewise, I compare the typical event API notification to being like the "idiot lights" most cars come with. You know, the "over temperature" light that comes one AFTER steam is coming out from under the hood or the tire pressure warning light that comes on as you pull off the road with a flat?
I think these are all bad examples because they're clearly broken notifications if they notify of obvious things. The alerts that appear in gnome-shell that I've seen have always been for non-obvious problems that needed attention like a dead hard drive in an array and the system kept on working normally otherwise, as it should in degraded mode.
I have not had the displeasure of trying F-20 without an MTA yet.
I know, 'yum install <mta>' is just sooo stressful. Geez.
Chris Murphy
Chris Murphy <lists <at> colorremedies.com> writes:
Restricting the context to just Fedora, by default it is a desktop OS with
a GUI. That's the default install
from live desktop, DVD ISO, and netinst media. That is the primary Fedora
deliverable and experience. It
is simply inappropriate for such a system, in the year 1999 let alone
2014, to silently produce
"important" messages via email as if the user will somehow just magically
discover them. And in fact,
that's not how it behaves, the user is properly informed of important
messages via alerts in gnome-shell
(and presumably on KDE), for things like SELinux alerts, crashes, and
degraded raid arrays (via udisks).
I'd really like to be able to get smartd notifications, in GNOME, without having to configure an MTA at all. For now, it's easier for me to just check gnome-disks regularly, but not as prompt. My last HDD only lasted about 1 1/2 years, and at the time its failure affected my ability to work, the number of bad sectors was high, but still below the FAIL threshold. (The previous day, there were no bad sectors at all, or any other sign of failure.) There wasn't enough time to do a backup before it failed. Having Fedora configured by default to give a desktop notification when the number of bad sectors increases (not just hitting an arbitrary FAIL threshold) would be handy.
On Sat, 4 Jan 2014 13:45:34 -0700 Chris Murphy lists@colorremedies.com wrote:
Restricting the context to just Fedora, by default it is a desktop OS with a GUI. That's the default install from live desktop, DVD ISO, and netinst media. That is the primary Fedora deliverable and experience.
By that logic, you could argue that Fedora should not have sshd installed by default. A typical desktop OS with a GUI is typically never being accessed remotely, for the vast 99% majority of cases.
And yet somehow I doubt that anyone will dare to remove sshd from the default install.
But since we are bashing around about unnecessary default services, one set of services that I would actually like to see removed is the NFS stack (nfs, nfslock, portmap, ...). Arguably, a typical desktop OS with a GUI has absolutely no need of networked file systems, especially as obsolete as NFS. I've used Fedora for as long as it exists, and I've never seen anyone actually use NFS in real life scenarios on a typical desktop machine with a GUI. That's also got to be in the 99% of cases...
Best, :-) Marko
On Jan 4, 2014, at 2:47 PM, Andre Robatino robatino@fedoraproject.org wrote:
I'd really like to be able to get smartd notifications, in GNOME, without having to configure an MTA at all.
Hmmm… http://gnomeshell.wordpress.com/2011/08/28/manage-the-startup-applications/
This shows Disk Notifications does this, and some results seem to indicate it was a default behavior at one time. Fedora 20 Gnome doesn't have this item in startup-applications. And I can't find a gdu-notification-daemon. I do have a gdu-sd-plugin.
Then I find this: http://code.metager.de/source/history/gnome/Platform/disk-utility/src/notify...
Looks like it was cut in 3.4 and has been added back in as gdu-sd-plugin.gnome-settings-plugin.in but I'm not sure how to access this in the GUI to configure it, or maybe it's already enabled by default. I'm not sure. In Disks, I have an option "Drive Settings" but it doesn't include SMART monitoring or notifications. There is a SMART Data & Self Tests which is "On". I don't know if that means I'll get notifications.
journalctl -xb | grep -i smartd
Shows that it is enabled and my drive has been added to the monitor list. If I remove -b, I get a lot more entries from prior boots, but there's no indication any tests are being done.
For now, it's easier for me to just check gnome-disks regularly, but not as prompt. My last HDD only lasted about 1 1/2 years, and at the time its failure affected my ability to work, the number of bad sectors was high, but still below the FAIL threshold.
This requires a lot of subjectivity and the available data shows something like a 60% correlation between the self-assessment and failure. So about 40% of the time, a failure occurs while health is a pass. And then correlating individual attributes to failures is also difficult according to the research. What might be useful is if the monitor setting had a slider for the user to set how verbose the monitoring is. Other than off, the least verbose would be to report any attribute in pre-fail now. And most verbose might notify each time any pre-fail type attribute value changes by >=2 since last check.
Value is not the same as the attribute's raw_ value which can change by a lot more than one without affecting the value. Raw_value is probably too verbose to be useful. And the old age types don't all give an indicator of impending failure.
A bigger issue is that the SCT ERC for consumer drives is almost certainly mismatched with the default linux SCSI block layer timeout value, so what happens is the drive can have problems that don't result in read errors before the kernel decides to reset the bus. For any raid configuration this especially tragic and to my knowledge the installer isn't changing the defaults.
[root@f20s ~]# cat /sys/block/sda/device/timeout 30
Indeed. 30 seconds is when it will timeout, and yet the drive is typically 120.
(The previous day, there were no bad sectors at all, or any other sign of failure.) There wasn't enough time to do a backup before it failed. Having Fedora configured by default to give a desktop notification when the number of bad sectors increases (not just hitting an arbitrary FAIL threshold) would be handy.
I'd file a feature request, I'll support it.
Chris Murphy
On Jan 4, 2014, at 6:12 PM, Marko Vojinovic vvmarko@gmail.com wrote:
On Sat, 4 Jan 2014 13:45:34 -0700 Chris Murphy lists@colorremedies.com wrote:
Restricting the context to just Fedora, by default it is a desktop OS with a GUI. That's the default install from live desktop, DVD ISO, and netinst media. That is the primary Fedora deliverable and experience.
By that logic, you could argue that Fedora should not have sshd installed by default. A typical desktop OS with a GUI is typically never being accessed remotely, for the vast 99% majority of cases.
Out of scope, the context is notifications. Given how people work, the MTA by default method of notification doesn't help uses unless they know where to look and how to configure it for non-local usage.
And yet somehow I doubt that anyone will dare to remove sshd from the default install.
I suspect it's used a ton more than an MTA. I enable sshd on all of my Macs and Fedora installs as one of the first things done. MTA? Never. Not configured even one time in 24 years.
But since we are bashing around about unnecessary default services, one set of services that I would actually like to see removed is the NFS stack (nfs, nfslock, portmap, ...). Arguably, a typical desktop OS with a GUI has absolutely no need of networked file systems, especially as obsolete as NFS. I've used Fedora for as long as it exists, and I've never seen anyone actually use NFS in real life scenarios on a typical desktop machine with a GUI. That's also got to be in the 99% of cases…
NFSv4.1 is a two year old spec? It's quite current. Getting rid of all the NFSv3 junk by default I think is valid. For video editing it's actually rather common on OS X because apparently applications don't disqualify NFS as a share for live editing, whereas AFP and SMB shares typically are disqualified for some reason. Plus async, it has much better performance than either AFP or SMB. It's the only file sharing I do between Fedora and OS X. Now that Apple is deprecating AFP in favor of SMB2, I'm uninterested in Netatalk. And their SMB2 implementation is still immature and buggy, while samba has something like 400 page quick start guide and a 9000 page user manual it's so complicated. (I'm exaggerating by a lot, but it seems an order of magnitude or more complicated than NFS to configure.)
Chris Murphy
On Sun, 5 Jan 2014 01:12:40 +0000 Marko Vojinovic vvmarko@gmail.com wrote: I've used Fedora for as long as it
exists, and I've never seen anyone actually use NFS in real life scenarios on a typical desktop machine with a GUI. That's also got to be in the 99% of cases...
I use nfs from Windows 8.1 to Fedora (filestore\backup etc..) As well as between Fedora Boxes
___ Regards, Frank www.frankly3d.com
On 01/04/2014 03:13 AM, Chris Murphy wrote:
On Jan 3, 2014, at 6:41 PM, "Lars E. Pettersson" lars@homer.se wrote:
On 01/04/2014 02:40 AM, Suvayu Ali wrote:
What I fail to follow is, why break the existing mechanism *before* we have these other future notification mechanisms ready?
*Exactly*
Please, SNMP has been around since 1988. Gnome has had a notification system for several years at least, probably longer.
Notifications do not belong into a GUI.
If I did 10 minutes of research there are probably 1/2 dozen other notification systems out there, a few of which are reasonably mature.
So how long do you want for your ancient email only sending program to modernize?
Why should any portable program support anything else but email? Unlike many other notification systems, email has proven its long term usability and applicability.
They haven't picked an alternative by choice. And it is their choice to not do so. It is inappropriate for Fedora to sit on its laurels waiting for every program to modernize before it makes changes the benefit most users. And it's inappropriate for Fedora to dictate these programs use some other method of notification than email.
Correct, ... but later is what is happening.
So *exactly* what are you two even talking about? Precisely how does waiting and doing NOTHING encourage program devs to change their notification methods?
May-be those devs have been satisfied with the situation and haven't seen any need to switch?
OH right, it doesn't do anything except enhance the stagnation and legitimize the non-working notification by email paradigm.
Guess what? Presumably the programs that you use that only notify by email, do not modernize because their user base doesn't care for any other kind of notification system.
I could not disagree more. IMO, what currently is going on in Fedora, is a campaign being led and conducted by inexperienced and wanna-be system-integrators, who haven't understood how things have been working for 20 years+.
On 01/05/2014 02:27 AM, Chris Murphy wrote:
I suspect it's used a ton more than an MTA. I enable sshd on all of my Macs and Fedora installs as one of the first things done. MTA? Never. Not configured even one time in 24 years.
Do you have any numbers on that (MTA vs. sshd)?
So sshd should stay because you use it, and the MTA should go because you do not use it. I do not buy into that kind of logic.
Added to this, the MTA is used by some applications, removing the MTA breaks the "notification" mechanism these applications use, i.e. mails. Enabling or disabling sshd does not interfere with other applications "notification" systems.
Lars
On 01/05/2014 09:25 AM, Frank Murphy wrote:
I use nfs from Windows 8.1 to Fedora (filestore\backup etc..) As well as between Fedora Boxes
Have you tried sshfs? We moved to that at work years ago (to share between Linux boxes, but windows applications for sshfs also exist).
Lars
On 01/04/2014 09:45 PM, Chris Murphy wrote:
On Jan 3, 2014, at 11:24 PM, David G. Miller dave@davenjudy.org wrote:
This is as close as I can get to the "end" of this discussion since I get the digest so it will have to do. I've seen you claim over and over that "no one" uses e-mail for system notifications.
It's hyperbole for me to say "no one" because it's clearly not meant to be literal. But it's true that from a high altitude perspective, it's in the realm of 99%.
No. IMO, this is just a defect of RH/Fedora based and other Linux distros. They have not been able to provide a proper, out-of-the-box configuration.
If they had done so, everybody was using it.
This is the exact opposite of my experience (30+ years with computers, 25+ years with Unix systems and 15+ years with Linux including currently working as a Linux/Unix engineer).
Do you have *ANY* independently verifiable numbers to back up your claim?
Yes it's called observation. Windows doesn't inform users of problems by email since never. OS X likewise, in effect has never done this because root was disabled, even though postfix is installed by default even to this day. iOS and Android never have either.
Apples and oranges. Correct, most of these OSes do not support this feature, primarily because these OSes have been designed as single-seat/single-users OSes and did not take multi-user/network-wide system-management into account.
Restricting the context to just Fedora, by default it is a desktop OS with a GUI.
That's what some people around here want to make it. However this is *not* what Linux is, nor is it what I want it to be.
If I'd wanted it to be ... I'd buy and use iOS, Windows or similar.
And in fact, that's not how it behaves, the user is properly informed of important messages via alerts in gnome-shell (and presumably on KDE), for things like SELinux alerts, crashes, and degraded raid arrays (via udisks). So in fact this is working rather like I expect, whether it's Fedora 19 or Fedora 20. By default I don't have to configure anything to be informed of urgent issues.
Again, this is the single-user school of thinking, which is inappropriate for multi-user/mult-seat system.
The alerts that appear in gnome-shell that I've seen have always been for non-obvious problems that needed attention like a dead hard drive in an array and the system kept on working normally otherwise, as it should in degraded mode.
I think gnome-alerts (and other desktop) notifications are a broken design - Why? They are inappropriate in everything else but a "personal-single-user" system. Think about non-IT personnel being notified in a corporite network environment.
On Sun, 05 Jan 2014 10:19:52 +0100 "Lars E. Pettersson" lars@homer.se wrote:
Have you tried sshfs?
No, We moved to that at work years ago (to share
between Linux boxes, but windows applications for sshfs also exist).
Lars
Will give it a test http://linhost.info/2012/09/sshfs-in-windows/
___ Regards, Frank www.frankly3d.com
On Sat, Jan 04, 2014 at 01:45:34PM -0700, Chris Murphy wrote:
Restricting the context to just Fedora, by default it is a desktop OS with a GUI. That's the default install from live desktop, DVD ISO, and netinst media. That is the primary Fedora deliverable and experience. It is simply
Well, let's go out one step form Fedora desktop though, to the Fedora cloud and Fedora server targets.
In cloud deployments, email notifications are a definite non-starter, because no one is going to ever log into individual machines to check, and outgoing mail from cloud networks is likely to just be dropped.
On servers, an MTA is often appropriate, but traditional servers are built to fit their niche and their specific needs. There, you have a kickstart file or hopefully at least a hand-built checklist for deployment, and "install MTA and configure for the relay environment used on my network" should be on the list.
On Jan 5, 2014, at 2:31 AM, Ralf Corsepius rc040203@freenet.de wrote:
No. IMO, this is just a defect of RH/Fedora based and other Linux distros. They have not been able to provide a proper, out-of-the-box configuration.
If they had done so, everybody was using it.
So this long running defect is just *itching* to be fixed so badly that the decision to drop installing an MTA by default was about to happen on the precipice of a proper OOB configuration implementation being ready for wide spread deployment?
Apples and oranges. Correct, most of these OSes do not support this feature, primarily because these OSes have been designed as single-seat/single-users OSes and did not take multi-user/network-wide system-management into account.
Windows has been designed for multi-user for over a decade, its origin as single user isn't relevant. While OS X has been multi-user since the before it was called OS X. This (factually incorrect) distinction is orthogonal to how humans prefer to be notified of problems, and what resources they're going to dedicate to configure it into the *existing* manner in which they work.
Restricting the context to just Fedora, by default it is a desktop OS with a GUI.
That's what some people around here want to make it.
Make it? It's been this way for what a decade? If anything it could be about to change in the direction you want with Fedora.next if the Server WG decides an MTA by default makes sense. Desktop? Good riddance. Cloud/VM? They get configured and then don't get logged into at all in normal operation. Why would I want the equivalent of something dating back to ants encased in amber? All of those VM MTAs to configure for non-local mail delivery is the easy part. The worst part is having VM's email me.
However this is *not* what Linux is, nor is it what I want it to be.
And this is what's so great about F/OSS, you get to yum install <mta> or whatever you want to make it whatever you want.
The alerts that appear in gnome-shell that I've seen have always been for non-obvious problems that needed attention like a dead hard drive in an array and the system kept on working normally otherwise, as it should in degraded mode.
I think gnome-alerts (and other desktop) notifications are a broken design - Why? They are inappropriate in everything else but a "personal-single-user" system. Think about non-IT personnel being notified in a corporite network environment.
It is one example, that is somewhat desktop biased, of a notification method better than emails. For server/cloud, if you were to argue that nagios (or other), should be installed by default, I might be inclined to agree. I suspect those WGs would be willing to look into it. But I don't know how that's going to end up working in terms of yum/dnf packaging. Maybe they all will share some core/base whatever it will be called, and then they'll become differentiated using package groups. *shrug*
Chris Murphy
On 01/05/2014 11:50 PM, Chris Murphy wrote:
On Jan 5, 2014, at 2:31 AM, Ralf Corsepius rc040203@freenet.de wrote:
No. IMO, this is just a defect of RH/Fedora based and other Linux distros. They have not been able to provide a proper, out-of-the-box configuration.
If they had done so, everybody was using it.
So this long running defect is just *itching* to be fixed so badly that the decision to drop installing an MTA by default was about to happen on the precipice of a proper OOB configuration implementation being ready for wide spread deployment?
Apples and oranges. Correct, most of these OSes do not support this feature, primarily because these OSes have been designed as single-seat/single-users OSes and did not take multi-user/network-wide system-management into account.
Windows has been designed for multi-user for over a decade, its origin as single user isn't relevant.
Win is multi-user in the sense as it allows more than one-login.
The actual difference to Linux is: Linux basically is a server OS, which also can be deployed as a desktop and can also be deployed as a single-user/single-seat OS.
With Win, the situation is converse: It once was is a single-user desktop client-OS, which meanwhile allows some limited "multi-user/server" uses.
Restricting the context to just Fedora, by default it is a desktop OS with a GUI.
That's what some people around here want to make it.
Make it? It's been this way for what a decade?
Correct, Fedora has not be been this way and except that some people do not seem to take non-single-user/single-seat configurations into account in Fedora-development, Fedora fortunately still isn't.
However this is *not* what Linux is, nor is it what I want it to be.
And this is what's so great about F/OSS, you get to yum install <mta> or whatever you want to make it whatever you want.
Right, you've got it! Linux (comprising Fedora) is a "construction kit", and is it *not* a restricted to be used as mere "Desktop OS". Deploying it as a desktop is just a subset of possible use-cases.
In this light, replacing "mail" as notification mechanism is a substantial functional regression in generality of deployment.
Ralf
On Jan 5, 2014, at 9:59 PM, Ralf Corsepius rc040203@freenet.de wrote:
In this light, replacing "mail" as notification mechanism is a substantial functional regression in generality of deployment.
It's obviously a matter of opinion, not fact, as evidenced by the lack of universal agreement by fairly reasonable people. I think email is such amazing piles of steaming poo that my happiness is inversely proportional to the number/rate of emails I'm getting. It simply does not scale well. And like the phone, it too easily confuses importance and urgency. Setting up mail rules requires duplicative effort, for each user, even when they have very similar ideas on notification prioritization. It's ickysauce.
Chris Murphy
On 01/06/2014 07:37 AM, Chris Murphy wrote:
It's obviously a matter of opinion, not fact, as evidenced by the lack of universal agreement by fairly reasonable people. I think email is such amazing piles of steaming poo that my happiness is inversely proportional to the number/rate of emails I'm getting. It simply does not scale well. And like the phone, it too easily confuses importance and urgency. Setting up mail rules requires duplicative effort, for each user, even when they have very similar ideas on notification prioritization. It's ickysauce.
That you despise mail is no reason to remove the MTA when applications actually rely on an existing MTA. You can not generalize your way of doing things to the entire community. The mail mechanics is there for a reason, and has proven its validity for decades.
Lars
On Mon, 06 Jan 2014 07:48:29 +0100 "Lars E. Pettersson" lars@homer.se wrote:
On 01/06/2014 07:37 AM, Chris Murphy wrote:
It's obviously a matter of opinion, not fact, as evidenced by the lack of universal agreement by fairly reasonable people. I think email is such amazing piles of steaming poo that my happiness is inversely proportional to the number/rate of emails I'm getting. It simply does not scale well. And like the phone, it too easily confuses importance and urgency. Setting up mail rules requires duplicative effort, for each user, even when they have very similar ideas on notification prioritization. It's ickysauce.
That you despise mail is no reason to remove the MTA when applications actually rely on an existing MTA. You can not generalize your way of doing things to the entire community. The mail mechanics is there for a reason, and has proven its validity for decades.
Lars
And moving notifications to Gnome? Does everyone use Gnome? Should i sit all the time behind the monitor? I don't. BR, Bob
Allegedly, on or about 06 January 2014, Bob Marcan sent:
And moving notifications to Gnome? Does everyone use Gnome? Should i sit all the time behind the monitor? I don't.
I think emailing this info is the best first default action. The system administrator may not be the person logged in at the moment some desktop alert pops up. The sysadmin mayn't even use that PC, they may be managing a whole office of PCs from one desk.
The root email can be delivered to anywhere that's appropriate. Leave desktop alerts to things that are (or should be) under the control of the current user, pertaining to their own settings, not the system.
On Mon, 06 Jan 2014 22:53:26 +1030 Tim ignored_mailbox@yahoo.com.au wrote:
I think emailing this info is the best first default action.
Subject: OfflineUncorrectableSector Date: Mon, 06 Jan 2014 07:58:48 +0000 User-Agent: Heirloom mailx 12.5 7/5/10
Device: /dev/sdc [SAT], 7 Offline uncorrectable sectors
Got no popup about this ;)
___ Regards, Frank www.frankly3d.com
On 01/05/2014 02:27 AM, Chris Murphy wrote:
On Jan 4, 2014, at 6:12 PM, Marko Vojinovic vvmarko@gmail.com wrote:
But since we are bashing around about unnecessary default services, one set of services that I would actually like to see removed is the NFS stack (nfs, nfslock, portmap, ...). Arguably, a typical desktop OS with a GUI has absolutely no need of networked file systems, especially as obsolete as NFS. I've used Fedora for as long as it exists, and I've never seen anyone actually use NFS in real life scenarios on a typical desktop machine with a GUI. That's also got to be in the 99% of cases…
This only means your usage scenarios are very limited. Actually, all my Linux systems have been using nfs ever since Linux supports it and ever since I am running/administrating networks.
NFSv4.1 is a two year old spec? It's quite current.
Correct, nfs is far from being dead or obsolete.
It's just that home-users with a Win-history commonly are not familiar with it and that using it takes a bit of a learning curve. Once it's set up it's very convienient, fast, reliable and useful.
Getting rid of all the NFSv3 junk by default I think is valid.
This would mean to lock out many professional use-cases and restrict Fedora-deployment to amateurish use-cases.
Ralf
On Jan 6, 2014 3:39 AM, "Bob Marcan" bob.marcan@gmail.com wrote:
On Mon, 06 Jan 2014 07:48:29 +0100 "Lars E. Pettersson" lars@homer.se wrote:
On 01/06/2014 07:37 AM, Chris Murphy wrote:
It's obviously a matter of opinion, not fact, as evidenced by the
lack of universal agreement by fairly reasonable people. I think email is such amazing piles of steaming poo that my happiness is inversely proportional to the number/rate of emails I'm getting. It simply does not scale well. And like the phone, it too easily confuses importance and urgency. Setting up mail rules requires duplicative effort, for each user, even when they have very similar ideas on notification prioritization. It's ickysauce.
That you despise mail is no reason to remove the MTA when applications
actually rely on an existing MTA. You can not generalize your way of doing things to the entire community. The mail mechanics is there for a reason, and has proven its validity for decades.
Lars
And moving notifications to Gnome? Does everyone use Gnome? Should i sit all the time behind the monitor? I don't. BR, Bob --
Libnotify works will all the DEs I've used, and there should be - if the DE is behaving properly - a way to make notifications persistent until acknowledged.
That said, I don't think that the few people passionately advocating a default MTA here have introduced anything that wasn't said in the Change proposal discussion. Isn't there a better use for all this energy?
--Pete
On Mon, Jan 6, 2014 at 6:37 AM, Chris Murphy lists@colorremedies.com wrote:
It's obviously a matter of opinion, not fact, as evidenced by the lack of universal agreement by fairly reasonable people. I think email is such amazing piles of steaming poo that my happiness is inversely proportional to the number/rate of emails I'm getting. It simply does not scale well.
This is rich, coming from someone that uses the steaming pile of crap that is gmail[1]. No wonder you have such a poor opinion of it. Email is proven and reliable and scales fantastically well. That you don't like it is incidental. As it happens, I'm OK with the removal of an MTA from the default install. It's really not something most users will need. However, in doing so, we *need* to be supplying something that works as a suitable alternative for the real world scenarios that have been mentioned. So far, I haven't seen any viable suggestions. "Use systemd instead of cron" doesn't cut it. Also, the whole world is not a single user desktop system. Sure, that may be the common case, and we need a reliable notification system for that case. But we need something that also works for my headless boxen and for my desktops that don't run GNOME (that'd be all of them).
FWIW, yes I also run NFS.
Tet
[1] Yes, I do appreciate the irony that I'm posting this from gmail. I'm at work, and we use it at work. I hate it, but it's what we have.
On Mon, 6 Jan 2014 11:37:26 -0700 Pete Travis lists@petetravis.com wrote:
Libnotify works will all the DEs I've used, and there should be - if the DE is behaving properly - a way to make notifications persistent until acknowledged.
That said, I don't think that the few people passionately advocating a default MTA here have introduced anything that wasn't said in the Change proposal discussion. Isn't there a better use for all this energy?
--Pete
What means behaving properly? Obeying your rules? And i don't use DE, i'm using fvwm Window Manager. The answer will probably be: use modern DE. DE with the ridiculous big icons, designed for touch screen. But i don't have one. I'm using workstation with keyboard and mouse. Keyboard as primary!
Am i too outdated? Probably yes. When i started, the memory was measured in KB, external storage in MB and power in KW.
As long i can install MTA and the applications will send notifications via email, it is o.k. for me. Otherwise i can use Windoze crap. It seems this is the way where all this heads to. Bob
On Mon, 06 Jan 2014 19:09:00 +0100 Ralf Corsepius rc040203@freenet.de wrote:
On 01/05/2014 02:27 AM, Chris Murphy wrote:
On Jan 4, 2014, at 6:12 PM, Marko Vojinovic vvmarko@gmail.com wrote:
But since we are bashing around about unnecessary default services, one set of services that I would actually like to see removed is the NFS stack (nfs, nfslock, portmap, ...). Arguably, a typical desktop OS with a GUI has absolutely no need of networked file systems, especially as obsolete as NFS. I've used Fedora for as long as it exists, and I've never seen anyone actually use NFS in real life scenarios on a typical desktop machine with a GUI. That's also got to be in the 99% of cases…
This only means your usage scenarios are very limited. Actually, all my Linux systems have been using nfs ever since Linux supports it and ever since I am running/administrating networks.
Ralf, apparently you missed the context here. :-) I was applying Chris' logic to something that is not an mta.
And to apply it further, I could argue that Fedora, being a typical desktop OS with a GUI, does not target network administrators as a default audience. When people complained about the absence of mta in the default install, Chris answers "just do a yum install your-favorite-mta and be happy". So an analogous answer to you would be "just yum install the-nfs-stack and be happy".
The point of my comment was to demonstrate that removing the mta is as absurd as removing the nfs, sshd, or whatever other service. Devs should not drop stuff out of the default install only on the basis of some imaginary target audience. There will always be a target group of people who rely on precisely that piece of functionality, and are used to the fact that it is installed by default. The issues raised about mta, nfs, sshd, etc. are only examples of this.
Your response wrt. nfs actually proves my point: unless there is an obvious functionality benefit, don't break people's habits --- keep the default as it was.
Best, :-) Marko
On Jan 6, 2014 12:36 PM, "Bob Marcan" bob.marcan@gmail.com wrote:
On Mon, 6 Jan 2014 11:37:26 -0700 Pete Travis lists@petetravis.com wrote:
Libnotify works will all the DEs I've used, and there should be - if
the DE
is behaving properly - a way to make notifications persistent until acknowledged.
That said, I don't think that the few people passionately advocating a default MTA here have introduced anything that wasn't said in the Change proposal discussion. Isn't there a better use for all this energy?
--Pete
What means behaving properly? Obeying your rules? And i don't use DE, i'm using fvwm Window Manager. The answer will probably be: use modern DE. DE with the ridiculous big icons, designed for touch screen. But i don't have one. I'm using workstation with keyboard and mouse. Keyboard as primary!
Am i too outdated? Probably yes. When i started, the memory was measured in KB, external storage in MB and power in KW.
As long i can install MTA and the applications will send notifications via email, it is o.k. for me. Otherwise i can use Windoze crap. It seems this is the way where all this heads to. Bob --
"Behaving properly" in this context means that the desktop notification system should retain critical priority messages until acknowledged. I don't know how your window manager behaves - you can test it from the command line with `notify-send`.
I'm pointing out that desktop notifications need not be specific to any DE. I am not claiming this is the ideal and preferred method for all applications to communicate with users for all use cases. I'm not even claiming to know how all use cases deal with libnotify.
I can say with some confidence that if a background process has an important message, the user is more likely to receive the message if they are sent a persistent desktop notification. An MTA installed by default or not does not affect this premise.
Is someone intending to drive a Change proposal to include an MTA in the default offering? If not, what exactly do you expect to gain from a debate on the user support list?
--Pete
On Jan 6, 2014, at 11:09 AM, Ralf Corsepius rc040203@freenet.de wrote:
Getting rid of all the NFSv3 junk by default I think is valid.
This would mean to lock out many professional use-cases and restrict Fedora-deployment to amateurish use-cases.
Right, amateurish cases like pNFS and something that's actually scalable.
The NFSv3 stuff isn't maintained anymore anyway. So it should just go away. I think there's been a proposal to do that. At least in my case, there's no rpnbind statd or lockd running, so it must be at least NFSv4 by default.
Chris Murphy
On Jan 6, 2014, at 11:37 AM, Pete Travis lists@petetravis.com wrote:
Isn't there a better use for all this energy?
Yes if they want to keep crying about it, throw a formal wake. At least there'd be booze.
Chris Murphy
On 01/06/2014 10:37 AM, Pete Travis wrote:
That said, I don't think that the few people passionately advocating a default MTA here have introduced anything that wasn't said in the Change proposal discussion. Isn't there a better use for all this energy?
Sorry for replying so late, but I've been sick the last few days. If I'd been asked during the discussion, I'd probably have suggested that anaconda ask if you want an MTA installed, with a comment that if you don't know what one is, you probably don't need it. And, of course, defaulting to NO. Too late now, of course.
On Tue, 07 Jan 2014 12:58:41 -0800 Joe Zeff joe@zeff.us wrote:
On 01/06/2014 10:37 AM, Pete Travis wrote:
That said, I don't think that the few people passionately advocating a default MTA here have introduced anything that wasn't said in the Change proposal discussion. Isn't there a better use for all this energy?
Sorry for replying so late, but I've been sick the last few days. If I'd been asked during the discussion, I'd probably have suggested that anaconda ask if you want an MTA installed, with a comment that if you don't know what one is, you probably don't need it. And, of course, defaulting to NO. Too late now, of course.
It is not a problem how and when the MTA is installed. It was announced in release notes. I'm afraid where this all is heading. Which rug will be pulled out from my feet next time? Linux is NOT a desktop, it is ALSO desktop. BR, Bob
Hi
On Tue, Jan 7, 2014 at 4:23 PM, Bob Marcan wrote:
It is not a problem how and when the MTA is installed. It was announced in release notes. I'm afraid where this all is heading. Which rug will be pulled out from my feet next time? Linux is NOT a desktop, it is ALSO desktop.
Well, this change was only done for the DESKTOP live image. So complaining that it might affect non-desktop users is missing the mark.
Rahul
On 01/07/2014 12:14 AM, Chris Murphy wrote:
On Jan 6, 2014, at 11:09 AM, Ralf Corsepius rc040203@freenet.de wrote:
Getting rid of all the NFSv3 junk by default I think is valid.
This would mean to lock out many professional use-cases and restrict Fedora-deployment to amateurish use-cases.
Right, amateurish cases like pNFS and something that's actually scalable.
The NFSv3 stuff isn't maintained anymore anyway. So it should just go away.
Says who? Isn't maintained as part of the Linux kernel or isn't maintained as part of RH-based distros?
As long as there exist nfs-servers, which do not support nfs > 3, Linux will have to continue supporting nfsv3. And if RH/Fedora doesn't want to loose users, they also will have to continue supporting it.
Ralf
-
Andre Robatino -
Bob Marcan -
Bruno Wolff III -
Chris Adams -
Chris Murphy -
CS DBA -
David Beveridge -
David G. Miller (aka DaveAtFraud) -
Ed Greshko -
Frank Murphy -
Heinz Diehl -
Joe Zeff -
Joonas Sarajärvi -
Kevin Fenzi -
Lars E. Pettersson -
Mark C. Allman -
Marko Vojinovic -
Matthew Miller -
Pete Travis -
Rahul Sundaram -
Ralf Corsepius -
Robert Moskowitz -
Suvayu Ali -
Tethys -
Tim -
Tom H -
Tom Horsley