AW: Nagios plugin to copy large text files

[Mohr James]

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

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:

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

The OpenView programm I "pushed" not is also "not a file management
application" and it "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." However, I did it. I am sure that the
HP developers that initially told support that it can't be done, "said
that functionality simply doesn't exist and with good reason." OpenView
does not have the same character limitation as Nagios. OpenView found a
very viable solution to the atomic write problem without having to limit
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. 

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. 

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

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

There was nothing, at all, in your originaly post that said that NRPE
*cannot* do what I ask. You simply stated that it was not designed for
it. So, I think it is very unfair of you to imply that I am not a "good
system administrator" system administrator because I cannot "recognize
that there are good ways and bad ways 
of doing things". (Perhaps I am simply infering this) Still, up to now,
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
issue of the character limitation, so obviously wanting this ability is
not unheard of. There are posts about changing values in various source
files, but that I am not happy with that solution.

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

A good system administrator documents his or her system properly so that
everyone knows where/what the differences are. We are not so "naive" as
to simply recompile check_nrpe (for example) and leave the name the
same. By calling the programm COMPANY_NAME_check_nrpe, it is self
documenting, in addition to the entries in or operations manual. We do
that with basically all of our scripts and I would highly recommend this
practice. (We do have some people who simply ingore this unwritten
rule.)

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

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
years, I can definately say it was worth the money. 


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

Granted, at least in theory. However, we still need to write and
maintain it. There is also a time factor here (we don't have the extra
time needed to program it).

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

I think that changing the value on a header file is far simpler than
writing a client-server application. Thus, I would not call changing a
.h file to be "additional programming".


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