May 2012 - 389-devel - Fedora Mailing-Lists

please review ticket #321 - krbExtraData is being null modified and replicated on each ssh login

by Mark Reynolds

https://fedorahosted.org/389/ticket/321 https://fedorahosted.org/389/attachment/ticket/321/0001-Ticket-321-krbExt... Thanks, Mark

11 years, 11 months

1
1
0 / 0

please review Ticket #365 - password in clear text in audit log

by Mark Reynolds

https://fedorahosted.org/389/ticket/365 https://fedorahosted.org/389/attachment/ticket/365/0001-Ticket-365-passwo... Thanks, Mark

11 years, 11 months

1
0
0 / 0

please review ticket 368 - Make the CLEANALLRUV task one step

by Mark Reynolds

https://fedorahosted.org/389/ticket/368 https://fedorahosted.org/389/attachment/ticket/368/0001-Ticket-368-Make-t... Thanks, Mark

11 years, 11 months

1
1
0 / 0

please review ticket #218 - Make RI Plugin work with replicated entries

by Mark Reynolds

https://fedorahosted.org/389/ticket/218 https://fedorahosted.org/389/attachment/ticket/218/0001-Ticket-218-Make-R... The diff is very large because I redid all the indentation in referint.c (it was a mess!) The changes to look at are in: referint_postop_init() referint_postop_del() referint_postop_modrdn() _do_modify() and repl5_plugins.c Thanks, Mark

11 years, 12 months

1
1
0 / 0

please review ticket 367 - Invalid chaining config triggers a disk full error and shutdown

by Mark Reynolds

https://fedorahosted.org/389/ticket/367 https://fedorahosted.org/389/attachment/ticket/367/0001-Ticket-367-Invali... Note: I also did some code cleanup with indentation, but the the fix is just to return -1, instead of LDAP_LOCAL_ERROR(-2). Thanks, Mark

11 years, 12 months

1
1
0 / 0

Please review (take 2'): [389 Project] #359: Database RUV could mismatch the one in changelog under the stress

by Noriko Hosoi

https://fedorahosted.org/389/ticket/359 Please review these 2 patches: https://fedorahosted.org/389/attachment/ticket/359/0001-Trac-Ticket-359-D... (389-ds-base-1.2.10) https://fedorahosted.org/389/attachment/ticket/359/0001-Trac-Ticket-359-D... (master)

12 years

1
0
0 / 0

please review ticket 196 - Interpret IPV6 addresses for ACIs, replication, and chaining

by Mark Reynolds

https://fedorahosted.org/389/ticket/196/ https://fedorahosted.org/389/attachment/ticket/196/0001-Ticket-196-RFE-In... Thanks, Mark

12 years

1
1
0 / 0

please review ticket #356 - RFE logconv.pl - Track Bind Info

by Mark Reynolds

https://fedorahosted.org/389/ticket/356 https://fedorahosted.org/389/attachment/ticket/356/0001-Ticket-356-RFE-Tr... Thanks, Mark

12 years

1
0
0 / 0

Please review: Ticket #358 - managed entry doesn't delete linked entry

by Rich Megginson

This patch passes entryusn, dna, managedentry, automember, memofenhancement, and linkedattrs tests. I'm running a full acceptance test now. Please let me know if you see any problems. https://fedorahosted.org/389/ticket/358 https://fedorahosted.org/389/attachment/ticket/358/0001-Ticket-358-manage...

12 years

1
0
0 / 0

winsync syncs deletions of AD entries that are out of scope

by Rich Megginson

This came up during extended testing for https://fedorahosted.org/389/ticket/355 steps: 1) make a ds user and an ad user that are in sync - verify ad changes go to ds and vice versa 2) move the ad user out of scope of the sync agreement 3) verify that sync is not working - verify ad changes don't go to ds and vice versa 4) delete the ad user - the ds user is also deleted Before the fix for ticket 355, moving the AD entry out of scope would delete the DS entry - but that was problematic - if you mis-configured your sync agreement, all of your DS users could be accidentally deleted This seems counter-intuitive - the entries are not in sync, yet the deletion is synced. This is because we do not look at the scope of the AD tombstone entry prior to deletion, and test it using is_subject_of_agreement_remote(e,prp->agmt) We could look at the AD tombstone to see if was in scope - the AD tombstone (with 2008 anyway) provides the attribute "lastknownparent": (gdb) p *e->e_attrs->a_next->a_next->a_next->a_next->a_next $27 = {a_type = 0x7fffc0056bb0 "lastknownparent", a_present_values = { va = 0x7fffc00563b0}, a_flags = 4, a_plugin = 0x6c85a0, a_deleted_values = {va = 0x0}, a_listtofree = 0x0, a_next = 0x7fffc0059450, a_deletioncsn = 0x0, a_mr_eq_plugin = 0x690240, a_mr_ord_plugin = 0x0, a_mr_sub_plugin = 0x0} (gdb) p *e->e_attrs->a_next->a_next->a_next->a_next->a_next->a_present_values.va[0] $28 = {bv = {bv_len = 36, bv_val = 0x7fffc0067470 "CN=deletedusers,DC=testdomain,DC=com"}, v_csnset = 0x0, v_flags = 0} So, in this case, if we used lastknownparent, we would see that the entry was outside of the scope of the agreement (the sync subtree is cn=testusers,dc=testdomain,dc=com). Question: In light of 355 changing the behavior - should we use lastknownparent to see if the tombstone is out of the scope of the agreement, and not delete the DS entry if so?

12 years

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel May 2012