<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="DE-CH" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hello<o:p></o:p> <o:p> </o:p> First, we really would like to thank the developers / community for the great work doing with FreeIPA!<o:p></o:p> <o:p> </o:p> At our company, we’re using a CentOS7 based FreeIPA installation (uspidm01 primary and uspidm02 replica) and it worked like a charm the last couple of months. Last week we suffered a severe outage (DNS related) and are still suffering from this on. We have a similar issue as reported by<o:p></o:p> <o:p> </o:p> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=826677">https://bugzilla.redhat.com/show_bug.cgi?id=826677</a> (upstream <a href="https://pagure.io/freeipa/issue/2797">https://pagure.io/freeipa/issue/2797</a>) <o:p></o:p> <a href="https://www.redhat.com/archives/freeipa-users/2013-May/msg00034.html">https://www.redhat.com/archives/freeipa-users/2013-May/msg00034.html</a> <o:p></o:p> <a href="https://www.redhat.com/archives/freeipa-users/2012-June/msg00382.html">https://www.redhat.com/archives/freeipa-users/2012-June/msg00382.html</a> <o:p></o:p> <o:p> </o:p> mainly our synchronization stopped with uspidm02 (replica) logging:<o:p></o:p> <o:p> </o:p> “[27/Mar/2017:11:57:39.756880208 +0200] NSMMReplicationPlugin - agmt="cn=meTouspidm01.[domainname].[tld]" (uspidm01:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized.”<o:p></o:p> <o:p> </o:p> We tried to re-initialize using “ipa-replica-manage re-initialize --from uspidm01.[domain].[tld]” but this failed. After this we headed for a “clean” first remove then add again solution (knowing that we will temporarily loss the replica and loss any unsynchronized changes). We followed upstream documentation from RedHat (see below) on this.<o:p></o:p> <o:p> </o:p> Unfortunately, the “ipa-replica-manage list” command still lists both servers (uspidm01 and uspidm02). The error given by a forced removal using “ipa-replica-manage del --no-lookup --force --cleanup uspidm02.[domain].[tld]” is<o:p></o:p> <o:p> </o:p> Cleaning a master is irreversible.<o:p></o:p> This should not normally be require, so use cautiously.<o:p></o:p> Continue to clean master? [no]: yes<o:p></o:p> unexpected error: This entry already exists<o:p></o:p> <o:p> </o:p> we then tried to further debug the python code used (ipa-replica-manage) and could identify using PDB that the function “replica_cleanup” from “/usr/lib/python2.7/site-packages/ipaserver/install/replication.py” complains about duplicate entries:<o:p></o:p> <o:p> </o:p> <o:p> </o:p> /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1203)replica_cleanup()<o:p></o:p> -> self.conn.delete_entry(entry)<o:p></o:p> (Pdb) n<o:p></o:p> DuplicateEntry: Duplicat...exists',)<o:p></o:p> > /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1203)replica_cleanup()<o:p></o:p> -> self.conn.delete_entry(entry)<o:p></o:p> (Pdb) n<o:p></o:p> > /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1204)replica_cleanup()<o:p></o:p> -> except errors.NotFound:<o:p></o:p> (Pdb) n<o:p></o:p> > /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1206)replica_cleanup()<o:p></o:p> -> except Exception, e:<o:p></o:p> ...<o:p></o:p> <o:p> </o:p> Using LDAPSearch we can confirm there are still entries listed for the ghost/offline server uspidm02 (which seems the reason why ipa-replica-manage still lists it). But we cannot identify where a duplicate entry is exactly. As long as there are entries for this host, it can not be added again (a ipa-server cannot be removed using “ipa host-del” and adding a new also fails).<o:p></o:p> <o:p> </o:p> Our situation for now is we're having a "read-only" IDM solution since any modification (password change, adding new servers, ...) fails. Adding a new replica (new name) is also failing. We suspect if we could clean up the ghost replica entry we should be able to restore IDM / replica again.<o:p></o:p> <o:p> </o:p> Any help would be greatly appreciated!!<o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> Rolf<o:p></o:p> <o:p> </o:p> Documentation used:<o:p></o:p> Uninstallation: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/replica-uninstall.html"> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/replica-uninstall.html</a> <o:p></o:p> New installation: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html"> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html</a> <o:p></o:p> <o:p> </o:p> Versions in use: initially both servers were updated to ipa-server-4.4.0-14.el7.centos.6.x86_64, uspidm01 was rollbacked to ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 (eliminating any upgrade issues)<o:p></o:p> <o:p> </o:p> </div> </body> </html>