-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that gecos can come from either the 'gecos' or 'cn' attributes, we need to ensure that we never remove it from the cache.
We were being too greedy with our removal code. It purges from the sysdb cache any attributes that were requested from LDAP but that we did not get. However, in the case of 'gecos' (if we are falling back to 'cn') this would mean that we were always purging the gecos-from-cn value.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Tue, Apr 12, 2011 at 12:54:54PM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that gecos can come from either the 'gecos' or 'cn' attributes, we need to ensure that we never remove it from the cache.
We were being too greedy with our removal code. It purges from the sysdb cache any attributes that were requested from LDAP but that we did not get. However, in the case of 'gecos' (if we are falling back to 'cn') this would mean that we were always purging the gecos-from-cn value.
gecos field is back in 'getent passwd' output.
ACK
bye, Sumit
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2kg94ACgkQeiVVYja6o6PO2QCdE8rhsVUb8rYyjOPZPVm0O42h 1b0An0uF5jQLOXaxnkqea6pO2PhYAGWX =UK4v -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/12/2011 03:41 PM, Sumit Bose wrote:
On Tue, Apr 12, 2011 at 12:54:54PM -0400, Stephen Gallagher wrote: Now that gecos can come from either the 'gecos' or 'cn' attributes, we need to ensure that we never remove it from the cache.
We were being too greedy with our removal code. It purges from the sysdb cache any attributes that were requested from LDAP but that we did not get. However, in the case of 'gecos' (if we are falling back to 'cn') this would mean that we were always purging the gecos-from-cn value.
gecos field is back in 'getent passwd' output.
ACK
Pushed to master and sssd-1-5.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Tue, 12 Apr 2011 12:54:54 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that gecos can come from either the 'gecos' or 'cn' attributes, we need to ensure that we never remove it from the cache.
We were being too greedy with our removal code. It purges from the sysdb cache any attributes that were requested from LDAP but that we did not get. However, in the case of 'gecos' (if we are falling back to 'cn') this would mean that we were always purging the gecos-from-cn value.
I am actually wondering why we are storing a duplicate here instead of retrieving CN in the nss responder and substituting the gecos field there, it would waste less space for a perfectly duplicate attribute and would avoid update corner cases like this one.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/12/2011 04:48 PM, Simo Sorce wrote:
On Tue, 12 Apr 2011 12:54:54 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that gecos can come from either the 'gecos' or 'cn' attributes, we need to ensure that we never remove it from the cache.
We were being too greedy with our removal code. It purges from the sysdb cache any attributes that were requested from LDAP but that we did not get. However, in the case of 'gecos' (if we are falling back to 'cn') this would mean that we were always purging the gecos-from-cn value.
I am actually wondering why we are storing a duplicate here instead of retrieving CN in the nss responder and substituting the gecos field there, it would waste less space for a perfectly duplicate attribute and would avoid update corner cases like this one.
My decision to do it this way was because I want to keep the NSS responder agnostic of the backends. Just because the LDAP provider uses 'cn' as an alternate, I don't necessarily want to do the same for a NIS provider or a winbind provider.
I decided that it made the most sense for the backend to conform to the expected format for the NSS responder.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org
-
Simo Sorce -
Stephen Gallagher -
Sumit Bose