DHCP 4.2.0 DDNS and OMAPI Bugs (RHEL5.5 x86_64)
jwest at brandeis.edu
Thu Sep 2 13:54:55 UTC 2010
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 22.214.171.124: 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.
Senior Systems Engineer
More information about the dhcp-users