On 05/28/2015 01:29 AM, Jan Cholasta wrote:
Dne 27.5.2015 v 15:51 Nathaniel McCallum 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.

As I understand the problem, there is an assumption that an optional
component has a distinct service to start and stop. That is not the
case here. This is just new config for apache.

Nathaniel


I say that's a wrong assumption. It should not matter whether the service is provided by an actual daemon, or a set of daemons or no daemon, as that is an implementation detail. By installing KDC proxy on IPA server an actual new service is provided to the outside world, which is conceptually the same as adding DNS or CA, so I don't see why it should be handled differently.


Depends on if you consider it a different service from Kerberos. It is just a different protocol, and in the HTTP world would have been handled by a content type.

That said, I could see the argument that the proxy is designed primarily to run in the DMZ, not where the IPA server is normally deployed, and the setup of the proxy really should be considered an architectual design decision. Deploying it on the same host as the IPA server doesn't really serve the main use case.


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

Reply via email to