Jon, I’ve figured, at least for my case, all the issues: Issue 1: was solved removing the public IP address and hostname from the /etc/hosts file. So when makedns is does not complains anymore about the reverse and forward public zones.
Issues 2 and 3: the hpclab.iq.ufrj.br.cluster.iq.ufrj.br. ridiculous name was fixed automatically after solving 1. So what I think is happening: xCAT does not read from it’s database to run makedns. It depends on /etc/hosts… the public network still exists in the lsdef -t network command: [root@hpclab ~]# lsdef -t network 10_0_0_0-255_255_255_0 (network) 146_164_29_0-255_255_255_0 (network) What do I have now? I think I will try a redeploy with those modified settings to see what’s happen. More issues will come, I think when deploying FreeIPA in a manner that xCAT makedns’ likes. That’s it for the server part. Let me ask another thing: how the clients authenticate? I’m using stateless images an this is and issue since I can’t run ipa-client-install on the chroot image. I was thinking in running ipa-client-install unattended everytime a node boots. But this isn’t really well documented and tested. Some solution may come with force re-enrollment: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/identity_management_guide/linux-manual https://www.freeipa.org/page/V3/Forced_client_re-enrollment But it’s not tested yet… Thanks, On 23 Sep 2019, at 09:00, Jon Diprose <j...@well.ox.ac.uk<mailto:j...@well.ox.ac.uk>> wrote: Hi Vinícius, As I said, still some oddities! Yes, I too failed with what I thought should be the correct explicit zone specification but found that zonesub probably did what I was expecting. We need a FreeIPA DNS expert to answer that one. I think some of issue 2 & 3 comes down to having the xCAT networks and nics tables set up appropriately. For me, I think I see that nics whose associated networks record points to a different nameserver don’t result in an update attempt. I get a message of the form: Ignoring host xxx-lan, it does not belong to any nets defined in networks table or the net it belongs to is configured to use an external nameserver. where xxx is a node that xCAT knows about, with a secondary nic with suffix ‘-lan’ and associated with a networks record in turn configured with a different nameserver, that nameserver not being the IPA instance in /etc/resolv.conf that xCAT is trying to update. I also think this extends to any aliases on such nics, which is where I configure the “real” external hostname. But yes, the non-local /etc/hosts entries that I haven’t told xCAT about end up with the internal domain appended to their fq-external-dn hostname. I think this is a fail-down from what you saw with your issue 1 forward zone failures - xCAT fails with just the external name and then tries again with the internal domain appended. In practice, it makes no difference until such time as the A record IPA returns has the wrong IP and I’ve dealt with it by manually purging such entries from IPA. The behaviour is predictable, so fixing it is scriptable, not that I’ve done it. At some point I’ll tell xCAT about everything I’m interested in and see if that helps. It may in fact be that I only see such internal-domain-appended updates going to IPA for domains not declared in the networks table. The search domains declared in /etc/resolv.conf may also have an effect. As per the above, I think issue 1 is a further symptom of the remaining 2 & 3 issues - so will disappear to the extent that you can prevent the inappropriate DNS update attempts. On the plus side, these updates both should fail and do fail, which means that, other than the log message, they aren’t a problem. We’d need someone who knows about how makedns actually works to know exactly how we should be doing it! Jon -- Dr. Jonathan Diprose <j...@well.ox.ac.uk<mailto:j...@well.ox.ac.uk>> Tel: 01865 287837 Research Computing Manager Henry Wellcome Building for Genomic Medicine Roosevelt Drive, Headington, Oxford OX3 7BN From: Vinícius Ferrão via xCAT-user [mailto:xcat-user@lists.sourceforge.net] Sent: 22 September 2019 19:23 To: xCAT Users Mailing list Cc: Vinícius Ferrão Subject: Re: [xcat-user] Removing BIND from xCAT Jon, I was an amateur. You already said the exactly string that I need to make DNS update with the grant policy. Sorry for this mess. I was able to understand exactly what’s going on in this website: http://www.zytrax.com/books/dns/ch7/xfer.html zonesub: The RR name being updated must match anything containing the zone name (as it appears in the zone clause containing this update-policy), including subdomains (any labels on the left) of this zone name. The optional tname field must be omitted when using this form. LOL. Anyway the issue 1. is still valid and happening. Solving the issues for 2 and 3, I’ve came through another issue: the external DNS name is added to the internal DNS with the domain appended, so I got the following registry: hpclab.iq.ufrj.br.cluster.iq.ufrj.br. Thanks, On 22 Sep 2019, at 14:52, Vinícius Ferrão <fer...@versatushpc.com.br<mailto:fer...@versatushpc.com.br>> wrote: Hello Jon, I’m having issues with the setup. First the enhancement things that may be welcoming for you: # chdef -t site externaldns=1 With this in place you can only use makedns instead of makedns -e. I think it’s a good idea to set it up to avoid messing with the local named daemon. In case of you forgetting to put -e in makedns command. Now the bad things. 1. Makedns insists in updating zones that I do not have control. For instance, the external domain name and the reverse IP of the external name: Error: [hpclab]: Failure encountered updating 29.164.146.IN-ADDR.ARPA. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating 29.164.146.IN-ADDR.ARPA. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating 29.164.146.IN-ADDR.ARPA. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating 29.164.146.IN-ADDR.ARPA. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating iq.ufrj.br<http://iq.ufrj.br/>. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating iq.ufrj.br<http://iq.ufrj.br/>. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating iq.ufrj.br<http://iq.ufrj.br/>. with entry '', error was REFUSED. See more details in system log. Error: [hpclab]: Failure encountered updating iq.ufrj.br<http://iq.ufrj.br/>. with entry '', error was REFUSED. See more details in system log. There’s a way to skip this zones? This happens because of my external addresses. 2. For reasons unknown I can’t make the grants for the internal zone: Sep 22 14:48:04 hpclab named-pkcs11[21244]: 'CLUSTER.IQ.UFRJ.BR' unexpected Sep 22 14:48:04 hpclab named-pkcs11[21244]: zone cluster.iq.ufrj.br/IN:<http://cluster.iq.ufrj.br/IN:> failed to parse policy string Sep 22 14:48:04 hpclab named-pkcs11[21244]: zone cluster.iq.ufrj.br/IN:<http://cluster.iq.ufrj.br/IN:> disabling all updates because of error in update policy configuration: unexpected token I’m using this policy in cluster.iq.ufrj.br<http://cluster.iq.ufrj.br/>; grant CLUSTER.IQ.UFRJ.BR krb5-self * A; grant CLUSTER.IQ.UFRJ.BR krb5-self * AAAA; grant CLUSTER.IQ.UFRJ.BR krb5-self * SSHFP; grant xcat_key CLUSTER.IQ.UFRJ.BR A CNAME; 3. The same thing happens for the reverse zone: Sep 22 14:50:35 hpclab named-pkcs11[21244]: '0.0.10.in-addr.arpa.' unexpected Sep 22 14:50:35 hpclab named-pkcs11[21244]: zone 0.0.10.in-addr.arpa/IN: failed to parse policy string Sep 22 14:50:35 hpclab named-pkcs11[21244]: zone 0.0.10.in-addr.arpa/IN: disabling all updates because of error in update policy configuration: unexpected token Sep 22 14:50:35 hpclab named-pkcs11[21244]: update_zone (syncrepl) failed for master zone DN 'idnsname=0.0.10.in-addr.arpa.,cn=dns,dc=cluster,dc=iq,dc=ufrj,dc=br'. Zones can be outdated, run `rndc reload`: unexpected token Using the policy in the reverse zone: grant CLUSTER.IQ.UFRJ.BR krb5-subdomain 0.0.10.in-addr.arpa. PTR; grant xcat_key 0.0.10.in-addr.arpa. * PTR; -x-x-x- Regarding 2 and 3; it’s probably something wrong on the grant policy. But I’ve followed your instructions and the instructions on the link that you’ve attached in the original message. What I’m missing? Thanks, On 12 Sep 2019, at 06:11, Jon Diprose <j...@well.ox.ac.uk<mailto:j...@well.ox.ac.uk>> wrote: Hi Vinícius, I am looking at exactly this at the moment. My experience so far is that: - xCAT’s ‘makedns -e’ uses TSIG to update at least the first dns server in the master’s /etc/resolv.conf - xCAT’s TSIG key appears to be hmac-md5 + I’d like to know if I could go to hmac-sha512 instead but I think that may be hardcoded as the hashing function declaration isn’t in the omapi entry of the password table, just the secret - https://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG basically applies - add the xcat_key stanza to the /etc/named.conf files and ‘rndc reload’ on all FreeIPA replicas - for the relevant FreeIPA forward zones the update-policy ‘grant xcat_key zonesub A CNAME;’ is required in addition to whatever is already there + if you are doing that at the command line, ‘ipa dnszone-show zone.name. --all’ shows the existing policy + note that ‘ipa dnszone-mod zone.name. --update-policy …’ replaces and does not append - for the relevant FreeIPA reverse zones the update-policy ‘grant xcat_key zonesub PTR;’ is required in addition to whatever is already there - those may not be the most appropriate policy wordings but they work for me - ‘ipa dnszone-mod zone.name. --dynamic-update true’ is required for both forward and reverse zones - the ‘@’ records and Authoritative Server settings that FreeIPA creates by default may need adjusting if those defaults are not reachable by your xCAT master - you can test the talking-to-FreeIPA bit without any of the xCAT stuff using the ‘nsupdate’ command - I haven’t yet attempted to enrol my xCAT master as an IPA client so I’ve no idea if kinit’ing with appropriate privilege would make the TSIG key work unnecessary - I don’t know if xCAT can speak GSS-TSIG ‘makedns -e’ now almost works for me - it updates the all IPA dns records that I am expecting from my xCAT config and a few more I wasn’t expecting from having manually added stuff to my /etc/hosts, all without touching the existing local config. It is still returning an exit code of 1 so there’s still something to track down, but I think that is now down to inconsistencies and oddities in my xCAT config and /etc/hosts file, complicated by my particular setup not being authoritative for some domains I use. I also ship fully-populated /etc/hosts files to all our xCAT-managed nodes, so I’m hoping for a seamless changeover when redirecting the nodes to the FreeIPA DNS instances instead of the one on the xCAT master. I hope that helps and I’d appreciate hearing about anything you learn along the way! Jon -- Dr. Jonathan Diprose <j...@well.ox.ac.uk<mailto:j...@well.ox.ac.uk>> Tel: 01865 287837 Research Computing Manager Henry Wellcome Building for Genomic Medicine Roosevelt Drive, Headington, Oxford OX3 7BN From: Vinícius Ferrão via xCAT-user [mailto:xcat-user@lists.sourceforge.net] Sent: 11 September 2019 15:32 To: xCAT Users Mailing list Cc: Vinícius Ferrão Subject: [xcat-user] Removing BIND from xCAT Hello, I’ve came across this documentation page: https://xcat-docs.readthedocs.io/en/stable/advanced/domain_name_resolution/domain_name_resolution.html#option-2-use-a-dns-that-is-outside-of-the-cluster And it says specifically that I can use an external DNS server. So the point is, with this option xCAT does not even use the shipped BIND? Can it coexist with another BIND daemon on the same machine? I’m interested in installing FreeIPA and enabling DNS integrated Zones, so FreeIPA handles the DNS service. Thanks, _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net<mailto:xCAT-user@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net<mailto:xCAT-user@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/xcat-user
_______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
