[Freeipa-users] FreeIPA + Foreman 1.5

[Dmitri Pal]

On 04/23/2014 07:23 PM, Stephen Benjamin wrote:
> ----- Original Message -----
>> From: "Dmitri Pal" <dpal at redhat.com>
>> To: "Stephen Benjamin" <stbenjam at redhat.com>
>> Cc: freeipa-users at redhat.com
>> Sent: Thursday, April 24, 2014 12:28:48 AM
>> Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5
>>
>>>> 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.
> Ok, is there an idea of when the proxy will be released in FreeIPA?
> 4.0? Or earlier?  When it happens, I'll link to it in the Foreman
> documentation.


I hope it will be available quite soon. 4.0 time frame seems like 
reasonable time frame.


>
>>> 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.
> Whatever fits with FreeIPA way of doing things...I think just the most
> important thing is it's relatively easy to setup.

I do not know. This is a question to the rest of the list.
Input welcome!


>
>>>> - 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.
> Well, Foreman will support Active Directory via adcli, when I have
> a chance to implement the smart proxy - hopefully for Foreman 1.6. Using
> realmd makes it work regardless of the underlying realm type.

But you already have special differentiation between IPA and AD in the 
way you pre-seed the server.
I think that realmd is more valuable for the laptop use case when it is 
not know in advance which server one needs to enroll with.
As you notice below the more we drill down into what else IPA can 
provide fro the system the bigger the difference would be between IPA 
and AD command(s) and thus realmd would be less and less attractive for 
IPA case. Using realmd for AD case is the right approch though to 
simplify the setup and let realmd do all the tricks for you.

>
> I have no horse in the race, but to me, realmd is there and it looks nice
> to have it just work out of the box.  It's one anaconda directive, versus
> many lines of a an IPA-specific snippet.

See above

>
> I would prefer that the work should be done to make realmd have sensible
> defaults and take some extra options for the specific provider.  That's
> probably not possible immediately, so I'm open to the idea of not using
> it for FreeIPA.

The problem I see is that realmd most likely would not be able to keep 
up with IPA capabilities and in some cases you might want to run more 
then one command for IPA configuration.

>
> At the end of the day, Foreman delivers the OTP, and users are free to
> customize things however they want.  I see the templates as suggestions
> with just some sane defaults.
>
> If the templates aren't sane, templates are pretty easy to contribute to:
>    https://github.com/theforeman/community-templates

It is a good start and we should work on making it more advanced over time.

>
> And the more I think about it, maybe the freeipa snippet isn't
> entirely sane and needs some extending (more about this below).
>
>
>>>    < 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.
> I'm very interested in this...
>
> I wrote the ipaclient module a year ago to suit a specific need for me.
> I have some consulting customers who use it, but I haven't had much
> feedback about it from anyone. Suggestions for changes to how I do
> things would be much appreciated.
>
> The way ipaclient is doing things works on *everything*, from a 2-year
> old release of RH IdM, to the 3.4 nightly I tested not too long ago.

Right. So this is where instead of relying on the command switches it 
might make sense to run commands (if they are available).
I do not recall what the commands and switches are. This is where I need 
help from Martin and Honza.
I know there is ipa-client-automount but I do not remember the names of 
the similar commands for SSH, SUDO and SELinux integration.


>
> It's used in the wild, so I can't just break the compatability there -- but,
> can I use SSSD setup even on the older versions of IPA?  Do you have
> some info about how to get that working? If so, I'll gladly go to
> that.

I need help here. Martin?


>
>
>> 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.
> Right, for this we'd need to extend the freeipa_snippet, and
> use Foreman parameters for these options.  I think it's a great idea,
> and something I'd gladly implement.  For Foreman 1.5, we've really
> fixed the templates now for the release, but this is something
> that could probably go into 1.5.1 if the details are hammered out.

Martin & Honza please suggest how this can be accomplished using our 
commands.
I would assume we can assume we are dealing with 6.4 and later, right?

>
> I'd really appreciate an issue opened about this.

Where?

>
> How do older versions of IPA respond to unknown options (say, if they don't
> support sudoers)?  I guess I need some kind of matrix of
> what's supported for each version, so that I can do the appropriate
> things.

Yes we should pass right options to the right clients but may be we can 
do some kind of introspaction based on the package version.
Something like:

if ipa-client package version is greater than X:
    add options k, l, m
otherwise
   log that options k, l, m are not supported on the version

if ipa-client package version is greater than Y:
    add options n, o, q, p
otherwise
   log that options n, o, q, p are not supported on the version

That might be a script that is run on the system rather than a part of 
the template and it would check the package version available and use 
only applicable options. Again here I would like to hear the opinion of 
the list.




>
>
>>> 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.
> Yup, great feedback, thanks!
>
>
>>>     http://projects.theforeman.org/projects/foreman/issues/new
>>>
>>>
>>> - Stephen
>>>
>>>
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager IdM portfolio
>> Red Hat, Inc.
>>
>>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.