Hi,
this patch should fix trac ticket #810 and fixes pro-actively a potential issue with the realm.
bye, Sumit
On Fri, 25 Feb 2011 13:06:22 +0100 Sumit Bose sbose@redhat.com wrote:
Hi,
this patch should fix trac ticket #810 and fixes pro-actively a potential issue with the realm.
bye, Sumit
NACK, not all IPA server are necessarily also a DNS server. Specifying a server may make the code try to reach a server that doesn't host a DNS instance.
I see 2 possibilities here. Try once with the server explicitly and if it fails fallback to let nsupdate find the server from the SOA record. Or always let nsupdate find the SOA record and try to fallback to explicit server if that fails.
Simo.
On Fri, Feb 25, 2011 at 08:05:08AM -0500, Simo Sorce wrote:
On Fri, 25 Feb 2011 13:06:22 +0100 Sumit Bose sbose@redhat.com wrote:
Hi,
this patch should fix trac ticket #810 and fixes pro-actively a potential issue with the realm.
bye, Sumit
NACK, not all IPA server are necessarily also a DNS server. Specifying a server may make the code try to reach a server that doesn't host a DNS instance.
I see 2 possibilities here. Try once with the server explicitly and if it fails fallback to let nsupdate find the server from the SOA record. Or always let nsupdate find the SOA record and try to fallback to explicit server if that fails.
Thank you for the review. I took the second possibility, because I think it is the more general approach. There might be one drawback. Depending on how the IPA DNS server sets the master name field in the SOA record all dynamic updates might be send to a single server. If you prefer the other possibility in this case I can easily modify the patch.
bye, Sumit
Simo.
-- Simo Sorce * Red Hat, Inc * New York
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/28/2011 12:38 PM, Sumit Bose wrote:
On Fri, Feb 25, 2011 at 08:05:08AM -0500, Simo Sorce wrote:
On Fri, 25 Feb 2011 13:06:22 +0100 Sumit Bose sbose@redhat.com wrote:
Hi,
this patch should fix trac ticket #810 and fixes pro-actively a potential issue with the realm.
bye, Sumit
NACK, not all IPA server are necessarily also a DNS server. Specifying a server may make the code try to reach a server that doesn't host a DNS instance.
I see 2 possibilities here. Try once with the server explicitly and if it fails fallback to let nsupdate find the server from the SOA record. Or always let nsupdate find the SOA record and try to fallback to explicit server if that fails.
Thank you for the review. I took the second possibility, because I think it is the more general approach. There might be one drawback. Depending on how the IPA DNS server sets the master name field in the SOA record all dynamic updates might be send to a single server. If you prefer the other possibility in this case I can easily modify the patch.
bye, Sumit
We discussed this approach yesterday on IRC with Simo and the result is that it's fine. This patch also works OK, so ACK unless Simo has any other reservations.
A single server is always hit with updates because of a bug in IPA - Bind instances on replicas are not added as NS records (tracked as ticket #1034 in freeipa trac).
Jakub
On Thu, 03 Mar 2011 14:29:47 +0100 Jakub Hrozek jhrozek@redhat.com wrote:
We discussed this approach yesterday on IRC with Simo and the result is that it's fine. This patch also works OK, so ACK unless Simo has any other reservations.
A single server is always hit with updates because of a bug in IPA - Bind instances on replicas are not added as NS records (tracked as ticket #1034 in freeipa trac).
Pushed to master.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/03/2011 06:37 PM, Simo Sorce wrote:
On Thu, 03 Mar 2011 14:29:47 +0100 Jakub Hrozek jhrozek@redhat.com wrote:
We discussed this approach yesterday on IRC with Simo and the result is that it's fine. This patch also works OK, so ACK unless Simo has any other reservations.
A single server is always hit with updates because of a bug in IPA - Bind instances on replicas are not added as NS records (tracked as ticket #1034 in freeipa trac).
Pushed to master.
Simo.
Also pushed to sssd-1-5
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org