[Freeipa-users] A couple of issues found with ipa-2.1.3-9 during setup/early use

[Rob Crittenden]

Charlie Derwent wrote:
> Hi
> I've been testing our potential new IPA server before roll out and while
> setting up a replica with ipa-server-2.1.3-9 I encountered the following
> issues during installation
> [root at ipa2 ~]# ipa-replica-install --setup-dns --no-forwarders --no-ntp
> /var/lib/ipa/replica-info-ipa2.test.net.gpg
>
> Directory Manager (existing master) password:____
>
> __ __
>
> Run connection check to master____
>
> Check connection from replica to remote master 'ipa1.test.net
> <http://ipa1.test.net/>':____
>
>     Directory Service: Unsecure port (389): OK____
>
>     Directory Service: Secure port (636): OK____
>
>     Kerberos KDC: TCP (88): OK____
>
>     Kerberos KDC: UDP (88): OK____
>
>     Kerberos Kpasswd: TCP (464): OK____
>
>     Kerberos Kpasswd: UDP (464): OK____
>
> HTTP Server: port 80 (80): OK____
>
>     HTTP Server: port 443(https) (443): OK____
>
> __ __
>
> Connection from replica to master is OK.____
>
> Start listening on required ports for remote master check____
>
> Exception in thread Thread-2:____
>
> Traceback (most recent call last):____
>
>    File "/usr/lib64/python2.6/threading.py", line 532, in
> __bootstrap_inner____
>
>      self.run()____
>
>    File "/usr/sbin/ipa-replica-conncheck", line 238, in run____
>
>      self.socket_timeout, responder_data="FreeIPA")
>
>    File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line
> 1134, in bind_port_responder____
>
>      raise e____
>
> error: [Errno 97] Address family not supported by protocol
> The same error runs across all threads. Turning on debug I can see that
> it happens when this command is passed to the server
> ipa-replica-conncheck --master ipa1.test.net <http://ipa1.test.net>
> --auto-master-check --realm TEST.NET <http://TEST.NET> --principal admin
> --hostname ipa2.test.net <http://ipa2.test.net>

Hmm, what does your network config look like? IPv4-only, IPv6-only or a mix?

> I got round that by running --skip-conncheck during the replica-install
> but was suprised I've heard no-one else has mentioned the issue is there
> anyway I can get some lower level debug info to find out the root cause
> of the issue? The other thing I noticed is when hosts enroll no
> timestamp appears in the "Enrolled?" column on the webui, it's not a
> major problem but my guys quite liked using it as a visual aid to work
> though the servers they had configured. I've looked at the 2.1.4 change
> log and nothing was mentioned regarding fixes for either issue.

IIRC the UI was using the date of the last host service principal 
password change as the date of enrollment and this could be misleading 
so we changed it to a simple yes/no.

rob