[SSSD] IFP: Implement methods to get and list domain objects

Pavel Březina pbrezina at redhat.com
Mon May 26 20:33:22 UTC 2014


On 05/26/2014 05:45 PM, Jakub Hrozek wrote:
> On Thu, May 22, 2014 at 07:57:28PM +0200, Pavel Březina wrote:
>> On 05/21/2014 11:03 PM, Jakub Hrozek wrote:
>>> Hi,
>>>
>>> the attaches two patches implement DBus methods to retrieve SSSD domains
>>> using the system bus as well as two example getters that leverage the
>>> infrastructure to Get and GetAll the object properties.
>>>
>>> Pavel, I know you have a large patchset in a private tree that
>>> implements the other getters and moves the domain methods into a
>>> separate file. I'm fine with merging your and mine patches, I just
>>> wanted to get the ball rolling on the list. Feel free to reply with your
>>> patchset.
>>
>> Hi,
>> see the attachment.
>>
>> I squash all my patches to these five - mainly discarded the moving
>> the code around.
>>
>> I kept you as the author for the methods as I made only very minor
>> changes there. However, I took the ownership for the properties
>> since there only very little of your original code remains there - I
>> hope you don't mind.
>>
>> The next three patches implements the SSSD components interface
>> required for the OpenLMI provider. I'm sending it to this thread
>> since it depends on the domain patches anyway - there is enough
>> dependency fuzz already.
>>
>
>>  From 7e55b23741ed749e95e9d33184b0fd702b86bb46 Mon Sep 17 00:00:00 2001
>> From: Jakub Hrozek <jhrozek at redhat.com>
>> Date: Tue, 22 Apr 2014 15:38:08 +0200
>> Subject: [PATCH 1/5] IFP: Add ListDomains and FindDomainByName
>
> This one was acked by Pavel separately.
>

Hi,
thank you for the review. I'm sending new patches.

>> +
>> +    /* TODO: replace hardcoded values with option names from the provider */
>
> I don't like this at all, but I can't see another way with the current

Me neither, thus todo.

> code. Maybe we should add a new ID target for getting info about
> domains? I think the performance would be a non-issue since all that
> would be needed is an sbus round trip to the DP that would just reply
> right away. But any DP changes should be discussed on the list first --
> for now, just please file a ticket.

My first idea was to do it as a part of future failover refactoring (to 
make the failover context per domain, not per backend). The idea was to 
provide a dbus interface for a failover that would retrieve a list of 
current servers, also with their status etc.

>> +    if (strcasecmp(dom->provider, "ldap") == 0) {
>> +        option = backup == false ? "ldap_uri" : "ldap_backup_uri";
>> +    } else if (strcasecmp(dom->provider, "ipa") == 0) {
>> +        option = backup == false ? "ipa_server" : "ipa_backup_server";
>> +    } else if (strcasecmp(dom->provider, "ad") == 0) {
>> +        option = backup == false ? "ad_server" : "ad_backup_server";
>> +    } else {
>> +        ret = EINVAL;
>> +        goto done;
>> +    }



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-IFP-Implement-domain-getters.patch
Type: text/x-patch
Size: 36835 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140526/16085b9c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-confdb-add-confdb_list_all_domain_names.patch
Type: text/x-patch
Size: 3533 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140526/16085b9c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-utils-add-get_known_services.patch
Type: text/x-patch
Size: 2020 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140526/16085b9c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-IFP-Implement-SSSD-components.patch
Type: text/x-patch
Size: 61644 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140526/16085b9c/attachment-0003.bin>


More information about the sssd-devel mailing list