[Freeipa-devel] External plugin integration

[Martin Basti]

On 05.08.2016 13:58, Alexander Bokovoy wrote:
> On Fri, 05 Aug 2016, Martin Basti wrote:
>>
>>
>> On 04.08.2016 17:49, Alexander Bokovoy wrote:
>>> Hi!
>>>
>>> I've stumbled into an interesting problem.
>>>
>>> Suppose, I have a plugin that adds schema and a subtree where 
>>> entries it
>>> manages will be stored. This subtree will have ACIs applied based on 
>>> the
>>> plugin permissions' configuration. Now, I put schema file in
>>> /usr/ipa/share, and updates file in /usr/share/ipa/updates, and also 
>>> add
>>> plugin code to the ipaserver/plugins/ (let's say, rpm does it for me).
>>> Next, I want to install IPA server. The install will run through up to
>>> server upgrade phase which will fail because generation of ACIs will
>>> reference schema attributes/classes which aren't loaded to the 
>>> dirsrv by
>>> installer. How to solve it?
>>> Installer uses hard-coded list of schema files and this is a 
>>> third-party
>>> plugin, it needs to extend the list of active schema files.
>>>
>>> If we can define a place where third-party plugins could drop schema 
>>> and
>>> we just load everything from there before processing updates, it would
>>> probably be enough.
>>>
>>
>> TLDR: you don't without modifications in current IPA code, or it will 
>> be huge hack
> So far all I needed are following modifications which really boil down
> to:
> - introduce /usr/share/ipa/schema.d to hold third-party schema files
> - add support to read the schema files from /usr/share/ipa/schema.d
>   to dsintance upgrade step and to ipa-server-upgrade
>
> That's all. Since I'm adding a new directory, I needed to update
> Makefile.am and install/configure.ac which requires regeneration of
> Makefile/configure files. You'd need to remove install/Makefile and run
> 'make bootstrap-autogen' to make sure the install/Makefile is recreated
> and install/share/schema.d/Makefile is created.
>
>> I think, this is a part of "Support of 3rd party plugins" effort, but 
>> it has not been designed yet. I would like to avoid any ad-hoc solution.
>> Maybe we should create a desing page and gathering requirements, you 
>> have a lot of them already :).
> I'm working on the whole package for FleetCommander integration and I'll
> produce a howto based on it. So far, there was no need to have anything
> dramatic.
>

You introduced a new convention,

+Each schema file should be named NN-description.schema where NN is a 
number 00..90.

Currently all LDAP schema files are *.ldif, why do not stay with this 
naming?

Martin^2