[SSSD] [PATCH] sudo: provide automatic configuration of machine hostnames

Pavel Březina pbrezina at redhat.com
Thu Jul 26 09:37:21 UTC 2012


On 07/25/2012 04:14 PM, Jakub Hrozek wrote:
> On Wed, Jul 25, 2012 at 01:29:26PM +0200, Jan Zelený wrote:
>> Dne středa 25 července 2012 10:34:15, Pavel Březina napsal(a):
>>> On 07/24/2012 02:16 PM, Pavel Březina wrote:
>>>> On 24.7.2012 14:11, Simo Sorce wrote:
>>>>> On Tue, 2012-07-24 at 12:21 +0200, Pavel Březina wrote:
>>>>>> +#include <unistd.h>
>>>>>> +#include <bits/local_lim.h> // HOST_NAME_MAX
>>>>>> +#include <string.h>
>>>>>
>>>>> I guess you attached the old patch.
>>>>>
>>>>> Simo.
>>>>
>>>> Not exactly. I didn't commit the changes. Thanks. :-)
>>>> The correct patch is attached.
>>>
>>> I'm sending this patch one more time. Now with updated manual page.
>>
>> I assume you are going to implement the function to initialize resolver
>> separately? If yes, either create a ticket for that or send another patch
>> right now so we don't forget it.
>>
>> The rest of the patch is ok, all previous concerns are addressed.
>>
>> Thanks
>> Jan
>
> Sorry, still a nack. The patch violates the tevent_req style.
>
> The steps of sdap_sudo_get_hostnames are named
> sdap_sudo_get_hostnames_send sdap_sudo_get_hostnames_resolv_done and
> sdap_sudo_get_hostnames_recv. Moreover, sdap_sudo_get_hostnames_done,
> which is just callback attached to the async request created by
> sdap_sudo_get_hostnames_send calls sdap_sudo_get_hostnames_recv. That's
> very confusing, it looks like some circular request.
>
> The asynchronous functions that perform "foo" must be named "foo_send",
> "foo_done", and "foo_recv" and should be placed in this order in the
> source file. If the request consists of multiple steps, they may be named
> differently, but when the request ends, there should be foo_done callback
> called. This may seem like nitpicking, but the asynchronous processing is
> hard to follow as it is..
>
> Also, please check lines that are over the 80-characters limit.

Done.

After a discussion with Jakub, it seems that 
CONFDB_DOMAIN_RESOLV_OP_TIMEOUT should be used after all.

I have created a ticket to create utility functions to create a new 
context and to handle CONFDB_DOMAIN_RESOLV_TIMEOUT timeout.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sudo-ldap-provider-support-autoconfiguration-of-host.patch
Type: text/x-patch
Size: 13522 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120726/bc3fc33e/attachment.bin>


More information about the sssd-devel mailing list