freeipa

#9549 server-del don't delete meTo records
Opened by pavkamlc. Modified

Open
Close Issue

Request for enhancement

As , I want so that .

Issue

After unsuccessful add replica is not possible to correctly add replica server again

Steps to Reproduce

  1. Install and configure primary server ipa1
  2. Install replica server ipa2
  3. Unsuccessful configuring replica
  4. ipa server-del ipa2.pavkamlc.cz --force
  5. /usr/sbin/ipa-server-install --uninstall
  6. ldapsearch -LLL -o ldif-wrap=no ..... -b "cn=config" "objectclass=nsds5replicationagreement" nsDS5ReplicaRoot nsDS5ReplicaHost | grep ipa2

Actual behavior

1) dn: cn=meToipa2.pavkamlc.cz,cn=replica,cn=dc\3Dpavkamlc\2Cdc\3Dcz,cn=mapping tree,cn=config
2) ipa-replica-install says Your system may be partly configured.

Expected behavior

working ipa-replica-install

Version/Release/Distribution

[admin@ipa2]$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.11.0-5.el9.x86_64
ipa-client-4.11.0-5.el9.x86_64
389-ds-base-2.4.5-3.el9.x86_64
package pki-ca is not installed
krb5-server-1.21.1-1.el9.x86_64
[admin@ipa1]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.9.12-11.module+el8.9.0+1652+4ee71f6a.x86_64
ipa-client-4.9.12-11.module+el8.9.0+1652+4ee71f6a.x86_64
389-ds-base-1.4.3.37-2.module+el8.9.0+1655+39468843.x86_64
package pki-ca is not installed
krb5-server-1.18.2-26.el8.x86_64

Additional info:

Used links

https://www.freeipa.org/page/Files_to_be_attached_to_bug_report
https://www.freeipa.org/page/V4/Replica_Setup#ipa-replica-configuration

ipareplica-install.log

Thanks for your report.
On which machine was the ipa server-del command executed (the primary server or the replica?), and do you have the logs from this machine? The files /var/log/httpd/error_log /var/log/dirsrv/slapd-YOURDOMAIN/access and /var/log/dirsrv/slapd-YOURDOMAIN/errors may provide additional information, with logs from the date the ipa server-del command was run.

In order to clean up, you can try to run ipa topologysegment-find domain and then ipa topologysegment-del domain name-of-found-segment.

I noticed that the replica installation was done with --skip-conncheck. Usually this means that there is a DNS issue in your topology (for instance the server is unable to resolve the replica's name), this may explain why the replica installation failed in the first try.

The issue can be reproduced if the master is unable to resolve the replica's name and replica installation failed during the step "setting up initial replication".

When the admin call ipa server-del replica.ipa.test --force, the pre_callback method is executed and creates a topology_connectivity graph: https://github.com/freeipa/freeipa/blob/ca776b6a9ca9f6b9884491909eb7e01522aef58b/ipaserver/plugins/server.py#L741

This method builds a graph with a list of servers obtained with ipa server-find and a list of segments obtained with ipa topologysegment-find. As the replica installation failed, server-find does not return the replica and the graph does not contain replica in its vertices.

Later on, the postcallback is executed and reuses the graph obtained in the pre_callback. As the replica is not a vertice in the graph, the method skips the agreement deletion (https://github.com/freeipa/freeipa/blob/ca776b6a9ca9f6b9884491909eb7e01522aef58b/ipaserver/plugins/server.py#L874)
This explains why we don't see any error even though the replication agreement is still visible.

Now we need to understand why the topology plugin doesn't remove the segment when the host is deleted...

Thanks for your report.
On which machine was the ipa server-del command executed (the primary server or the replica?), and do you have the logs from this machine? The files /var/log/httpd/error_log /var/log/dirsrv/slapd-YOURDOMAIN/access and /var/log/dirsrv/slapd-YOURDOMAIN/errors may provide additional information, with logs from the date the ipa server-del command was run.

ipa server-del on primary machine

In order to clean up, you can try to run ipa topologysegment-find domain and then ipa topologysegment-del domain name-of-found-segment.

I noticed that the replica installation was done with --skip-conncheck. Usually this means that there is a DNS issue in your topology (for instance the server is unable to resolve the replica's name), this may explain why the replica installation failed in the first try.

topologysegment-del clean meToipa2 correctly. At now I can´t found this ldap records.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.