[DESIGN DRAFT] IPA client installation with Ansible

[Florence Blanc-Renaud]

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

[Tomas Krizek]

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
>  _______________________________________________
>  FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to
>  freeipa-devel-leave(a)lists.fedorahosted.org 
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.

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?

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.

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.

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

-- 
Tomas Krizek

PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869

[Martin Kosek]

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

[Petr Vobornik]

On Thu, Aug 3, 2017 at 4:39 PM, Tomas Krizek via FreeIPA-devel
<freeipa-devel(a)lists.fedorahosted.org&gt; 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.




-- 
Petr Vobornik

[Florence Blanc-Renaud]

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

[Rob Crittenden]

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

[Florence Blanc-Renaud]

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(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-devel-leave(a)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

[Alexander Bokovoy]

On to, 07 syys 2017, Florence Blanc-Renaud via FreeIPA-devel wrote:
> 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(a)lists.fedorahosted.org
> >To unsubscribe send an email to freeipa-devel-leave(a)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. 
If you do have Ansible controller enrolled in
IPA, you can use 'ipa
host-add/mod' from the controller itself. For some time we already ship
'ipa' CLI utility with the base Python code that every enrolled client
has installed.


-- 
/ Alexander Bokovoy