[Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL

[Simo Sorce]

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 at 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 at 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