[Freeipa-users] FreeIPA 2.1.4 replication

Thu Jan 5 20:11:58 UTC 2012

Dan Scott wrote:
> On Wed, Jan 4, 2012 at 13:48, Rob Crittenden<rcritten at redhat.com>  wrote:
>> Dan Scott wrote:
>>>
>>> Hi,
>>>
>>> Recently I've had some crash/hang problems with my FreeIPA 2
>>> installation which appear solved using the updates-testing version of
>>> freeipa-server (2.1.4-2.fc16.x86_64) which I'm currently running on
>>> both servers (as a quick aside, does anyone know when 2.1.4 will be
>>> released to the main repos?).
>>>
>>> I'm still having problems creating replicas however. The replication
>>> process mostly completes, but fails with:
>>>
>>> Restarting IPA to initialize updates before performing deletes:
>>>    [1/2]: stopping directory server
>>>    [2/2]: starting directory server
>>> done configuring dirsrv.
>>> creation of replica failed: Command '/bin/systemctl restart
>>> krb5kdc.service' returned non-zero exit status 1
>>
>>
>> You'd need to see why the kdc is failing to start. /var/log/krb5kdc.log is a
>> place to start. dmesg/messages may have info, as well as systemctl status
>> service.krb5kdc.
>
> Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutdown
> signal received
> Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 11
> Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 12
> Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 10
> Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): closing down fd 9
> Jan 03 10:31:32 fileserver4.example.com krb5kdc[2050](info): shutting down
> krb5kdc: Can't contact LDAP server - while initializing database for
> realm EXAMPLE.COM
>
> Does it mean the new replica's LDAP server, or the existing LDAP server?

The new LDAP server. I think Martin was looking at a similar problem 
where a service restart was returning but it was actually up and 
available. This might account for it (sort of a timing issue).

Is your LDAP server running?

>
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>> [root at fileserver4 ~]#
>>>
>>> The replication appears to be working, but I'd like to have the
>>> configuration complete successfully to be sure.
>>>
>>> If I use the --setup-ca option, the process fails even earlier:
>>>
>>> Configuring certificate server: Estimated time 3 minutes 30 seconds
>>>    [1/12]: creating certificate server user
>>>    [2/12]: creating pki-ca instance
>>>    [3/12]: configuring certificate server instance
>>> root        : CRITICAL failed to configure ca instance Command
>>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname'
>>> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir'
>>> '/tmp/tmp-0h0omd' '-client_certdb_pwd' XXXXXXXX '-preop_pin'
>>> 'Vi8OHzzN0yjMDcqMv3aD' '-domain_name' 'IPA' '-admin_user' 'admin'
>>> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX
>>> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048'
>>> '-agent_key_type' 'rsa' '-agent_cert_subject'
>>> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com'
>>> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password'
>>> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048'
>>> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true'
>>> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name'
>>> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA
>>> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP
>>> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name'
>>> 'CN=fileserver4.example.com,O=EXAMPLE.COM'
>>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM'
>>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM'
>>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12'
>>> '-clone_p12_password' XXXXXXXX '-sd_hostname'
>>> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name'
>>> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true'
>>> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero
>>> exit status 255
>>> creation of replica failed: Configuration of CA failed
>>
>>
>> You need to look in /var/log/pki-ca/debug to determine where it failed. IIRC
>> the last time we looked at this there was some issue with the security
>> domain.
>
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](Error): preauth
> pkinit failed to initialize: No realms configured correctly for pkinit
> support
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): setting
> up network...
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening
> on fd 9: udp 0.0.0.0.88 (pktinfo)
> krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked
> krb5kdc: No realms configured correctly for pkinit support - Cannot
> request packet info for udp socket address :: port 88
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping
> unrecognized local address family 17
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): skipping
> unrecognized local address family 17
> krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening
> on fd 10: udp fe80::a00:27ff:fe5f:27a2%p2p1.88
> krb5kdc: setsockopt(11,IPV6_V6ONLY,1) worked
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening
> on fd 12: tcp 0.0.0.0.88
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): listening
> on fd 11: tcp ::.88
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2567](info): set up 4 sockets
> Jan 03 10:48:51 fileserver4.example.com krb5kdc[2568](info):
> commencing operation
>
> The only errors in /var/log/pki-ca/debug are:
> Error: unknown type org.apache.catalina.connector.ResponseFacade
> Error: unknown type java.lang.Boolean
> Error: unknown type org.apache.catalina.connector.RequestFacade

dogtag is way more subtle, unfortunately. The installer basically acts 
as a simple HTTP client, POSTing information to the wizard on the 
server. So you have to look to see where it is blowing up it is almost 
never very obvious. If you want to send me the debug log I'll take a 
look and/or pass it onto the dogtag guys.

rob