[Freeipa-users] ipa-replica-manage list fail on server 2
barrykfl at gmail.com
barrykfl at gmail.com
Fri Jul 11 08:01:48 UTC 2014
should i change all server nsslapd-db-deadlock-policy: 6 in config for
problematic server only or all servers need restart?
2014-07-11 15:53 GMT+08:00 <barrykfl at gmail.com>:
> At server 2 there is a error:
>
>
> [10/Jul/2014:12:29:59 +0800] NSMMReplicationPlugin - agmt="cn=
> meToserver1.abc.com" (central:389): Replication bind with GSSAPI auth
> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure. Minor code may provide more information
> (Credentials cache file '/tmp/krb5cc_494' not found))
>
>
> 2014-07-11 10:26 GMT+08:00 <barrykfl at gmail.com>:
>
>> Yes ,
>> still get "cant contact ldap server" after upgrading both servers.
>>
>>
>> 2014-07-10 23:18 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:
>>
>>> On 07/10/2014 09:15 AM, barrykfl at gmail.com wrote:
>>>
>>> But any hint that server 2 say cant contact ldap server if type ipa
>>> command?
>>>
>>>
>>> Please keep replies on list.
>>>
>>> You still get "cant contact ldap server" after upgrading both servers?
>>>
>>> 2014/7/10 下午10:25 於 "Rich Megginson" <rmeggins at redhat.com> 寫道：
>>>
>>>> On 07/10/2014 01:14 AM, barrykfl at gmail.com wrote:
>>>>
>>>> Tried and now two version same ....but seem same situation.
>>>>
>>>> i found a related error log that server1 has account after added user
>>>> but not replicated to server2. Is it too fast on UI clicking ? as i exp
>>>> once that click very
>>>> fast twice add and edit user may cause server 2 no record.
>>>>
>>>>
>>>> [10/Jul/2014:14:20:01 +0800] NSMMReplicationPlugin - changelog
>>>> program - _cl5WriteOperationTxn: retry (49) the transaction
>>>> (csn=53be3097000000040000) failed (rc=-30994 (DB_LOCK_DEADLOCK: Locker
>>>> killed to resolve a deadlock))
>>>> [10/Jul/2014:14:20:01 +0800] NSMMReplicationPlugin - changelog program
>>>> - _cl5WriteOperationTxn: failed to write entry with csn
>>>> (53be3097000000040000); db error - -30994 DB_LOCK_DEADLOCK: Locker killed
>>>> to resolve a deadlock
>>>> [10/Jul/2014:14:20:01 +0800] NSMMReplicationPlugin -
>>>> write_changelog_and_ruv: can't add a change for
>>>> uid=xuehuimei,cn=users,cn=accounts,dc=abc,dc=com (uniqid:
>>>> 1300de84-07fa11e4-b3ddf885-593f3a7a, optype: 16) to changelog csn
>>>> 53be3097000000040000
>>>> [10/Jul/2014:14:56:51 +0800] NSMMReplicationPlugin - changelog program
>>>> - _cl5WriteOperationTxn: retry (49) the transaction
>>>> (csn=53be3939000000040000) failed (rc=-30994 (DB_LOCK_DEADLOCK: Locker
>>>> killed to resolve a deadlock))
>>>> [10/Jul/2014:14:56:51 +0800] NSMMReplicationPlugin - changelog program
>>>> - _cl5WriteOperationTxn: failed to write entry with csn
>>>> (53be3939000000040000); db error - -30994 DB_LOCK_DEADLOCK: Locker killed
>>>> to resolve a deadlock
>>>> [10/Jul/2014:14:56:51 +0800] NSMMReplicationPlugin -
>>>> write_changelog_and_ruv: can't add a change for
>>>> uid=websubcon04,cn=users,cn=accounts,dc=abc,dc=com (uniqid:
>>>> 3e39fc81-07ff11e4-b3ddf885-593f3a7a, optype: 16) to changelog csn
>>>> 53be3939000000040000
>>>>
>>>>
>>>> This looks like https://fedorahosted.org/389/ticket/47409 and
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=979169
>>>>
>>>> Cause: Under certain conditions, with a mix of concurrent search and
>>>> update and outgoing replication operations, there will be deadlocks in the
>>>> changelog db, leading to error messages like this:
>>>> NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn:
>>>> failed to write entry with csn (XXXXXXX); db error - -30994
>>>> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
>>>> This is caused by a deadlock between the changelog readers, writers,
>>>> and main database writers.
>>>>
>>>> Consequence: Update operations will fail with the above error message
>>>> in the directory server errors log.
>>>>
>>>> Fix: A new configuration parameter is introduced:
>>>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>>>> nsslapd-db-deadlock-policy: 9
>>>>
>>>> With the default policy 9 (DB_LOCK_YOUNGEST), the last locker gets
>>>> killed when there is a deadlock. In the case that this is the changelog
>>>> writer, the write will fail, and the entire update will fail.
>>>>
>>>> Users who frequently see the above errors in the errors log are advised
>>>> to change this setting to 6 (DB_LOCK_MINWRITE) will which instead kill the
>>>> locker that has the fewest write locks (that is, the changelog reader).
>>>> The changelog reader code has been changed to handle this deadlock
>>>> condition and retry. The setting can be changed like this:
>>>>
>>>> ldapmodify -x -D "cn=directory manager" -W <<EOF
>>>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>>>> changetype: modify
>>>> replace: nsslapd-db-deadlock-policy
>>>> nsslapd-db-deadlock-policy: 6
>>>> EOF
>>>>
>>>> You may ask why the default is not changed to 6. The answer is that
>>>> the setting will apply to _all_ threads, so that changing this setting
>>>> could cause regular search requests to fail, if the directory server is
>>>> under a heavy update load. In our testing, we did not see this happen, but
>>>> we cannot guarantee that changing this value to 6 will not impact regular
>>>> search requests.
>>>>
>>>> Result: After changing nsslapd-db-deadlock-policy to 6, updates will
>>>> succeed and no longer cause errors like the above.
>>>>
>>>>
>>>>
>>>>
>>>> 2014-07-10 10:40 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:
>>>>
>>>>> On 07/09/2014 08:36 PM, barrykfl at gmail.com wrote:
>>>>>
>>>>> Hi :
>>>>>
>>>>> What is the procedure for this minor update ?
>>>>>
>>>>> just yum update ipa-server after stop the server?
>>>>>
>>>>>
>>>>> If you just want to upgrade only the LDAP server, which is the
>>>>> component that I for sure know is out of date, then yum update 389-ds-base.
>>>>>
>>>>> Or just "yum update" - in general I don't like running
>>>>> "franken-systems" which have a mix of up-to-date and out of date packages.
>>>>> Note that "IPA server" is composed of several packages.
>>>>>
>>>>> You do not need to stop the server. yum/rpm upgrade will restart as
>>>>> needed. If you want to make sure, do ipactl restart after upgrade.
>>>>>
>>>>>
>>>>> and effect of the exsitn ldap?
>>>>>
>>>>>
>>>>> Not sure what you mean. Upgrade should not touch any config or data.
>>>>>
>>>>>
>>>>>
>>>>> As the server 2 is master of replica also , so need refo ipa-replica
>>>>> install ?
>>>>>
>>>>>
>>>>> No, you just need to perform the same upgrade procedure.
>>>>>
>>>>>
>>>>>
>>>>> barry
>>>>>
>>>>>
>>>>> 2014-07-09 22:20 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:
>>>>>
>>>>>> On 07/08/2014 09:02 PM, barrykfl at gmail.com wrote:
>>>>>>
>>>>>> Some error i found :
>>>>>>
>>>>>>
>>>>>> server1.abc.com:636 (/etc/dirsrv/slapd-abc-COM)
>>>>>>
>>>>>> [29/Jun/2014:02:00:56 +0800] - 389-Directory/1.2.11.25
>>>>>> B2013.325.1951 starting up
>>>>>> [29/Jun/2014:02:00:56 +0800] attrcrypt - attrcrypt_unwrap_key: failed
>>>>>> to unwrap key for cipher AES
>>>>>> [29/Jun/2014:02:00:56 +0800] attrcrypt - attrcrypt_cipher_init:
>>>>>> symmetric key failed to unwrap with the private key; Cert might have been
>>>>>> renewed since the key is wrapped. To recover the encrypted contents, keep
>>>>>> the wrapped symmetric key value.
>>>>>> [29/Jun/2014:02:00:56 +0800] attrcrypt - attrcrypt_unwrap_key: failed
>>>>>> to unwrap key for cipher 3DES
>>>>>> [29/Jun/2014:02:00:56 +0800] attrcrypt - attrcrypt_cipher_init:
>>>>>> symmetric key failed to unwrap with the private key; Cert might have been
>>>>>> renewed since the key is wrapped. To recover the encrypted contents, keep
>>>>>> the wrapped symmetric key value.
>>>>>> [29/Jun/2014:02:00:56 +0800] attrcrypt - All prepared ciphers are not
>>>>>> available. Please disable attribute encryption.
>>>>>> [29/Jun/2014:02:00:56 +0800] schema-compat-plugin - warning: no
>>>>>> entries set up under cn=computers, cn=compat,dc=abc,dc=com
>>>>>> [29/Jun/2014:02:00:57 +0800] schema-compat-plugin - warning: no
>>>>>> entries set up under cn=ng, cn=compat,dc=abc,dc=com
>>>>>> [29/Jun/2014:02:00:57 +0800] schema-compat-plugin - warning: no
>>>>>> entries set up under ou=sudoers,dc=abc,dc=com
>>>>>> [29/Jun/2014:02:00:57 +0800] - Skipping CoS Definition cn=Password
>>>>>> Policy,cn=accounts,dc=abc,dc=com--no CoS Templates found, which should be
>>>>>> added before the CoS Definition.
>>>>>> [29/Jun/2014:02:00:57 +0800] set_krb5_creds - Could not get initial
>>>>>> credentials for principal [ldap/server1.abc.com at abc.COM] in keytab [
>>>>>> FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
>>>>>> requested realm)
>>>>>> [29/Jun/2014:02:00:58 +0800] - Skipping CoS Definition cn=Password
>>>>>> Policy,cn=accounts,dc=abc,dc=com--no CoS Templates found, which should be
>>>>>> added before the CoS Definition.
>>>>>> [29/Jun/2014:02:00:58 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information
>>>>>> (Credentials cache file '/tmp/krb5cc_492' not found)) errno 0 (Success)
>>>>>> [29/Jun/2014:02:00:58 +0800] slapi_ldap_bind - Error: could not
>>>>>> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
>>>>>> [29/Jun/2014:02:00:58 +0800] NSMMReplicationPlugin - agmt="cn=
>>>>>> meToserver2.abc.com" (server2:389): Replication bind with GSSAPI
>>>>>> auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI
>>>>>> Error: Unspecified GSS failure. Minor code may provide more information
>>>>>> (Credentials cache file '/tmp/krb5cc_492' not found))
>>>>>> [29/Jun/2014:02:00:58 +0800] - slapd started. Listening on All
>>>>>> Interfaces port 389 for LDAP requests
>>>>>> [29/Jun/2014:02:00:58 +0800] - Listening on All Interfaces port 636
>>>>>> for LDAPS requests
>>>>>>
>>>>>>
>>>>>> 389-Directory/1.2.11.15 B2013.240.174
>>>>>> server2.abc.com:636 (/etc/dirsrv/slapd-abc-COM)
>>>>>>
>>>>>> [30/Jun/2014:12:51:31 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information (Ticket
>>>>>> expired)) errno 0 (Success)
>>>>>> [30/Jun/2014:12:51:31 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information (Ticket
>>>>>> expired)) errno 0 (Success)
>>>>>> [30/Jun/2014:12:51:31 +0800] slapi_ldap_bind - Error: could not
>>>>>> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
>>>>>> [30/Jun/2014:12:51:31 +0800] NSMMReplicationPlugin - agmt="cn=
>>>>>> meToserver1.abc.com" (server1:389): Replication bind with GSSAPI
>>>>>> auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI
>>>>>> Error: Unspecified GSS failure. Minor code may provide more information
>>>>>> (Ticket expired))
>>>>>> [30/Jun/2014:12:51:34 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information (Ticket
>>>>>> expired)) errno 0 (Success)
>>>>>> [30/Jun/2014:12:51:35 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information (Ticket
>>>>>> expired)) errno 0 (Success)
>>>>>> [30/Jun/2014:12:51:35 +0800] slapi_ldap_bind - Error: could not
>>>>>> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
>>>>>> [30/Jun/2014:12:51:40 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information (Ticket
>>>>>> expired)) errno 0 (Success)
>>>>>> [30/Jun/2014:12:51:40 +0800] slapd_ldap_sasl_interactive_bind -
>>>>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP
>>>>>> error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>> Unspecified GSS failure. Minor code may provide more information (Ticket
>>>>>> expired)) errno 0 (Success)
>>>>>> [30/Jun/2014:12:51:40 +0800] slapi_ldap_bind - Error: could not
>>>>>> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
>>>>>> [30/Jun/2014:12:51:52 +0800] NSMMReplicationPlugin - agmt="cn=
>>>>>> meToserver1.abc.com" (server1:389): Replication bind with GSSAPI
>>>>>> auth resumed
>>>>>>
>>>>>>
>>>>>> You are using an older version of 389. The version on server2 is
>>>>>> older than the version on server1. Can you upgrade and see if that fixes
>>>>>> your problems? Even if it doesn't fix your problems, it will be much
>>>>>> easier for us to support.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-07-09 10:55 GMT+08:00 <barrykfl at gmail.com>:
>>>>>>
>>>>>>> FYI..
>>>>>>> 160: [04/Jul/2014:12:35:30 +0800] conn=936207 fd=73 slot=73
>>>>>>> connection from 192.168.156.89 to 192.168.156.89
>>>>>>> 163: [04/Jul/2014:12:35:30 +0800] conn=936207 op=-1 fd=73 closed - B1
>>>>>>>
>>>>>>> There is not abt binding but i unsure how to fix ..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2014-07-09 2:01 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:
>>>>>>>
>>>>>>> On 07/08/2014 02:16 AM, barrykfl at gmail.com wrote:
>>>>>>>>
>>>>>>>> Resent as size limit.
>>>>>>>>
>>>>>>>>
>>>>>>>> Here u are server1 's access log seem one side broken
>>>>>>>>
>>>>>>>> the problem is how to make it replicate again.
>>>>>>>>
>>>>>>>> At server 1
>>>>>>>>
>>>>>>>> it is ok master server1 master server2
>>>>>>>>
>>>>>>>>
>>>>>>>> Another side server 2 contains 2 ip replication.
>>>>>>>>
>>>>>>>> ipa-replica-manage list shown Can't contact LDAP server
>>>>>>>>
>>>>>>>> I dont know why but the prolematic server is sever 2 not server 1
>>>>>>>>
>>>>>>>> log of server2
>>>>>>>> [08/Jul/2014:16:02:40 +0800] conn=3299731 fd=69 slot=69 connection
>>>>>>>> from 192.168.15.89 (server1) to 192.168.15.88(server2)
>>>>>>>> [08/Jul/2014:16:02:40 +0800] conn=3299731 op=-1 fd=69 closed - B1
>>>>>>>> [08/Jul/2014:16:02:40 +0800] conn=3299732 fd=69 slot=69 connection
>>>>>>>> from 192.168.15.89 to 192.168.15.88
>>>>>>>> [08/Jul/2014:16:02:40 +0800] conn=3299732 op=-1 fd=69 closed - B1
>>>>>>>> [08/Jul/2014:16:02:41 +0800] conn=3299733 fd=69 slot=69 connection
>>>>>>>> from 192.168.15.89 to 192.168.15.88
>>>>>>>> [08/Jul/2014:16:02:41 +0800] conn=3299733 op=-1 fd=69 closed - B1
>>>>>>>>
>>>>>>>>
>>>>>>>> You never answered my question below. "Are you sure that this
>>>>>>>> connection is a replication session? Can you post all of the operations
>>>>>>>> from the access log from conn=936207?"
>>>>>>>>
>>>>>>>> In the future, please avoid spamming the list with large log
>>>>>>>> files. In general, it's better to provide excerpts from the log files
>>>>>>>> showing the problem, paste them to fpaste.org, and post the link
>>>>>>>> to the mailing list. If for some reason you need to post a large file,
>>>>>>>> please use a file sharing service and post the link to the file.
>>>>>>>>
>>>>>>>> Can you take a look at your errors log from server 1 and server 2
>>>>>>>> and see if there are any relevant errors?
>>>>>>>>
>>>>>>>> If I had to guess, I would say that there is some sort of network
>>>>>>>> error between server 1 and server 2 that causes the excessive closed - B1.
>>>>>>>> Perhaps there will be more information in the errors log.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-07-07 22:21 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:
>>>>>>>>
>>>>>>>>> On 07/04/2014 03:28 AM, barrykfl at gmail.com wrote:
>>>>>>>>>
>>>>>>>>> FOUND something strange that server 1 replicate to itself rather
>>>>>>>>> than server2
>>>>>>>>>
>>>>>>>>> Server1 access log > Wrong
>>>>>>>>> [04/Jul/2014:12:35:30 +0800] conn=936207 fd=73 slot=73 connection
>>>>>>>>> from 192.168.15.89( server1 ) to 192.168.15.89 (server1)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Are you sure that this connection is a replication session? Can
>>>>>>>>> you post all of the operations from the access log from conn=936207?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Server 2 access log > OK
>>>>>>>>> [04/Jul/2014:12:35:30 +0800] conn=936208 fd=74 slot=74 connection
>>>>>>>>> from 192.168.15.89(server2) to 192.168.15.88 (server2)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-07-04 9:25 GMT+08:00 <barrykfl at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Just sure now one side flow is broken, if u update server1 , it
>>>>>>>>>> 100% work server2 will upgrade.
>>>>>>>>>> but if u update server2 there is chance non-syn e.g it create
>>>>>>>>>> username in server1 with posfix grp >ok
>>>>>>>>>> but in server2 it only created posfix grp but no username
>>>>>>>>>> /attribute it occur serveral times. I have to use command line grp del
>>>>>>>>>> ...etc. to force del them and recreate them.,.
>>>>>>>>>>
>>>>>>>>>> Result below:
>>>>>>>>>>
>>>>>>>>>> server2.abc.com: replica
>>>>>>>>>> last init status: None
>>>>>>>>>> last init ended: None
>>>>>>>>>> last update status: 0 Replica acquired successfully:
>>>>>>>>>> Incremental update succeeded
>>>>>>>>>> last update ended: 2014-07-04 00:33:18+00:00
>>>>>>>>>>
>>>>>>>>>> Directory Manager password:
>>>>>>>>>>
>>>>>>>>>> server1.abc.com: replica
>>>>>>>>>> last init status: 0 Total update succeeded
>>>>>>>>>> last init ended: 2014-06-20 10:07:02+00:00
>>>>>>>>>> last update status: 0 Replica acquired successfully:
>>>>>>>>>> Incremental update succeeded
>>>>>>>>>> last update ended: 2014-07-04 01:14:19+00:00
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [root@(LIVE)server2 ~]$ ipactl status
>>>>>>>>>> Directory Service: RUNNING
>>>>>>>>>> KDC Service: RUNNING
>>>>>>>>>> KPASSWD Service: RUNNING
>>>>>>>>>> MEMCACHE Service: RUNNING
>>>>>>>>>> HTTP Service: RUNNING
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2014-07-04 1:34 GMT+08:00 Rob Crittenden <rcritten at redhat.com>:
>>>>>>>>>>
>>>>>>>>>> barrykfl at gmail.com wrote:
>>>>>>>>>>> > Yes they are running. Server 1 can syn to server2 but error at
>>>>>>>>>>> server 2
>>>>>>>>>>> > like this.
>>>>>>>>>>>
>>>>>>>>>>> How do you know server 1 is syncing with server 2?
>>>>>>>>>>>
>>>>>>>>>>> On server 1 I'd run:
>>>>>>>>>>>
>>>>>>>>>>> ipa-replica-manage list -v `hostname`
>>>>>>>>>>>
>>>>>>>>>>> This will show the replication status.
>>>>>>>>>>>
>>>>>>>>>>> And what does ipactl status show on server 2?
>>>>>>>>>>>
>>>>>>>>>>> rob
>>>>>>>>>>>
>>>>>>>>>>> >
>>>>>>>>>>> > 2014/7/3 下午10:14 於 "Rob Crittenden" <rcritten at redhat.com
>>>>>>>>>>> > <mailto:rcritten at redhat.com>> 寫道：
>>>>>>>>>>> >
>>>>>>>>>>> > Please keep relies on the list.
>>>>>>>>>>> >
>>>>>>>>>>> > barrykfl at gmail.com <mailto:barrykfl at gmail.com> wrote:
>>>>>>>>>>> > > I saw the error beloe and errpr log is it related ?
>>>>>>>>>>> > >
>>>>>>>>>>> > > 29/Jun/2014:02:00:58 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind - Error:
>>>>>>>>>>> > > could not perform interactive bind for id [] mech
>>>>>>>>>>> [GSSAPI]: LDAP error
>>>>>>>>>>> > > -2 (Local error) (SASL(-1): generic failure: GSSAPI
>>>>>>>>>>> Error: Unspecified
>>>>>>>>>>> > > GSS failure. Minor code may provide more information
>>>>>>>>>>> (Credentials
>>>>>>>>>>> > cache
>>>>>>>>>>> > > file '/tmp/krb5cc_492' not found)) errno 0 (Success)
>>>>>>>>>>> > > [29/Jun/2014:02:00:58 +0800] slapi_ldap_bind - Error:
>>>>>>>>>>> could not
>>>>>>>>>>> > perform
>>>>>>>>>>> > > interactive bind for id [] mech [GSSAPI]: error -2
>>>>>>>>>>> (Local error)
>>>>>>>>>>> >
>>>>>>>>>>> > I believe this is fairly normal on a new startup. It has
>>>>>>>>>>> to start
>>>>>>>>>>> > somewhere. The expired ticket errors below are unexpected
>>>>>>>>>>> since there
>>>>>>>>>>> > are so many of them. Is your KDC running?
>>>>>>>>>>> >
>>>>>>>>>>> > ipactl status
>>>>>>>>>>> >
>>>>>>>>>>> > rob
>>>>>>>>>>> >
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> > > 2014-07-02 14:15 GMT+08:00 <barrykfl at gmail.com
>>>>>>>>>>> > <mailto:barrykfl at gmail.com> <mailto:barrykfl at gmail.com
>>>>>>>>>>> > <mailto:barrykfl at gmail.com>>>:
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> > > this is the error log i found at 2.abc.com <
>>>>>>>>>>> http://2.abc.com>
>>>>>>>>>>> > <http://2.abc.com>
>>>>>>>>>>> > >
>>>>>>>>>>> > > [30/Jun/2014:12:51:31 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind -
>>>>>>>>>>> > > Error: could not perform interactive bind for id []
>>>>>>>>>>> mech [GSSAPI]:
>>>>>>>>>>> > > LDAP error -2 (Local error) (SASL(-1): generic
>>>>>>>>>>> failure: GSSAPI
>>>>>>>>>>> > > Error: Unspecified GSS failure. Minor code may
>>>>>>>>>>> provide more
>>>>>>>>>>> > > information (Ticket expired)) errno 0 (Success)
>>>>>>>>>>> > > [30/Jun/2014:12:51:31 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind -
>>>>>>>>>>> > > Error: could not perform interactive bind for id []
>>>>>>>>>>> mech [GSSAPI]:
>>>>>>>>>>> > > LDAP error -2 (Local error) (SASL(-1): generic
>>>>>>>>>>> failure: GSSAPI
>>>>>>>>>>> > > Error: Unspecified GSS failure. Minor code may
>>>>>>>>>>> provide more
>>>>>>>>>>> > > information (Ticket expired)) errno 0 (Success)
>>>>>>>>>>> > > [30/Jun/2014:12:51:31 +0800] slapi_ldap_bind -
>>>>>>>>>>> Error: could not
>>>>>>>>>>> > > perform interactive bind for id [] mech [GSSAPI]:
>>>>>>>>>>> error -2
>>>>>>>>>>> > (Local error)
>>>>>>>>>>> > > [30/Jun/2014:12:51:31 +0800] NSMMReplicationPlugin -
>>>>>>>>>>> > > agmt="cn=meTo1.abc.com <http://meTo1.abc.com>
>>>>>>>>>>> > <http://meTo1.abc.com>" (central:389):
>>>>>>>>>>> > > Replication bind with GSSAPI auth failed: LDAP error
>>>>>>>>>>> -2 (Local
>>>>>>>>>>> > > error) (SASL(-1): generic failure: GSSAPI Error:
>>>>>>>>>>> Unspecified GSS
>>>>>>>>>>> > > failure. Minor code may provide more information
>>>>>>>>>>> (Ticket
>>>>>>>>>>> > expired))
>>>>>>>>>>> > > [30/Jun/2014:12:51:34 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind -
>>>>>>>>>>> > > Error: could not perform interactive bind for id []
>>>>>>>>>>> mech [GSSAPI]:
>>>>>>>>>>> > > LDAP error -2 (Local error) (SASL(-1): generic
>>>>>>>>>>> failure: GSSAPI
>>>>>>>>>>> > > Error: Unspecified GSS failure. Minor code may
>>>>>>>>>>> provide more
>>>>>>>>>>> > > information (Ticket expired)) errno 0 (Success)
>>>>>>>>>>> > > [30/Jun/2014:12:51:35 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind -
>>>>>>>>>>> > > Error: could not perform interactive bind for id []
>>>>>>>>>>> mech [GSSAPI]:
>>>>>>>>>>> > > LDAP error -2 (Local error) (SASL(-1): generic
>>>>>>>>>>> failure: GSSAPI
>>>>>>>>>>> > > Error: Unspecified GSS failure. Minor code may
>>>>>>>>>>> provide more
>>>>>>>>>>> > > information (Ticket expired)) errno 0 (Success)
>>>>>>>>>>> > > [30/Jun/2014:12:51:35 +0800] slapi_ldap_bind -
>>>>>>>>>>> Error: could not
>>>>>>>>>>> > > perform interactive bind for id [] mech [GSSAPI]:
>>>>>>>>>>> error -2
>>>>>>>>>>> > (Local error)
>>>>>>>>>>> > > [30/Jun/2014:12:51:40 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind -
>>>>>>>>>>> > > Error: could not perform interactive bind for id []
>>>>>>>>>>> mech [GSSAPI]:
>>>>>>>>>>> > > LDAP error -2 (Local error) (SASL(-1): generic
>>>>>>>>>>> failure: GSSAPI
>>>>>>>>>>> > > Error: Unspecified GSS failure. Minor code may
>>>>>>>>>>> provide more
>>>>>>>>>>> > > information (Ticket expired)) errno 0 (Success)
>>>>>>>>>>> > > [30/Jun/2014:12:51:40 +0800]
>>>>>>>>>>> slapd_ldap_sasl_interactive_bind -
>>>>>>>>>>> > > Error: could not perform interactive bind for id []
>>>>>>>>>>> mech [GSSAPI]:
>>>>>>>>>>> > > LDAP error -2 (Local error) (SASL(-1): generic
>>>>>>>>>>> failure: GSSAPI
>>>>>>>>>>> > > Error: Unspecified GSS failure. Minor code may
>>>>>>>>>>> provide more
>>>>>>>>>>> > > information (Ticket expired)) errno 0 (Success)
>>>>>>>>>>> > > [30/Jun/2014:12:51:40 +0800] slapi_ldap_bind -
>>>>>>>>>>> Error: could not
>>>>>>>>>>> > > perform interactive bind for id [] mech [GSSAPI]:
>>>>>>>>>>> error -2
>>>>>>>>>>> > (Local error)
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> > > 2014-07-02 12:32 GMT+08:00 <barrykfl at gmail.com
>>>>>>>>>>> > <mailto:barrykfl at gmail.com>
>>>>>>>>>>> > > <mailto:barrykfl at gmail.com <mailto:
>>>>>>>>>>> barrykfl at gmail.com>>>:
>>>>>>>>>>> > >
>>>>>>>>>>> > > yes on node 1 it is happening only node2 fail
>>>>>>>>>>> connect
>>>>>>>>>>> > >
>>>>>>>>>>> > > ipa-replica-manage list 2.abc.com <
>>>>>>>>>>> http://2.abc.com>
>>>>>>>>>>> > <http://2.abc.com>
>>>>>>>>>>> > > Directory Manager password:
>>>>>>>>>>> > >
>>>>>>>>>>> > > 1.abc.com <http://1.abc.com> <http://1.abc.com>:
>>>>>>>>>>> replica
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>> > > 2014-06-30 20:59 GMT+08:00 Rob Crittenden
>>>>>>>>>>> > <rcritten at redhat.com <mailto:rcritten at redhat.com>
>>>>>>>>>>> > > <mailto:rcritten at redhat.com <mailto:
>>>>>>>>>>> rcritten at redhat.com>>>:
>>>>>>>>>>> > >
>>>>>>>>>>> > > Barry wrote:
>>>>>>>>>>> > > > Hi:
>>>>>>>>>>> > >
>>>>>>>>>>>
>>>>>>>>>> ...
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140711/695fc1c0/attachment.htm>
More information about the Freeipa-users
mailing list