[Freeipa-devel] Client-side command in the IPA framework

[Adam Young]

On 02/28/2014 10:21 AM, Petr Viktorin wrote:
> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote:
>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote:
>>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote:
>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote:
>>>> >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote:
>>>> >> On 28.2.2014 04:02, Rob Crittenden wrote:
>>>> >> > Alexander Bokovoy wrote:
>>>> >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote:
>>>> >> >>> So the recent discussion on importing tokens led me to write a
>>>> script to
>>>> >> >>> parse RFC 6030 xml files into IPA token data. This all works
>>>> well. But
>>>> >> >>> now I need to integrate it into the IPA framework.
>>>> >> >>>
>>>> >> >>> This command will parse one or more xml files, creating a set
>>>> of tokens
>>>> >> >>> to be added. Given that we already have otptoken-add on the
>>>> server-side,
>>>> >> >>> it seems to me that all work needs to be done on the
>>>> client-side. How do
>>>> >> >>> I create a new client-side command that calls existing
>>>> server-side API?
>>>> >> >> subclass from frontend.Local, override run() or forward()
>>>> method and
>>>> >> >> perform batch
>>>> >> >> operation of otptoken_add from there.
>>>> >> >>
>>>> >> >> See cli.help, for example.
>>>> >> >
>>>> >> > If you do an override, do forward() for cli-specific work.
>>>> >> >
>>>> >> > But you should do as little as possible for reasons you already
>>>> stated:
>>>> >> > the UI. Anything you do in forward Petr will need to implement
>>>> in the UI.
>>>> >> >
>>>> >> > Unfortunately we don't yet have a nice way to handle files. We 
>>>> have
>>>> >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and
>>>> >> > https://fedorahosted.org/freeipa/ticket/2933
>>>> >> >
>>>> >> > If this file is something that would be pasted into a big text
>>>> field
>>>> >> > then you can probably handle it in a similarly clumsy way that
>>>> we do
>>>> >> > CSRs in the cert plugin.
>>>> >> >
>>>> >> > rob
>>>> >>
>>>> >> +1 for parsing it on server. Otherwise every client, not just CLI
>>>> or Web
>>>> >> UI, would have to reimplement the same logic - having it on server
>>>> will
>>>> >> support better integration with third party products.
>>>> >>
>>>> >> Parsing on client would be understandable if there was some middle
>>>> step
>>>> >> which would require some action from user, i.e, pick only some
>>>> tokens to
>>>> >> import.
>>>> >
>>>> >If we parse on the server side, how do we handle the long-running
>>>> >operation? Think of the case of importing hundreds or thousands of
>>>> >tokens...
>>>> Why then to do it as a IPA CLI command at all?
>>>> This is an administrative task which can be done with a separate
>>>> ipa-otp-import command, designated to run on IPA masters.
>>>
>>> Agreed.
>>>
>>> 1. Is there a framework for this? Or should it just be an independent
>>> script?
>> We don't really have a framework for administrative tools. You may start
>> with install/tools/ipa-adtrust-install, it is main part is relatively
>> independent of the task (which is in 
>> ipaserver/install/adtrustinstance.py)
>>
>
> The framework is there, new tools use it, and there's a ticket to 
> convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's 
> low priority in Future Releases, so not much progress is there...)
> Also see http://www.freeipa.org/page/V3/Logging_and_output
>
>


The RESTful approach would be:

1. Upload a file to a specific URL (not JSON RPC)
2.  Receive back a 202 Accepted  HTTP Request, to include an URL to poll 
for status

Not certain the right response from the URL in step 2 would be, but I am 
assuming it would be 200 with the body of the message stating: 
processing or completed.

It would be really nice if the Batch command could be handled this way 
as well.  The response back could be the partial responses until 
processing is complete.

It might also be nice to supply an email address for notification of 
completed processing instead of polling, if it is going to be a really 
long running task.