[Freeipa-devel] Disabling Schema Compatibility rule

[Alexander Bokovoy]

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
>>>>> older
>>>>> 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
>>>> Compatibility,cn=plugins,cn=config"'
>>>> is our simplest way.
>>>>
>>>> One can create an update file for ipa-ldap-updater, for example:
>>>> --8<--8<--8<--8<--8<--8<--8<--
>>>> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>>> deleteentry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>>> -->8-->8-->8-->8-->8-->8-->8--
>>>>
>>>> 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.
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