Cross-Platform Event Reporting

Joe Aguiar

It is relatively common these days for systems administrators to be responsible for the management of multiple dissimilar platforms. A mix of UNIX and Windows NT is probably one of the most common scenarios. It would be nice if all operating systems used a standard method of reporting system errors and events, but this is not the case. Windows NT uses the Event Log service and UNIX uses the syslog service. Each system uses a disk file repository to keep the information, however this is just about where the similarity ends. The data file formats are completely different (the UNIX syslog using a simple text file, easily readable, while the NT Event Log uses a binary format data file similar to the UNIX utmp file).

This article addresses some alternatives for integrating the two systems using free software tools written in Perl so that reporting can be centralized and analysis can be accomplished more easily and at a lower cost.

Alternatives

Whether your mixed environment is predominantly UNIX or Windows NT, it might be desirable to run your management software on a single platform of your choice. This would save time spent learning how to use tools to do the same thing on multiple platforms, as well as reduce licensing costs of what would likely be tools from multiple vendors (and multiple support contracts). Perhaps you just want to be able to check one, or a small number of designated management hosts manually. In any case, there are at least two alternatives that could help satisfy this need: send the UNIX syslog events to the Windows NT Event Log, or send the Windows NT Event Log entries to the UNIX syslog. These alternatives are discussed below.

Event Log to syslog

There could be a number of reasons for taking the approach of forwarding Event Log entries to a UNIX syslog server. Perhaps your site is predominantly UNIX, or perhaps you have invested time and money into a software product that does event management from UNIX. Whatever the reason, there is a freely available tool that my site, for example, uses to help accomplish this goal. It is called evtfwdd. It is a Perl script that will forward new Event Log entries to a UNIX syslog server at a specified syslog priority.

The NT Event Log provides a number of data members in each record that are suitable for sorting. The evtfwdd tool, using a configuration file, allows the user to sort messages according to five pieces of data: Event Type, Source, Category, EventID, and Computer Name. All of these fields may use regular expressions to obtain matches. The most interesting field is probably the Event Type. NT supports at least five different types:

EVENTLOG_INFORMATION_TYPE
EVENTLOG_WARNING_TYPE
EVENTLOG_ERROR_TYPE
EVENTLOG_AUDIT_SUCCESS
EVENTLOG_AUDIT_FAILURE

The meaning of each of these is implied by its name; however, the Win32 Perl Programming book [1] gives a short explanation of each. The next most interesting field to sort on is Source, which is like the “tag” portion of the syslog message format and often refers to the application that generated the message. It is unclear to me how NT actually uses Category or EventID, however, evtfwdd will let you sort on these fields, too. The way evtfwdd does its sorting is controlled by the evtfwd.con configuration file (Figure 1).

The entries above will cause evtfwdd to forward new data in the Event Log to the host “tweedle”, dependent upon the Type field. If the Event Log entry is of EVENTLOG_INFORMATION_TYPE, the message will be forwarded to the syslogd on host tweedle at priority 14. This corresponds to the syslog user.info priority. The EVENTLOG_WARNING_TYPE entries will go with priority 12, which is user.warn. Priority 11 is user.err, and 38 and 36 are auth.info and auth.warn, respectively.

It is easy to calculate the priority entries (under Solaris, the calctool in logical mode works well). Look at the syslog.h file on any UNIX box, find the number corresponding to the facility, left shift three, then OR the number corresponding to the level. There is also a tool called xlatepri.pl that comes with the evtfwdd package that will convert UNIX syslog priority string to an integer. The priority may be expressed as a string, such as user.info, or as an integer in the configuration file.

The other fields shown above (Category, Event ID, etc.) are represented here by regular expression character classes. The ‘‘+’’ means one or more occurrence of any of these characters. To run evtfwdd, use the following command:

perl -w evtfwdd --conf /etc/evtfwd.con  \
  --port 514 -debug

Actually, /etc/evtfwd.con and port 514 are the default and do not need to be specified on the command line. The pl2bat command that is distributed with the Active State Perl package will create an evtfwdd.bat file, which can then be started simply by typing evtfwdd as long as it resides in your path.

Syslog to Event Log

If you are operating in a predominantly NT environment, forwarding UNIX syslog entries to a Windows NT Event Log service may be a desirable alternative. There is a tool called ntpsysld, which can be used to accomplish this. ntpsysld is a UNIX syslogd work-alike written in Perl and ported to the Windows NT environment. It has a number of interesting features, however, the thing that makes it useful for our purpose is the fact that syslog entries can either be sent to a text file on the NT server or directly into the NT Event Log database.

