> On 8 May 2020, at 03:09, Graham Leggett <minf...@sharp.fm> wrote: > > On 07 May 2020, at 18:51, Graham Leggett <minf...@sharp.fm> wrote: > >> I have two servers, an older CentOS7 server running >> 389-ds-base-1.3.10.1-5.el7, and a newer CentOS8 server running >> 389-ds-base-1.4.1.3-7.module_el8.1.0+234+96aec258, and I want to set up >> multi-master-replication between them. >> >> The replication agreement for CentOS7-> CentOS8 works great, replication is >> working fine. >> >> The replication agreement for CentOS8 -> CentOS7 doesn’t work, giving the >> following strange error: >> >> [07/May/2020:18:42:59.201795217 +0200] - ERR - slapi_ldap_bind - Could not >> send bind request for id [cn=Replication Manager,cn=config] authentication >> mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 >> (Invalid function argument.), network error 0 (Unknown error, host >> “x.x.x:636”) >> >> At the core of the above message is "network error 0”, otherwise known as >> “success”.
It could be TLS min versions / max versions setting perhaps? But I think I'd want to see more detailed logging to be sure ... or even a packet capture of the handshake to see where that's failing. >> >> Does this ring a bell with anyone? > > Some googling sees me unearth this worrying thread: > https://pagure.io/389-ds-base/issue/47536 > > Quite a while back I spent an enormous amount of debugging time on an Ubuntu > version of 389ds that refused point blank to replicate. We eventually > discovered an awful bug where 389ds had been bound to two competing SSL > libraries, GnuTLS and NSS, and 389ds was passing NSS parameters (directory > paths) to GnuTLS, which was silently failing and then eating error messages. > We concluded Ubuntu was too broken to fix in any reasonable time and moved > all LDAP servers to CentOS7, which worked. > > Doing an ldd /usr/sbin/ns-slapd shows that on CentOS8 389ds is linked to both > NSS and OpenSSL, which looks worryingly like the same bug has crept into > CentOS8. In the future there will be some openssl provided crypto opts for password hashing/enc, but no sockets are activated, and the symbol names are seperate so I think this may not be the cause. > > Anyone have any details? > > Regards, > Graham > — > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
