3:50 a.m.
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&autoco...
4:45 a.m.
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&autoco...
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
5:08 a.m.
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
--
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
5:15 a.m.
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
5:20 a.m.
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
8:37 a.m.
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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.
--
David Kupka
7:04 a.m.
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
--
Gerald-Markus Zabos <gmzgames.de(a)googlemail.com>
Web: http://www.gmzgames.de
2503
days inactive
2504
days old
freeipa-users@lists.fedorahosted.org
6 comments
6 participants
participants (6)
-
Christian Heimes -
David Kupka -
Florence Blanc-Renaud -
Gerald-Markus Zabos -
Martin Kosek -
wouter.hummelink＠kpn.com