DHCP 4.2.0 DDNS and OMAPI Bugs (RHEL5.5 x86_64)

[Joshua West]

  Hi David,

On 09/01/10 16:52, David W. Hankins wrote:
> On Mon, Aug 30, 2010 at 05:02:07PM -0400, Joshua West wrote:
>> The first issue is DDNS updates no longer work.  The error I receive in
>> /var/log/messages is :
>>
>> dhcpd: Unable to add forward map from myhost.mydomain.com to 1.2.3.4: not found
> Not found, interesting.
>
> I would guess it's having problems finding the zone or TSIG definition
> for 'mydomain.com'.

Ahhh.... Upon further inspection of the man pages (RTFM!), it looks like 
there needs to be the zone definitions in dhcpd.conf.  However, on my 
4.1.1-P1 setup, I don't have the zone's defined and I'm also not using 
TSIG (for now...).  Why would things work OK with 4.1.1-P1 with no 
zone/key defined in dhcpd.conf but not in 4.2.0?  Is this a new change 
or I've been mis/underconfigured all this time?

I'll try this out with TSIG + zone definitions.  I really want to take 
advantage of the asynchronous DDNS updates.

> Unfortunately all we have at this point in logging is an ISC result code
> binary number ("ISC_R_NOTFOUND").  What returned it is a mystery.
>
> You could try setting 'DEBUG_DNS_UPDATES' but my intuition is it's
> not getting that far.

I'll give that a whirl if tests with above zone + key doesn't work :-)

>> I cannot build DHCP 4.2.0 with the
>> RHEL 5.5 supplied bind-libbind-devel / bind-devel packages (aka
>> --with-libbind=/usr) as they are for an older version of BIND than 9.7.x.
> We currently only build with the library we include, and link them in
> statically (this is why 'dhcpd' got huge in 4.2.0).  How we want to
> solve trying to figure out if system-level shared libraries are up to
> snuff is still in the air.
>
>> dhcpctl_connect: operation in progress
> I spotted this too.  We'll fix this in maintenance.  I don't know of
> any workaround.

Do you have a patch available for pre-release?

>> In addition, dhcpd then spikes to 100% CPU usage.
> I didn't notice that!

If I recall correctly, it only was happening on the primary dhcp server 
and not the secondary.

Thanks for your help David -- much appreciated.


-- 
Joshua West
Senior Systems Engineer
Brandeis University
http://www.brandeis.edu