Task Invocation Via LDAP Design


Implementation

cn=tasks The general framework of cn=tasks is laid out in Task Invocation Via LDAP Design so read that first: the general idea is to create a section of the DSE under cn=config where server maintenance tasks can be started. Each task becomes its own entry, and the attributes of the entry track the task’s parameters (for example, the files to import) and running status.

There are five tasks:

The entries under each task share a common base objectClass (to be defined) with the following attributes:

In addition, each task type has its own special attributes (for passing parameters to the task on startup). == cn=import ==

cn=export

cn=backup

cn=restore

cn=index

Backend Implementation Details

When calling the backend db2ldif/ldif2db/etc functions, there’s now a new parameter in the pblock:

Slapi_Task *pb_task;    

which can be pulled by the flag SLAPI_BACKEND_TASK. This parameter will be NULL for tasks that weren’t started via the cn=tasks mechanism. For tasks that were, it will point to a structure containing lots of useful info (defined at the bottom of slapi-plugin.h) like the dn of the task. To update a task’s progress, fill in the fields in the Slapi_Task structure, and then call

void slapi_task_status_changed(Slapi_Task *task);    

which will automatically do the modification of the cn=tasks entry for you. This function also checks the task state (task_state), and if the state is SLAPI_TASK_FINISHED or SLAPI_TASK_CANCELLED, it considers the task done and schedules the cleanup of the task entry (based on the user-supplied ttl).

There are two callback functions in Slapi_Task: cancel() is called if the user asynchronously requests the task to be canceled, and this callback should be set if the task can be canceled. destructor() is called after a task has finished (or aborted) and the user-supplied ttl has expired – it’s meant to be used for cleaning up any allocated memory, and it’s called right before the Slapi_Task structure is deallocated.

Update: Only ldif2db sets any of the state info or calls slapi_task_status_changed(). The other (simpler) tasks are handed a Slapi_Task structure that’s already filled in, and these other tasks only need to call slapi_task_log_notice() or slapi_task_log_status() when they want to log an event or status change. The rest is handled by the frontend.

Last modified on 7 August 2014