On 05/28/2015 03:06 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 07:42 +0200, Jan Cholasta wrote:
>> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a):
>>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote:
>>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a):
>>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote:
>>>>>>>>      ipa config-mod --enable-kdcproxy=TRUE
>>>>>>>>      ipa config-mod --enable-kdcproxy=FALSE
>>>>>> I don't like this approach, as it is completely inconsistent with
>>>>>> every
>>>>>> other optional component. There should be *one* way to handle them
>>>>>> and
>>>>>> there already is one, no need to reinvent the wheel.
>>>>> Sorry Jan, but this is really the correct approach.
>>>> I don't think so.
>>>>> We want a boolean in LDAP to control whether the IPA Domain allows
>>>>> proxying or not, the code is embedded in the overall framework and has
>>>>> no need for explicit install/uninstall unlike the CA or DNS components.
>>>> There is a boolean for every other component/service as well. If you
>>>> want to add new API to manipulate the boolean, fine, but it should be
>>>> done in a generic way that works for other components as well.
>>> This is the same as:
>>> ipa config-mod --enable-migration=TRUE
>>> Why is it a problem ?
>> This is a switch to enable the migrate-ds plugin. I think it's hardly 
>> fair to compare it to a whole new component which provides a new service 
>> to the outside world.
> Well, this is the problem, I guess there is a perception issue. The KDC
> Proxy is basically nothing more than adding a new protocol to the KDC.
> It doesn't really do anything special but getting packets on HTTPS and
> sending them to the KDC over TCP.
> SO I think that for this specific case the KDC Proxy really is
> comparable to migration mode (actually simpler than migration).
>>> This is not a separate service.
>> How is it not a separate service? If it's installed, MS-KKDCP is 
>> provided to the outside world, and if it's not installed MS-KKDCP is not 
>> provided to the outside world.
> If the migration plugin is installed the service is provided, if it is
> not installed it is not provided, it is conceptually the same. Yes there
> is code involved, but we plan to have the proxy always provided. There
> is no plan to have it as a removable component, you can only enable or
> disable it, like for migration.
>>  How is this different from, say, DNS? 
>> (Besides implementation details, such as what protocols or how many 
>> daemons it uses - think about IPA as a black box for a moment.)
> It is completely different in size and scope, the KDCProxy really is
> just an enabler to reach the KDC over a different protocol, it is not a
> whole new protocol and service.
> In the end it is a matter of perspective, I think most of the people
> that have been dealing with it think it is much like migration and not
> an entire new service like DNS.

In the end, Alexander had a good point that there will be some needed
associated configuration changes in DNS, when the KdcProxy is enabled/disabled:


In which case, we may want to end up with more complicated API/CLI
(ipa-kdcproxy-manage) than just config-mod command. We now mostly settled to
per replica configuration, postponing powerful API/CLI for later:



Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to