community.aegirproject.org

One of the common tasks available to all three of the major entities in Aegir (Servers, Platforms and Sites) is the Verify task.

You can think of the Verify task as a sort of routine 'sanity check' of that specific entity, with a sort of checklist of expected behaviour with which it runs through to confirm that the entity is operating as normal.

The Verify task also can be used to regularly 'sync' your platform or site with the Aegir package registry, to keep it up to date on whether any modules have changed (been removed or enabled/disabled). This will aid running Migration and Clone tasks, since Aegir needs to have a precise knowledge of what modules, themes or profiles are on the system before it can accurately judge whether an upgrade is possible.

It is recommended to run the Verify task on your entities routinely to keep them in sync with the Aegir database, and to run a Verify of your site, current platform and target platform prior to attempting a Migration or Clone task.

What happens in a Verify task?

1. Servers

   • When you add a new server node in the Aegir frontend, a Verify task is spawned for the first time.
   • the configuration directories are created if they don't exist and set to the correct permissions, or set to the correct permissions if they already existed but were incorrectly set
   • if the server is the master server, some additional configuration and backup directories are created
   • generates or updates a Drush alias file for the server.
   • some configuration directories are synced from the master server to remote servers
   • Checks that new databases and database users can be created
   • Checks that the HTTP web server can be restarted

2. Platforms

   • When you add a new platform node in the Aegir frontend, a Verify task is spawned for the first time.
   • If the platform directory didn't exist on the file system and a Drush makefile was provided, Drush Make will be called to build the platform in that location
   • If the platform directory didn't exist and no Drush makefile was provided, the task will fail with the error 'Does not contain a valid Drupal installation'.
   • Checks that the permissions are correct, at least of the 'sites' folder of the platform directory (so we can create new sites here)
   • Searches for existing sites on the platform that are not yet in the system. These sites will be 'imported' into Aegir.
   • Scans the platform and builds or updates the package registry in the Aegir database.
   • Generates or updates a Drush alias for the platform, and a drushrc.php file in the platform's directory root.
   • Reads in the platform's .htaccess file into a platform-wide web server vhost configuration file.
   • Restart the web server

3. Sites

   • When you add a new site in the Aegir system, an Install task is spawned, This is contrasted with the above entities which spawn only Verify tasks initially.
   • Scans the site and builds or updates the package registry in the Aegir database.
   • Creates important directories in the site folder, such as 'files'. Sets or corrects the appropriate permissions
   • Manages/updates any site aliases (symlinks, redirects etc)
   • Re-generates the settings.php
   • Re-generates the site's web server vhost configuration file
   • Re-generates the site's drushrc.php and a Drush alias
   • Clears caches.

You can run or re-run the Verify task at any time on a server, platform or site, and it is encouraged to do so.

Certain tasks, such as 'deploy' when a site is being imported, automatically imply a verify of the site.

Each Verify task, like all tasks generated by Aegir, emit a 'task log' available for review after the task has completed (or failed).

If a Verify task fails, and the task log does not provide enough information to help you resolve the problem, trying running drush @example.org provision-verify --debug from the command line to find out what caused the problem. Remember to replace 'example.org' with the URL of the site you are trying to verify.

Platforms, like sites, have tasks that can be performed against them, however these tasks are smaller in number and generally more simple.

Some tasks that are available to platforms out of the box are Lock/Unlock and Delete.

Lock

The lock task is simply a conceptual protection placed over a platform so that new sites can't be installed on that platform.

It doesn't actually modify anything on the filesystem or on the platform itself, but merely changes the status of the platform in the Aegir database. Once a platform is considered 'locked', it no longer appears in the New Site form when adding a new site.

You might choose to Lock a platform if there is something wrong with that platform and you want to prevent new sites from being added to it by one of your clients or users, or you want to 'hide' the platform for some other reason (perhaps awaiting a release date before allowing new sites).

Unlock

To unlock a platform that has been locked, simply click the Unlock button and the status of the platform will be switched back to an Enabled state.

Delete

The Delete task is similar to that of sites. The delete button allows you to completely remove a platform from your filesystem irreversibly.

This can be handy if you engage in a build management methodology that involves making regular new platforms to upgrade your site to. It is easy to amass large numbers of platforms on the filesystem, so the Delete task was born to deal with that problem.

A platform can only be deleted if there are no sites currently provisioned on it. The task will fail before deleting anything if it detects that there are sites in the 'sites' directory of that platform.

You must migrate these sites off to a valid new platform before you can delete such a platform.

Unlike site deletions, there is no backup made of a platform (because it's not bootstrappable by Drush), so be careful with this task: there is no going back!

It is recommended to make regular filesystem backups outside of Aegir altogether, and to use the Lock task to temporarily 'disable' a platform from use if you are unsure whether you want to delete it, but don't want it shown on the Aegir frontend.

Manually deleting a platform

Similarily to deleting sites, sometimes something goes wrong during a Delete task and the platform doesn't get completely removed. Often this is caused by permissions problems on the platform (i.e something owned by a different user that the aegir user can't remove).

The Delete task sometimes cannot be re-run in this situation. In which case,:

• Manually remove the platform files on the server if they exist (i.e /var/aegir/drupal-6.19)
• Remove the Drush alias for this platform if it is still present (in /var/aegir/.drush/)
• Remove the platform configuration file from /var/aegir/config/server_master/apache/platform.d (and the same for the other server_ directory if the platform was hosted on a remote webserver)
• Go to e.g. /node/123456/delete in your browser on the Aegir frontend and delete the node. This will remove the platform node and all associated task nodes from the system, as well as remove the entry from the hosting_platform and hosting_context table in the database.

Introduction

Once you understand why Aegir is a great tool for developing and managing Drupal web sites you inevitably start looking for ways to optimize workflow. mig5's article on Drupal deployments and workflows provides great insight on managing platforms, profiles and sites using Aegir, version control and the drush_make project.

The challenge of managing platforms and profiles

Whether you are using Drupal to develop bespoke web sites or vertical web applications with hundreds of instances (sites), it is not uncommon to be managing a mix of platforms and profiles. These comprise community-contributed projects that, in many cases, are frequently updated. To protect the integrity of their platforms developers like to explicitly control which version of which project they use and when. It can be time consuming to keep everything up to date. Many contributed projects are available in versions compatible with multiple Drupal versions so this mix of platforms and profiles can be complex.

Using drush_make to manage common and disparate code bases

One of the really powerful features of drush_make is that it can operate recursively. You invoke the drush make command on a local make file but if drush_make fetches a profile or project that includes another make file then this is parsed and additional packages are fetched.

A typical way that developers leverage this feature is when they want to have some projects available to the entire platform and some that are specific to one or more custom profiles that are part of the platform. They achieve this by including a different make file with each profile repository.

Using make files with profiles works well when you want to manage distinct code bases that are specific to a site running under that profile. Only sites using profile 'foo' can see modules, themes or libraries located in subdirectories of the foo profile's directory. However, using the includes option you can also reference a make file directly using a local path or a URL. The advantage of this is that you can maintain a make file that references the projects you use on every profile on every platform (e.g. views, cck, path etc.).

This is illustrated schematically below:

Example make files

Here are some example make files that illustrate the concepts described above:

<namespace>_<platform₁>.make

<namespace>_<profile₁>.make

<namespace>_<profile₂>.make

<namespace>_base.make

Preview	Attachment	Size
	drush-make-architecture-2011-01-14.png	20.11 KB