subject:"Re\: \[Freeipa\-users\] stubborn old replicas"

Re: [Freeipa-users] stubborn old replicas

2015-09-02 Thread Ludwig Krispenz


Hi Janelle,
On 09/01/2015 06:17 PM, Janelle wrote:

On 8/28/15 8:17 AM, Vaclav Adamec wrote:
You could try this (RH recommended way). It works for me better than 
cleanallruv.pl  as this sometimes leads to 
ldap freeze)


unable to decode: {replica 30} 5548fa20001e 
5548fa20001e unable to decode: {replica 26} 
5548a9a8001a 5548a9a8001a


for all of them, on-by-one:

ldapmodify -x -D "cn=directory manager" -w XXX dn: 
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config 
changetype: modify replace: nsds5task nsds5task: CLEANRUV30  + 



On Fri, Aug 28, 2015 at 4:55 PM, Guillermo Fuentes 
 wrote:


Hi Janelle,

Using the cleanallruv.pl  tool was the
only way I was able to get ride of the "unable to decode:
{replica x}" entries.

This is how I used it, cleaning a replica ID at a time:
# For replica id: 40
cleanallruv.pl  -v -D "cn=directory
manager" -w - -b 'dc=example,dc=com' -r 40

Note that the "-w -" will make the tool prompt you for the
directory manager password.

Hope this helps,
Guillermo


On Thu, Aug 27, 2015 at 10:27 AM, Janelle
 wrote:

On 8/27/15 1:05 AM, thierry bordaz wrote:

On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:


On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

My biggest problem is losing replicas and then trying to
delete the
entries and rebuild them. Here is a perfect example, I
simply can't get
rid of these  (see below). I have tried (of course after
the ORIGINAL
"ipa-replica-manage del hostname --force --clean":

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps
the most
frustrating part about maintaining IPA.

~J

unable to decode: {replica 12} 5588dc2e000c
559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e
5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010
55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019
55a4924200040019
unable to decode: {replica 29} 55d199a50001001d
55d199a50001001d
unable to decode: {replica 3} 5587c5c30003
55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005
55cc82ab041d0005

Have you tried restarting DS before trying to clean the
ruv ?

I run in a similar problem in a test install recently,
and I got better
results that way. The bug is known to the DS people and
they are working
to get out patches that fix the root issue.

Simo.

CCing DS folks. Wasn't there a recent DS fix that was
supposed to improve the
RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes
in 1.3.4.x releases:


https://fedorahosted.org/389/query?summary=~RUV=closed=milestone=id=summary=status=owner=type=priority=milestone




I see that 389-ds-base-1.3.4.3 is already in Fedora 22+,
does the RUV issue
happen there?

it should not, and I think Thierry verified the fix.
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.
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.

The other source is that these corrupted rivs can be

Re: [Freeipa-users] stubborn old replicas

2015-09-01 Thread Janelle

On 8/28/15 8:17 AM, Vaclav Adamec wrote:
You could try this (RH recommended way). It works for me better than 
cleanallruv.pl  as this sometimes leads to 
ldap freeze)

unable to decode: {replica 30} 5548fa20001e 
5548fa20001e unable to decode: {replica 26} 
5548a9a8001a 5548a9a8001a

for all of them, on-by-one:

ldapmodify -x -D "cn=directory manager" -w XXX dn: 
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config 
changetype: modify replace: nsds5task nsds5task: CLEANRUV30  + 

On Fri, Aug 28, 2015 at 4:55 PM, Guillermo Fuentes 
> wrote:

Hi Janelle,

Using the cleanallruv.pl  tool was the only
way I was able to get ride of the "unable to decode: {replica x}"
entries.

This is how I used it, cleaning a replica ID at a time:
# For replica id: 40
cleanallruv.pl  -v -D "cn=directory
manager" -w - -b 'dc=example,dc=com' -r 40

Note that the "-w -" will make the tool prompt you for the
directory manager password.

Hope this helps,
Guillermo

On Thu, Aug 27, 2015 at 10:27 AM, Janelle
> wrote:

On 8/27/15 1:05 AM, thierry bordaz wrote:

On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:

On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

