On 08/20/2015 03:19 PM, Simo Sorce wrote:
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.

Sorry, I meant PTR

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.


Petr Vobornik

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to