Just an update on this.
Came back from the long weekend and 50% of our servers (3) were not responding,
the dirsrv was crashing everytime it had an update from the CA master (we could
not figure out why). If we closed the firewall between replica and CA master
the servers stayed up.
After a
Nicholas Cross via FreeIPA-users wrote:
> Ah got it! Wonderful.
>
> The trick as to run the topologysegement-del on the same server it was on.
>
> It seems i am moving forward with this now - thanks.
>
>
> #
> # To remove the topology segment, which removed the replica agreement
> #
>
> #
>
Ah got it! Wonderful.
The trick as to run the topologysegement-del on the same server it was on.
It seems i am moving forward with this now - thanks.
#
# To remove the topology segment, which removed the replica agreement
#
#
# Show the bad replication agreement
#
# ipa-replica-manage list
Tested this again making sure that dirsrv is not running and the replica record
is back.
I am obviously doing something wrong. My steps are below. I appreciate your
time on this.
#
# check dirsrv is currently running
#
[root@ipa006 ~]# ps aux | grep dirsrv
dirsrv 3221639 31.4 5.4
Nicholas Cross via FreeIPA-users wrote:
> Shutdown dirsrv
> backed up dse.ldif
> edited the ldif
> restarted dirsrv
>
> replication agreement came back!
>
> Is it being sync'ed from some where else? another file?
It sounds like dirsrv was still running if values in cn=config were
restored. It
Shutdown dirsrv
backed up dse.ldif
edited the ldif
restarted dirsrv
replication agreement came back!
Is it being sync'ed from some where else? another file?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an
Thanks for the tips. I'll run the trace on Monday.
Also i'll edit the ldif Monday too.
Distro: alma9
# rpm -qa | grep ipa | sort
almalinux-logos-ipa-90.5.1-1.1.el9.noarch
ipa-client-4.10.0-8.el9_1.x86_64
ipa-client-common-4.10.0-8.el9_1.noarch
ipa-common-4.10.0-8.el9_1.noarch
Nicholas Cross via FreeIPA-users wrote:
> I think i have a handle on this now.
>
> There are a number of issues that i am now aware of.
>
> 1. old replication agreement to oldbox1 on newbox6
>
> 2. corrupt RUVs, giving the impression of Ghost Replicas.
>
> For #1 i normally can delete these
I think i have a handle on this now.
There are a number of issues that i am now aware of.
1. old replication agreement to oldbox1 on newbox6
2. corrupt RUVs, giving the impression of Ghost Replicas.
For #1 i normally can delete these fine with a ldap command. BUT! running
this crashes the
