Dne 27.5.2015 v 14:47 Petr Vobornik napsal(a):
On 05/27/2015 01:57 PM, Jan Cholasta wrote:
Dne 27.5.2015 v 13:34 Martin Kosek napsal(a):
On 05/27/2015 01:33 PM, Christian Heimes wrote:
On 2015-05-27 11:59, Martin Kosek wrote:
On 05/27/2015 11:53 AM, Alexander Bokovoy wrote:
On Wed, 27 May 2015, Martin Kosek wrote:
On 05/26/2015 05:40 PM, Jan Cholasta wrote:
Dne 22.5.2015 v 12:24 Christian Heimes napsal(a):
Finally I haven't figured out the best way to configure the
admin should be able to enable / disable KDC proxy. Should I
script or a ipa plugin for the job?
A script, ipa-kdcproxy-install, if you want to be consistent with
I thought we wanted to install it by default and only switch it
configuration in LDAP. In that case, no ipa-*-install should be
As with any other feature which requires configuration of other
components, if it wasn't installed before, you need to make sure
able to configure it over upgraded instance. Not providing
ipa-kdcproxy-install would mean you are not supporting an upgrade
I do not disagree with the approach for optional components. But as
above, this was supposed to be configured everywhere by default -
both on new
and upgraded installations.
It doesn't matter whether it's installed by default or not. This is to
support disabling and enabling the component - "ipa-kdcproxy-install" to
enable, "ipa-kdcproxy-install --uninstall" to disable.
Install/uninstall is not the same thing as enable/disable. Installation
is a set of steps which first configures and then (optionally) enables
The configuration steps exist for the sole purpose of making it possible
to enable the component after they are done. The result of install is
that the component is enabled, and the result of uninstall is that the
component is disabled. So, in a way, they are the same thing.
1. modify configuration file(s), ldap entries
2. run something which starts the component. E.g. `systemctl start xxx`,
an ldap change which is being observed (like topology plugin).
Yes, and this boils down to:
1. enable KDC proxy in LDAP
for KDC proxy.
The only rationale for external tool is to do stuff which can't be done
trough API. E.g. restart of httpd.service or a need of Directory
Manager. But in that case the tool should be:
There is no API for enabling/disabling components, so it can't be done
There is no ipa-ca-manage, ipa-dns-manage or ipa-kra-manage.
AFAIK, it is mostly just one config for Apache and wsgi script.
Yes, it is really just one boolean switch (service enabled/disabled).
The state of the switch is read when Apache is started or reloaded. In
the default state KDC Proxy is enabled. When the service is disabled,
the WSGI script replies with 404 instead. All remaining settings like
kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf.
This is just an implementation detail.
I had both the per-replica and the global switch implemented. After I
discussion with Nathaniel and Martin, it's now a global switch only.
Nathaniel argued, that a global switch is easier to implement as
sufficient for now.
The state of the switch is controlled with ipa config-mod:
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.
Could you be more specific? Is there really *one* way? The only optional
components/functions of IPA server which can be turned on and off while
still being installed are probably Managed Entry plugin(controlled by
ipa-managed-entries) and a Migration mode(controlled in the same fashion
as current proposal).
These are not components, but rather DS "switches".
Other optional components(CA, DNS, KRA) could be just installed later if
they are not installed during server installation. They cannot be
disabled nor uninstalled (KRA is exception, there is also
uninstallation). So they are not the same case.
They can be uninstalled, it's just not implemented yet :-)
The schema changes for the new attribute are handled by
ipa-server-upgrade. The Apache config file is created
ipa-server-install, ipa-replica-install and ipa-server-upgrade.
Thanks. This is all we need for 4.2, IMO.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code