Description of problem: when installing ipa-client onto a server on a established network sems to give dns issues that make installing impossible. Version-Release number of selected component (if applicable): ipa-client-1.91-0.2010101321git19272e5.fc13.i686 ipa-server-1.91-0.2010101321git19272e5.fc13.i686 How reproducible: always Steps to Reproduce: 1. install and setup a ipa server with a similar command: ipa-server-install --setup-dns --forwarder=10.14.63.12 --hostname=qe-blade-04.idm.lab.bos.redhat.com -r testrelm -n testrelm -p Secret123 -P Secret123 -a Secret123 -u admin -U 2. Install ipa client onto another machine. 3. point dns at the master server. 4. attempt to instal client with ipa-client Actual results: [root@qe-blade-12 ~]# ipa-client-install DNS discovery failed to determine your DNS domain Please provide the domain name of your IPA server (ex: example.com): testrelm Discovery was successful! Realm: TESTRELM DNS Domain: testrelm IPA Server: qe-blade-04.testrelm BaseDN: dc=testrelm Continue to configure the system with these values? [no]: yes Enrollment principal: admin Password for admin@TESTRELM: Joining realm failed: HTTP response code is 301, not 200 Additional info: The master server seems to set up the forward zone properly, but not the reverse, this can be shown with : [root@qe-blade-12 ~]# dig qe-blade-04.testrelm ;; ANSWER SECTION: qe-blade-04.testrelm. 86400 IN A 10.16.76.35 dig -x 10.16.76.35 ;; ANSWER SECTION: 35.76.16.10.in-addr.arpa. 86400 IN PTR qe-blade-04.idm.lab.bos.redhat.com. The previous should return qe-blade-04.testrelm the dns ldap database on qe-blade-04 does appear to contain the reverse zone, but for some reason, I am unable to resolve the entries when doing a dns lookup. I am able to provide a server client pair for testing if needed.
https://fedorahosted.org/freeipa/ticket/363
I've corrected the issue, which led me to an error during client installation. Instead of successful discovery, this operation fails and user is asked to fill hostname of domain DNS server by hand. I might add that the failure is caused by resolver on client being unable to find hostname of the master server (vm-074.testrealm in my case), which makes sense to me, because the master server is just a forwarder and doesn't contain any records of hosts in testrealm domain by default. Am I right?
The patch is included in git repo, should be available with the next release.
Setting this bug to modified, so that it can be verified. The bug should not have been closed.