On Thu, 2015-08-20 at 15:11 +0200, Petr Vobornik wrote: > On 08/20/2015 02:46 PM, Martin Basti wrote: > > > > > > On 08/20/2015 02:40 PM, Oleg Fayans wrote: > >> Done. https://fedorahosted.org/freeipa/ticket/5240 > >> > >> The initial question however is still unsolved: why does > >> ipa-replica-prepare behaves differently on fedora and rhel? I thought, > >> rhel host had more than one reverse zone, but it's not the case.
Not sure why the difference but you can pass --no-host-dns to ipa-replica-install, it should skip the reverse zone check. We may want to add a ticket to make the reverse check just a warning, installation should not fail, but the default is to stop in unattended mode unfortunately. > > Can you try fedora on the same machine? > > Are you sure that both systems has the same configuration. E.g. one > could have only IPv4 but the other also IPv6? > > >> > >> > >> On 08/20/2015 01:43 PM, Martin Basti wrote: > >>> It could be, please file a bug. > >>> > >>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: > >>>> Hi Martin, > >>>> > >>>> I guess, I know where is the problem. During replica-install the > >>>> replica tries to resolve it's own ip to a hostname to check whether > >>>> the dns is configured correctly. And fails, since we specified > >>>> --no-reverse during the replica preparation on master. > >>>> This looks like a bug to me. > > Why is that a bug? Where should ipa-replica-prepare put a SRV record if > no reverse zone is created? SRV records are not stored in the reverse zone, we should work just fine w/o a reverse zone. > I.e. if I do not want to add them by ipa-replica-prepare e.g. because > they are not managed in IPA then they have to be added to DNS > server(whatever server it is) by other means. We *should* be able to work fine w/o reverse zones or with reverse zones that point to bogus names. I think this is something we SHOULD test because it is a normal network condition in some organizations (because they can't control reverse). If something fails if reverse is wrong/missing we need to fix it, because relying on reverse resolution is broken (vs security) anyway and we should not. Simo. > > > >>>> > >>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: > >>>>> > >>>>> > >>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: > >>>>>> > >>>>>> > >>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: > >>>>>>>> Hi Martin > >>>>>>>> > >>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 > >>>>>>>>>> The tests keep failing at the step of preparing the replica. I > >>>>>>>>>> figured > >>>>>>>>>> out, the ipa-replica-prepare with the standard parameters > >>>>>>>>>> requests > >>>>>>>>>> reverse zone info (does not do it in fedora) which causes the > >>>>>>>>>> test to > >>>>>>>>>> fail. > >>>>>>>>>> > >>>>>>>>>> Does anyone know why does it do it? We can, of course update our > >>>>>>>>>> tests > >>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it > >>>>>>>>>> behaves > >>>>>>>>>> differently depending on the platform. > >>>>>>>>>> > >>>>>>>>>> The system is > >>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com > >>>>>>>>>> > >>>>>>>>>> The command looks like this: > >>>>>>>>>> > >>>>>>>>>> [root@dell-pe1950-06 ~]# ipa-replica-prepare -p '<password>' > >>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com > >>>>>>>>>> Do you want to configure the reverse zone? [yes]: > >>>>>>>>>> > >>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use > >>>>>>>>> --no-reverse > >>>>>>>>> option. > >>>>>>>>> > >>>>>>>>> Did you test fedora on the same machine? > >>>>>>>> No, it's a beaker-provisioned vm. > >>>>>>>> > >>>>>>>> I added a --no-reverse to the install_replica method in > >>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. > >>>>>>>> However, now the test fails at the step of ipa-replica-install: > >>>>>>>> > >>>>>>>> [root@dell-pe1950-05 ~]# ipa-replica-install -U -p '<password>' -w > >>>>>>>> '<password>' --ip-address 10.34.54.25 > >>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg > >>>>>>>> > >>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 > >>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' > >>>>>>>> will > >>>>>>>> be disabled in favor of ntpd > >>>>>>>> > >>>>>>>> ipa : ERROR Unable to resolve the IP address > >>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts > >>>>>>>> and DNS name resolution > >>>>>>>> > >>>>>>> > >>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP > >>>>>>> address of replica or master. > >>>>>>> > >>>>>>> > >>>>>> Does the resolv.conf point to master on replica? > >>>>> It's an ip address of the replica. And yes, it does point to master's > >>>>> ip. > >>>>> > >>>> > >>> > >> > > > > > -- > Petr Vobornik > -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code