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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
