Where have the cgi gone?

[Paul L. Allen]

Marc Powell writes: 

> On Friday, January 23, 2004 3:51 PM, Paul L. Allen shared with us:

>> Hmmm, it generates graphs on-the-fly.
> 
> Which makes absolutely no difference if the cgi doesn't exist, as is
> clearly stated.

It explains WHY the cgi doesn't exist, to those who bother to think
about it.  All the CGIs that don't generate graphics on the fly
are present, all those that do are absent.  Right away, the problem
has been narrowed down.  We know that all the missing CGIs have
property X and none of the CGIs which are present have property X.
It should not take a genius to figure out that, for some unknown reason,
there is something about property X which is somehow related to
those being absent. 

>> And that generates graphs on-the-fly, too.
> 
> Ditto.

Yes, another case of having property X.  Identifying a feature common
to several problematical items which is not shared by items without
problems is the first step in the analysis.  Of course, sometimes it
is a lot more complex than that, where having property X causes problems
only if it does not have property Y or if it does have property Z.  In
this case it was nice and simple: all the CGIs that generate graphics
on the fly are missing; all the CGIs that are present do not generate
graphics on the fly. 

>> That one doesn't generate graphs.  But it does generate a status map,
>> which is a graphic that is created on-the-fly. 
> 
> Ditto the ditto above.

Ditto-cubed. 

>> Yes, the documentation can help.  It tells you what libraries you
>> need in order for certain things to be built.  See if you can guess
>> what type of library you might be missing before you read through the
>> documentation.   
> 
> Now, I'll admit that I am a big fan of 'give them enough information to
> help them help themselves and learn in the process', but really, there's
> nothing to take away from this comment that's useful in the least and is
> actually very condescending.

It was MEANT to be condescending.  The answer IS in the documentation,
albeit somewhat obscure.  And by "documentation" I mean not only the
web docs but also the FAQs, the installation instrucions in the tarball,
the output of configure --help, etc.  These are all places I would have
looked before then going on to search google for a while.  Only if none
of those things turned up an answer would I have considered asking here. 

Then again, I would have been bright enough to make the connection that
only the CGIs which generate graphics on the fly had gone missing.  I
would have looked at the output of the CGIs that worked and noticed that
they did not generate graphics on the fly.  I would have read up on
the functionality that was meant to be provided by the missing CGIs
and realized that they did generate graphics on the fly. 

And if reading and thinking about it hadn't provided me with the answer,
I'd have done a make clean, then rebuilt while watching the output of
configure and make like a hawk to see if it complained about anything.
Which it would have done and given me the answer on the spot. 

This is NOT rocket science, just a bit of careful reading and/or a bit
of thought.  Installing packages, and reading the docs when things go
wrong, is meant to be what *nix admins DO.  That's why they're *nix
admins and MCSE point-and-click monkeys are not *nix admins.  Well,
that's how it used to be - these days it seems more and more people
ask questions here because they think the place is inhabited by
animated paperclips... 

> As far as I remember, and I'm pretty
> familiar with the documentation, this issue isn't addressed at all
> specifically and the gd libs are only mentioned in one line out of
> several thousand.

And yet you managed to conclude from his description, as did I, that
he was missing the GD libs.  How did you reach that conclusion?  Because
you remembered one line of the docs out of thousands or because it was
painfully obvious where the problem was? 

> I think I can forgive someone for missing that.

Forgive, yes.  Let him get away with me doing the work that he should
have done first, no.  OK, it took me all of ten seconds to realize what
his problem was and it would probably have taken him a whole day.  But
that would have been a day of useful experience in tracking down and
solving problems by reading documentation and applying logical thought.
Or it would have at least convinced him to go back to being a point-and-
click monkey. 

> The FAQ however does contain several entries related to this, specifically
> http://www.nagios.org/faqs/viewfaq.php?faq_id=55 and that would have
> been a much better pointer.

Even trainee *nix admins ought to know within days of starting the job
to search the FAQs before asking on a list.  Read the docs.  Then the
FAQs.  Then do a google search.  Then read the source.  If all else fails,
then think about asking on the list. 

> To make a correlation between the specific cgis generating graphs on
> the fly and not being present is a huge leap for someone without years
> of experience with linux/unix and knowing specifically how those graphs 
> are generated.

You convinced me.  It is perfectly feasible for Nagios to be distributed
with pre-created graphics of every possible statusmap, trend chart, etc.,
that any of us might ever have data for that would lead to such a chart
being required.  Nobody in his right mind would ever expect that statusmaps
or trend charts of what are essentially UNIQUE data would be generated
on demand.  Nobody would ever guess that CGIs which generate images
which could not possibly be pre-distributed with Nagios could possibly
have anything whatsoever in common when all three go missing. 

BTW, before I even contemplated installing Nagios to test it, I read
the docs (which show sample output) and went to the test site and it was
perfectly obvious which CGIs embedded static images in HTML and which
CGIs were creating images on demand.  As I said before, this isn't
rocket science.  If he'd done even a fraction of the research he
SHOULD have done before asking here, he'd have seen the property those
three CGIs had in common but which was not shared by any of the other
CGIs. 

Do you not think that somebody tasked with installing software that
monitors operating system performance and network services ought to
have a slight clue about operating systems and network services?  Or is
it OK if they think it works by some sort of magic and if anything goes
wrong they ought to consult a magician?  I have no objection to that IF
they want to pay the going consultation rates for magicians.  If they
want help for free then they need to show some signs of possibly being
able to learn from that help, because otherwise they'll just insist on
being spoon-fed every step of the way. 

If, after my post, he'd been able to figure out that he was missing a
graphics library of some sort that would have indicated he wasn't
totally beyond help and that maybe, just maybe, he would not need
babying through every step of the way of installing GD on his distro
in such a way that the missing CGIs would be created. 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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