Bug 478450

Summary: DHCP peers get out of sync
Product: Red Hat Enterprise Linux 5 Reporter: Martin Poole <mpoole>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team>
Severity: high Docs Contact:
Priority: high    
Version: 5.2CC: dcantrell, dmair, eva, gpaterno, jplans, mgandolf, mosvald, mpoole, mrappa, rlerch, rvokal, tao
Target Milestone: rcKeywords: Rebase
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-26 10:56:24 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 499522, 531114    

Comment 6 David Cantrell 2009-09-21 16:41:49 EDT
I don't know how to access Issue Tracker tickets, so I can't read anything there or access any files there.
Comment 11 David Cantrell 2009-09-30 15:38:14 EDT
The discovery made throughout this entire bug is that DHCP failover code is entirely broken in all versions of ISC dhcp except 4.1.0 and higher.  So the hotfix package built for this issue has dhcp-4.1.0 built and installed alongside the existing version of ISC dhcp.  As stated by mosvald, the customer did verify that dhcp-4.1.0 solved the problem for them and the hotfix package does provide the right executables, so we just need to verify that they are using them:

1) Is the hotfix package installed on all affected systems?
2) Have they modified /etc/init.d/dhcpd to use /usr/sbin/dhcpd4?
3) They should chmod 0000 /usr/sbin/dhcpd just for safe measure.

Aside from that, I have no ideas.  The only real solution is to have this customer use dhcp-4.1.0.  That's been provided in the hotfix, but they have to manually edit the dhcpd init script and make sure they are using the dhcpd4 binary over the dhcpd binary.
Comment 15 RHEL Product and Program Management 2009-10-26 10:56:24 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.