12:24 p.m.
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.
9:24 p.m.
On 01/07/2014 12:14 AM, Chris Murphy wrote:
On Jan 6, 2014, at 11:09 AM, Ralf Corsepius <rc040203(a)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
2:25 a.m.
On Sun, 5 Jan 2014 01:12:40 +0000
Marko Vojinovic <vvmarko(a)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
3:58 p.m.
On Jan 6, 2014 12:36 PM, "Bob Marcan" <bob.marcan(a)gmail.com> wrote:
On Mon, 6 Jan 2014 11:37:26 -0700
Pete Travis <lists(a)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
3:19 p.m.
On Mon, 06 Jan 2014 19:09:00 +0100
Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 01/05/2014 02:27 AM, Chris Murphy wrote:
>
> On Jan 4, 2014, at 6:12 PM, Marko Vojinovic <vvmarko(a)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
1:28 p.m.
On Mon, Jan 6, 2014 at 6:37 AM, Chris Murphy <lists(a)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.
--
"Java is a DSL for taking large XML files and converting them to stack
traces" -- Bulat Shakirzyanov
12:37 p.m.
On Jan 6, 2014 3:39 AM, "Bob Marcan" <bob.marcan(a)gmail.com> wrote:
On Mon, 06 Jan 2014 07:48:29 +0100
"Lars E. Pettersson" <lars(a)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
6:29 a.m.
On Mon, 06 Jan 2014 22:53:26 +1030
Tim <ignored_mailbox(a)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
6:23 a.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
4:39 a.m.
On Mon, 06 Jan 2014 07:48:29 +0100
"Lars E. Pettersson" <lars(a)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
12:48 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
10:59 p.m.
On 01/05/2014 11:50 PM, Chris Murphy wrote:
On Jan 5, 2014, at 2:31 AM, Ralf Corsepius <rc040203(a)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
7:17 p.m.
On Jan 4, 2014, at 2:47 PM, Andre Robatino <robatino(a)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/not...
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
7:12 p.m.
On Sat, 4 Jan 2014 13:45:34 -0700
Chris Murphy <lists(a)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
7:20 a.m.
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?
1. 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.
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>.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:41 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:13 p.m.
On Jan 3, 2014, at 6:41 PM, "Lars E. Pettersson" <lars(a)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
7:30 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:21 p.m.
On Jan 3, 2014, at 12:32 PM, Tom H <tomh0665(a)gmail.com> wrote:
On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson
<lars(a)homer.se> wrote:
> On 01/03/2014 12:01 AM, Rahul Sundaram wrote:
>>
>>
https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendma...
>
> 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
5:26 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:45 p.m.
New subject: Fedora 20 install - can I revert to the old installer?
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
2:31 p.m.
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(a)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?
--
Suvayu
Open source is the future. It sets us free.
6:44 a.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
6:11 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
5:35 a.m.
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
5:36 a.m.
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...:
[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(a)gmal.com
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
5:27 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
5:10 a.m.
On 01/03/2014 12:01 AM, Rahul Sundaram 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.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
9:05 p.m.
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(a)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,
--
Suvayu
Open source is the future. It sets us free.
9:01 p.m.
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(a)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,
--
Suvayu
Open source is the future. It sets us free.
7:51 p.m.
On Thu, Jan 2, 2014 at 11:56 PM, Chris Murphy <lists(a)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...
5:56 p.m.
On Jan 2, 2014, at 3:42 PM, "Lars E. Pettersson" <lars(a)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
5:48 p.m.
On Jan 2, 2014, at 2:32 PM, Lars E. Pettersson <lars(a)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
1:32 p.m.
On Jan 2, 2014 12:26 PM, "Lars E. Pettersson" <lars(a)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(a)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
5:01 p.m.
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_Sendma...
"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
1:26 p.m.
On 01/02/2014 08:09 PM, Chris Murphy wrote:
On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson"
<lars(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
4:03 p.m.
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.
12:52 p.m.
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson <lars(a)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
2:37 p.m.
On Jan 2, 2014, at 1:03 PM, "Lars E. Pettersson" <lars(a)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
2:32 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:29 p.m.
On Jan 2, 2014, at 12:55 PM, "Lars E. Pettersson" <lars(a)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
1:31 p.m.
On Jan 2, 2014, at 12:09 PM, "Lars E. Pettersson" <lars(a)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(a)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
12:49 p.m.
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.
--
Mark C. Allman, PMP, CSM
12:30 p.m.
On Jan 2, 2014, at 3:54 AM, Suvayu Ali <fatkasuvayu+linux(a)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
7:03 a.m.
On 01/02/2014 04:13 AM, Frank Murphy wrote:
On Wed, 1 Jan 2014 20:40:35 -0700
Chris Murphy <lists(a)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.
4:58 a.m.
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.
--
Suvayu
Open source is the future. It sets us free.
4:54 a.m.
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(a)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.
--
Suvayu
Open source is the future. It sets us free.
3:13 a.m.
On Wed, 1 Jan 2014 20:40:35 -0700
Chris Murphy <lists(a)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
9:59 p.m.
On Jan 1, 2014, at 8:40 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Jan 1, 2014, at 6:17 PM, Rahul Sundaram <metherid(a)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
9:55 p.m.
On Jan 1, 2014, at 7:39 PM, Suvayu Ali <fatkasuvayu+linux(a)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
9:40 p.m.
On Jan 1, 2014, at 6:17 PM, Rahul Sundaram <metherid(a)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
8:39 p.m.
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?
--
Suvayu
Open source is the future. It sets us free.
7:31 p.m.
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
8:31 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:08 p.m.
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
8:03 p.m.
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
8:03 p.m.
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 system
Bad example. Non technical users don't install yum-cron.
Why not? The might...
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:25 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:57 p.m.
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.
7:55 p.m.
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
7:51 p.m.
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...:
[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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:08 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:01 p.m.
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.
7:01 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7 p.m.
Hi
On Wed, Jan 1, 2014 at 7:12 PM, Lars E. Pettersson <lars(a)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
6:51 p.m.
Hi
On Wed, Jan 1, 2014 at 7:48 PM, Lars E. Pettersson <lars(a)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(a)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
6:26 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
5:28 p.m.
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(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
5:21 p.m.
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,
--
Suvayu
Open source is the future. It sets us free.
4:30 p.m.
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
3:47 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
3:19 p.m.
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
5:21 a.m.
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.
5:40 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
3:49 p.m.
2013/12/31 Joe Zeff <joe(a)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
3:04 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
12:58 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
11:55 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
11:05 a.m.
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(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:14 p.m.
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.
--
Suvayu
Open source is the future. It sets us free.
9:03 p.m.
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(a)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,
--
Suvayu
Open source is the future. It sets us free.
8:45 p.m.
On Tue, 31 Dec 2013 02:27:06 +0000
Frank Murphy <frankly3d(a)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
--
Regards,
Frank
www.frankly3d.com
8:27 p.m.
On Tue, 31 Dec 2013 01:46:07 +0100
Suvayu Ali <fatkasuvayu+linux(a)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.
--
Regards,
Frank
www.frankly3d.com
1:38 p.m.
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).
1:29 p.m.
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
1:23 p.m.
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?
--
Getting tired of non-Fedora discussions and self-serving posts
1:20 p.m.
On Mon, Dec 30, 2013 at 14:00:50 -0500,
Robert Moskowitz <rgm(a)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.
1 p.m.
On 12/30/2013 01:29 PM, Bruno Wolff III wrote:
On Mon, Dec 30, 2013 at 13:24:07 -0500,
Robert Moskowitz <rgm(a)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.
12:34 p.m.
On Mon, 30 Dec 2013 13:24:07 -0500
Robert Moskowitz <rgm(a)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
12:29 p.m.
On Mon, Dec 30, 2013 at 13:24:07 -0500,
Robert Moskowitz <rgm(a)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.
12:09 p.m.
On 01/05/2014 02:27 AM, Chris Murphy wrote:
On Jan 4, 2014, at 6:12 PM, Marko Vojinovic <vvmarko(a)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
7:59 p.m.
On Jan 3, 2014, at 6:40 PM, Suvayu Ali <fatkasuvayu+linux(a)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
7:54 p.m.
On Jan 3, 2014, at 6:30 PM, "Lars E. Pettersson" <lars(a)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
7:40 p.m.
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?
--
Suvayu
Open source is the future. It sets us free.
7:32 p.m.
On Jan 3, 2014, at 1:31 PM, Suvayu Ali <fatkasuvayu+linux(a)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(a)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
7:10 p.m.
On Jan 3, 2014, at 12:27 PM, Tom H <tomh0665(a)gmail.com> wrote:
On Fri, Jan 3, 2014 at 3:05 AM, Suvayu Ali
<fatkasuvayu+linux(a)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
9:33 p.m.
New subject: systemd-journald, was: Unintended consequences of no default MTA - How best to fix
On Jan 1, 2014, at 2:47 PM, Lars E. Pettersson <lars(a)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
11:49 a.m.
On Tue, Dec 31, 2013 at 18:05:05 +0100,
"Lars E. Pettersson" <lars(a)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.
7:47 p.m.
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
7:39 p.m.
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.
1:49 a.m.
On Fri, 3 Jan 2014 16:17:43 -0700
Pete Travis <lists(a)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
3:24 a.m.
On Thu, 02 Jan 2014 21:50:51 +0100
"Lars E. Pettersson" <lars(a)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
12:56 p.m.
On 12/30/2013 01:34 PM, Kevin Fenzi wrote:
On Mon, 30 Dec 2013 13:24:07 -0500
Robert Moskowitz <rgm(a)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.
1:20 p.m.
Once upon a time, Robert Moskowitz <rgm(a)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(a)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.
--
Chris Adams <linux(a)cmadams.net>
1:31 p.m.
On 12/30/2013 02:20 PM, Chris Adams wrote:
Once upon a time, Robert Moskowitz <rgm(a)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(a)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.
7:06 p.m.
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(a)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(a)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.
5:51 a.m.
On Tue, 31 Dec 2013 10:50:46 +0800
Ed Greshko <Ed.Greshko(a)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
--
Regards,
Frank
www.frankly3d.com
3:20 p.m.
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/msg000...
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
4:39 p.m.
On Mon, Dec 30, 2013 at 6:24 PM, Robert Moskowitz <rgm(a)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.
3:49 p.m.
Hi
On Tue, Dec 31, 2013 at 4:36 PM, Joe Zeff <joe(a)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
3:36 p.m.
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.
3:26 a.m.
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..
10:46 p.m.
On 12/31/2013 11:10 PM, David Beveridge wrote:
On Wed, Jan 1, 2014 at 1:13 AM, Heinz Diehl <htd(a)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.
10:10 p.m.
On Wed, Jan 1, 2014 at 1:13 AM, Heinz Diehl <htd(a)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.
8:16 p.m.
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
1:09 p.m.
On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson" <lars(a)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
1:49 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:45 p.m.
On Jan 2, 2014, at 12:35 PM, "Lars E. Pettersson" <lars(a)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
2:24 p.m.
On Jan 2, 2014, at 12:49 PM, "Lars E. Pettersson" <lars(a)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
10:07 p.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSxjeBAAoJEL1wZM0+jj2Z3XAH/RluryvmhmIetfJD3TuguTW4
f7FwPpgc75ae92gBEMi+4QnHsicUEPFq5m4gfleoCTyAaQ8kcMpUmJQffApur773
HzIPxsN+rvTEyTWCWu269crkOeBFhig0L0n7/M6OqDo8dAl7QdGPgzg1650T2YT6
w57FXF1PEJPJ5Bzvd7vcYi269/l14iTKVTOxe4AuQj1GyjUlNHq3P1yjdBL9KRSS
QRoMFp151iwtcm8AaRPSeHa3Xvy5BaPKDaU5flzDuw1u3qLvxNI7U8MJVjH3tArb
0GLYTEVM5HAoqNdtb2x139J983F7GTYauFQBTm7OtRXL04OGuEXd4TjdLPOYgZQ=
=iPBF
-----END PGP SIGNATURE-----
5:08 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
11:31 a.m.
On Jan 3, 2014 4:08 AM, "Lars E. Pettersson" <lars(a)homer.se> wrote:
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=0557929cbde247928f945d8b53a6e067
> 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 .
>> $ 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 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.
2:16 p.m.
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,
--
Suvayu
Open source is the future. It sets us free.
1:49 p.m.
New subject: Fedora 20 install - can I revert to the old installer?
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
2:56 p.m.
On Jan 3, 2014 1:16 PM, "Suvayu Ali" <fatkasuvayu+linux(a)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=0557929cbde247928f945d8b53a6e067
How 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
5:12 p.m.
On 01/03/2014 06:31 PM, Pete Travis wrote:
On Jan 3, 2014 4:08 AM, "Lars E. Pettersson"
<lars(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:35 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:12 a.m.
On 01/04/2014 03:13 AM, Chris Murphy wrote:
On Jan 3, 2014, at 6:41 PM, "Lars E. Pettersson" <lars(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:45 p.m.
On Jan 3, 2014, at 11:24 PM, David G. Miller <dave(a)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
3:47 p.m.
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.
1 p.m.
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
6:06 p.m.
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
5:32 p.m.
On 01/03/2014 08:32 PM, Tom H wrote:
On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson
<lars(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
6:46 p.m.
On Fri, Jan 03, 2014 at 01:56:33PM -0700, Pete Travis wrote:
On Jan 3, 2014 1:16 PM, "Suvayu Ali"
<fatkasuvayu+linux(a)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=0557929cbde247928f945d8b53a6e067
>
> How 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!
:)
--
Suvayu
Open source is the future. It sets us free.
3:23 p.m.
On Tue, 07 Jan 2014 12:58:41 -0800
Joe Zeff <joe(a)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
2:58 p.m.
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.
4:42 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
4:31 p.m.
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
3:32 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
3:08 p.m.
On Jan 2, 2014, at 1:50 PM, "Lars E. Pettersson" <lars(a)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
2:50 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:49 p.m.
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
2:45 p.m.
On Jan 2, 2014, at 1:32 PM, "Lars E. Pettersson" <lars(a)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
2:03 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2 p.m.
On 01/02/2014 02:31 PM, Chris Murphy wrote:
On Jan 2, 2014, at 12:09 PM, "Lars E. Pettersson"
<lars(a)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(a)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.
1:55 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:53 p.m.
On 01/02/2014 01:52 PM, Chris Murphy wrote:
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson <lars(a)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.
1:37 p.m.
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
11:27 a.m.
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
11:15 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:32 p.m.
On Fri, Jan 3, 2014 at 11:10 AM, Lars E. Pettersson <lars(a)homer.se> wrote:
On 01/03/2014 12:01 AM, Rahul Sundaram wrote:
>
>
https://fedoraproject.org/wiki/F20_release_announcement#No_Default_Sendma...
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.
1:27 p.m.
On Fri, Jan 3, 2014 at 3:05 AM, Suvayu Ali <fatkasuvayu+linux(a)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.
12:28 p.m.
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
12:14 p.m.
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,
--
Suvayu
Open source is the future. It sets us free.
1:45 p.m.
On Jan 2, 2014, at 12:26 PM, "Lars E. Pettersson" <lars(a)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(a)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
1:35 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:09 p.m.
On 01/02/2014 07:52 PM, Chris Murphy wrote:
On Jan 2, 2014, at 5:34 AM, Lars E. Pettersson <lars(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
12:48 p.m.
On 01/02/2014 01:30 PM, Chris Murphy wrote:
On Jan 2, 2014, at 3:54 AM, Suvayu Ali
<fatkasuvayu+linux(a)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.
12:45 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
9:12 p.m.
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,
:)
--
Suvayu
Open source is the future. It sets us free.
9:04 p.m.
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>
--
Getting tired of non-Fedora discussions and self-serving posts
6:46 p.m.
Hi Chris,
On Mon, Dec 30, 2013 at 01:20:04PM -0600, Chris Adams wrote:
Once upon a time, Robert Moskowitz <rgm(a)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(a)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,
--
Suvayu
Open source is the future. It sets us free.
6:50 a.m.
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.
6:34 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
6:26 a.m.
New subject: systemd-journald, was: Unintended consequences of no default MTA - How best to fix
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:32 a.m.
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.
--
Suvayu
Open source is the future. It sets us free.
5:57 a.m.
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
5:49 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
9:07 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:48 p.m.
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,
--
Suvayu
Open source is the future. It sets us free.
8:41 p.m.
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
8:29 p.m.
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
8:25 p.m.
HI
On Wed, Jan 1, 2014 at 9:17 PM, Joe Zeff <joe(a)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
8:25 p.m.
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.
8:20 p.m.
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
8:17 p.m.
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?
7:17 p.m.
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
8:14 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:21 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:19 p.m.
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.
--
Matthew Miller -- Fedora Project Architect -- <mattdm(a)fedoraproject.org>
5:14 p.m.
On Jan 6, 2014, at 11:09 AM, Ralf Corsepius <rc040203(a)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
6:48 p.m.
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(a)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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
6:12 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
6:05 p.m.
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
2:40 p.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:36 p.m.
On Mon, 6 Jan 2014 11:37:26 -0700
Pete Travis <lists(a)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
12:37 a.m.
On Jan 5, 2014, at 9:59 PM, Ralf Corsepius <rc040203(a)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
7:27 p.m.
On Jan 4, 2014, at 6:12 PM, Marko Vojinovic <vvmarko(a)gmail.com> wrote:
On Sat, 4 Jan 2014 13:45:34 -0700
Chris Murphy <lists(a)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
4:50 p.m.
On Jan 5, 2014, at 2:31 AM, Ralf Corsepius <rc040203(a)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
5:17 p.m.
On Jan 3, 2014 4:12 PM, "Lars E. Pettersson" <lars(a)homer.se> wrote:
On 01/03/2014 06:31 PM, Pete Travis wrote:
>
> On Jan 3, 2014 4:08 AM, "Lars E. Pettersson" <lars(a)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
6:59 a.m.
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.
12:40 p.m.
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".
3:42 a.m.
On Sun, 05 Jan 2014 10:19:52 +0100
"Lars E. Pettersson" <lars(a)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
3:31 a.m.
On 01/04/2014 09:45 PM, Chris Murphy wrote:
On Jan 3, 2014, at 11:24 PM, David G. Miller <dave(a)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.
3:19 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
3:15 a.m.
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
12:24 a.m.
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
3:50 p.m.
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/msg000...
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
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:50 p.m.
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.
--
Getting tired of non-Fedora discussions and self-serving posts
2:58 a.m.
On 01/04/2014 03:13 AM, Chris Murphy wrote:
On Jan 3, 2014, at 6:41 PM, "Lars E. Pettersson" <lars(a)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+.
3797
days inactive
3806
days old
202 comments
27 participants
participants (27)
-
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