[Freeipa-users] Unable to start replica server after setting up replication

Wed Jan 30 17:02:30 UTC 2013

On 2013/30/01 11:59, Dmitri Pal wrote:
> On 01/30/2013 11:43 AM, freeipa at stormcloud9.net wrote:
>> On 2013/30/01 09:37, Martin Kosek wrote:
>>> On 01/30/2013 03:22 PM, freeipa at stormcloud9.net wrote:
>>>> On 2013/30/01 09:19, Martin Kosek wrote:
>>>>> On 01/30/2013 03:16 PM, Patrick Hemmer wrote:
>>>>>> On 2013/30/01 03:33, Martin Kosek wrote:
>>>>>>> On 01/30/2013 02:05 AM, freeipa at stormcloud9.net wrote:
>>>>>>>> On 01/29/2013 07:49 PM, Dmitri Pal wrote:
>>>>>>>>> On 01/29/2013 07:26 PM, freeipa at stormcloud9.net wrote:
>>>>>>>>>> Using ipa-server 2.2.0-17 on Amazon linux (RHEL6 clone), and after using the
>>>>>>>>>> `ipa-replica-install` script to configure the replica server, the service
>>>>>>>>>> will not start. Whenever I try it throws "SASL(-4): no mechanism available"
>>>>>>>>>> during start.
>>>>>>>>>>
>>>>>>>>>> Any ideas?
>>>>>>>>>>
>>>>>>>>>> Full output:
>>>>>>>>>>
>>>>>>>>>> # /etc/init.d/ipa start
>>>>>>>>>> Starting Directory Service
>>>>>>>>>> Starting dirsrv:
>>>>>>>>>>     CLIFF-CLOUDBURRITO-COM...                              [  OK  ]
>>>>>>>>>>     PKI-IPA...                                             [  OK  ]
>>>>>>>>>> Failed to read data from Directory Service: Unknown error when retrieving
>>>>>>>>>> list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ',
>>>>>>>>>> 'desc': 'Unknown authentication method'}
>>>>>>>>>> Shutting down
>>>>>>>>>> Shutting down dirsrv:
>>>>>>>>>>     CLIFF-CLOUDBURRITO-COM...                              [  OK  ]
>>>>>>>>>>     PKI-IPA...                                             [  OK  ]
>>>>>>>>> Sounds like DS did not start under the CA. Please check the DS logs in the
>>>>>>>>> PKI instance.
>>>>>>>> ns-slapd appears to be starting fine. I can even start it manually, but `ipactl
>>>>>>>> status` still shows the error:
>>>>>>>> Below is the result of me starting it manually (directly running ns-slapd):
>>>>>>>>
>>>>>>>> # ps ax|grep slapd
>>>>>>>> 15540 ?        Sl     0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i
>>>>>>>> /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid
>>>>>>>> 15586 ?        Sl     0:00 /usr/sbin/ns-slapd -D
>>>>>>>> /etc/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM -i
>>>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.pid -w
>>>>>>>> /var/run/dirsrv/slapd-CLIFF-CLOUDBURRITO-COM.startpid
>>>>>>>> # netstat -tpnl | grep slapd
>>>>>>>> tcp        0      0 :::636                      :::*                       
>>>>>>>> LISTEN      15586/ns-slapd     
>>>>>>>> tcp        0      0 :::7389                     :::*                       
>>>>>>>> LISTEN      15540/ns-slapd     
>>>>>>>> tcp        0      0 :::7390                     :::*                       
>>>>>>>> LISTEN      15540/ns-slapd     
>>>>>>>> tcp        0      0 :::389                      :::*                       
>>>>>>>> LISTEN      15586/ns-slapd     
>>>>>>>> # ipactl status
>>>>>>>> Directory Service: RUNNING
>>>>>>>> Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4):
>>>>>>>> no mechanism available: ', 'desc': 'Unknown authentication method'}
>>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> OK, it seems that ipactl could not bind to your Directory Server. This script
>>>>>>> uses a "ldap_uri" configuration option value from /etc/ipa/default.conf to
>>>>>>> connect to Directory Server via EXTERNAL auth.
>>>>>>>
>>>>>>> You can verify yourself if that bind works or not with the following ldapsearch
>>>>>>> (just replace $LDAP_URI_VALUE with your setting):
>>>>>>>
>>>>>>> # ldapsearch -Y EXTERNAL -H $LDAP_URI_VALUE -b
>>>>>>> "cn=masters,cn=ipa,cn=etc,dc=cliff,dc=cloudburrito,dc=com"
>>>>>>>
>>>>>>> I assume it will report the same error as ipactl. We need to verify that the
>>>>>>> referred LDAP URI is indeed right and functional.
>>>>>>>
>>>>>>> Martin
>>>>>> The system had no /etc/ipa/default.conf
>>>>>> I copied the one from the master server, changed the `host=` and
>>>>>> `xmlrpc_uri=` parameters to reflect the replica server, and now `ipactl
>>>>>> status`, along with everything else, is working perfectly.
>>>>>> Should that file have been created during the `ipa-replica-install`
>>>>>> process? I don't see anything in the documentation about having to copy
>>>>>> and edit it manually.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Patrick
>>>>>>
>>>>> Yeah, this should have been created during ipa-replica-install.
>>>>>
>>>>> Can you please check /var/log/ipareplica-install.log and check if
>>>>> ipa-client-install (which is run as part of ipa-replica-install) succeeded? I
>>>>> have a suspicion you hit a bug I was fixing recently.
>>>>>
>>>>> Martin
>>>> No, the client install failed:
>>>> 2013-01-29T23:24:05Z DEBUG stderr=
>>>> 2013-01-29T23:24:05Z DEBUG Restarting the web server
>>>> 2013-01-29T23:24:06Z DEBUG args=/sbin/service httpd restart
>>>> 2013-01-29T23:24:06Z DEBUG stdout=Stopping httpd:          [  OK  ]
>>>> Starting httpd:                                            [  OK  ]
>>>>
>>>> 2013-01-29T23:24:06Z DEBUG stderr=
>>>> 2013-01-29T23:24:20Z DEBUG args=/usr/sbin/ipa-client-install --on-master
>>>> --unattended --domain cliff.cloudburrito.com --server
>>>> i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com --realm
>>>> CLIFF.CLOUDBURRITO.COM
>>>> 2013-01-29T23:24:20Z DEBUG stdout=Discovery was successful!
>>>> Hostname: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com
>>>> Realm: CLIFF.CLOUDBURRITO.COM
>>>> DNS Domain: cliff.cloudburrito.com
>>>> IPA Server: i-d26b7f8b.ipa-server.us-west-1.cliff.cloudburrito.com
>>>> BaseDN: dc=cliff,dc=cloudburrito,dc=com
>>>>
>>>>
>>>> Configured /etc/sssd/sssd.conf
>>>> Installation failed. Rolling back changes.
>>>>
>>>> 2013-01-29T23:24:20Z DEBUG stderr=DNS domain 'cliff.cloudburrito.com' is
>>>> not configured for automatic KDC address lookup.
>>>> KDC address will be set to fixed value.
>>>>
>>>> Failed to add CA to the default NSS database.
>>>>
>>>> 2013-01-29T23:24:20Z DEBUG Failed to configure the client
>>>>   File "/usr/sbin/ipa-replica-install", line 496, in <module>
>>>>     main()
>>>>
>>>>   File "/usr/sbin/ipa-replica-install", line 485, in main
>>>>     raise RuntimeError("Failed to configure the client")
>>>>
>>> Getting warmer... Can you please check /var/log/ipaclient-install.log if there
>>> is a reason why it failed? The problem here is that the client removed
>>> default.conf, keytabs etc. when it uninstalled itself due to the failure.
>>>
>>> Thanks,
>>> Martin
>> Below is the last few lines of the file.
>> It looks like it's failing because sssd is already configured. This is
>> true as our servers are preconfigured for sssd to use the IPA master
>> server. If this is indeed the cause, is there any way to have it not
>> configure sssd? Or should I wipe the sssd config before attempting to
>> set up the replica?
>> Could it also be fixed so that if the client install does fail, that it
>> doesn't break the server?
>>
>> 2013-01-30T16:28:38Z DEBUG stderr=
>> 2013-01-30T16:28:38Z DEBUG Restoring client configuration files
>> 2013-01-30T16:28:38Z DEBUG args=/usr/sbin/selinuxenabled
>> 2013-01-30T16:28:38Z DEBUG stdout=
>> 2013-01-30T16:28:38Z DEBUG stderr=
>> 2013-01-30T16:28:38Z DEBUG Saving Index File to
>> '/var/lib/ipa-client/sysrestore/sysrestore.index'
>> 2013-01-30T16:28:38Z DEBUG   -> no files, removing file
>> 2013-01-30T16:28:38Z DEBUG args=/sbin/service nscd status
>> 2013-01-30T16:28:38Z DEBUG stdout=
>> 2013-01-30T16:28:38Z DEBUG stderr=nscd: unrecognized service
>>
>> 2013-01-30T16:28:38Z INFO nscd daemon is not installed, skip configuration
>> 2013-01-30T16:28:38Z DEBUG args=/sbin/service nslcd status
>> 2013-01-30T16:28:38Z DEBUG stdout=
>> 2013-01-30T16:28:38Z DEBUG stderr=nslcd: unrecognized service
>>
>> 2013-01-30T16:28:38Z INFO nslcd daemon is not installed, skip configuration
>> 2013-01-30T16:28:38Z DEBUG The original configuration of SSSD included
>> other domains than IPA-based one.
>> 2013-01-30T16:28:38Z DEBUG Original configuration file is restored,
>> restarting SSSD service.
>> 2013-01-30T16:28:38Z DEBUG args=/sbin/service sssd restart
>> 2013-01-30T16:28:38Z DEBUG stdout=Stopping sssd:           [FAILED]
>> Starting sssd:                                             [  OK  ]
>>
>> 2013-01-30T16:28:38Z DEBUG stderr=cat: /var/run/sssd.pid: No such file
>> or directory
>>
> Any what do SSSD logs say?
> I seems that restart of SSSD did not go that smoothly.

sssd started up fine, it's running right now. Looks like a race
condition, the pid file has an mtime of 16:28:38, the same second as the
"No such file or directory" error.