On 15/01/15 20:24, Martin Basti wrote:
On 15/01/15 17:13, David Kupka wrote:
On 01/15/2015 03:22 PM, David Kupka wrote:
On 01/15/2015 12:43 PM, David Kupka wrote:
On 01/12/2015 06:34 PM, Martin Basti wrote:
On 09/01/15 14:43, David Kupka wrote:
On 01/07/2015 04:15 PM, Martin Basti wrote:
On 07/01/15 12:27, David Kupka wrote:
https://fedorahosted.org/freeipa/ticket/4249

Thank you for patch:

1)
-        root_logger.error("Cannot update DNS records! "
-                          "Failed to connect to server '%s'.",
server)
+        ips = get_local_ipaddresses()
+    except CalledProcessError as e:
+        root_logger.error("Cannot update DNS records. %s" % e)

IMO the error message should be more specific,  add there something
like
"Unable to get local IP addresses". at least in log.debug()

2)
+    lines = ipresult[0].replace('\\', '').split('\n')

.replace() is not needed

3)
+    if len(ips) == 0:

if not ips:

is more pythonic by PEP8


Thanks for catching these. Updated patch attached.

merciful NACK

Thank you for the patch, unfortunately I hit one issue which needs to be
resolved.

If "sync PTR" is activated in zone settings, and reverse zone doesn't
exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print
Error message, 'DNS update failed'. In fact, all A/AAAA records was
succesfully updated, only PTR records failed.

Bind log:
named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at
'vm-101.example.com' AAAA

named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA
'vm-101.example.com.' refused: unable to find active reverse zone for IP
address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found

With IPv6 we have several addresses from different reverse zones and
this situation may happen often.
I suggest following:
1) Print list of addresses which will be updated. (Now if update fails,
user needs to read log, which addresses installer tried to update)
2) Split nsupdates per A/AAAA record.
3a) If failed, check with DNS query if A/AAAA and PTR record are there
and print proper error message
3b) Just print A/AAAA (or PTR) record may not be updated for particular
IP address.

Any other suggestions are welcome.


After long discussion with DNS and UX guru I've implemented it this way:
1. Call nsupdate only once with all updates.
2. Verify that the expected records are resolvable.
3. If no print list of missing A/AAAA, list of missing PTR records and
list to mismatched PTR record.

As this is running inside client we can't much more and it's up to user
to check what's rotten in his DNS setup.

Updated patch attached.


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



One more change to behave well in -crazy- exotic environments that
resolves more PTR records for single IP.



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Yet another change to make language nerds and our UX guru happy :-)
Sorry, but NACK.

1) BIND/dyndb-ldap bug? (if sync_ptr is enabled)
+        try:
+            answers = dns.resolver.query(fqdn, record_type)
+        except dns.resolver.NoAnswer:
+            if record_type == dns.rdatatype.A:
+                root_logger.debug('No A record for %s' % fqdn)
+            elif record_type == dns.rdatatype.AAAA:
+                root_logger.debug('No AAAA record for %s' % fqdn)
+        except dns.exception.DNSException as e:
+            root_logger.debug('DNS resolver error: ' % e)
+        else:
+            for rdata in answers:
+                try:
+                    missing_ips.remove(rdata.address)
+                except ValueError:
+                    extra_ips.append(rdata.address)

This somehow doesn't work, for missing A/AAAA records (4 A/AAAA records expected)
$host `hostname`
vm-024.example.com has address 10.16.78.24
vm-024.example.com has IPv6 address fed0:babe:baab:0:21a:4aff:fe10:4e37
But I get *no warning*.

== Why ==
Probably bug in BIND, all AAAA/A records *exists for several seconds*, then bind remove all A/AAAA records without PTR record. (Needs more investigation, maybe it is dependent on bind version, in previous testing, the A/AAAA records stay untouched )

This it the older journal from the *same machine* with same packages, where record without PTR haven't been deleted after few seconds EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at 'vm-101.example.com' A EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at 'vm-101.example.com' AAAA EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' A EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' AAAA vm-101.example.com.' refused: unable to find active reverse zone for IP address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found EXAMPLE.COM: updating zone 'idm.example.com/IN': adding an RR at 'vm-101.example.com' AAAA vm-101.example.com.' refused: unable to find active reverse zone for IP address 'fed0:babe:baab:0:21a:4aff:fe10:4eaa': not found EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' AAAA vm-101.example.com.' refused: unable to find active reverse zone for IP address 'fec0:0:a10:4c00:21a:4aff:fe10:4eaa': not found
* There is no additional lines related with records above*

Current journal continues with removing records.

The only one change it the new script is checking status of records with DNS query.

IMO expected behavior is, the A/AAAA records should stay untouched.

We can't test if records are there with this BIND behavior.

bind-9.9.6-6.P1.fc21.x86_64
bind-dyndb-ldap-6.1-1.fc21.x86_64

I investigated deeper, this issue is somehow related with option --enable-dns-update (and enabled PTR SYNC).
With this option, only A/AAAA records with PTR are updated.
Without this option all A/AAAA records are updated (with or without PTR)

Is this caused by SSSD?


2)
You should also catch
NXDOMAIN - the query name does not exist
exception instead of NoAnswer, to have proper debug results. NoAnswer means that the resolver doesnt respond.

Can you also print to debug log, which addresses you test?

3)
+        except dns.exception.DNSException as e:
+            root_logger.debug('DNS resolver error: ' % e)

This will not work, dns python exceptions doesn't contain any text

Log:
2015-01-15T17:42:44Z DEBUG DNS resolver error:
2015-01-15T17:42:46Z DEBUG DNS resolver error:
2015-01-15T17:42:46Z DEBUG DNS resolver error:



--
Martin Basti

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to