Hi,
the team is starting investigations regarding the deployment of IPA using Ansible, and we would like to get community feedback. Ansible already provides a few community-maintained Identity Modules [1] allowing to manage users, groups, hosts, hbac rules, roles, sudo rules, but in a first phase, we are focusing on IPA client installation.
The command line ipa-client-install is configuring various components (hostname, NTP client, IPA client, SSSD, PAM and NSS, Kerberos client + host keytab, DNS, ssh, OpenLDAP client, NIS, automount, firefox prefs...) Because of this modularity, a possible strategy would be to provide an Ansible role for ipaclient, decomposing the installation into reusable Ansible parts (kerberos client role, OpenLDAP client etc). In order to avoid maintaining 2 different installation mechanisms, we could rewrite ipa-client-install so that it internally calls Ansible to perform the configuration. Note that this would include a new dependency on Ansible, and we need to make sure that this is acceptable, keeping in mind that we are not targeting only RHEL and Fedora but also other Linux distributions.
Another strategy would be to have Ansible call the current ipa-client-install command, but the limitation is that this CLI is not idempotent. It exits on error when the host is already configured as an IPA client. A few community-provided IPA roles (client or server) are already using this approach. They can be found in Galaxy [2].
Whatever strategy is picked, we need to - keep aligned the Ansible module/role/playbook version and IPA version. - identify the most important options from ipa-client-install in order to start with what is really needed from the community - identify the most frequent use cases regarding * authentication: install with username and password, with one-time password, with an existing keytab * DNS configuration: using DNS autodiscovery based on the host domain name, specifying a domain or a server ...
We are waiting for your feedback on all these topics: would you be likely to use Ansible to deploy an IPA client, which requirements, concerns, ideas do you have in this area?
Thank you for your involvement in this project: as users of FreeIPA, your voice really matters, and you can take this opportunity to influence the direction we are going to take.
Flo
[1] https://docs.ansible.com/ansible/list_of_identity_modules.html [2] https://galaxy.ansible.com/list#/roles?page=1&page_size=10&autocompl...
Hi,
For our puppet profile we use ipa-client-install unless the file /etc/ipa/default.conf exists (which is created by ipa-client-install), this should work for ansible as well. The creates option in both puppet exec and ansible shell modules seem to serve the same purpose in that regard.
-----Original Message----- From: Florence Blanc-Renaud via FreeIPA-users [mailto:freeipa-users@lists.fedorahosted.org] Sent: maandag 12 juni 2017 10:51 To: Freeipa-users Cc: Florence Blanc-Renaud Subject: [Freeipa-users] Ansible and ipa-client-install
Hi,
the team is starting investigations regarding the deployment of IPA using Ansible, and we would like to get community feedback. Ansible already provides a few community-maintained Identity Modules [1] allowing to manage users, groups, hosts, hbac rules, roles, sudo rules, but in a first phase, we are focusing on IPA client installation.
The command line ipa-client-install is configuring various components (hostname, NTP client, IPA client, SSSD, PAM and NSS, Kerberos client + host keytab, DNS, ssh, OpenLDAP client, NIS, automount, firefox prefs...) Because of this modularity, a possible strategy would be to provide an Ansible role for ipaclient, decomposing the installation into reusable Ansible parts (kerberos client role, OpenLDAP client etc). In order to avoid maintaining 2 different installation mechanisms, we could rewrite ipa-client-install so that it internally calls Ansible to perform the configuration. Note that this would include a new dependency on Ansible, and we need to make sure that this is acceptable, keeping in mind that we are not targeting only RHEL and Fedora but also other Linux distributions.
Another strategy would be to have Ansible call the current ipa-client-install command, but the limitation is that this CLI is not idempotent. It exits on error when the host is already configured as an IPA client. A few community-provided IPA roles (client or server) are already using this approach. They can be found in Galaxy [2].
Whatever strategy is picked, we need to - keep aligned the Ansible module/role/playbook version and IPA version. - identify the most important options from ipa-client-install in order to start with what is really needed from the community - identify the most frequent use cases regarding * authentication: install with username and password, with one-time password, with an existing keytab * DNS configuration: using DNS autodiscovery based on the host domain name, specifying a domain or a server ...
We are waiting for your feedback on all these topics: would you be likely to use Ansible to deploy an IPA client, which requirements, concerns, ideas do you have in this area?
Thank you for your involvement in this project: as users of FreeIPA, your voice really matters, and you can take this opportunity to influence the direction we are going to take.
Flo
[1] https://docs.ansible.com/ansible/list_of_identity_modules.html [2] https://galaxy.ansible.com/list#/roles?page=1&page_size=10&autocompl... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 2017-06-12 11:45, wouter.hummelink--- via FreeIPA-users wrote:
Hi,
For our puppet profile we use ipa-client-install unless the file /etc/ipa/default.conf exists (which is created by ipa-client-install), this should work for ansible as well. The creates option in both puppet exec and ansible shell modules seem to serve the same purpose in that regard.
In my experience a check for /etc/ipa/default.conf does not work reliable. It fails to detect failed or broken installations. ipa-client-install checks for additional files, e.g. its internal installation state in /var/lib/ipa-client/sysrestore/
Christian
On 06/12/2017 11:45 AM, wouter.hummelink--- via FreeIPA-users wrote:
Hi,
For our puppet profile we use ipa-client-install unless the file /etc/ipa/default.conf exists (which is created by ipa-client-install), this should work for ansible as well. The creates option in both puppet exec and ansible shell modules seem to serve the same purpose in that regard.
Ok, thanks for info. I suspect that the future FreeIPA client Ansible module could benefit you as well. AFAIK, Ansible can be also called from Puppet, if that is your configuration tool of choice.
If we manage to Ansible-ize client "properly", i.e. not just wrap ipa-client-install in an Ansible module, but actually decompose the steps in native Ansible actions as Flo suggested, the benefit should be that FreeIPA client installation could be:
- modified by the client Ansible module, without having to re-enroll client as with ipa-client-install - possibly repaired by the client Ansible module if somebody did some action on the client that broke it
Martin
On 2017-06-12 10:50, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
the team is starting investigations regarding the deployment of IPA using Ansible, and we would like to get community feedback. Ansible already provides a few community-maintained Identity Modules [1] allowing to manage users, groups, hosts, hbac rules, roles, sudo rules, but in a first phase, we are focusing on IPA client installation.
The command line ipa-client-install is configuring various components (hostname, NTP client, IPA client, SSSD, PAM and NSS, Kerberos client + host keytab, DNS, ssh, OpenLDAP client, NIS, automount, firefox prefs...) Because of this modularity, a possible strategy would be to provide an Ansible role for ipaclient, decomposing the installation into reusable Ansible parts (kerberos client role, OpenLDAP client etc). In order to avoid maintaining 2 different installation mechanisms, we could rewrite ipa-client-install so that it internally calls Ansible to perform the configuration. Note that this would include a new dependency on Ansible, and we need to make sure that this is acceptable, keeping in mind that we are not targeting only RHEL and Fedora but also other Linux distributions.
Another strategy would be to have Ansible call the current ipa-client-install command, but the limitation is that this CLI is not idempotent. It exits on error when the host is already configured as an IPA client. A few community-provided IPA roles (client or server) are already using this approach. They can be found in Galaxy [2].
Thanks for your summary, Flo.
It sounds like we both agree that the second strategy (simply run ipa-client-install and catch error) is not the best approach. The simplistic variant has multiple issues. On the other hand ipa-client-install does a lot of stuff. I don't think we can deliver a full replacement in Ansible within the development phase of 4.6 or 4.7. It may be more feasible to augment the ipa-client-install command and expose installation steps as subcommands? A check or state subcommand could be added to get the installation state.
$ ipa-client-install check $ ipa-client-install enroll $ ipa-client-install dns $ ipa-client-install openldap $ ipa-client-install ssh-client ...
The subcommands and checker could be re-used by puppet, too. What do you think?
My biggest concern is insecure enrollment with username and password. Every playbook I known -- including my own one -- passes username and password to the client machine. For Ansible automation, we should not use admin credentials but rather push for OTP. To make OTP enrollment work idempotent, multiple steps with extra checks are required. The OTP approach eliminates the need to delegate GSSAPI to a client machine.
Example:
* A->C check if client is IPA enrolled * A->I check if client has a host entry * A->I create host entry * A->I generate OTP for host entry * A->C enroll client with OTP
A: Ansible control machine C: new client machine I: IPA master
Regards, Christian
On Mon, Jun 12, 2017 at 12:20:38PM +0200, Christian Heimes via FreeIPA-users wrote:
On 2017-06-12 10:50, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
the team is starting investigations regarding the deployment of IPA using Ansible, and we would like to get community feedback. Ansible already provides a few community-maintained Identity Modules [1] allowing to manage users, groups, hosts, hbac rules, roles, sudo rules, but in a first phase, we are focusing on IPA client installation.
The command line ipa-client-install is configuring various components (hostname, NTP client, IPA client, SSSD, PAM and NSS, Kerberos client + host keytab, DNS, ssh, OpenLDAP client, NIS, automount, firefox prefs...) Because of this modularity, a possible strategy would be to provide an Ansible role for ipaclient, decomposing the installation into reusable Ansible parts (kerberos client role, OpenLDAP client etc). In order to avoid maintaining 2 different installation mechanisms, we could rewrite ipa-client-install so that it internally calls Ansible to perform the configuration. Note that this would include a new dependency on Ansible, and we need to make sure that this is acceptable, keeping in mind that we are not targeting only RHEL and Fedora but also other Linux distributions.
Another strategy would be to have Ansible call the current ipa-client-install command, but the limitation is that this CLI is not idempotent. It exits on error when the host is already configured as an IPA client. A few community-provided IPA roles (client or server) are already using this approach. They can be found in Galaxy [2].
Thanks for your summary, Flo.
It sounds like we both agree that the second strategy (simply run ipa-client-install and catch error) is not the best approach. The simplistic variant has multiple issues. On the other hand ipa-client-install does a lot of stuff. I don't think we can deliver a full replacement in Ansible within the development phase of 4.6 or 4.7. It may be more feasible to augment the ipa-client-install command and expose installation steps as subcommands? A check or state subcommand could be added to get the installation state.
$ ipa-client-install check $ ipa-client-install enroll $ ipa-client-install dns $ ipa-client-install openldap $ ipa-client-install ssh-client ...
The subcommands and checker could be re-used by puppet, too. What do you think?
My biggest concern is insecure enrollment with username and password. Every playbook I known -- including my own one -- passes username and password to the client machine. For Ansible automation, we should not use admin credentials but rather push for OTP. To make OTP enrollment work idempotent, multiple steps with extra checks are required. The OTP approach eliminates the need to delegate GSSAPI to a client machine.
Example:
- A->C check if client is IPA enrolled
- A->I check if client has a host entry
- A->I create host entry
- A->I generate OTP for host entry
- A->C enroll client with OTP
A: Ansible control machine C: new client machine I: IPA master
Regards, Christian
-- Christian Heimes Senior Software Engineer, Identity Management and Platform Security
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Christian, I agree with your proposal. This is IMO the only viable way to support multiple high level approaches to FreeIPA client installation.
With this architecture it's easy to keep consistent behaviour, add new instalation path and keep around the old and well known ipa-client-install with all its options.
On Mon, 2017-06-12 at 10:50 +0200, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
We are waiting for your feedback on all these topics: would you be likely to use Ansible to deploy an IPA client, which requirements, concerns, ideas do you have in this area?
Thank you for your involvement in this project: as users of FreeIPA, your voice really matters, and you can take this opportunity to influence the direction we are going to take.
Flo
Hi,
we're already using ansible to ipa-client-install our RedHat/CentOS machines, which works well in about 99% of all installations. Our ansible playbook calls something like this:
- name: Join IPA domain '{{ ansible_domain }}' shell: ipa-client-install --domain={{ ansible_domain }} --mkhomedir --hostname={{ ansible_hostname }}.{{ ansible_domain }} --enable-dns-updates -p XXXXXXX -w XXXXXXX --unattended
We have a few different use cases:
1.)- new install on servers -> using static IP address (--ip-address=x.x.x.x) 2.)- new install on workstations -> mostly using DHCP for assigning IP address (--enable-dns-updates) 3.)- remove server/workstation from Windows Active Directory (AD.MH.LOCAL), getting rid of Windows AD membership, afterwards joining IPA domain 4.)- remove server/workstation from IPA domain e.g. 'MHDEV.LOCAL', afterwards add server/workstation to IPA domain e.g. 'MH.LOCAL'
As from the experience with all these use cases, we would like to see an idempotent installation mechanism. Reasons:
- As a bad example, if we run our playbook for use case 3.) (didn't try for use case 4.) ) and we do not delete /etc/sssd/sssd.conf, no new sssd.conf will be created, but the existing one will be expanded with new additional config parameters. If i remember correct, .bkp files are created anyways, so if you would want to go back to your old files, these can be still found.
- If 'ipa-client-install' fails, we use 'ipa-client-install --uninstall' to get rid of the failed installation. Maybe this could be automated, since you never want to have a broken installation. (Reboot needed?)
Nice to have: - Create & delete host entries, as well as DNS records when installation & uninstallation was successful. At the moment, after unenrollment, we have to delete DNS records of a machine (which does not exist in our IPA domain anymore) by either doing this in the Web UI or by cli command.
- As you can see, we're using username + password during 'ipa-client-install'. Either allow crypted passwords or give out OTP, which can be automatically used with ansible.
Regards,
Gerald
freeipa-users@lists.fedorahosted.org
-
Christian Heimes -
David Kupka -
Florence Blanc-Renaud -
Gerald-Markus Zabos -
Martin Kosek -
wouter.hummelink＠kpn.com