Nagios plugin to copy large text files

[Marc Powell]

> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
> admin at lists.sourceforge.net] On Behalf Of Mohr James
> Sent: Friday, September 16, 2005 4:00 PM
> To: Nagios-users at lists.sourceforge.net
> Subject: AW: [Nagios-users] Nagios plugin to copy large text files
> 
> >> > -----Original Message-----
> >> > From: nagios-users-admin at lists.sourceforge.net
> >> [mailto:nagios-users-
> >> > admin at lists.sourceforge.net] On Behalf Of Mohr James
> >> > Sent: Friday, September 16, 2005 11:57 AM
> >> > To: Nagios-users at lists.sourceforge.net
> >> > Subject: AW: [Nagios-users] Nagios plugin to copy large text

[snip]

> Well, Marc, if you look back at the email you sent, up to now, the
> only
> half-way relevant thing you said was:
> 
> "Nagios is not a file management application. NRPE isn't designed to
> copy files between hosts. Both are designed solely to execute plugins
> that return one line of text and exit with the proper exit code."
> 
> Up to now, no one has come out and said that what I am trying to
> accomplish is *impossible*. My original post started with:

Up to your last e-mail you hadn't explained in sufficient detail what
you were trying to do and under what restrictions. My responses have
reflected the amount and type of information you have supplied and in
fact I specifically tried to elicit more detailed information from you
in order to provide a more specific answer.

> "I was wondering if there was a Nagios plug-in that was able to "copy"
> large block of text from the agent to the server."

Which is very different than what you ended up needing.

First - "The bottom line is we want/need to return larger amounts of
data. Thus, I need to find the place(s) where I should change the code,
as well as the place(s) where there are problems."

Then - "I was wondering if there was a Nagios plug-in that was able to
"copy" large block of text from the agent to the server."

Then - "All we are really interested in is getting text files (i.e.
/var/log/messages) from the clients to the server."

Then - "scp, ftp, rsync, ftp, wget and CFEngine are not a viable
solution for security reasons. Basically, we are not allowed to open
ports through the various firewalls without permission from the
customer."

Then - "The only purpose would be to retrieve files from specific
directories. This has a greater chance of getting approved because of
the limitations we could froce on the program and auditors would be able
to see the limitation for themselves."

This still leaves out what you intended NRPE to do with these files once
it retrieved them, where to put them, etc.

> the amount of data. Furthermore, the OpenView messages survive system
> restarts far more reliably than Nagios. If the server goes down,
> messages sent via send_nsca are not lost, for example. So, I am really
> curious as what the "good reason" was that Nagios does not implement
> the
> same level of reliability as OpenView.

Perhaps because Nagios/NRPE have one main developer with different
priorities to date?

> Nrpe **does** have code to execute commands and send the output to
> check_nrpe, which does have code display the output of the command
> that
> nrpe execute. The nrpe on the remote system runs "cat source_filename"
> and you run "check_nrpe > destination_file" completely external to
> Nagios. What "file management" functions are needed. On the remote
> side,
> I could run "find ./ -name filename -exec cat {} \;" and it wouldn't
> matter to nrpe, it simply returns the text to check_nrpe.

So your expectation was that NRPE would pass on these large data streams
to Nagios to store internally and display in the CGI's? Clearly you
haven't thought that through very well. Per the plugin specs, which NRPE
executes on the behalf of Nagios, it's expecting one line of output and
an exit code. As you've indicated, NRPE doesn't care _what_ the plugin
does, as long as it returns the expected output. Nagios is expecting the
same, one line of output and an exit code. Nothing more.
 
> Just so that we both know that we are talking about the same thing,
> what
> in my post did I say that led you to believe I needed "a file
> management
> application"? I would like to know so I can clarify the statement. As
> far, as I can find in my post, all I said was that I need a "large
> block
> of text". Where did I say that one of my "objectives" (your word) or
> blief that nrpe has "code to create or manage files on either host"?

"All we are really interested in is getting text files (i.e.
/var/log/messages) from the clients to the server."

This is a file management task. There are tools designed specifically
for this task. I don't know about yours but my /var/log/messages files
are usually several megs in size or more.
 
[chop]

> neither you, nor anyone else has come flat and and said "It can't be
> done". There are a number of posts in the list archives that discuss
> the

You have only just explained with sufficient detail what your intent
was. I'm not saying it can't be done. I'm saying you can't do it
_through_ NRPE. NRPE can execute a plugin on the remote host which then
SCP's or otherwise pushes the files to your nagios server using some
other mechanism but you cannot use it to essentially retrieve the file
through the same socket connection.

[chop]

> Also, I think your comment "Additionally, Nagios != OpenView (thank
> goodness) and is much more flexible" does not reflect reality.
> Although
> there are a few things that Nagios does do better, I have run into a
> number of cases where the response from the list was more or less
> "Nope,
> can't do that in Nagios. If you don't like it then stick with
> OpenView."
> Further the functionality that is built into Nagios is limited
> compared
> to what OpenView does by default. There are plugins for more wide-
> spread
> products than Nagios, they all integrate without any extra effort and

Apples and oranges. Different purposes, different design goals,
different methods. I personally find that I'm able to do things with
Nagios very easily that would have been difficult or impossible under
OpenView.

> when one breaks, I have one single source for support. Unlike many
> open
> source project, there are freuquently comments like "it not an
> official
> plugin, so you're on your own."

I'm certainly not going to get into a discussion of the relative
benefits of open/closed/proprietary programs and support. Suffice it to
say that anyone using Open Source software should be well aware that
they alone are responsible for the support, use and application of said
software unless they contract with someone who provides support for Open
Source products or the product developer provides such services. We're
just here because we desire to help and expand our understanding of the
products we use.
 
> Please, don't see this as an attack on the wonderful work that Nagios
> it. However, a "good system administrator" does not blindly stick with
> a
> product because it is open source or because it is not open source.
> You
> get what you pay for, and after working with OpenView for over five

I concur. Proprietary and open source products each have their strong
points. You choose the one that best suits your specific needs.


[chop]

--
Marc 


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null