[Freeipa-users] New install, unsupported format?

[Standa Laznicka]

On 02/27/2017 04:51 PM, Steve Huston wrote:
> On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka <slaznick at 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 )
>