ipa_host: Fix enabled and disabled states

[abakanovskii]

SUMMARY

Fix enabled and disabled states
Fixes #1094

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

ipa_host

ADDITIONAL INFORMATION

Im not sure why it is how it is on 267 line of code and what exactly random_password is used for but for better reverse compatibility I kept it
And looking at the ansible-freeipa collection their module is way ahead of this one (if not all of them) so I don't know if these should be maintained in community.general

# Now this works as intended
    - name: disable host
      community.general.ipa_host:
        fqdn: target_fqdn
        state: disabled
        validate_certs: no
        ipa_pass: pass
        ipa_user: user
        ipa_host: host

[felixfontein]

Thanks for your contribution!

[felixfontein]

This change looks wrong. disabled should (apparently) be a special case of present, so the host exists, but is disabled.

[abakanovskii]

yeah, but if there are no host found It would create one which seems to be weird because enabled and disabled are states for managing already existing hosts so I created an additional if statement for that case

[felixfontein]

I don't think it's weird. But I think there should also be another state, like disabled-or-absent. Depending on what you want to achieve disabled or disabled-or-absent is the right state to use.

[abakanovskii]

I added force_creation parameter for that case

[felixfontein]

This looks wrong to me. A present host can both be enabled or disabled.

[abakanovskii]

yes, but there are no such thing as 'enabling' host, because host is considered as 'enabled' if it has a keytab so to 'enable' a host you would need to do something completely different https://freeipa.readthedocs.io/en/latest/api/host_disable.html
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/identity_management_guide/host-disable#reenabling-hosts
and this module should not create keytab files on its own so I don't see a reason for having 'enabled' state other than to be an alias for 'present'

[felixfontein]

I don't know FreeIPA at all, I only know about Ansible semantics, and what I wrote is what enabled/disabled usually means, and seems to be what the module also means (or better: intended do mean) when looking at the current implementation.

[abakanovskii]

Well, in that case I will keep it as it was before my changes

[ansibullbot]

cc @Akasurde @Nosmoht @justchris1
click here for bot help

[abakanovskii]

Should ipa_* modules even be maintaned as long as ansible-freeipa exists? ipahost from ansible-freeipa seems to be far advanced

[felixfontein]

And looking at the ansible-freeipa collection their module is way ahead of this one (if not all of them) so I don't know if these should be maintained in community.general

I think there has been a (not sure how long) discussion some years ago of whether the IPA modules should be moved there / whether forces should be combined with that collection, but I'm not sure what happened to it. (I can't find the discussion anymore, unfortunately...)

[felixfontein]

Now I found #1147 (comment) and some IRC logs from that time. In the IRC logs we kind of agreed that we should ask the FreeIPA community, but I'm not sure this ever happened.

(Right now there's also https://forum.ansible.com/t/5738 which complicates things a bit...)

[abakanovskii]

Now I found #1147 (comment) and some IRC logs from that time. In the IRC logs we kind of agreed that we should ask the FreeIPA community, but I'm not sure this ever happened.

(Right now there's also https://forum.ansible.com/t/5738 which complicates things a bit...)

Thanks for the info! Then I will fix this issue for now but will try to not focus on freeipa modules not to reinvent the wheel
I think even if we combine community and freeipa modules it will result in a different namespace anyway :)

[felixfontein]

I cannot judge the IPA parts, but it looks OK to me. I'll merge this in ~a week if nobody objects.

[russoz]

LGTM