Frontend/Backend Inter-process Communication

Aegir is based on a very important distinction between the "frontend" and the "backend". The frontend is the Drupal website that creates the user interface that people manipulate. The backend is (usually) a set a drush commands that do the actual operations on the backend objects (servers, platforms, sites).

The frontend and backend run as different users: the frontend runs under the webserver user, while the backend run as a separate UNIX user, which we call the backend sandbox. This distinction is important as it brings an extra layer of security. It also allows for commands to be ran on different servers more easily.

The way the frontend communicates to the backend is through the use of "queues", that are actually defined in the frontend (hosting). The frontend also define drush commands that are ran through a cronjob and therefore provide the glue to the backend.

The point of entry is through the "dispatcher" (the hosting-dispatch command), which runs the different queues appropriately. There are different types of queues (see hook_hosting_queues()), but the most important one is the "task" queue, which runs the basic tasks like install and backup.

When tasks are ran, a provision command is called with the same name of the task type defined in the frontend (see drush_hosting_task()). If we are running a special task like install, verify or import, data from the task is actually saved in the backend, through the backend provision-save command. The data saved is from the associative array "context_options", defined from the hook see hook_hosting_TASK_OBJECT_context_options(). A good example of such a variable is the site name or platform it is on, which are obviously saved in the backend.

There is also an "options" array that are just one-time parameters that are not stored in the backend context. A good example of that is the site email address, that is just sent during the install or password resets task but not saved.


Namesort ascending Location Description
_hosting_queue_next_run ./ Calculate the time at which the task queue will run next.
_hosting_queues_clean_output ./
_hosting_dispatch_cmd ./
hosting_task_TASK_TYPE_form_validate task/hosting_task.api.php Validate the form data defined in hosting_task_TASK_TYPE_form().
hosting_task_TASK_TYPE_form task/hosting_task.api.php Add fields to the task confirmation form.
hosting_run_queue ./ Run a queue specified by hook_hosting_queues()
hosting_queues_cron_removal ./ Remove Aegir lines from a crontab.
hosting_queues_cron_cmd ./ Generate a crontab entry.
hosting_get_queues ./ Retrieve a list of queues that need to be dispatched
hostingService_example_basic::context_options example/ Pass values to the provision backend when we call provision-save.
hook_hosting_tasks_alter task/hosting_task.api.php Alter front-end tasks defined by other modules.
hook_hosting_tasks task/hosting_task.api.php Define tasks that can be executed in the front-end.


./, line 8
This file defines an API for defining new queues.