On 01/08/2015 07:44 PM, Jakub Hrozek wrote:
>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.
This brings another question. Because we are talking about
ListUsersByFilter() that returns a list of object paths the only thing that
is needed to construct such path is UID. So we can avoid membership
evaluation here which would reduce load and processing time.
The caller will be probably interested mostly in user name, is that correct?
So we can skip membership evaluation at all unless group property is
requested.
Yes, we know updating membership is a costly operation, that's why there is a
separate method for that.