[Freeipa-devel] Disabling Schema Compatibility rule

[Martin Kosek]

On 03/04/2016 02:30 PM, Alexander Bokovoy wrote:
> On Fri, 04 Mar 2016, Martin Kosek wrote:
>> On 03/04/2016 01:09 PM, Alexander Bokovoy wrote:
>>> 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.
>>
>> My point is that if we do not have a nice and easy way of disabling the Schema
>> Compat rules, the whole value of not using Schema Compat trees by SSSD is
>> lower, as we cannot save the memory and CPU for 389-ds-base in maintaining this
>> extra trees - right?
>>
>> As you talk about the slapi-nis successor, is there any technical way of a
>> short-term approach that would let us do the proposed, before we get the
>> successor?
> Give me some time to look what I can do.

Thank you. First, we should just assess how much it would cost and that would
enable us compare the costs and benefits and choose to either wait for the
slapi-nis successor or do something now.

Martin