https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
*Domains* The interface from the design page is already implemented. Is there any method or property that is missing?
*Users* Do we want also to have methods ListDomainUsers() and ListUsers() without the name filter?
Do we want some other filter options as well?
Should extraAttributes be present in Properties.GetAll() output?
What is UpdateGroupList() supposed to do?
Property groups - do we really want to return list of object paths instead of pure group names? I think that more common use case will want only the names. Or we can even implement both.
*Groups* Basically the same questions and per Users.
On 12/16/2014 08:26 AM, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
If this is a question about API naming then I do not think there are any specific requirements.
*Domains* The interface from the design page is already implemented. Is there any method or property that is missing?
List domains with a filter which a regular expressions is the requirement. Filter can be *. You can use any syntax for regex. For domains the filter is optional.
*Users* Do we want also to have methods ListDomainUsers() and ListUsers() without the name filter?
I think this is dangerous. I would say no.
Do we want some other filter options as well?
I think we want SSSD to return an error is it thinks a filter is too short. It should be at least on character, may be 2-3. We would need to check with RHEV and others. The caller would need to be able to handle the error.
Should extraAttributes be present in Properties.GetAll() output?
Yes, if they are configured to be exposed.
What is UpdateGroupList() supposed to do?
I think it is to refresh the cache with most recent group info for a specific user. I suspect it also returns the updated list.
Property groups - do we really want to return list of object paths instead of pure group names? I think that more common use case will want only the names. Or we can even implement both.
For now we need just names. If we need objects we can add an interface later.
I am not sure if we want to have an option to indicate that local cache is good enough and call does not need to go over the wire and can be served by cached data only.
*Groups* Basically the same questions and per Users.
Same answers.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
*Domains* The interface from the design page is already implemented. Is there any method or property that is missing?
I'm not aware of any. Maybe in the future, we may add some online/offline status check, when we implement that in the deamon, but for now I think we're good.
*Users* Do we want also to have methods ListDomainUsers() and ListUsers() without the name filter?
To list all? What about using '*' for that?
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..
Should extraAttributes be present in Properties.GetAll() output?
Yes, I think it would be a bug if they're not :-)
What is UpdateGroupList() supposed to do?
Update the group property you asked about below. Basically re-run initgroups().
Property groups - do we really want to return list of object paths instead of pure group names? I think that more common use case will want only the names. Or we can even implement both.
IIRC Stef requested object paths as being more common in the D-Bus world.
On 01/06/2015 11:10 AM, Jakub Hrozek wrote:
On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
*Domains* The interface from the design page is already implemented. Is there any method or property that is missing?
I'm not aware of any. Maybe in the future, we may add some online/offline status check, when we implement that in the deamon, but for now I think we're good.
*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.
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.
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?
Should extraAttributes be present in Properties.GetAll() output?
Yes, I think it would be a bug if they're not :-)
Ok.
What is UpdateGroupList() supposed to do?
Update the group property you asked about below. Basically re-run initgroups().
Ok.
Property groups - do we really want to return list of object paths instead of pure group names? I think that more common use case will want only the names. Or we can even implement both.
IIRC Stef requested object paths as being more common in the D-Bus world.
Ok.
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)
On 01/06/2015 11: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?
I can't say that without any performance tests... maybe not. We will do it and we shall see.
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)
Dmitri, is full regex support needed or is '*' wildcard enough?
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. - 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.
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.
On Wed, Jan 07, 2015 at 11:07:05AM +0100, Pavel Březina wrote:
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.
Yes, but as a second step, because back end currently only supports looking up a single entry (name=dpal) or all of them (name=*) which triggers enumeration.
But requiring enumeration /now/ and working on the filter-based lookups later would allow us to finish the dbus responder changes already.
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.
I think we'll need to add filter-based lookups as well to the back end. Requiring enumeration is simply a no-go in large production systems.
On Tue, 06 Jan 2015 09:59:08 -0500 Dmitri Pal dpal@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.
- 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.
I am not entirely sure about this, in most applications it will not be easy to return such errors to users.
Simo.
On 01/07/2015 03:05 PM, Simo Sorce wrote:
On Tue, 06 Jan 2015 09:59:08 -0500 Dmitri Pal dpal@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. IMO there should be a way for those queries to actually go online. We can, however, not process all results. We can explicitly say "first 10 or 20 results and that is it". It can be an argument of the call with the default being a value in sssd.conf.
- 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.
I am not entirely sure about this, in most applications it will not be easy to return such errors to users.
Simo.
I think apps can popup a message saying that filter is too short easily. It is a new interface to use anyways.
On Wed, 07 Jan 2015 15:25:30 -0500 Dmitri Pal dpal@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@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.
IMO there should be a way for those queries to actually go online. We can, however, not process all results. We can explicitly say "first 10 or 20 results and that is it". It can be an argument of the call with the default being a value in sssd.conf.
It may make sense to think of a "ranged" interface for wildcard lookups, where you have to explicitly provide the range you want capped to a max length defined in sssd conf, and if you exceed that size you get an error.
This way users are forced to think about how many result they want/can process.
So the wildcard interface will be different from exact match interface.
Simo.
On 01/07/2015 03:41 PM, Simo Sorce wrote:
On Wed, 07 Jan 2015 15:25:30 -0500 Dmitri Pal dpal@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@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.
IMO there should be a way for those queries to actually go online. We can, however, not process all results. We can explicitly say "first 10 or 20 results and that is it". It can be an argument of the call with the default being a value in sssd.conf.
It may make sense to think of a "ranged" interface for wildcard lookups, where you have to explicitly provide the range you want capped to a max length defined in sssd conf, and if you exceed that size you get an error.
This way users are forced to think about how many result they want/can process.
So the wildcard interface will be different from exact match interface.
Simo.
how about:
entries[] = lookup(string filter, unsigned total);
Filter can be: - string without asterisk (then there will be an exact match search online) - string with asterisk or just asterisk (in this case function would search for "total" number of results only)
if total is 0 then a configured maximum value from sssd.conf will be used. Default 30 would probably be enough.
In this case * will go online but for only 30 results max. It is similar to -z option in the ldapsearch.
Does that make sense?
On Wed, 07 Jan 2015 16:03:38 -0500 Dmitri Pal dpal@redhat.com wrote:
On 01/07/2015 03:41 PM, Simo Sorce wrote:
On Wed, 07 Jan 2015 15:25:30 -0500 Dmitri Pal dpal@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@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.
IMO there should be a way for those queries to actually go online. We can, however, not process all results. We can explicitly say "first 10 or 20 results and that is it". It can be an argument of the call with the default being a value in sssd.conf.
It may make sense to think of a "ranged" interface for wildcard lookups, where you have to explicitly provide the range you want capped to a max length defined in sssd conf, and if you exceed that size you get an error.
This way users are forced to think about how many result they want/can process.
So the wildcard interface will be different from exact match interface.
Simo.
how about:
entries[] = lookup(string filter, unsigned total);
Filter can be:
- string without asterisk (then there will be an exact match search
online)
- string with asterisk or just asterisk (in this case function would
search for "total" number of results only)
if total is 0 then a configured maximum value from sssd.conf will be used. Default 30 would probably be enough.
In this case * will go online but for only 30 results max. It is similar to -z option in the ldapsearch.
Does that make sense?
How do you get the next 30 ?
Also the query may be slow no matter what you set if you make it at all with '*'.
We can use paged serches with some servers, but not all of them support this and some will be slow anyway.
Simo.
On 01/07/2015 04:06 PM, Simo Sorce wrote:
On Wed, 07 Jan 2015 16:03:38 -0500 Dmitri Pal dpal@redhat.com wrote:
On 01/07/2015 03:41 PM, Simo Sorce wrote:
On Wed, 07 Jan 2015 15:25:30 -0500 Dmitri Pal dpal@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@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.
IMO there should be a way for those queries to actually go online. We can, however, not process all results. We can explicitly say "first 10 or 20 results and that is it". It can be an argument of the call with the default being a value in sssd.conf.
It may make sense to think of a "ranged" interface for wildcard lookups, where you have to explicitly provide the range you want capped to a max length defined in sssd conf, and if you exceed that size you get an error.
This way users are forced to think about how many result they want/can process.
So the wildcard interface will be different from exact match interface.
Simo.
how about:
entries[] = lookup(string filter, unsigned total);
Filter can be:
- string without asterisk (then there will be an exact match search
online)
- string with asterisk or just asterisk (in this case function would
search for "total" number of results only)
if total is 0 then a configured maximum value from sssd.conf will be used. Default 30 would probably be enough.
In this case * will go online but for only 30 results max. It is similar to -z option in the ldapsearch.
Does that make sense?
How do you get the next 30 ?
Also the query may be slow no matter what you set if you make it at all with '*'.
We can use paged serches with some servers, but not all of them support this and some will be slow anyway.
Simo.
I do not need next 30. This is the whole point of the filter.
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@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@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.
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@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@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.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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@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@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.
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@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@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.
On 01/08/2015 03:16 PM, 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 dpal@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@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.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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 dpal@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@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.
On 01/09/2015 09:59 AM, Jakub Hrozek wrote:
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 dpal@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@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.
Ok. I will prepare a design page that will cover all this.
On 01/06/2015 11:10 AM, Jakub Hrozek wrote:
On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
Do we agree on the following interface schema? Or do you have other suggestions?
/ifp/Users ifp.Users /ifp/Users/* ifp.Users.User
Methods will drop 'Users' keyword. I.e. ifp.Users.List() instead of ifp.Users.ListUsers().
I though about ifp.User for the subtree but I don't really like when interface name differs only in the ending 's'. That is quite error prone to me.
On Wed, Jan 07, 2015 at 11:02:39AM +0100, Pavel Březina wrote:
On 01/06/2015 11:10 AM, Jakub Hrozek wrote:
On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
Do we agree on the following interface schema? Or do you have other suggestions?
/ifp/Users ifp.Users /ifp/Users/* ifp.Users.User
Methods will drop 'Users' keyword. I.e. ifp.Users.List() instead of ifp.Users.ListUsers().
I though about ifp.User for the subtree but I don't really like when interface name differs only in the ending 's'. That is quite error prone to me.
What about changing infopipe to ifp? Or is that a typo?
On 01/07/2015 12:00 PM, Jakub Hrozek wrote:
On Wed, Jan 07, 2015 at 11:02:39AM +0100, Pavel Březina wrote:
On 01/06/2015 11:10 AM, Jakub Hrozek wrote:
On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
Do we agree on the following interface schema? Or do you have other suggestions?
/ifp/Users ifp.Users /ifp/Users/* ifp.Users.User
Methods will drop 'Users' keyword. I.e. ifp.Users.List() instead of ifp.Users.ListUsers().
I though about ifp.User for the subtree but I don't really like when interface name differs only in the ending 's'. That is quite error prone to me.
What about changing infopipe to ifp? Or is that a typo?
I just wanted to shorten the name for the purpose of this conversation and avoid writing the whole org.freedesktop.sssd.infopipe. Sorry, I thought its obvious.
On Wed, Jan 07, 2015 at 01:39:03PM +0100, Pavel Březina wrote:
On 01/07/2015 12:00 PM, Jakub Hrozek wrote:
On Wed, Jan 07, 2015 at 11:02:39AM +0100, Pavel Březina wrote:
On 01/06/2015 11:10 AM, Jakub Hrozek wrote:
On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi, I have take the following tikcet that is about implementing D-Bus calls for domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface* At this moment we implement all List* and Find* methods on /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers() /infopipe/Users/$UID user specific methods and properties
instead of: /infopipe infopipe.ListUsers() /infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
Do we agree on the following interface schema? Or do you have other suggestions?
/ifp/Users ifp.Users /ifp/Users/* ifp.Users.User
Methods will drop 'Users' keyword. I.e. ifp.Users.List() instead of ifp.Users.ListUsers().
I though about ifp.User for the subtree but I don't really like when interface name differs only in the ending 's'. That is quite error prone to me.
What about changing infopipe to ifp? Or is that a typo?
I just wanted to shorten the name for the purpose of this conversation and avoid writing the whole org.freedesktop.sssd.infopipe. Sorry, I thought its obvious.
OK, then I agree with your proposal.
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
On 01/12/2015 09:51 AM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
1) There is a difference between allowing a wild card in a string and allowing it at the beginning or at end. In the latter case you can use much fast searches such as "begins with" and "ends with" or "contains" if you have *foo*. I think it should be explicit whether we allow regex or not becuase an asterisk in general would require regex. I thought we said we want to avoid regex.
2) In the min length configuration options please be explicit that we are talking about non wild card characters in the string.
On Mon, Jan 12, 2015 at 02:17:46PM -0500, Dmitri Pal wrote:
On 01/12/2015 09:51 AM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
- There is a difference between allowing a wild card in a string and
allowing it at the beginning or at end. In the latter case you can use much fast searches such as "begins with" and "ends with" or "contains" if you have *foo*. I think it should be explicit whether we allow regex or not becuase an asterisk in general would require regex. I thought we said we want to avoid regex.
- In the min length configuration options please be explicit that we are
talking about non wild card characters in the string.
I must have missed why do we have these options at all? The design page doesn't specify it either. Is it to avoid thrashing the LDAP server with searches too wide?
Also can you link https://fedorahosted.org/sssd/ticket/2553 with the design page?
The sections that have no signals and/or no properties should explicitly say "none", the current state looks a bit odd.
It would be nice to have a backlink to the original page.
On 01/12/2015 03:18 PM, Jakub Hrozek wrote:
On Mon, Jan 12, 2015 at 02:17:46PM -0500, Dmitri Pal wrote:
On 01/12/2015 09:51 AM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
- There is a difference between allowing a wild card in a string and
allowing it at the beginning or at end. In the latter case you can use much fast searches such as "begins with" and "ends with" or "contains" if you have *foo*. I think it should be explicit whether we allow regex or not becuase an asterisk in general would require regex. I thought we said we want to avoid regex.
- In the min length configuration options please be explicit that we are
talking about non wild card characters in the string.
I must have missed why do we have these options at all? The design page doesn't specify it either. Is it to avoid thrashing the LDAP server with searches too wide?
Yes. It was in the discussion. We do not want user to provide one letter and get tons of responses. However we can also do a different thing, we can limit the number of results returned and never return over some hard coded limit, for example, 300. With the default 30.
Also can you link https://fedorahosted.org/sssd/ticket/2553 with the design page?
The sections that have no signals and/or no properties should explicitly say "none", the current state looks a bit odd.
It would be nice to have a backlink to the original page. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, Jan 12, 2015 at 03:40:33PM -0500, Dmitri Pal wrote:
On 01/12/2015 03:18 PM, Jakub Hrozek wrote:
On Mon, Jan 12, 2015 at 02:17:46PM -0500, Dmitri Pal wrote:
On 01/12/2015 09:51 AM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
- There is a difference between allowing a wild card in a string and
allowing it at the beginning or at end. In the latter case you can use much fast searches such as "begins with" and "ends with" or "contains" if you have *foo*. I think it should be explicit whether we allow regex or not becuase an asterisk in general would require regex. I thought we said we want to avoid regex.
- In the min length configuration options please be explicit that we are
talking about non wild card characters in the string.
I must have missed why do we have these options at all? The design page doesn't specify it either. Is it to avoid thrashing the LDAP server with searches too wide?
Yes. It was in the discussion. We do not want user to provide one letter and get tons of responses. However we can also do a different thing, we can limit the number of results returned and never return over some hard coded limit, for example, 300. With the default 30.
OK, that makes total sense, but care must be taken to return a nice error string if the admin uses a shorter filter.
On 01/13/2015 09:44 AM, Jakub Hrozek wrote:
On Mon, Jan 12, 2015 at 03:40:33PM -0500, Dmitri Pal wrote:
On 01/12/2015 03:18 PM, Jakub Hrozek wrote:
On Mon, Jan 12, 2015 at 02:17:46PM -0500, Dmitri Pal wrote:
On 01/12/2015 09:51 AM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
- There is a difference between allowing a wild card in a string and
allowing it at the beginning or at end. In the latter case you can use much fast searches such as "begins with" and "ends with" or "contains" if you have *foo*. I think it should be explicit whether we allow regex or not becuase an asterisk in general would require regex. I thought we said we want to avoid regex.
Asterisk can be present in the middle of the word in LDAP filter so we don't have to implement it ourselves. Or am I wrong?
- In the min length configuration options please be explicit that we are
talking about non wild card characters in the string.
I must have missed why do we have these options at all? The design page doesn't specify it either. Is it to avoid thrashing the LDAP server with searches too wide?
Yes. It was in the discussion. We do not want user to provide one letter and get tons of responses. However we can also do a different thing, we can limit the number of results returned and never return over some hard coded limit, for example, 300. With the default 30.
So which way should we go? We can do even both.
OK, that makes total sense, but care must be taken to return a nice error string if the admin uses a shorter filter.
On Tue, Jan 13, 2015 at 11:08:20AM +0100, Pavel Březina wrote:
Yes. It was in the discussion. We do not want user to provide one letter and get tons of responses. However we can also do a different thing, we can limit the number of results returned and never return over some hard coded limit, for example, 300. With the default 30.
So which way should we go? We can do even both.
I would personally prefer limiting the number of responses. Limiting the filter seems a bit unintuitive -- I understand it because I've been working with LDAP for years, but for many admins it will be just a really strange parameter.
On 01/13/2015 05:17 AM, Jakub Hrozek wrote:
On Tue, Jan 13, 2015 at 11:08:20AM +0100, Pavel Březina wrote:
Yes. It was in the discussion. We do not want user to provide one letter and get tons of responses. However we can also do a different thing, we can limit the number of results returned and never return over some hard coded limit, for example, 300. With the default 30.
So which way should we go? We can do even both.
I would personally prefer limiting the number of responses. Limiting the filter seems a bit unintuitive -- I understand it because I've been working with LDAP for years, but for many admins it will be just a really strange parameter. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Let us limit the responses.
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
On 01/14/2015 10:19 AM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
ack
On 01/14/2015 08:02 PM, Dmitri Pal wrote:
On 01/14/2015 10:19 AM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
ack
Thanks.
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was chosen so that we cover the 32bit value range and can use the negative range for errors.
On 01/16/2015 11:39 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was chosen so that we cover the 32bit value range and can use the negative range for errors.
I don't think I follow. What errors? Errors are reported through D-Bus error message, not through an input parameter.
On Fri, Jan 16, 2015 at 11:41:19AM +0100, Pavel Březina wrote:
On 01/16/2015 11:39 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was chosen so that we cover the 32bit value range and can use the negative range for errors.
I don't think I follow. What errors? Errors are reported through D-Bus error message, not through an input parameter.
OK, for input parameters and properties it makes sense to use unsigned number. I just checked AccountsService and they use UInt64 -- not sure why, can you check with Stef or Matthias Clasen ? I can't think of other reason than representing undefined or extra values, though.
In SSSD itself, we use uint32_t to represent UIDs anyway.
On 01/16/2015 11:55 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:41:19AM +0100, Pavel Březina wrote:
On 01/16/2015 11:39 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was chosen so that we cover the 32bit value range and can use the negative range for errors.
I don't think I follow. What errors? Errors are reported through D-Bus error message, not through an input parameter.
OK, for input parameters and properties it makes sense to use unsigned number. I just checked AccountsService and they use UInt64 -- not sure why, can you check with Stef or Matthias Clasen ? I can't think of other reason than representing undefined or extra values, though.
In SSSD itself, we use uint32_t to represent UIDs anyway.
CCing Stef.
On 16.01.2015 11:56, Pavel Březina wrote:
On 01/16/2015 11:55 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:41:19AM +0100, Pavel Březina wrote:
On 01/16/2015 11:39 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was chosen so that we cover the 32bit value range and can use the negative range for errors.
I don't think I follow. What errors? Errors are reported through D-Bus error message, not through an input parameter.
OK, for input parameters and properties it makes sense to use unsigned number. I just checked AccountsService and they use UInt64 -- not sure why, can you check with Stef or Matthias Clasen ? I can't think of other reason than representing undefined or extra values, though.
In SSSD itself, we use uint32_t to represent UIDs anyway.
CCing Stef.
No idea. Maybe for cross platform insurance? Matthias wrote that code.
Although it would be awesome to have longer UIDs in the kernel, the reality is that we're limited to uint32_t.
Stef
On 01/16/2015 11:58 AM, Stef Walter wrote:
On 16.01.2015 11:56, Pavel Březina wrote:
On 01/16/2015 11:55 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:41:19AM +0100, Pavel Březina wrote:
On 01/16/2015 11:39 AM, Jakub Hrozek wrote:
On Fri, Jan 16, 2015 at 11:29:27AM +0100, Pavel Březina wrote:
One more question - uid_t is unsigned int. Should we use it in FindById instead of int64_t which was taken from the original design page?
uid_t is unsigned 32bit on most (all?) platforms. IIRC int64_t was chosen so that we cover the 32bit value range and can use the negative range for errors.
I don't think I follow. What errors? Errors are reported through D-Bus error message, not through an input parameter.
OK, for input parameters and properties it makes sense to use unsigned number. I just checked AccountsService and they use UInt64 -- not sure why, can you check with Stef or Matthias Clasen ? I can't think of other reason than representing undefined or extra values, though.
In SSSD itself, we use uint32_t to represent UIDs anyway.
CCing Stef.
No idea. Maybe for cross platform insurance? Matthias wrote that code.
Although it would be awesome to have longer UIDs in the kernel, the reality is that we're limited to uint32_t.
Stef
Let's go with uint32. All the underlying functions uses uid_t or uint32_t if the code is shared for uid and gids so there is no point to allow bigger ids here since it would have to be converted to uint32 anyway.
On 01/14/2015 04:19 PM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
I think we should rethink the object paths. Currently it contains only $UID information which should be unique across all domain. Therefore we relay on sysdb_getpwuid, however, this function still requires domain.
We can either iterate over all domains and use the first match, or we can add domain information into the object path:
/ifp/Users/$domain/$uid
Or other variants. Opinions?
On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
On 01/14/2015 04:19 PM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
I think we should rethink the object paths. Currently it contains only $UID information which should be unique across all domain. Therefore we relay on sysdb_getpwuid, however, this function still requires domain.
We can either iterate over all domains and use the first match, or we can add domain information into the object path:
/ifp/Users/$domain/$uid
Is it about the object path only?
From application perspective, the UID might be the only input data they have
(think file ownership), we should provide a mean to retrieve a user based on this data only. The fact that we use 'domains' is not interesting for applications.
I don't have a problem with adding domain to the path, after all, the user is not supposed to construct the paths himself, he ought to use the Find() methods. But I think we shouldn't require the domain to be an input parameter.
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 28, 2015 12:22:09 PM Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
On 01/14/2015 04:19 PM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
I think we should rethink the object paths. Currently it contains only $UID information which should be unique across all domain. Therefore we relay on sysdb_getpwuid, however, this function still requires domain.
We can either iterate over all domains and use the first match, or we can add domain information into the object path:
/ifp/Users/$domain/$uid
Is it about the object path only?
From application perspective, the UID might be the only input data they have (think file ownership), we should provide a mean to retrieve a user based on this data only. The fact that we use 'domains' is not interesting for applications.
Yes, it is only about the domain path. The object path can be obtained by uid search with Users.FindByID(id), not domain is required there.
We can iterate through all the domains in the getters, but having the domain as a part of an object path is simply more convenient.
I don't have a problem with adding domain to the path, after all, the user is not supposed to construct the paths himself, he ought to use the Find() methods. But I think we shouldn't require the domain to be an input parameter.
I'm also thinking about more complex and more object oriented interface usage. Something like:
ifp.Users.ListByName on /ifp/Users ifp.Users.ListByName on /ifp/$domain/Users
The later can replace ListByDomainAndName(domain, filter, limit) method.
User object path can then look like: /ifp/$domain/Users/$uid
But that is probably too complex and overthought. What do you think?
On 01/28/2015 02:00 PM, Pavel Brezina wrote:
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 28, 2015 12:22:09 PM Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
On 01/14/2015 04:19 PM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
I think we should rethink the object paths. Currently it contains only $UID information which should be unique across all domain. Therefore we relay on sysdb_getpwuid, however, this function still requires domain.
We can either iterate over all domains and use the first match, or we can add domain information into the object path:
/ifp/Users/$domain/$uid
Is it about the object path only?
From application perspective, the UID might be the only input data they have (think file ownership), we should provide a mean to retrieve a user based on this data only. The fact that we use 'domains' is not interesting for applications.
Yes, it is only about the domain path. The object path can be obtained by uid search with Users.FindByID(id), not domain is required there.
We can iterate through all the domains in the getters, but having the domain as a part of an object path is simply more convenient.
I don't have a problem with adding domain to the path, after all, the user is not supposed to construct the paths himself, he ought to use the Find() methods. But I think we shouldn't require the domain to be an input parameter.
I'm also thinking about more complex and more object oriented interface usage. Something like:
ifp.Users.ListByName on /ifp/Users ifp.Users.ListByName on /ifp/$domain/Users
The later can replace ListByDomainAndName(domain, filter, limit) method.
User object path can then look like: /ifp/$domain/Users/$uid
But that is probably too complex and overthought. What do you think?
As long as you can get users without of with domain specified I do not really have any preference.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Jan 28, 2015 at 02:00:59PM -0500, Pavel Brezina wrote:
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 28, 2015 12:22:09 PM Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
On 01/14/2015 04:19 PM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote:
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
I think we should rethink the object paths. Currently it contains only $UID information which should be unique across all domain. Therefore we relay on sysdb_getpwuid, however, this function still requires domain.
We can either iterate over all domains and use the first match, or we can add domain information into the object path:
/ifp/Users/$domain/$uid
Is it about the object path only?
From application perspective, the UID might be the only input data they have (think file ownership), we should provide a mean to retrieve a user based on this data only. The fact that we use 'domains' is not interesting for applications.
Yes, it is only about the domain path. The object path can be obtained by uid search with Users.FindByID(id), not domain is required there.
We can iterate through all the domains in the getters, but having the domain as a part of an object path is simply more convenient.
I don't have a problem with adding domain to the path, after all, the user is not supposed to construct the paths himself, he ought to use the Find() methods. But I think we shouldn't require the domain to be an input parameter.
I'm also thinking about more complex and more object oriented interface usage. Something like:
ifp.Users.ListByName on /ifp/Users ifp.Users.ListByName on /ifp/$domain/Users
The later can replace ListByDomainAndName(domain, filter, limit) method.
User object path can then look like: /ifp/$domain/Users/$uid
But that is probably too complex and overthought. What do you think?
I don't think this is required, meh :-)
The only thing that comes to mind wrt the object path is that the object path might be the identifier that we use for object caching. But then I don't suppose subdomains can be renamed with the current code at all..
On 01/28/2015 08:56 PM, Jakub Hrozek wrote:
On Wed, Jan 28, 2015 at 02:00:59PM -0500, Pavel Brezina wrote:
----- Original Message -----
From: "Jakub Hrozek" jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Sent: Wednesday, January 28, 2015 12:22:09 PM Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
On 01/14/2015 04:19 PM, Pavel Březina wrote:
On 01/12/2015 03:51 PM, Pavel Březina wrote:
On 12/16/2014 02:26 PM, Pavel Březina wrote: > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
I created a new design page to reduce size and increase readability in the original one. I would like to keep DBusResponder page mainly as a crossroad with links to other pages in the future so it is not swamped with too many details on everything.
I will replace user and group design in DBusResponder with the following link if you agree:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
It should cover everything we agreed on. If not, please tell me and I will add it.
New iteration is available at: https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
I think we should rethink the object paths. Currently it contains only $UID information which should be unique across all domain. Therefore we relay on sysdb_getpwuid, however, this function still requires domain.
We can either iterate over all domains and use the first match, or we can add domain information into the object path:
/ifp/Users/$domain/$uid
Is it about the object path only?
From application perspective, the UID might be the only input data they have (think file ownership), we should provide a mean to retrieve a user based on this data only. The fact that we use 'domains' is not interesting for applications.
Yes, it is only about the domain path. The object path can be obtained by uid search with Users.FindByID(id), not domain is required there.
We can iterate through all the domains in the getters, but having the domain as a part of an object path is simply more convenient.
I don't have a problem with adding domain to the path, after all, the user is not supposed to construct the paths himself, he ought to use the Find() methods. But I think we shouldn't require the domain to be an input parameter.
I'm also thinking about more complex and more object oriented interface usage. Something like:
ifp.Users.ListByName on /ifp/Users ifp.Users.ListByName on /ifp/$domain/Users
The later can replace ListByDomainAndName(domain, filter, limit) method.
User object path can then look like: /ifp/$domain/Users/$uid
But that is probably too complex and overthought. What do you think?
I don't think this is required, meh :-)
The only thing that comes to mind wrt the object path is that the object path might be the identifier that we use for object caching. But then I don't suppose subdomains can be renamed with the current code at all..
OK. I amended the design page to reflex /ifp/Users/$DOMAIN/$UID object path.
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Pavel Březina -
Simo Sorce -
Stef Walter