[Freeipa-users] ipa replica install fails
Rob Crittenden
rcritten at redhat.com
Tue Feb 5 16:59:21 UTC 2013
Rajnesh Kumar Siwal wrote:
> Both of these replica are in the same network.
> I have disabled the iptables on both
> Selinux disable.
> still the output of kinit admin is the same
> kinit: Cannot contact any KDC for realm
>
> strace output attached.
strace isn't really helpful in this case.
Is the KDC running? You might want to check /var/log/krb5kdc.log to see
what it says.
rob
>
>
> On Tue, Feb 5, 2013 at 9:45 PM, Rajnesh Kumar Siwal
> <rajnesh.siwal at gmail.com> 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.
>> ---------------------------------------------------------------------
>>
>> [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.
>>>>>
>>>>> rob
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Rajnesh Kumar Siwal
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Rajnesh Kumar Siwal
>>
>>
>>
>> --
>> Regards,
>> Rajnesh Kumar Siwal
>
>
>
More information about the Freeipa-users
mailing list