[Freeipa-devel] External plugin integration

[Alexander Bokovoy]

On Fri, 05 Aug 2016, Martin Basti wrote:
>
>
>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?
Because I wanted to unify it with other publicly visible component,
/usr/share/ipa/updates. In updates directory we have update files
following the same pattern, NN-description.update.

Unfortunately, I just realised that extension has probably to be .ldif
for 389-ds to correctly recognize it when files are loaded and upgraded
via 398-ds tools.

I fixed the extension part. Testing the whole setup now.
-- 
/ Alexander Bokovoy