[Nagiosplug-devel] system specific defines ... Was: check_dhcp - a possible addition

[Andreas Ericsson]

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