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 11:57 AM
> To: Nagios-users at lists.sourceforge.net
> Subject: AW: [Nagios-users] Nagios plugin to copy large text files
> 
> Marc,
> 
> I fully understand what the intent of NRPE is. Nagios and NRPE are
open
> source tools with their roots in the UNIX tradition that one can often
use
> a tool to do things other than which is was intented. Often times
people
> who have worked with a product for a long time in real-world
environments
> are able to get programs to do things even the developer didn't know
the
> product could do. (My brother told me a story where he once showed
Stephan
> Bourne something with the Bourne-Shell that Bourne himself said
couldn't
> be done). So, for me, the fact that "NRPE isn't designed to copy files
> between hosts" is not the issue. (see Gene Kranz in "Apollo 13": "I am
not
> interested in what it was designed to do. I want to know what it can
do."
> "If it lights, it lights. I am not going to hold you personally
> responsible if it doesn't".) ;-)

I am one of those people who pushes programs to their limits. My
response to your statements above is that they don't apply in this case.
A more useful analogy is that while my mail server can talk to your mail
server I can't get it to send me your /var/log/messages file no matter
how hard I try. The functionality simply doesn't exist and with good
reason. Being able to do something with bash that Stephan Bourne didn't
know could be done is a far cry from getting NRPE to transfer files
between hosts. In the former case it's a fair bet that your brother
exploited existing functionality, however obscure, in the bash shell.
NRPE has no code to create or manage files on either host. NRPE has no
code to transfer large amounts of data in a safe manner. It's going to
take more than fiddling with the value of a variable or two to achieve
those objectives. In the tradition of open source, if you want that
functionality you are certainly free to take the source code and add it
yourself or kindly submit it as a feature request to the developer. 

> We are currently using HP OpenView, which allows the executed
> script/programm to send several kilobytes of data. OpenView also has
an
> additional mechansism which enables us to send megabytes of data.
(<horn
> tooting>I have implemented this in a way that OpenView was "not
designed
> to do", to the surprise of HP support. Pushing programs beyond what
they
> are designed to do in order to accomplish the task at hand makes the
> difference between a good system administrator and an operator. </horn
> tooting>)

[opinion]
All tooting aside, a good system administrator should also be able to
recognize that there are good ways and bad ways of doing things,
practical and impractical and when business decisions are creating an
environment where good and practical are forcing you to come up with
ever more obscure and difficult to maintain solutions to problems that
have numerous valid and accepted solutions. A good system administrator
recognizes when they are becoming a silo of information and creating an
environment where they can not be replaced or are creating a system that
only they can support. Will the person who replaces you know that your
version of NRPE is different than the version that the rest of us are
using? Will they be able to upgrade it when new functionality is added
by the developer? Will they come to us for support when it doesn't work
properly? Additionally, Nagios != OpenView (thank goodness) and is much
more flexible. Expecting the feature sets between the two programs to be
the same or similar is naive. 
[/opinion]

[snip]

> We have also investigated the possibility of creating our own client-
> server application using perl. 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 would be my direction given the same circumstances or create a
custom plugin that does what you want. You're indicating that these same
auditors might be comfortable with you _in theory_ being able to copy
arbitrary files off the remote machines with NRPE IF that functionality
existed in NRPE? I'd expect that a purpose built solution would be more
likely to receive approval than a general solution given these
circumstances.

> Using nrpe, we would not need to open any additional ports, as the
ports
> has already been approved. It also allows us to restrict which
> applications are executed. It would also not require any additional
> programming on our part and there is a direct connection between the
> Nagios server and the client machine without any intermediaries.

As indicated above, it _will_ require additional programming. Nagios
itself will as well I suspect since it's only going to expect 1 line of
text + exit code from NRPE.

--
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