RE: Question Re: Piping and Redirection

On Wed, 20 Nov 2002, Goodbar, Loyd (AFS-Water Valley) wrote:

> Unix messages can have a "severity level", but not in the OS/400 sense.
> There are levels such as "debug", "info", "crit", "kernel", etc. But these
> levels are processed by the syslog daemon to determine which messages should
> be sent to a log file (for example, /var/log/messages). I believe the
> message level is part of the text in the log file. If you're using syslog,
> you can flag certain messages to interrupt the terminal; I think "crit"
> messages do this. However, I don't think unix log files + tail + syslog has
> the same flexibility and power as OS/400 message files with break mode,
> break handling programs, rcvmsg, etc. It's just a different animal.

It doesn't have the same flexibilty - it has more :)  (don't get upset,
more flexibility != better - though I like it a lot)

Let's confine ourselves to the case of using tail to monitor system
logs.  Suppose you want to monitor all incoming telnet attempts.  You
would use:

tail -f /var/log/messages | grep "telnetd"

That could be a lot of stuff.  You could probably do a similar thing on
the AS/400 by watching the TCP logs.  But now you are only interested in
incoming telnet attempts that do not originate from a certain IP (say you
are watching for someone trying to break into your system).  You could
use:

tail -f /var/log/messages | grep "telnetd" | grep -v "xxx.xxx.xxx.xxx"

where xxx.xxx.xxx.xxx is the IP address you are not interested in
monitoring.  As you can see this can be very flexible.

> The tail command does automatically refresh the screen (new entries are at
> the bottom of the screen), which I do like over dsppfm, dspmsg. I use a
> secure shell program in Windows to monitor my unix box's activities, the
> advantage here is if messages are occurring faster than I can read them,
> then I can simply use the scroll bar to view previous messages.

Or you can use this:

tail -f /var/log/messages | less

and let the "less" paginator handle things.

> Two big problems with both OS/400 and /var/log/messages, in my view, are
> 1) you cannot selectively "clear" messages from the queue. Here, I'm talking
> about wrkmsg qsysopr, then remove all printer alignment messages, or all
> jobs at workstation X ended messages. This is different from having critical
> messages in qsysmsg; I'd want to clear the "fluff" from qsysopr. Same is
> true for /var/log/messages.
> 2) Both of these are cleared on IPL/bootup. If you had an abnormal
> powerdown, you don't see anything prior to the IPL message or initial boot
> message. Again, I'm talking about message queues, not the wrkhst command.

Well, clearing the log files may happen on whatever distribution you are
using, but it certainly doesn't happen on mine.  It is a security issue.
If an attacker wants to hide his tracks he just has to restart the machine
to erase them.  For a long time my logs just grew and grew.  Now I use
logrotate on them to break them up into manageable sizes and dump old,
unneeded logs.

> I think the monitoring capabilities are better for OS/400 (we like Messenger
> Plus), since the messages are standardized, and contain "metadata" that
> shouldn't change between releases. Unix message files can contain any
> message format, where it is up to the program to interpret the message "in
> stream". OS/400 is better, with substitution variables, message data,
> severity levels, and message identifiers.

Unix certainly does have substitution variables, but not the same way as
OS/400.  It does this using something like:

printf ("This is the error message for error number %d.\n", error_num);

Of course what unix doesn't have is the ability to press help on the
message.  Whether or not this is really a problem is debateable.

James Rich