On 28.5.2015 11:59, Martin Kosek wrote:
> On 05/28/2015 11:12 AM, Alexander Bokovoy wrote:
>> On Thu, 28 May 2015, Petr Spacek wrote:
>>> On 28.5.2015 07:42, 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.
>>>>> 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. 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.)
>>> I very much agree with Honza - we have per-replica boolean for every service
>>> so there is no reason not to have one for kdc proxy, especially when we
>>> consider future containerization of services.
>> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in
>> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
>> would be accepted, clients will not be assuming all of replicas serve
>> MS-KKDCP proxies so there will not be need to run them everywhere.
>> Rather, only the servers on a network boundary will need to be
>> advertised. This means we'll eventually get per-replica need as well.
>> It is fine to assume right now that all of them are going to run
>> MS-KKDCP proxy but configuration isn't really going to be global.
>> Additionally, ipa-kdcproxy-manage would need to manipulate
>> _kerberos.$DOMAIN URI DNS records too, so there is more than just
>> switching the boolean here.
> I see. My question is - if we go this way, what is then the reasonable subset
> configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
> feature in for 4.2). Is ipa-kdcproxy-manage doable?
> What is the proposed API here?
> ipa-kdcproxy-manage list
> ipa-kdcproxy-manage enable <server>
> ipa-kdcproxy-manage disable <server>

I believe that for 4.2 it is perfectly enough to have per-replica switch in
LDAP (enabled by default) and to provide ldapmodify command in docs. User
interface can be polished later if we get the design right.

Petr^2 Spacek

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

Reply via email to