When connecting to an an unknown or irrelevant master, we print a confusing error message:
# ipa-replica-manage connect foo You cannot connect to a previously deleted master
There may be no mean to distinguish between previously deleted master and completely foreign master, but we should at least improve the error message.
FreeIPA 3.0.0 GA has been released, moving the ticket to 3.0 bugfixing release.
master: e7c99e7
ipa-3-0: 5ff4025
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=908094 (Red Hat Enterprise Linux 6)
FWIW this fix is 3.0.1, which is NOT part of CentOS/RHEL 6.5... Only 3.0.0 is. Hit this and git tag --contains helped :)
Question: What is the correct way to actually run this check to see if the server is not an IPA server yet? Should I extract the necessary python code from the git link above and can I use those libs (is that stable?) or should these error messages get proper (stable) return exit codes? (or both?)
Thanks, James
Side note: I have found that running (ON THE FIRST MASTER, eg: ipa1.example.com) I can run:
ipa-replica-conncheck -R ipa2.example.com
And this only returns true (eg: 0) when the replica is actually installed... Hope this is an appropriate hack. If it's not, let me know. :)
In other words when ipa-replica-conncheck -R ipa2.example.com returns true, then I know it's safe to try and run the ipa-replica-manage connect ipa2.example from ipa1.example.com because otherwise it will always fail.
ipa-replica-conncheck doesn't validate that a server is an IPA server, it just ensures that the required ports are available.
See the function ipacheckldap in ipa-client/ipaclient/ipadiscovery.py
Metadata Update from @mkosek: - Issue assigned to tbabej - Issue set to the milestone: FreeIPA 3.0.1 (bug fixing)
Login to comment on this ticket.