March 2019 - 389-devel - Fedora Mailing-Lists

by William Brown

https://pagure.io/389-ds-base/issue/49668 https://pagure.io/389-ds-base/issue/49667 https://pagure.io/389-ds-base/pull-request/50275 — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs

5 years, 1 month

1
0
0 / 0

please review: PR 50274 - reduce replication agmt default timeout

by Mark Reynolds

https://pagure.io/389-ds-base/pull-request/50274

5 years, 1 month

1
0
0 / 0

Please review: secure pin/pwdfile fro nss

by William Brown

https://pagure.io/389-ds-base/pull-request/50272 -- Sincerely, William

5 years, 1 month

1
0
0 / 0

please review: Ticket 50208 - lib389 - fix regression in listing all instances

by Mark Reynolds

https://pagure.io/389-ds-base/pull-request/50271

5 years, 1 month

1
0
0 / 0

please review: PR 50269 - backend txn plugins can corrupt entry cache

by Mark Reynolds

https://pagure.io/389-ds-base/pull-request/50269

5 years, 1 month

1
0
0 / 0

Please review: 50267 dn tests

by William Brown

This is related to: https://pagure.io/389-ds-base/pull-request/50259 To make sure that our dn construction in lib389 works, I have a pr for extra tests: https://pagure.io/389-ds-base/pull-request/50267 — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs

5 years, 1 month

1
0
0 / 0

Please Review 49715 - account functionality

by William Brown

https://pagure.io/389-ds-base/issue/49715 https://pagure.io/389-ds-base/pull-request/50262 — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs

5 years, 1 month

1
0
0 / 0

Please Review: 49655 rm doap file

by William Brown

https://pagure.io/389-ds-base/pull-request/50261 https://pagure.io/389-ds-base/issue/49655 -- Sincerely, William

5 years, 1 month

1
0
0 / 0

[discuss] Entry cache and backend txn plugin problems

by Mark Reynolds

I want to start a brief discussion about a major problem we have backend transaction plugins and the entry caches. I'm finding that when we get into a nested state of be txn plugins and one of the later plugins that is called fails then while we don't commit the disk changes (they are aborted/rolled back) we DO keep the entry cache changes! For example, a modrdn operation triggers the referential integrity plugin which renames the member attribute in some group and changes that group's entry cache entry, but then later on the memberOf plugin fails for some reason. The database transaction is aborted, but the entry cache changes that RI plugin did are still present :-( I have also found other entry cache issues with modrdn and BE TXN plugins, and we know of other currently non-reproducible entry cache crashes as well related to mishandling of cache entries after failed operations. It's time to rework how we use the entry cache. We basically need a transaction style caching mechanism - we should not commit any entry cache changes until the original operation is fully successful. Unfortunately the way the entry cache is currently designed and used it will be a major change to try to change it. William wrote up this doc: http://www.port389.org/docs/389ds/design/cache_redesign.html But this also does not currently cover the nested plugin scenario either (not yet). I do know how how difficult it would be to implement William's proposal, or how difficult it would be to incorporate the txn style caching into his design. What kind of time frame could this even be implemented in? William what are your thoughts? If William's design is too huge of a change that will take too long to safely implement then perhaps we need to look into revising the existing cache design where we use "cache_add_tentative" style functions and only apply them at the end of the op. This is also not a trivial change. And what impact would changing the entry cache have on Ludwig's plugable backend work? Anyway we need to start thinking about redesigning the entry cache - no matter what approach we want to take. If anyone has any ideas or comments please share them, but I think due to the severity of this flaw redesigning the entry cache should be one of our next major goals in DS (1.4.1?). Thanks, Mark

5 years, 1 month

4
7
0 / 0

please review: PR 50258 - lib389 - password policy user vs subtree checks are broken

by Mark Reynolds

https://pagure.io/389-ds-base/pull-request/50258

5 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel March 2019