On Fri, 04 Mar 2016, Martin Kosek wrote:
On 03/04/2016 12:59 PM, Alexander Bokovoy wrote:
On Fri, 04 Mar 2016, Martin Kosek wrote:
On 03/04/2016 10:10 AM, Alexander Bokovoy wrote:
On Fri, 04 Mar 2016, Martin Kosek wrote:
Hi Alexander and others,

As you know, SSSD 1.13.4 added support of reading the native SUDO tree [1].
This means that FreeIPA deployments with all clients being SSSD 1.13.4 or
will be able to disable the sudoers schema compatiblity tree
(cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config).

Right now, I am only aware of an attribute tu disable the whole Schema Compat
plugin (exposed via ipa-compat-manage tool), but this would not fly for people
with legacy clients reading from Compat tree.

I am thinking, is there an easy way we can recommend to admins on how to do
disable just certain Schema Compatibility rules? Ideally having a config
options something like:

schema-compat-enabled: on|off

That could be changed via ldapmodify.

[1] https://fedorahosted.org/sssd/ticket/1108
There is nothing like that in slapi-nis. If you want to remove container
configuration, you just remove it.

So, doing as DM 'ldapdelete "cn=sudoers,cn=Schema
is our simplest way.

One can create an update file for ipa-ldap-updater, for example:
dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
deleteentry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config

and then run it as ipa-ldap-updater ./89-remove-sudo-compat-tree.update

This is what I was afraid of...

I'm not sure if running server upgrade would not restore the
configuration, though.

I think it would.

On the other hand, if no users are going to use the configuration, it
should not hurt anymore to have it enabled. With current slapi-nis state
there should be no problems anymore.

Well, slapi-nis will still maintain the memory cache, AFAIK.

How difficult would it be to implement

schema-compat-enabled: on|off

? It seems to me as the best way forward.
The attribute itself is not hard to implement. It is much more complex
to ensure the map is ignored if disabled.

Even if we require 389-ds-base restart after this configuration? I would guess
that it should be then easy to simply ignore the disabled rule and do not load 
It is not about restart. slapi-nis has long supported changing
configuration on flight. You don't need to restart 389-ds on removal of
the configuration.

Removing this feature is certainly not welcomed.

My observation about the complexity is basically questioning the need to
do such switch at all -- by working on the switch we are delaying work
on slapi-nis successor.
/ Alexander Bokovoy

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

Reply via email to