lvps / 389ds-server Goto Github PK

Maybe you mean

- name: "Reload schema on {{ dirsrv_serverid }}"
  tags: dirsrv_schema
  ldap_entry: [...]
  when: not dirsrv_restart_condition_has_restarted|default(false) and (
      ( dirsrv_restart_condition_schema_reload_1 is defined and dirsrv_restart_condition_schema_reload_1.changed ) or
      ( dirsrv_restart_condition_schema_reload_2 is defined and dirsrv_restart_condition_schema_reload_2.changed )
    )

In this way it works very pretty for me.

I apologize for this probably dumb question, but I'm confused.

Running the role with dirsrv_selfsigned_cert: true, I hit the following issue:

TASK [389ds-server : Check that tls_key[_file] is defined] *******************************************************************
fatal: [proxy]: FAILED! => {
    "assertion": "(dirsrv_tls_key is defined) != (dirsrv_tls_key_file is defined)",
    "changed": false,
    "evaluated_to": false
}

MSG:

only one of dirsrv_tls_key or dirsrv_tls_key_file must be defined

I had the following settings:

    dirsrv_tls_enabled: true
    dirsrv_tls_certificate_trusted: false
    dirsrv_tls_enforced: false
    dirsrv_selfsigned_cert: true
    dirsrv_selfsigned_cert_duration: 24

I had not set either dirsrv_tls_key or dirsrv_tls_key_file (and I had no idea what to set it to).
I worked around it by setting dirsrv_tls_enabled: false, but I'm unsure if this is correct, because I do want to use TLS (just with the self-signed cert for the time being). Can you confirm?

Since #47 has been merged, LDAPI is used by default and the role also assumes that the default LDAPI socket path is used.
The path can be customized by users, so it would be a good idea to either add a variable and use the default only if the variable is not set, or detect the current path from dse.ldif.

Hello,
recently epel-modular repository for EL8 was discontinued and new builds of 389-ds-base are now distributed via copr:
https://lists.fedoraproject.org/archives/list/[email protected]/thread/4UORX27XQUHZAF4KMPK4JIYZHGJH666A/
I'm not sure the lvps.389ds_server is still working for RHEL8 based distros (Rocky, Alma, etc.) after this change... probably the variable "dirsrv_product" which now defaults to "@389-directory-server:stable/minimal" has to changed to just "389-ds-base".
Can you please have a look ?
Thanks

Some variables have opinionated defaults: dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme (deletes current value if not set), dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabled, dirsrv_dna_plugin.

To ignore them, dirsrv_factory exists. However that should be the default behavior, without the need to enable dirsrv_factory: do not change 389DS defaults, unless one of those variables is defined.

So how can it be ethnically ok if I’m the owner an the target??? Anyone else think that’s strange? Fuck Wikipedia fuck the reduction an fuck the program manager who has cloned me an taking 50$ a day from my account- an I found out not for months…. An something will happen to be a big player an experience I soon not forget however you are 21 cola berating my life so who is the one who knows what to do now

