Re: [squid-users] ext_kerberos_ldap_group_acl and Kerberos cache
Hi. On 18.05.2016 16:29, Amos Jeffries wrote: I don't know what you mean by "the main tree". But The feature you describe does not qualify for adding to the 3.5 production release series. The only features added to a series after is goes to "stable" production releases are ones which resolve non-feature bugs or can be done without affecting existing installations. Well, you can treat kerberos cache in the kerberos group ACL helper as both. It doesn't affect current installations in any way: neither it doesn't change the configuration syntax, nor adds new caveats. In the same way it can be considered as a bugfix: as far as I know it was supposed to exist in the helper from the start, but was misimplemented. All it adds is the cache: it caches the credentials up to their TTL, which is defined by the ticket (not by squid, not by helper). By changing the helper behaviour in all cases this clearly affects existing installations. So only qualifies for including into the next series, which is Squid-4. It doesn't change helper behaviour, it fixes it. Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ext_kerberos_ldap_group_acl and Kerberos cache
On 18/05/2016 5:57 p.m., Eugene M. Zheganin wrote: > Hi. > > I've just checked that squid 3.5.19 sources, and discovered the > following fact that is really disturbing: > (first some explanation) > Markus Moeller, the author of the external kerberos group helper, has > implemented the Kerberos credentials cache in the > ext_kerberos_ldap_group_acl helper back in the 2014. The idea is to > cache the credentials inside the helper instance, so when it encounters > a request with user id and group that are already in the cache, the > helper can skip the kerberos initialization sequence for this set of > credentials. This cached version is times faster than original one, that > doesn't use the cache. > > (now the disturbing fact) > Surprisingly, the cached version didn't make it to the main tree for 2 > past years. > Could this situation be corrected please ? I don't know what you mean by "the main tree". But The feature you describe does not qualify for adding to the 3.5 production release series. The only features added to a series after is goes to "stable" production releases are ones which resolve non-feature bugs or can be done without affecting existing installations. By changing the helper behaviour in all cases this clearly affects existing installations. So only qualifies for including into the next series, which is Squid-4. It is a bit disappointing that 4.x is not yet in stable series itself. But we need to get the major bugs in the new code fixed before that can happen. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] ext_kerberos_ldap_group_acl and Kerberos cache
Hi. I've just checked that squid 3.5.19 sources, and discovered the following fact that is really disturbing: (first some explanation) Markus Moeller, the author of the external kerberos group helper, has implemented the Kerberos credentials cache in the ext_kerberos_ldap_group_acl helper back in the 2014. The idea is to cache the credentials inside the helper instance, so when it encounters a request with user id and group that are already in the cache, the helper can skip the kerberos initialization sequence for this set of credentials. This cached version is times faster than original one, that doesn't use the cache. (now the disturbing fact) Surprisingly, the cached version didn't make it to the main tree for 2 past years. Could this situation be corrected please ? Thanks. Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
