[Freeipa-users] ipa-replica-manage list fail on server 2

barrykfl at gmail.com barrykfl at gmail.com
Mon Jul 14 23:58:31 UTC 2014


kinit work , can input password

any ipa command fail even ipa replica-manage status command >>"cant contact
ldap server"


2014-07-15 0:03 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:

>  On 07/13/2014 08:51 PM, barrykfl at gmail.com wrote:
>
>  Hi:
>
>  Only for the servers that are getting the "DB_LOCK_DEADLOCK: Locker
> killed to resolve a deadlock" message in the errors log.
>
> > need restart ipactl service after modifcation?
>
> But this does not explain the "cant contact ldap server" errors.
>
> Which ipa commands give the "cant contact ldap server" errors?
>
>  > server2.abc.com  and command related ipa shown can't contact ldap sver
> , log shown before.
>
>
> Does this mean that
> ipa user-find
> on server2.abc.com gives a "cant contact ldap server" error?
>
> Or is it only the ipa replica-manage status command that gives this error?
>
> If it is the former, does ldapsearch work?  Does kinit work?
>
>
>
> 2014-07-11 21:55 GMT+08:00 Rich Megginson <rmeggins at redhat.com>:
>
>>  On 07/11/2014 01:53 AM, barrykfl at gmail.com wrote:
>>
>>  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))
>>
>>
>> This is usually a transient error that should go away.
>>
>>
>>
>> 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/20140715/ba481845/attachment.htm>


More information about the Freeipa-users mailing list