Here at NetApp, we're planning some changes in the way messages are implemented, to provide more specific information (e.g. unique message id's, to identify exactly where messages are coming from), handle things like internationalization, and make it easier to post-process messages.
We'd like to know how many people currently have scripts to process the /etc/messages file (and/or any other destinations of syslog or console output). If you would be affected by any changes to the format of /etc/messages or console output, please send me email, so we can take your input into account. Thanks much.
...Tim Thompson...Network Appliance, Inc...tjt@netapp.com...
In message 199805150058.RAA24595@tooting.netapp.com, Tim Thompson writes:
Here at NetApp, we're planning some changes in the way messages are implemented, to provide more specific information (e.g. unique message id's, to identify exactly where messages are coming from), handle things like internationalization, and make it easier to post-process messages.
We'd like to know how many people currently have scripts to process the /etc/messages file (and/or any other destinations of syslog or console outp ut). If you would be affected by any changes to the format of /etc/messages or console output, please send me email, so we can take your input into account. Thanks much.
...Tim Thompson...Network Appliance, Inc...tjt@netapp.com...
We currently use logsurfer and swatch to parse syslog messages generated by our F330. We also use procmail to forward "critical" email from the filer to alpha-pagers.
Any changes you make to the messages would most likely be inconvenient for one reason. There isn't an appendix which contains a _complete_ list of all error messages and sample _syntax_ in the filer documentation. Tech Support couldn't even get me a list of all the possible email subject headers the filer might send in case of error! (I ended up pulling all the strings out of the OnTap kernel just to guess that important messages end in "!!!".) What all this boils down to is that we were unable to proactively look for problems until _after_ we had encountered them... Not a Good Thing(tm).
So, I'm all for more specific messages -- as long as they are documented. Please.
jason
--- Jason D. Kelleher kelleher@susq.com Susquehanna Investment Group 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122
P.S. You might want to take a look at the Raptor Firewall documentation. Although it completely glosses over configuration and maintenance of the firewall, it's treatment of error messages is pretty good. The messages all follow a standard format which makes them ideal for processing with procmail.