[Nagiosplug-devel] post-1.3.0 features

[Karl DeBisschop]

On Wed, 2003-03-05 at 22:07, Jeremy T. Bouse wrote:
> On Wed, Mar 05, 2003 at 09:27:11PM -0500, Karl DeBisschop wrote:
> > 
> > HEAD is explicitly for development. The r1_3_0 branch will allow us to
> > apply bug fixes on the road to 1.4.x.
> > 
> > So we don't need another branch, at least in my estimation. Just have at
> > it.
> > 
> 	Okay, can't argue with that logic... Makes it a lot easier but I
> have work'd in some environments where we did special development projects
> like this as forked branches and brought the code back to the main trunk
> after it was fleshed out...

developer time is in pretty short supply. I can kive with HEAD having
brief period where it's a little dysfunctional.

> > A good place to look for AF implementation might be the postgresql
> > sources. The recently went through it, and they successfully support a
> > pretty wide set of platforms.
> > 
> 	Yeah I'll do that... I just need to figure out if getaddrinfo and
> getnameinfo are available, if so use them otherwise I need to prolly create
> equiv functions using getnameby* and getaddrby* function calls... I have
> some code that's already #define'd (different from my original patch submitted)
> so if I can get the test working in configure it should be smooth sailing 
> from there...

Ah.. good. I was going to suggest that approach. Creating a stub like
that can be pretty functional with fairly little investment of time. At
least, I haven't heard many complaints doing millisecond timing that
way.

> 	As for plugins needing work to be AF-indep I could use some help
> brainstorming specifically on check_ping as I've found some use the standard
> ping with a '-A inet6' option and others (mainly linux) use ping6 for IPv6 
> ping and standard ping command for IPv4... Need to come up with a portable
> way of figuring this out so the code can be portable...

What about rewriting check_ping to call the network functins directly,
instead of wrapping ping. I was once (even fairly recently) of the mind
that I did not want to be responsible for suid code. But the fact of the
matter is, we invoke suid code in ping anyway. So the risk is there,
whether we chose to own it or not. Thoughts?

> 	I think the idea of adding -4 and -6 as plugin command line options
> to force IPv4 or IPv6 was mentioned and would need to be hashed out. As well
> I think configure should prolly be able to be compiled with IPv6 disabled if
> it weren't required or wanted...

Never quite as simple as it seems at first.

I just opened up check_disk for a minor repair. Ended up deciding that I
need to learn the statfs function, and stop wrpping df whenever
statfs(2) is available. Never easy.

But alway educational, and sometimes even fun.

--
Karl