The code looks good.
Though we have an error during lib389/tests/tls_external_test.py execution:

CRITICAL:lib389:TLS negotiation failed: {'info': "TLS error -8179:
Peer's Certificate issuer is not recognized.", 'errno': 2, 'desc': 'Connect error'}

Build tested: 389-ds-base: 1.3.6.1-15.el7

Also, we have an error with SECUREPORT_STANDALONE access, but for this, I think, we need to modify our CI, not the tests.

Yeah, SECUREPORT_STANDALONE may not be relabeled correctly with SELinux.

As for the not recognised, I can't really see why not? We provide the CA and everything to the call, so it "should just work". I'm going to need some more info to get to the bottom of this.

Can you give me the full output from py.test -s in an email perhaps @spichugi

I have reproduced this and am working on a solution :)

Funny that @mreynolds sent that roadmap mail: this is part of it. The core is that DirSrv represents two things at the same time. It's both a connection and an instance. As a result, it's flawed, because we have to make assertions about locality (local or remote) and state (online, offline). We attempt to determine SSL/StartTLS (don't get me started on how bad starttls is) based on settings in the dirsrv instance, but these are not updated refective of changes to the server. We also can not assert a relationship between a ca store from the dirsrv instance being accessible from the client. To make it worse, when we restart /start, we attempt to open a new connection, which does not expose all the options we need to actually make a working TLS connection.

I'll come up with a fix for this, but we really need to rethink this interface, because it's a mess and a bit out of hand to work on.

Another issue is that dirsrv being a derivative of SimpleLDAPObject causes a stack of pain, because when we restrart / close / open, there seem to be settings that "dont work" in the ldap library. IE once you init a conn, you can NEVER set the opt.TLS params after that point, even if you close and reopen. Again, this is due to the design of this lib, and it's hard to fix.

I think that perhaps we need to consider breaking this to three parts.

1) A connection module that opens / closes and is destroyed correctly as needed.
2) A local interaction module that does start / stop etc.
3) The "DirSrv" type, that acts a proxy to these two.

In most cases we would actually use module 1 for remote access. But for compat, because of the way we link these two, we need the proxy to control these local vs remote interaction.

The benefit would be on stop we could destroy the connection object, and on open we could recreate it, avoiding many of the pit falls of the pythonldap library's behaviour.

This resolves the issue: the core of the issue is that python-ldap fundamentally does NOT support multiple open connections with varying settings at a time.

The code looks good to me. Tests passed. Thank you, William!

commit 3a7802da1c9ef6810b18ecffa298d1e0c5ef083b
To ssh://git@pagure.io/lib389.git
f32a14b..3a7802d master -> master