On Wed, Jan 07, 2015 at 03:41:01PM -0500, Simo Sorce wrote:
> On Wed, 07 Jan 2015 15:25:30 -0500
> Dmitri Pal <dpal(a)redhat.com> wrote:
>
>> On 01/07/2015 03:05 PM, Simo Sorce wrote:
>>> On Tue, 06 Jan 2015 09:59:08 -0500
>>> Dmitri Pal <dpal(a)redhat.com> wrote:
>>>
>>>> On 01/06/2015 05:54 AM, Jakub Hrozek wrote:
>>>>> On Tue, Jan 06, 2015 at 11:31:55AM +0100, Pavel Březina wrote:
>>>>>>>> *Users*
>>>>>>>> Do we want also to have methods ListDomainUsers() and
>>>>>>>> ListUsers() without the name filter?
>>>>>>> To list all? What about using '*' for that?
>>>>>> We can implement it this way internally, but exposing an easier
>>>>>> way to the consumers is nice, imho.
>>>>> I'm not too opposed, although I prefer minimal APIs.
>>>>>
>>>>>> However, do we actually want to allow to list all users? As
>>>>>> Dmitri suggested we may want to require the minimum filter
>>>>>> length since the number of users may be very high. The maximum
>>>>>> D-Bus message is 128MiB so I think we are good there but I think
>>>>>> it can be very time consuming to return all users without some
>>>>>> sort of paging.
>>>>> This feature is internally dependant on enumerate=true, where we
>>>>> already store all standard POSIX attributes (struct passwd, struct
>>>>> group) in-memory, do you think the D-Bus "enumeration"
provides
>>>>> that much overhead?
>>>>>
>>>>> Paging would be really complex, we'd need to store the full
>>>>> results in-memory per-client anyway and then pass around some
>>>>> kind of cookie to resume iteration..
>>>>>
>>>>> In a centralized environment, I wouldn't expect the listing
>>>>> commands to be used that commonly. Greeters or login managers
>>>>> (gdm) would typically use the cached users instead. Some
>>>>> applications (Hi, RHEV-M!) choose to display all their users in
>>>>> some kind of table and then I would expect them to implement
>>>>> paging themselves:
>>>>>
>>>>> for letter in a..z:
>>>>> users = ListUsersByNameFilter($letter)
>>>>>
>>>>>>>> Do we want some other filter options as well?
>>>>>>> In the design I wanted to keep the filtering simple. Unless
we
>>>>>>> receive some other requirements..
>>>>>> Yes, you suggested to allow only asterisk. Implement full
regular
>>>>>> expression efficiently as Dmitri would be quite problematic
since
>>>>>> ldb doesn't support regex lookup thus we would have to do
this
>>>>>> ourselves and therefore we would loose indices, or am I wrong?
>>>>> I guess we'd have to grab all the entries and filter them
>>>>> ourselves..
>>>>>
>>>>> (Yes, this is the reason I chose the asterisk notation in the
>>>>> first place) _______________________________________________
>>>>> sssd-devel mailing list
>>>>> sssd-devel(a)lists.fedorahosted.org
>>>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>>> Several points:
>>>>
>>>> - IMO having a full regular expression support will be an overhead.
>>>> - "Begins with" filtering with * to indicate the remaining part
is
>>>> good enough
>>> reasonable
>>>
>>>> - I do not think we should rely on enumeration. I think we should
>>>> do a lookup since these operations will be rare.
>>> Nope.
>>> This is the same thinking the implementers of the nss interface went
>>> through. And then users started using enumeration all the time.
>>>
>>> It may be ok to let users programmatically force full enumeration
>>> somehow. But the default should be to return only what is in cache.
>>> If you do otherwise people will test applications using * with 3
>>> users on the system and then fail spectacularly when there are
>>> actually 100K users in the directory.
>> I think there is a problem with the approach you suggest.
>>
>> Say there is an application that allows you to list groups starting
>> with a letter. It is used to define roles for application
>> administration.
>>
>> Assume that there is a group "Agroup". It is a new group that does
>> not have users yet. But it was created for use with the application
>> so that roles can be associated with this group. The admin of the
>> application thus wants to start using it.
>> This group will never be looked up if "A*" query will be run against
>> cache because it will not end up in cache. That would force admin to
>> turn full enumeration on SSSD. This is bad.
> What matters is the '*' does not do enumeration, if 'ABC*' causes an
> online lookup it is fine imo.
Yes, this is exactly what I was proposing. However, handling 'ABC*' on
the back end side must be implemented, currently we only handle a single
entry or enumeration.
I might have confused you because I proposed to first finish the DBus
*responder* work and temporarily require enumeration until we extend the
back end.
I hope it makes sense now.
As long as the work is bound to the same milestone the order does not
matter.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.