[Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6 upgrade
Will Sheldon
mail at willsheldon.com
Tue Nov 18 18:44:53 UTC 2014
No, not resolved yet I did test with GSSAPI (-Y) and like you it worked. :(
Will Sheldon
On November 18, 2014 at 8:37:10 AM, dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) wrote:
Hi,
On Fri, 7 Nov 2014, Dmitri Pal wrote:
> On 11/07/2014 01:24 AM, Will Sheldon wrote:
>> On November 6, 2014 at 10:07:54 PM, Dmitri Pal (dpal at redhat.com
>> <mailto:dpal at redhat.com>) wrote:
>>> On 11/07/2014 12:18 AM, Will Sheldon wrote:
>>>>
>>>> On the whole we are loving FreeIPA, Many thanks and much respect to
>>>> all involved, we’ve had a great 12-18 months hassle free use out of
>>>> it - it is a fantastically stable trouble free solution… however now
>>>> we’ve run into a small issue we (as mere mortals) are finding it hard
>>>> to resolve :-/
>>>>
>>>> We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything
>>>> seems to go well, but one server is behaving oddly. It’s likely not
>>>> an IPA issue, it also reset it’s hostname somehow after the upgrade
>>>> (it’s an image in an openstack environment)
>>>>
>>>> If anyone has any pointers as to how to debug I’d be hugely
>>>> appreciative :)
>>>>
>>>> Two servers, server1.domain.com and server2.domain.com
>>>>
>>>> Server1 can’t push data to server2, there are updates and new records
>>>> on server1 that do not exist on server2.
>>>>
>>>>
>>>> from the logs on server1:
>>>>
>>>> [07/Nov/2014:01:33:42 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to send
>>>> endReplication extended operation (Can't contact LDAP server)
>>>> [07/Nov/2014:01:33:47 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=meToserver2.domain.com" (server2:389): Replication bind with
>>>> GSSAPI auth resumed
>>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=meToserver2.domain.com" (server2:389): Warning: unable to
>>>> replicate schema: rc=2
>>>> [07/Nov/2014:01:33:48 +0000] NSMMReplicationPlugin -
>>>> agmt="cn=meToserver2.domain.com" (server2:389): Consumer failed to replay
>>>> change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will
>>>> retry later.
>>>
>>> Try to see
>>> a) Server 1 properly resolves server 2
>>> b) You can connect from server 1 to server 2 using ldapsearch
>>> c) your firewall has proper ports open
>>> d) dirserver on server 2 is actually running
>>
>> All seems working:
>>
>> [root at server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b ''
>> namingContexts
>
> Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y
> switch?
is this resolved? I observe it on my systems, too. Exact same symptoms.
ldapsearch with "-Y GSSAPI" works.
> Did you find anything in the server2 logs?
On my "server2", I see "sasl_io_recv failed to decode packet for
connection #".
Could there be something wrong with default buffer sizes as described in
https://bugzilla.redhat.com/show_bug.cgi?id=953653
I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my
database is rather small: ~30 users, <10 hosts and services.
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <> with scope baseObject
>> # filter: (objectclass=*)
>> # requesting: namingContexts
>> #
>>
>> #
>> dn:
>> namingContexts: dc=domain,dc=com
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>> [root at server1 ~]#
>>
>> And:
>>
>> [root at server2 ~]# /etc/init.d/dirsrv status
>> dirsrv DOMAIN-COM (pid 1009) is running...
>> dirsrv PKI-IPA (pid 1083) is running...
>> [root at server2 ~]#
>>
>>>
>>> Check logs on server 2 to see whether it actually sees an attempt to
>>> connect, I suspect not, so it is most likely a DNS/FW issue or dir server
>>> is not running on 2.
>>>>
>>>>
>>>> and the servers:
>>>>
>>>> [root at server1 ~]# ipa-replica-manage list -v `hostname`
>>>> Directory Manager password:
>>>>
>>>> server2.domain.com: replica
>>>> last init status: None
>>>> last init ended: None
>>>> last update status: 0 Replica acquired successfully: Incremental update
>>>> started
>>>> last update ended: 2014-11-07 01:35:58+00:00
>>>> [root at server1 ~]#
>>>>
>>>>
>>>>
>>>> [root at server2 ~]# ipa-replica-manage list -v `hostname`
>>>> Directory Manager password:
>>>>
>>>> server1.domain.com: replica
>>>> last init status: None
>>>> last init ended: None
>>>> last update status: 0 Replica acquired successfully: Incremental update
>>>> succeeded
>>>> last update ended: 2014-11-07 01:35:43+00:00
>>>> [root at server2 ~]#
Mit freundlichen Gruessen/With best regards,
--Daniel.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141118/dbf5614b/attachment.htm>
More information about the Freeipa-users
mailing list