Dissociate Smart Proxies unmanaged IPv6 #3645
Conversation
github-actions
bot
added
Needs tech review
Lennonka
force-pushed
the
dissociate-smartproxies-unmanaged-ipv6
branch
2 times, most recently
from
da4f340 to
36058fe
Compare
Lennonka
force-pushed
the
dissociate-smartproxies-unmanaged-ipv6
branch
from
36058fe to
2f8312d
Compare
|
ACK, makes sense |
Lennonka
added
tech review done
maximiliankolb
added
style review done
|
I think it's a bug this can be done in the first place: the DHCP management is IPv4-only and we know the subnet type |
| @@ -4,6 +4,11 @@ | |||
| You must add information for each of your subnets to {ProjectServer} because {Project} configures interfaces for new hosts. | |||
| To configure interfaces, {ProjectServer} must have all the information about the network that connects these interfaces. | |||
|
|
|||
| [IMPORTANT] | |||
| ==== | |||
| In an IPv6 network with unmanaged DHCP and DNS, do not assign DHCP {SmartProxy} and Reverse DNS {SmartProxy} to your subnet. | |||
There was a problem hiding this comment.
This is IMHO a bug that the user can select this in the first place. Is there work tracked to make that impossible?
There was a problem hiding this comment.
I wouldn't mark it as a bug yet. We may start supporting DHCPv6 management in the future. The same goes for DNS, maybe we will be able to support managed DNS for IPv6 networks later on (for example in retroactive mode, where we update the DNS once we get the facts from the host).
There was a problem hiding this comment.
Until we develop the feature, we should make it impossible set unsupported options. Because of that I'd qualify it as a bug.
There was a problem hiding this comment.
Let's create an issue on Redmine then. Sounds fine by me.
There was a problem hiding this comment.
It looks like this thread will be resolved by an issue on the code side. I'll resolve this thread then (but it would be nice if you could add a link to the Redmine issue for reference).
There was a problem hiding this comment.
Unresolving because reverse DNS should work. There is explicit code for it and I'd like to see some reproducer that shows it's broken before documenting it. Then we can, while we fix the bug, document a known issue.
There was a problem hiding this comment.
@ekohl reverse DNS will cause ip6 field to be required too: https://github.com/theforeman/foreman/blob/2a81d51f7793f82bc5687952789e716b278083ff/app/services/nic_ip_required/base.rb#L29
There was a problem hiding this comment.
Interesting, but I'm having trouble wrapping my head around why this is an issue. Is there a bug report with the reproducer steps? Is it something like:
- User creates a new host
- User doesn't select a compute resource which can provide an IPv6 address
- User adds a NIC
- User selects IPv6 subnet with reverse DNS set
- User doesn't set an IPv6 address
Now the user is presented with an error, but how is that a problem? When is selecting an IPv6 subnet without setting an IPv6 address valid?
If you are provisioning with IPv6 with unmanaged DHCPv6 then I'd assume you don't set the IPv6 subnet and instead rely on it to be set later when it's set via facts: https://github.com/theforeman/foreman/blob/2a81d51f7793f82bc5687952789e716b278083ff/app/models/host/base.rb#L512-L517
| @@ -22,6 +22,11 @@ If you experience timeouts during DNS conflict resolution, check the following s | |||
| * The domain name must have a Start of Authority (SOA) record available from {ProjectServer}. | |||
| * The system resolver in the `/etc/resolv.conf` file must have a valid and working configuration. | |||
|
|
|||
| [IMPORTANT] | |||
| ==== | |||
| In an IPv6 network with unmanaged DNS, do not assign DNS {SmartProxy} to your domain. | |||
There was a problem hiding this comment.
I don't understand this sentence. Why shouldn't a user do this? Why is it IPv6 specific?
There was a problem hiding this comment.
While it's not IPv6 specific, it is relevant here. If a user assigns a DNS proxy to the subnet/domain, Foreman will require IP address, which cannot be set in IPv6 scenario (at least for the foreseeable future).
There was a problem hiding this comment.
The Smart Proxy can manage AAAA records and IPv6 PTR records so I still don't see why it's a problem.
Having said that, for unmanaged DNS you should never set a DNS Smart Proxy anyway so I'm still deeply confused.
There was a problem hiding this comment.
I think making it clear that the user should not set the DNS smart proxy as long as there is no IPv6 set on the machine is useful here. Otherwise the host will require setting an IPv6 address for the host, which is not currently possible (we only support unmanaged DHCPv6 for provisioning).
There was a problem hiding this comment.
But users can assign an IPv6 address statically or rely on EUI64. For dual stack that is fine.
There was a problem hiding this comment.
Yes they can assign addresses, but not set the proxy. The proxy will just cause errors.
There was a problem hiding this comment.
@ekohl Do you have a suggestion for how to rewrite the note to be clearer from your perspective? If not, I'd prefer we go ahead and merge.
There was a problem hiding this comment.
The whole sentence needs to be dropped IMHO. For DNS it should work. If not, that's a bad bug.
@ShimShtein perhaps you're confused with DHCP, which indeed can't work with IPv6. But there's code that should prevent it from being a problem. I'm not saying it works, but there was the intention.
theforeman/foreman@990dee6 was the first step to introduce IPv6 support. There it implemented supports_ipam_mode?, which relies on supported_ipam_modes. That is [delegated](https://github.com/theforeman/foreman/blob/2a81d51f7793f82bc5687952789e716b278083ff/app/models/subnet.rb#L123 to the class).
If we go to the specific class, you can see that for IPv4 it lists dhcp while for IPv6 it doesn't.
To wrap this up you have the belongs_to_proxy statement to add the DHCP proxy. Note the if that should return true for IPv4 while returning false for IPv6.
If this code works as intended, I can't see how Foreman would ever attempt to send DHCP related API calls to the proxy even if it somehow was assigned.
There was a problem hiding this comment.
The problem here is not the API calls, but the validation on the ip6 field. Once the domain has a DNS proxy assigned to it, any host that will use that domain will require either ip or ip6 field to be not empty.
If we are talking about IPv6-only network, and since we can't manage DHCPv6 (at least for now) there won't be an option to save the host record.
There was a problem hiding this comment.
AFAIK Foreman has never supported provisioning where the IP wasn't known in advance. Shouldn't the workflow recommend users to use EUI-64 where the IP address is based on the mac address? It's a reasonable expectation that in an unmanaged DHCP environment the assigned address is exactly that.
You could even mandate with unmanaged DHCP that SLAAC is also used to assign IP addresses.
|
So I can merge this, right? |
I have the same question :) @ShimShtein's ack means |
|
Unsetting |
aneta-petrova
added
Needs tech review
What changes are you introducing?
Adding important instructions for subnets and domains in IPv6 networks, where DHCP and DNS cannot be managed by Foreman
...and a couple of cosmetic improvements
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Checklists
Please cherry-pick my commits into: N/A