[Freeipa-users] Failed to setup replica, slapi_ldap_bind fails

Mon Feb 15 10:14:08 UTC 2016

I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap

Here's complete debug log of replica install:
http://pastebin.com/38zi5MWd

Now I noticed following, don't know if it can directly relate to this issue:

ipa         : DEBUG    stderr=ldap_initialize( ldap://idm02.tcpcloud.eu:389/??base )
ldap_modify: Server is unwilling to perform (53)

ipa         : CRITICAL Failed to load indices.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpIV39iM'' returned non-zero exit status 53

On 2016/02/15 11:06, Ludwig Krispenz wrote:
> 
> On 02/12/2016 06:22 PM, Filip Pytloun wrote:
> >Following is in /etc/ldap/ldap.conf on both servers (only URI differs):
> what is your OS, do you also have a /etc/openldap/ldap.conf
> 
> ldapsearch and the replication connection shoudl use the same openldap
> libraries and so it is strange that -ZZ works and indside ds doesn't.
> 
> At what point did your replica install fail, is there any hint in the
> replica install log ?
> >
> >TLS_CACERT /etc/ipa/ca.crt
> >TLS_REQCERT allow
> >URI ldaps://idm02.tcpcloud.eu
> >BASE dc=tcpcloud,dc=eu
> >
> >As ldapsearch is passing just fine on both nodes, I don't suppose
> >ldap.conf is wrong.
> >I also tried to set TLS_REQCERT to allow just to be sure (in case that
> >bad cert is provided).
> >
> >On 2016/02/12 16:57, Ludwig Krispenz wrote:
> >>On 02/12/2016 03:35 PM, Filip Pytloun wrote:
> >>>It's the same as for idm01:
> >>>
> >>>[12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code))
> >>>[12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
> >>you can get this connect error if the client side cannot verify the cert the
> >>server sends, could you check what you have in f
> >>
> >>>In access logs I can't read much interesting, just that TLS connection happened from idm01:
> >>>
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM
> >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1
> >>>[12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192
> >>>[12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
> >>>[12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0
> >>>[12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM
> >>>[12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1
> >>>
> >>>On 2016/02/12 15:22, Ludwig Krispenz wrote:
> >>>>On 02/12/2016 03:06 PM, Filip Pytloun wrote:
> >>>>>Hello,
> >>>>>
> >>>>>even when enabling replication logging, I get nothing useful in logs:
> >>>>>
> >>>>>[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext
> >>>>>[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config,  passwd = {AES-some_encrypted_password
> >>>>>[12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
> >>>>>[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code))
> >>>>>[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer
> >>>>what is in the access and error logs of idm02 for this time ?
> >>>>>But I can bind just fine manually:
> >>>>>
> >>>>>ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ
> >>>>>
> >>>>>I am starting to be clueless, nobody has an idea what could be wrong?
> >>>>>
> >>>>>- DNS including PTR records are set up fine
> >>>>>- /etc/hosts is setup fine
> >>>>>- conncheck passes fine between nodes
> >>>>>- I can bind manually just fine
> >>>>>
> >>>>>On 2016/02/08 18:05, Filip Pytloun wrote:
> >>>>>>Hello,
> >>>>>>
> >>>>>>I have a weird issue setting up FreeIPA replica. Conncheck passes fine
> >>>>>>but at the end of ipa-replica-install I always get following error:
> >>>>>>
> >>>>>>slapi_ldap_bind -Error: could not send startTLS request: error -11
> >>>>>>(Connect error) errno 0 (Success)
> >>>>>>
> >>>>>>on both master and replica without any further explanation in logs.
> >>>>>>
> >>>>>>/etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA
> >>>>>>certificate is installed in system CA bundle so TLS should work just
> >>>>>>fine.
> >>>>>>
> >>>>>>Also I can manually connect just fine from replica to master and back so
> >>>>>>it's not a network or LDAP client issue.
> >>>>>>
> >>>>>>Replica agreement looks like this: http://pastebin.com/FT3p3KUk
> >>>>>>
> >>>>>>freeipa-server 4.1.4
> >>>>>>389-ds 1.3.4.5
> >>>>>>
> >>>>>>Has anyone idea where to look at?
> >>>>>>
> >>>>>>Filip
> >>>>>
> >>>>-- 
> >>>>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
> >>>
> >>-- 
> >>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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160215/01364618/attachment.sig>