[Freeipa-devel] [PATCH] Password vault

[Alexander Bokovoy]

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