On 01/06/2015 03:59 PM, Dmitri Pal 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@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.
In my opinion:
List methods (i.e. those that return list of objects) should return only
those objects that are already cached. If the caller wants all of them,
enumeration should be turned on.
Find methods (i.e. those that return single object) can perform a
lookup, similar to what nss responder does.
- 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.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
