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:

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
- 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

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

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to