I tested with ansible-2.7.11 and molecule-2.20.1 and in the testinfra section I get this error:

    =================================== FAILURES ===================================
    _________________ test_389ds_listening_389[ansible://default] __________________
    
    host = <testinfra.host.Host object at 0x307d810>
    
        def test_389ds_listening_389(host):
            socket = host.socket('tcp://0.0.0.0:389')
        
    >       assert socket.is_listening
    E       assert False
    E        +  where False = <socket tcp://0.0.0.0:389>.is_listening
    
    tests/test_default.py:25: AssertionError

Ansible returns an error: Error: -1 - Can't contact LDAP server - 2 - [] - No such file or directory

failed: [some_host] (item=~/some_ldif) => {"ansible_loop_var": "item", "changed": true, "cmd": ["/usr/sbin/dsconf", "-D", "cn=admin", "
-w", "some_pass", "ldap://some_fqdn", "backend", "import", "userRoot", "/var/lib/dirsrv/slapd-host/ldif/some_ldif"], "delta":
"0:00:00.487725", "end": "some_time", "item": "~/some_ldif", "msg": "non-zero return code", "rc": 1, "start": "some_time", "stderr": "",
"stderr_lines": [], "stdout": "Error: -1 - Can't contact LDAP server - 2 - [] - No such file or directory", "stdout_lines": ["Error: -1 - Can't
contact LDAP server - 2 - [] - No such file or directory"]}

Most likely, the problem is that at the place where the task is running, the instance is not yet running. Of the possible solutions, you can place this task after the start of the service.

Or execute a command like:

dsconf {{dirsrv_serverid}} backend import {{dirsrv_bename}} /dir/file

Instead of: (how it is done now)

dsconf -D {{dirsrv_rootdn}} -w {{dirsrv_rootdn_password}} ldap://{{dirsrv_fqdn}} backend import userRoot /dir/file

This does not require ldap:// connection and imports the changes directly into the instance and does not require service start. Why isn't this used?

P.S. I can create a PR with one of these variants

It was removed for some reason

LDAPI + high minssf = cannot connect
However, if nsslapd-localssf > minssf, 389DS will accept LDAPI connections. See section 3.1.1.112 here.

I see nsSSLClientAuth gets turned off in tasks/configure_tls.yml.
In my use case I need ssl client auth to setup replication agreements, based on host certificates (rather than user/pass).
It would be nice to have an option to override this setting (maybe an extra variable: dirsrv_sslclientauth)
Thanks

Trying to use an LDIF in a demo setup to create some demo users. The Install additional ldif files (dsconf) task fails with dsconf reporting:

Could not open LDIF file "/tmp/users.ldif", errno 2 (No such file or directory)

when I set vars for the role of:

      dirsrv_install_additional_ldif:
        - users.ldif

System info:

[root@hq ~]# uname -a
Linux hq.boulderhill.net 4.18.0-240.22.1.el8_3.x86_64 #1 SMP Thu Apr 8 19:01:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@hq ~]# cat /etc/redhat-release 
CentOS Linux release 8.3.2011
[root@hq ~]# ansible --version
ansible 2.9.21
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /bin/ansible
  python version = 3.6.8 (default, Aug 24 2020, 17:57:11) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]
[root@hq ~]# cat /etc/ansible/roles/lvps.389ds_server/meta/.galaxy_install_info 
{install_date: 'Tue May 25 02:14:12 2021', version: v3.0.2}

Hello,
new versions of Ansible (I'm on 2.16) no longer allow the use of ansible.builtin.include.
Could you please update the role with include_tasks or import_tasks ?

ERROR! [DEPRECATED]: ansible.builtin.include has been removed. Use include_tasks or import_tasks instead. This feature was removed from ansible-core in a release after 2023-05-16. Please update your playbooks.

Whenever I use the role I get this warning:

[DEPRECATION WARNING]: community.general.ldap_attr has been deprecated. see plugin documentation for details. This feature will be removed from community.general in version 3.0.0. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.

Recent versions of ansible-lint report a lot of errors

ansible-lint --version
ansible-lint 24.2.0 using ansible-core:2.16.4 ansible-compat:4.1.11 ruamel-yaml:0.17.40 ruamel-yaml-clib:0.2.8

Using CentOS 8.3 amd64, 389-ds-base-1.4.3.17

I get this in the error log:

[23/Jan/2021:23:48:42.177303526 +0100] - ERR - dna-plugin - dna_parse_config_entry - Unable to locate shared configuration entry (cn=Account UIDs,ou=Ranges,dc=i,dc=ewsrv,dc=ch)
[23/Jan/2021:23:48:42.177841836 +0100] - ERR - dna-plugin - dna_parse_config_entry - Invalid config entry [cn=uid numbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped
[23/Jan/2021:23:48:42.178312560 +0100] - ERR - dna-plugin - dna_parse_config_entry - Unable to locate shared configuration entry (cn=Account GIDs,ou=Ranges,dc=i,dc=ewsrv,dc=ch)
[23/Jan/2021:23:48:42.178713577 +0100] - ERR - dna-plugin - dna_parse_config_entry - Invalid config entry [cn=gid numbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped

created with this configuration:

dirsrv_starttls_early: '{{ dirsrv_tls_enabled }}'
dirsrv_suffix: "dc=i,dc=dom,dc=com"
dirsrv_rootdn_password: "bla-blu-blap"

dirsrv_fqdn: "dir.i.dom.com"

dirsrv_serverid: "dir"

dirsv_role: "both"

dirsrv_plugins_enabled: 
  MemberOf Plugin: True
  Distributed Numeric Assignment Plugin: True

dirsrv_dna_plugin:
  gid_min: 200000
  gid_max: 999999
  uid_min: 200000
  uid_max: 999999

dirsrv_allow_other_schema_files: "True"
dirsrv_custom_schema: ["freeradius-ldap-schema.schema"]
dirsrv_create_suffix_entry: "True"

dirsrv_install_examples: True

Hey,

What exactly is the purpose of the rescue block in the configure_tls_enforcing.yml file?
I think that part is never triggered, because the Configure enforcing of TLS tasks has an failed_when: false attribute.

If one or more hosts in my inventory has already been installed, this role causes an error saying that port 389 is already in use. It would be awesome if we could modify this role to detect already installed servers and validate configuration or update configuration.

This would allow for periodic re-runs of a playbook+inventory to ensure that the server/service is properly configured and in compliance with our declarative state.

I will take a look and see if I can figure out how to make this happen.

Hi,

Thanks for creating this Ansible role - it's very useful.

I wanted to set in my playbook dirsrv_serverid to be the hostname of the server. The playbook is used for more than one server so I wanted to use either ansible_hostname or inventory_hostname_short for dirsrv_serverid. This fails to work with the "Configure LDAPI" task however:

TASK [389ds-server : Configure LDAPI] ***************************************************************************************************************************************
changed: [spitfire0] => (item={'name': 'nsslapd-ldapilisten', 'value': 'off'})
changed: [spitfire0] => (item={'name': 'nsslapd-ldapiautobind', 'value': 'off'})
ERROR! 'ansible_hostname' is undefined

Earlier tasks that rely upon dirsrv_serverid work though.

Example playbook entry:

- role: 389ds-server
      tags: 389ds-server
      vars:
        dirsrv_rootdn_password: 'password_here'
        dirsrv_serverid: '{{ ansible_hostname }}'
        dirsrv_install_examples: true