Bug #16143
closed
Discovered host IP address is not changed to fall within the subnet range
Added by Lukas Zapletal over 8 years ago.
Updated over 4 years ago.
Category:
Discovery plugin
|
|
Description
When booting a host for discovery my understanding is it is using an address from the pool configured in the /etc/dhcp/dhcpd.conf. When converting the host to discovered though the address is not changed to fall within the range specified for the subnet. This can lead to conflicts with later discovered hosts having the same IP address specified as an existing host record does. As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1367549
I believe only auto-provisioning is affected. I tested this without discovery process (bare-metal - new host) and foreman core DOES honor this (I believe this was fixed last year). Therefore we need to correct this in discovery.
# lease of an external host
lease 192.168.223.11 {
starts 3 2016/08/17 10:20:48;
ends 0 2016/08/28 23:54:08;
cltt 3 2016/08/17 10:20:48;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 52:54:00:5a:00:e0;
}
# host was created with the same MAC - reservation from range (110-240)
host test.nested.lan {
dynamic;
hardware ethernet 52:54:00:5a:00:e0;
fixed-address 192.168.223.112;
supersede server.filename = "pxelinux.0";
supersede server.next-server = c0:a8:df:01;
supersede host-name = "test.nested.lan";
}
We need to change traditional and quick provisioning as well in this regard. Changes might be required too.
So all we need to do is to call unused_ip for both auto and interactive paths. Smart proxy will take care of the rest. Easy patch.
Test with V2 API as well.
- Priority changed from Normal to Urgent
Increasing priority on this one, we are branching 1.13 this week.
Lukas Zapletal wrote:
Increasing priority on this one, we are branching 1.13 this week.
I'f I'm grok'ing this correctly, this fixes the primary interface portion of http://projects.theforeman.org/issues/16132 which is personally my real blocker for using discovery the way I've hoped to. Happy to help on this however I can as I've got a personal stake in it (and 5K cores of compute I'm hoping to discovery as soon as I can do the unused_ip call!
Actually, one question: would the "unused_ip" call be before/after the hostname template parsing? I ask because in my environment the hostname will be based off the IP, and its critical it be the new IP from unused_ip, not the originally leased IP for discovery. Totally understand if that is a larger/separate issue, worst case for me I get the IP's i want and change my naming pattern to deal w/ it.
- Is duplicate of Bug #16132: When a Discovered Host is converted to a Managed Host the IP address is not changed to fall within the subnet range added
I'f I'm grok'ing this correctly, this fixes the primary interface portion of http://projects.theforeman.org/issues/16132 which is personally my real blocker for using discovery the way I've hoped to. Happy to help on this however I can as I've got a personal stake in it (and 5K cores of compute I'm hoping to discovery as soon as I can do the unused_ip call!
Hello, yup. I am currently working on the patch. I will call unused_ip on all managed interfaces rather than on provisioning interface only.
Actually, one question: would the "unused_ip" call be before/after the hostname template parsing? I ask because in my environment the hostname will be based off the IP, and its critical it be the new IP from unused_ip, not the originally leased IP for discovery. Totally understand if that is a larger/separate issue, worst case for me I get the IP's i want and change my naming pattern to deal w/ it.
Good question, in my WIP branch it's after hostname template rendering, but I think it is worth changing it as you want probably to match hostname with the target IP. I will change that.
To be honest, the reason why it took so long to fix this is I haven't figured this out. On my testing environments and small environments, I always keep the discovered IP and I never run into issues. It's quite surprising this was reported mid-2016.
- Target version set to 1.5.2
Lukas, if there is anything I can do to help, be it testing or anything, I'm more than happy to. I've got a rollout of a few hundred systems Ive been hoping to use discovery for, but this is my current blocker. I've got a backup plan if it comes down to the wire, but until then I'm happy to do whatever it takes to help get this sorted.
Hello, I am currently working on the patch. Can't give you an ETA tho. Will keep you posted.
- Status changed from New to Ready For Testing
- Assignee set to Lukas Zapletal
- Pull request https://github.com/theforeman/foreman_discovery/pull/306 added
- Related to Bug #17613: Discovery, DHCP and lease conflict added
- Difficulty changed from easy to medium
- Triaged set to Yes
- Fixed in Releases Discovery Plugin 16.0 added
- Status changed from Ready For Testing to Closed
- Related to Bug #28330: Reboot/kexec is ussed against new (reserved) IP address added
- Pull request https://github.com/theforeman/foreman_discovery/pull/496 added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Anonymous