My biggest problem is losing replicas and then trying to
delete the
entries and rebuild them. Here is a perfect example, I
simply can't get
rid of these  (see below). I have tried (of course after
the ORIGINAL
"ipa-replica-manage del hostname --force --clean":

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps
the most
frustrating part about maintaining IPA.

~J

unable to decode: {replica 12} 5588dc2e000c
559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e
5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010
55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019
55a4924200040019
unable to decode: {replica 29} 55d199a50001001d
55d199a50001001d
unable to decode: {replica 3} 5587c5c30003
55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005
55cc82ab041d0005

Have you tried restarting DS before trying to clean the ruv ?

I run in a similar problem in a test install recently, and
I got better
results that way. The bug is known to the DS people and
they are working
to get out patches that fix the root issue.

Simo.

CCing DS folks. Wasn't there a recent DS fix that was
supposed to improve the
RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes in
1.3.4.x releases:

https://fedorahosted.org/389/query?summary=~RUV=closed=milestone=id=summary=status=owner=type=priority=milestone

I see that 389-ds-base-1.3.4.3 is already in Fedora 22+,
does the RUV issue
happen there?

it should not, and I think Thierry verified the fix.
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.
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.

The other source is that

Re: [Freeipa-users] stubborn old replicas

2015-08-28 Thread Vaclav Adamec

You could try this (RH recommended way). It works for me better than
cleanallruv.pl as this sometimes leads to ldap freeze)

unable to decode: {replica 30} 5548fa20001e 5548fa20001e
unable to decode: {replica 26} 5548a9a8001a 5548a9a8001a

for all of them, on-by-one:

ldapmodify -x -D cn=directory manager -w XXX dn:
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype:
modify replace: nsds5task nsds5task: CLEANRUV30 enter + Ctrl + D

