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

Jakub Hrozek jhrozek at redhat.com
Wed Jan 30 18:13:46 UTC 2013 

On Wed, Jan 30, 2013 at 12:02:30PM -0500, freeipa at stormcloud9.net wrote:
> 
> 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.

There was an error fixed in 1.9 (and hence RHEL-6.4) where the SSSD init
scripts would report success and the sssd would write pidfile before all
the subprocesses that actually talk to the remote servers were up.

Starting the SSSD so that it's in a full functional state can take up
toa couple of seconds. In 6.4 you should see [OK] after a delay when the
SSSD is starting up.

More information about the Freeipa-users mailing list