On Thu, Jan 08, 2015 at 09:35:42AM -0500, Dmitri Pal wrote:
On 01/08/2015 04:05 AM, Jakub Hrozek wrote:
>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.
OK, I filed
https://fedorahosted.org/sssd/ticket/2553 into the same
milestone.