[Freeipa-users] ipa replica install fails

Petr Spacek pspacek at redhat.com
Tue Feb 5 16:33:39 UTC 2013


On 5.2.2013 17:15, Rajnesh Kumar Siwal wrote:
> Last time the installation of replica failed. So this is second time I
> did it (The logs in the mail are from the second time after I
> uninstalled the ipa2).
>
> After installing the replica, I restarted IPA and failed to start the KDC too.
> So, kinit admin is now failing.

Correct me if I'm wrong, please:
Now you have 2 replicas, one of them is not starting and you can't kinit?

In that case you really have some network/firewall problems, because kinit 
should failover to the functional replica.

I would recommend to really debug network/firewall and then continue with 
something else.

Petr^2 Spacek

> ---------------------------------------------------------------------
>
> [root at ipa2 log]# klist -ket /etc/named.keytab
> Keytab name: WRFILE:/etc/named.keytab
> KVNO Timestamp         Principal
> ---- ----------------- --------------------------------------------------------
>     2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes256-cts-hmac-sha1-96)
>     2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes128-cts-hmac-sha1-96)
>     2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (des3-cbc-sha1)
>     2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (arcfour-hmac)
> [root at ipa2 log]# kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ
> kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting
> initial credentials
> ---------------------------------------------------------------------------------------------------------------
>
> On Tue, Feb 5, 2013 at 8:15 PM, Rajnesh Kumar Siwal
> <rajnesh.siwal at gmail.com> wrote:
>> Finally , I installed it with "--skip-conncheck":-
>> Now DNS fails to start.
>> I tried ipa-dns-install too:-
>>
>> [root at ipa2 log]# ipa-dns-install
>> The log file for this installation can be found in
>> /var/log/ipaserver-install.log
>> ==============================================================================
>> This program will setup DNS for the IPA Server.
>>
>> This includes:
>>    * Configure DNS (bind)
>>
>> To accept the default shown in brackets, press the Enter key.
>> Existing BIND configuration detected, overwrite? [no]: yes
>> DNS is already configured in this IPA server.
>> [root at ipa2 log]# /etc/init.d/ipa status
>> Directory Service: RUNNING
>> KDC Service: RUNNING
>> KPASSWD Service: RUNNING
>> DNS Service: STOPPED
>> MEMCACHE Service: RUNNING
>> HTTP Service: RUNNING
>> CA Service: RUNNING
>> [root at ipa2 log]# /etc/init.d/named restart
>> Stopping named:                                            [  OK  ]
>> Starting named:                                            [FAILED]
>>
>> ---------------------------------------------------------------------------------------------
>> DNS logs :-
>> Feb  5 09:40:19 ipa2 named[19873]:
>> ----------------------------------------------------
>> Feb  5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet
>> Systems Consortium,
>> Feb  5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3)
>> public-benefit
>> Feb  5 09:40:19 ipa2 named[19873]: corporation.  Support and training
>> for BIND 9 are
>> Feb  5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support
>> Feb  5 09:40:19 ipa2 named[19873]:
>> ----------------------------------------------------
>> Feb  5 09:40:19 ipa2 named[19873]: adjusted limit on open files from
>> 102400 to 1048576
>> Feb  5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads
>> Feb  5 09:40:19 ipa2 named[19873]: using up to 4096 sockets
>> Feb  5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf'
>> Feb  5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range:
>> [1024, 65535]
>> Feb  5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range:
>> [1024, 65535]
>> Feb  5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53
>> Feb  5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53
>> Feb  5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0,
>> 172.31.254.205#53
>> Feb  5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS
>> Feb  5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones
>> Feb  5 09:40:19 ipa2 named[19873]: set up managed keys zone for view
>> _default, file 'dynamic/managed-keys.bind'
>> Feb  5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS
>> failure.  Minor code may provide more information (Mutual
>> authentication failed)
>> Feb  5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error
>> Feb  5 09:40:19 ipa2 named[19873]: loading configuration: failure
>> Feb  5 09:40:19 ipa2 named[19873]: exiting (due to fatal error)
>> Feb  5 09:40:28 ipa2 kernel: IN=eth0 OUT=
>> MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0
>> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP
>> SPT=68 DPT=67 LEN=308
>> [root at ipa2 log]# klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: admin at XYZ.DMZ
>> Valid starting     Expires            Service principal
>> 02/05/13 14:32:56  02/06/13 14:32:24  krbtgt/XYZ.DMZ at XYZ.DMZ
>> 02/05/13 14:33:16  02/06/13 14:31:34  ldap/ipa2.xyz.dmz at XYZ.DMZ
>>
>>
>>
>> On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal
>> <rajnesh.siwal at gmail.com> wrote:
>>> Hi Rob,
>>>
>>> Thanks for the quick reply.
>>> I tried logging iptables in the replica also, but no log for dropped packet :-
>>> I would appreciate if you could please let me know what these login actually do.
>>> 1. Looks to me as getting tgt for admin
>>> 2. Is it trying to login though ssh to ipa1 server ?
>>> ----------------------------------------------------------------------
>>> Get credentials to log in to remote master
>>>   admin at XYZ.DMZ password:
>>>
>>>   Execute check on remote master
>>>   admin at ipa1.xyz.dmz's password:
>>> ----------------------------------------------------------------------
>>>
>>> SELINUX is disabled at both the ends.
>>>
>>> Is there any other log file that may suggest something.
>>> It would be great if we could figure out whats the cause of the error.
>>> -----------------------------------------------------------------------------------------------------------------------
>>>
>>> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>>> Rajnesh Kumar Siwal wrote:
>>>>>
>>>>> We are trying to setup the IPA replication but it says "Connection
>>>>> check failed!".
>>>>> We disabled the firewall and found the same result.
>>>>>
>>>>>
>>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns
>>>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg
>>>>> ipa         : DEBUG    /usr/sbin/ipa-replica-install was invoked with
>>>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options:
>>>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False,
>>>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False,
>>>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None,
>>>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True,
>>>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')],
>>>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False}
>>>>> ipa         : DEBUG    Loading Index file from
>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index'
>>>>> ipa         : DEBUG    Loading StateFile from
>>>>> '/var/lib/ipa/sysrestore/sysrestore.state'
>>>>> ipa         : DEBUG    Loading Index file from
>>>>> '/var/lib/ipa/sysrestore/sysrestore.index'
>>>>> Directory Manager (existing master) password:
>>>>>
>>>>> ipa         : DEBUG    args=/usr/bin/gpg --batch --homedir
>>>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty
>>>>> -o /tmp/tmpRGaqDpipa/files.tar -d
>>>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg
>>>>> ipa         : DEBUG    stdout=
>>>>> ipa         : DEBUG    stderr=gpg: WARNING: unsafe permissions on
>>>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg'
>>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created
>>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created
>>>>> gpg: 3DES encrypted data
>>>>> gpg: encrypted with 1 passphrase
>>>>> gpg: WARNING: message was not integrity protected
>>>>>
>>>>> ipa         : DEBUG    args=tar xf /tmp/tmpRGaqDpipa/files.tar -C
>>>>> /tmp/tmpRGaqDpipa
>>>>> ipa         : DEBUG    stdout=
>>>>> ipa         : DEBUG    stderr=
>>>>> Run connection check to master
>>>>> Check connection from replica to remote master 'ipa1.xyz.dmz':
>>>>>      Directory Service: Unsecure port (389): OK
>>>>>      Directory Service: Secure port (636): OK
>>>>>      Kerberos KDC: TCP (88): OK
>>>>>      Kerberos Kpasswd: TCP (464): OK
>>>>>      HTTP Server: Unsecure port (80): OK
>>>>>      HTTP Server: Secure port (443): OK
>>>>>      PKI-CA: Directory Service port (7389): OK
>>>>>
>>>>> The following list of ports use UDP protocol and would need to be
>>>>> checked manually:
>>>>>      Kerberos KDC: UDP (88): SKIPPED
>>>>>      Kerberos Kpasswd: UDP (464): SKIPPED
>>>>>
>>>>> Connection from replica to master is OK.
>>>>> Start listening on required ports for remote master check
>>>>> Get credentials to log in to remote master
>>>>> admin at XYZ.DMZ password:
>>>>>
>>>>> Execute check on remote master
>>>>> admin at ipa1.xyz.dmz's password:
>>>>>
>>>>> Remote master check failed with following error message(s):
>>>>>
>>>>> ipa         : DEBUG    args=/usr/sbin/ipa-replica-conncheck --master
>>>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin
>>>>> --hostname ipa2.xyz.dmz --check-ca
>>>>> Connection check failed!
>>>>> Please fix your network settings according to error messages above.
>>>>> If the check results are not valid it can be skipped with
>>>>> --skip-conncheck parameter.
>>>>>
>>>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>> Please suggest
>>>>
>>>>
>>>> Each server has its own iptables configuration.
>>>>
>>>> The test from the replica to the master succeeded. What failed is the
>>>> connection test from the master to the replica, so I'd look at the iptables
>>>> configuration on the replica machine.
>>>>
>>>> If that turns out ok it could be a false positive. You can add the
>>>> --skip-conncheck to the ipa-replica-install command to skip this test.




More information about the Freeipa-users mailing list