[Freeipa-devel] Disabling Schema Compatibility rule

[Alexander Bokovoy]

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.
-- 
/ Alexander Bokovoy