Feature #6778
open
ability to force delete existing PTR's via smart-proxy
Added by Greg Petras about 10 years ago.
Updated about 10 years ago.
Description
We often re-provision an environment that is on its own dedicated subnet. Occasionally we run across an old PTR, possibly due to a failed deletion of that record. Either way, the proxy has handed out the address, so we trust that it is not in use.
I would like to see a flag in the smart-proxy configuration that lets me delete existing PTR records on VM creation so that the provisioning process can continue.
Files
Related issues
1 (1 open — 0 closed)
Foreman should raise a conflict, then ask you to confirm that you wish to overwrite the existing DNS record?
Sorry, I should have clarified that this is when using the API. Is there an option that could be passed when POSTing to /api/hosts?
Thanks,
Greg
- Category changed from Smart Proxy to API
Ah, that makes more sense. Try setting `override: 'true'` in your hash of host attributes. It's not documented unfortunately.
Dominic Cleal wrote:
Ah, that makes more sense. Try setting `override: 'true'` in your hash of host attributes. It's not documented unfortunately.
Hey Dominic. Thanks for the reply. I tried what you recommended, and got this:
unknown attribute: override (ActiveRecord::UnknownAttributeError)
See attached for the host JSON I tested with.
Oh sorry, typo, it should have been "overwrite". You have this already in the JSON - just remove the override entry and flip overwrite to true.
Dominic Cleal wrote:
Oh sorry, typo, it should have been "overwrite". You have this already in the JSON - just remove the override entry and flip overwrite to true.
Yeah I actually noticed this right after I posted it, so I gave that a try with the same JSON I posted earlier. I got this error instead:
Invalid MAC (Net::Validations::Error)
/usr/share/foreman/lib/net/validations.rb:19:in `validate_mac'
/usr/share/foreman/lib/net/dhcp/record.rb:7:in `initialize'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:16:in `new'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:16:in `dhcp_record'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:120:in `queue_remove_dhcp_conflicts'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:73:in `queue_dhcp'
[snip]
Let me know if you would like the rest of the stacktrace.
Thanks,
Greg
Sorry for the delay. I think that's a bug in the DHCP orchestration then, which isn't taking into account when handling "overwrite" that it won't know the MAC of the VM yet. If you're willing to try something, could you edit app/models/concerns/orchestration/dhcp.rb and in queue_remove_dhcp_conflicts change the first line to:
return unless (dhcp? and overwrite? and mac.present?)
Dominic Cleal wrote:
Sorry for the delay. I think that's a bug in the DHCP orchestration then, which isn't taking into account when handling "overwrite" that it won't know the MAC of the VM yet. If you're willing to try something, could you edit app/models/concerns/orchestration/dhcp.rb and in queue_remove_dhcp_conflicts change the first line to:
return unless (dhcp? and overwrite? and mac.present?)
Sorry for the delay as well. I tried to comment out the line you mentioned (Foreman 1.5.3 now), and I get 'Operation FAILED: Invalid MAC'. Any other details I can provide?
Thanks for your help.
Greg
- Related to Bug #7623: Adding kvm-guest with confilicting DNS-entry leads to failure in MAC validation added
Also available in: Atom
PDF