On Fri, Jul 03, 2015 at 02:12:34PM -0400, Simo Sorce wrote: > On Fri, 2015-07-03 at 11:59 +0200, Jakub Hrozek wrote: > > On Fri, Jul 03, 2015 at 11:54:46AM +0200, Jakub Hrozek wrote: > > > Hi, > > > > > > the attached patches fix https://fedorahosted.org/sssd/ticket/2701 > > > > > > The first patch just adds a common function instead of copying the same > > > pattern again to the new test. > > > > > > The second adds a new request krb5_auth_queue_send() that wraps > > > krb5_auth_send() and also uses the Kerberos authentication queue. I hope > > > the unit tests cover a lot of use-cases, if not, please suggest more! > > > > > > btw I was thinking that the chaining might not always be necessary if > > > the ccache is of type MEMORY and I hope that the serializaton wouldn't > > > be perceived as performance regression for users. Shall we say that > > > Pavel's cached auth patches are a more systematic solution that doesn't > > > rely on properties of the ccache type in that case? > > > > I'm sorry, but CI fails on Debian because of wrong linking with > > libraries. I'm already testing a fix. Review of the rest is appreciated > > :-) > > If we are serializing all authentications then a busy server would be > swamped. I do not see a per-user/per-cache queue so I would tentatively > NACK the approach sorry.
The current cache queue is per user, see add_to_wait_queue() for details. bye, Sumit > > If clobbering is the only issues we have then what we can do is to > always use a custom memory ccache for each auth attempt and then use a > locking mechanism to copy from the memory ccache to the actual ccache. > > But we should really do either per-ccache queuing (maybe not per user as > in pathological cases we may have the same ccache for different users ?) > or use memory ccaches and copy them with locking, but fully serializing > all authentications is not really a solution, when a full auth may > require multiple network roundtrips. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > sssd-devel mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
