Nagios Support Forum

--=_mixed 0064A1BF85256D48_=
Content-Type: multipart/alternative; boundary="=_alternative 0064A1C685256D48_="


--=_alternative 0064A1C685256D48_=
Content-Type: text/plain; charset="US-ASCII"

OK, I know there were a lot of problems with the last "dtd" sent out
(comments and all).

While the Nagios configuration files would do much better with a schema
based design, a simple dtd is sufficient for the status file for the
moment. I'll try and pump out a schema design for the statuslog file soon.
I am working on an entire XML tier for interfacing with Nagios 1.x. I
will release components as they become useful.

The first component I have is a small Perl app that will create an XML
document from the Nagios 1.0 status file according to the dtd included in
this message. This app can be used either from the command-line (for
pipeline processing) or as a CGI. Just change the path to your status file
in the first line of code (and make sure you have setup permissions
properly) and you should be good to go.

This app can be used to integrate Nagios status information into any
application that understands XML. This weekend I intend to setup a
Sourceforge project for these components. The posted version will also
contain the ability to transform the XML via XSLT stylesheets before
outputting the data. I hope to have completed a sample Web UI for
reporting Nagios Status using these techniques.

If anyone has any problems with this code, please let me know. Also if
anyone tries it on Nagios 1.1 I would appreciate knowing how it works.

Thanks,

__________________
Daniel Koffler
[email protected]
Tel: 514.497.1411
Fax: 206.600.4642
GPG Key ID: 0xA2C6DC83 Fingerprint: 1FD7 3FDF 8A0D 961F 26A2 3EDA AE8F
A874 A2C6 DC83





John Arley Burns
17/06/2003 11:22 AM

To
[email protected], [email protected]
cc

Subject
Re: [Nagios-devel] status log dtd again







Good start, but it would have to be substantially expanded to include
everything currently in the Nagios config files.

You might want to switch to XSchema since it's much clearer and allows
for tighter definitions.

PS Your DTD can't contain comments within the element
definition.

--- [email protected] wrote:

---------------------------------

Sorry about the html garbage in my lastpost, let's try that again


__________________
Daniel Koffler
[email protected]
Tel: 514.497.1411
Fax: 206.600.4642
GPG Key ID: 0xA2C6DC83 Fingerprint: 1FD7 3FDF 8A0D 961F 26A2 3EDA
AE8FA874 A2C6 DC83



> ATTACHMENT part 2 application/octet-stream
name=nagios_status_log_dtd.xml




--=_alternative 0064A1C685256D48_=
Content-Type: text/html; charset="US-ASCII"


OK, I know there were a lot of problems
with the last "dtd" sent out (comments and all).

While the Nagios configuration files
would do much better with a schema based design, a simple dtd is sufficient
for the status file for the moment. I'll try and pump out a schema design
for the statuslog file soon.  I am working on an entire XML tier for
interfacing with Nagios 1.x. I will release components as they become useful.


The first component I have is a small
Perl app that will create an XML document from the Nagios 1.0 status file
according to the dtd included in this message. This app can be used either
from the command-line (for pipeline processing) or as a CGI. Just change
the path to your status file in the first line of code (and make sure you
have setup permissions properly) and you should be good to go.

This app can be used to integrate Nagios
status information into any application that understands XML. This weekend
I intend to setup a Sourceforge project for these components. The posted
version will also contain the ability to transform the XML via XSLT stylesheets
before outputting the data. I hope to have completed a sample Web UI for
reporting Nagios Status using these techniques.</f

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]