[Freeipa-devel] [PATCH] 1106 IPA REST smart proxy

Fri Feb 21 21:49:21 UTC 2014

Dmitri Pal wrote:
> On 02/21/2014 11:09 AM, Martin Kosek wrote:
>> On 02/21/2014 04:37 PM, Rob Crittenden wrote:
>>> Dmitri Pal wrote:
>>>> On 02/17/2014 04:57 PM, Rob Crittenden wrote:
>>>>> Dmitri Pal wrote:
>>>>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote:
>>>>>>> Dmitri Pal wrote:
>>>>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote:
>>>>>>>>> Dmitri Pal wrote:
>>>>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote:
>>>>>>>>>>> Martin Kosek wrote:
>>>>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote:
>>>>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize
>>>>>>>>>>>> things
>>>>>>>>>>>> now,
>>>>>>>>>>>> difficult to do when it is live upstream and/or integrated with
>>>>>>>>>>>> Foreman.
>>>>>>>>>>>>
>>>>>>>>>>>> I think the key for the right naming is a fact if this is
>>>>>>>>>>>> really
>>>>>>>>>>>> specific to
>>>>>>>>>>>> Foreman or it is a truly general design usable also in other
>>>>>>>>>>>> use
>>>>>>>>>>>> cases. If
>>>>>>>>>>>> Foreman-specific, I would go with
>>>>>>>>>>>> freeipa-server-smartproxy-host or
>>>>>>>>>>>> similar.
>>>>>>>>>>>>
>>>>>>>>>>>> If general, we can go with
>>>>>>>>>>>>
>>>>>>>>>>>> freeipa-server-proxy-host
>>>>>>>>>>>> freeipa-server-proxy-user
>>>>>>>>>>>> freeipa-server-proxy-dhcp
>>>>>>>>>>>>
>>>>>>>>>>>> The proxies may share the framework and only expose the
>>>>>>>>>>>> requested
>>>>>>>>>>>> part of the
>>>>>>>>>>>> tree - which in advance gives you an option for an API
>>>>>>>>>>>> separation, as
>>>>>>>>>>>> compared
>>>>>>>>>>>> to general freeipa-server-smartproxy.
>>>>>>>>>>> I still don't get the point of this. Are you proposing having 3
>>>>>>>>>>> different servers, each providing a unique service? Or one
>>>>>>>>>>> service
>>>>>>>>>>> that one can turn on/off features, or something else? Do you
>>>>>>>>>>> envision
>>>>>>>>>>> this as 3 separate subpackages?
>>>>>>>>>>>
>>>>>>>>>>> There is no "framework" in my current patch, it is a cherrypy
>>>>>>>>>>> server
>>>>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of
>>>>>>>>>>> layers.
>>>>>>>>>>
>>>>>>>>>> Then it seems to make sense to have 3 different packages that
>>>>>>>>>> can be
>>>>>>>>>> optionally coninstalled and would probably share the same
>>>>>>>>>> principal,
>>>>>>>>>> keytab and local REST API socket/port.
>>>>>>>>>>
>>>>>>>>> Well, what you are designing is a central framework with plugins.
>>>>>>>>> What
>>>>>>>>> I designed is a quick-and-dirty get something up quickly. We
>>>>>>>>> need to
>>>>>>>>> pick one. The plugable method is going to require a fair bit of
>>>>>>>>> rework, though it will potentially pay dividends in the future.
>>>>>>>> I think that we can start where you are but drive towards this
>>>>>>>> architecture via refactoring. But we need to pick the right name
>>>>>>>> now.
>>>>>>>> Even if the architecture is not there yet we should name the
>>>>>>>> package in
>>>>>>>> such way that it does not preclude us from moving towards a clean
>>>>>>>> architecture I described during the next iteration.
>>>>>>> Just having a hard time seeing the value. This would be like making
>>>>>>> each of the IPA plugins a separate package and somehow installing
>>>>>>> them
>>>>>>> individually.
>>>>>>>
>>>>>>> To do this you'd need at least 2 packages, a high level one with the
>>>>>>> "framework" and then a separate one for each data type.
>>>>>>>
>>>>>>> This could also be achieved, and likely more cleanly, without all
>>>>>>> these extra packages, as a simple configuration file. Once a
>>>>>>> package,
>>>>>>> always a package.
>>>>>>>
>>>>>>> Maybe I'm too close to the problem, but to me this is a
>>>>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I
>>>>>>> don't know that anything else is using it. If you want a RESTful
>>>>>>> server, then we enable REST in IPA directly, but selectively
>>>>>>> enabling
>>>>>>> and disabling APIs is not something we've done before. It has been
>>>>>>> controlled by ACIs instead.
>>>>>>>
>>>>>>> rob
>>>>>>>
>>>>>> We are trying to predict future here. Say we release it as you
>>>>>> suggest.
>>>>>> Tomorrow we point someone upstream who wants to add users to IPA
>>>>>> from a
>>>>>> similar proxy to this implementation and say use this as a model.
>>>>>> And then Rich needs the same but for DNS for Designate.
>>>>>>
>>>>>> What would be the best? Rob if you knew that tomorrow two other
>>>>>> developers will create similar proxies for users and DNS would you
>>>>>> change anything? Would you provide some guidelines to them?
>>>>>> If you are close to the problem you should be able to at least tell
>>>>>> them: "copy and paste" vs. "add more APIs to the same proxy".
>>>>>> If your recommendation is copy and paste then I suspect there will be
>>>>>> challenges of running these proxies on the same machine - they will
>>>>>> collide on ports and sockets. If we say "extend" shouldn't we use
>>>>>> a more
>>>>>> generic name?
>>>>>>
>>>>> I'd say "use the existing IPA API". The only reason we have to write
>>>>> the smartproxy at all is to interoperate with another service that
>>>>> already has a well-defined remote server API which uses REST.
>>>>>
>>>>> rob
>>>> OK, so you think that proxy is one off. OK I am fine with it.
>>>> I was under assumption that it would be a beginning of a trend but I
>>>> might be wrong as I do not have valid arguments to prove or disprove
>>>> one
>>>> way or another.
>>>> I guess time would show.
>>>>
>>>> Any objections to Rob's approach?
>>>>
>>> Ok, so try to summarize this long-running thread, I'll rename the
>>> subpackage to
>>> freeipa-server-foreman-smartproxy to make it clearer what it is/does.
>>> Right now
>>> it requires manual configuration so having the package installed
>>> should have no
>>> negative impacts (other than potentially pulling in additional
>>> dependencies).
>>>
>>> I'll leave it in smartproxy for now, it's just cleaner and better
>>> integrates
>>> with ipatests IMHO.
>> Ok, sounds reasonable to me.
>>
>>> Foreman supports SSL client auth which is great, by cherrypy does not
>>> yet.
>>> There is a pull request to add this,
>>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity
>>>
>>> . Foreman otherwise supports no other authentication method, so we're
>>> blocked
>>> with this. The certs for this would initially come out of
>>> Foreman/puppet.
>> Does that then mean that the first version will be without any
>> authentication
>> or socket connection? Is that OK with everybody?
>>
>> Martin
> The pull request seems like a year old and suck. Any way to unstuck it?
> Can we accept the changes so far by not release it upstream until the
> change is accepted and help with it to be accepted?
> We can still start developing and integrating with Foreman using smart
> proxy without authentication for now and include it once the problem
> above is sorted.
> It would be a blocker for IPA release though so we should look into it
> but it should not be a blocker for this patch review.
> May be we should add a ticket to IPA trac this so that we explicitly
> indicate that we can't release if this cherrypy auth issue is not resolved.
>

I've poked at the issue, we'll see what happens. It got a positive 
review but AFAICT needed rebasing and that was never done. Then we'd 
need to see about getting it backported.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-1106-5-rest.patch
Type: text/x-patch
Size: 45662 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140221/4a93ba01/attachment.bin>