On Fri, Aug 28, 2015 at 4:55 PM, Guillermo Fuentes 
guillermo.fuen...@modernizingmedicine.com wrote:

 Hi Janelle,

 Using the cleanallruv.pl tool was the only way I was able to get ride of
 the unable to decode: {replica x} entries.

 This is how I used it, cleaning a replica ID at a time:
 # For replica id: 40
 cleanallruv.pl -v -D cn=directory manager -w - -b 'dc=example,dc=com'
 -r 40

 Note that the -w - will make the tool prompt you for the directory
 manager password.

 Hope this helps,
 Guillermo


 On Thu, Aug 27, 2015 at 10:27 AM, Janelle janellenicol...@gmail.com
 wrote:

 On 8/27/15 1:05 AM, thierry bordaz wrote:

 On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:


 On 08/27/2015 09:08 AM, Martin Kosek wrote:

 On 08/26/2015 05:31 PM, Simo Sorce wrote:

 On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

 Hello all,

 My biggest problem is losing replicas and then trying to delete the
 entries and rebuild them. Here is a perfect example, I simply can't get
 rid of these  (see below). I have tried (of course after the ORIGINAL
 ipa-replica-manage del hostname --force --clean:

 ipa-replica-manage clean-ruv 25

 ldapmodify... with:
 dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
 objectclass: extensibleObject
 replica-base-dn: dc=example,dc=com
 replica-id: 25
 cn: clean 25

 And yet nothing works. Any suggestions? This is perhaps the most
 frustrating part about maintaining IPA.

 ~J

 unable to decode: {replica 12} 5588dc2e000c 559f3de60004000c
 unable to decode: {replica 14} 5587aa8d000e 5587aa8d0003000e
 unable to decode: {replica 16} 5588f58f0010 55bb7b0800050010
 unable to decode: {replica 25} 55a4887b0019 55a4924200040019
 unable to decode: {replica 29} 55d199a50001001d 55d199a50001001d
 unable to decode: {replica 3} 5587c5c30003 55b8a04900010003
 unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005

 Have you tried restarting DS before trying to clean the ruv ?

 I run in a similar problem in a test install recently, and I got better
 results that way. The bug is known to the DS people and they are working
 to get out patches that fix the root issue.

 Simo.

 CCing DS folks. Wasn't there a recent DS fix that was supposed to improve
 the
 RUV situation?

 Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x
 releases:


 https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone

 I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV
 issue
 happen there?

 it should not, and I think Thierry verified the fix.
 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.
 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.

 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


 Hello,

 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.
 According to the timestamp in the ruv (for example csn2date.py
 5587aa8d0003000e -- 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.

 The problem is that even a fixed server can get those corrupted
 ruv-elements from others

Re: [Freeipa-users] stubborn old replicas

2015-08-28 Thread Guillermo Fuentes

Hi Janelle,

Using the cleanallruv.pl tool was the only way I was able to get ride of
the unable to decode: {replica x} entries.

This is how I used it, cleaning a replica ID at a time:
# For replica id: 40
cleanallruv.pl -v -D cn=directory manager -w - -b 'dc=example,dc=com' -r
40

Note that the -w - will make the tool prompt you for the directory
manager password.

Hope this helps,
Guillermo

On Thu, Aug 27, 2015 at 10:27 AM, Janelle janellenicol...@gmail.com wrote:

On 8/27/15 1:05 AM, thierry bordaz wrote:

On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:

On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

My biggest problem is losing replicas and then trying to delete the
entries and rebuild them. Here is a perfect example, I simply can't get
rid of these (see below). I have tried (of course after the ORIGINAL
ipa-replica-manage del hostname --force --clean:

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps the most
frustrating part about maintaining IPA.

unable to decode: {replica 12} 5588dc2e000c 559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e 5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010 55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019 55a4924200040019
unable to decode: {replica 29} 55d199a50001001d 55d199a50001001d
unable to decode: {replica 3} 5587c5c30003 55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005

Have you tried restarting DS before trying to clean the ruv ?

I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to the DS people and they are working
to get out patches that fix the root issue.

Simo.

CCing DS folks. Wasn't there a recent DS fix that was supposed to improve
the
RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x
releases:

https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone

I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV
issue
happen there?

it should not, and I think Thierry verified the fix.
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.
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.

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

Hello,

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.
According to the timestamp in the ruv (for example csn2date.py
5587aa8d0003000e -- 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.

The problem is that even a fixed server can get those corrupted
ruv-elements from others servers.
All servers in the topology should be updated with that fix, so that at
least they stop creating corrupted ruv-elements.
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.

thanks
thierry

Simple question -- what if one is running RHEL 7.1?? Can this fix be
installed?? I see you mentioned it is in 1.3.4.0 for RHEL 7, but I don't
see it?

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the

Re: [Freeipa-users] stubborn old replicas

2015-08-27 Thread Janelle

On 8/27/15 1:05 AM, thierry bordaz wrote:

On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:

On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

My biggest problem is losing replicas and then trying to delete the
entries and rebuild them. Here is a perfect example, I simply
can't get

rid of these (see below). I have tried (of course after the ORIGINAL
ipa-replica-manage del hostname --force --clean:

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps the most
frustrating part about maintaining IPA.

unable to decode: {replica 12} 5588dc2e000c
559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e
5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010
55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019
55a4924200040019
unable to decode: {replica 29} 55d199a50001001d
55d199a50001001d
unable to decode: {replica 3} 5587c5c30003
55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005
55cc82ab041d0005

Have you tried restarting DS before trying to clean the ruv ?

I run in a similar problem in a test install recently, and I got
better
results that way. The bug is known to the DS people and they are
working

to get out patches that fix the root issue.

Simo.
CCing DS folks. Wasn't there a recent DS fix that was supposed to
improve the

RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x
releases:

https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone

I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the
RUV issue

happen there?

it should not, and I think Thierry verified the fix.
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.
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.

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

Hello,

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.
According to the timestamp in the ruv (for example csn2date.py
5587aa8d0003000e -- 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.

The problem is that even a fixed server can get those corrupted
ruv-elements from others servers.
All servers in the topology should be updated with that fix, so that
at least they stop creating corrupted ruv-elements.
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.

thanks
thierry

Simple question -- what if one is running RHEL 7.1?? Can this fix be
installed?? I see you mentioned it is in 1.3.4.0 for RHEL 7, but I don't
see it?

~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] stubborn old replicas

2015-08-27 Thread Ludwig Krispenz

On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps the most
frustrating part about maintaining IPA.

Have you tried restarting DS before trying to clean the ruv ?

I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to the DS people and they are working
to get out patches that fix the root issue.

Simo.

CCing DS folks. Wasn't there a recent DS fix that was supposed to improve the
RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x releases:

https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone

I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV issue
happen there?

it should not, and I think Thierry verified the fix.
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.
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.

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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] stubborn old replicas

2015-08-27 Thread Martin Kosek

On 08/26/2015 05:31 PM, Simo Sorce wrote:
 On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:
 Hello all,

 My biggest problem is losing replicas and then trying to delete the 
 entries and rebuild them. Here is a perfect example, I simply can't get 
 rid of these  (see below). I have tried (of course after the ORIGINAL  
 ipa-replica-manage del hostname --force --clean:

 ipa-replica-manage clean-ruv 25

 ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

 And yet nothing works. Any suggestions? This is perhaps the most 
 frustrating part about maintaining IPA.

 ~J

 unable to decode: {replica 12} 5588dc2e000c 559f3de60004000c
 unable to decode: {replica 14} 5587aa8d000e 5587aa8d0003000e
 unable to decode: {replica 16} 5588f58f0010 55bb7b0800050010
 unable to decode: {replica 25} 55a4887b0019 55a4924200040019
 unable to decode: {replica 29} 55d199a50001001d 55d199a50001001d
 unable to decode: {replica 3} 5587c5c30003 55b8a04900010003
 unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005
 
 Have you tried restarting DS before trying to clean the ruv ?
 
 I run in a similar problem in a test install recently, and I got better
 results that way. The bug is known to the DS people and they are working
 to get out patches that fix the root issue.
 
 Simo.

CCing DS folks. Wasn't there a recent DS fix that was supposed to improve the
RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x releases:

https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone

I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV issue
happen there?

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] stubborn old replicas

2015-08-27 Thread thierry bordaz

On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:

On 08/27/2015 09:08 AM, Martin Kosek wrote:

On 08/26/2015 05:31 PM, Simo Sorce wrote:

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:

Hello all,

My biggest problem is losing replicas and then trying to delete the
entries and rebuild them. Here is a perfect example, I simply can't
get

rid of these (see below). I have tried (of course after the ORIGINAL
ipa-replica-manage del hostname --force --clean:

ipa-replica-manage clean-ruv 25

ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25

And yet nothing works. Any suggestions? This is perhaps the most
frustrating part about maintaining IPA.

unable to decode: {replica 12} 5588dc2e000c
559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e
5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010
55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019
55a4924200040019
unable to decode: {replica 29} 55d199a50001001d
55d199a50001001d
unable to decode: {replica 3} 5587c5c30003
55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005
55cc82ab041d0005

Have you tried restarting DS before trying to clean the ruv ?

I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to the DS people and they are
working

to get out patches that fix the root issue.

Simo.
CCing DS folks. Wasn't there a recent DS fix that was supposed to
improve the

RUV situation?

Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x
releases:

https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone

I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV
issue

happen there?

it should not, and I think Thierry verified the fix.
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.
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.

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

Hello,

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.
According to the timestamp in the ruv (for example csn2date.py
5587aa8d0003000e -- 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.

thanks
thierry

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] stubborn old replicas

2015-08-26 Thread Simo Sorce

On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:
 Hello all,
 
 My biggest problem is losing replicas and then trying to delete the 
 entries and rebuild them. Here is a perfect example, I simply can't get 
 rid of these  (see below). I have tried (of course after the ORIGINAL  
 ipa-replica-manage del hostname --force --clean:
 
 ipa-replica-manage clean-ruv 25
 
 ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25
 
 And yet nothing works. Any suggestions? This is perhaps the most 
 frustrating part about maintaining IPA.
 
 ~J
 
 unable to decode: {replica 12} 5588dc2e000c 559f3de60004000c
 unable to decode: {replica 14} 5587aa8d000e 5587aa8d0003000e
 unable to decode: {replica 16} 5588f58f0010 55bb7b0800050010
 unable to decode: {replica 25} 55a4887b0019 55a4924200040019
 unable to decode: {replica 29} 55d199a50001001d 55d199a50001001d
 unable to decode: {replica 3} 5587c5c30003 55b8a04900010003
 unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005

Have you tried restarting DS before trying to clean the ruv ?

I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to the DS people and they are working
to get out patches that fix the root issue.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

Re: [Freeipa-users] stubborn old replicas

9 matches

Site Navigation

Mail list logo

Footer information