On 04/23/2014 05:07 PM, Stephen Benjamin wrote:
Hi,
----- Original Message -----
From: "Dmitri Pal" <d...@redhat.com>
To: freeipa-users@redhat.com, stben...@redhat.com
Sent: Wednesday, April 23, 2014 10:16:16 PM
Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/23/2014 10:00 AM, Stephen Benjamin wrote:
Hi All,
As part of the next release of Foreman, 1.5, realm join integration
is being introduced. The first provider is, of course, FreeIPA. :-)
The first release candidate of 1.5 is out now and I'd really
appreciate it if anyone wants to give the FreeIPA integration a good
workout. You can see it in action during today's sprint demo starting
at about 36 minutes in:
https://www.youtube.com/watch?v=XliDyFFi-SI#t=36m00
Docs about the FreeIPA stuff are here:
http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm
If you run into any problems, I'm happy to help, I'm stbenjam
over on #theforeman or #freeipa IRC channels.
Note - There's at least one bug whose fix should be merged in RC2:
unenrolled hosts aren't deleted from IPA correctly. Otherwise it
should all work as advertised!
Thanks!!
Stephen
Very cool!
Several questions:
- Is it using IPA smart proxy and if not when and how it will? We would
probably need to add the instruction on how to set it up instead of the
native one. I suspect there are some differences and the reason why one
would be used over another.
It is using a provider built-in to the Foreman Smart Proxy. However, Rob
and I collaborated to ensure the APIs are compatible. You should be able
to swap out the Foreman proxy for the FreeIPA proxy when it's released.
I know, I am sort of asking for documentation and comparison so that
people would know which one we prefer them to use and why.
Having the proxy in your repos, and very easily configured is
brilliant, it makes the user experience so much better. We do need to
make sure it gets SSL authentication enabled. But over time, I expect
Foreman's proxy to be deprecated and most people to use FreeIPA's, but
we do need ours for older versions.
OK.
- I think the setup script should probably be a part of IPA smart proxy
project rather than a part of Foreman. IMO it is in the boat as mart
proxy as it links IPA and Foreman together. What do you think? May be
there should be spacial repo in IPA. As we move forward we would need to
have more and more simple scripts to setup specific integration aspects
with different projects. This is just the first one of them so we need
to define what we want to do with the next one when it emerges.
The setup script in the video is just creating some permissions we
need, it's here:
http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser
I would kind of like to see this added to FreeIPA as a role, or somehow
distributed with the FreeIPA proxy package.
I opened an issue about this a while back:
https://fedorahosted.org/freeipa/ticket/4252
Yes we have it in the right bucket so this is coming.
The question is more about where it really belongs and in what shape of
form.
Should be an out of box setup so that once you install IPA it is already
ready for Foreman integration? Should it be a script that is run on the
server? Than can be something like:
ipa-enable-integration
command with arguments:
--foreman - would load everything needed for foreman
--OpenStack - would load everything needed for OpenStack
--foo - will handle foo
...
The alternative is to have a script with proxy in the proxy package.
That would work too.
I just do not knwo what approach is best thus asking the question.
- You have FreeIPA there as a realm type. Would it be possible to change
this string because in RHEL it is called "Identity Management"?
"FreeIPA" is used pretty much everywhere, like config files. Just the UI
wouldn't be a big issue to alter, if you want to change it for Satellite.
Yes that would be the case, I think.
- Does this support a case when the machine needs to be re-provisioned?
Does it do the right cleanup?
Yup, it disables the host if enrolled, and then requests a new OTP during
re-provision.
If you update the host group in Foreman, we also send that as a userclass
attribute for use with automembership, although automembership currently
works on initial creation.
Good
- Moving forward it might make sense to be able to pass other parameters
to the realm join to pass to ipa client install. I think we need to
explore this more. For example do you want to configure SUDO or
automaint integration on the provisioned host? Do you want to generate
and upload host fingerprint, etc. Where is the right place to track this
work?
The OTP is accessible to any provisioning template or snippet, so you
can do things however you want.
We ship some provisioning templates distributed with Foreman, which
use either 1 or 2 ways:
Fedora 20+ (and RHEL 7+):
- Built in Anaconda realm join,
https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration
I do not see a reason for realmd to be used in this case. It does not
add any value on top the ipa-client-install and actually limits the
amount of the command arguments that can be passed to the client install
script. There are two ways to overcome it: make realmd capable of
passing arguments it does not know to ipa-client install (that would be
a realmd rfe) or use ipa-client-install directly. I think direct use is
OK here because one is using IPA smart proxy and expecting the systems
to connect to IPA and not to AD.
< Fedora 20, RHEL 6, etc:
- Kickstart snippet:
https://github.com/theforeman/community-templates/blob/master/snippets/freeipa_register.erb
For Anaconda realm join, I don't see where you can pass additional options
to the installer. For the FreeIPA snippet, you can add a global
parameter to add arbitrary command line options to ipa-client-install.
See above. I think we should just go and do a direct call to
ipa-client-install
The snippet and provisioning can be customized however, and special
cases may want to make use of foreman_hooks:
https://github.com/theforeman/foreman_hooks
Yes but i do not see what else is needed yet.
Potentially there we can start adding SRV records when the deployes
system is know to run a particular server.
However, I specifically predicted the sudoers question, so I
have this blog post about it:
https://bitbin.de/blog/2014/04/freeipa-sudoers-with-puppet-foreman/
I am not sure it is doing the right thing. In the blog you specify
bindpw for SUDO, this means you are configuring SUDO without SSSD
integration. If you use IPA it is a command switch on the
ipa-client-install command to enable sudo, ssh or automount integration
(at least in the latest versions of IPA). I think we should focus on that.
https://fedorahosted.org/freeipa/ticket/3740
https://fedorahosted.org/freeipa/ticket/3358 <- but one can run command
after install to enable integration with SUDO
Honza, martin can you please add the details about SSH and SELinux
integration
I haven't investigated automount, maybe it's something I can
consider adding to the ipaclient puppet module.
I see it more as apart of the initial client setup and check boxes: do
you want SUDO integration y/n; do you want automount y/n; do you want
SELinux user mapping y/n; Do you want SSH integration y/n. Once you
deploy you usually do not change these things because they are dictated
by general policy rather than something that you turn on and off.
Thanks for the e-mail! I'm definitely interested in feedback.
Feature requests, PR's, etc are all welcome too :-)
We will be putting some PR do not worry!
Let us have a plan around open questions here and then I will start
reaching out and sharing the news.
http://projects.theforeman.org/projects/foreman/issues/new
- Stephen
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
