On Wed, Sep 10, 2014 at 02:33:00PM +0200, Jakub Hrozek wrote:
On Wed, Sep 10, 2014 at 02:22:15PM +0200, Sumit Bose wrote:
> On Wed, Sep 10, 2014 at 01:23:15PM +0200, Michal Židek wrote:
> > Hi,
> >
> > this patch should solve regression on IPA server
> > triggered by the patches for this ticket:
> >
https://fedorahosted.org/sssd/ticket/2343
> >
> > Patches for #2343 solved the IPA side of the
> > problem by searching for objectclass groupOfNames
> > instead of posixGroup (which was not available in
> > non-posix groups). But (as we discovered now) not
> > all groups in IPA are members of the objectClass
> > groupOfNames (the private groups created
> > automatically for users are not, so as a result
> > we were not able to query them). So there is
> > no common objectclass for all groups in IPA that
> > would be suitable for group query filters.
> >
> > So these 2 patches add the possibility to query
> > groups using primary and alternative objectClass
> > (ORed in the filter).
> >
> > I tested the patches, but I would feel safer if
> > someone pushed them to Beaker and run QE tests
> > on it before pushing (I thing Jakub volunteered
> > for this task off-list :) ).
No, I volunteered for writing a unit test for these changes.
> >
> > Thank you,
> > Michal
>
> While I agree with the general approach I think the default for the
> alternative objectclass should be NULL at it should only be added to the
> search filter if defined. Maybe a function returning either
> "(objectClass=group_oc)" or
> "(|(objectClass=group_oc)(objectClass=alt_group_oc))" might help here.
Yes please, we need a separate function that returns the objectclass
filter.
>
> I guess you did not include changes to the man page and the config API
> on purpose to make it hard to change or unset the values. But
> nevertheless it is a config option and should be handled as such.
Another change I would like to see is make the alt_objectclass a list
instead of a single string as you suggested on IRC.
maybe, but see my comment below.
>
> I understand that we need a fix for the issue fast because it is in
> already released. Hence I would agree if trac tickets are created for
> the issues above for the next release.
Fine by me.
Another question -- do we want to extend the other maps, too (OK by me
to do this in master only)
I think options which allow to override the search filters which are
currently discussed on sssd-users are the more general solution here.
With this the user is free to add any number of objectclasses.
bye,
Sumit
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel