On Thu, Jan 08, 2015 at 09:16:53PM +0100, Pavel Březina wrote: > 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 <d...@redhat.com> wrote: > >>>> > >>>>>On 01/07/2015 03:05 PM, Simo Sorce wrote: > >>>>>>On Tue, 06 Jan 2015 09:59:08 -0500 > >>>>>>Dmitri Pal <d...@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@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. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
