search

rocky-linux / infrastructure

The infrastructure monorepo for the Rocky Linux project. This project will be archived/deprecated in the future.
https://rockylinux.org
386 stars 46 forks source link

[Enhancement] Ansible Playbooks - FreeIPA DNS and PTR #15

Open nazunalika opened 3 years ago

nazunalika commented 3 years ago

Currently when FreeIPA domain controllers are built, the zones are populated with the domain controller issues, including reverse DNS entries. However, there are two problems with the clients:

NeilHanlon commented 3 years ago

Currently when FreeIPA domain controllers are built, the zones are populated with the domain controller issues, including reverse DNS entries. However, there are two problems with the clients:

  • Their DNS servers in /etc/resolv.conf need to point at the domain controllers in their DC

    • This requires a change, potentially to role-rocky-ipa-client.yml to assert if the DNS resolver is correct and if not, change it
    • This change will also require a way to determine, based on subnet, what zone it's in to correct the above if needed

If we encode zone in a subdomain, can we use this instead of calculating subnet? I suppose calculating subnet is OK as we will also have a consistent ip addr plan. I will mull this over. It could actually be computationally faster to determine the right ipa to go to based on the inverse wildcard mask of the subnet. Holy shit.

Like.

I can (I think) write an ansible/jinja python thing that given an ip and mask returns the ipa server for that region, given our ip address plan. Without any other info except the planned ip addresses of the ipa servers.

  • Kickstarts of systems can also configure the systems to be static addressed to put in another "check"

  • Clients do not receive PTR records

    • A post_task should be added after the initial install to turn on automatic PTR records
    • Other domains created (reverse) should also have automatic PTR records
nazunalika commented 3 years ago

If we encode zone in a subdomain, can we use this instead of calculating subnet? I suppose calculating subnet is OK as we will also have a consistent ip addr plan. I will mull this over. It could actually be computationally faster to determine the right ipa to go to based on the inverse wildcard mask of the subnet. Holy shit.

Like.

I can (I think) write an ansible/jinja python thing that given an ip and mask returns the ipa server for that region, given our ip address plan. Without any other info except the planned ip addresses of the ipa servers.

Right yeah, I was wanting to actually to do something like that. Where, we calculate on the subnet that has a predetermined list of IPA replicas serving DNS, because they would be based on location regardless. Inevitably this will be part of the inventory vars too, where IPA servers will be grouped up based on location, that way their /etc/resolv.conf is checked and if required set to the right DNS values.

piwi3910 commented 3 years ago

one proposition i can do here: After kick start let your vm's do service registration to something like consul and send tags what function they would expect to be you can then use ansible kv lookup to set vars based on that. It's super powerfull and allows you to do geolocations and all and you can do your IPAM in there if you want :-)

NeilHanlon commented 3 years ago

Adding context from Slack - there was discussion on having this generate based on information stored in DCIM.