#5686 ipa-replica-prepare and ipa-replica-install should not fail if PTR record is not resolvable
Closed: Fixed None Opened 8 years ago by ofayans.

In dual-stacked networks (with both ipv4 and ipv6 enabled) when I run ipa-replica-prepare without --ip-address option, ipa master tries to resolve ipv6 address of the future replica first and fails if the attempt is unsuccessful:

# ipa-replica-prepare -p <password> <replica_hostname>
You might use the --ip-address option to create a DNS entry if the DNS zone is managed by IPA.
Unable to resolve the IP address 2620:52:0:224e:21a:4aff:fe23:1210 to a host name, check /etc/hosts and DNS name resolution
The ipa-replica-prepare command failed.

It should try both ipv4 and ipv6 addresses instead.


Can you please run command in debug mode?

I'm sure that this is not related to --ip-address option, just ipa-replica-prepare got both A and AAAA records for <replica_hostname> and PTR validation failed for IPv6 address.

On a fresh vm the issue does not reproduce. However, the replica preparation is
broken:

    [root@vm-088 ofayans]# ipa-replica-prepare -p $admin_password
    $replica_hostname
    You might use the --ip-address option to create a DNS entry if the DNS zone
    is managed by IPA.
    Unable to resolve the IP address $replica_ip to a host name, check
    /etc/hosts and DNS name resolution
    The ipa-replica-prepare command failed.
    [root@vm-088 ofayans]# dig -x $replica_ip

    ; <<>> DiG 9.10.3-RedHat-9.10.3-2.fc23 <<>> -x $replica_ip
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7205
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;$replica_ip_reverted.in-addr.arpa.arpaINPTR

    ;; AUTHORITY SECTION:
    10.IN-ADDR.ARPA.ARPA86400INSOA10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400

    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu Feb 18 14:39:53 CET 2016
    ;; MSG SIZE  rcvd: 103

When I explicitly use the nameserver configured as forwarder for dig request,
it works:

{{{
[root@vm-088 ofayans]# dig @$forwarder_ip -x $replica_ip
; <<>> DiG 9.10.3-RedHat-9.10.3-2.fc23 <<>> @$forwarder_ip -x $replica_ip
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25325
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

I assume that you have server with DNS, can it be this issue? https://fedorahosted.org/bind-dyndb-ldap/ticket/160

I have the same issue in a lab. There is PTR record for A but not for AAAA. Discovery should try both IPs.

Workaround is to use --no-host-dns option.

Note: my comment was related to promotion of replica using ipa-replica-install

Replying to [comment:4 mbasti]:

I assume that you have server with DNS, can it be this issue? https://fedorahosted.org/bind-dyndb-ldap/ticket/160

Yes, the master was installed with "--setup-dns" option. These issues do seem related.

devel mtg notes:

  • if some PTR is wrong (pointing to a wrong host name) then print big FAT warning
  • if there is no PTR just print a warning and continue

It is needed also for 4.2.4 testing.

master:

  • 8f01b47 Make PTR records check optional for IPA installation

ipa-4-3:

  • bd725f4 Make PTR records check optional for IPA installation

ipa-4-2:

  • e66ce1a Make PTR records check optional for IPA installation

Metadata Update from @ofayans:
- Issue assigned to mbasti
- Issue set to the milestone: FreeIPA 4.2.4

7 years ago

Login to comment on this ticket.

Metadata