Smart Proxy for DNS PTR is not chosen properly
The Smart Proxy that is used for updating the DNS PTR entries is - afaict - the same that is used for the forward record.
However, the Smart-Proxy to be used should be chosen based on the subnet and not based on the domain.
adds ec2 provisioning support fixes #1223
- added progress bar for instance creation
- minor fixes for certname based deployments
- added ssh provisioning support to orchestartion, which utilize finish
scripts by default
- added images support (part of the vm compute tab)
- cleanup a lot of unused view attributes in favour of a couple html5
- adds capabilities to each compute resource (e.g. build vs. image
- allow to access @host.compute_resource and @host.info in provisioning
- added automatic ssh key pair generation when creating a new compute
resource (note, if you already created one, you would need to delete
it and create it again
- reverse dns now depends on the selected subnet - fixes #1558
- added readonly console support for ec2
#2 Updated by Andreas Rogge about 7 years ago
I got two DNS smart proxies foo and bar.
foo handles the zones foo.example.com and 2.0.192.in-addr.arpa.
bar handles the zones bar.example.com and 100.51.198.in-addr.arpa.
Now I create three hosts:
huey - domain foo.example.com, subnet 192.0.2.0
dewey - domain bar.example.com, subnet 198.51.100.0
louie - domain foo.example.com, subnet 198.51.100.0
As far as I can tell the current behaviour would lead to the following situation:
For huey both DNS entries will be created via smart-proxy foo
For dewey both DNS entries will be created via smart-proxy bar
For louie both DNS entries will be created via smart-proxy foo
The last one - louie - will fail, as is isn't possible to add a PTR for subnet 198.51.100.0 in zone 100.51.198.in-addr.arpa through smart-proxy foo.
Foreman should decide which smart-proxy to use for adding the reverse DNS record based on the configuration of the subnet.
Additionally Foreman should skip the reverse DNS record when no dns smart-proxy is configured for the subnet as this means there is no way for foreman to manage the PTR record.