<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Janelle,<br>
<div class="moz-cite-prefix">On 09/01/2015 06:17 PM, Janelle wrote:<br>
</div>
<blockquote cite="mid:55E5CF87.9030701@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 8/28/15 8:17 AM, Vaclav Adamec wrote:<br>
<blockquote
cite="mid:CAN1zQ4YRucN_sYziAW7GJFLjHj1RW35BcyUyuDBPfZZap5z5wQ@mail.gmail.com"
type="cite">
<div dir="ltr">You could try this (RH recommended way). It works
for me better than <a moz-do-not-send="true"
href="http://cleanallruv.pl/" target="_blank"
style="font-family:verdana,sans-serif;font-size:12.8px">cleanallruv.pl</a><span
style="font-family:verdana,sans-serif;font-size:12.8px"> as
this sometimes leads to ldap freeze</span>)
<div><br>
</div>
<div><span
style="color:rgb(51,51,51);font-family:Overpass,'Open
Sans',Helvetica,sans-serif;font-size:14px;line-height:19.6px;white-space:pre-wrap">unable
to decode: {replica 30} 5548fa200000001e0000
5548fa200000001e0000
unable to decode: {replica 26} 5548a9a80000001a0000
5548a9a80000001a0000</span><br>
</div>
<div><br>
</div>
<div>for all of them, on-by-one:</div>
<div><br>
</div>
<div><span
style="color:rgb(51,51,51);font-family:Overpass,'Open
Sans',Helvetica,sans-serif;font-size:14px;line-height:19.6px;white-space:pre-wrap">ldapmodify
-x -D "cn=directory manager" -w XXXXXXX
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
changetype: modify
replace: nsds5task
nsds5task: CLEANRUV30
<enter> + <Ctrl + D></span><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 28, 2015 at 4:55 PM,
Guillermo Fuentes <span dir="ltr"><<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:guillermo.fuentes@modernizingmedicine.com">guillermo.fuentes@modernizingmedicine.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_default">
<div class="gmail_default"><font face="verdana,
sans-serif">Hi Janelle,</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif">Using the <a moz-do-not-send="true"
href="http://cleanallruv.pl" target="_blank">cleanallruv.pl</a>
tool was the only way I was able to get ride of
the "</font>unable to decode: {replica x}" entries<span
style="font-family:verdana,sans-serif">.</span></div>
<div class="gmail_default"><font face="verdana,
sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif">This is how I used it, cleaning a
replica ID at a time:</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif"># For replica id: 40</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif"><a moz-do-not-send="true"
href="http://cleanallruv.pl" target="_blank">cleanallruv.pl</a>
-v -D "cn=directory manager" -w - -b
'dc=example,dc=com' -r 40 </font></div>
<div class="gmail_default"><font face="verdana,
sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif">Note that the "-w -" will make the
tool prompt you for the directory manager
password.</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif">Hope this helps,</font></div>
<div class="gmail_default"><font face="verdana,
sans-serif">Guillermo</font></div>
<div class="gmail_default"><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">On Thu, Aug 27, 2015 at 10:27 AM,
Janelle <span dir="ltr"><<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:janellenicole80@gmail.com">janellenicole80@gmail.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div class="h5">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div> On 8/27/15 1:05 AM, thierry bordaz
wrote:<br>
<blockquote type="cite">
<div>On 08/27/2015 09:41 AM, Ludwig
Krispenz wrote:<br>
</div>
<blockquote type="cite"> <br>
On 08/27/2015 09:08 AM, Martin Kosek
wrote: <br>
<blockquote type="cite">On
08/26/2015 05:31 PM, Simo Sorce
wrote: <br>
<blockquote type="cite">On Wed,
2015-08-26 at 06:36 -0700,
Janelle wrote: <br>
<blockquote type="cite">Hello
all, <br>
<br>
My biggest problem is losing
replicas and then trying to
delete the <br>
entries and rebuild them. Here
is a perfect example, I simply
can't get <br>
rid of these (see below). I
have tried (of course after
the ORIGINAL <br>
"ipa-replica-manage del
hostname --force --clean": <br>
<br>
ipa-replica-manage clean-ruv
25 <br>
<br>
ldapmodify... with: <br>
dn: cn=clean 25,
cn=cleanallruv, cn=tasks,
cn=config <br>
objectclass:
extensibleObject <br>
replica-base-dn:
dc=example,dc=com <br>
replica-id: 25 <br>
cn: clean 25 <br>
<br>
And yet nothing works. Any
suggestions? This is perhaps
the most <br>
frustrating part about
maintaining IPA. <br>
<br>
~J <br>
<br>
unable to decode: {replica 12}
5588dc2e0000000c0000
559f3de60004000c0000 <br>
unable to decode: {replica 14}
5587aa8d0000000e0000
5587aa8d0003000e0000 <br>
unable to decode: {replica 16}
5588f58f000000100000
55bb7b08000500100000 <br>
unable to decode: {replica 25}
55a4887b000000190000
55a49242000400190000 <br>
unable to decode: {replica 29}
55d199a50001001d0000
55d199a50001001d0000 <br>
unable to decode: {replica 3}
5587c5c3000000030000
55b8a049000100030000 <br>
unable to decode: {replica 5}
55cc82ab041d00050000
55cc82ab041d00050000 <br>
</blockquote>
Have you tried restarting DS
before trying to clean the ruv ?
<br>
<br>
I run in a similar problem in a
test install recently, and I got
better <br>
results that way. The bug is
known to the DS people and they
are working <br>
to get out patches that fix the
root issue. <br>
<br>
Simo. <br>
</blockquote>
CCing DS folks. Wasn't there a
recent DS fix that was supposed to
improve the <br>
RUV situation? <br>
<br>
Looking at 389 DS Trac, I see some
interesting RUV fixes in 1.3.4.x
releases: <br>
<br>
<a moz-do-not-send="true"
href="https://fedorahosted.org/389/query?summary=%7ERUV&status=closed&order=milestone&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone"
target="_blank">https://fedorahosted.org/389/query?summary=~RUV&status=closed&order=milestone&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone</a>
<br>
<br>
I see that 389-ds-base-1.3.4.3 is
already in Fedora 22+, does the
RUV issue <br>
happen there? <br>
</blockquote>
it should not, and I think Thierry
verified the fix. <br>
The problem we resolved and which we
think is the core of the corrupted
RUV was that the cleanallruv task
did only purge the RUV, but dit not
purge the changelog. If cleanallruv
was run and the server had a
disorderly shutdown (crash or abort
when shutdown was hanging) then at
restart the changelog RUV was
rebuilt from the data in the
changelog and if it contained a csn
from cleaned RIDs this was added to
the RUV (but the reference to the
server was lost and so the url part
is missing from this RUV. <br>
The fix now does remove all
references to the cleaned RID from
the changelog and the problem should
not reoccur with RIDs cleaned with
the fix, of course th echangelog can
still can contain references to RIDs
cleaned before the fix - and if no
changelog trimming is configured
this is what will happen. So, even
after the fix old RUVs could pop up
and have to be (finally) cleaned. <br>
<br>
The other source is that these
corrupted rivs can be "imported"
from another server by exchanging
ruvs in the repl protocol.
Cleanallruv tries to address this
and to propagate the cleanallruv
tasks to all servers it thinks are
connected. If there are replication
agreements to servers which no
longer exist or to servers which
cannot be connetcted this will delay
the ruv cleaning <br>
<br>
</blockquote>
<br>
<font face="Times New Roman, Times,
serif">Hello, <br>
<br>
I verified the fix in 1.3.4.2 F22 /
389-ds-base-1.3.4.0-6.el7 RHEL7, so
after those versions CLEANALLRUV do
not create any longer corrupted ruv
elements.<br>
According to the timestamp in the
ruv (for example csn2date.py
5587aa8d0003000e0000 -->
22/06/2015:06:26:21) this are old
ruv elements. I think Ludwig is
right, these corrupted ruv-elements
come from old cleanallruv before the
fix was applied.<br>
<br>
The problem is that even a fixed
server can get those corrupted
ruv-elements from others servers.<br>
All servers in the topology should
be updated with that fix, so that at
least they stop creating corrupted
ruv-elements.<br>
Now to get rid of the existing ones,
I imagine only brute option of
recreating replica and reinit... I
hope an other option is possible.<br>
<br>
thanks<br>
thierry<br>
</font><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<font color="#888888">For a few minutes - almost an hour
actually, I thought there was hope. I found the cleanallruv.pl
script and that not only seemed to work, but it wiped the
"unable to decode" from all the servers even just running it on
one. Sadly, within an hour, they all came back. :-(<br>
<br>
unable to decode {replica 12} 559f3de60004000c0000
559f3de60004000c0000<br>
unable to decode {replica 14} 5587aa8d0003000e0000
5587aa8d0003000e0000<br>
unable to decode {replica 16} 55bb7b08000500100000
55bb7b08000500100000<br>
unable to decode {replica 25} 55a49242000400190000
55a49242000400190000<br>
unable to decode {replica 29} 55d199a50001001d0000
55d199a50001001d0000<br>
unable to decode {replica 31} 55e4bc680005001f0000
55e4bc680005001f0000<br>
unable to decode {replica 3} 55b8a049000100030000
55b8a049000100030000<br>
unable to decode {replica 5} 55cc82ab041d00050000
55cc82ab041d00050000<br>
<br>
I cried... Followed by heavy drinking.<br>
</font></blockquote>
<font color="#888888">does drinking help, could be a great
workaround ?<br>
<br>
Now, more seriously, I think you need a build including the
mentioned improvement for cleanallruv, we are currently checking
if and where it is available for 7.1.<br>
But this fix will only help in future cleanallruvs, so you
probably need to go thru a few iterations of cleaning.<br>
Since the core problem of the corrupted ruvs is that they can be
recreated from the changlog I think configuring changlog trimming
is something that should be done.<br>
</font>
<blockquote cite="mid:55E5CF87.9030701@gmail.com" type="cite"><font
color="#888888"> <br>
~Janelle<br>
</font> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>