-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sometimes, a value in LDAP will cease to exist (the classic example being shadowExpire). We need to make sure we purge that value from SSSD's sysdb as well.
Fixes https://fedorahosted.org/sssd/ticket/750
- -- 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 SIGNED MESSAGE----- Hash: SHA1
On 01/13/2011 03:37 PM, Stephen Gallagher wrote:
Sometimes, a value in LDAP will cease to exist (the classic example being shadowExpire). We need to make sure we purge that value from SSSD's sysdb as well.
Attaching rebased version atop Sumit's patch for search timeouts.
- -- 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 Mon, Jan 17, 2011 at 08:14:35AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/13/2011 03:37 PM, Stephen Gallagher wrote:
Sometimes, a value in LDAP will cease to exist (the classic example being shadowExpire). We need to make sure we purge that value from SSSD's sysdb as well.
Attaching rebased version atop Sumit's patch for search timeouts.
The patch works as expected. I'm just wondering if it wouldn't be better to start the transaction before calling sysdb_set_user_attr(). Otherwise we might leave the object in an inconsistent state, where the new values and attributes are already added, but the old ones are not removed. This would be pretty much the current state which we try to improve.
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/
iEYEARECAAYFAk00QLsACgkQeiVVYja6o6MNyACePAigFrvKC2wc7AVDe5LxTFAY FV0AmQHFfH8iX0fiR0pC0tDrfercCSDp =TnPu -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/20/2011 03:56 PM, Sumit Bose wrote:
On Mon, Jan 17, 2011 at 08:14:35AM -0500, Stephen Gallagher wrote: On 01/13/2011 03:37 PM, Stephen Gallagher wrote:
Sometimes, a value in LDAP will cease to exist (the classic example being shadowExpire). We need to make sure we purge that value from SSSD's sysdb as well.
Attaching rebased version atop Sumit's patch for search timeouts.
The patch works as expected. I'm just wondering if it wouldn't be better to start the transaction before calling sysdb_set_user_attr(). Otherwise we might leave the object in an inconsistent state, where the new values and attributes are already added, but the old ones are not removed. This would be pretty much the current state which we try to improve.
I added a transaction around all of sysdb_store_user(), but I didn't remove the one from sysdb_remove_attrs(). It's safe to have nested transactions, and I'd rather that it be in place if we should ever use sysdb_remove_attrs() directly.
I also changed the finalization for the transactions slightly, so that a failure to commit a transaction will also try to cancel it.
- -- 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 SIGNED MESSAGE----- Hash: SHA1
On 01/21/2011 03:43 PM, Stephen Gallagher wrote:
On 01/20/2011 03:56 PM, Sumit Bose wrote:
On Mon, Jan 17, 2011 at 08:14:35AM -0500, Stephen Gallagher wrote: On 01/13/2011 03:37 PM, Stephen Gallagher wrote:
Sometimes, a value in LDAP will cease to exist (the classic example being shadowExpire). We need to make sure we purge that value from SSSD's sysdb as well.
Attaching rebased version atop Sumit's patch for search timeouts.
The patch works as expected. I'm just wondering if it wouldn't be better to start the transaction before calling sysdb_set_user_attr(). Otherwise we might leave the object in an inconsistent state, where the new values and attributes are already added, but the old ones are not removed. This would be pretty much the current state which we try to improve.
I added a transaction around all of sysdb_store_user(), but I didn't remove the one from sysdb_remove_attrs(). It's safe to have nested transactions, and I'd rather that it be in place if we should ever use sysdb_remove_attrs() directly.
I also changed the finalization for the transactions slightly, so that a failure to commit a transaction will also try to cancel it.
Sumit pointed out on IRC that I forgot to initialize sret in sysdb_remove_attrs(). This new patch corrects that.
- -- 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 Fri, Jan 21, 2011 at 04:08:46PM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/21/2011 03:43 PM, Stephen Gallagher wrote:
On 01/20/2011 03:56 PM, Sumit Bose wrote:
On Mon, Jan 17, 2011 at 08:14:35AM -0500, Stephen Gallagher wrote: On 01/13/2011 03:37 PM, Stephen Gallagher wrote:
Sometimes, a value in LDAP will cease to exist (the classic example being shadowExpire). We need to make sure we purge that value from SSSD's sysdb as well.
Attaching rebased version atop Sumit's patch for search timeouts.
The patch works as expected. I'm just wondering if it wouldn't be better to start the transaction before calling sysdb_set_user_attr(). Otherwise we might leave the object in an inconsistent state, where the new values and attributes are already added, but the old ones are not removed. This would be pretty much the current state which we try to improve.
I added a transaction around all of sysdb_store_user(), but I didn't remove the one from sysdb_remove_attrs(). It's safe to have nested transactions, and I'd rather that it be in place if we should ever use sysdb_remove_attrs() directly.
I also changed the finalization for the transactions slightly, so that a failure to commit a transaction will also try to cancel it.
Sumit pointed out on IRC that I forgot to initialize sret in sysdb_remove_attrs(). This new patch corrects that.
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/
iEYEARECAAYFAk059d4ACgkQeiVVYja6o6P6LQCfcpGVQqHYSwtDMEeQip5wCqAi BDYAoIdKrJBF/Mgud78vSpF9PZPIuwQf =xgCw -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/21/2011 04:27 PM, Sumit Bose wrote:
On Fri, Jan 21, 2011 at 04:08:46PM -0500, Stephen Gallagher wrote: On 01/21/2011 03:43 PM, Stephen Gallagher wrote:
On 01/20/2011 03:56 PM, Sumit Bose wrote:
On Mon, Jan 17, 2011 at 08:14:35AM -0500, Stephen Gallagher wrote: On 01/13/2011 03:37 PM, Stephen Gallagher wrote:
>> Sometimes, a value in LDAP will cease to exist (the classic >> example being shadowExpire). We need to make sure we purge that >> value from SSSD's sysdb as well. >> >> Fixes https://fedorahosted.org/sssd/ticket/750 >>
Attaching rebased version atop Sumit's patch for search timeouts.
The patch works as expected. I'm just wondering if it wouldn't be better to start the transaction before calling sysdb_set_user_attr(). Otherwise we might leave the object in an inconsistent state, where the new values and attributes are already added, but the old ones are not removed. This would be pretty much the current state which we try to improve.
I added a transaction around all of sysdb_store_user(), but I didn't remove the one from sysdb_remove_attrs(). It's safe to have nested transactions, and I'd rather that it be in place if we should ever use sysdb_remove_attrs() directly.
I also changed the finalization for the transactions slightly, so that a failure to commit a transaction will also try to cancel it.
Sumit pointed out on IRC that I forgot to initialize sret in sysdb_remove_attrs(). This new patch corrects that.
ACK
bye, Sumit
Pushed to master.
- -- 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
-
Stephen Gallagher -
Sumit Bose