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
- I do not think we should rely on enumeration. I think we should do a
lookup since these operations will be rare.
- SSSD should have a configuration option that specifies how short the
filter can be - default 3 characters (number of characters without
asterisk). If application provided a shorter filter becuase user typed
less characters SSSD would return error indicating that filter is too
short. We would need to teach oVirt to respect such errors.
- We need to review this with Jan, Barak and Alon.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.