Hi Maciej,
thanks for answer.
Am Mittwoch, den 31.03.2021, 09:28 +0200 schrieb Maciej Delmanowski:
On mar 31, Jan Kowalsky wrote:
> since my first test with the debops_service_slapd role and an slapd
> server worked at a first glance I now run into an error:
>
> slapd server is up and running and i can connect with ssl and the
> cn=admin user via ldapsearch.
You tested this on the remote host itself? The 'pki' role ensures
that the
yes, the ldapsearch command I tested on the remote host.
DebOps internal CA is trusted, but hosts outside of the DebOps
control, like
the Ansible Controller itself if you don't manage it with DebOps,
don't trust
the new CA by default.
I understand. You are right. Since we use an ansible controller for
multiple debops projects the ca's from the several projects weren't
included in the ca-certificates of the controller.
> next step was:
>
> debops ldap/init-directory -l test-ldap.test.example.de -vvv
>
> and now I get:
> Error messages sounds like there is a problem with tls. But
Did you run the 'ldapsearch' command from the Ansible
Controller
itself?
No, since this isn't easy because the target ldap server is only
reachable through ssh proxy jump and is not directly accessible.
DebOps 'ldap' role runs the LDAP tasks on the Ansible
Controller and
contacts
the LDAP server remotely.
You might need to add the DebOps CA to your system CA certificate
store.
Ok, I did. But this wasn't enough. So my understanding now is that the
ldap commands are executed directly from the controller - so the ldap
port has to be open and routing has to work. I just brought the target
ldap server into the local network and it worked.
Since (most of? all?) other roles just rely on remote ssh connections I
didn't think about this possibility. Is there any reason why the ldap
statements are not executed remote? And is there any possiblity to
change this behaviour?
As long as I understand the ldap server (and all other hosts in the
network?) have to be reachable from the ansible controller for all ldap
based operations. This is in fact a limitation for our purposes.
Is someone have any ideas ...
Thanks and regards
Jan