On Thu, Aug 3, 2017 at 4:39 PM, Tomas Krizek via FreeIPA-devel freeipa-devel@lists.fedorahosted.org wrote:

On 08/02/2017 01:36 PM, Florence Blanc-Renaud via FreeIPA-devel wrote:

Hi all,

The first version of a new design document is available at https://www.freeipa.org/page/V4/ClientInstallationWithAnsible

The feature will allow to deploy IPA clients using Ansible. Please feel free to send your comments, suggestions or concerns.

Thanks, Flo

Hi Flo, finally got to responding. In general the design seems good to me.

Hi!

Thanks for the design. I'd like to share some thoughts.

1. I find it confusing that ipaclient module will just check the domain and

realm if it is already configured. I can imagine a situation where an admin modifies the installargs, re-runs the playbook and expects the changes to be applied. Unfortunately, I can't think of a good solution for this. I wouldn't expect this behavior as a user of this module. At the very least, this should be very well documented.

I would treat it as next step.

2a. I think ipaclient role should support at least Fedora, RHEL and Debian. Do we know about any distribution specifics besides the different package names?

Commands and API are IMO the same. So we might be ok.

2b. Since the packages names are different and we have to have distro-specific code anyway, is there any advantage to using the `package` module instead of `dnf`, `yum` and `apt` modules?

3. The ipaclient role state=absent could uninstall the packages by default,

but provide a variable to override this behavior.

What is the best practice in Ansible modules?

4. I'd appreciate to see comprehensive documentation of all the options for

the modules -- similar to Ansible documentation for modules (e.g. [1]). Some options were mentioned in the text and examples, but I'm not sure whether the list is exhaustive and an overview of all options would be nice.

5. Regarding the minimum version of ipa-client-install: 4.4+ has to be

supported, as that's the version in current Fedora and also in Debian. It might be worth investigating how difficult would it be to support the version of ipa-client-install that's in RHEL 6.9. If the complexity is high, I wouldn't support it.

There should not be noticible differences in 4.4+. With RHEL 6.x (FreeIPA <= 3.2) it might be a different story. Mainly because ipalib behaves a bit differently. We can try it. If it works then great if not then we should look at the problem as see if it is worth fixing it.

[1] - http://docs.ansible.com/ansible/latest/service_module.html

As a next step. We can leverage the fact that for uninstallation we can use account with higher privileges then host (standard client uninstaller can work only with host keytab). This advantage allows us to solve problems like https://pagure.io/freeipa/issue/5676 [RFE] ipa-client-install: need an option to completely remove client from idm server

e.g. by calling `host-del --update-dns` or other command.

On 08/16/2017 09:16 AM, Martin Kosek wrote:

On 08/02/2017 01:36 PM, Florence Blanc-Renaud via FreeIPA-devel wrote:

...

Hi all,

The first version of a new design document is available at https://www.freeipa.org/page/V4/ClientInstallationWithAnsible

The feature will allow to deploy IPA clients using Ansible. Please feel free to send your comments, suggestions or concerns.

Thanks, Flo

Thanks for design, I just read it. For now, I have just a question regarding what is the state of communication with Ansible upstream community, especially regarding improvement of the already developed modules.

In the design, I see: " ipa_host module does not allow to create a random One-Time Password all the IPA modules are authenticating to IPA server using principal + password and do not support keytabs all the IPA modules are communicating with the IPA server using the remote JSON API instead of the Python API These limitations argue in favor of a new ipahost module. " Does it mean you want to propose a parallel ipahost Ansible module for the upstream Module Index? I would think it would be better to work with Ansible upstream and refactor/enhance the modules that are existing in there already, rather than fork them. The upstream Ansible modules are in "preview" mode anyway, i.e. the interface can change.

Thanks, Martin

Hi,

an internal conversation also argued that my proposal would require ssh access to ipa master from Ansible controller, and some users may not agree with this.

Keeping this in mind, I now tend to think that it would be better to enhance the existing ipa_host module (still using HTTP+JSON) and if possible also support authentication with an admin keytab. The other IPA modules would benefit from this change, too.

Are there any concerns with this new approach? Flo

On 09/01/2017 03:56 PM, Rob Crittenden via FreeIPA-devel wrote:

Florence Blanc-Renaud via FreeIPA-devel wrote:

...

On 08/16/2017 09:16 AM, Martin Kosek wrote:

...

On 08/02/2017 01:36 PM, Florence Blanc-Renaud via FreeIPA-devel wrote:

...

Hi all,

The first version of a new design document is available at https://www.freeipa.org/page/V4/ClientInstallationWithAnsible

The feature will allow to deploy IPA clients using Ansible. Please feel free to send your comments, suggestions or concerns.

Thanks, Flo

Thanks for design, I just read it. For now, I have just a question regarding what is the state of communication with Ansible upstream community, especially regarding improvement of the already developed modules.

In the design, I see: " ipa_host module does not allow to create a random One-Time Password all the IPA modules are authenticating to IPA server using principal + password and do not support keytabs all the IPA modules are communicating with the IPA server using the remote JSON API instead of the Python API These limitations argue in favor of a new ipahost module. " Does it mean you want to propose a parallel ipahost Ansible module for the upstream Module Index? I would think it would be better to work with Ansible upstream and refactor/enhance the modules that are existing in there already, rather than fork them. The upstream Ansible modules are in "preview" mode anyway, i.e. the interface can change.

Thanks, Martin

Hi,

an internal conversation also argued that my proposal would require ssh access to ipa master from Ansible controller, and some users may not agree with this.

Keeping this in mind, I now tend to think that it would be better to enhance the existing ipa_host module (still using HTTP+JSON) and if possible also support authentication with an admin keytab. The other IPA modules would benefit from this change, too.

Are there any concerns with this new approach?

Support for using an OTP is a must for proper automation.

rob _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-leave@lists.fedorahosted.org

Hi Rob, I totally agree that we need to support OTP.

The draft design was proposing to provide a new Ansible module performing the equivalent of ipa host-add/mod --random (to create the OTP) by executing the Ansible module on IPA master and using IPA API. Then concerns were raised, that this required ssh access to the master for Ansible. Hence my proposal for the module to use JSON and be executed on the Ansible controller. Does this clarify (or did I have a wrong interpretation of your concern)?

Flo