On Wed, 03 Jun 2015, Endi Sukma Dewata wrote:
On 6/3/2015 1:41 AM, Martin Kosek wrote:
On 06/02/2015 11:22 PM, Alexander Bokovoy wrote:
On Tue, 02 Jun 2015, Endi Sukma Dewata wrote:
I think ideally the
client and server code should be in separate files (so they can be deployed
separately too), but the framework doesn't seem to allow that.
This exactly the case we have to use here and we are using that in
trusts case as well -- some code has to run on server only and shouldn't
cause to install Samba related packages on the client. This is because
IPA client is actually using the same IPA plugins that server uses, to
have access to the API calls metadata and client-side callbacks are
defined in the same place where server-side callbacks are. It is IPA
framework design, so we have to use what we have.
This is planned to be changed BTW, when we start with the "Thin Client" concept
and have different code/plugins for FreeIPA server side and client side.
Is there a ticket for this?
In other words, it is not necessarily an evil under conditions we are
dealing with.
Having to use the same plugins for client and server is a framework
limitation/poor design. Having to use conditional imports to work
around the limitation is a bad programming practice. The fact that
trust plugin has to implement a similar workaround is not a
justification, it just shows that the problem is not vault-specific.
There is another thing. Even when splitting client/server sides, we'll
need to check on the server side that certain functionality is
available. In trust case we have ID Views (a separate plugin) which does
use information about trusts to resolve users from AD to their
normalized references (SIDs) and few other places would be depending on
functionality only provided when Samba packages are installed.
To continue your approach, we would need to split also server-side parts
of plugins into separate callable units that would only be provided and
called when appropriate rpm subpackages are installed. This is unneeded
complication in place where we can simply handle dependencies in run
time and make sure the packaging deps are managed separately.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
