I think you are missing a very simply idea.
FreeNAS can't (and in my opinion shouldn't) differentiate between "normal feedback" and "sh*t be is broken yo!"
The OSes job is not to interpret information and feed that back to you but to simply report what it knows. It's your job as the administrator to decide *if* its important or not and *if* you should even take any actions.
I don't think I'm missing anything. I agree that it's an administrator's responsibility to know what's going on. Based upon your "Feature #2070" comments, it's clear that you didn't agree with the idea of limiting the type of outgoing emails sent by the system, in spite of the overwhelming end user demand. But you did offer the very good idea of offering checkboxes for enabling/disabling emails.
It looks like the developers decided to change the way system emails work, but didn't give the user any choice about configuring the system in this regard. The user never got the option of choosing the old way or the new way, the system just does what the developer wants, which may or may not be what an administrator wants.
No offense intended, but I think that the implemented changes and some of the comments made in this thread could be interpreted as being a bit patronizing and perhaps a bit contradictory. FreeNAS is already interpreting information and making decisions in the administrator's absence -- the OS is already reviewing the information and interpreting it, and filtering the information that is going out to the admin, and the admin isn't given any options regarding the level of email traffic that goes out.
As an example, the OS already:
1) interprets the status messages and assigns color-coded warning/threat levels on the system -- ie: it's already making threat-level interpretations and makes decisions based upon those interpretations;
2) interprets that the nightly status emails should not be sent, regardless of whether the admin wants to see them or not. This effectively forces the administrator into hoping that no news is good news. Clearly, that's not a good solution -- with the current implementation the administrator has no way of knowing that the email system is still functioning properly in the absence of email delivery. With the current implementation the admin now has to jump through hoops to confirm that the system functionality has not been interrupted.
... you *should* be looking through that. If there are any errors that require action on your part that is how you are going to know. We all know you didn't watch the bootup as it scrolled text off the screen faster than you could see it. ;)
It's probably not a good idea to make assumptions that nobody looks at their logs, or to make assumptions about whether or not a user tracks the boot-up sequence. In my neck of the woods, most computers are headless. It's hard to watch headless servers boot in real-time, as not all machines have fold-out displays in the rack and IPKVM connections. Sometimes it's necessary to grep the dmesg output to monitor boot status. I probably do that more than most people.
I don't know that email notifications have ever been "more configurable" than they currently are. It's very basic and there's really not much more to add to it unless you plan to write us code that is a heuristic system for identifying what should be high priority and what is just informational.
Maybe I am missing something simple, but I don't see how email configuration is any more configurable now than it was before. The only thing that I've noticed is that the system has stopped sending nightly emails after the upgrade, which I'm not sure is such a great idea, for reasons stated previously -- I have no way of knowing that failure to receive an email is not a false negative result.
Granted, not everyone wants to deal with the low signal to noise ratio that came with the previous email configuration, so many people have asked for fewer emails, and the developers responded by making a change, while not offering the user any choices in this regard. At least if there are choices that can be made, I haven't been able to find them.
If the user is able to configure the choice of old-style email vs. new-style email, I'd like to know how to make that selection. Insofar as the system currently allows the administrator to send email output to multiple email addresses, and the system already makes decisions about threat levels, it would make sense to direct emails to selected locations based upon their content. It certainly would be worth putting a text through to my phone if the server went offline, though it wouldn't be worth interrupting a meeting to tell me that a scrub was started on-schedule. To me, it would make sense to direct most of the emails to my desktop, and to direct critical level emails to my phone. The system already assesses some events as "critical" by putting that text string in message headers.
I guess that the answer is that the functionality that I'm looking for doesn't exist in the web GUI, and that any solution to my "problem" is going to have to be performed under the hood.
By now it might seem obvious that "yo shit is broken" and "Unless you plan to write us code" were not the types of responses that I was expecting to hear. I merely asked if I was looking in the right place or the wrong place for the information. I guess the answer is that I am looking in the wrong place.
