Hi Ludwig,
On 03/13/18 14:47, Ludwig Krispenz via FreeIPA-users wrote:
On 03/13/2018 09:07 AM, Harald Dunkel via FreeIPA-users wrote:
Hi Ludwig,
On 03/12/18 17:10, Ludwig Krispenz via FreeIPA-users wrote:
Hi,
to get rid of this ruv entry with replicaid 7 you could try to run the
cleanallruv task directly. On any server (and onöy on one) run
ldapmodify ..... -D "cn=directory manager"
|dn: cn=clean 7, cn=cleanallruv, cn=tasks, cn=config changetype: add objectclass:
extensibleObject replica-base-dn: <your suffix > replica-id: 7
replica-force-cleaning: yes |
|But I would like to understand how you did get in|to this state, we have seen
this occasionly, but have no reproducer. Unfortunately the csn for replicaid 7
is from Jan, 19th 2017 11:01:16 - so you will probably not remember
||
Not sure if its related, but I wrote an EMail to freeipa-users on that day,
reporting an internal error. See
https://www.redhat.com/archives/freeipa-users/2017-January/msg00286.html
the csn of the replicaid 7 is from Jan,19th, two days later. maybe you did ad a
new replica, or removed one or ...
Got confused by the "17". But maybe the problem was introduced when I
tried to examine or fix the conflict. Just a wild guess.
Looks like you have three problems and I don't think they are related.
1] corrupt RUV element, as Thierry said, we believe to have an an explanation
how it could occur before a specific fix, and since it is there for one year
you didn't have that fix. To get rid of this you could apply cleanallruv as I
suggested in a previous mail, if you do not want to do it, I think it was there
for quite some time and doesn't do really any harm except raising errors in
decoding it.
I will try the cleanallruv at the weekend.
2] conflicts, looks like you have conflitcts remaining which are relate to
managed entries, these are espcially bad and difficult to handle. if you delete
the conflict of an original entry it will delete the real managed entry and not
the conflict of the managed entry. And the managed entry plugin is trying to
prevent you to modify these entries directly.
So what you can do is: determine which entries should be there, then delete
them or rename them, if managed enty plugin gets in the way, either disable the
MEP plugin temporarily or modify teh entries by deleting the mep objectclasses
and attributes, cleanup the conflicts and fix them again
I have the impression that the entry
"cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de"
has been lost. Is it?
If I got you correctly I have to rename
cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de
to
cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de
Next I have to add
memberOf: cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de
to
dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de
The entry
dn:
cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de
can be deleted then. If the mep complains, then I could try to delete
the mepManagedBy entry and add it later again.
Is this correct?
3] Retro Changelog errors: An error occured while adding change number
14065299 .....
This looks like the retro changelog did mess up the counter to generate the
next entry. a restart should hopefully reset it and let the RCL continue
The restart did not help, but I could re-initialize ipa1 and ipa4 from
ipa2. They appear to be in sync again, but I would like to make sure
that they *stay* in sync.
Thanx for your support
Harri
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
