[SSSD] [PATCHES] DYDNDS: update quality of input for nsupdate

Pavel Reichl preichl at redhat.com
Tue Oct 6 08:03:47 UTC 2015



On 10/06/2015 07:45 AM, Lukas Slebodnik wrote:
> On (05/10/15 14:14), Pavel Reichl wrote:
>> On 10/05/2015 02:08 PM, Petr Spacek wrote:
>>> On 5.10.2015 13:35, Pavel Reichl wrote:
>>>>
>>>>
>>>> On 10/05/2015 11:55 AM, Jakub Hrozek wrote:
>>>>> On Thu, Oct 01, 2015 at 01:15:10PM +0200, Pavel Reichl wrote:
>>
>> [snip]
>>
>>>>> Additionally, what versions of nsupdate do /not/ have the realm command?
>>>>> If they are very old, can we just drop the support for them? (I haven't
>>>>> checked, just asking..)
>>>>
>>>> It seems to me that support for REALM keyword was introduced in bind 9.9.0 in
>>>> 'bug' 2929 (https://kb.isc.org/article/AA-00496/0/). In my opinion this is old
>>>> version and we can expect newer version to be present on rhel and fedora.
>>>
>>> In fact the option 'realm' was added in BIND 9.8.0a1, which is available in
>>> RHEL 6.x. IMHO it is okay to ignore older versions because they would not work
>>> (for various reasons) anyway :-)
>>>
>>> Petr^2 Spacek
>>>
>>
>> Thanks Petr, I filled #2817 and assigned it to myself.
>>
>> Updated patches attached.
>>
>> Thanks!
>
>>From bdd7d705a218d3e2b450ddcefe65b57cd414765d Mon Sep 17 00:00:00 2001
>> From: Pavel Reichl <preichl at redhat.com>
>> Date: Fri, 24 Jul 2015 13:25:56 -0400
>> Subject: [PATCH 2/2] DYNDNS: improve nsupdate_msg_add_fwd()
>>
>> Update nsupdate_msg_add_fwd() to group commands by address family
>> processed IP address belongs to.
>>
>> It's better to group removing old A addresses and adding new A
>> addresses in a single transaction. Same goes for AAAA addresses.
>>
>> Separate transaction for A and AAAA addresses updates are important
>> because server might block updates for one of these families and thus
>> the update even for the non-blocked address family would unnecessarily
>> fail.
>>
>> For more details please see:
>> https://fedorahosted.org/sssd/wiki/DesignDocs/DDNSMessagesUpdate
>>
>> Resolves:
>> https://fedorahosted.org/sssd/ticket/2495
>> ---
>> src/providers/dp_dyndns.c      |  56 ++++++---
>> src/tests/cmocka/test_dyndns.c | 280 ++++++++++++++++++++++++++++++++++++++++-
>> 2 files changed, 316 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/tests/cmocka/test_dyndns.c b/src/tests/cmocka/test_dyndns.c
>> index 815acf6963916bbfa5069c700360fa2fb2ca4e1e..43df0e1b58793e2efe55ea1317fc1f7ca8cc579f 100644
>> --- a/src/tests/cmocka/test_dyndns.c
>> +++ b/src/tests/cmocka/test_dyndns.c
>> @@ -355,6 +355,266 @@ void dyndns_test_addr_list_as_str_list(void **state)
>>      assert_true(check_leaks_pop(dyndns_test_ctx) == true);
>> }
>>
>>      struct sockaddr_in sin;
>> -    memset (&sin, 0, sizeof (sin));
>> +    memset(&sin, 0, sizeof (sin));
> Can somebody explain how is this chage rellated to the grouping A addresses
> into one transaction?

It's not related. It's just a little code style change being in the same function as other changes in this patch.

I'm aware that you recently became passionate about such irrelevant changes, however other developers seems not to mind.
Might be you can try to formulate such a rule for our code style guidelines and if agreed to we can adhere to it?

>
> Unrelated changes should not be part of another ticket.
> It just obfluscate output of git blame.
>
>
>>      sin.sin_family = AF_INET;
>>      sin.sin_addr.s_addr = inet_addr ("192.168.0.2");
>>      ret = sss_get_dualstack_addresses(dyndns_test_ctx,
>> @@ -436,7 +696,7 @@ void dyndns_test_dualstack_multiple_addresses(void **state)
>>      }
>>
>>      struct sockaddr_in sin;
>> -    memset (&sin, 0, sizeof (sin));
>> +    memset(&sin, 0, sizeof (sin));
>                              ^
> Moreover this change was half done. There is still extra space.
Yes, you are right. I'm just not sure it's worth to send another patch to fix such little problem.

>
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>


More information about the sssd-devel mailing list