Like the UNIX syslogd, ntpsysld uses a configuration file (syslog.con) that has a very similar format to the typical syslog.conf file. A sample ntpsysld configuration file is shown in Figure 2.

Instead of a tab separating the fields, one or more spaces are used. The two columns represent syslog priority and the action to be taken. The priority has the same meaning as in the normal UNIX syslog (see your UNIX syslogd(3), and syslog.conf(3) man pages) with the following extensions:

• A range of priority levels may be specified using a hyphen (-). For example, auth.info-warning, would apply to messages of the auth facility with info, notice, and warning levels.

• A single priority level may be specified using -only. For instance, user.crit-only would apply only to messages of user facility at crit level instead of the default crit and above (crit, alert, and emerg).

The action column supports the normal syslog convention of specifying a disk file. There is no wall or user list ability, however, a slight modification to the source code and downloading an additional module may get you a Winpopup capability (this is planned for the next version of ntpsysld). The odd period-separated action specifier shown in Figure 2 has the following meaning:

• The first part is an event type specifier, such as EVENTLOG_ERROR_TYPE.
• The second part is the event category, such as 0 (meaning none).
• The third part is the event identifier. This can be used as a means to further sort your messages.
• The last part, the “evt” tag, tells ntpsysld that this message should be sent to the Event Log service.

For example, the first line in the sample ntpsysld configuration file will cause ntpsysld to send messages it receives from any facility at level info and above to the NT Event Log with an event type of EVENTLOG_INFORMATION_TYPE, a category of 0, and an event identifier of 8000. The last line shown in this sample would send all messages of level debug to the text file debug.log.

ntpsysld also differs from the normal UNIX syslogd in that it only accepts messages from an Internet domain UDP socket. To run ntpsysld, type:

perl -w ntpsysld --port 514 --conf  \
  /etc/syslog.con

The pl2bat tool can be applied here as with evtfwdd. It may be necessary to create an /etc/syslog.aut file. This file specifies from which hosts messages will be accepted. The documentation that accompanies the package explains the use of this file, however, an entry such as type = none should get you up and running.

Download and Installation

The download package for each of these tools contain installation instructions, so those will not be covered here. Note that ntpsysld is now bundled into the psyslogd package, which is an extended syslogd for UNIX, written in Perl. To build ntpsysld from this package requires GNU tools on your NT box, which you may or may not want to deal with. Because of this, a pre-built ntpsysld is available at the same download site and in the psyslogd package as ntpsysld.sample. Tools discussed in this article may be downloaded at the following sites:

Evtfwdd and ntpsysld: http://home.inreach.com/jaguiar

Activestate Perl for NT: http://www.activestate.com

One of several sites for GNU tools for NT: ftp://sourceware.cygnus.com

It is possible to run evtfwdd or ntpsysld as an NT service. A very good article detailing how to turn a Perl script into an NT service appeared in The Perl Journal [2]. Also, there have been a number of news group postings on turning a program into an NT service, as well as postings on the Microsoft Web site. Tools are available for creating an NT service in the NT resource kit for NT 4.0. The same tools for creating a service on NT 3.5 seem to work for NT 4.0 as well and are available for download at:

ftp://ftp.microsoft.com/bussys/winnt/  \
   winnt-public/reskit/nt35/i386/

Summary

It is possible to effectively and inexpensively solve the problem of integrating event reporting between UNIX and Windows NT. In the cases discussed here, we were able to build and use freely available tools. Which solution you choose can depend on many things, some of which are: what management platform you use, what OS the majority of your servers run, or where your expertise lies.

There are a number of improvements planned for the tools evtfwdd and ntpsysld, and they will be added over time. Suggestions or bug reports/fixes are always welcome (jaguiar@inreach.com). I hope these tools prove to be useful in solving some of your cross-platform system logging needs.

References

[1] Win32 Perl Programming: The Standard Extensions, Dave Roth, MacMillan Technical Publishing, 1998.

[2] “Turning a Perl Program into an NT Service”, Kevin Meltzer, The Perl Journal: Vol.4, No.3, (http://tpj.com), Earth Web, Inc.

[3] Programming Perl, Larry Wall, Tom Christianson and Randal L. Schwartz, O’Reilly and Associates, Inc., 1996.

About the Author

Joe Aguiar has worked as a Systems and Network Administrator and Software Engineer since 1986. He holds a BSEE degree from CSU, Fresno. He can be reached at jaguiar@inreach.com.