[Nagiosplug-devel] system specific defines ... Was: check_dhcp - a possible addition
Andreas Ericsson
ae at op5.se
Thu Jan 20 03:15:18 CET 2005
Andreas Ericsson wrote:
> Stanley Hopcroft wrote:
>
>> Dear Folks,
>>
>> As pointed out by Mr Ericsson, check_dhcp will not build properly
>> without preprocessor symbols being defined (__bsd__ etc).
>>
>> I thought this was necessary to select _completely_ different code to
>> get the MAC address of the interface from the system (eg BSD use raw
>> sockets, solaris and hpux use DLPI [and prob AIX ...], Linux uses a
>> Linux specific ioctl()).
>>
>> Continuing down this path requires that configure.in and config.h.in
>> be patched to set these symbols depending on the value of 'host'.
>>
>> While tbis is feasable, doing so is seems anti-autoconf and
>> anachronistic (although this is the way that fping seems to operate) -
>> it looks bad and probably is too.
>>
>> What is a better way ?
>>
>
> Make sure in the necessary plugins that they are being compiled with
> GCC. The default compile mode for gcc is -std=gnu89 (meaning c89 with
> GNU extensions) for versions until the c99 support started emerging (not
> sure where that was), and -std=gnu99 (meaning c99 with GNU extensions).
> GNU extensions means that most BSD features (all networking ones, some
> stringhandling ones) are available as well as the "pure" gnu extensions
> (such as asprintf(), which is being heavily used throughout all C plugins).
>
> The code to accomplish the above is done as such;
> #ifdef __GCC__
My bad. It's __GNUC__ (at least in 3.4.4).
> <code>
> #else
> int
> main(void)
> {
> puts("This plugin requires GNU extensions, and can't be properly
> compiled without GCC\n");
> return 0;
> }
> #endif
>
> main must be present (unless this is done from autoconf, which would be
> neater) or there will be lots of errors during make. It could probably
> be put in utils.c or somewhere else which all plugins use, but only
> compiled #if !defined(__GCC__).
>
>> Chuck the system specific stuff and let the user define the broadcast
>> interface _and_ the MAC address (simply set the hardware address in
>> the DISCOVER packet and let the server respond with an OFFER to the
>> real MAC) ?
>>
>
> Broadcast interface should be enough, although it couldn't hurt with MAC
> address as well. I'll have a look at how the ISC client does it, as it
> ports nicely to virtually every unix available.
>
>> Chuck the C version and build a Perl one (based on Net::DHCP or
>> friends) ?
>>
>
> suid perl is not a very good idea, and I strongly disagree with having
> to install additional perl modules (yes, I know it's simple enough using
> the automated CPAN stuff).
>
>> Leave the C version Linux specific (and prob put it back in contrib/)
>> and or build a Perl one ?
>>
>
> Nah. Make sure it's compiled by GCC and write in the suggested changes.
> It shouldn't be terribly complicated.
>
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Lead Developer
More information about the Devel
mailing list