Work with RHDS11 and other minor fixes

[falon]

Hello, I would like to suggest some other changes for this very useful role:

• [new] With dirsrv_product you can specify a different module repo for the 389ds. Useful if you install the Red Hat Directory Server in place of the Fedora Directory Server.
• [mod] Use dnf in place of yum on Centos 8
• [mod] All latest rpm of 389-ds-base install the wanted user and group. At least I suggest to keep the useradd task on legacy system only.
• [mod] Run sefcontext only if selinux is defined and enabled.

[lvps]

Thanks, those changes look useful too!

The only one I'm not really sure about is Run sefcontext only if selinux is defined and enabled..
That is, I think ansible_selinux is defined is a good check, but I'm not sure about ansible_selinux.status == 'enabled': does it change when SELinux is permissive instead of enforcing? Is there any unwanted effect when that rule is added via sefcontext if SELinux is not enabled?

If I remember correctly it's set to permissive by default, so I may install 389DS and then switch it to enforcing. I'd rather have all the rules in place at that point, instead of re-running the role for a single sefcontext task, probably. If ansible_selinux.status == 'enabled' is still true for permissive mode this is much less of a problem, although I guess some users could disable SELinux and then enable it again later.

[falon]

Hello, I read here:

https://www.reddit.com/r/ansible/comments/6jo1xe/checking_for_selinux/

and here:

https://github.com/ansible/ansible/blob/438cd6687f825873751d03a509ff0b5f9744198b/test/integration/targets/sefcontext/tasks/main.yml

Is there any unwanted effect when that rule is added via sefcontext if SELinux is not enabled?

this could be a reason to add this check. I have to understand better.

Travis claims also about "Check 389DS package version". Maybe does it run on ubuntu? I have tested dnf change on Centos like systems.

[lvps]

Indeed, I found the same two pages that mention ansible_selinux, but I didn't find any other documentation, so I'm not really sure.

Travis is running the tests on a CentOS container inside some other container (probably Ubuntu), but everything happens inside the CentOS one. I think it may be a fluke/random error that will fix itself on the next run, since you didn't really change anything for CentOS 7 and it passed 1 test out of 4.

[falon]

The error on Centos 7, where I can't understand what I could have changed in the PR, still occurs.

About selinux, I don't have at the moment additional ldif files to add in order to test deeply the sefcontext task.

I have a very complicated LDAP setup, so I would add the complete configuration after dscreate with ds-easyconf.

On 389ds > 1.4 I prefer to trust completely on dsconf (lib389). So I wrote a recursive dsconf manager. But this is another story.

[falon]

I tried with an ldif file, removing the line

ansible_selinux.status == 'enabled'

using an host (ldap.example.com) which has selinux disabled at all.

The playbook stops with this error:

failed: [ldap.example.com] (item=modify_replication_manager.ldif) => {
    "ansible_loop_var": "item",
    "changed": false,
    "invocation": {
        "module_args": {
            "ftype": "a",
            "ignore_selinux_state": false,
            "reload": true,
            "selevel": null,
            "setype": "user_tmp_t",
            "seuser": "unconfined_u",
            "state": "present",
            "target": "/tmp/modify_replication_manager.ldif"
        }
    },
    "item": "modify_replication_manager.ldif",
    "msg": "SELinux is disabled on this host."
}

So I must add ansible_selinux.status == 'enabled' to work.

[lvps]

Alright then, ansible_selinux.status == 'enabled' is needed, thank you for investigating that part. This evening I'll try to figure out why the tests keep failing and merge you PR.

By the way, it was interesting to know the automation tools you built around dscreate/dsconf, although my production setup is so simple that I don't really need to get to that level of automation.

[lvps]

The task is only failing in Travis, it works on my pc. Merging now and trying to debug the task in Travis later.