On 02/27/2017 04:51 PM, Steve Huston wrote:
On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka <slazn...@redhat.com> wrote:
Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can
run `ipa domainlevel-get` on the master if you don't know)? Did you have a
client installed prior to ipa-replica-install?
It's level 1.  I did have a couple clients installed, and the machine
I was trying to promote to a replica was one of them.  This whole
instance is a testing instance, with live data but not in production,
while I make sure everything works as expected before I deploy it, so
the servers and their data are new as of a couple weeks ago and began
life as a RHEL7.3 install.

It seems there might be two issues here; the one I originally reported
was that the ipa-server packages installed on a client machine are
unable to talk to the server, even though it obviously knows what the
server is (the "unsupported format" error I originally shared).  The
second is with setting up a replica in general.
The server rpm packages should have no impact on client settings if neither server nor replica are installed on the given machine. IIRC client only uses the NSS database in /etc/ipa/nssdb, you may want to check the permissions there (should be o+xr for the folder, o+r for the *.db files there).
I had tried the various methods outlined in the RedHat IdM
documentation, including promoting a client via an administrators TGT,
adding the client to the ipaservers group on the server, etc.  What
did finally work was unprovisioning the client, setting a one-time
password, and running "ipa-replica-install -v
--domain=astro.princeton.edu --server=ipa.astro.princeton.edu
--realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu
--setup-ca -p foobar" - this yielded a fully working replica when it
finished.  All of the previous failures happened in the same way as
mentioned before - it seems to unprovision the client for some reason,
then fail in reprovisioning it.
I believe your machine might have been in some kind of undecided state when you tried to promote a client to a replica. What happens during replica installation on domain level 1 is that client installation is checked first. If client is installed the installation continues with other steps, if it's not, it tries to install the client. In your case, you probably had your client installed at first and tried to install replica. Something bad happened, can't be sure what, the installation failed and tried to uninstall the client but that might have failed, too. Eventually, you uninstalled the client yourself successfully, all files were removed and its records were also removed from the server. This made it possible to eventually successfully install a replica. I wouldn't bet my life on it but I'd think the installation could have gone successfully even if you installed a client and tried to promote it again :)

Anyway, I am sorry to hear you had such troubles, the replica installation is not usually such a painful process, I hope you will have more luck with FreeIPA in the future.
One problem which has cropped up before and caused problems is with
DNS capitalization.  DNS reports the domain name of "Princeton.EDU"
for hosts here, which means in order to do just about anything with a
FreeIPA server I have to manually add the host to /etc/hosts with all
lowercase letters.  I also have to force all of the host names via
command line switches so that DNS is not consulted for lookups, which
will return the StudlyCaps names and fail.  I suppose I should raise
that as a separate issue, because my understanding is that
hostnames/domainnames should be case insensitive so I'm not sure why
FreeIPA cares (and it may be easier to steer the entire project to not
care than convince those in control of DNS here to change it :D )

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to