Aegir Handbook

Aegir is a set of Drupal modules that helps you maintain your Drupal sites.

What is it?

Aegir is a powerful hosting system that sits alongside a LAMP or LEMP server to create, deploy and manage Drupal sites.

Once Aegir is installed, you can setup a Drupal site in just a few clicks. Aegir creates the web server's site configuration files, the site's database, runs the Drupal installation process and reloads the relevant services, all automatically.

This documentation will help you understand Aegir and how to get it set up and running, as well as how to use it on an ongoing basis.

How does it work?

It does this by providing you with a simple Drupal based hosting frontend or control panel for managing your entire network of websites.

To deploy a new site you simply have to create a new Site node. That site node then provides you with a collection of tasks that can be executed against that site (such as Backup, Restore, Migrate (upgrade), Clone, Disable, Delete, among others).

What is the meaning of Ægir?

In Norse mythology, Ægir was the god of the oceans and if Drupal is a drop of water, Ægir is the deity of large bodies of water.

Another common spelling is "Aegir," which means a tidal wave.

Okay... but how's it pronounced?

Good question! Technically, /ˈaiːjɪr/, but Icelandic phonology is somewhat complicated. The written pronounciation would be something like "ay-eer".

(BTW, most of us at Koumbit pronounce it "eager" in English, and "agir" (to act) in French.)

Where can I learn more?

You're in the right place! Browse the subsections listed in the Notebook sidebar to continue reading our handbook.

Want to extend Aegir or join the development effort? Read our section on Developing for Aegir.

Want to get involved and help improve the project with support, documentation, Q/A, publicity or even just spend some time with our great community? Check out Community Support. Need help? The FAQ is your first point of call.

Levels of access and experience

Every article is tagged with corresponding user level experience or access level required to make use of explained Aegir feature.

Sysadmin level is generally for users with the root access to their server, who are responsible for installation and configuration of entire Aegir system environment.

Hosted level is for users, who are using hosted Aegir version, without access to the server root, with features limited to those allowed by their host, and often with Aegir UI changed/simplified.

Client level is for users who have access to only their sites and not able to manage all Aegir features, accounts or the server/system.

Some topics can include information useful only for Sysadmin level users, while other are useful for all levels. Hosted and Client levels can have further differences. If you are in doubt, please consult your host FAQ pages.

Finally, welcome to our community, and thanks for using Aegir!

Referenced by Last post Author
reshuffled the handbook Sat, 11/27/2010 - 01:10 anarcat

Introduction to Aegir

If you are new to Aegir you may have heard great things about the project but not know about many of the benefits of using it. Here are some - feel free to add to this list.


One of the great architectural features of Drupal is that you can have multiple web sites that share a common platform of modules, themes and other code used to manage content and appearance. If you make a change to the platform (e.g. update a module, change a theme etc.) all sites based on the platform are immediately updated. At the same time, each site has its own database and file system that can be tailored to the specific needs of the site. In addition to the concept of platforms, Drupal lets you create installation profiles. A platform can have one or more profiles which allows you create different sites based on your choice of platform and profile.

Multiple Site Installations

Aegir provides a web interface to define a platform and then create multiple sites based on that platform. Aegir creates the site database, site-specific file folders and the web server files that point browser requests to the right place.

Site Management

Through the Aegir interface you can create backups, restore a specific backup, disable or delete individual sites. Thus Aegir is a very helpful way of tracking and managing lots of sites spread over several platforms. Moreover, you can perform bulk tasks on all sites based on a particular platform.

Site Development

When you are building a platform from scratch or simply extending or upgrading an existing platform, Aegir can significantly speed up development time and minimize impacts to sites in production.

With Aegir you can clone a site to the same or a different platform. So, say you have a number of sites running on a Platform A and you decide to upgrade a platform module but you want to test your sites to make sure they are compatible with the upgrade. Using Aegir you would create another platform, Platform B that is identical except for the module upgrade. Then you can use clone to create a copy of one of your sites from Platform A to Platform B. The database and all your files are copied by Aegir and you can then test your cloned site without worrying that you might impact the existing production site.

Once you are satisfied that your cloned site is working properly you can then migrate one or all of your sites from Platform A to Platform B.

This process can be very useful for building out new platforms, troubleshooting issues etc.

Site Aliasing

Through the Aegir interface you can define aliases for your web sites so that, for example, traffic to and is directed to the same site.

Multiple Servers

The Aegir interface can also be used to manage platforms and web sites on different web servers, which gives you latitude to tailor a hosting architecture to your own needs.

Scheduled Tasks (Cron)

Most Drupal sites rely on recurring scheduled tasks also known as cron jobs to perform operations like checking for updates, cleaning up log files etc. Aegir can be configured to run cron jobs for hosted sites on regular intervals without having to utilitize other tools or configure cron jobs manually on a site-by-site basis.

Operating system support

Aegir is primarily developed on Debian GNU/Linux, but it supports a whole slew of other platforms, Debian packages have been available for that platform for a while and the install instructions have been originally written primarily for Debian.

This page documents Aegir support for various operating system, including specifics on how it is best recommended to install Aegir on those platforms, quirks and problems, packaging issues and coordination.

1. Debian support

1.1. Fully supported

Aegir is fully supported in Debian, with multiple reports of successful installations, both manual and automatic installs and upgrades.

1.2. Packaging complete

Debian packaging is currently done in Koumbit's private repositories, as documented in the install instructions.

Drush is also fully supported in Debian, with regularly Debian packages in unstable, Wheezy, and Squeeze-backports.

Drush make doesn't yet have a Debian package.

To building Debian packages, follow those instructions.

2. Ubuntu support

2.1. Well supported

Because none of the core developpers actually run Ubuntu daily, it is less well supported. But because Ubuntu is actually based on Debian, lots of people are happily running Aegir on Ubuntu without problems.

2.2. Packaging almost complete

Through the Debian packages, packaging is almost complete. The key piece missing is Drush in Ubuntu Maverick and previous versions. See this bug report for more information.

(Ubuntu synced Drush 4.4 in Natty Narwhal 11.04, which should be released by the end of april, but we're still looking for a Ubuntu MOTU to handle the backporting on the Ubuntu side of things.)

There are unofficial install scripts also available for Ubuntu:

3. Arch Linux

3.1. Well supported

Some people definitely run Aegir in Arch Linux, as the manual install process documentation has extensive details of the Arch Linux specific steps.

3.2. No packaging

Unfortunately, no package is available for this platform.

4. CentOS and Redhat-descendants

4.1. Well supported

A few people are running Aegir on RedHat and related operating systems, mostly CentOS. There are a few tricks documented in the manual install process but it's still fairly straightward to install.

4.2. No packaging

Unfortunately, no package is available for this platform, we are looking for volunteers to write a spec file to create RPMs.

5. Gentoo

5.1. Supported

We believe that Aegir works on Gentoo right now, according to this post. Follow the manual install instructions.

5.2. No packaging

No packages are provided on this platform.

6. Mac OS X

6.1. Partially supported

OS X can be difficult for web developers, because it doesn't ship with a good Apache/PHP/MySQL stack and the UNIX internals are a bit awkward. Still, Aegir was originally developed on OS X, so it's perfectly possible to use Aegir on OS X.

6.2. No packaging

There are currently no packages for OS X and none planned. Special instructions are provided for installing on OS X but once it's installed, the usage should be similar to other platforms, including for upgrades.

7. Solaris

7.1. Supported

There are at least two Solaris installs out there, and significant work was done to make sure that Aegir was UNIX-agnostic enough to respect Solaris' idiosyncracies. The manual install instructions include some of those exceptions clearly documented and outline. Because the upgrade can be iffy, it is recommended to upgrade using the full manual install process.

7.2. No packaging

No packages are provided on this platform.

8. FreeBSD

8.1. Supported

We had one report of Aegir being installable on FreeBSD. The pre-requesites have not yet been merged into the main install instructions (see #659024 for followup on that), so you'll need a bit of guesswork.

8.2. No packaging

No packages are provided on this platform, but it should be fairly simple to make a port inspired by the Debian packaging, considering how it currently works.

9. Other platforms

Other platforms are probably supported but those have not been explicitly and clearly documented so they are not yet included here. Feel free to edit this page to add a section for those users!

Project goals



This project is developed using Git. People are free to download the source code for the project (and in fact are required to run it). Git access is available here.

After many discussions with many different developers working in this space, it has become apparent to the developers that many people have developed their own custom set of utilities and scripts to manage many of the issues this project encompasses.

This project aims to be an open framework that will allow us to collaborate on a single set of community developed / maintained utilities, so that the quality and the capabilities will improve for all of us.


This functions on both a developer and a user level.

For the user, the intent is to make the system as simple to install and operate as possible, which means drastically lowering the requirements for installing and getting up and running with the system. To that end the system has an installation script to automate the installation of Aegir, which has developed a long way from a multi-step install.php wizard and even more complex requirements before then.

The system will auto-detect as many of the settings it requires to run as is possible from within the confines of PHP, and will provide detailed and accurate inline documentation on the server configuration required, based on the configured settings.

This system aims to be self documenting, to aid in troubleshooting, in the event that an error occurs. This documentation is both translatable and extendable when new services are enabled.

For developers we aim to keep the implementation simple, clear and concise, and use as few as possible additional requirements outside of Drupal itself. We aim to provide extensive developer documentation, to lower the barrier for people wanting to integrate with the system.

The system will never require any additional core patches for the sake of base functionality. It is a 'contrib' project.

Basically, the aim is to do everything possible to ensure that the user and developer experience is a positive one.


The system aims to help maintain many sites, not just when they are initially installed, but over the entire lifetime of the site.

It is designed to install new sites, provisioning all the required services (such as Apache, Mysql and DNS), with the flexibility to provision additional services (such as Mail, LDAP etc.) through optional contributed modules or features.

It provides the ability to revert back to previous versions of your sites, as well as re-deploy existing sites under different domain names ( copied to These backups will be usable on any system with the provisioning backend installed (such as a developer's machine, or a staging server).

This aspect of the system will also be used to manage upgrades between multiple versions of Drupal, and will allow you to schedule upgrades. It will do its utmost to ensure that your site has been successfully upgraded, and features dependency tracking to keep track of which sites are eligible to be upgraded.

It will provide a mechanism that ensures the cron process is run on all your sites within the specified time frame, and additionally will allow for scheduled backups of all your sites.

Through optional modules it will be able to extract usage statistics from your hosted sites and provide an overview of site usage through the administration interface, it will also be able to keep track of server health and load for each of the configured servers.

These are the stated feature goals, many of these features will not be available in the initial releases, as they are not considered a base requirement.


The system will make sure that it has the least amount of power available to it to accomplish it's task, and will ensure that all file permissions are set to the strictest possible levels they need to be, and that no sensitive information is web accessible.

None of the functionality or code required to accomplish it's tasks will ever be available in the provisioned sites, and the hosting front end itself will make extensive usage of Drupal's access control requirements to ensure that users will not have access to things they are not meant to see.

to be extended


The system functions entirely on the command line, using unix pipes for inter-process communication.

As such, once ssh has been configured for the user the back end script is running as, it will be able to freely communicate with the external server through the only mechanism it knows how (the command line).

As an extension of the backup/restore functionality, you will be able to seamlessly move sites between servers, while providing a redirect to an always accessible site alias for users who have cached dns entries.

You will also be able to change database servers through simply modifying the site record on the user frontend.

to be extended


The system will provide accurate and complete logs of everything that has occurred on the system, as well as feature complete error reporting and notification of all issues that have occurred. It will first verify that it is able to complete the requested task, and then it will verify that the task has been completed successfully, before completing the task.

When an error occurs, it will rollback to its last working state before exiting, so that failures will not negatively affect sites.

All node types in the front end are revision controlled, to allow for complete history of all objects.

to be extended


This system aims to be as flexible as Drupal itself is.

It will provide a complete and useful set of hooks to module developers, for both the front end and the back end, to accomplish whatever tasks they need.

The administration interface will provide complete views support for all data in the site, to allow for custom reporting on your network.

The core node types are all standard Drupal nodes, that can be extended through CCK by the implementor. This could be used for tracking additional client information or additional information on sites.

You will be able to integrate Drupal contributed modules such as Organic Groups or Ecommerce/Ubercart to build support or billing functionality directly into the hosting front end.

The system is completely white boxed, so that it will work with almost any Drupal theme, and as such can have your own corporate identity.

to be extended

Project history

Aegir is a completely new iteration of the original Hostmaster project written by Adrian Rossouw. The original version has been running the hosted service provided at for nearly 4 years, hosting literally thousands of sites, and has been implemented for several large clients. Originally, the system would only manage a single Drupal instance, on a single web server with a single database server, and as the requirements grew (concurrently running multiple versions of Drupal and then needing to manage several servers), it grew considerably in (unplanned) complexity.

There were also non-ideal implementation and licensing issues, such as the choice of Python and PostgreSQL for the backend and not developing the system as an "invite-only" GPL project, which severely limited the number of developers that were attracted to the project. Because of the system requirements, it was also very difficult for new users to install, and had many unnecessary points of failure.

The Aegir hosting system has been designed with all these issues in mind, and the lessons learned have formed the basis of many of the Aegir Project Goals. The code was committed to in november 2007 and has seen multiple production-ready but still "alpha" releases there in the two following years.

  • 0.1 marked the first Drupal 5 and "multi-site" capable version.
  • 0.2 marked the first multi-platform version, which supported upgrades between different Drupal versions
  • 0.3 marked the port of the frontend to Drupal 6

Then in 2009, a major overhaul of the code was performed to provide "multi-server" support, which led to numerous 0.4-alpha releases (about 20) and, around the end of 2009, required the move to git as a version control system even though was still stuck in CVS-land, which meant started hosting the git repositories on their servers.

All this led to, about a year and a half later (early 2011), to the 1.0 release of our beloved platform and the Aegir project migrating back to at last

Aegir now exceeds the capabilities of the original HostMaster system and is in use by numerous real world projects.

Aegir is now supported by, Computer Minds and mig5 and is being used to deploy sites in universities, private companies and non-profits around the world.

On January 8, 2014 the 2.0 release ships with significant stability improvements, Drush 5 and 6 support, subdirectory multisite support, improved nginx support, native views and much, much more.


Table of Contents 
  1. 1. Help!
    1. 1.1. Where can I get help?
    2. 1.2. Can I ask you a question?
    3. 1.3. Who are the Aegir developers?
    4. 1.4. I'd like to help out / become a developer!
  2. 2. Installing Aegir
    1. 2.1. Can I run Aegir on a shared hosting environment?
    2. 2.2. Can I run Aegir on Windows?
    3. 2.3. Can Aegir be installed next to CPanel/Plesk/AlternC/etc?
    4. 2.4. Where can I get support for Barracuda/Octopus Aegir?
    5. 2.5. Do I really need to create an aegir user?
    6. 2.6. Install fails with 'dummy connection failed to fail' on Ubuntu 12.04 LTS!
    7. 2.7. How can I tell what version of Aegir I have installed?
    8. 2.8. After installing Aegir I have two servers listed, is this normal?
    9. 2.9. I followed the installation instructions. What directory holds all of my sites now?
    10. 2.10. I tried to create a site, but the create task failed and retries don't succeed. How do I delete the partially created site and associated Aegir tasks?
  3. 3. Upgrading Aegir
    1. 3.1. What is a patch or 'hotfix', and how can I apply it to fix my site if I can't / don't want to upgrade to HEAD?
    2. 3.2. I upgraded Aegir by mistake, can I downgrade it?
  4. 4. Using Aegir
    1. 4.1. Cron isn't running (scheduled tasks aren't being executed), what do I do?
    2. 4.2. How do I get debug/verbose info from Drush when running the hosting commands?
    3. 4.3. How do I update a site's or platform's modules using Aegir?
    4. 4.4. Is it best to set up sites under aegir as or just as
    5. 4.5. How can I setup a site to use https:// under Aegir?
    6. 4.6. Aegir is not verifying / deleting / migrating my site because of file permission problems.
    7. 4.7. I can verify a platform but Aegir fails to provision a site on it (often OpenAtrium)
    8. 4.8. A platform with an installation profile has verified okay, but Aegir doesn't seem to be able to use the profile
    9. 4.9. I tried to migrate a site, but Aegir incorrectly reported an incompatibility between one or more modules in my source and destination platforms. How do I force Aegir to see that the two platforms are compatible?
    10. 4.10. What about .htaccess settings?
    11. 4.11. I'm using a Git repo for a site, but symlinks make crazy things happen!
    12. 4.12. How can I tell what database name my site is using?
    13. 4.13. Can I use the subdirectory multisite feature of Drupal in Aegir?
    14. 4.14. My cache/performance settings in /admin/settings/performance keep resetting themselves!
    15. 4.15. I get [warn] NameVirtualHost *:80 has no VirtualHosts when I restart Apache
    16. 4.16. I get 'Dummy connection failed to fail' when doing $stuff
    17. 4.17. How do I make custom changes to a site's settings.php?
    18. 4.18. How to migrate site via drush

1. Help!

1.1. Where can I get help?

From the Aegir Handbook (which should be the first place you look) :

The Issue Queue for all the projects that make up Aegir is here:

This is the first place to look - chances are someone's had the same problem as you before, and you'll get the quickest answers by searching for what they discovered.

Before asking a question or reporting an issue, you should read the bug reporting guidelines.

You can join the #aegir channel at Freenode on IRC. (IRC instructions for drupal users are at: It's a friendly community, but a small one, so ask nicely and be patient!

If you find a solution to a problem that isn't in the documentation or in this FAQ, be the first to login and edit these pages to bring them up to date! The rest of the community thrives on your helpful information!

1.2. Can I ask you a question?

Of course you can! Don't ask to ask, just ask! It is polite to look if the question has already been answered in the documentation, the issue queue or here, but if not, please do ask around! If you ask a question and we have a nice answer, you can even add it to the FAQ here so that others can have your valuable answer.

1.3. Who are the Aegir developers?

The Aegir core developers are listed on the Aegir maintainers page.

1.4. I'd like to help out / become a developer!

We love people who want to help and get involved! We even made a page for you to read.

2. Installing Aegir

2.1. Can I run Aegir on a shared hosting environment?

Shared hosting will not give you enough permissions to install new sites. Toughen up, read some Linux beginners tutorials and buy a cheap VPS which will do nicely.

2.2. Can I run Aegir on Windows?

To install Aegir you need a unix based operating system (for details see: Aegir will not work on Windows and there are no plans to add support for it.

2.3. Can Aegir be installed next to CPanel/Plesk/AlternC/etc?

No, or rather "it's not supported". See

2.4. Where can I get support for Barracuda/Octopus Aegir?

Barracuda/Octopus are custom scripts for Aegir that install or set up various things that Aegir doesn't do out of the box. This is a custom solution tailored to Nginx systems, provided by and is not officially supported by the core Aegir project or team. For help or more information, please visit BOA Group, Barracuda and Octopus project pages / issue queue on

2.5. Do I really need to create an aegir user?

If you have a UNIX system, you already have a user. It just needs to not be root for safety reasons. But you don't really have to create a user.

2.6. Install fails with 'dummy connection failed to fail' on Ubuntu 12.04 LTS!

Ubuntu 12.04, by default, installs an insecure MySQL server configuration that allows anonymous users to login without a password. This must be rectified by running 'mysql_secure_installation' before attempting to apt-get install Aegir.

Please see this step in the Install Documentation and this other FAQ item.

2.7. How can I tell what version of Aegir I have installed?

This works for version 1.1 and above . . . maybe earlier too . . . .

grep '[hostmaster][download][tag]' /var/aegir/.drush/provision/aegir.make

Also, if you have drush installed someplace other than in /var/aegir/.drush, then you should grep the aegir.make file in the directory tree where you have drush installed. For example, on Ubuntu, apt-get may install drush in /usr/share/drush/. So, the file to be grep'd would be /usr/share/drush/commands/provision/aegir.make.

If you're still unsure or this didn't work, contact a developer on IRC and we'll be able to tell you after you answer a few questions.

2.8. After installing Aegir I have two servers listed, is this normal?

Yes. By default, after installing Aegir, a server node is created that represents your webserver. This also generates the 'server_master' Drush alias on your system. The second server node is called 'localhost' and has your database service attached to it, because by default MySQL listens on localhost and not your webserver's IP (or on all interfaces). This corresponds to the 'server_localhost' Drush alias on your system.

This is normally fine: you want your websites to be serve-able via your web server's IP / all interfaces, and your database server to only listen on localhost.

If you end up creating remote webservers, you'll not be able to have them use databases on this Aegir server is all.

If you know you want to have remote webservers communicate back to the Aegir server as the 'remote database server', you'll need to attach the database service type to the non-localhost server node, comment out bind-address in /etc/mysql/my.cnf and perform the necessary firewall changes to allow remote access to TCP port 3306 on the Aegir server.

But generally its recommended to create remote database servers too (or combine web + db on the one remote server), so this is generally a non-issue, rather than use the original Aegir server as a 'remote' database server for remote web servers.

2.9. I followed the installation instructions. What directory holds all of my sites now?

For a full overview of a typical Aegir filesystem structure, read this.

2.10. I tried to create a site, but the create task failed and retries don't succeed. How do I delete the partially created site and associated Aegir tasks?

See the section 'Manually deleting the site' from the documentation

3. Upgrading Aegir

3.1. What is a patch or 'hotfix', and how can I apply it to fix my site if I can't / don't want to upgrade to HEAD?

Sometimes releases are made and bugs are discovered afterward. We commit fixes for such bugs to HEAD, but HEAD is often volatile and you don't want to use a non-stable release in your environment. Fortunately we do (or should: if it's critical, please ask for a patch otherwise) provide a 'hotfix' or patch for users. A patch means that you can 'patch' your Aegir system to fix the bug without running the risks of using HEAD.

To patch an Aegir component, use the following example, in which we fix the Provision module with an imaginary patch. The same or similar steps apply for Hosting or Hostmaster (though you shouldn't need to patch Hostmaster, you only use it once to install!)

Run the steps as the aegir user.

1) Backup /var/aegir/.drush/provision to somewhere else for safety, such as /tmp/provision

2) Download the patch given in the ticket, to your server. Use wget or a similar useful tool for downloading it over the commandline. You can download the file to anywhere.

3) edit your aegir user's crontab (crontab -e) and comment out the dispatch entry (place a '#' in front of the hosting dispatch cron entry). This is a precautionary step in case you patch the module, something goes wrong and it breaks the module. The hosting dispatch cron might come around and try and run the queue dispatcher and break/complain due to a broken component. If you know what you are doing and are fast enough to fix it, you may skip this.

4) cd /var/aegir/.drush/provision/

5) patch -p0 < /path/to/the/patch/file

6) crontab -e and uncomment the dispatch cron task

If the patch doesn't apply or prompts you to enter the filename to patch, try running patch -p1 instead of -p0 above.

If it still asks for clarification, verify that you are in the top-level directory of the component (in this case, we are inside /var/aegir/.drush/provision)

If it still doesn't work, it might be an unclean patch, and you should make a request in the relevant ticket to be given a cleaner patch to apply.

For more information on patches, please read the Drupal documentation.

3.2. I upgraded Aegir by mistake, can I downgrade it?

Short answer: no, that would be crazy.

Long answer: well... maybe. Actually, yes. But it could destroy your house, your cat, your life insurance and certainly give you headaches. We will tell you anyways because we're nice.

This assumes you have a backup from before the upgrade. We will be deploying that backup, so understand that you will loose any changes done on the frontend since the upgrade was performed (or more precisely, since that backup was done). That's the way Drupal works, you can't downgrade Drupal, and we're just cheating by restoring a previous backup.

So first, delete that frontend site:

drush @hostmaster provision-delete

This is not absolutely mandatory, but you should make a backup, and deleting the site does that, plus it's important to cleanup after ourselves. We can use the backup to restore to that upgraded version if we give up on the downgrade.

Then remove the Debian packages (if you installed through those, if not, you're on your own: but you need to at least remove the provision code):

apt-get purge aegir2 aegir2-provision aegir2-hostmaster

This may also be:

apt-get purge aegir2 aegir-provision2 aegir-hostmaster2

Depending on the release candidate you installed.

Next, you install the old provision, but only that - don't go around installing the frontend just yet because you will have an empty site to overwrite.

apt-get install aegir-provision

Then you need to edit the @hostmaster alias to point to the old platform, which supposedly exists (if not, you're in trouble: create it by hand or something).

(Alternatively, you could install aegir-hostmaster, which would create you the alias, but this could fail exactly because the alias already exists. Just edit the alias already.)

So you need to change three parameters:

  'platform' => '@platform_hostmaster6x1x',
  'root' => '/var/aegir/hostmaster-6.x-1.x',
  'site_path' => '/var/aegir/hostmaster-6.x-1.x/sites/',

Then you can deploy your backup on that platform:

drush @hostmaster provision-deploy $PWD/backups/

From there the frontend should be back. Maybe. Probably. Well, the purge earlier may have killed the aegir.conf symlink, so if you want to test the frontend right now, restore that. Otherwise, be bold and upgrade to the latest 1.x release using the debian packages, which should restore everything you need:

apt-get install aegir

This should perform an upgrade from your older 1.x release to (for example here) 1.11.

If it doesn't work, sorry, i told you it could break. :)

4. Using Aegir

4.1. Cron isn't running (scheduled tasks aren't being executed), what do I do?

If you're using Aegir 2.x ensure the "Task queue" feature is activated. To do so go to /admin/hosting/queues check "Task queue". Click on "Save changes" button. With default settings the item(s) in the queue will be process in roughly 1 min.

Below are other options to resolve that issue

At the shell prompt as the aegir user, type

crontab -e

a) If you get an error that the command is not found, then you need to install cron on your server (some basic images don't include it - Linode's Ubuntu 9.04 image is one):

sudo apt-get install cron
Now go back to the directory /var/aegir/drupal-6.19 and re-execute the hosting dispatch:
/var/aegir/drush/drush.php @hostmaster hosting-setup
Type 'crontab -e' again.

b) You should see the default entry:

*/1 * * * * (php  '/<path to drush>/drush.php' @hostmaster hosting-dispatch

But if this is still not working it may well be a permissions issue. An example error :

Forking : (php /<path to drush>/drush.php  --quiet @hostmaster  'hosting' 'task' '266' --backend &) > /dev/null [0.432 sec]                [notice]
sh: /dev/null: Permission denied

This means the system doesn't have permissions to access /dev/null. To resolve it, give the system permissions to write to /dev/null (it should have this anyway), by executing:

sudo chmod a+w /dev/null

c) If this still hasn't worked, have you moved the location of drush? If so - see

d) If you are a *BSD user (verified on freebsd at least) You need to add the line : PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin at the TOP of your cron file. Simply log in as the aegir user and type crontab -e and insert the above line on top. Thanks goes to mauror for

e) When cron for your sites stops working, it is possible that for some reason (system overload, broken site, timeout etc), Aegir failed to release a sites cron semaphore. To release it, use this simple recipe:

$ su -s /bin/bash - aegir
$ cd /path/to/hostmaster/sites/domain
$ drush vdel hosting_queue_cron_running -y

4.2. How do I get debug/verbose info from Drush when running the hosting commands?

Add these to the drush call :


If you're having specific problems when using the frontend, you can easily run the hosting commands from the command line by:

  1. Click the view button and then copy the Drush command which was executed at the top of the log;
  2. While logged in as the aegir user, paste the command in at the terminal and replace --backend with --debug at the end of the commandline.

4.3. How do I update a site's or platform's modules using Aegir?

Aegir isn't a package management GUI for installing modules or themes on your site.

It's designed to help manage your site between builds. To upgrade sites, you should be using the Migrate tool to move your site between two platforms, which invokes drush updatedb.

If you aren't ready for this paradigm, and are frustrated that Aegir isn't some GUI for wildly updating or installing new modules with no regards for rollback or dealing with when it will inevitably break your site, Aegir is probably not for you.

4.4. Is it best to set up sites under aegir as or just as

Aegir supports either method and can even automatically create whichever one you didn't use as the main site name. Read more about Aliases and this feature in our documentation.

4.5. How can I setup a site to use https:// under Aegir?

Aegir ships with an experimental SSL feature, but currently doesn't provide any means of managing SSL certificates.

You can follow the ongoing SSL work here.

In the meantime, to set up SSL with basic self-signed certs, follow our documentation.

4.6. Aegir is not verifying / deleting / migrating my site because of file permission problems.

Aegir releases prior to 0.3 RC3 encountered an error when the web server has uploaded files and made new directory in the sites/$url/files directory. A prevalent example of this occurring is with the color module and when imagecache is used (such as in atrium).

This bug (see: #203204 ) was introduced with Drupal 6, and has since been fixed with Drupal 7. The patch has however not been backported yet, and the patch won't fix existing files that were created incorrectly.

In Aegir 0.3 RC3 we introduced a work around which sets the umask for the site, which forces new files and directories to be the correct permissions, but this will only take effect after the site has been succesfully verified. To enforce the correct file ownership and permissions on the files, run the following command on each of your Drupal 6 platforms :

  sudo chown -R $aegir_user $platform/sites/*/files

This will allow the verify task to correctly set the permissions and succesfully modify/remove the files.

4.7. I can verify a platform but Aegir fails to provision a site on it (often OpenAtrium)

A premature failure of a site install with an unhelpful message such as 'The external command could not be executed due to an application error' often, but not always, means your php-cli's memory_limit is set too low.

To confirm that this is an issue, try running drush provision-verify --debug from the command line to find out what caused the problem. Remember to replace '' with the URL of the site you are trying to verify.

Raise your memory_limit in your php cli php.ini file to something like 128MB, or maybe 64MB if that's too much. On Debian-based distributions this is /etc/php5/cli/php.ini. Apache does not need a restart for this: installations fail because the command is being executed via drush using php cli.

This is a common issue for OpenAtrium as it requires more memory to run its install profile as it has a lot more to do than a regular Drupal install.

4.8. A platform with an installation profile has verified okay, but Aegir doesn't seem to be able to use the profile

Your platform has been setup and verified okay, but when you go to create a new site Aegir keeps giving an error message about the profile, or the list doesn't offer you the profile you're expecting. This could be a namespace issue. Modules, themes and profiles in Drupal all have a machine name - which is essentially their folder name. This is also used to prefix their functions etc, so that there are no clashes. What isn't often recognised or well documented is that Drupal has a single namespace for all items - so your themes, modules and install profiles can't have the same name as each other. Often an installation profile will be created called 'OpenPotato' and the theme for it will also be called 'OpenPotato'. This makes Drupal unhappy, and when Drupal's unhappy Aegir's unhappy. We don't want that, but it isn't Aegir's fault, it's the developer's limited or lack of understanding of this Drupal caveat. The easiest thing is to name your installation profile directory 'OpenPotato_install' and name the profile file 'OpenPotato_install.profile'. You'll also need to rename the functions inside this file. Then everything should work just fine.

4.9. I tried to migrate a site, but Aegir incorrectly reported an incompatibility between one or more modules in my source and destination platforms. How do I force Aegir to see that the two platforms are compatible?

This problem can arise for at least two different reasons. First, you may have updated a module in a platform that you imported and forgotten to run update.php before you imported the site into Aegir. Second, you may have updated a module in a platform and not re-verified the platform in Aegir. Be sure that you have run update.php on a drupal platform that you will be importing into Aegir before you import. Also, if you make any change to the modules in an Aegir Platform, re-verify that platform and all sites using that platform. (At least, experience suggests that doing these things will allow the migration to succeed.

4.10. What about .htaccess settings?

As of recent 0.4 alpha releases, Aegir now reads in the contents of a platform's .htaccess file when generating the Apache configurations. You can safely make additions/changes to the platform .htaccess and expect the relevant site to respect those changes.

If you're symlinking an entire /sites/ folder, Aegir may not acknowledge the site, as this will cause problems when cloning/migrating a site.

If you are using Git to version control your themes, custom modules, etc, and symlinking these into your sites folder, you will find that cloning a site will clone those symlinks (by virtue of copying the sites folder). This is probably not what you want to happen!

Themes and custom modules are better off being checked out to or symlinked into the install profile folder. If your site's install profile is 'foobar' (there's an 'install_profile' variable in the variables table), Drupal core understands to look inside the /var/aegir/yourplatform/profiles/foobar/ folder for modules and themes directories.

The files directory for uploads (which I don't think can be efficiently versioned anyway in most cases) and the settings.php file will be all that's left in your sites folder, and Aegir will happily move that all around as you clone or migrate your site between platforms.

Storing your site's dir in git is an archaic and inefficient method of developing sites. It's 2010 and there are more elegant ways of doing things thanks to Drush Make and Aegir. You might like to look at mig5's excellent article where he provides some great tips on how to manage Drupal deployments & workflows with version control, drush_make, and Aegir.

4.12. How can I tell what database name my site is using?

Check the site's vhost configuration file in /var/aegir/config/server_$whatever/apache/vhost.d/. The db name (and user/password) are stored as 'SetEnv' parameters to Apache, allowing us to cloak database credentials in the settings.php so that they are protected in a multisite environment from prying eyes (admins with PHP filter permissions).

You can also use 'drush st' on your site to get a status report containing the database name, user, password, among other things.

In modern releases (0.4-alpha9 or so and above), the site database names have switched from site_$nid style names to more properly reflect the site name/URL itself.

4.13. Can I use the subdirectory multisite feature of Drupal in Aegir?

Also known as "" and "" are different sites.

Short answer: not yet - at least not natively. (see the 'aegir_subfolders' experimental extension)

Long answer: this is currently not supported, because multiple sites usually end up sharing the same virtual host entry in the webserver and you will be required to upgrade/migrate all of the sites simultaneously. That is because /site1 is on the same drupal root as /site2. Another problem is that they can't be on separate servers...

To fix this, you would need to decouple virtual hosts and sites in Aegir, which is a fairly deeply rooted assumption. It would be possible to use Aliases to work around that and have the sites be in different document roots.

But even if you actually coerce Aegir into having multiple sites in the same domain, you get into crazy namespace issues. Do you want to allow the site on to completely break sites or If so, who can? The same client? The same user? If not, you need to implement checks so there's no overlap...

Tools shouldn't dictate policy, people should. Therefore, this should probably be allowed, from a strictly technical perspective.

The thing is: domain names are cheap, contrary to common opinion. You only have to get one domain and you can have as many sub-domains as you want. Hell, you can even have sub sub domains and have your whole domain tree down there, you're free to go. Providers often give out a free DNS namespace to their customers based on their username (full disclosure: Koumbit does :P).

The other thing is: /site1 is exactly what drupal does: ot dispatches menus callbacks based those GET URLs. So trying to make Aegir (or Apache + Drupal, rather) do that is rather backward. On the other hand, Drupal is notoriously bad (if you make exception of the Domain module) at dispatching requests based on domains, and that's where Apache, DNS, Aegir and all their happy friends gets in.

In short, it's been very low priority for the use cases of the development team so far. If developers step up or if funding is provided, this could very well be part of a future release. See this feature request for followup:

Also see an extension for Aegir, written by mig5, called 'aegir_subfolders', which works (mostly)

4.14. My cache/performance settings in /admin/settings/performance keep resetting themselves!

Some values such as $conf['cache'] are hardcoded in the site's settings.php, which Aegir generates. This prevents some settings from being changed in the admin interface.

You can change the value of cache, and other variables, by creating a brand new file called 'local.settings.php' inside your site directory (e.g, alongside the settings.php). Put any value you want in it, e.g:

$conf['cache'] = 3;

..leave off the closing ?> tag, and this setting will now override all others. Aegir will not edit or remove this file.

4.15. I get [warn] NameVirtualHost *:80 has no VirtualHosts when I restart Apache

This is a harmless warning that Apache throws when you have duplicate 'NameVirtualHost *:80' entries in the Apache config somewhere. It doesn't cause any problem.

Aegir inserts this config line into an Aegir-managed apache config file just to make sure it's there at least once. If it's annoying you and you want to remove this warning, you need to remove the IP address from the server node and verify the server again. Note that this may fail in 2.x if the IP address is used by an SSL certificate yet the SSL certificate is unused. This shouldn't generally happen unless you are running a pre-2.0 release candidate, see #2159265 for details and [/discuss/how-delete-unused-ssl-certificate#comment-2163](this workaround).

4.16. I get 'Dummy connection failed to fail' when doing $stuff

Aegir attempts to make a connection to your database server that is deliberately designed to fail. The intention of this, is to get the 'remote host' of your webserver as seen from the perspective of the database server. This is used to generate appropriate GRANT statements so that your Aegir-managed sites can connect to their appropriate databases.

If you get the message 'Dummy connection failed to fail', this means that Aegir was able to login to your mysql server using username 'intntnllyInvalid' with a null password. This is a security problem on your behalf!

You should secure your MySQL service by running 'mysql_secure_installation' or manually by removing users in your mysql database's User table that don't have a valid password. See for more information.

Alternatively, if your MySQL server is sufficiently secured, there's always a possibility that your MySQL server responded with something Aegir didn't understand. Aegir expects either of these error messages:

Access denied for user(.... etc)

Host (...) is not allowed to connect to (....etc).

If your MySQL server responded with something else, but is secure, please open a bug report.

4.17. How do I make custom changes to a site's settings.php?

Aegir re-generates the settings.php for a site on certain tasks (Verify, Migrate, Backup, Restore, etc). For this reason it is not wise to put custom settings in the settings.php as you will probably lose them.

Instead, create a file 'local.settings.php' alongside your site's settings.php and put your custom changes in there.

If you want to make a change and have it apply to all sites immediately, put that change in /var/aegir/config/includes/

Neither of these files will be overwritten by Aegir on any task. thus preserving your changes.

4.18. How to migrate site via drush

drush provision-migrate '@platform_new_platform_alias'

Then, to update the frontend to reflect the changes:

drush @hostmaster hosting-import ''

Ubercart Integration FAQ

These are frequently asked questions about Aegir Ubercart Integration. For basic install and usage instructions please consult the guide.


Does this module create a site install task after product is purchased?

There may be some adjustment to UI needed to make this clearer, but the short answer is "Yes".

This is done conditionally: The module adds a checkbox saying "Create my site later" to the purchase form displayed on a product, if that product has the site feature. If that checbox is checked, then we go right to payment completion, and the client will create their site later using the regular aegir interface.

If that checkbox is not checked, we throw the user into a site creation form, store the data they input, and then use it on payment completion to create the site.

Regardless of whether or not they enter their site info during ordering, their client's quota is incremented.

In the case of a product kit with multiple sites included, only the first site can be created in this manner.

Case Studies

Case studies are intended to help explain the utility of Aegir by showcasing its use in some real-world example.

Pagebuild Case Study
Pagebuild allows non technical users to build websites very quickly and easily. It was built on top of Drupal, with the idea behind it being to provide an editing interface that is so simple, even an adult could use it. This is a explanation of what we did and how we went about doing it (and why).

Wikipedia Article


Feel free to enhance and improve!

Getting Help

Need help with Aegir? Documentation just not covering it?

We recommend you run through the following in this order:

  1. Read the FAQ to check that your problem isn't answered there or that there isn't a workaround
  2. Review these tips on configuring Aegir, Drush, Apache and more, and avoid common mistakes.
  3. Search this site to see if your problem or question has already been addressed.
  4. Look at the current issues for all of the Aegir-related issue queues to see if the bug has already been reported.
  5. Ask the community for help (but see below for good hints on how to make this work better!)
  6. If you think you have found a a bug report or support request, head over to the bug reporting guidelines
  7. If you've exhausted all these avenues and still haven't been able to resolve your issue, or otherwise want some professional assistance, you may want to refer to our Aegir Service Provider Directory

Asking for help

If you need help from the community, you're going to have a lot more success by helping the community help you. Just saying "it doesn't work" or "it's broken" will not help us help you. When you ask for help or report a bug, please include the following information:

  • if the install failed, try the install again with the --debug flag on the hostmaster-install command, or with the DEBUG=yes environment set before running apt-get install
  • if a task failed, include a copy-paste of the complete task log, properly formatted (between <code> tags)
  • in any case, explain what you are trying to do clearly, what are the expected results and the actual results and how to reproduce your issue
  • give as much details as you can: the version of your operating system, the version of Aegir, drush and Drush make you are using, the version of Apache or Nginx you are running, which servers or platforms you are using, etc

For more information about how to ask smart questions, see How To Ask Questions The Smart Way by Eric S. Raymond.

Finally, if you're confused or don't know where to go, you can always come to us! To talk with the community and the developers directly, you can join IRC, discuss site or ask on the mailing lists. See the Community and Support page for more information.

Troubleshooting Aegir


Aegir undergoes rigorous testing, but no actively-developed software ever escapes bugs.

If you feel you have encountered a bug, the FAQ is the first place to check if there's a simple solution.

Common installation and configuration errors

Aegir is a more complex product than your average Drupal site. Something that has far-reaching control over bits of your server and your sites results in more bits and pieces working together, and inevitably it becomes possible to misconfigure, break, or miss setting up any one of these components.

The installation and upgrade procedure has evolved from these pains to becoming something almost purely automated. Nonetheless, making a mistake during the installation of Aegir or Drush is still easy to do, and these tips identify the most common mistakes.

If Something Goes Wrong

If an installation fails partway, particularly while using the script, you may not be able to run it successfully until you've rolled back any changes that the script has made. Delete the contents of the /var/aegir directory (not the directory itself) making sure to remove any hidden directories like /var/aegir/.drush. Also, drop any new MySQL database (which will be named according to the hostmaster domain name).

The Aegir User

Make sure you have an aegir user (who we call the Aegir User) and that the Aegir User is properly configured on your server.

Typing 'id aegir' on your system should print something like this as output.

aegir:~# id aegir
uid=104(aegir) gid=108(aegir) groups=108(aegir),33(www-data)

If you don't want to use a user called 'aegir' for the installation, that's possible (albeit not recommended). Be cautious about using a different username, and do not use an existing user or a user that will have any other role on the server. The Aegir User has certain privileges and should only be used for Aegir activities.

Aegir User's home directory

Verify the Aegir install directory is the user's home. In a standard installation, the Aegir directory is /var/aegir.

Be cautious about installing Aegir in a different directory - it is easy to get confused since nearly all the documentation tries to be consistent by assuming you have used /var/aegir and you'll otherwise constantly have to translate this mentally when trying to learn.

Aegir User as script user

Make sure that the 'Server' node in your Aegir system (this is usually the node located at /node/2) lists the 'Script User' as being your Aegir User. You can also find this node by clicking on the Servers menu tab and then clicking on the server URI shown in the list that appears of Aegir-managed servers. In a basic installation, there is only one server.

Do not run as root

Do not run aegir as root! It's an unsafe and unsupported configuration that is known to cause problems.


A standard Aegir installation will check that Drush is functioning properly, or if it doesn't find Drush at all, will install it for you.

Always run drush as your aegir user, and never as "root".


Make sure that the Provision module is in the aegir/.drush/provision/ directory. A standard Aegir installation will install this for you.


Aegir uses the 'root' user of the MySQL server to create and manage databases. If MySQL is running on the same server, Aegir will still attempt to connect to the database as if remotely. If the MySQL server is security hardened to prevent this type of access, this would result in MySQL errors during Aegir installation.

To see the root users. Connect to MySQL database and run the query

SELECT user, host, password FROM mysql.user WHERE user = 'root';

There should be separate records for the host localhost and hostname, and the password hashes should be the same to avoid confusion. If the password hashes are different, which is possible if the root user password has been updated with mysqladmin, you can make the passwords consistent by running:

UPDATE user SET Password=PASSWORD('new_password')  WHERE host='hostname' AND user='root';


Make sure the Aegir User can restart Apache without a password and that the corresponding command is defined in your Aegir 'Server' node.

As your Aegir User, run the command shown in the "Restart command" field in your Aegir 'Server' node to ensure that your Aegir User can in fact restart Apache (if not, see the Sudo information below).

On Debian/Ubuntu, the command sudo /usr/sbin/apache2ctl graceful. The command should execute and return without asking for a password when run as the Aegir User.

Make sure Apache can parse its configuration without syntax errors. On Ubuntu, sudo apache2ctl configtest should report "Syntax OK".


Check that the aegir user is in your /etc/sudoers file with the permission to restart Apache. Instructions and an example for doing this are contained in the INSTALL.txt.

On a Linux system, check that /etc/sudoers is chmod 440 (i.e., read only for the file owner and group, which is usually root)

Attempt to run the task queue manually from the command line

php /var/aegir/drush/drush.php @hostmaster hosting-tasks --debug

Run a specific task in the queue from the command line

php /var/aegir/drush/drush.php @hostmaster hosting-task <nid of the task> --debug

Run the 'Cron' queue manually from the command line

php /var/aegir/drush/drush.php @hostmaster hosting-cron --debug

Contact the community

Want to talk with the Aegir community? There are many channels with various virtues.

Discussion Forum

The community site has a discussion area that anyone can use to talk about Aegir with others or seek support.


You can join the #aegir channel at Freenode on IRC. There's a loyal community of Aegir developers and users that frequent this channel. Much development discussion also takes place here, and support questions are welcomed.

The core developers also are reachable in #aegir on IRC.

Remember that Aegir, like Drupal, transcends timezones, and even the developers are many hours apart from each other. Sometimes it's quiet, and sometimes it's very busy. Don't repeat yourself: someone will respond eventually if not immediately.

New to IRC? IRC instructions for Drupal users are at:

Mailing Lists

There are mailing lists that can be used for support, general discussion and development or announcements.

  • announce - the announce mailing list is used to announce new releases or major news
  • users - the user mailing list is used for general discussions and support for Aegir users
  • core - the core mailing list is used for internal discussions in the core team


Aegir is often present at many of the popular DrupalCamps and DrupalCons, either as a formal session or in smaller BOF sessions.

We encourage users who are confident in using Aegir to demonstrate it at any relevant events they attend, and to post slides/screencasts so that others can benefit.


As well as the News/Blog area here, the developers also often blog about new Aegir features or share handy tips for the community. Here are two blogs to stay up to date with:

Bug reporting guidelines


Reporting bugs is a great way to contribute to Aegir and it helps all of us (developers and users both) shape Aegir into the fantastic Drupal management system we want and need.

Before reporting bugs

Mis-reporting bugs that are due to not following instructions or skipping steps, not providing enough information or duplicating reports, however, can be a distraction to the development team and waste precious resources. So, help out by following these guidelines for reporting bugs.

Before you report a bug, make sure you have done things right and are sure it's a bug, by reviewing the Getting help section, if only to include the right information in your bug report.

Where to report bugs

Somehow a bug or two may have slipped into Aegir. Eek! So it's really a bug? A new bug? To report it, file an issue on

  • Hosting (if the issue is in the frontend)
  • Provision (if the issue is in the backend) or
  • Hostmaster (if it is in the installer, a documentation bug, or if you don't know where the issue should go).
  • Eldir (if it's an issue with the default Eldir theme that ships with Aegir.)

Feature Requests

Feature requests are, of course, always welcome in these queues as well. To get an idea of where Aegir is headed with new features, you should first consult the Aegir Roadmap and Project Goals - we may be already on it!

How to help?


  • download new release
  • report bugs
  • test existing issues and patches
  • use it! test everything!


Contribute to this handbook and the rest of the community site.

Contributing can mean adding new documentation, or reviewing existing docs to ensure that they haven't become out of date, incorrect or been defaced.



Want to become an Aegir developer?

Submit good patches and review existing ones and we will love you and give you commit access.


See the donation page.

Donate to the Aegir project

We are happy to take donations from users to further development and keep our community site, mailing lists, and Jenkins CI server running. Note that you can also talk with existing service providers if you have the budget to further specific functionalities, but otherwise a small (or big!) donation is always appreciated and will make sure we have funds to operate the infrastructure for the project or maybe even pay people for development work.

Help us work on one of these goals:

  • The next 7.x-3.x maintenance release
  • The next 6.x-2.x maintenance release
  • Hosting Drupal 8 sites
  • Extending Aegir with new features

You can make this happen.

Financial support can greatly accelerate our development efforts. The core team needs your help to keep this going.

You can make this happen! Can you spare $5?

  via paypal

Gratipay (formerly Gittip) logoGratipay (formerly Gittip) has a team for Aegir

The small core team that works on Aegir does this mostly because they use it themselves. That however does not cover all the time we work on Aegir.
Our passion to produce a good product, and love for Drupal, drives us to keep working on this, but there is a risk of developer burnout.
For example: supporting older versions and making upgrade paths user-friendly is a lot of work. While the core team has only limited personal need for this.
Donations validate more time being spent on this.

Please contact one of the service providers if you're looking for paid support.

Aegir Service Providers

Here is a list of consulting and hosting firms offering paid support for the Aegir Hosting System:

Koumbit Networks
Koumbit's team includes several of Aegir's core maintainers and contributors; including, among others, Anarcat, the project lead, as well as developers of several contributed projects. Koumbit manages one of the largest Aegir deployments, hosting hundreds of custom developed websites, as well as being one of the first providers to automate site ordering and provisioning. Koumbit is a dynamic team of designers, developers and sysadmins, offering support and consulting services from front-end development (design, theming and UI), through e-commerce, complex Drupal site builds and data migrations, to hosting and systems administration. This diversity has allowed Koumbit to develop deep expertise in distributed development best-practices. Koumbit has recently launched AegirVPS services, offering full root/SSH/SFTP access to robust virtual servers with Aegir pre-installed, maintained and supported. offers dedicated Aegir hosting service since July 2009, using custom developed, high performance cloud servers configuration. Hosted options include SSH and Drush access, with simplified Aegir interface. supports also remote Aegir installations and maintenance on Client's servers. Simplified and optimized for single server installations system configuration is open-sourced since 2009 and available as a dual-core Barracuda and Octopus installer.
Praxis Labs Coop

We are a worker's cooperative based in Montreal. We share an interest in web technologies and direct democracy. We've all been working with Drupal and Aegir for many years. One of our founding members (Christopher "ergonlogic" Gervais) is in fact a lead developer of the Aegir project.

We provide Aegir, Drupal and Open Atrium hosting, development, support & consulting.

Praxis is a proud partner of Koumbit networks.

ThinkDrop Consulting
ThinkDrop provides Infrastructure and Architecture consulting for Aegir and Drupal. We are the creators of (DevShop)[], the first open source Drupal Environment Manager, built on Aegir. We have also created a number of other Aegir addons like Aegir Drush Aliases and the Hosting & Provision Solr modules. The ThinkDrop team is Jon Pugh, Kevin LaPalme, and Jacinto Capote
Initfour websolutions
Initfour provides Infrastructure and Architecture consulting for Aegir and Drupal. Internally Aegir is used for hosting managed Drupal sites. Fixing what needs to be fixed, Initfour has worked in many corners of the Drupal/Aegir universe.
On helmo

Shop resources

shop resources

User Manual

This section of the handbook describe how to use Aegir in the day-to-day management of sites and platforms.

Getting to know the interface

So you've installed Aegir, arrived at the home page of your installation and are waiting for the magic to begin. On this page we'll introduce you to Aegir and how easy it is to use.

Get to know the interface


Once you've successfully completed an Aegir installation, you'll be presented with the homepage, titled 'Home'.

In a standard installation there won't be any sites listed here yet, other than the main Aegir site itself, which gets imported into the system during the installation. This is normal - Aegir even recognises itself as a Drupal site on your server, and to a limited degree is capable of 'managing' itself. Skynet is here!

Admin menu

At the very top of the screen you'll see the Admin menu, which you may recognise as a popular contrib module installed on many other sites, perhaps even some of your own.

This gives you access to all the normal Drupal administrative functionality, which is not normally required in everyday Aegir user, but it also does provide you access to the 'Hosting' administrative settings where you can enable features that ship with Aegir and make other configuration changes.

The Eldir theme

The Aegir project ships with a default theme called 'Eldir' which is the classic navy blue, simplistic functional interface consistent with the overall Aegir brand. Eldir has been specifically designed for Aegir - nonetheless it is a Drupal theme like any other.


Eldir has a main content section and a right sidebar. In the sidebar, several blocks are enabled by default.


The first is 'Queues'. Queues are Aegir's method of creating 'tasks' and putting them into a pool for the backend system to execute.

Two types of Queue exist in Aegir, though only one is enabled by default. These are

  • the 'Task' queue (sending tasks to the backend to be executed by the 'aegir' user from the command line, such as installing, deleting, enabling, migrating sites and platforms)
  • the 'Cron' queue, which, when the Cron feature is enabled, runs cron on your site in batches.

The task queue that you'll see upon installation shows all the tasks that Aegir has recently run, or is about to run. It shows the last 5, but there is a link to see the full list of historical tasks.

After installation there will be as many as three tasks in the task queue:

  • a Verify task for the main 'server' node,
  • the Import task of the main Aegir site itself, and
  • the Verify task of the main Aegir 'platform' that hosts the Aegir site.

These tasks are kicked off during the actual Aegir installation.

A task is colored

  • a neutral blue-grey if currently queued but not running yet
  • white with a spinning wheel if currently in the process of being run
  • green if completed successfully
  • red if there was an error

It's worth checking the queues regularly to see that the Task or Cron queues are being run regularly. If not you may have a problem with the cron setup on your server - see the FAQ.


Underneath the Summary is the standard Navigation block in Drupal.


The main content body in the Aegir interface lists

  • your sites when on the frontpage or viewing the 'Sites' tab
  • your platforms when viewing the 'Platforms' tab
  • your servers when viewing the 'Servers' tab

The main content area also is where nodes are viewable or editable, such as viewing more information on a site, platform or server, or editing/creating new entities of these types.


When clicking on a task's 'Run' or 'View' buttons, a modalframe dialog is loaded in the browser. This is to provide a fluid, attractive experience for the user without requiring them to leave the current page or node to perform operations on a site. When the action is performed on the task, the modalframe will close and the user will be returned to the page they were on when they clicked that button.

Your site and Aegir

So, you've provisioned a site using Aegir, and you're poking about looking at the system and what it's done.

A Drupal site managed by Aegir is really mostly the same as any other Drupal site. However, there are a few very minor differences that might surprise or confuse some users.

None of these things adversely affect the running of your site - they are designed to actually make your life even easier.


Aegir installs sites on a platform, which means it places the site directory in /var/aegir/platforms/(yourplatform)/sites/( Many sites can all be installed alongside each other inside a platform's 'sites' directory. This is a standard, built-in Drupal feature known as 'multisite', and it is not unique to Aegir.

Settings.php and cloaked credentials

Within a multisite structure where multiple sites share the same 'Document Root' or codebase on the system, administrative users on sites that have PHP access, are capable of manipulating the server into exposing the database credentials of other sites in that codebase with reasonable ease. This is a pretty serious disclosure of sensitive information, although it is only possible if users have PHP execution privileges. Any multisite installation of Drupal (even without Aegir) has the potential for this to be a problem.

But security is very important to Aegir, and that's why special precautions are enabled by default to avoid this issue.

Essentially, when Aegir installs a site and creates the settings.php for that site, it 'masks' or 'cloaks' the database credentials, replacing them instead with environment variables fetched from the $_SERVER array in PHP.

The credentials are instead set in the site's Apache 'vhost' configuration file, which is stored outside the 'Document Root' or platform codebase, and is therefore safe from prying eyes by administrative users.

Apache/PHP is able to read the environment variables from the vhost and understand the settings.php's mask, allowing your site to work as normal.

If this feature confuses you or is inconvenient, you have a few options available to you:

  • Run Nginx (which doesn't cloak the credentials)
  • Set $options['provision_db_cloaking'] = FALSE; in the site's drushrc.php and then re-Verify the site
  • Stop worrying and enjoy the extra security Aegir provides you

Also note that when you run the Backup task against a site, it actually uncloaks the credentials of the settings.php that it saves in a tarball with the rest of the site. The benefit of this is that you are able to take the backup tarball and deploy it on a non-Aegir server, using standard Drupal, and your settings.php will be in 'normal' Drupal form for that environment. This also makes it easier to 'import' sites from previous-Aegir installations, into new Aegir installations if need be.

'Files' rewrite rule

Everyone knows about the inconvenience of having to place an img src in your node that looks like this:

<img src="/sites/">

If you ever deploy this site under a new URL or for whatever reason this path changes, those images or links will become broken on the site. That's because this information ends up stored in the database, and it can be a pain to fix up.

When you Migrate or Clone a site with Aegir, some paths in the database are automatically updated where they are consistent enough to be able to be scripted by Aegir (such as those in the files table).

However, Aegir can't fix up actual node body content, as that would be risky, and as a rule, Aegir doesn't like tampering that deeply into your data. Aegir exists to help you manage your data, but not manipulate it except where absolutely necessary.

Fortunately, what Aegir can offer is adding a '/files' redirect in the Apache vhost configurations. This pattern-matching rule allows you to enter this into your node instead:

<img src="/files/mycutecat.jpg">

and you can expect that to actually point to the same place. When you clone this site or rename it to a new URL, this path doesn't actually need to change, because the Rewrite rule will be modified to point to the new location, thus avoiding breakages.

It's not perfect, and people are often frustrated with Aegir not 'just fixing' everything like this, despite the fact the above is more than what Drupal does for you out of the box!

Fortunately, it's expected that Drupal 7 will improve this sort of thing altogether and things will hopefully become easier.

The .htaccess

Using a .htaccess with an Allow Override all directive in Apache can be a major performance killer, because it requires Apache to stat each subdirectory of the codebase looking for overrides in .htaccess.

As a result, Aegir disables the reading of the Drupal .htaccess in the runtime environment.

This does not mean that the .htaccess is not needed. Instead, when you run the Verify task against a Platform, the .htaccess is studied by Aegir and its contents are copied into the platform-wide Apache vhost configuration, typically located in /var/aegir/config/server_master/apache/platform.d

Need to make a modification to the .htaccess? Simple: you can simply edit it in-place as you normally would, but you must re-Verify the platform in Aegir afterward, in order for those new or modified settings to be 'loaded in' to the platform vhost file.

The end result is improved performance for your sites, without losing any functionality, as you can still customise the .htaccess to your liking.


Permissions in Aegir generally follow these rules:

  • Everything is owned by aegir:aegir, and the 'other' bit is read-only in most cases
  • Things that need to be written to (uploads) by the web server, have the 'group' bit of 'www-data' (or whatever the relevant user/group is on your system) with the group bit writable
  • Anything that is sensitive information, such as the data in the configuration files, are owned by aegir:aegir or aegir:www-data when the web server needs to read those files, with no read access by the 'other' bit.

The use of the 'aegir' user on the system is vital for normal Aegir functionality, however it can be confusing to users who wish to edit files (say, theme development on a site, or downloading new modules) as a user other than Aegir.

The methodology recommended in these situations is:

  • Add a standard user to your server, say, 'john'
  • Add that 'john' user to the 'aegir' group: adduser john aegir
  • By default, Aegir sets the 'modules', 'themes' and 'libraries' directories so they are aegir:aegir with the group bit writable. This means that any user on the system who is a member of the 'aegir' group, is then able to add, delete, or modify files within those directories.

The drushrc.php

You may have noticed a file called 'drushrc.php' on your system, stored alongside the settings.php of a site (and another in the root-level directory of your platform or Drupal core codebase). What's this about?

The drushrc.php is a file that contains important metadata about your site or platform. The significant portion of the file contains metadata on all 'packages' (modules, themes, install profiles and libraries) in that part of the system, including their version numbers and whether they are actually enabled or not.

This file is generated by Aegir whenever a platform is verified, and whenever a site is installed or verified.

Paradoxically, settings from the existing drushrc.php are able to be 'read in' by Aegir when performing those tasks and many others.

The drushrc.php generally should not be edited unless you know what you're doing. As previously discussed above, some supported configurations such as the disabling of the 'cloaking' of database credentials in a site's settings.php, are able to be set in the drushrc.php to provoke the system into modifying how that site is to be treated.

@TODO: Drush aliases

Installing a new website

Creating a new website using Aegir is really, really easy, and is probably one of the most exciting aspects of Aegir. The very idea of clicking a button and suddenly being able to visit a new site may even be the prospect that drove you to installing Aegir in the first place.

To create a site you must have created a Platform first, which is the codebase, typically a copy of Drupal core, on which to place your new site. Read the Platform documentation if you have not yet completed this stage.

The Site form

Much like your Platform, a site is represented as a node in the Aegir frontend. To create a new site, you must create a new Site node.

The site node is a form requiring various attributes to be filled out in order to accurately advise the Aegir system about what kind of site you wish to create. These fields commonly are:

  • Domain name - the site name. This becomes the title of the node.
  • Client - who is the client or owner of this site. This field really only is relevant if you have enabled the Clients feature to manage segregations of sites between clients.
  • Install Profile - the install profile to use to install this site. This has a dramatic effect on the end result of your site
  • Platform - the platform to install the site on. The list of available platforms is based on what profile you choose above (in other words, which platforms support that install profile. The choice of platform also implies which web server hosts that platform, so this is why 'web server' is not a selectable option in the form.
  • Language - what language install the site with. This is dependent on the profile or platform chosen.
  • Database server - which database server to install the database on.

Below is an example of the site form.

Installing the site

Once you have filled out the site form per your requirements, click Save to submit the form. An 'Install' task is automatically spawned and added to the task queue for the dispatcher to execute.

The backend does the hard work of essentially completing a standard Drupal installation automatically. It creates a database and database user for the site, executes the Drupal installation procedure, populates the database, and generates a web server virtualhost configuration file for the site (Apache or NginX depending on your environment). In the event that the platform is located on a remote web server, the data is synced across from the main Aegir site to the remote server.

Finally, it restarts the HTTP service to load the new site's virtualhost into the HTTP service's runtime environment.

A traditional 'welcome' e-mail containing the one-time login link is sent to the e-mail address of the 'Client' who owns this site. As well as that, the login link is generated and displayed on the new site node view (see below).

As you can see above, the successful installation of the site has provided a series of tasks available to be performed against this site. This task block is similar in appearance to the Task Queue block we previously discussed, but rather than showing a list of tasks either run, queued or processing, it instead displays the list of potential tasks that may be run for this site only.

We will discuss these tasks and more in the following sections.

Site Aliases



Site aliases are helpful if you move content to a new domain, change domain names or simply want to make sure that and take users to the same place. You can implement site aliases with or without redirection. The differences between these two methods and how Aegir handles them is described below.

Enable Alias Support in Aegir

  1. You have to enable alias support in Aegir as it is off by default. Assuming the URL of your Aegir front end is, browse to how to get to the Aegir features page

  2. Check the Site aliasing box how to enable site aliasing on Aegir

  3. Click Save configuration

Global Settings for Aliasing

After you have enabled the site aliasing feature in Aegir you can navigate to (see the menu item that is added under Hosting in the admin menu bar). Here you can set default site alias settings for all of your Aegir-hosted sites.

global site aliasing settings

Site-Specific Settings for Aliasing

You can override the global settings for aliasing by configuring site-specific alias settings either when you create the site or later by editing the site settings.

site-specific aliasing settings

Redirection Option

For users, one of the main differences that occurs when redirection is turned on is that the URL that they enter in the browser address bar changes. This reflects what the server is doing, which is in effect to redirect the request to the same site under the main URL, as opposed to serving the same site from under an alias.

User navigates to with redirection off

aliasing without redirection

User navigates to with redirection on

aliasing with redirection

Aegir alias management under the hood

Aegir primarily manages aliases in the virtual hosts file for each site (e.g. /var/aegir/config/server_master/apache/vhost.d/

When Aliases are in use, the virtual hosts file will have a ServerAlias directive for each site alias:


In addition to the above directives, when redirection is off, Aegir creates a symlink in the platform/sites/ folder for each alias that points to the folder associated with the primary domain

lrwxrwxrwx 1 aegir aegir   15 Oct 31 23:25 ->
7 aegir aegir 4096 Oct 31 23:02
1 aegir aegir   15 Oct 31 23:25 ->

When redirection is enabled, Rewrite directives are added to the virtualhost to send http requests to the primary domain that the aliases are associated with:

RewriteCond %{HTTP_HOST} !^$ [NC]
RewriteRule ^/(.)$$1 [L,R=301]

The symlinks are not required in this case.

Resetting site password


The 'Reset password' task is a simple one: it allows you to generate a new one-time login URL for a site.

The one-time login URL is bound to the account of the admin user (uid 1) of a site. It cannot be used to reset the password of another user on the site.

This can be handy in cases where the password for the admin user of a site has been forgotten. The 'Reset password' task is re-runnable and provides a convenient method of re-gaining access to a website from within Aegir.

In normal situations, viewing a site node shows a 'Go to' clickable link that takes the user to the site in question.

When the Reset password task has been run on a site, the 'Go to' link automatically gets changed to become a 'Login to' link that is the one-time login URL.

Once the one-time login URL has been clicked, this link returns to being a 'Go to' link.

Migrating/upgrading and renaming websites


One of the most powerful features of Aegir is the way it can help you to upgrade large numbers of websites safely.

For example, you may have dozens of sites hosted on a drupal 6.18 codebase. But suddenly the 6.19 release comes out with vital security fixes. Previously you'd have to go to each site, back up the files and database, upload the new codebase, run update.php, check everything worked and then onto the next site.

With Aegir you simply click a button in the frontend and it handles everything. This is called 'migrating' sites in Aegir terminology, because it might be used in more cases than simply upgrading the main codebase. For example you may have different 'platforms' with different mixes of contrib modules and themes and charge clients for tiers of 'basic', 'advanced' and 'gold' packages. When they choose to move from basic to advance, you simply migrate their site.

Other examples of using Migrate include:

  • moving a standard Drupal site to a Pressflow platform for performance enhancements
  • renaming a site (giving it a new URL entirely)
  • the Clone feature (discussed in later chapters) is a subsidiary of Migrate, except it doesn't move but copy the site.

How to migrate a site

Enabling the feature

Aegir version 2.x

  • The "Site migration" feature is enable by default. So you don't have to enable it.

Aegir version 1.x

  • By default, Migrate is not enabled in Aegir after a fresh installation, as it is an optional feature. This means that the 'Migrate' button is not immediately present in the list of available tasks for a site.
  • To enable the Migrate feature, simply go to /admin/hosting/features and check the Migrate feature. Submit the form and then return to the site node, and you'll see that the Migrate task is now available.

Migrating a site - the Migrate form

In the Aegir frontend, click on the website that you want to migrate. As per usual, in the 'Site view' you are presented with some summary information about the site, as well as a list of available tasks. Click the 'Run' button for the 'Migrate' task. A modalframe dialog will appear in your browser.

The Migrate form has several options. These are:

  • Domain name (this is already the domain of the existing site. If you are intending to simply rename the site (give it a new URL altogether), you can simply change this field and leave the target platform be the 'current platform'. This will make the site accessible under the new URL.

  • Platform selection. A radio selection of available platforms on the Aegir system. Certain platforms will be un-selectable. This is because they contain 'Errors' - that is, they contain versions of packages (modules, libraries or themes) that are of an older version than that of the original platform. You cannot upgrade a site to older versions of the same package.

Upgrades, warnings, errors?

What's this about upgrades, warnings and errors on each potential platform to migrate the site to?

Up until now you might be forgiven for thinking that Aegir is simply automating the install of sites and creating Apache vhosts and databases.

The truth is, Aegir actually is a much more advanced tool than that. It keeps a running registry in its database of your Platforms and Sites and what modules, themes, libraries and install profiles are available on platforms and installed on sites.

Not only does it keep track of what these packages are, but it also keeps track of what version of a package is installed (say, Views 6.x-2.11), and whether it is actually an enabled module or not.

The Migrate task, despite its name, is the tool for upgrading your site, because the Migrate code actually invokes the command drush updatedb in the backend, automatically. drush updatedb is the equivalent of running '/update.php' in your browser against your site.

In this way, when the time comes (and it always does) to Migrate your site, Aegir is able to intelligently analyse the available platforms on the system and make a sane judgement on where you can upgrade your site to. The logic is as follows:

  1. Current platform has module X, schema version 6002 and 6003
  2. Site module has module X, schema version 6003 installed
  3. Target platform A has module X, schema version 6002. Site cannot be upgraded to an older schema version. An error.
  4. Target platform B does not have module X at all. Theoretically this is still a possible upgrade, but module X will probably be disabled by Drupal's upgrade logic during the process. This is a warning.
  5. Target platform C has module X, schema version 6003. Site is upgradeable, there is no change.
  6. Target platform D has module X, schema version 6004. Site is upgradeable. There is a module update to be performed.

In the logic laid out above, examples 4, 5 ,6, or platforms B, C and D would be listed as valid target platforms. Target platform D would actually upgrade the site's module to a newer version, which may involve database updates.

To view the schema differences between current and target platforms in this way, click the 'Compare platforms' link against each target platform in the form.

If your intention is to upgrade your site between versions of any package (this can include core or contrib!), you need to make sure the relevant packages are present and up to date on the platform you want to migrate to. Aegir can only try and make this judgement call based on the information you feed into the system by adding and verifying platforms with the correct components.

If you've had to download extra packages to the target platform to make them possible candidates for an upgrade, you may need to visit that platform node in the Aegir frontend, and run the Verify task against the site (this is a re-runnable task). This updates Aegir's registry of information about all the packages on the platform.


Select the relevant target platform and click 'Migrate' to submit the form. The modalframe dialog will close and Aegir will spawn a new Migrate task into the Task queue, and process it on the next cron run.

The process of Migration in the backend occurs automatically, like all Aegir tasks, and is as follows:

  • The site is placed into maintenance or 'site offline mode' as a precaution. Safety first!
  • A 'backup' task is implied silently. The site and its database are backed up into a tarball. Still safety first!
  • Depending on the settings sent to the backend (are we migrating the site under its current name, or just renaming the site, or renaming the site and migrating as well), various metadata regarding the site is updated
  • If we are moving to a new platform (upgrading, not just renaming), the backup tarball that was made earlier, is used in a silent 'provision-deploy' command, which essentially unpacks the tarball into the target platform and creates a new database and database user for the site, importing the database dump that was made in the backup
  • The deploy task above, invokes drush updatedb, effectively upgrading the site by calling all hook_update() functions.
  • Various bits and pieces are fixed up, such as paths to files in the 'files' table of the database.
  • Caches are cleared
  • A verify task is run, settings.php and apache vhost are updated to reflect the new path (new platform) and new database credentials, site gets brought back out of maintenance mode.
  • If all went well and nothing has fatally errored here, we remove the old copy of the site from the previous platform (it wasn't touched til now, other than backing it up)

Potential errors?

If something goes wrong during all this work, the metadata reflecting where the site is located on the system (which platform it is on) and other information is reverted. The task will become 'red' in the task queue, indicating an error.

Aegir will attempt to restore the site's vhost and settings.php to reflect the original platform and database credentials, and bring the site out of maintenance, in an effort to return the site to a state where it was prior to the Migrate.

The user may be requried to manually recover from this error depending on what has occurred. Nonetheless, remember that a backup was made early on, and this can be used to restore the site easily.

Migration Tips

In the context of sites, migration is the task of moving a site from one platform to another. Migration is the Aegir-preferred method for applying updates to modules and certainly to core. In other words, to upgrade core or modules, create a new platform with the upgrades, then migrate sites to the new platform.

Ideally, a migration requires nothing more than a mouse-click on the Migrate button on the Site node in your Aegir for the site you want to migrate. If you've prepared your destination platform properly, a migration will be this simple. Proper preparation, therefore, is vital.

To prepare a new platform to be a destination for migration, consider at least the following:

  • The directory structure for your modules and themes must be the same on the source and destination platforms. For example, if the modules on the source platform are in
    then the destination platform must have its modules also in this directory.
  • You may need to clear the Drupal cache on the source platform to avoid migration errors. Upgrades to Aegir in the future may handle this automatically, so be aware of the version of Aegir you're running and whether it includes upgrades to address this issue.

Renaming the Aegir hostmaster site itself

From :

WARNING: Be sure to have a good backup (which you can restore) before attempting this.

  1. manually edit the crontab for aegir to stop the periodic execution of the command 'hosting-dispatch' (the drush command 'hostmaster-pause' did not exist on my system)
  2. delete the hostmaster site (drush @hostmaster provision-delete)
  3. change the alias (drush provision-save @hostmaster
  4. deploy the backup (drush @hostmaster provision-deploy /var/aegir/backup/
  5. checked that all changes appeared correct - YES
  6. Reneabled the hosting-dispatch task by editing the crontab again
  7. ran a verify task against the new hostmaster site. Noticed that the site is listed on the site page with the old domain name. The verify failed.
  8. Found that the verify task had created a new entry in the hostmaster-6.x-1.7/sites directory for the old domain name. I removed this created directory. I found and edited (using phpMyAdmin) the relevant entries in the node and node revision tables for the hostmaster site to update the domain name (change the title field). The hosting_site_alias table may also need to be updated if you have site aliases.
  9. The verify task also seemed to have regressed the @hostmaster alias file (~/.drush/hostmaster.alias.drushrc.php) as it had the URI and aliases details from the old site back in it. I edited this file to return these items to their new values.
  10. The verify task now completed successfully and all seems to be working correctly.

Cloning sites


Aegir provides an easy method of making entire copies of a site. This includes the actual site files, modules and so on, as well as a copy of the actual database.

This feature is called 'Clone' in Aegir, because it is a method of duplicating a site with a new URL or 'site name'.

The feature is very closely linked to the Migrate feature because it is almost the same, except that rather than move the site, it leaves the existing site in place and just copies it to a new name.

For this reason, enabling the Clone feature also enables the Migrate feature.

Enabling Clone

The Clone feature is disabled by default on a fresh Aegir installation. To enable it, visit /admin/hosting/features in your Aegir frontend, check the 'Clone' box and submit the form.

Now when you visit a site node in your frontend, you'll see there's a 'Clone' button in your list of available tasks for the site.

Cloning a site

To clone a site, simply click the Clone button. A modalframe dialog will appear with a form. If you are familiar with the Migrate feature, you'll likely notice the similarities between the two forms.

The clone form has these options:

  • Domain name - this is the URL for the new site, which must be unique.
  • Platform - this is the target platform to clone the site to. It may be the current platform or a different platform that meets the requirements for hosting this site (has all the correct or newer versions of relevant modules)
  • Database server - this option is only available if you have a remote database server configured, otherwise it is implied.
  • Site aliases - If you have the Site Aliases feature enabled, you are also able to set new Site Aliases for this clone at this point. If the original site also had aliases, you will have to change or remove the aliases that load in this form before you can submit it.

As with the Migrate form, you can view the package comparison table between the current platform of the original site and that of a target platform, by clicking the 'Compare platforms' link. You can only clone a site to another platform if it meets the requirements for successfully hosting that site. In other words, the target platform has to contain the same or newer versions of modules. If the packages are missing on the target platform, those missing modules may be disabled.

Once you have made your selection and submitted the form, a 'Clone' task is spawned and added to the Task queue ready for dispatching.

What Clone does

The Clone task makes the following actions in the system:

  • Makes a backup of the original site. This tarball will be used to 'deploy' a copy of the site
  • Generates a new Drush alias for the new site
  • Deploys the backup tarball to the new location as a new site
  • The new site is imported and verified into the Aegir system, and relevant configurations are saved (HTTP vhost file, etc)

When might I want to use Clone?

Clone can be a very useful tool in a variety of situations. Commonly, people use Clone for:

  • Testing what a 'Migrate' might do to a site, without migrating it. In other words, Clone can be used as a simulation tool to anticipate results of upgrading a site to a new release or build safely.
  • If you have a 'template' site, often with a custom install profile, and anticipate having to generate multiple sites that are very similar, you can use Clone to rapidly do this.
  • Cloning a live site to a 'development' version of a site, especially to a development platform residing on a remote 'development' web server, can be a useful and fast method of working on a site by ensuring the dev environment has the latest database and files from production.

Is there any relationship between the original and cloned site?

Currently there is no real relationship between the original site and any of its clones.

In future, Aegir development is likely to develop natural relationships between these sites, which will allow for 'rules' to be established, for example

  • being able to regularly 're-clone' a site 'over the top' of previously-made clone, or
  • automatically schedule clones after the original site has been migrated (upgraded) to keep a clone 'up to date' with the original.

Other uses may develop in time.

Disabling and Enabling sites


Aegir provides a method for sites to be temporarily 'disabled'. This means preventing all access to a site, but in a way that it can be re-enabled later.

Think of disabling a site in a similar fashion to placing a site under Maintenance mode, but that instead of a 'Site offline' message, a request to the site is redirected to a special page under the main Aegir frontend's URL, and a 'Site disabled' message is shown instead.

Aegir makes no presumptions about why you may wish to disable a site. Use this feature at your own discretion.

How to Disable a site

To disable a site, simply click on the site node in the Aegir frontend. In the list of available tasks for this site, click the 'Disable' button. A modalframe dialog will load, prompting you to confirm if you really wish to disable the site. Confirm and submit the form to spawn a 'Disable' task to the queue to take this site offline.

How to Enable a site

Once your site has been disabled, the list of available tasks has now radically changed in the site node: you now have only the option to Delete the site or Enable it again.

To re-enable a disabled site, simply click Enable. The site will be brought back out of hibernation and become live again.

Disabling before deleting

In Aegir's default configuration, you must first disable a site before you may delete it. This is meant as a precaution - if considering deleting a site, it forces you to think about whether you really want to, before accidentally clicking Delete and irreversibly removing your site.

But don't worry - Aegir always silently makes a backup of the site before disabling (or deleting) a site.

Backup and Restore


The Aegir system provides a convenient method of backing up sites, and restoring sites from those backups.

Like most other Aegir functionality, the Backup feature comes in the form of a task, aptly named 'Backup'. It is one of the core features of Aegir and thus is always available for a site, out of the box.

Backing up a site in Aegir is twofold: the site folder (containing the settings.php, files dir and so on) is added to a tarball along with a database dump of the site and stored in /var/aegir/backups on the master Aegir server.

In the event that the website or database is a remote server, those relevant components are synced down to the master Aegir server to be tarballed up. Only the master Aegir server stores backups of a site. (This is known as a 'spoke' model, as opposed to a 'mesh' or distributed model, and suits the Aegir system at this time).

The tarball generated for a site can be used for a number of things: restoring a site from that backup via the 'Restore' task, or from the command line using the provision-deploy command for advanced users as a method of quickly importing a site onto a system.

Other cases whereby a backup task is generated and its tarball used are when a site is being Migrated (upgraded) or being Cloned as a new site, but that is outside the scope of this chapter.

Backing up

When viewing the site node of a site in the Aegir frontend, click the 'Backup' button in the list of available tasks for this site.

A modalframe dialog appears, prompting for confirmation, as well as providing an editable Description field which you may fill out. This field is optional, designed only to aid you in future if you seek a reason for why a backup was made.

Once the form is submitted, a Backup task is spawned and added to the Task queue for dispatching by the backend.

The full output of a Backup task is viewable in the task log. Extra security precautions are built into Aegir so that the 'mysqldump' command uses file descriptors to hide exposing the database user's password in the running process and output of the task.

Restoring from a backup

Restoring a site from a backup is simple and follows the same pattern as backing up. Simply click the 'Restore' button from the list of available tasks for a site. A modalframe dialog will load, and the form offers a list of radio items. These are the backups that have been made for a site, in the format of 'Date/time - Reason'.

Where no custom reason was given for a backup, the message 'Generated on request' is shown instead.

Choose a backup to restore from and submit the form. A 'Restore' task will be spawned and added to the Task queue for dispatching by the backend.

What happens during a Restore task

The restore process

  • puts the site under 'maintenance mode' temporarily (safety first!)
  • generates a new backup of the site before restoring to it (still safety first!). This new backup will be available in the list of backups if you ever re-run the Restore task, and will carry the description 'Generated before being restored to a previous version'.
  • uses the implied provision-deploy command in the backend to unpack the tarball,
  • create a new database and import the database dump into it,
  • create a new database user,
  • spawn a verify task silently, which will
    • re-write the settings.php,
    • sync the data if necessary to a remote platform,
    • re-generate the web server's vhost configuration file for this site,
    • finally reload the web server

Automatic backups and purge

There are contributed modules that can handle automatic creation and deletion (clean-up / purging) of backups:

Eventually these contributed modules will be incorporated into Aegir core.

It is also easy to set up a cronjob to automatically run backup tasks (that can still be used to restore from) for all your sites. To do this, download and set up mig5's bulk backup script.

Deleting sites


There may come a time when you want to remove a website from your Aegir system and your server altogether. As you'd expect, Aegir handles this for you too. It ships with a 'Delete' task that is capable of removing the site from the Aegir system, as well as carrying out backend tasks to remove the site from the filesystem and web/db servers.

The Aegir frontend is a Drupal site in itself, and sites are represented in that system as nodes. New users that are familiar with Drupal often make the mistake of thinking that the process of deleting a site is like deleting a node in Drupal, and attempt to delete the site node (or are confused by the fact we hide the Delete button for this reason).

This is an incorrect method of deleting a site, and doesn't actually spawn a task to clear away the site from the server at all. Below are the steps to correctly remove a site.

Method 1 (default) - Disable the site first

Part of this confusion can stem from the fact that when viewing a site node in Aegir, the Delete button is not actually present in the list of available tasks by default:

This is because, in the default Aegir configuration, you must run the Disable task against a site before you may Delete it. This logic is in Aegir to help users avoid accidentally deleting a site either by accidentally processing the task (despite having to confirm it first) or to prompt the user to think a little bit more on the decision before irreversibly blowing away the data.

The decision stems from Aegir development policy of being uncomfortable making such risky actions on your data. While it is possible to delete a site, we'd like you to really be sure that's what you want to do.

Once you Disable a site (see the Disable section prior to this chapter), the list of available tasks is modified to only offer an Enable or Delete button. At this point you can run the Delete task and permanently remove your site.

Method 2 (optional) - Delete without Disabling

The first method above is the default Aegir configuration. However, some users might be too confused by the lack of the Delete button altogether, which may not be ideal for your situation.

For this reason, Aegir also provides a configurable setting allowing a site to be Deleted without requiring a Disable first. This option makes the 'Delete' button appear in the list of available tasks, even when a site is currently in an Enabled state.

To activate this setting, visit /admin/hosting/settings on your site and uncheck the checkbox that is titled "Require site to be disabled before deletion".

Re-visit the site node and you'll see that the Delete button is now present and clickable, alongside the Disable button.

The deletion process

When you click Delete and confirm your intentions in the modaldialog that loads, a 'Delete' task is spawned and added to the Task queue to await dispatch by the backend system.

The process runs through a series of steps to remove this site from your server. These are as follows:

  • Make a backup of the site and its database for the last time (safety first, remember!
  • Drops the site database
  • Revokes the GRANT to that database for the database user (effectively deleting the database user)
  • Deletes the site folder and everything inside it, from the platform that the site was hosted on
  • Removes the Drush alias file for the site
  • Removes the site's web server vhost configuration file
  • Reloads the web server
  • Sets the site's status to 'Deleted' in the Aegir system. Note: it does not delete the site node from the Aegir system. This is by design: the site node is retained in the Aegir database for historical purposes (you could customise Aegir by adding the ability to run a report or a View of all deleted historical sites, for example)
  • The deleted status of the site, removes it from the list of sites in the 'Sites' page (and thus front page) of the Aegir system.
  • Historical tasks run on the site remain in the Task queue history.

Manually deleting the site

Sometimes something goes wrong during an Install or a Delete task and a site doesn't install or get deleted successfully. The Delete task cannot be run or re-run on this site because Aegir has no way of knowing just how much of it got deleted (whether the files are still there but not the database, for example). Re-running the Delete task is likely to fail because some of these steps listed above will not exit successfully on completion.

At the time of writing, no task in Aegir exists to 'force' a removal of a site without having to bootstrap it first, so some manual steps are required on your part to remove this site.

  • Manually remove the site files on the server if they exist (i.e /var/aegir/platforms/drupal-6.16/sites/
  • Drop the database and revoke db user privileges associated with this site if it got created before failing (check the vhost configuration file's 'SetEnv' parameters, or the settings.php if the credentials are uncloaked, for the site's database name and user)
  • Manually remove the Apache vhost file for this site if it is still present (in /var/aegir/config/server_master/apache/vhost.d/)
  • Manually remove the Drush alias for this site if it is still present (in /var/aegir/.drush/)
  • Enter the Aegir database from mysql and set the status of the node in the hosting_site table to -2 (deleted). For example, if your site node was nid 83 (the 'Edit' tab of the site node will tell you this), run UPDATE hosting_site SET status = '-2' WHERE nid = 83;
  • Still in the Aegir database, delete the node record in the hosting_context table. For example, if your site node was nid 83 (as above), run DELETE FROM hosting_context WHERE nid = 83;
  • Alternatively, if you want to even remove the node altogether from the system (not recommended), go to /node/83/delete in your browser on the Aegir frontend and delete the node. This will remove the site node and all associated task nodes from the system, as well as remove the entry from the hosting_site table in the database.
  • If you are using the SSL feature and had Encryption enabled for this site, you may also need to manually delete the SSL certificate folder located in /var/aegir/config/ssl.d/[domain of site you are deleting] and/or /var/aegir/config/server_master/ssl.d/[domain of site you are deleting]. Additionally you may also need to delete the entry for the domain you are deleting in the hosting_ssl_cert table of the Aegir database.
  • If you are using the DNS feature you may also need to remove the site's entry in the zone file by running the following command: drush @server_master provision-zone rr-delete sub.domain A
  • If your site has ssl support enabled you also need to remove ssl certificate from database issuing DELETE FROM hosting_ssl_cert WHERE ssl_key = '';
  • Re-verify the Platform node where the Platform is the one where your site was hosted on. This will regenerate some metadata whereby the Platform believed it still had that site contained within it.

If you need to manually remove the site's platform see the instructions here:

Open ID tips and tricks

Allowing multiple people to access User 1

This approach depends on the OpenID Admin module. Here are the drush commands to download and install it, and set an openid access:

drush dl openidadmin
drush en -y openidadmin
drush openid-add 1 https://your.openid.server/your-open-id

This can allow you to simplify development workflow and easily control who has access to User 1, without giving away that account's username and password.

The best recipes for disaster and how to avoid them

This is a short list of all those bad things you should avoid while still learning how to use Aegir system properly, compiled from many real-world issues, so you could enjoy reading about creative ways to destroy your sites or Aegir system instead of experience it.

How to get all kinds of failed migrate or clone tasks?

Very easy. Simply use sites/domain-name/modules space for your code. This will guarantee many half-broken migrations with duplicates of the same site existing in two platforms, with fatal errors because some required include file in some module no longer exists, or not yet exists, as all paths to sites/domain-name/modules change on the fly when either domain-name or platform used changes, so some entries in your site's system table will cause either failed and reverted tasks in Aegir or some nice WSOD, until you will repair registry with

No, really, don't use sites/domain-name/modules for anything and save yourself headaches and frustration.

To help you understand this better, let's quote mig5 - Aegir core developer: "Aegir doesn't track site-specific modules/themes in /sites /$yoursite /(modules|themes) because it's not possible to ever upgrade those modules (they are tarballed up and moved with the site on a Migration). For this reason it's unwise to store site specific modules in this directory as you'll never be able to upgrade them if you do your upgrades properly (via Migrations, to new target platforms). To have site-specific modules not in that directory, you should learn install profiles, and store the modules/themes in /profiles /$yourprofile /(modules|themes) for a site using that install profile. (...) I don't see us ever handling the upgrades of modules in /sites/$site, since that entire dir gets tarballed up and moved across. In fact we made a deliberate design decision to literally ignore those modules in the Aegir package system." We highly recommend to read all comments there. There is also an excellent handbook entry you should read to understand this better.

How to break the site so even the Restore task will not help?

To make that happen you need to forget about correct upgrade workflow and good habits, use Backup task in Aegir to create a pseudo-safe copy of your site, upload new contrib modules to your new platform and then use Migrate task to move/upgrade your site to the new platform. To make it even worse, you could then try to use Restore task if anything went wrong with the migration and this will either fail completely or it will revert your database, but it will leave the site in the new platform – because Restore task will never move the site back to the old platform, so all your previous backups are immediately useless, and you are locked in the new platform without any chance to rollback automatically.

OK, so what is the correct workflow for sites upgrades in Aegir? It highly depends on how you manage your code, but some general rules are always valid and we will list them below:

  1. Create or choose new platform.
  2. Upload all your contrib modules and themes to the new target platform.
  3. Re-verify the target platform in Aegir.
  4. Clone your live site with some working subdomain in the old platform.
  5. Re-verify old platform and also just cloned site.
  6. Migrate cloned site to the new platform.
  7. Check if the cloned site works without any issues.
  8. If the step 7 above works, you can safely migrate also the live site.

Note: if this is a Drupal core version upgrade, it is always better to split the upgrade in two parts: first migrate to the new core, but using the same contrib modules versions, and then migrate to the final target platform with newer contrib modules. This may help if you experience failed upgrades with mysterious errors like "Call to undefined function node_types_rebuild()" without any hint on which module causes the issue.

How to break the site and lock it in the broken state in a one step?

This sounds frightfully, but it is really easy to do. All you need is to skip the steps with creating and testing the site’s clone in the existing platform first and simply use the Clone task to clone the site directly to the new platform. While this appears to be a handy shortcut, it is in fact one of the best recipes for disaster. Why? Because Aegir will not be able to properly check for all possible issues related to the contrib code and db updates to alert you before running the Clone+Migrate task. Yes, this kind of Clone task is in fact Clone and Migrate in a one step. It is very handy, but only when you already tested it with both old and new platform before. To stay safe, just avoid cloning the site to the different platform directly. Instead, clone it first in the existing platform, then migrate to the new platform, and finally re-verify it.

Setting up a Platform


What is a platform anyway?

Platforms are a type of node in Aegir and often the source of confusion for new users. This is because the term or concept isn't really used explicitly outside of Aegir - Aegir is a system that suddenly makes Platforms 'make sense' to have.

The simplest definition of a Platform is a copy of Drupal core. That's really it. When you download a copy of Drupal from, the result is what Aegir thinks of as a 'Platform'. No sites exist on it yet.

Before you can create a site using Aegir, you must first define the Platform. This tells Aegir where to store the site directory, settings.php etc on the system.

In short: first you create a Platform, and a site 'lives' on that platform, in exactly this fashion:

  • drupal-6.19 (Platform)
    • /sites/ (site)

This abstraction is somewhat unique to Aegir in that it opens up a world of new opportunities for you. By managing Platforms or copies of Drupal core, and understanding what sites are on what copy of core, Aegir is capable of moving sites between platforms (which is effectively upgrading a site) - read more about this in Migrating/upgrading and renaming sites.

What else could be considered a platform?

Anything that is more or less a copy of Drupal core is something Aegir considers a 'platform'. This thus includes any Drupal distribution, such as OpenAtrium, Pressflow, Acquia Drupal, OpenPublish, ManagingNews, and so on.

The key difference between such distributions and a standard 'vanilla' copy of Drupal core is that these distributions tend to have * a custom install profile in the /profiles/ directory * a set of contrib or custom developed modules, libraries or themes shipped with the core or profile

If you build a copy of Drupal core and place your custom install profile in /profiles, this could be considered a Platform.

If you place your custom install profile in an existing Platform and re-Verify the Platform, that profile will now be recognised as an option when creating a site on that Platform.

Various 'versions' of Drupal, such as Drupal 5.x, Drupal 6.x or Drupal 7.x, are all considered separate Platforms in Aegir.

Drupal 4.x is not supported in Aegir.

Is this paradigm clear? 'Sites' are managed inside 'Platforms'. 'Platforms' are managed inside 'Servers'. 'Servers' are managed by Aegir. In this sense, Aegir manages all the rest too.

Getting a Platform onto your server

A number of techniques exist to put a platform on a server.


For a standard Drupal platform, the easiest is to simply use drush:

php /var/aegir/drush/drush.php dl drupal-6.19


You can simply use the 'wget' command, for example:

Version control

You could use CVS, eg:

cvs login
cvs co -d aegir/drupal-6.15 -r DRUPAL-6-19 drupal


You could download it on your PC and scp or FTP the files up onto your server.

Drush Make

Drush Make comes installed on your Aegir system by default. You can use Drush Make to 'build' a platform, which does the job of fetching core and any other contributed or custom packages that you specify in a makefile.

You can even specify the URL or path to a makefile in the form you are given when adding a Platform node in the Aegir frontend, and Aegir will execute the Drush Make command in the backend and build it for you!

Explaining how to use Drush Make is outside the scope of this document. Consult the README.txt of Drush Make to learn the makefile syntax, or use a ready-made makefile available from the web. Some distributions such as OpenAtrium provide an example makefile for you to build the distribution with.

Platforms and remote web servers

Aegir has a 'spoke' model when it comes to remote servers, whereby the 'master' Aegir server keeps a copy of all platforms and sites and syncs changes outbound to remote servers that are running those platforms or sites, on tasks such as Verify etc.

Because of this, all platform names and paths must be unique, even across remote servers. This means you cannot have 'Drupal 7.0' in /var/aegir/platforms/drupal-7.0 on both Server A and Server B, because it can only exist once in that location on the master Aegir server. Platforms can't share the same name 'Drupal 7.0' because Aegir uses the platform name to define a 'context' by which it can refer to that server, and there can be no conflicts.

The exception to the unique path rule is when using web clustering (a collection of web servers running a platform), but even then, the platform is attached to the 'cluster' server and so is still 'unique' in this sense, that path cannot be reused for another platform running on another server somewhere else.

So when adding platforms to your filesystem and to Aegir, make sure that the platform is unique in name and path, so that other servers cannot try and use this reserved name/path for other platforms.

More on the platform name space

Migrating a site to a remote server illustrates this name space issue further: as an example; given that an Aegir hostmaster has two directories representing two platforms (and remembering that aegir does not migrate platforms, only sites):


and the remote server also has:


then having aegir hostmaster migrate a site from platform plat-local to plat-remote will result in the site files being:
1. moved from .../plat-local to hostmaster's local .../plat-remote and
2. rsync'd to .../plat-remote on the remote server.

It is important to understand this if you are importing a working Drupal site into Aegir's control and Aegir hostmaster is on a different server from the working Drupal site.

Do I have to have multiple platforms on my Aegir?

No, you can simply have one platform or copy of Drupal core and provision all your sites to sit on the one platform. However, eventually you will want to upgrade your sites to a new copy of Drupal core, and rather than replace your core files in-place, it's recommended to build a new Platform with the newer copy of core, and use the Migrate task to move your sites (upgrade) onto the new code.

Adding the Platform node

Now that you've got your Platform on your server, or you know where and how you're going to do it (say, with Drush Make), it's time to tell Aegir about your new Platform.

To do so, add a new node of type 'Platform' in your Aegir frontend. Typically this is most easily done by visiting Create Content > Platform in the Admin Menu.

The Platform node form has several fields required for giving Aegir information about your platform. These are:

  • Name (a descriptive name for your platform. You very likely want this to be something like "Drupal 6.19".)
  • Publish Path (the path on the filesystem where the platform is, or will be when Drush Make builds it. This must be the absolute path, for instance '/var/aegir/drupal-6.19')
  • Makefile (the path on the filesystem to a makefile that will be used to create the platform.)

Once you have completed entering this information, you can click the Save button. A 'Verify' task will be spawned and added to the Task queue (visible in the right sidebar). The backend will then parse this new platform and build up a registry of information about it, such as what version of Drupal it is, as well as what versions of install profiles, modules and themes are present on that platform.

Certain system configurations, such as Apache configurations similar to the .htaccess file that comes with Drupal, will be written to the filesystem, permissions checked and adjusted where necessary, and services restarted.

Now that you have a platform or codebase that Aegir is aware of, you can now proceed to install or import sites onto that platform!

Verifying servers, platforms and sites


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 provision-verify --debug from the command line to find out what caused the problem. Remember to replace '' with the URL of the site you are trying to verify.

Locking and Deleting platforms


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.


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).


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.


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.

Using drush_make to optimize workflow


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:


core = 6.x
api = 2

; drupal core
projects[drupal][version] = 6.20

; platform projects
projects[webform][vesion] = 3.2
projects[workflow][version] = 1.4
projects[job_scheduler][version] = 1.0-beta3
projects[feeds][version] = 1.0-beta10

; platform theme
projects[acme_theme][type] = "theme"
projects[acme_theme][download][type] = "git"
projects[acme_theme][download][url] = ""
projects[acme_theme][download][branch] = "master"

; profile 1
projects[acme_profile1][type] = "profile"
projects[acme_profile1][download][type] = "git"
projects[acme_profile1][download][url] = ""
projects[acme_profile1][download][branch] = "master"

; profile 2
projects[acme_profile2][type] = "profile"
projects[acme_profile2][download][type] = "git"
projects[acme_profile2][download][url] = ""
projects[acme_profile2][download][branch] = "master"

; base make file
includes[acme_base] = ""

; patches
projects[superfish][patch][] = ""


core = 6.x
api = 2

; ecommerce
projects[ubercart][version] = 2.4


core = 6.x
api = 2

projects[openlayers][version] = 2.x-dev
projects[ldap_integration][version] = 1.0-beta2


core = 6.x
api = 2

; utilities
projects[ctools][version] = 1.8
projects[jquery_ui][version] = 1.4
projects[jquery_update][version] = 2.x-dev
projects[modalframe][version] = 1.7
projects[advanced_help][version] = 1.2
projects[transliteration][version] = 3.0
projects[token][version] = 1.15

; content management
projects[imageapi][version] = 1.9
projects[imagecache][version] = 2.x-dev
projects[cck][version] = 2.9
projects[filefield][version] = 3.9
projects[imagefield][version] = 3.9
projects[diff][version] = 2.1
projects[date][version] = 2.7
projects[calendar][version] = 2.4
projects[views][version] = 3.x-dev
projects[views_slideshow][version] = 2.3
projects[content_profile][version] = 1.0
projects[og][version] = 2.1
projects[node_clone][version] = 1.2
projects[node_export][version] = 2.21
projects[node_import][version] = 1.x-dev
projects[nodequeue][version] = 2.9
projects[noderelationships][version] = 1.6
projects[reverse_node_reference][version] = 1.0
projects[nodereference_views][version] = 1.3
projects[page_title][version] = 2.3
projects[pathauto][version] = 1.5
projects[realname][version] = 1.3

; ui
projects[wysiwyg][version] = 2.2
projects[imce][version] = 2.1
projects[imce_wysiwyg][version] = 1.1

; site administration
projects[admin_menu][version] = 1.6
projects[devel][version] = 1.x-dev
projects[devel_themer][version] = 1.x-dev
projects[globalredirect][version] = 1.x-dev
projects[google_analytics][version] = 2.3
projects[xmlsitemap][version] = 2.0-beta1

; site building
projects[rules][version] = 1.4
projects[features][version] = 1.0
projects[context][version] = 3.0
projects[strongarm][version] = 2.0
projects[purl][version] = 1.0-beta13
projects[spaces][version] = 3.0

; site theming
projects[skinr][version] = 1.6
projects[superfish][version] = 1.6
projects[adaptivetheme][version] = 3.0-rc2

; libraries

; CKEditor
libraries[ckeditor][download][type] = "get"
libraries[ckeditor][download][url] = ""
libraries[ckeditor][directory_name] = "ckeditor"
libraries[ckeditor][destination] = "libraries"

; jquery ui library
libraries[jquery_ui][download][type] = "get"
libraries[jquery_ui][destination] = "modules/jquery_ui"
libraries[jquery_ui][download][url] = ""
libraries[jquery_ui][directory_name] = "jquery.ui"
drush-make-architecture-2011-01-14.png20.11 KB

Client management and access control


@TODO update this, it's been copied directly from GDO without modifications yet.

In some situations you may wish to allow different people access to Aegir, but restrict which sites they can manage.

  • Use Case 1:

    As a developer you may simply wish to segregate your sites in Aegir by different clients for your own internal management reasons.
  • Use Case 2:

    If you have many staff working on different projects, you may wish to issue them with different logins and restrict which sites they can access on the Aegir system.
  • Use Case 3:

    As a drupal hosting company you might allow clients to sign up via your promotional website (using the 'Signup Form' feature in Aegir!), and then have their own account created on Aegir, with their newly provisioned site. They can then login and manage their own upgrades (by migrating to new platforms).

This functionality is provided by the Client feature in Aegir. Here's a brief guide to using it...

1. Enable the Clients Feature

If you didn't enable this feature during installation, you can do so now by choosing the following from the menu bar at the very top of the page: Hosting > Features. On this page, click on 'Experimental' to expand these feature options. You can tick 'Clients' and click on the 'Save Configuration' button.

NOTE: Experimental features are designed to be for developer preview only, although we do have reports of them being successfully used in production environments - but do so at your own risk!

2. Configure the Client Feature Options

From the top admin menu select Hosting>Clients. On this page you can configure how you want this feature to operate, with the following options:

Automatically Create User Accounts for New Clients

If you tick this option, whenever you setup a new Client within Aegir, they will have a drupal user account created for them to be able to access their sites within the Aegir site. You will definitely want to leave this unticked for Use Case 1, perhaps also for Use Case 2, but may want to tick this for Use Case 3.

Send Welcome Mail to New Clients

If this setting is ticked, the client will be sent an email when you create their drupal user account allowing them access to the system. Below this you can configure the email that will be sent.

Create Clients

Creating a new Client on Aegir is as simple as selecting Create Content>Client. Then enter their email address (twice for confirmation), Name and Organization. Now click 'Save'.

Depending on the options you selected above they might also have a user account created for them at this stage by Aegir, and then be emailed with their login details.

Otherwise the Client record will just be stored in the database and you will be able to assign sites to this client in the future.

Adding New Users to a Client

Perhaps you didn't initially allow clients to access their own Client area within Aegir and just kept it for your own internal use, or perhaps you now want to add additional users to a Client on the system.

To do this visit the Client page and select the 'Edit' tab. You'll see a list of allowed users. You can add users to this list by typing their username in the autocomplete field, or you can remove users by tciking the box next to their username and saving the form.

If the user you wish to add doesn't yet have a drupal user account on the Aegir site, you can create one as normal by going to the following on the top admin menu: User Management>Users>Add User. Then you can return to the client page and add their username to give them access to that client's area.

Clients Accessing the System

If you have selected above that new Clients should also have an Aegir account setup for them, then they will be able to access the Aegir site.

Within Aegir they will ONLY be able to see details about their own sites.

Administrator Manual


Aegir is a powerful system that provides you with a lot of opportunities and methods for managing your sites.

These methods come in the form of 'tasks' which can be applied against the various entities that Aegir manages. Such entities include:

  • Servers
  • Platforms
  • Sites

This section 'Using Aegir' outlines all the various tasks you'll likely be performing against these entities and how to get the most out of your Aegir system. In doing so, it also represents the recommended 'best practices' associated with achieving certain results (such as upgrading sites).

This section can be read in any order. Choose a specific activity or task from the table of contents to get started or work your way through all the various tasks at your leisure.

Installation Guide

This page is being moved to

Aegir requires some special permissions to your server in order to automate some configurations. For example, when a new site is installed, the web server will be automatically configured (vhost) and restarted. Therefore Aegir cannot be installed on a shared hosting environment. Consult the system requirements to ensure you meet the necessary requirements.

Automatic or manual install?

The automatic install process through Debian packages is the currently recommended install process on Debian and Ubuntu platforms. It should just be a matter of adding the right sources to your APT repositories and running apt-get install aegir.

The manual install process should take about 15 minutes for trained system administrators, between 30 to 60 minutes for others. The section contains detailed instructions on how to install Aegir manually on supported systems. It is aimed at system administrators and porters that want to control every step of the install process.

To decide which method is the right one, you may also want to review the operating system support page.

We also provide a troubleshooting guide to resolve common installation problems.

Note that, while installing Aegir does change some system configurations, it does only minor changes and keeps all its system configurations in one place so that it is easy to uninstall. It will not remove existing configurations. However, make sure you have backups before installing.

Automatic install and maintenance with Puppet

There is now a Aegir Puppet module that can further automate installation and maintenance of Aegir servers. It defaults to using the Debian packages, and is thus best-suited to Debian and it's derivatives (Ubuntu, Mepis, &.), but also supports (experimental) installation via the manual install process. This currently also only works on Debian, as it follows the documented installation procedure; however, it should be pretty straight-forward to adapt it to other OSes.

Development installs with Vagrant and Aegir-up

If you're installing Aegir for experimental or development purposes, you might be interested in Aegir-up, a Virtualbox/Vagrant-based local virtual machine automation system. It provides a simple method of building a complete Aegir system locally using the Puppet modules, and is, in fact, the primary development platform for them. In addition, you can build a dev version of Aegir from the git repos (with .git directories intact) to make debugging and writing patches and extensions easier.

Related documentation

System Requirements


Note that the following System Requirements are the same for Aegir automatic or manual install

A system capable of running Drupal
The Aegir system is entirely Drupal based, and has the same base requirements that Drupal does (with the exception that it won't run on Windows). See more notes on Unix and LAMP/LEMP requirements below.
Your own server
The low level of access required to be able to configure and run this system is very far beyond what is commonly available to users with shared hosting. A VPS from any popular provider such as Linode, Rackspace, Slicehost, Amazon EC, etc. will do fine. You will need root access to the server and the server needs to be dedicated to Aegir.
A Unix-based operating system
Aegir must run on some flavour of UNIX, because the majority of functionality in this system occurs in the back-end, through command line scripting. There are also several features (such as symlinks), that are not available to users on Windows. There are no plans currently to add Windows support. See the operating system support page for more information.
Web server
You will need at least one dedicated web server, running Apache. We generally work with Apache 2 but we should be compatible with the 1.x series. Aegir also supports the Nginx web server, but requires at least version 0.7.66 or newer. Since Nginx doesn't provide php-cgi or php-fpm (recommended) modules, you will need to install and run php-fpm server separately. You can find useful examples and tips in the third party Barracuda installer available at the barracuda project page.

N.B.: This third party installer is not supported by the core Aegir developers, but you can find helpful community support at the boa group.

PHP 5.2 and 5.3
Aegir depends on Drush 4.x, which requires PHP 5.2 or higher. Aegir 2.x depends on a minimun of Drush 5.10 (though Drush 6 is recommended), which requires PHP 5.3 or higher. You also need to have the command-line version of PHP to run Drush properly, and the MySQL extensions for PHP.

Given that PHP 5.2 has been deprecated since July 2010, we suggest using PHP 5.3 if possible. Note that while Drupal 6.x and above support PHP 5.3, some contributed third-party modules may still have problems with this version. Most often these cause warnings that can be safely ignored. Aegir and Drush themselves have no known outstanding PHP 5.3 compatibility issues, although you could have a lot of warnings in Drupal 6 due to ereg deprecation, see this issue for details. If you need to host Drupal 5.x sites, note that Drupal 5.x is not compatible with PHP 5.3 and above, and most likely never will be. See (amongst other issues) for details. As such, Aegir has dropped support for Drupal 5 in versions 2.0+.

Database server
You will require a database server, obviously. Aegir currently only supports MySQL and MariaDB. It is preferable to use a dedicated (not shared-hosting) server since Aegir will create database users and will require the use of a MySQL root user.
Mail transfer agent
Aegir requires an MTA (Mail Transfer Agent) installed on your webserver in order to be able to install new sites to your new platform. If you don't have an MTA, the site installation will fail with message like "could not send email". Additional messages will show that site has been removed because of this problem. To remedy the situation simply install an MTA like sendmail, postfix, or exim and do the minimal configuration.
Other utilities: sudo, rsync, git and unzip
Aegir installs itself via a Drush Make makefile that downloads via git if you want the bleeding edge code, or via wget if you want the latest official release. If you want the latest development version, and don't have the git program you will need to install it on the server.

The jQueryUI library is used in the Aegir UI, unzip is required to extract it. Sudo is required to allow the aegir user the limited privilege to restart the webserver when required. Rsync is used to sync files to remote servers.

No conflicting Control Panels
Other popular control panels such as Plesk, cPanel etc, are designed to manage all aspects of Apache configuration and other areas that Aegir also is intended to be used for.

Running Aegir alongside such control panels is not supported and very likely may cause you problems or difficulties installing or running Aegir. Filing bug reports that are caused by interference by another control panel will likely be closed unless the problem can be fixed without causing problems for other Aegir users. Proceed at your own risk!

System requirements of popular Drupal distributions
Some Drupal distributions, such as OpenAtrium, are specialized products that may contain unique prerequisites for optimal performance. Such examples may include raising the php-cli program's memory_limit to something higher than 64M.

Please note that this is not a requirement of Aegir but of the distribution you are trying to install a site on. Thus the Aegir documentation may not officially 'require' such performance settings, but be aware that Aegir may report errors if the system was under-resourced to complete such a task.

Automatic install on Debian


These are the installation instructions that are recommended on Debian. Aegir dependencies (Apache, MySQL, PHP...) are also automatically installed. If you are managing the installation from a remote Windows computer, well-known open source tools for this task are for example PuTTY (a SSH client for command line), and WinSCP (a SFTP client with easy text file editing).

If you wish to install Debian packages over an existing manual install, it's possible. See the Debian upgrade procedures.

Debian packages are uploaded to shortly after a release. We eventually want to upload those packages to the official archives, but this will take some adaptation and time to sponsor the packages in.

1. Requirements for automatic install on Debian

Basic Linux system administration skills

Root access to your server

An up-to-date system and applications

Run the following command lines to update your system and applications.

  aptitude update

  aptitude safe-upgrade
A configured Fully Qualified Domain Name (FQDN)

Such as

The hostname returned by the commands hostname -f and uname -a must resolve to the IP address of your server.

After setting up your FQDN you must restart your server with a reboot command so your changes take effect.

Note that newly created domain name usually take 24 to 48 hours to fully start working. This period, called propagation, is the projected length of time it takes for root name servers and cache records across the entire web to be updated with your website's DNS information.

Other System Requirements


2. Adding the project repositories

Use this command to add the Aegir package "Software Source" repository to your system:

echo "deb stable main" | sudo tee -a /etc/apt/sources.list.d/aegir-stable.list

To install a customized Debian package, see the developer instructions for the debian package. Other distributions are available for courageous people that want to try development versions.

2.x note: to install the development version of Aegir, you can use the unstable or stable distribution above.

3. Adding the archive key to your keyring

This repository self-signs packages uploaded to it (and packages uploaded are verified against a whitelist of trusted uploaders) using OpenPGP (GnuPG, to be more precise).

Use these commands to download and add the repository's PGP key, then update the package list on your system:

wget -q -O- | sudo apt-key add -
sudo apt-get update

4. Adding backports for or manually installing Drush

If you are running Debian wheezy or later, or Ubuntu Natty 11.04 or later, you don't need to do anything here. The Drush package you need is available from your distribution's repositories.

If not, you should also configure backports repositories for Drush. Version 4.4 of Drush is now in Debian unstable, wheezy, squeeze-backports and Ubuntu Natty.

1.x note: if you are running Debian Squeeze 6.0 or Debian Squeeze 7.0, add the following line to /etc/apt/sources.list :

You might also have to add a proper Pin-Priority before this works. Create a file called drush containing the following and drop it into /etc/apt/preferences.d:

Package: drush
Pin: release a=squeeze-backports
Pin-Priority: 1001

Alternatively, you could download and install the squeeze-backports package for Drush 4.5 directly from: Then you could install it with:

dpkg -i drush_4.5-2~bpo60+1_all.deb

2.x note: if you are running Debian Squeeze 6.0, to get drush-5.8.x and above, download php-console-table manually and install it

wget ""
dpkg -i php-console-table_1.1.4-1_all.deb

You do not need to edit /etc/apt/sources.list or create /etc/apt/preferences.d/drush

Then run:

sudo apt-get update && sudo apt-get install drush

If you are running Debian lenny 5.0 or Ubuntu Maverick 10.10 or Karmic Koala or earlier, we recommend downloading and installing the Drush package manually. The version of Drush in the Ubuntu Universe repository for these versions of Ubuntu is outdated. If you are using Ubuntu Lucid LTS 10.04, you can install the Drush package manually or instead use Brian Mercer's PPA (Personal Package Archive) using the following command:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:brianmercer/drush

Now run apt-get update again to refresh the apt database.

sudo apt-get update

N.B. Since Aegir 2 requires Drush 5, which in turn requires PHP 5.3+, Drupal 5 sites are not supported in Aegir 2.

5. DNS configuration

Aegir requires a properly configured "FQDN" (Fully Qualified Domain Name) be assigned to the machine. In practice, this means that the hostname returned by the hostname -f and uname -n shell commands should resolve to the IP address for this server, and vice versa, with the resolveip command (included with the mysql-server package).

For Ubuntu, /etc/hosts should have entries that look like:

::1 host ip6-localhost ip6-loopback host localhost host localhost

To set this up in a virtual machine (e.g. Virtualbox), here are the steps:

  1. Create a new VM
  2. Go to settings->network. Enable Adapter 2, and set to "host-only"
  3. Install Ubuntu. Set hostname as FQDN during install
  4. You may need to add the lines `auto eth1` and `iface eth1 inet dhcp` to /etc/network/interfaces

If you have a virtual machine already setup and want to change the FDQN:

  1. change /etc/hostname using: `sudo hostname NEW_NAME`
  2. change /etc/hosts using: `sudo nano /etc/hosts` and change name
  3. reboot and test `hostname -f`, `uname -n`, `resolveip NEW_NAME`, `resolveip IP`
  4. YMMV - Your Mileage May Vary

6. Manual sudo configuration

If you are running Debian squeeze or later, or Ubuntu Lucid 11.04 or later, you don't need to do anything here. The Aegir package configures sudoers automatically.

If not, you will need to manually modify your /etc/sudoers file to add the following line:

echo "aegir ALL=NOPASSWD: /usr/sbin/apache2ctl" | sudo tee -a /etc/sudoers

The line above assumes that you have created a user aegir as specified in the installation instructions.

7. Manual installation of MySQL (on Ubuntu 12.04 LTS)

Please note that Ubuntu 12.04 LTS installs, by default, an insecure MySQL installation that contains an anonymous user grant, allowing anyone to login without a password. This breaks Aegir functionality.

If you are running Ubuntu 12.04, you should install MySQL manually, and then ensure it is installed securely:

sudo apt-get install mysql-server
sudo mysql_secure_installation

When running 'sudo mysql_secure_installation', answer 'Y' to 'Remove anonymous users?'

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
... Success!

Now you can proceed with installing Aegir below.

8. Installing Aegir

To install Aegir version 2, frontend and backend, use the following command:

sudo apt-get install aegir2

2.x note: Aegir version 2 is now stable. Read more at

1.x note: to install Aegir version 1, use sudo apt-get install aegir instead.

If apt-get reports that the aegir packages have unmet dependencies, then make sure that you have installed Drush (as explained above). On a debian system, you can force the install of Drush from the squeeze-backports repository:

sudo apt-get -t squeeze-backports install drush

Then install aegir using the apt-get command above.

This will prompt you for the required information (MySQL password, Postfix configuration...) and go ahead with the install.

During the Postfix configuration, the following options appear: "No configuration, Internet site, Internet with smarthost, Satellite system, Local only". That first text screen only allows to use the tab key to select "OK", and then the enter key to display a second screen where you can select one of the choices. The default is "Internet site", useful in most cases to enable the server to send email messages, for example to the admin.

At the end of the installation, you will receive an email message or, if the user "aegir" has been assigned with a local email account during the installation, the file /var/mail/aegir will contain the message. It will include a one-time login to your new Aegir control panel, that is a URL to copy into your browser so that you can set the password for the "admin" user.

9. Custom Drupal distributions and make files

If you have your own Drupal make file, you can go ahead with the above process, but change the make file to the one you want:

echo debconf aegir/makefile string /var/aegir/makefiles/aegir/aegir-custom.make | debconf-set-selections
apt-get install aegir

This allows you to specify the makefile path for your custom distribution of Aegir. To maintain these customizations, you'll need to ensure you do the same when upgrading.

An example aegir-custom.make file could look like:

core = 6.x
api = 2

includes[aegir] = "/usr/share/drush/commands/provision/aegir.make"

projects[] = module_filter

Note that for this to work, you may need the patch from this issue, allowing drush_make to reference absolute system paths. If drush make --version <= 2.2 you need this patch.

After installing Aegir, you can reinstall the front end (hostmaster), with following commands:

sudo rm -rf /var/aegir/hostmaster-*.*
sudo su -s /bin/sh aegir -c "drush -y hostmaster-install --aegir_db_pass=$DB_PASSWORD --makefile=$MAKEFILE $DOMAIN"
su -s /bin/sh aegir -c "some command" runs some command in the /bin/sh shell as user aegir. sudo runs the su command as root - prompting for your user's password instead su asking for aegir's password.

10. Troubleshooting the install

To make the install smoother, the install command is run without much debugging information, which can make diagnostics pretty hard. For this, there's a special environment variable you can set that will trigger debugging output. Install aegir with this*:

env DPKG_DEBUG=developer apt-get install aegir

You can build your own Debian packages from our repositories using those instructions.

Note: Prior to 1.1-4. the command was env DEBUG=yes apt-get install aegir

Automatic Installation on Ubuntu 11.04+ (QuickStart)

Here are simplified instructions for installing Aegir on a server, quickly and easily.

The fastest way to install Aegir is on the latest Ubuntu Server LTS (Long Term Support). Currently 12.04.

Command Summary

Here is every command, ready to copy and paste.

sudo su
echo "deb stable main" | tee -a /etc/apt/sources.list.d/aegir-stable.list
wget -q -O- | apt-key add -
apt-get update
apt-get install aegir

It is highly recommended to read through the Installation Instructions step by step to give yourself the feel for how this is done. In addition, if you are not already familiar in Linux system administration, please read up on the subject. Standard linux security protocols should be followed.

Installation Instructions

Enter all commands in code boxes exactly as they are written.

ALL commands should be entered as root user until these instructions are complete. After that, you should never have to use the root user.

Self-installation of Ubuntu has you create an additional user in the admin group, which means they can sudo. If you are using a cloud hosting service, it likely just sent you root user credentials. Server security and user management is up to you. Don't give away access to root or the aegir user unless you know what you are doing. Follow standard web host best practices

For a summary of all needed commands, scroll to the bottom of the page.

  1. Fire up a new server

    • Use Ubuntu 11.04 Server Edition for the smoothest and most reliable installation experience.
    • Make sure it has at least 1024MB, preferably 2048MB of memory. Depending on your host you will have to configure a hostname. It can be convenient to call this 'aegir'.
    • If you want the smoothest installation, create a brand new server. There will be the least chance of conflicts if you start with a brand new Ubuntu 11.04 server. If you use Ubuntu Desktop, you should be able follow these instructions without any problems.
    • Run all commands as root. If you are not root, enter
      sudo su
  2. Add the project repositories and archive key

    Use this command to add the Aegir package "Software Source" repository to your system:

    echo "deb stable main" | tee -a /etc/apt/sources.list.d/aegir-stable.list
    Use this command to add the archive key to your keyring:
    wget -q -O- | apt-key add -
    Then, finally, update your apt repositories:
    apt-get update

  3. Install configure Aegir and dependencies

    Once you have added the repositories, you can now fire off the standard debian installation command. For Aegir 1.x, the command is:

    apt-get install aegir
    For Aegir 2.x, the command is:
    apt-get install aegir2
    This fires off the installation script for AEgir, along all dependencies including Apache, MySQ and PHP. You will be asked a number of questions about your server.

    • You will be asked to create a MySQL root user password. Make this long and random and type it down somewhere safe, you won't need it very often, but you will need it later on in the installation process.
    • In Postfix Configuration: Choose Internet Site, unless you have a reason otherwise. When asked for the System mail name, pick either the hostname (default) or the domain name you will be hosting this server on.
    • In Configure aegir-hostmaster, you will be asked to choose a "URL of the hostmaster frontend". This should be either the hostname (default) or the domain name the server will be hosting, with "aegir" as a subdomain. For example, "". You may want to change this to whatever you prefer, just don't forget it as it will be where you use the Aegir front-end.
    • After entering your domain, Aegir Hostmaster installation will ask you for the MySQL root password you created earlier. You did write it down, didn't you?
      NOTE: The current DEB package requires you to enter the MySQL root password twice. When this script is done, if everything went ok, after a lot of other interesting information, you should see this:
      Aegir is now installed. You can visit it at http://test/user/reset/1/1329504351/eda205d9a27abde400a27cf160dff69a
      frontend bootstrap correctly, operation was a success!
      Setting up aegir (1.6-1) ...
      Setting up libhtml-template-perl (2.9-2) ...
      Setting up mysql-server (5.1.54-1ubuntu4) ...
      Setting up php5 (5.3.5-1ubuntu7.7) ...
      Processing triggers for libc-bin ...
      ldconfig deferred processing now taking place

    At this point, everything is installed. Visit the link the script provided you to check out the frontend. Switch to the aegir user to check out the backend:

    su - aegir

    Once you are the aegir user, check out the drush site aliases it gives you. @hostmaster is the alias for the new front-end you created. You will get new site aliases for every platform and site you create.

    drush site-aliases

  4. Give yourself access to the server

    As the "Administrators Manual" can tell you, you should only manage the Aegir server from the backend as the aegir user.

    However, by default, the aegir user cannot sudo (except to restart apache). The aegir user also does not have a password. Therefor, the only way to become aegir is to sudo su - aegir from a user that can.

    So, to finish the server, you should give yourself a personal account that you can use to login to the server with a password in case all of your SSH keys get lost.

    To add yourself as a user:

    adduser yourname
    Then fill out the little wizard it gives you.

    //@TODO: Add some helpful notes about SSH keys and remote aliases.

    Install SSH on your server, generating your SSH keys and install them on your Ubuntu server. (Directions to generate your SSH keys are assuming your PC is Ubuntu as well, Windows users look below for SSH directions)

    If using Windows, you must use Putty, PuttyGen, and PuttyPageant to generate and use your SSH keys.

    You will want to also be a part of the aegir and www-data groups so you can write to some of their files:

    addgroup yourname aegir
    addgroup yourname www-data

  5. Start Using!

    Now that aegir is installed, head to the User Manual page to get your first platform and site up and running.


This document was originally based on but has been trimmed down to list only the steps you need to use on an Ubuntu server to get Aegir up and running as quickly and easily as possible.

Manual Installation


This page describes to process you need to follow if Aegir doesn't have packages for your distribution. We currently provide Debian packages and others should be coming, if you help! This manual assumes you are fairly familiar with the UNIX commandline interface, but should be possible to follow through if you copy and paste faithfully all steps of the procedure.

A note on supported systems

These instructions provide example commands for a Debian-like distribution, but should be fairly easy to adapt to other environments. This document is meant as a canonical reference that should work on every supported platform. It can also be used for people porting Aegir to new platforms or installing on alien platform for which Aegir is not yet packaged.

It currently contains special recommendations for CentOS, RHEL 6, Arch Linux and Solaris. Users of those platforms are also strongly encouraged to review the common installation problems that occur on those platforms. Aegir is also known to be installable (and was developed partly on) Mac OS X, but that process is so obtuse that it has a separate page for the first part of the manual (up to Install Aegir components).

Installing Aegir may seem daunting at first (which is why we provide automated installs through packages), but once you get around it, it's fairly simple. It follows those steps:

Note that these instructions setup a complete Aegir system. If you want to only setup a new remote web/db server, it should be sufficient to install the system requirements (step 1), configure them (step 2) and follow the Remote server how-to.

1. Review System Requirements


2. Install system requirements

To install the required components, run the following command as root:

apt-get install apache2 php5 php5-cli php5-gd php5-mysql php-pear postfix sudo rsync git-core unzip

Note: replace apache2 with nginx php5-fpm to install nginx on Ubuntu Precise or newer. Since Debian Squeeze doesn't provide php5-fpm, you will need to follow before you will be able to install php5-fpm.

2.1. CentOS-specific configuration

yum install httpd php php-mysql php-cli php-gd php-process sudo rsync git postfix

For versions of CentOS previous to 6.0, you will need to upgrade to PHP 5.3 using those instructions.

Also for Centos minimal you should install cron (for queue and drupal cron) and unzip (for jquery.ui)

yum install cronie unzip

2.2. RHEL 6 specific configuration

RHEL 6 Server needs an additional PHP package to enable POSIX support. To find the package php-process you must enable the RHEL Server Optional channel. Once enabled, download and install the php-process-5.3.2-6.el6_0.1.i686.rpm.

You will also need to install the php-xml package if you are planning to use Aegir to manage Drupal 7 sites.

2.3. Solaris specific configuration

Solaris has this way of dealing with third party software that is... far from ideal. You will need to find the best way to install the following packages: apache2, git, sudo, mysql, PHP 5.2 and wget. unzip and sendmail should be part of the base Solaris install. The other applications should be available on the companion CDs or on

In particular, git can be compiled easily by exporting the following environment::

export CFLAGS="-I/usr/sfw/include -I/opt/sfw/include"
export LD_LIBRARY_PATH="/usr/sfw/lib:/opt/sfw/lib:$LD_LIBRARY_PATH"

Then the compile instructions bundled with git should just be followed directly. I had trouble installing the binaries, as git expects ginstall to be available in the $PATH. I ended up adding the source directory in the $PATH, which works fine for most uses.

2.4. Arch Linux specific configuration

To install the required components, run the following command as root:

pacman -S apache php php-apache php-gd mysql postfix sudo rsync unzip git

Although all of the necessary apache modules and php extensions are installed at this stage, further configuration is required to enable and tweak certain features. Critically, virtual hosts are not enabled. It is worth examining the Arch Linux wiki page on LAMP server set up and verifying that more than one named virtual host functions properly.

If setting up for standalone development, see this useful wiki page to configuring postfix for local mail only.

To ensure Apache and mysql start when the machine boots, enable the httpd and mysqld daemons by adding them to the /etc/rc.conf file:

DAEMONS=(... mysqld httpd ...)

3. Configure system requirements

3.1. Create the Aegir user

The provision framework of Aegir requires that the scripts run as a non-root system account, to ensure that it can correctly set the file permissions on the hosted files.

Also to ensure that the file permissions of the hosted sites are always as safe as can be, and especially to make sure that the web server does not have the ability to modify the code of the site, the configured system account needs to be a member of the web server group, in order to be able to correctly set the file permissions.

While you can choose another username, most aegir documentation assumes the Aegir user is aegir, its home directory is /var/aegir and the webserver group is www-data.

Shell commands as root:

adduser --system --group --home /var/aegir aegir
adduser aegir www-data    #make aegir a user of group www-data

3.1.1. CentOS specific configuration

CentOS requires special commands to create the user, use those instead:

useradd --home-dir /var/aegir aegir
gpasswd -a aegir apache
chmod -R 755 /var/aegir

3.1.2. Solaris specific configuration

groupadd aegir
useradd -g aegir -G webservd -d /var/aegir -s /bin/bash -c "Aegir sandbox" aegir
chown aegir:aegir /var/aegir

3.1.3. Arch Linux specific configuration

useradd --system --groups http --home /var/aegir --create-home aegir
chmod -R 755 /var/aegir

3.2. Webserver configuration

Aegir supports two popular web servers, Apache and Nginx.

3.2.1. Apache configuration

Aegir assumes a few Apache modules are available on the server, and generates its own configuration files. The way we enable this is by symlinking a single file which contains all the configuration necessary. In Debian-based systems, you should symlink this file inside /etc/apache2/conf.d that will be parsed on startup or alternatively you can place include that file in your apache.conf/httpd.conf. We prefer the former. In other systems there are similar ways to accomplish this. Consult your OS's documentation if unsure.

If you are on a Debian-based system, you will also need to enable the mod_rewrite module manually.

Run the following shell commands as root. First, configure Apache to enable RewriteEngine:

a2enmod rewrite

Finally, create a symlink from an apache configuration file to a folder within the /var/aegir/:

ln -s /var/aegir/config/apache.conf /etc/apache2/conf.d/aegir.conf Ubuntu 14.04+ specific Apache configuration

Ubuntu 14.04 departs from Debian and previous Ubuntu Apache setup in that it doesn't use /etc/apache2/conf.d any more and better separates out sites-enabled from conf-enabled configurations. So:

ln -s /var/aegir/config/apache.conf /etc/apache2/conf-available/aegir.conf  
a2enconf aegir

Do not reload/restart Apache if prompted to after running these commands, it will fail. CentOS specific Apache configuration

On CentOS, mod_rewrite is enabled by default and you can create the following symlink:

ln -s /var/aegir/config/apache.conf /etc/httpd/conf.d/aegir.conf Arch Linux specific Apache configuration

On Arch Linux, mod_rewrite is also enabled by default. Add the aegir apache configuration include file to the httpd.conf file:

echo "Include /var/aegir/config/apache.conf" >> /etc/httpd/conf/httpd.conf Other systems' Apache configuration

In other systems that do not have a conf.d directory, this could also work:

echo "Include /var/aegir/config/apache.conf" >> /etc/apache2/httpd.conf


  • A standard umask of 022 is assumed. This is the default on most systems.
  • For more information, see the common installation errors.
  • For all OSes, the installer script creates the configuration file referenced by the newly created symlink/or file referenced in the Apache config file.

3.2.2. Nginx configuration

(If you just succeeded in installing Apache, please skip this section.)

Aegir assumes standard Nginx configuration is available on the server, and generates its own configuration files. The way we enable this is by symlinking a single file which contains all the configuration necessary. In Debian-based systems, you should symlink this file inside /etc/nginx/conf.d that will be parsed on startup.

Please make sure your nginx installation is up and running before continuing. On Ubuntu 12.04 Server, for instance, you must edit /etc/nginx/nginx.conf and uncomment the line "types_hash_max_size 2048;" in order for nginx to start successfully.

Shell command as root::

ln -s /var/aegir/config/nginx.conf /etc/nginx/conf.d/aegir.conf

Do not reload/restart Nginx after running these commands, it will fail.

The installer script creates the configuration file referenced by the newly created symlink.

3.3. PHP configuration

Some complex installation profiles or distributions require a PHP memory limit that is higher than the default. To avoid common errors when installing sites on some distributions, the PHP command line tool should be configured to use 192Mb of RAM.

Change the memory_limit directive in /etc/php5/cli/php.ini to read:

memory_limit = 192M      ; Maximum amount of memory a script may consume (192MB)

Most modern Drupal sites require around 96M or even 128M of RAM for certain operations. This is far more than what is provided by the default PHP configuration.

Change the memory_limit directive in /etc/php5/apache2/php.ini to read:

memory_limit = 128M      ; Maximum amount of memory a script may consume (128MB)

If your distributions require more memory than these limits, then use some common sense and update it as appropriate to suit your individual needs.

For Aegir 3, make sure you've installed the required PHP extensions, particularly the image library (php-gd).

3.3.1. RHEL 6 specific configuration

The default php.ini configuration beyond the above changes also requires that the timezone be set for your location. Otherwise, you get fun errors and warnings during the host-master install step.

  1. sudo vi /etc/php.ini
  2. enter your password
  3. /zone (this will bring you to the date specific timezone module area
  4. Remove the semi colon in front of date.timezone and enter your specific timezone.

      ; Defines the default timezone used by the date functions
      date.timezone = Your Time Zone Goes Here

  5. Restart apache to compile these changes. sudo httpd -k graceful

3.3.2. Arch Linux specific configuration

Make the following changes to the php.ini file (/etc/php/php.ini):

Add :/var/aegir/ to the open_basedir directive:

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/var/aegir/

Add date.timezone value as per PHP's runtime configuration instructions - this is an example:

date.timezone = Europe/London

Modify the memory_limit directive:

memory_limit = 192M


3.4. Sudo configuration

Next, we need to give the aegir user permission to execute the Apache2 command to restart the web server without entering a password.

Create a file at /etc/sudoers.d/aegir and add the following:

Defaults:aegir  !requiretty
aegir ALL=NOPASSWD: /usr/sbin/apache2ctl

After saving, change the permissions on the file:

chmod 0440 /etc/sudoers.d/aegir

Note - the path to your apache2ctl program may differ from this example. On some systems it may also be called 'apachectl' instead of apache2ctl. Adjust to suit your own requirements.

3.4.1. CentOS Linux specific sudo configuration

For CentOS apache2ctl is apachectl and you should use this instead, as root::


This command opens an editor to allow you to edit the /etc/sudoers file. Add the following to the end of the file (specific directions cannot be given since this depends on what editor you're using):

Defaults:aegir  !requiretty
aegir ALL=NOPASSWD: /usr/sbin/apachectl

Note - the !requiretty bit is to make aegir able to run sudo even though it's not attached to a terminal. By default CentOS enforces requiretty so this exception is necessary.

3.4.2. Nginx specific configuration

For those using Nginx, set the sudoers line as follows

aegir ALL=NOPASSWD: /etc/init.d/nginx

3.5. DNS configuration

Aegir requires a properly configured "FQDN" (Fully Qualified Domain Name) be assigned to the machine. In practice, this means that the hostname returned by the hostname and uname -n shell commands should resolve to the IP address for this server, and vice versa.

If you only intend to use Aegir on a single server, it is acceptable for the resolved IP address to be the '' loopback address.

If you intend to manage multiple servers using Aegir, you will need to make sure that the IP address is the public IP of this server.

You can add multiple entries to your /etc/hosts file for testing purposes, for example:

Then you can use to create your first site.

3.6. Database configuration

Aegir supports MySQL right now. It is best to install the MySQL server using your Linux distribution's package manager.

Shell commands as root::

apt-get install mysql-server

To make sure that the Aegir backend, and all the possible web servers can reach your database server, you need to configure mysql to listen on all the public IP addresses available to it.

Again, as root, edit the MySQL configuration file /etc/mysql/my.cnf configuration line to comment out by placing a # at the beginning of the line as follow:


bind-address        =


# bind-address      =

Without this line commented out, MySQL will listen only on localhost for database connection requests.

Now you need to restart mysql, to clear any caches.

Shell command as root:

/etc/init.d/mysql restart

The installer will prompt you for your MySQL root user password. The root user will be used to make administrative tasks such as creating new databases, and granting and revoking access to those databases for sites.

Even though MySQL is now listening on all IP's, it will not allow invalid users to connect to the databases, without the correct user accounts configured.

If you are concerned about MySQL being accessible in this way, you can also configure your firewall to only allow incoming connections from certain addresses. This is outside the scope of this document however.

Note that Aegir will ask you for your MySQL root password. If you do not want to use your regular root password for Aegir, you will need to create another root account for Aegir using a MySQL command like:


Note: If you are running your Aegir databases on a remote DB server, you will want to create this aegir_root user. The install will often fail if you're trying to use the root user on a remote database. See this issue for details.

3.6.1. Ubuntu, RHEL, Arch linux specific configurations

NOTE: If you are running either Ubuntu 12.04 LTS, RHEL 6 or Arch Linux, you should still install MySQL in the same way as above. However, once done, you must now remove the anonymous, passwordless login that those platforms creates by default. To do this, run:

sudo mysql_secure_installation

Otherwise, Aegir will fail to install and work at all. See this FAQ entry.

3.6.2. RHEL 6 specific configuration

In Red Hat, you may need to move a default configuration file from /usr/share/mysql/ to /etc/my.cnf to view or modify any of the settings mentioned above.

4. Install Aegir components

Next step is to install the Aegir software components themselves, that is: drush, provision and hostmaster.

4.1. Install drush

Before installing Aegir proper, you first need to install Drush. This can be done through your operating system's package manager (Drush is shipped with Debian and Ubuntu currently) or by following the Drush README.txt file which has all the information for installing and using drush.

Note for 1.x users: you should use Drush version 4. Aegir 1.x does not support Drush 5. Also note there is a bug in Drush 4.0 and 4.1 so you should use a version of Drush between 4.1 and 5.

pear channel-discover
pear install drush/drush-4.6.0

Note for 2.x users: you need to install a minimum of Drush version 5.10, though Drush 6.x is recommended. In this case, you may be able to install the regular release:

Note for 3.x users: you need to install a minimum of Drush version 6,some time you need apt-get install php-console-table before you become the Aegir user:

pear channel-discover
pear install drush/drush

This should install Drush system-wide, but if you follow the manual install, you may end up with Drush in a non-standard location (traditionally /var/aegir/drush/drush.php), in which case you will need to add that directory to your path or use the following symlink:

ln -s /var/aegir/drush/drush /usr/local/bin/drush

4.1.1. Arch Linux specific configuration

It seems that Arch's PHP environment needs to be modified for Drush:

mkdir /var/aegir/.drush
cp /etc/php/php.ini /var/aegir/.drush/

Edit /var/aegir/.drush/php.ini to remove the values after open_basedir =, as this will any open_basedir values are likely to cause Drush to fail.

4.2. Stop! Now become the Aegir user!

The remaining of this manual assumes you are running as the Aegir user. Things will go very wrong if you do not change your shell credentials to become that user. You can do this by running the following command as root:

su -s /bin/bash - aegir

If this fails because /bin/bash doesn't exist, try using /bin/sh.

4.3. Install provision

Once Drush is installed you should be able to install the latest recommended Provision release using the following drush command:

Note for 1.x users:

drush dl --destination=/var/aegir/.drush provision-6.x

Note for 2.x users:

drush dl --destination=/var/aegir/.drush provision-6.x-2.0
drush cache-clear drush

Note for 3.x users: replace provison-6.x-2.0 to provison-7.x

4.4. Running hostmaster-install

Once you have downloaded drush and provision, you can just install provision in the commands directory of Drush (either ~aegir/.drush or /usr/share/drush/commands), if that's not already done. Once provision is properly installed, you can install all other aegir components using the hostmaster-install command:

drush hostmaster-install

You will be prompted for the required information if not provided on the commandline. See the inline help for the available options:

drush help hostmaster-install

For example, to install the frontend on Nginx, use:

drush hostmaster-install --http_service_type=nginx

Note for 2.x users: Drush 5 has a commandfile cache which you need to clear before installing Aegir:

drush cache-clear drush

It is imperative that you provide a valid FQDN to the installer. This is used for database GRANTs. Remote web servers depend on the FQDN being resolvable in order to connect back to your Aegir master server if it is used as your database server for managed sites.

Upon completion of the installation, the traditional Drupal 'Welcome' e-mail will be sent to the e-mail address specified by --client_email=(your e-mail) or if not provided as a command line switch, the address prompted by the installer process. This e-mail address will also be used as the default e-mail address of the first user and client in Aegir, but can be changed later.

There are other commandline switches available, documented in drush help hostmaster-install, as usual.

4.4.1. Arch Linux specific configuration

drush hostmaster-install --web_group=http

5. Install the Hosting Queue Daemon

For Aegir 2.x installs, using the Hosting Queued Daemon (hosting_queued) is highly recommended. For Aegir 1.x, check out instead.

These instructions will install the daemon to run as a regular service in /etc/init.d/. Instructions will vary according to platforms, but the following should work in Debian, running as root.

  1. Install the init script in place

    cp <hostmaster_platform_root>/profiles/hostmaster/modules/hosting/queued/init.d.example /etc/init.d/hosting-queued
  2. Setup symlinks and runlevels

    update-rc.d hosting-queued defaults
  3. Start the daemon


6. Checkpoint / Finished!

At this point, you have checked out all the code and setup your basic Drupal system (Drupal core, hosting, hostmaster and eldir) that will be the Aegir frontend and the backend system (provision and drush). Your filesystem layout should look something like this:


Variations on this are acceptable (for example, the Drush Debian package works out of /usr/bin/drush and that's fine), but you are better to stick with the defaults if you really want to get through this.

The installation will provide you with a one-time login URL to stdout or via an e-mail. Use this link to login to your new Aegir site for the first time.

For troubleshooting this process and resulting install, see the common installation problems page.

You may also want to read on with what you can do with Aegir now that it is installed.

Mac OS X installation instructions



For Apache based installation hints see Apache / mySQL / PHP / Aegir


Nginx is more performant than Apache, if you are interested in setting Aegir up using nginx Brian Gilbert from Realityloop has created a script to install everything that you need on a clean Mac (not already running anything on port 80), see OSX Aegir Installer on github.

Apache / mySQL / PHP / Aegir

This is a helper file to the canonical manual install process. It is aimed at helping you install Aegir on Mac OS X. Since PHP and MySQL support on OS X is fairly limited and complicated, a separate documentation page was created for that part of the documentation. You should follow this page all the way through and then proceed with the regular install, step 4: becoming the aegir user.

1. Special software requirements

While Mac OS X comes with Apache & PHP (and even MySQL on the Server version), the version of PHP shipped with 10.6 Snow Leopard is 5.3.x and thus may not work with Aegir (as of the 0.4alpha-era) and various other software. If you're running 10.5 Leopard, it may work out of the box, but I haven't tested it.

There are several different ways to get Apache, PHP 5.2, and MySQL 5 onto a Mac OS X machine. I give detailed instructions for MacPorts below, but if that's a bit more than you're ready to bite off right now, feel free to use an alternative approach.

One such alternative is MAMP. There is a good but outdated HOWTO for installing Aegir on Mac OS X 10.6 (Snow Leopard) using MAMP located here:

MAMP stands for Mac, Apache, MySQL, and PHP and is the Mac equivalent of "LAMP". It is a self-contained package of all of these programs with a nice graphical installer and control panel. You can find it here:

MAMP is pretty straightforward, but it's also not very flexible (IMHO). While certainly not without its own headaches, MacPorts is a decently powerful way to sanely manage a healthy stack of open source UNIX software on your Mac. Since this is what I use, I'm going to assume MacPorts is in use for the rest of this HINTS file. I have also only tested this on Mac OS X 10.6 Snow Leopard.

If you don't yet have MacPorts installed, go here to get it:

Once it's installed, quit and re-launch your Terminal before continuing. Otherwise MacPorts won't yet be in your PATH.

The first two commands below are optional but recommended.

  sudo port selfupdate
  sudo port upgrade outdated
  sudo port install apache2 mysql5-server git-core unzip php52 php5-posix php5-gd php5-apc +mysql5

php5-apc is optional, but highly recommended as it will significantly increase PHP performance.

Watch the output of the last port command carefully, as there are usually some boring tasks for you to perform once the install is done. You'll be wishing you were running Ubuntu/Debian and apt-get by the time you're done.

2. Configure system requirements

Next we'll create the aegir user and add it to the _www group. This part is very different on Mac OS X than Linux or most other Unices. Must be a NeXTism. The command we will use he is "dscl", which is a short for Directory Service Command Line. In OSX 10.3 and earlier, that command is "nicl" (short for Net Info Command Line). It is also possible to create the user using the "Workgroup Manager" utility included with OS X Server. To obtain Workgroup Manager for the OS X Client, download the "Server Admin Tools" from Apple. For example, for Mac OS X 10.6, the admin tools can be found at:

  sudo dscl . -create /Users/aegir NFSHomeDirectory /var/aegir

Now you need to find the next spare UID to assign the user.

Here's how you find out on your system:

   sudo dsexport users.out /Local/Default dsRecTypeStandard:Users

Then open the file users.out in a text editor, search for the highest 5xx user ID and add 1 to it (in your brain, not in the file). So if you find 506 but no 507, use 507. When you're done, delete users.out to be safe.

   sudo rm users.out

Now assign this UID to the aegir user, replacing "5xx" with the UID.

   sudo dscl . -create /Users/aegir UniqueID 5xx

!! If you're running Mac OSX Lion, you also need to assign PrimaryGroupID to the aegir user.
   sudo dscl . -create /Users/aegir PrimaryGroupID XXX

Set a secure password for the aegir user, as it needs shell access.

sudo passwd aegir

Create the aegir home directory and set its permissions.

sudo mkdir /var/aegir
sudo chown aegir /var/aegir
sudo chgrp _www /var/aegir

Add the aegir user to the _www group. This is the group Apache runs as.

sudo dscl . -append /Groups/_www GroupMembership aegir

Give the aegir user the ability to restart Apache.

   sudo mv /usr/sbin/apachectl /usr/sbin/apachectl-apple
   sudo ln -s /opt/local/apache2/bin/apachectl /usr/sbin/apachectl
   sudo visudo

Go to the last line of the file and add the following.

   aegir ALL=NOPASSWD: /usr/sbin/apachectl

Save the file and exit your text editor.

Next configure Apache to include the Aegir config.

   echo "Include /var/aegir/config/apache.conf" >> /opt/local/apache2/conf/httpd.conf

Configuring your MySQL database and user accounts is the same as in the INSTALL.txt file. But you probably want to add the path to its executables to your user's PATH and the aegir user's PATH.

   echo 'export PATH=/opt/local/lib/mysql5/bin:$PATH' >> ~/.profile
   su - aegir
   Password: (the password you setup earlier)
   echo 'export PATH=/opt/local/lib/mysql5/bin:$PATH' >> ~/.profile

nginx / MariaDB / PHP / Aegir (MEMPÆ)

The instructions that used to be here are now outdated, instead use the OSXAegirInstaller created by Brian Gilbert of Realityloop.

Centos 6.x Aegir Install Guide

There are 2 methods of installing AEgir on CentOS both are the same but one is scripted and the other is manual and is documented below.


The script can be found at

NB. There is preliminary work to fix selinux at Feedback is quite welcome as well as git pulls.


Connect to the server via ssh as root user.

ssh root@

Install system requirements

yum install httpd php php-mysql php-cli php-gd php-process php-pear php-mbstring php-xml php-soap sudo rsync git postfix tree wget cronie unzip mysql-server mlocate nmap samba samba-client samba-common vim

Note: The following packages are not required but are very useful to include git wget mlocate nmap samba samba-client samba-common vim


Make sure Security-Enhanced Linux is disabled as it creates install problems.

vim /etc/selinux/config Make sure SELINUX=disabled

If was SELINUX=enabled then we need to restart.

shutdown -r now

Note: I am not sure if it can be enabled at the end I have never tried.

Create the Aegir user

The provision framework of Aegir requires that the scripts run as a non-root system account, to ensure that it can correctly set the file permissions on the hosted files.

Also to ensure that the file permissions of the hosted sites are always as safe as can be, and especially to make sure that the web server does not have the ability to modify the code of the site, the configured system account needs to be a member of the web server group, in order to be able to correctly set the file permissions.

While you can choose another username, most aegir documentation assumes the Aegir user is aegir, its home directory is /var/aegir and the webserver group is www-data.

useradd --home-dir /var/aegir aegir

gpasswd -a aegir apache

chmod -R 755 /var/aegir

Apache configuration

Start Apache

service httpd start

Make apache start automatically after reboot.

chkconfig httpd on

We need to create a symbolic link between aegir and apache.

ln -s /var/aegir/config/apache.conf /etc/httpd/conf.d/aegir.conf

PHP configuration

vim /etc/php.ini

Increase the memory limit as complex installation profiles or distributions require a PHP memory limit that is higher than the default (128M)

memory_limit = 192M

Set Date Zone to your time zone see

date.timezone = “”

Sudo configuration

Next, we need to give the aegir user permission to execute the Apache2 command to restart the web server without entering a password.


Add to end of file

Defaults:aegir !requiretty

aegir ALL=NOPASSWD: /usr/sbin/apachectl

DNS configuration

Aegir requires a properly configured "FQDN" (Fully Qualified Domain Name) be assigned to the machine. In practice, this means that the hostname returned by the hostname and uname -n shell commands should resolve to the IP address for this server, and vice versa.

If you only intend to use Aegir on a single server, it is acceptable for the resolved IP address to be the '' loopback address.

If you intend to manage multiple servers using Aegir, you will need to make sure that the IP address is the public IP of this server.

You can add multiple entries to your /etc/hosts file for testing purposes, for example:#> >vim /etc/hosts Add your ip and hostname hostname

Database configuration

Start mysql

service mysqld start

Make mysql start automatically after reboot.

chkconfig mysqld on

Configure Mysql



Set root Password

Remove anonymous users? y

Disallow root login remotely? y

Remove test database and access to it? y

Reload privilege tables now? y

Install drush

pear channel-discover

pear install drush/drush-4.5.0

Check if drush works If you get PHP Fatal error: Class 'Console_Table' not found then

pear install Console_Table

Stop! Now become the Aegir user!

The remaining of this manual assumes you are running as the Aegir user. Things will go very wrong if you do not change your shell credentials to become that user.

su -s /bin/bash - aegir

Install provision

drush dl --destination=/var/aegir/.drush provision-6.x

Clear the drush cache

drush cache-clear drush

Run hostmaster-install

drush hostmaster-install

Manual install of a web cluster aegir using nginx

These are some really rough notes on how to go about creating a 4 server aegir installation (aegir, mysql, web1, web2).

Adapted from reading through the BOA project and my own experimentation.

** Note -- regarding the wildcard SSL, your sites will need some configuration in your settings.php or local.settings.php to check for the X-Forwarded-Proto headers. I can't recall if the wildcard SSL config.

These notes also assume the last Ubuntu LTS -- 10.04/Lucid.


sudo apt-get update
sudo apt-get upgrade
sudo apt-get install vim mysql-server


#AEGIR_DB_PASS=`echo $RANDOM:\`date\`:$AEGIR_HOST | openssl md5`

echo "[client]
password=password" >> .my.cnf

mysql -uroot mysql<<EOFMYSQL




sudo apt-get update
sudo apt-get upgrade

sudo mkdir -p /var/www/nginx-default

CATHOSTDEBDEPS="git-core git-doc mysql-client-5.1 vim nginx-custom drush postfix php5-cli php5-mysql php5-fpm php5-gd rsync unzip bzr patch curl"
sudo apt-get -V install $CATHOSTDEBDEPS

#postfix config already sorted

sudo adduser --system --group --home /var/aegir aegir
sudo adduser aegir www-data
sudo chsh -s /bin/bash aegir

#patch drush, re: ereg()

#as root:
echo "aegir ALL=NOPASSWD: /etc/init.d/nginx" >> /etc/sudoers

ln -s /var/aegir/config/nginx.conf /etc/nginx/conf.d/aegir.conf
#disable directives in nginx.conf:
invoke-rc.d nginx restart

#install SSL cert to:
cd /etc/ssl/private/
ln -s nginx-wild-ssl.crt
ln -s nginx-wild-ssl.key

#install SSL config to:
#TODO: also install for /var/aegir/config/server_aegirweb{1,2}

#as aegir:
cd ~

mkdir .ssh
ssh-keygen -t rsa

ln -s /usr/share/drush /var/aegir/drush
mkdir ~/.drush
cd ~/.drush
wget -c
tar -zxf provision-6.x-1.3.tar.gz

#htaccess password bit
mkdir ~/tmp
cd ~/tmp
git clone --branch develop git://
#must be develop branch to use crypt() and for nginx support
cp -r aegir_http_basic/provision ~/.drush/provision/aegir_http_basic
cp -r aegir_http_basic/hosting ~/hostmaster-6.x-1.3/profiles/hostmaster/modules/hosting/http_basic_auth
#set directory permissions? -- patch aegir/http_basic module to do so?

#_AEGIR_HOST=`uname -n`

#going vanilla
echo "drush hostmaster-install $_DOMAIN --aegir_host=$_AEGIR_HOST --aegir_db_user=$_USER --aegir_db_pass=$_AEGIR_DB_PASS --http_service_type=nginx --db_service_type=mysql --db_port=3306 --aegir_db_host=$_AEGIR_DB_HOST --client_email=$_ADM_EMAIL --script_user=$_USER --web_group=$_WEBG --profile=hostmaster -d -v"

drush hostmaster-install $_DOMAIN --aegir_host=$_AEGIR_HOST --aegir_db_user=$_USER --aegir_db_pass=$_AEGIR_DB_PASS --http_service_type=nginx --db_service_type=mysql --db_port=3306 --aegir_db_host=$_AEGIR_DB_HOST --client_email=$_ADM_EMAIL --script_user=$_USER --web_group=$_WEBG --profile=hostmaster -d -v

cd hostmaster-6.x-1.3
echo "alive" >> healthcheck

#enable aegir modules
drush @hostmaster en hosting_web_cluster
drush @hostmaster en hosting_alias
drush @hostmaster en hosting_http_basic_auth
#*** enable hosting client in features -- disabling client module cause WSOD on site add page

# setup aegirweb{1,2}
# test ssh to aegirweb{1,2}
# add to known_hosts

# NOTE: Aegir web clusters need to share the files, and private directories between web servers (also cache directory, if using boost module)
# Setup provision hook for NFS links

mkdir -p /var/lib/sitedata/aegir
chown -R aegir:www-data /var/lib/sitedata/aegir

mkdir -p /var/lib/sitedata/aegir/cache
chown -R aegir:www-data /var/lib/sitedata/aegir/cache

# add web servers
# add web cluster
#TODO: Add DR web servers to cluster
#TODO: Add WR, re: DR web servers & firewall

# set date/time settings in Aegir

#TODO: Logrotate webserver logs

#TODO: Add an alias for the aegir user:
#aegir: """


#TODO: Check puppeted stuff, fix, etc

sudo apt-get update
sudo apt-get upgrade

sudo mkdir -p /var/www/nginx-default

CATWEBDEBDEPS="mysql-client-5.1 vim nginx-custom drush postfix php5-cli php5-mysql php5-fpm php5-gd rsync unzip patch"
sudo apt-get -V install $CATWEBDEBDEPS

sudo adduser --system --group --home /var/aegir aegir
sudo adduser aegir www-data
sudo chsh -s /bin/bash aegir

#install SSL cert to:
cd /etc/ssl/private/
ln -s nginx-wild-ssl.crt
ln -s nginx-wild-ssl.key

#install SSL config to:
#TODO: also install for /var/aegir/config/server_aegirweb{1,2}

#as root:
echo "aegir ALL=NOPASSWD: /etc/init.d/nginx" >> /etc/sudoers

#as aegir:
mkdir /var/aegir/.ssh
cat >> /var/aegir/.ssh/authorized_keys2

#TODO: Logrotate webserver logs


nginx / MariaDB / PHP-FPM Single Server Installation


Note: This installation process assumes that you're using a fresh install of Ubuntu 14.04 x64. If you use a lower version of Ubuntu, you may have trouble with this guide.

On most VPS providers, you'll be logged in as root initially. The installation process below assumes that you are logged in as root. Obviously, this is not a secure long-term solution, so once you're done with this guide, I suggest setting up public key authentication, turning off root login over SSH, and creating yourself a new unprivileged user. That's out of scope for this doc page, so you're probably on your own for that.

Finally, this document assumes that you're going to be installing aegir at Any time you see, replace it with your domain.

1. Housekeeping

Make sure you're up to date:

apt-get update
apt-get upgrade

And that you have the the python-software-properties package (we'll need it later):

apt-get install python-software-properties

2. Install MariaDB


MariaDB is a database server that offers drop-in replacement functionality for MySQL. 
MariaDB is built by some of the original authors of MySQL, with assistance from the
broader community of Free and open source software developers. In addition to the core
functionality of MySQL, MariaDB offers a rich set of feature enhancements including
alternate storage engines, server optimizations, and patches.

Install MariaDB:

apt-get install mariadb-server

You'll need to set your root password for the MariaDB server

3. Install Nginx

Next, install Nginx and PHP-FPM:

apt-get install nginx php5-cli php5-mysql php5-fpm php5-gd

Create the default docroot for Nginx as well:

mkdir -p /var/www/nginx-default

4. Install all the other stuff

apt-get install git-core git-doc vim drush postfix rsync unzip bzr patch curl

When prompted for Postfix configuration, select "Internet Site", then use "" for the System mail name.

5. Create the Aegir user


adduser --system --group --home /var/aegir aegir
adduser aegir www-data
chsh -s /bin/bash aegir

6. Misc Configuration

Make sure the Aegir user is allowed to restart Nginx:

echo "aegir ALL=NOPASSWD: /etc/init.d/nginx" >> /etc/sudoers

Symlink Aegir's nginx configuration into place:

ln -s /var/aegir/config/nginx.conf /etc/nginx/conf.d/aegir.conf

Disable duplicated directives in /etc/nginx/nginx.conf (the Aegir config specifies these values as well - if you do not disable them in the main nginx.conf, nginx will fail to restart). You can just remove (or comment them out with a "#") the lines that start with the following


Then, restart Nginx:

service nginx restart

7. Install Aegir

IMPORTANT Switch to the Aegir user now: IMPORTANT

su - aegir
cd ~/

Download the latest Provision release:

mkdir ~/.drush
cd ~/.drush
wget -c
tar -zxf provision-6.x-2.1.tar.gz
rm provision-6.x-2.1.tar.gz

Start the Aegir install process:

cd ~/
drush hostmaster-install \
--aegir_host="" \
--http_service_type="nginx" \
--aegir_db_user="root" \
--aegir_db_pass="[YOUR ROOT DATABASE PASSWORD]" \
--db_service_type="mysql" \
--db_port=3306 \
--aegir_db_host="localhost" \
--client_email="[YOUR EMAIL ADDRESS]" \
--script_user="aegir" \
--web_group="www-data" \

8. Optional Improvements

Common installation problems

There are a few things that can go wrong in the install.

1. Verify and install run everything through SSH

Since Aegir has multi-server support, it is possible that you have a misconfigured "FQDN" and that aegir then tries to connect to the local server as a remote server. To check if you have a misconfigured server, run the following commands:

resolveip `uname -n`

If the command returns your IP address, you are all set. If it returns an error you will need to edit your /etc/hosts file.

First line of this file looks like:  localhost

Simply add all domains you want to this line. e.g:  localhost

2. NameVirtualHost *:80 has no VirtualHosts

It does not hurt anything, but it can be annoying in your logs. This may disappear as soon as you define your first virtual site using Aegir. If it does not, you most likely have a second NameVirtualHost statement in your configuration someplace other than in the Aegir configurations.

If you are on a Debian system, that is usually a configuration fragment in /etc/apache2/ports.conf or in a fragment symbolically linked in /etc/apache2/sites-enabled and it is safe to comment out any NameVirtualHost statements you find there as this really is a large part of the job you have asked Aegir to do for you.

Once those are commented out, the message should disappear.

3. Making sure it works

Your new Aegir server will be installed with a single site named the way you specified in your install script. That's great, but you may have more paths to that same server.

When you try to browse to your server for the first time from a non-localhost browser you may get an addressing issue. If you do, make sure that you actually have the server defined in DNS and that the DNS server was reloaded. If it was reloaded and you use slave servers, make sure that the serial number in the zone file was incremented so that the slaves automatically reload.

If you already have multiple URLs in your DNS which resolve to the same Aegir, you should check them. For instance: if your DNS resolves both and to your new Aegir server's IP, you need to make sure that both are accommodated. If they will both get the same physical hostmaster site, one should be set up as an alias to the other. If they are indeed going to be separate sites you will have to create a new site node with the other name as a virtual site.

4. Access by the server's physical IP address

Another "gotcha" that you may run into is http access using the actual IP itself. Remember that the IP is not picked up by the site vhost and will not match a ServerName or ServerAlias - so it gets picked up by the default vhost. This is just standard apache stuff, nothing Aegir or Drupal specific here, but quite the annoyance and a potential problem.

You can easily work around it by simply adding the IP as a Site Alias in the site node in either the Aegir site (or another site that you may have defined which you would prefer the IP to address).

You can tell if you have the IP problem by simply pointing your browser to the server by IP as http://999.999.999.999/ and seeing what comes up. If you get an install screen, you have the problem. You certainly do not want that install screen getting executed!

The good news is that fixing it is easy.

Simply log into Aegir, click on Sites, click on the site name that you want the IP to address, click on Edit and scroll down to Domain Aliases. Put the IP into the box, click on the Redirect checkbox so that Aegir instructs Apache to do a rewrite to the real domain name, and finally click Save.

If you do not have the Domain Aliases entry box, you need to turn that feature on. In that case, go to your administration menu at the top of the page, point to Hosting and then click on Features. Click the checkbox for Site Aliasing and then Save Configuration. The Aliases box will now appear when you edit a site. There is excellent information about the site alias feature in this handbook at with much more detail.

After the Verify job completes you should test your server again. Now when you address the server by it's IP address the URL should automatically change to the site you selected and the install screen never appears.

5. CentOS firewall settings

You may need to adjust CentOS's firewall settings to allow HTTP traffic on port 80. If you installed CentOS with a UI, enable "Firewall settings -- WWW (HTTP)".

Alternatively, another solution may be to edit /etc/sysconfig/iptables and add a rule accepting traffic on the relevant interface on port 80.

Afterwards, you can restart the firewall with this command:

Shell commands::

service iptables restart

6. CentOS cron requires restart?!

Also, in some configurations, it seems necessary to restart crond for the user crontab changes to take effect (very bizarre). For that, use:

Shell commands::

service crond restart

See if you have more information about this issue.

7. CentOS aegir.conf permission denied

If you receive:

Starting httpd: httpd: Syntax error on line 209 of /etc/httpd/conf/httpd.conf: Could not open configuration file /etc/httpd/conf.d/aegir.conf: Permission denied
when trying to restart httpd, check your SELinux settings. If enabled, you can run the following command on the aegir.conf file in /var/aegir/config/server_master directory:
chcon -t httpd_config_t apache.conf
Alternatively, you can disable SELinux completely if you desire. Both options will result in removing the permisson denied error.

You can see this comment: for a little more info.

Try the following if nothing works:

setenforce permissive

See this doc to make the change permanent:

8. Solaris cron issues

I had numerous problems setting up a proper cron job, as Solaris' crond seems pretty anal about what it accepts. The only way I could get it to work was to create a wrapper shell script that would be called using the simplest cron tab.

Crontab entry:

* * * * * /var/aegir/

Content of



export HOME
export PATH

php '/var/aegir/drush/drush.php' --php=/usr/local/bin/php '@hostmaster' hosting-dispatch

9. Drush execution path issues

Solaris (and maybe others) suffers from the dreaded execution issues of drush:

Those can be worked around by hardcoding the --php executable on the commandline path. Adding the proper shebang (#!/usr/local/bin/php, for example) header and using a proper PATH that includes the PHP executable also helps.

10. APC issues

If you are having trouble running APC with Aegir, try downgrading to APC 3.1.4. This can be achieved by the following:

sudo pecl uninstall apc

sudo pecl install apc-3.1.4

Ubuntu 10.04 Specific : How to downgrade to php 5.2 before install


As explained at, the recommended version of PHP is 5.3, but some users may wish to use PHP 5.2 in order to host Drupal 5.x sites or to use modules which have PHP 5.3 compatibility issues. Should you choose to do so, the following documentation may be useful. What is explained here is specific to Ubuntu 10.04. It hasn't been tested on further versions, mostly because many sysadmins prefer to use the latest Long Term Support (LTS) version of Ubuntu, currently 10.04, on their production servers.

Follow this procedure :

sudo apt-get install python-software-properties

add-apt-repository ppa:txwikinger/php5.2

Create the file /etc/apt/preferences.d/php and input the following code in it :

Package: libapache2-mod-php5
Pin: version 5.2.10*
Pin-Priority: 991

Package: libapache2-mod-php5filter
Pin: version 5.2.10*
Pin-Priority: 991

Package: php-pear
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-cgi
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-cli
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-common
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-curl
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-dbg
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-dev
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-gd
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-gmp
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-ldap
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mhash
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mysql
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-odbc
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-pgsql
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-pspell
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-recode
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-snmp
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-sqlite
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-sybase
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-tidy
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-xmlrpc
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-xsl
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mcrypt
Pin: version 5.2.6*
Pin-Priority: 991

Package: php5-imap
Pin: version 5.2.6*
Pin-Priority: 991

Then proceed Aegir install as explained at

Post-install configuration

Alright, so you have installed Aegir, what else is there?

You have a lot of things you can do now:

A lot more is available in the user manual.

Importing sites


It is possible to import existing sites into the Aegir hosting system, so that they can be managed by Aegir.

These instructions assume you've set up a new server with Aegir on it, and you want to import sites into Aegir from another server, or even from the same server, using backups.

There are basically three ways of importing sites in Aegir:

This section also regroups troubleshooting and other less orthodox techniques.

Importing from existing Aegir backups


If you need to import a site from an existing Aegir system, this can be done from an Aegir site backup.


  1. New Aegir version 0.4 alpha15 or later.
  2. Access to Aegir backups from the old server.
  3. A platform set up and verified that matches the platform on the old Aegir server.

1. Copy backups

First log into the new server via ssh - switch to the aegir user. Create a temporary directory somewhere, for example:

mkdir /var/aegir/tmp/migrate

Run a command to syncronize the new directory with the backups directory of the old Aegir hosting system. This command does the entire directory, but you may want to modify this if you have a lot of unneeded backups on the old system.

This command also assumes that you can shell into the other server as the aegir user. Modify as required.

rsync -aPv -e ssh* /var/aegir/tmp/migrate

Now you can re-run the above command just before you are going to migrate a site. This is handy if you have a lot of sites to migrate and each site requires attention. Simply make a new backup of the site in the old system, and rerun the rsync command.

2. Create the site context and deploy the backup

For brevity, I assume that drush can be executed as drush. Replace with php /var/aegir/drush/drush.php if needed.

Pay attention to these two commands, they require modification to match the name of the site, the alias of the platform, and the name of the backup archive. These commands should each be on one line. You also need to know the platform alias. You can see all the platform aliases available by typing drush sa | grep platform.

First tell Aegir about the site, which creates a site alias.

drush provision-save --context_type=site --platform=@platform_d6 --db_server=@server_localhost --client_name=admin

Then run the provision-deploy:

drush provision-deploy /var/aegir/tmp/migrate/

Note: if you receive an error, you might also try adding the site to your new Aegir platform (using the same platform and site name, of course). Then run the provision-deploy again.

3. Verify the Platform

The final step is to import the site into Aegir. This is easily done by logging into the Aegir front-end and verifying the platform, which then will trigger an import task for the new site.

4. Caveats

The provision-save command will assume the database server is the same as the master server and that you are not using any install profile. So if your DB lives in another server or if you are using an install profile like openatrium you will probably need to edit the file created at /var/aegir/.drush/

5. Setting a Non-Default Install Profile

If you are using a non-default install profile, you may want to specify your install profile by adding --profile=profilemachinename to the drush provision-save command above.

Using the example above but using an install profile for Open Atrium, the command would look like:

drush provision-save --context_type=site --platform=@platform_d6 --profile=openatrium

Importing a single site manually


If you already have a platform setup on Aegir with EXACTLY the same codebase as your existing site, then you don't need to transfer the entire old codebase - you can just transfer the sites/ directory. However, you also need to make sure any dependencies on contrib modules that your site has, are covered on the codebase or Platform that you're importing it into.

In general it may be considered safer/less prone to confusing errors to transfer the entire old codebase into Aegir as a whole Platform, whereby the site will be imported automatically under that Platform. You can then migrate it in Aegir to one of your existing Platforms later. See importing from a complete Drupal platform for this method.

Also, it is much faster to just "deploy" an Aegir backup than go through the manual procedure here, so you should generally follow that procedure instead of the one defined here unless you have a very hairy setup.

To transer a site manually into Aegir, those are the steps you should follow:

1. Create the site database, user and directory

In order to import the site, you need to create a database and database user for the site, along with a directory in the platform.

The simplest way to do this is to create an empty site in the right platform and overwrite it. Through the commandline:

drush provision-save --context_type=site --platform=@platform_d6 --db_server=@server_localhost --client_name=admin
drush provision-install

Through the UI, this can be done simply by creating a site in Create content.

If this is not working for some reason, you can create the mysql user and database manually using the following:

CREATE DATABASE databasename;

2. Transfer the files

You need to copy the sites/ directory from your old server to the new Aegir server.

To do this, first create a tarball of the site on the old server. Within the sites/ directory type:

tar -zcvf .

Then, on the Aegir server, you can create a directory for it in the codebase (platform) you want to put it under:

cd /var/aegir/platforms/drupal-X.Y/sites
-zxvf ./files ./modules ./libraries ./themes

Instead of using wget you could of course use SCP or FTP to transfer the tarball onto the Aegir server.

In the above we assume that you have created an empty site as directed above, if not, you will also need to extract the settings.php file, so that last command should instead be simply:

tar -zxvf

Then you will need to modify the settings.php file to follow the user and database created in the first step. Again, this is not necessary if you let Aegir create the site for you.

Once the file is unpacked, check the ownership and group of each file by using ls -al. It should be either 'aegir:aegir' or 'aegir:www-data'. Change it if necessary. In particular, files that may have been uploaded on your site via modules like imagecache, upload, Profile pics etc, may need to have their ownership changed:

sudo chown -R aegir:www-data $platform/sites/*/files

3. Transfer the Database

Make a backup of the database on your old server (Backup and Migrate module is good for this, or you can use phpmyadmin or your favourite MySQL management tool. It's a good idea to truncate the cache, search and watchdog tables first to reduce the size of the database. The "Backup and Migrate" module does this for you.

If you are importing a site from a previous Aegir installation somewhere, such as from a backup tarball, the database.sql will already be within the tarball you unpacked. You can use this to import into a new database on your new server.

You can import the database with drush using the following command:

drush sqlc < database.sql

4. Verify In Aegir

In the Aegir web interface click on the name of the platform you have added your site to. You can access the list of platforms via the 'Platforms' tab in the primary links menu.

Execute a new Verify task on this platform via the 'Verify' button in the task list.

Aegir will now re-verify the platform. In the process of this, it will discover your new site and spawn a new 'Import' task for the site.

Once it's done this (it may take a couple of cron runs to dispatch these tasks in the queue) the tasks should turn green (if not, see 'Troubleshooting' below).

At this point, presuming you have updated DNS or are overriding DNS via an entry in your /etc/hosts file to access the site via the new Aegir server, you can visit the site in a browser and check around to see that it has worked. Pay particular attention to any links in node content that pointed to paths referencing /sites/ if your site was not part of a multisite setup. (Drupal has a habit of storing these paths in the database, or they may have been hard-coded into nodes by users).

Aegir will not go through all your database and update all URLs, so some images or links may be broken. This will need to be done manually. Aegir does attempt to update paths stored in tables such as 'files' though.

It's a good idea to clear the caches, and you may need to get imagecache to rebuild its thumbnails if you use it.

Importing a complete Drupal platform


This way of importing sites is often considered the safest whereby you transfer across an entire codebase containing Drupal core, and define it as a Platform first. This makes sure you bring any dependencies, contrib modules etc, in exactly the same version and configuration that is referenced in the database for the site.

1. Transfer the codebase

Create a tarball of the codebase on the old server. Within the drupal root directory type: tar -zcvf * .htaccess

Note that we have to specify including the .htaccess because it isn't picked up by the * wildcard due to being prefixed with a full stop. It is important to bring along the .htaccess for a platform so that Aegir can consider these settings when it generates Apache configuration for this platform.

Then, on the new server you can create a directory for it in the codebase you want to put it under:

cd /var/aegir/platforms
mkdir your-new-platform
cd your-new-platform

Instead of using wget you could of course use SCP or FTP to transfer the tarball onto the Aegir server.

Once the file is unpacked, check the ownership and group of each file by using ls -al. It should be either 'aegir:aegir' or 'aegir:www-data'. Change it if necessary. We have to assume you have basic knowledge of Linux and POSIX permissions - we can't be responsible for teaching you sysadmin skills :)

In particular, files that may have been uploaded on your site via modules like imagecache, upload, Profile pics etc, may need to have their ownership changed: sudo chown -R aegir $platform/sites/*/files

If your site previously resided in sites/defau1t you need to move it because Aegir ignores the default directory (it has no way of understanding what URL this would be accessed by, so it is impossible to 'manage' it). Each site needs its own directory with the correct domain in typical Drupal multisite design:

mv sites/defau1t sites/

If you do this, you may need to also update your filepath's stored in the files table by running the following query on your database:

UPDATE files SET filepath = REPLACE(filepath, 'sites/defau1t', 'sites/');

There are many other places in the database that can suffer the same problem, the node_revisions table for example. If you have phpMyAdmin available you can easily search the entire database for 'sites/defau1t'. Select the database, then click the Search tab. Once you know which tables are affected you can run a variation of the above query to correct these records.

2. Transfer the Database

Note: This step is not necessary if you are moving your site from one directory on your server (e.g., /var/www/html) to a newly created Aegir directory on the same server (e.g., /var/aegir).

Make a backup of the database on your old server (Backup and Migrate module is good for this, or you can use phpmyadmin or your favourite MySQL management tool. It's a good idea to truncate the cache, search and watchdog tables first to reduce the size of the database (Backup and Migrate does this for you).

Aegir does not provide support for importing databases with prefixed tables so it is best to remove prefixes form the database. However, there is work to bring this support in ( and a solution if you want to keep prefixes on your tables (

Unlike traditional Drupal projects the database settings cannot be found in settings.php. The database credentials are stored in the Apache vhost config of the associated site. This is a security measure implemented by the Aegir project.

In the vhost directory on your old server, /var/aegir/config/server_master/apache/vhost.d/, is a vhost file for every site on your server. The contents of the file can be displayed in your terminal with the command cat thenameofthefile. At the top of the file you will find the credentials needed to create a database on the new server.

On your new server, manually create a new database and upload the .sql file from your backup.

Then create the mysql user that your site accesses the database as, and grant it all permissions on that database except 'GRANT'.

Connect to the database on the old server: mysql -u root -p

Create the new database: create database yourdatabasename

Add the user: CREATE USER 'yourdatabaseuser'@'localhost' identified by 'youruserpassword';

Give the necessary privileges: GRANT ALL PRIVILEGES ON yourdatabasename.* TO 'yourdatabaseuser'@'localhost';

Import the database: mysql -u yourdatabaseuser -p -h localhost yourdatabasename < thenameofthedatabase.sql

3. Setup Platform in Aegir

In the Aegir web interface click on 'Create Content' and 'Platform'. This step is often easiest when using the admin-menu on the top of your screen.

Enter the name you want to use for the platform (eg 'My Platform import'), and the path to the platform on the server (eg '/var/aegir/platforms/your-new-platform')

Click Save to submit the form, and Aegir will spawn a Verify task for this platform into the queue.

Once the task is complete this the task should turn green (click through to the homepage to refesh and check. If not, see 'Troubleshooting' below).

4. Import and Verify Sites In Aegir

Upon completion of the above Platform verification task, Aegir will discover your new site and spawn a new 'Import' task for the site.

Once it's done this (it may take a couple of cron runs to dispatch these tasks in the queue) the tasks should turn green (if not, see 'Troubleshooting' below).

At this point, presuming you have updated DNS or are overriding DNS via an entry in your /etc/hosts file to access the site via the new Aegir server, you can visit site in a browser and check around to see that it has worked. Pay particular attention to any links in node content that pointed to paths referencing /sites/ if your site was not part of a multisite setup. (Drupal has a habit of storing these paths in the database, or they may have been hard-coded into nodes by users).

It's a good idea to clear the caches, and you may need to get imagecache to rebuild its thumbnails if you use it.

5. Migrate To Another Platform

Now that you have your sites under Aegir's control you can take advantage of its power, and easily migrate them to another platform. In the event that your sites were on old versions of Drupal core and a new one is available and present as another Platform on your Aegir server, you can use the Migrate process to upgrade those sites onto the new core.

For details on how to Migrate sites, consult the Migrate documentation.

6. Troubleshooting

For those who are migrating existing sites that live with their files in the sites/ folder, things can get tricky. However, you can follow this tutorial and successfully get things moved over rather easily.

Setting up a test Aegir site from an existing one

We have already seen how to import sites in an Aegir install, but what if we want to test the "hostmaster" site itself, ie. setup a development or staging environment of an Aegir install itself?

This page explains how. The basic steps are:

1. Installing aegir

The first step should be fairly simple and intuitive if you got that far: you have to install aegir itself on the staging server. You should install the specific version that is currently in production.

Maybe that also involves uninstalling the existing install.

2. Backup the production site

Run a backup on the production site, on the production server. This can be done in the frontend or in the backend using:

drush @hostmaster provision-backup

3. Deploy the production site in staging

Copy the resulting backup to the staging server. Then you should be able to deploy it with the following command:

drush @hostmaster provision-deploy /home/anarcat/ --debug

In this case, we use deploy to also rename the site (

4. Tweaking the install for the staging server

The environment on the staging server could be very different from the production server. The server name will be different, maybe there will not be a dedicated mysql server, platforms will not exist, etc.

It is recommended to review the "Servers" page to change the domain names to the staging environment. In Koumbit's case, this means:

  1. editing the master server to change the hostname and IPs
  2. renaming the DB server to "localhost" and changing the database credentials
  3. renaming the main hostmaster site:
    drush @hostmaster sqlq "UPDATE node n JOIN hosting_context h ON h.nid = n.nid SET n.title='' WHERE name='hostmaster';"
    drush @hostmaster sqlq "UPDATE node_revisions nr JOIN hosting_context h ON h.nid = nr.nid JOIN node n ON n.vid = nr.vid SET nr.title='' WHERE'hostmaster';"
  4. change the sites to point to the good web and db servers:
    UPDATE hosting_site SET db_server=3631 WHERE db_server <> 3631;
    UPDATE hosting_platform SET web_server = 3 WHERE web_server <> 3;

Note that this will have the added benefit of reverifying all platforms and therefore create them if they are makefile-based.

5. Troubleshooting

I had weird issues with failing to run updatedb on the hostmaster site (while deploying to another alias would work). My workaround was to suspend the process right before it would run drush updatedb, then run updatedb manually, twice:

drush @hostmaster updatedb
drush @hostmaster cc all
drush @hostmaster updatedb

Troubleshooting creating a platform or importing sites

First things to check:

Does the aegir user have proper permissions?

sudo chown aegir -R PLATFORM/sites/yoursite

Is the database properly set up? Try drush sql-cli to see if the site db user has access and if there are tables (try SHOW TABLES).

If something goes wrong with importing a site you might end up with a node for a non-working site. In such a case it can be good to delete the node for this non-working site and verify the underlying platform again. Since there is no direct way to delete such a node from the user interface you have change the URL from node/NUMBER/edit into node/NUMBER/delete to do this.

Remote servers (multiserver)


Aegir supports multiple 'server' entities. These servers have 'services' such as 'Web' or 'Database', and 'service types' which are implementations of that service, such as 'Apache' or 'MySQL'.

Some previous experience in the configuration of Apache and MySQL will help if you want to use remote servers with Aegir. If you haven't had any experience in setting up and maintaining Apache or MySQL before you might want get familiar with the basic concepts first.

1. Remote web servers

1.1. System dependencies

On the remote server, install these packages

  apt-get install rsync apache2 php5 php5-cli php5-mysql postfix mysql-client sudo

1.2. Aegir user

Any number of remote web servers may be configured. The remote server needs an aegir user created on the system.

adduser --system --group --home /var/aegir aegir
adduser aegir www-data    #make aegir a user of group www-data

1.3. Web server configuration

You'll also need to prepare the web server in the same way you did for the master Aegir server during installation:

a2enmod rewrite
ln -s /var/aegir/config/apache.conf /etc/apache2/conf.d/aegir.conf

Don't restart Apache even when it prompts you. This will be done by the Verify task you'll spawn for the server from the Aegir frontend later.

1.4. Sudoers

Add the aegir user to sudoers so it can restart Apache (e.g. sudo visudo -f /etc/sudoers.d/aegir):

aegir ALL=NOPASSWD: /usr/sbin/apache2ctl

1.5. Login shell

The remote aegir user will also need a login shell, which can be modified using the chsh command.

chsh -s /bin/sh aegir

1.6. MySQL access

Aegir connects directly to the remote server's MySQL to create databases and users. Therefore, you need to log into MySQL in the remote server as root and create a user with the following command:



  • 'root' is the username on the Aegir server that will be connecting. Leave 'root';
  • 'aegir_server_ip' is the IP address of your Aegir server. For example '';
  • 'password' is the password that will be used by your Aegir 'root' user to connect to the remote server's MySQL to create databases and users. It is suggested to store that password in a secure location. To increase security, it is recommended to choose a password with 6 to 16 alphanumeric and or punctuation characters.

If MySQL returns something like "Query OK", that means the command was successful. For example:

Query OK, 0 rows affected (0.00 sec)

Note the comment about "bind-address =" on

When the server is being verified, Aegir will attempt to create a database and grant privileges to a user for that database. If any of these two fails, verify that your MySQL configuration is correct and that there is no firewall blocking your MySQL port.

You can confirm that MySQL is configured correctly on the remote server by manually connecting from the command line on your Aegir machine:

[aegir@aegir_box:~]$ mysql -h <mysql_server_IP> -u root -p

If your MySql database is running on the same server as the Aegir master and is configured with the name "localhost", you may run an issue where the remote web server tries to access MySql via a local socket rather than the hostname. To resolve this, just change the server hostname for the MySql server in Aegir from "localhost" to the hostname of the server.

1.7. SSH keys

SSH public/private keys should be set up so the main Aegir server's aegir user can access remote web aegir users with no passwords required.

Example: on main Aegir server:

ssh-keygen -t rsa
(follow prompts)

Do not use a passphrase when you create your key. Simply press Enter to leave the passphrase blank. Otherwise, SSH will insist that you enter the passphrase everytime you try to SSH using the key. We don't want SSH to present any prompts.

Put the public key's contents into /var/aegir/.ssh/authorized_keys on the remote web server. The easiest way to do this is to use the ssh-copy-id command.

You should manually login for the first time from your Aegir master server to your remote server as the aegir user, so that the remote web server is added to the known_hosts file in /var/aegir/.ssh on your Aegir master server. Verifying the remote webserver will fail until this has been done.

You can confirm that SSH is set up correctly by manually connecting from your aegirmaster server to your remote server as aegir@ user to aegir@ user:

[aegir@aegirmaster:~]$ ssh aegir@<remoteserver>
This should directly log you into the remote shell command line without any additional keys pressed.

There are many, many tutorials online for setting up ssh keys, and various mistakes can be made by inexperienced users such as permissions etc. Aegir isn't a 'Linux beginner's practice tool', so setting these up is really out of the scope of this document and users are encouraged to research this on their own. (For Ubuntu, see this article).

If you have followed the instructions above, and your SSH connection gets closed immediately after you try to connect to the remote server as the aegir user, you may not have given the aegir user a shell correctly. Check the /etc/passwd file on the remote server to make sure that the aegir user has a shell.

1.8. Verify the server

Now you can add a new server node in Aegir, set the hostname and/or IP and set the service type to be 'Apache' (or Apache_SSL if this site is to handle SSL sites).

A verify task will be spawned and added to the Task queue ready for dispatching. During a server verification task, various configurations will be set on the Aegir master server and also synced to the remote web server, restarting Apache.

Now when you add a new Platform node in Aegir, you have the option of setting which web server to host it on. If you are not using a makefile but are downloading a platform manually, you must still do this on the main Aegir server. The contents will then be synced across to the web server.

You don't choose a web server when installing a new site. Because a site depends on a platform, its web server is implied by which platform has been chosen. In other words, all sites on a platform are hosted on the same server. You cannot host two sites on the same platform on different servers.

sudoers.png68.03 KB

Remote webserver configuration


Any number of remote web servers may be configured. They need an aegir user and webserver configuration, with the same user name and directory paths. SSH public/private keys should be set up so hostmaster's Aegir user can access remote web Aegir users with no passwords. The above Apache configuration needs to be performed too.

Additionally, the remote web server needs the 'mysql' client binary installed so that Aegir can test that it can successfully connect to the database server. On (at least) Debian-based systems, this can be installed via the 'mysql-client' package.

They will also need a login shell, which can be modified using the chsh command.

Shell commands as root::

apt-get install mysql-client
adduser --system --group --home /var/aegir aegir
adduser aegir www-data    #make aegir a user of group www-data
chsh -s /bin/sh aegir
apt-get install rsync apache2 php5 php5-cli php5-mysql
mkdir /var/aegir/.ssh
cat > /var/aegir/.ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...UF aegir@filer01
chown aegir:aegir /var/aegir/.ssh -R
chmod 750 /var/aegir/.ssh
chmod 640 /var/aegir/.ssh/authorized_keys
a2enmod rewrite
ln -s /var/aegir/config/apache.conf /etc/apache2/conf.d/aegir.conf
cat > /etc/sudoers.d/aegir <<EOF
Defaults:aegir  !requiretty
aegir ALL=NOPASSWD: /usr/sbin/apache2ctl
chmod 440 /etc/sudoers.d/aegir

For clusters, use the aegir-cluster-slave package to operate the above and NFS mounts for you. See also web cluster configuration documentation.

Adding a platform on a remote web server

Especially if you have been using Aegir for a while simply because it handles updates, moving to new releases, cloning, aliases and everything Drupal with such elegance on a single server - you might not be entirely clear on what changes when you make the move to multiple servers. Hopefully this will help.

Understanding the process

Multiple servers are great even if you do not have to manage a server farm. Having a server for development that you are free to break, one for testing that you hope will not break, one for approvals so your clients can go to see how their "real" website will look, and one for production that serves the daily grind of live sites is a wonderful thing. This DTAP (Development, Testing, Acceptance, and Production) structure works and it is surprisingly easy to accomplish under Aegir.

If you are managing a farm, creating massive numbers of servers is quick and easy with Aegir - especially if you use virtual machines like Xen where a server image can be cloned or generated using LVM disks that can be migrated (even while running) to other physical machines.

When it is time break out an Aegir master controller and remote slaves you have to remember that Aegir is the place that it (almost) all happens. Everything is stored in Aegir - including your remote platforms and your sites - and then distributed to the slave servers by Aegir in the Verify process.

Remember too that sites reside on platforms, and platforms reside on servers. You are turning your Aegir install into an Aegir Master as the hub, and the Aeger Remote Slaves as the spokes. To move into this "hub and spoke" architecture, you must build the remote server, tell the Aegir Master about that server and verify it, install a Drupal platform for that server on the Aegir Master and finally tell the Aegir Master about that Drupal install and verify that. You then create the sites on the platform you want based upon the install profile you select for that site. Need more? How about an example:

The mechanics

(1) Build a server image on your network to become your Aegir Slave. This can be anything from a separate headless server to a Virtual Machine image on physical machine with a dozen other Virtual Machines on it. As long as it has its own IP and is capable of running a Drupal image, it will work.

(2) Ensure that your new server image is resolved in your DNS by adding it to your zone files and incrementing the serial number in the zone file. Aegir can manage that for you now to some extent, but you might want to wait until that feature leaves the experimental status. Make sure the entries in /etc/hostname and /etc/hosts all match your zone files (including reverse DNS). Reload/restart the DNS server. Any DNS slaves should automatically get notified and the incremented serial number should make sure they reload automatically. Test the resolution and ping the new Aegir Slave server image from the Aegir Master to Ensure that the IPs all resolved properly.

(2) Follow the steps in the Aegir Handbook page at carefully. You should be able to use cut and paste if you are using Debian Stable or the like. In any case, you will need those packages. You do not need Aegir on the slave, but you do need the aegir user and that user must have a shell. I prefer the bash shell, but the sh shell in the instructions will do.

(3) You need to have the "passphraseless" ssh working and proven before you continue. A web search on the terms "passphraseless ssh" plus your operating system will generally get you great instructions, but putting those instructions here for every possible combination is beyond the scope of this example. In terms of helpful hints, however, you do not need to have a password for the aegir user on the Aegir Slave. Your access will be this certificate. By simply hitting enter when it asks for the passphrase, you make the certificate passphraseless. You should carefully set the permissions and back these certificates up to a secure location. You MUST log in manually from the Aegir Master to the Aegir Slave the first time or your verify will fail. This is because the system has to add the ssh keys to the known hosts and it will ask about about it before it will allow the connection. Aegir nows nothing about this and will not answer, so the verify will fail. To be absolutely sure it works, after exiting the initial login, you should retry the login to verify it does not ask for a password and then exit the login and try an rsync (which is the process by which the Aegir Master controls the Aegir Slaves). All of these commands should work from the Aegir Master to the new Aegir Slave while logged into the Aegir Master as the aegir user with no request for a password, proving that the systems are exchanging keys (do not proceed until you can do this flawlessly without having to enter a response):

##  Start from the Aegir Master as the aegir user
# Log in to the slave from the Aegir Master and exit without any password or reply required
# Create a test file for rsync
echo 'rsync test file' > MyRsyncTest
# Send the test file to the remote slave by name using rsync
rsync -azvv /var/aegir/MyRsyncTest
# Log back into the remote slave
# Make sure the file is there and readable
cat /var/aegir/MyRsyncTest
# Delete the test file from the remote slave
rm /var/aegir/MyRsyncTest
# Exit the ssh login session on the remote
# Delete the test file on the Aegir Master
rm /var/aegir/MyRsyncTest

(4) Go to Add Content/Server and put in the server name, leave the Database set as None (Your sites will use the Aegir Master database and none is required on the Remote Slave) and under Web select apache or apache ssl (to match the example) then click Save. After the process completes you should see that it found the IP address properly on its own, plugged it in all by itself and then Verify quite nicely. If you look on the Aegir Slave remote server you will see that you now have directories named config and platform.

(5) Now that hard decision for platform choice comes in play. My preference is a Drupal install that is the same release as the Aegir Master server or higher. Since sites are eventually destined to be Drupal 7 one day, and the Aegir system is not Drupal 7 ready as of this writing but heading that direction, making at least one Drupal 7 slave is a good idea so that you can migrate sites to that platform as they are ready. If you are migrating sites off of your existing Aegir and onto slaves, migrating to platforms of the same Drupal version makes that process much easier. In any case, firm up your decision about which Drupal version you want to install on your new Aegir Slave Platform.

(6) Time to create that platform. The big thing here is to do it right the first time and make certain that the name of the platform is unique to any platform on your Aegir Master server. If you look in your /var/aegir directory you will notice that Aegir has its own naming convention. For instance, you should see /var/aegir/hostmaster-0.4-rc1 as the platform for the Aegir 0.4 release candidate 1. You need to consider doing the same. For instance, name your platform something like: /var/aegir/slavename-drupal-version and you will make it easier to distinguish which server the platform resides upon and the drupal version so that you can manage updates and migrations more easily. Make certain that you are not destroying one platform when creating another. Be aware that at some point Aegir started organizing platforms into a separate directory: /var/aegir/platforms and you should change to that structure if you have an older original install. Again, be careful you are not overwriting an existing install when you create the new one. For instance, if you already have a Drupal install in /var/aegir/platforms/drupal-7.14 the code below will attempt to recreate it on top of the existing install. If you are using a Makefile, be sure that the same problem does not occur in that makefile. To create a Drupal 7 Aegir Remote Slave Platform, log into the Aegir Master as the aegir user and run this simple code (of course edit it to match the platform and name you want to create:

# Make sure you are in the proper directory
cd /var/aegir/platforms
# Install Drupal 7.14
drush/drush.php dl drupal-7.14
# Rename the platform to your own naming convention
mv /var/aegir/platforms/drupal-7.14 /var/aegir/platforms/slavename-drupal-7.14

(7) The final step in creating this platform is to actually tell the Aegir Master about it so that it can distribute it (via rsync) to the new Aegir Remote Slave. Simple enough. Just go to Create Content/Platform and the Create Platform screen comes up. Under Name write something descriptive and unique. In the example so far, this will be something like 'slavename Drupal 7.14' or in some way adhere to your chosen naming convention. I use the directory name I created above since that serves two purposes. Under Publish Path you will put the path that holds this Drupal distribution. In the example above that will be /var/aegir/platforms/slavename-drupal-7.14 but the path will be reflected from the Aegir Master to the Aegir Slave and will be the same on both. If you are using a Makefile you need to enter the full path and name of that Makefile here as well, but the creation and use of the Makefile is beyond the scope of this example. Lastly choose the server that this platform will reside upon. When you are finished, double check the screen and then click on Save. The Verify step should execute flawlessly and when it does, your Aegir Remote Slave will be complete and ready to accept sites.

(8) Lather, rinse and repeat for each Aegir Remote Slave.

Creating sites on the remote

The only difference you will notice when creating a new site under Aegir will be the choice of platform. The Create Site screen is quite self explanatory, but the main thing is to select the Install Profile that you require and then the list of Platforms that support that install profile will be populated.

As usual, Aegir makes it all faster and easier than you expect.

Web clusters


Cluster module

The cluster module is a simplified solution for maintaining platforms across multiple web servers. A cluster server node does not require a physical machine to be present on the network. Simply create web servers as usual and create a server node that has "Cluster" selected under the web field set of the server node add form. Select the servers that should be part of the new web cluster by clicking the check box next to each web server in the "Servers" section.

The cluster module will rsync the platforms between each web server and keep them up to date.

Pack module

A Pack consists of a single server node that is specified as "pack" and any number of server nodes specified as "apache" or "nginx". The main difference between the Pack functionality and Web Cluster functionality is that Aegir rsync's configuration (Apache & Nginx) to "all" nodes in the Pack and rysnc's the platform and site code to only the "master" node in the Pack. All other "slave" nodes will see the platform and site code via NFS.

Configuring the Pack server node:

The "pack" server node will not be used by Aegir to physically deploy sites or platforms on, so consider it more of a 'virtual server group' for logistical purposes only. When creating the pack node, you do not need to supply a valid Server hostname or IP address, so choose a naming convention that makes sense in your environment.

Next, select the "pack" radio button option under the web configuration when creating or editing the server node, in order to designate this server node as the "pack" server.

Now select the "Master" server from the list of Master servers. The Master server will be the server node that Aegir rsync's the platform and site to. Typically, you would choose the Aegir server itself as the 'master'.

Finally, select the "Slave" servers from the list of Slave servers. The Slave servers will have the Apache or Nginx config rsync'd to them but not the platform or site code, since those will be available to all Slave servers via the NFS share.

Configuring the Web server nodes (Master and Slaves):

Configure all web server nodes using these instructions. Take care to ensure the 'aegir' user and group on your NFS client machines, have the same UID/GID as that of the NFS server, or else you may run into permissions issues with NFS.

Then mount the files on the remote server.

On the NFS server:

sudo apt-get install nfs-kernel-server
echo "/var/aegir/platforms,no_subtree_check)" >> /etc/exports
sudo service nfs-kernel-server reload

(Replace the subnet here or add specific /32 hosts as necessary for your environment)

Then on the web servers (Master, if it wasn't also the NFS server, and the Slaves):

sudo apt-get install nfs-client
sudo mount /var/aegir/platforms

(Replace the NFS server's IP here with that of your master server/Aegir server)

Add this to your fstab on the servers that mount the NFS share, so that the share is mounted on boot: /var/aegir/platforms nfs rw 0 0

Creating a Platform on a Pack:

When configuring a Platform to be deployed on a Pack, choose the "Pack" server node from the Web server radio group during the Platform node creation. Then you choose this Platform as usual when adding a site, and that site will be served from any servers within the Pack.


Relying on an NFS share to serve your entire /var/aegir/platforms can be a single point of failure if the NFS share becomes unavailable. You may want to look into providing some sort of failover for NFS (google for things like DRBD and Heartbeat), or using some other form of redundancy for your NFS (Netapp filer clusters etc)

There have also been reports of issues with MySQL GRANT statements not being provided to all webservers in the pack - especially where the master server is not the Aegir hostmaster server. This issue is ongoing - see the Talk page here or this ticket

Also attached is an example diagram of a Pack cluster known to be functioning in production (with an optional MySQL-MMM cluster out of scope for this documentation), which may help you visualise the Pack and how it can be put together.

aegir_pack.png41.2 KB

Setting Up Varnish & Memcache with Aegir


I had the hardest time finding resources & documentation on how to get this configured properly so I am adding this to the documentation for those of you who may need it.

A couple of notes: I am using Ubuntu 10.04 LTS. I set my apache to port 8082 because there was a conflict on port 8080 on my system. You should make a copy of each file before editing it. Memcache settings are drupal 7.


Setting up varnish isn't too hard but it could end up being kind of tedious if you configure something incorrectly & you have alot of sites.

First you install it sudo apt-get install varnish

Then you have to go to configure it. I use vim. sudo vim /etc/varnish/default.vcl

These are my settings.

backend default {
    .host = "";
    .port = "8082";
    .connect_timeout = 600s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 600s;
sub vcl_recv {
  // Remove has_js and Google Analytics __* cookies.
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
  // Remove a ";" prefix, if present.
  set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
  // Remove empty cookies.
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;

// Skip the Varnish cache for install, update, and cron
  if (req.url ~ "install\.php|update\.php|cron\.php") {
    return (pass);

// Cache all requests by default, overriding the
  // standard Varnish behavior.
  // if (req.request == "GET" || req.request == "HEAD") {
  //   return (lookup);
  // }
sub vcl_hash {
  if (req.http.Cookie) {
    set req.hash += req.http.Cookie;

Now you have to edit /etc/default/varnish sudo vim /etc/default/varnish

Here are my settings

# Should we start varnishd at boot?  Set to "yes" to enable.
# Maximum number of open files (for ulimit -n)
NFILES=$(ulimit -n)
#Malloc size depend on your memory server
DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,512M \
             -u www-data \
             -g www-data"

Now we have to configure apache's listening ports

sudo vim /etc/apache2/ports.conf


NameVirtualHost *:80
Listen 80

So that it looks like this

NameVirtualHost *:8082
Listen 8082

Start varnish services varnish start

Now login to aegir Edit your server & change the port from 80 to 8082

Aegir will re-verify the server, as well as all platforms & sites on the server.

If that doesnt work, you need to go to /var/aegir/config/server_master/apache/vhost.d and edit all of your virtual hosts so that the port shows 8082 instead of 80 then do the same thing with /var/aegir/config/server_master/apache.conf Reverify your server.

Now add this to the local.settings.php of the sites that you want to leverage varnish

# Tell Drupal it's behind a proxy
$conf['reverse_proxy'] = TRUE;
# Tell Drupal what addresses the proxy server(s) use
$conf['reverse_proxy_addresses'] = array('','your-ip-address-here');
# Bypass Drupal bootstrap for anonymous users so that Drupal sets max-age &gt; 0
$conf['page_cache_invoke_hooks'] = FALSE;


There is hardly any current documentation for setting up memcache on D7, especially not for aegir.

FIrst you install memcache & its dependencies Download & install memcache module into the platform of the site/sites in which you will be using memcache

Then you have to edit /etc/default/memcached sudo vim ./etc/init.d/memcached

Here are my settings

#! /bin/sh



start_instance() {
        echo -n $"Starting $prog ($1): "
        start-stop-daemon --start --quiet --pidfile /var/run/memcached/memcached.$ --exec $DAEMON -- -d -p $PORT -u $USER  -m $2 -c $MAXCONN -P /var/run/memcached/memcached.$ $OPTIONS
        [ $RETVAL -eq 0 ] && touch /var/lock/memcached.$1
        PORT=`expr $PORT + 1`

stop_instance() {
        echo -n $"Stopping $prog ($1): "
        start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/memcached/memcached.$ --exec $DAEMON 
        if [ $RETVAL -eq 0 ] ; then
            rm -f /var/lock/memcached.$1
            rm -f /var/run/memcached/memcached.$
start () {
        # insure that /var/run/memcached has proper permissions
        mkdir -p /var/run/memcached
        if [ "`stat -c %U /var/run/memcached`" != "$USER" ]; then
                chown $USER /var/run/memcached

        start_instance default 64;
        start_instance block 16;
        start_instance content 128;
        start_instance filter 128;
        start_instance form 32;
        start_instance menu 16;
        start_instance page 8;
        start_instance update 8;
        start_instance views 8;
        start_instance path 8;
        start_instance field 8;
        start_instance rules 8;
        start_instance token 8;
        start_instance image 8;
        start_instance apachesolr 16;
stop () {
        stop_instance default;
        stop_instance block;
        stop_instance content;
        stop_instance filter;
        stop_instance form;
        stop_instance menu;
        stop_instance page;
        stop_instance update;
        stop_instance views;
        stop_instance path;
        stop_instance field;
        stop_instance rules;
        stop_instance token;
        stop_instance image;
        stop_instance apachesolr;

restart () {

# See how we were called.
case "$1" in
        status memcached
        echo $"Usage: $0 {start|stop|status|restart|reload|force-reload}"
        exit 1

exit $?

Start memcache sudo services memcached start If you see errors u may have an issue where a one line got split into two lines. Check and make sure that none of your lines got broken off.

Place this code in your local.settings.php file inside your site folder

// the path to the core cache file
  // the path to the memcache cache file
  // make MemCacheDrupal the default cache class
  $conf['cache_default_class'] = 'MemCacheDrupal';
  # Key Prefix: edit this for multisite use.
  $conf['memcache_key_prefix'] = "$_SERVER[db_user]";
  $conf['memcache_servers'] = array(
  '' => 'default',
  '' => 'menu',
  '' => 'filter',
  '' => 'form',
  '' => 'block',
  '' => 'update',
  '' => 'views',
  '' => 'content',
  '' => 'apachesolr',
  '' => 'path',
  '' => 'field',
  '' => 'rules',
  '' => 'token',
  '' => 'image',    
$conf['memcache_bins'] = array(
  'cache' => 'default',
  'cache_menu'   => 'menu',
  'cache_filter' => 'filter',
  'cache_form'   => 'form',
  'cache_block'  => 'block',
  'cache_update' => 'update',
  'cache_views'  => 'views',
  'cache_views_data'  => 'views',
  'cache_content'  => 'content',
  'cache_apachesolr'  => 'apachesolr',
  'cache_path'  => 'path',
  'cache_field'  => 'field',
  'cache_rules'  => 'rules',
  'cache_token'  => 'token',
  'cache_image'  => 'image',

And that should be basically it.

Working as aegir user

It can be convenient to do stuff as the aegir user. The default shell of the aegir user is /bin/false, so you have to make sure to use something more usable:

sudo su - aegir -s /bin/bash

GNU Screen is a super useful window manager for the console. When launching screen you will usually get errors like

Cannot open your terminal '/dev/pts/6' - please check.

You can get around this by running

script /dev/null

All in all this works nicely:

sudo su aegir -s /bin/bash -c "script -q /dev/null"

It can be convenient to put it in a little script as /usr/local/bin/suaegir

Allowing other users besides root on your system to run commands as aegir

If you wish to allow other users on your system to run commands as the aegir user using sudo, without allowing them to use sudo generally, you can add the following two lines to your /etc/sudoers file using visudo:

User_Alias      AEGIRUSERS = comma, separated, list, of, users
AEGIRUSERS      ALL = (aegir) ALL

If you want to allow these users to use aegir without entering a password, simply change the second line to this:


Adding apache config files


If you connect to your Hostmaster server and look at ~aegir/config/server_examplecom/apache.conf, you can see that this file includes files from pre.d and post.d directories. The includes are done in the following order:

  1. pre.d
  2. vhost.d
  3. platform.d
  4. post.d

The earlier files take precendence over the later files for <VirtualHost> blocks. The latter files take precedence over earlier files for <Directory> blocks.

If we wanted to add a phpini directive that can only be set on a PHP_INI_PERDIR-for example, post_max_size-we could create a file called upload.conf and add it either to pre.d or post.d.

Here's a possible upload.conf:

# Custom Server-wide configuration #
# our php.ini sets memory limit to 96M
# post_max_size should also be less than memory_limit.

php_value post_max_size                90M
php_value upload_max_filesize          85M
If we put upload.conf in pre.d, our setting would always take precedence, because it occurs higher up the chain of include files.

If we put upload.conf in post.d, our setting would be applied only if the same setting is not defined higher up the chain by the aegir code. As Antoine states here post.d is mainly useful when migrating in sites. It would also be useful if you wanted to set a server-wide default which could be overridden on by a virtual host or platform config setting.


Using SSL



SSL support was significantly improved in Aegir 0.4 alpha9 and subsequent releases have further refined the SSL functionality. Here are the current steps to configure SSL support in Aegir and apply it to your web sites.

Prepare Your Server

  1. Make sure port 443 is open for SSL traffic.
  2. From the command line, install SSL software for your web server (e.g. on Debian/Ubuntu you can use sudo apt-get install openssl).
  3. Enable SSL support (e.g. sudo a2enmod ssl). You will need to restart Apache at this point.

Enable SSL Support in Aegir

  1. You have to enable SSL support in Aegir as it is off by default. Assuming the URL of your Aegir front end is, browse to how to get to the Aegir features page
  2. Click on Experimental to reveal experimental features experimental features of Aegir
  3. Check SSL support
  4. Click Save configuration

Configure Your Aegir Server

  1. Click on the Servers tab
  2. Click on the server that you wish to enable SSL support
  3. Click Edit to change the server configuration
  4. Click apache_ssl (this will reveal an additional field: SSL port, which should be already populated with 443).enabling SSL on your Aegir server
  5. You may also have to add an IP address to the IP addresses field. The field is used as an "IP pool" for SSL certificates: IPs are assigned to SSL sites when they are created on a first come, first served basis. (Note that there are known issues with this process, see issue #1126640 for details.)
  6. Click Save - this will start various tasks beginning with a verify task on the server followed by verify tasks on all platforms that are associated with that server
  7. If all goes well you will see the following changes in your Aegir file system structure: a new /var/aegir/config/ssl.d directory and a new /var/aegir/config/server_master/ssl.d directory.

The /var/aegir/config/ssl.d directory is where you will be able to manipulate SSL keys and certificates, for example by importing commercial SSL certificates or generating a new key. Do not manually edit the /var/aegir/config/server_master/ssl.d directory as changes to that directory will be overwritten when the server or site are verified.

Configure Your Aegir Site

  1. You must enable SSL on your sites that are on those platforms associated with the server. Browse to
  2. Click Edit to change the site configuration
  3. Choose the type of Encryption required and the Encryption key (see the explanatory notes below each option). configuring an Aegir site for SSL NOTE:, Alternatively, you may specify a directory under /var/aegir/config/server_master/ssl.d where your own certificate and key is to be stored (see Apache notes below).
  4. Click Save. Aegir will then generate a certificate and private key for your web site and insert these into a new VirtualHost directive in your vhost file. (This file is typically at /config/server_master/apache/vhost.d/
  5. If all goes well the VirtualHost directive will now have these important elements:

<VirtualHost xx.xx.xx.xx:443> # <-- where xx.xx.xx.xx is an IP address dedicated for SSL access to your site and 443 is the port number

    # Enable SSL handling.
    SSLEngine on

    SSLCertificateFile /var/aegir/config/server_master/ssl.d/
    SSLCertificateKeyFile /var/aegir/config/server_master/ssl.d/

Now, when you navigate to you should see that your site is SSL enabled. It will, however, generate warnings in your browsers because it is a self-signed certificates. See below for how to use commercial certificates to remove this warning.

Notes for Apache users with Commercial Certificate File(s)

If you wish to use your own commercial certificate and key you will need to do the following:

  1. Follow the directions above, using the "Generate new encryption key" option and using your site's domain name for the "New encryption key". This will create a site directory under /var/aegir/config/ssl.d/ With this step, you have created a self-signed certificate, and your site is now configured to use it.
  2. This generated a 2048 bit RSA key for you along with a CSR (Certificate Signing Request). If you prefer to generate your own RSA key, replace the files (openssl.key and openssl.csr) in the /var/aegir/config/ssl.d/ directory with your RSA key and associated CSR.
  3. Copy and paste the .csr file into the form for the issuing Certificate Authority (CA) to create your certificate.
  4. When your certificate has been generated, download the files from the issuing authority and place in your temporary folder on your PC. You may have more than one .crt files, in this case you have a "bundle" or what we call a "certificate chain" that you need to add in aegir (see below).
  5. Transfer all the files to /var/aegir/config/ssl.d/ Rename the site .crt file to openssl.crt. If you have a certificate chain, install it in openssl_chain.crt. You should have at least three files in the directory (openssl.crt, openssl.key, openssl.csr, and optionnally openssl_chain.crt).

Verify your site from aegir's frontend.

You should now be able to access your site via https:// using your commercial certificate.

Notes for Nginx users:

It is recommended to allow Aegir to create a default self-signed certificate and key first, and then replace the contents of both files (not the files itself) with your real key and certificate. Any chained certificates (bundles) should be included in the same file, directly below your own certificate - there is no need for extra files/lines like it is for Apache configuration.

site-ssl-configuration_0.png26.91 KB




There is preliminary support for DNS in Aegir's backend that allows it to manage zonefiles dynamically when sites are created. There are still a few major bits missing (described in this meta-ticket) so we generally recommend people use the wildcard approach for now.

That said, while perhaps not yet ready for production use, Aegir's DNS functionality can be quite useful for local development environments. If you run Aegir locally, you're probably in the habit of hacking /etc/hosts regularly, or if you're more adventurous, you've set up a local DNS forwarder, such as dnsmasq. With Aegir's DNS feature, you can avoid this hassle, and let Aegir handle it transparently.

While Aegir supports both BIND and dnsmasq, this documentation will focus on the former. The first step is to install BIND. On Debian-based distros, this will look like:

apt-get install bind9

Next we need to allow the aegir user to run rndc (the name server control utility). On recent Debian systems, this will involve editing /etc/sudoers.d/aegir, whereas on older releases this would be /etc/sudoers. Modify the aegir line to read:

aegir ALL=NOPASSWD: /usr/sbin/apache2ctl, /usr/sbin/rndc

Then we need to make sure the bind user has access to read Aegir's files, so we'll add bind to the aegir group:

adduser bind aegir

We're now ready to activate the feature in Aegir's frontend. Go to Hosting >> Features (admin/hosting/features) and select "DNS Support" under the "Experimental" fieldset, and save the configuration.

Finally, we need to activate DNS on the Aegir server. Visit the server node (hosting/c/server_master) and click the edit tab (which should bring you to node/2/edit). Then under "DNS Service", select "Bind" and then save.

This should trigger a verify of the server (and then probably the platforms on it too), after which Aegir will be managing your local BIND server, and it's zonefile(s). If you have installed Aegir in /var/aegir, put this line in the file /etc/bind/named.conf.local:

include "/var/aegir/config/bind.conf";

Aegir is now a full-fledged DNS server that you can use to resolve addresses locally. This can be accomplished on Debian-like systems by editing /etc/resolv.conf to include "nameserver". If you're running Aegir in a VM, you can just point this to the address of the virtual machine.


You need to have a working DNS/bind/named server for AEgir to take control of. What follows is rough documentation to reach that stage. It is currently UNTESTED in a production environment.

yum -y install bind-chroot bind-utils bind-libs bind
chkconfig named on
ln -s /var/named/chroot/var/named/named.conf /etc/named.conf
cat >> /etc/named.conf << EOF
controls {
        inet allow {
} keys {
options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        // Those options should be used carefully because they disable port
        // randomization
        // query-source    port 53;
        // query-source-v6 port 53;
        forwarders {; };
        forward only;
//      allow-query     { localhost; };
//      allow-query-cache { localhost; };

logging {
        channel default_debug {
                file "data/";
                severity dynamic;

view localhost_resolver {
        match-clients      { any; };
        match-destinations { any; };
        recursion yes;
        include "/etc/named.rfc1912.zones";

    // Add local zone definitions here.

    include "/var/aegir/config/bind.conf";

include "/etc/rndc.key";
service named start

Additional Notes

Additional documentation can be found in the Provision DNS module:

DNS Wildcard Configuration

Why run a wildcard DNS server?

A wildcard DNS setup lets you automatically have subdomains for a given domain. For example, say you own the domain and you want to setup an unlimited number of subdomains like,,, etc.... Typically you would have to set these all up individually. A wildcard DNS can let you bypass a lot of configuration. In a development environment it can let you setup any number of test/development sites very quickly and easily. Drupal developers in particular can leverage Drupal's multisite installation feature to setup lots of sites for development or production very quickly.

Creating a DNS wildcard with hosted DNS

Many of the popular domain registration companies allow you to manage your DNS records through a web interface. If you have access to such a facility, adding a DNS wildcard is easy: you just create an A record called '*', pointing to your server's IP address.

For convenience, here are instructions for some popular hosting providers: GoDaddy, (which uses the popular cPanel system) and It is likely that your host will have a similar system to one of these.

How to configure DNS wildcards on your own server


OS X Snow Leopard

Setting up a Wildcard DNS configuration on Ubuntu/Debian

Overview of Steps on Ubuntu/Debian

I. Install Bind 9 II. Add a zone to /etc/bind/named.conf.local. Check the syntax of named.conf.local with named-checkconf III. Add a zone file & Check the syntax of your zone files for errors with named-checkzone IV. Edit /etc/resolv.conf V. Start up Bind VI. Check setup with dig VII. Troubleshoot if needed

I. Install Bind 9

$ sudo apt-get install bind9

II. Edit /etc/bind/named.conf.local to add a zone.

We need to add a zone to /etc/bind/named.conf.local. A zone is a record for a domain. In this case we'll use a fake domain for development purposes. Our domain can be called anything. Let's call it mydev. (I was really tempted to call the domain bullshit - would have been great for screencasts). So at a shell prompt do:

$ sudo nano /etc/bind/named.conf.local

Add this to the end of the file:

zone "mydev" {
type master;
   file "/etc/bind/db.mydev";

Save the file with Control - O and enter. Exit from nano with Control X.

Check the syntax of the file as follows:

$ named-checkconf /etc/bind/named.conf.local

If the file is syntactically correct the shell prompt will return nothing. If there is an error - make sure you did not miss a quote or semicolon and recheck the file.

III. Add a zone file & Check the syntax of your zone files for errors with named-checkzone

$ sudo nano /etc/bind/db.mydev

Add this to the file replacing with your IP address

mydev. 86400 IN SOA mydev. hostmaster.mydev. (
               20091028 ; serial yyyy-mm-dd
               10800; refresh every 15 min
                3600; retry every hour
                 3600000; expire after 1 month +
                86400 ); min ttl of 1 day
  IN NS mydev.
          IN MX 10 mydev.
        IN A
*.mydev. IN A

Save the file with Control - O and enter. Exit from nano with Control X. Check the syntax with the following:

$ named-checkzone mydev /etc/bind/db.mydev

If the syntax of the file is correct you should see something like:

zone mydev/IN: loaded serial 20091028

If not review the file for errors. In particular whenever referring to a domain, it must end in a . , thus mydev.

IV. Edit /etc/resolv.conf

resolv.conf tells applications like browsers where to look for DNS info. By default it may have your ISPs info. We need to tell it to check our local DNS server first then the ISP.

$ sudo nano /etc/resolv.conf

Add/change the following

domain mydev
search mydev
nameserver (your isp nameserver or open dns)

If you are receiving an IP address via DHCP then you need to edit /etc/dhcp3/dhclient.conf too.

$ sudo nano  /etc/dhcp3/dhclient.conf

Look for the lines send host-name, supersede domain-name, and prepend domain-name-servers and set them as follows (and make sure they are uncommented ) :

send host-name "mydev";
supersede domain-name "mydev";
prepend domain-name-servers;
sudo dhclient

Whew! Almost there.

V. Start up Bind (or Restart)

$ sudo /etc/init.d/bind9 restart

VI. Check setup with ping and dig

$  ping testing.mydev
PING testing.mydev ( 56(84) bytes of data.
64 bytes from ubuntu.local ( icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from ubuntu.local ( icmp_seq=2 ttl=64 time=0.039 ms
64 bytes from ubuntu.local ( icmp_seq=3 ttl=64 time=0.0

If ping works then you should be good to go. If not try dig and part V. To stop the ping action press [Ctrl]+[c].

VII. Troubleshoot

I found the section on Troubleshooting Bind in O'Reilly's "Linux System Administration" helpful. Fortunately, this part of the book is viewable on Google books as of this writing (10/29/2009): . See page 66

Getting a Wildcard DNS running on OSX Snow Leopard

Note: it took me several tries to get this working. If you are new to DNS be patient with yourself - you'll get it, but may take a few tries.

In this example I will concentrate on setting a development environment with OSX using wildcard DNS

Overview of Steps

I. Edit /etc/named.conf to add a zone.
II. Add a zone file at /var/named/ III. Check the syntax of named.conf and your zone files for errors IV. Edit /etc/resolv.conf V. Set your computers network settings to use as a name server VI. Start up Bind VII. Check setup with dig VIII. Reboot if needed

Before we start a few more notes.

I tend to use the nano text editor to edit Unix configuration files you could use Emacs, VI, Textmate, BBEdit or the editor of your choice.

Backup all these files we are editing so you can start over if you mess up. I didn't do this and it added more time to the project. For example to backup /etc/named.conf do:

$ sudo cp /etc/named.conf /etc/named.conf.bck

Last, most of the files we need to edit are owned by root so you will need to use sudo to edit these files. If you get tired of typing sudo you can become root by doing this:

$ sudo -s

Be careful when working as root or using sudo. You can mess up your system so make sure to backup. All example here are run as root.

I. Edit /etc/named.conf to add a zone

We need to edit named.conf to add our zone.

$ nano /etc/named.conf

I called my zone vmdev so I added this to named.conf

zone "vmdev" IN {
        type master;
        file "db.vmdev";

I added this right before the zone 0.0.127.inaddr.apra and saved the file. So we told Bind to look in /var/named/db.vmdev for this zone.

II. Add a zone file at /var/named/

$ nano /var/named/db.vmdev
vmdev. 7200    IN       SOA     vmdev. root.vmdev. (
                                        2008031801 ;    Serial
                                        15      ; Refresh every 15 minutes
                                        3600    ; Retry every hour
                                        3000000 ; Expire after a month+
                                        86400 ) ; Minimum ttl of 1 day
                IN      NS      vmdev.
                IN      MX      10 vmdev.

                IN      A
*.vmdev.        IN      A

You can just copy this but be sure to change to you Mac's IP address

III. Check the syntax of named.conf and your zone files for errors

Run this to check your named.conf file:

$ named-checkconf /etc/named.conf 

If it returns nothing, your named.conf file is at least syntactically correct. If there is an error, then well you have to diagnose and fix the error.

Now run this to check your zone file:

$ named-checkzone vmdev /var/named/db.vmdev

It should return something like this:

zone vmdev/IN: loaded serial 2008031801

If there are errors then diagnose and fix them.

IV. Edit /etc/resolv.conf

$ nano /etc/resolv.conf
# Mac OS X Notice
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
# This file is automatically generated.
domain vmdev.

V. Set your computers network settings to use as a name server

Do this at System Preferences -> Network. You may want to use your ISPs Name server as the second name server

VI. Start up Bind

$ launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist

The -w option tells OSX to enable Bind at startup

VII. Check setup with dig

$ dig faker.vmdev 

Should return something like this:

; <<>> DiG 9.6.0-APPLE-P2 <<>> faker.vmdev
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45640
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;faker.vmdev.                   IN      A

faker.vmdev.            7200    IN      A

vmdev.                  7200    IN      NS      vmdev.

vmdev.                  7200    IN      A

;; Query time: 0 msec
;; WHEN: Wed Oct 14 19:28:56 2009
;; MSG SIZE  rcvd: 75

The key here is status NOERROR; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45640 If you get an error then check previous steps.

Now try:

$ ping faker.vmdev

should return:

PING test.vmdev ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.059 ms
64 bytes from icmp_seq=1 ttl=64 time=0.087 ms

but if it does not got to VIII.

VIII. Reboot if needed.

I needed to reboot to get everything to take. Whoila! Have a cookie or something.

Hooking into Aegir (site overrides)


Because Aegir is capable of installing, deploying and moving your sites around, it has to manage the various configuration files that keep your sites running.

These configurations include the standard Drupal settings.php for a site, .htaccess overrides for your HTTP server, as well as HTTP 'VirtualHost' or 'vhost' configuration files that tell your HTTP server where your site is.

A caveat of this system is that Aegir regularly re-generates these configuration files to apply new changes that have been made to the sites or platforms, as well as doing so as a safety mechanism to ensure these files are 'sane'.

For example, if you make a modification to a site vhost or settings.php and it breaks your site, running a 'Verify' task on the site should restore the file back to how it was.

However, sometimes it is necessary to add custom configuration or overrides to these files, and you can't do that if Aegir is regularly wiping your changes.

Fortunately, Aegir provides a series of hooks and inclusions for overriding or injecting customisations into these files safely and persistently.

This chapter shows you how each of these hooks or inclusions work.

Injecting into server-wide vhosts


Changing maximum filesize upload is common when setting up sites in Drupal. As described in Overriding site-specific PHP values you can change this value for each site created with Ægir by adding a file in /var/aegir/.drush directory. But wouldn´t it be nice to be able to do it side-wide?

Here below is the same code from ergonlogic demonstrating how to create a file using the domain name as a condition before the code injection.

function ergonlogiccom_provision_apache_vhost_config($uri, $data) {
    if (
$uri == "") {
drush_log("Overriding PHP file size values. See .drush/");
      return array(
"php_value upload_max_filesize 100M", "php_value post_max_size 200M");

Apparently you can do this side-wide by omitting the IF statement and create a file with a extension.

For instance, you could create a file called and put in the following code:

function globalsettings_provision_apache_vhost_config($uri, $data) {
drush_log("Overriding PHP file size values. See .drush/");
      return array(
"php_value upload_max_filesize 100M", "php_value post_max_size 200M");
* the closing ?> syntax should not be used

Make sure you Verify your site after you create the file. Then scroll through the log and find the message you added in the code:

Overriding PHP file size values. See .drush/

Injecting into platform-wide vhosts (.htaccess)


Using a .htaccess with an Allow Override all directive in Apache can be a major performance killer, because it requires Apache to stat each subdirectory of the codebase looking for overrides in .htaccess.

As a result, Aegir disables the reading of the Drupal .htaccess in the runtime environment.

This does not mean that the .htaccess is not needed. Instead, when you run the Verify task against a Platform, the .htaccess is studied by Aegir and its contents are copied into the platform-wide Apache vhost configuration, typically located in /var/aegir/config/server_master/apache/platform.d

Need to make a modification to the .htaccess? Simple: you can simply edit it in-place as you normally would, but you must re-Verify the platform in Aegir afterward, in order for those new or modified settings to be 'loaded in' to the platform vhost file.

The end result is improved performance for your sites, without losing any functionality, as you can still customise the .htaccess to your liking.

Injecting into site vhosts


Aegir provides some hook functions in its API, one of which allows you to inject extra configuration snippets into your Apache vhost files for sites.

When would I want to do this?

A good example for this is when you may need to inject a custom Rewrite rule that goes beyond what the Aegir Aliases 'redirection' feature provides.

Or, perhaps you have to inject some htpasswd mod_auth password protection for your site, or perhaps a CustomLog definition. The http_basic_auth module uses this. (code)

Typically you'd just add what you need to the vhost file, but the problem is that Aegir manages these vhosts, and on every Verify task, will rewrite the config from a template, blowing away your changes in the process. Ouch!

Fortunately there is a very easy and elegant solution to this problem to save your configurations persistently across Verify tasks and the like, by means of invoking the Provision hook provision_apache_vhost_config(), or, if you are using Nginx, provision_nginx_vhost_config() (and just replace the below examples with 'nginx' instead of 'apache' where necessary). Below "mig5" is just an example, you can replace this with anything as drush looks for all * files in ~aegir/.drush

A simple example

In this example I'll inject a simple 'ErrorLog' apache definition into a vhost to save the site error logs to a file.

  1. Create a file in ~aegir/.drush called (Choose <any> prefix for the file name <any>
  2. Add this snippet of PHP to the file:

    function mig5_provision_apache_vhost_config($uri, $data) {
    "ErrorLog /var/aegir/" . $uri . ".error.log";
    (Choose <any> prefix for the function name <any>_provision_apache_vhost_config).
  3. drush cache-clear drush
  4. Install a site or verify an existing one

Check your site's vhost config file (in /var/aegir/config/server_master/apache/vhost.d/) and you'll see the line has been injected into the '#Extra configuration' area of the vhost

<VirtualHost *:80>

  DocumentRoot /var/aegir/hostmaster-HEAD
  SetEnv db_type  mysqli
  SetEnv db_name  1mig5forgenet
  SetEnv db_user  1mig5forgenet
  SetEnv db_passwd  X7KzsFhxhp
  SetEnv db_host  tardis
  SetEnv db_port  3306

# Extra configuration from modules:
  ErrorLog /var/aegir/
    # Error handler for Drupal > 4.6.7
    <Directory "/var/aegir/hostmaster-HEAD/sites/">
      SetHandler This_is_a_Drupal_security_line_do_not_remove


It's that simple! You can see that via the hook, we pass $uri and the drush data to the function, allowing me to abstract the site url so that each site will get its own error log. You could do extra PHP conditionals to ensure certain data only gets inserted into certain sites of a specific name.

To inject multiple lines instead of one, use an array, i.e

function mig5_provision_apache_vhost_config($uri, $data) {
    return array(
"ErrorLog /var/aegir/" . $uri . ".error.log", "LogLevel warn");

The key point of this is that the file ~aegir/.drush/ file will never be touched by Aegir, so you can rest assured your changes will be respected.

If you want to only inject code into a specific site, wrap your code with an if statement, i.e

function mig5_provision_apache_vhost_config($uri, $data) {
    if (
$uri === "<site-name-in-aegir>") {
        return array(
"ErrorLog /var/aegir/" . $uri . ".error.log", "LogLevel warn");

A more advanced example

Managing multiple versions of a production site can be a tricky proposition, even in Aegir. This is particularly true when you want to use the same canonical domain name to allow users to access one such site of your choosing at any given moment. For instance, in Aegir I might have a site named (with an alias of,) and a couple of alternates with the site names of and If I suddenly decide that I want my primary domain to access, Aegir forces me into a tedious process that ultimately results in site downtime – I have to delete or migrate the existing site to a new unused site name (or clone it to an unused site name, and delete the original) and then I have to migrate to the vacated site name Alternatively, I could add the and aliases to but then my users would just be redirected to

Given the way Aegir manages aliases, it would actually be easier to make this switch if the desired address was never used as a site name to begin with. Instead of having the site name alongside of the two other test sites, we might have, with in-use aliases of and, and a rewrite instruction in the vhost that rewrites to If we could easily change the rewrite instructions in that vhost, all we would need to do is move the aliases from one site to the next in the GUI (with the requisite verify tasks executed on each site in question) in order to quickly change which site was being loaded at any given moment by For example, if I wanted to move to, I would remove the and aliases from and verify, add those aliases to and verify, and change my vhost so that test2 is rewritten as Since as previously mentioned Aegir overwrites changes to the vhost during the verify process, the solution is to use the provision_apache_vhost_config hook in a file to selectively add the rewrite information to the vhost when verifying the site that we want our canonical domain to refer to.

function aliasredirects_provision_apache_vhost_config($uri, $data) {
// the uri to check here is the name of the site in Aegir
if ($uri === "") {
$rval[] = "";
$rval[] = "# Forces redirect to one uri";
$rval[] = "RewriteEngine On";
// if the host is not
$rval[] = "RewriteCond %{HTTP_HOST} !^$ [NC]";
// rewrite to with a 301 redirect
$rval[] = "RewriteRule ^(.*)$$1 [R=301,L]";
$rval[] = "";
When we want to switch again, say to, We could update the code to look for the uri.

Overriding site-specific PHP values

Sometimes it is useful to override certain PHP values on a per-site basis, but changes to php.ini are generally server-wide. Depending on the value you want to override, a couple of options present themselves.

First, let's consider where PHP values can be changed. lists php.ini directives, and under the "Changeable" column, indicates where a configuration setting may be set. If your value shows either PHP_INI_USER or PHP_INI_ALL, then the easiest way to change this value would be using ini_set() in a local.settings.php:

@ini_set('memory_limit', '128M');

On the other hand, if the changes mode is either PHP_INI_PERDIR or PHP_INI_SYSTEM, php_ini() won't work. In this case, the solution is to inject the value into the vhost. Since vhosts are managed by Aegir, manually adding an override to /var/aegir/config/server_master/apache/vhost.d/<uri> would get blown away the next time that the site is verified.

As described in Injecting into site vhosts, we can inject values into vhosts using a Drush hook. For example, to raise the file upload size limit on, I added the following code in /var/aegir/.drush/

function ergonlogiccom_provision_apache_vhost_config($uri, $data) {
    if (
$uri == "") {
drush_log("Overriding PHP file size values. See .drush/");
      return array(
"php_value upload_max_filesize 100M", "php_value post_max_size 200M");

This results in the insertion of the following lines into /var/aegir/config/server_master/apache/vhost.d/

php_value upload_max_filesize 100M
php_value post_max_size 200M

Also, in the verify task log I get the following informative message:

Overriding PHP file size values. See .drush/

One challenge this technique may present is inspecting the values of the parameters passed into this function. It appears that the Hostmaster site doesn't get bootstrapped, and so common debugging tools (such as devel.module's dd()) aren't available. However drush_log() is, and when called, will push arbitrary messages back into your Aegir site's verify task log.

So sticking the following into the function above can help:

("$uri: " . print_r($uri));

Injecting into settings.php



Every web site in an Aegir environment has a Drupal configuration file settings.php in /sites/ directory. Web administrators often need to make changes to this file; however, the Aegir system also manages this file and any manual customizations will be lost when a site is verified.

Fortunately, there are two mechanisms to ensure that your customizations can be preserved. If you look in the bottom of an Aegir settings.php file you will see references to two files local.settings.php and

# Additional host wide configuration settings. Useful for safely specifying configuration settings.
if (file_exists('/var/aegir/config/includes/')) {

# Additional site configuration settings. Allows to override global settings.
if (file_exists('/var/aegir/example-platform/sites/')) {

If these files exist they are loaded at run time by Drupal. As you can probably surmise from the paths to these files, local.settings.php is for site-specific customizations and is for Aegir-wide customization.

Let's look at these files in more detail. We'll use customization of user session cookies as an example. If you look at the settings.php file generated by Aegir you see that it sets more conservative php settings for cookies (@ini_set('session.cookie_lifetime',  0); i.e. cookies expire immediately) than are in the default.settings.php packaged with Drupal (@ini_set('session.cookie_lifetime',  2000000); i.e. 2 million seconds, which is just over 23 days).

Site-specific Customization

The local.settings.php file by default does not exist in a new Aegir site installation so you have to create it. Continuing with our example of user session cookies, let's override the Aegir default.

# site-specific Drupal customization

# override Aegir-generated cookie policy for sites - set cookies to expire after a week (604,800 seconds)
@ini_set('session.cookie_lifetime', 604800);

Note that because local.settings.php is included after the variables are set in the main settings.php it's customizations takes precedence.

Now, whenever you clone a site or migrate it between platforms, Aegir moves a copy of local.settings.php as well.

Using drush_hook_provision_drupal_config

You can also use the API to add module-specific site configurations with hook_provision_drupal_config

* Append PHP code to Drupal's settings.php file.
* To use templating, return an include statement for the template.
* @param $uri
*   URI for the site.
* @param $data
*   Associative array of data from provisionConfig_drupal_settings::data.
* @return
*   Lines to add to the site'
s settings.php file.
* @
see provisionConfig_drupal_settings
drush_hook_provision_drupal_config($uri, $data, $config) {
'$conf[\'reverse_proxy\'] = TRUE;';

For example it could look like this

function drupalwiki_provision_drupal_config($uri, $data, $config) {
$extra = drush_get_option('site_extra_settings', '');
// remove window CR
$extra = str_replace("\r",'',$extra);

That is used to add the site settings added by the UI in the hosting backend implemented in

Aegir-wide Customization

In some situations you may want to implement the same configuration settings on all your Aegir sites. This is where comes in. Note that is now included in settings.php before local.settings.php, so that Aegir system administrators no longer retain the ability to override configuration changes in local.settings.php, but instead it is possible to override global settings per site (read why this has been changed: - note: this change is available since 0.4-rc1 release).

For example, say the system administrator wanted to limit users' session lifetimes to a maximum of one day they could create a as follows:

# Aegir-wide Drupal customization

# override Aegir-generated cookie policy for all sites - set cookies to expire after a day (86,400 seconds)
@ini_set('session.cookie_lifetime', 86400);

You can even set more granular policy within (however it makes more sense to keep site-specific overrides in the local.settings.php):

# Aegir-wide Drupal customization

# override Aegir-generated cookie policy for all sites - set cookies to expire after a day (86,400 seconds)
@ini_set('session.cookie_lifetime', 86400);

# Make the aegir front-end server more secure by expiring cookies immediately
if (preg_match("/hostmaster/", $conf['install_profile'])) {
# set cookies to expire immediately on hostmaster
@ini_set('session.cookie_lifetime', 0);

If you are using Aegir to manage multiple remote webservers, you will need to run the Verify task on the webserver in order to push to the remote machine.

Note: on some Aegir installations (e.g. alpha14) the permissions on /var/aegir/config are insufficent for Apache to properly include the file. If you find that the configuration settings in are being ignored, change the permissions with chmod a+x /var/aegir/config. This only has to be applied to the config directory as the sub directory and file permissions should be correct.

If you have other configuration examples, create a wiki and reference it here.

Injecting into drushrc.php

The drushrc.php file can be changed in two ways:

  1. by changing the templates used for the Drushrc context (see the hook_provision_config_load_templates() hook)
  2. by creating a local.drushrc.php file in the site-specific folder (e.g. sites/

This is a stub. You can put more stuff here and it would be prettier.

Contributed Modules

1. Aegir 7.x-3.x

Contrib modules for the upcomming version are listed on a sub page

2. Extensions to Hostmaster (frontend)

2.1. Verified in Aegir 2.x

Aegir HTTP basic authentication (now included in hosting_tasks_extra)
This module allows you to protect sites with passwords.
Hosting server titles
This is a really simple module that allows you to change the names of servers that are displayed in lists in the Hosting frontend when choosing what server to use for something.
Hosting site Backup Manager
Add a backups tab to a site node. It extends the default backup functionality with the ability to download a backup over HTTP.
Now also includes the functionality from Hosting backup garbage collection and Hosting backup queue
Hosting site Git
This is a simple module for the Aegir project that adds a 'Git pull', 'Git checkout' and 'Git clone' task for sites.
Hosting platform Git
Provides integration with Aegir that allows provisioning a platform from a git repository (also allows specifying the branch or tag name)
Hosting tasks extra
This module extends Aegir hostmaster (and drush/provision) with some additional tasks. Such as: cache-clear and registry-rebuild.
Now also includes the functionality from Aegir HTTP basic authentication
Hosting database login
Provides a link to login into a PHPMyAdmin instance (or other db management web software) configured for the current site database server. Requires dblogin to be installed on the site.
Aegir Piwik integration
Makes it easy to connect an Aegir instance and a Piwik instance. When you create a site in Aegir, the site is registered in Piwik. When you verify the site in Aegir, new site aliases (if any) get added to Piwik. Also adds system variables to settings.php in order to integrate properly with the Piwik module.

Note: There's a good chance that other Aegir 1.x contrib modules also work on 2.x

2.2. Aegir 1.x

Aegir Ubercart Integration
This module allows you to sell an Ægir client, with quotas and access to specific platforms, through Ubercart . It automates a number of set-up tasks from the moment the order ...
Aegir HTTP basic authentication
This module allows you to protect sites with passwords.
Aegir HTTP basic LDAP authentication
A fork of the above to allow you to specify an LDAP server and Require (ldap filter) string for authentication of 'sites'.
Aegir feeds
This is a very basic module that provides feeds integration with Aegir . Features Provides mapping targets for Aegir site nodes, allowing you to create new sites from a feed or file upload.
Aegir Piwik integration
Makes it easy to connect an Aegir instance and a Piwik instance. When you create a site in Aegir, the site is registered in Piwik. When you verify the site in Aegir, new site aliases (if any) get added to Piwik. Also adds system variables to settings.php in order to integrate properly with the Piwik module.
Aegir Rules
Aegir Rules provides Rules integration for the Aegir.
Aegir Drush Make Platform working-copy
This feature allows you to specify 'working-copy' when adding a platform using a Drush makefile. Working-copy means your .git subdirectories are preserved in the platform, which may be useful for development purposes.
Aegir Subfolders
Support for '' style sites in Aegir (experimental as of July 2012)
Hosting Platform Pathauto
This is an add-on module for the Aegir hosting system: This module simply makes a little time-saving tweak when creating a new platform: ...
Hosting queue runner
This module allows the Hosting tasks queue for the Aegir project to be 'daemonized' so that tasks are run as soon as possible instead of waiting for a cron run. This makes Aegir appear much more responsive. This module was inspired by the Waiting queue project. Requirements You will need ...
Hosting Reinstall
The Hosting Reinstall module provides a frontend for the Provision Reinstall module so that you can reinstall any sites via Hostmaster (Aegir).
Hosting backup garbage collection
This is an add-on module for the Aegir hosting system: Introduction This module allows you to specify how long Aegir should retain backups for. You can specify, ...
Hosting backup queue
This is a simple module for the Aegir project that allows scheduling of backups. E.g. backup sites every hour, day or month. The module allows for the general settings to be applied to all sites, ...
Hosting site Backup Manager
Add a backups tab to a site node. It extends the default backup functionality with the ability to download a backup over HTTP.
Hosting site Git
This is a simple module for the Aegir project that adds a 'Git pull', 'Git checkout' and 'Git clone' task for sites.
Hosting upload
This module allows administrators to add platforms to aegir and extend platforms and sites with modules, themes, libraries without the need of ssh access.
Hosting Profile Roles
Hosting Profile Roles extends Aegir to enable more control over what role(s) a client is assigned during site install. Since, by default, Aegir client's are given UID1 during site installs, this module also allows UID1 to be assigned to another user.
Hosting server titles
This is a really simple module that allows you to change the names of servers that are displayed in lists in the Hosting frontend when choosing what server to use for something.
Services API Support
Integrates the Services API framework into the Hostmaster suite of tools. It allows Aegir managers the ability to build Services API connections over any of the available servers for Services API.
Hosting Advanced Cron
This module allows an administrator to set the default cron interval globally and to override that interval for individual sites.
Hosting Features
This module provides a Task to Hostmaster that provides integration with a site's Features. (In beta as of June 1,2012)
Hosting Notifications
This is a module that integrates with the Notifications framework. This allows you to receive notifications about task execution in various formats.
Hosting Task Garbage Collection (merged into Aegir 7.x-3.x)
This module will delete rows in the {hosting_task} and {hosting_task_log} tables. (In alpha as of June 1,2012)
Hosting Remote Import
This Drupal module provides a UI for fetching sites from remote Aegir servers. (In development as of June 1, 2012)
Hosting Varnish
Allows the Varnish cache for Aegir-managed sites to be purged via the user interface. (In alpha as of June 1,2012)
Hosting CivicCRM Cron
This module provides the ability to trigger CiviCRM cron jobs on sites hosted on the Aegir Hosting System.
Hosting tasks extra
This module extends Aegir hostmaster (and drush/provision) with some additional tasks. Such as: cache-clear and registry-rebuild.
Hosting Filemanager
This module provides a web file browser for viewing files under sites and platforms. (In beta as of August 29,2012)
Hosting Signup Settings
This module is dependent on hosting_signup module in the hosting package of Aegir. It allows the Signup form at /hosting/signup to be configured. (Sandbox project, October 22, 2012)
Hosting Client Roles
Client Roles module integrates Aegir user roles into hosting_products as product feature. With this module you can assign Aegir user roles to Ubercart products, and sell them as hosting products. This module is part of the "Hosting & Ubercart Integration" package, and depends on uc_hosting and uc_hosting_products modules
Hosting Solr
Works with Provision Solr to give Aegir the ability to manage Solr servers and and gives sites a Solr database.

3. Extensions to Provision (backend)

Provision boost support
the Aegir project and therefore depends on the provision backend and expects the Aegir environment to be functional. Quickstart Download the provision_boost code into your /var/aegir/.drush/ Download ...
Provision ACL support
This drush command aims to provide preliminary ACL support for the Aegir backend . The objective here is to allow administrators to set more granular access policies on files managed by Aegir and resolve more hairy access permissions requirements than what is usually allowed by the Aegir core. ...
Project Status
Project status is an extension for drush which takes a list of drupal platforms as arguments and returns a list of modules which are not in use by any site within these platforms. It is also optionally able to list modules which are use, by platform and site.
Provision CiviCRM
A Drush module to automatically setup Drupal instances with the CiviCRM Constituent Relationship Management solution. It is specifically aimed towards the Aegir project.
Provision Backup Platform
This hooks into deleting a platform and creates a simple tar backup.
Koumbit's "standard Drupal platforms", a set of makefiles to build and maintain development and production platforms easily.
Provision Git
Provision Git is a backend Drush module. It provides 4 drush commands. (In alpha as of June 1,2012)
Provision Merge Log
This Aegir extension allows you to automate fetching and merging logs from multiple servers part of the same cluster in a single logfile for later analysis with various analysis tools
Provision CDN
This is a simple module and drush script for that allows you to enable CDN support per site in Aegir. (In development as of June 1,2012)
Provision profile settings
Incredibly simple extension for provision that allows install profiles to easily inject settings into settings.php for provisioned sites.
Provision New Relic
This is a simple extension that exposes all sites in New Relic, so you can monitor each sites performance.
Provision Solr
Works with Hosting Solr to give Aegir the ability to manage Solr servers and and gives sites a Solr database.

4. Themes

  • Koumbit has provided it's custom Aegir theme as a sample subtheme of Eldir.
  • Saeven, a clone of the core theme Seven, based on Omega 4 or 5, clean, simple and responsive.

5. Puppet modules and Chef cookbooks

Those projects allow you to manage Aegir instance(s) through Puppet. Chef recipes also welcome, we don't discriminate.

6. Others

Aegir up
Aegir-up is a Drush extension that deploys a local instance of the Aegir Hosting System atop Vagrant and Virtualbox, for development and testing purposes.
DevShop is a Drupal Development Environment Manager built on Aegir.

DevShop creates Aegir platforms and sites automatically from Git URLs. It tracks multiple Projects and allows multiple environments to be created for each Project, such as dev, test, and live. It provides tools to Pull Code, Sync Data, Commit Features, and Run Tests on these environments, and provides a dashboard with useful links and information for developers.

7. Your module here?

Developers: Please add your contributed module here, and feel free to put install instructions or other documentation in a child page. If you are looking for ways of extending Aegir or have already done so and want to document the internals of your module, head over to the extending Aegir page.

Aegir Services

Aegir Services integrates the Services API framework into the Hostmaster suite of tools. It allows Aegir managers the ability to build Services API connections over any of the available servers for Services API.

Using Services 3.x we are aiming at full CRUD support for clients, tasks and sites, as well as read access to profiles, platforms, and eventually, packages.

The 2.x branch of Aegir Ubercart Integration will take advantage of this support to provide a remote storefront functionality.

Please report issues and request support via the issue queue on


  1. Install Aegir
  2. Install the dev version of services 3.x, including at least one server and, ideally, an authentication server.
  3. Install this module.
  4. Configure your endpoint, it's resources and authentication, normally.
  5. Optionally, test your rest server using the included bash script,

Contribs for Aegir 7.x-3.x

1. Extensions to Hostmaster (frontend)

Hosting Git
This is a simple module for the Aegir project that adds a 'Git pull', 'Git checkout' and 'Git clone' task for sites.
The successor of Hosting site Git & Hosting platform Git
Hosting Logs
This is a simple module for the Aegir project that adds a 'Logs' tab to sites and platforms. Showing Apache error, Git commit and watchdog logs.
Hosting Platform Pathauto
This is an add-on module for the Aegir hosting system: This module simply makes a little time-saving tweak when creating a new platform: ...
Hosting site make
Allows a site to have its modules built from a makefile in the sites directory.
Hosting tasks extra
This module extends Aegir hostmaster (and drush/provision) with some additional tasks. Such as: cache-clear and registry-rebuild.
Now also includes the functionality from Aegir HTTP basic authentication

2. Extensions to Provision (backend)

Starting from Aegir 7.x-3.x the Drush component can be included in a 'drush' directory in the same git repository as the hosting module.

Therefore this list will be shorter then for previous versions.

Provision STS
Adds the Strict Transport Security header to hosts that require SSL.

3. Themes

4. Puppet modules and Chef cookbooks

Those projects allow you to manage Aegir instance(s) through Puppet. Chef recipes also welcome, we don't discriminate.

5. Others

Aegir up
Aegir-up is a Drush extension that deploys a local instance of the Aegir Hosting System atop Vagrant and Virtualbox, for development and testing purposes.
DevShop is a Drupal Development Environment Manager built on Aegir.

DevShop creates Aegir platforms and sites automatically from Git URLs. It tracks multiple Projects and allows multiple environments to be created for each Project, such as dev, test, and live. It provides tools to Pull Code, Sync Data, Commit Features, and Run Tests on these environments, and provides a dashboard with useful links and information for developers.

Aegir Pathologic Files
A tiny Drupal Module to simplify file paths in content. This helps prevent broken images when the site directory name changes. Requires an apache rewrite rule to point /files to /sites/, which Aegir provides by default.
This module is not for hostmaster, but for the sites hosted under Aegir.

6. Your module here?

Developers: Please add your contributed module here, and feel free to put install instructions or other documentation in a child page. If you are looking for ways of extending Aegir or have already done so and want to document the internals of your module, head over to the extending Aegir page.

DevShop Provision


DevShop Provision

Drupal development infrastructure made easy.

This module provides the backend commands needed to deploy and manage sites using the DevShop git and features based development workflow.

About DevShop

The goals of DevShop are...

  1. to simplify management of multiple environments for multiple Drupal projects.
  2. to provide web-based tools that streamline the Drupal site building workflow.
  3. to provide a common, open-source infrastructure for Drupal development shops.


To install devshop_provision, simply use drush:

$ drush dl devshop_provision

Or, you can download the source code to any available drush commands folder, such as /usr/share/drush or ~/.drush


DevShop Provision works by providing a new Provision class called "Project".

To start, you must have a Project drush alias. Using the DevShop+Hostmaster system will make this much easier, but if you wish to only use the backend, you can create a project alias with provision-save, for project NAME:

  $ drush provision-save project_NAME --context_type=project --code_path=/var/aegir/projects/NAME --git_url=http://git.url/to/repo.git

    $ drush provision-save project_NAME --project_name=NAME --context_type=project --code_path=/var/aegir/projects/NAME


DevShop contains a set of features that make Drupal site building within a version-controlled code workflow quick and easy.

Currently you must create new platforms within a project in hostmaster. Once created, you can execute the following commands:

1. Pull Code

  $ drush @project_NAME provision-devshop-pull ENVIRONMENT

This task runs on the dev platform for this project. It runs git pull, and optionally runs new updates, reverts features, and clears caches. It is used to keep the dev server up to date on every commit via the devshop_pull module, and can be used as the deployment task.

  • Git Pull the code for your site's platform.
  • Then, all optionally:
    • Run update.php.
    • Revert all Features modules
    • Clear caches

2. Commit Features

  $ drush @project_NAME provision-devshop-commit ENVIRONMENT --message="My Commit"

This task integrates with Features.module to make it very easy to commit your changes to your features.

  • Calls drush features-update-all
  • Commits the result, with a part automated and part customized commit message.
  • (Optionally) pushes the commits.
  • (Optionally) force-reverts after a commit.

3. Sync Content

  $ drush @project_NAME provision-devshop-sync SOURCE_ENVIRONMENT DESTINATION_ENVIRONMENT

This task makes it easy to syncronize the database and files down from other environments within the project.

WARNING: This will DESTROY the destination site's database!

This task:

  • (optionally) Pulls code
  • Drops the @destination database.
  • Creates an SQL dump from @source.
  • Copies the SQL dump to the local system (if @source is a remote).
  • Imports the SQL dump into @destination database.
  • (optionally) Runs update.php.
  • (optionally) Runs features-revert-all.
  • (optionally) Clears all caches.


$ drush --filter=devshop_provision

All commands in devshop_provision: (devshop_provision)
provision-devshop-co  Export the site's Features and commit the result.                                             
mmit (pdc)                                                                                                          
provision-devshop-pu  Pull & verify platform code and (optionally) run update.php, clear cache, and revert features.
ll (pdp)                                                                                                            
provision-devshop-sy  Sync database (and files, coming soon) from a chosen source site.                             
nc (pds)                                                                                                            
provision-devshop-te  Run a group of SimpleTest tests.                                                              
st (pdt)                                                                                                            

$ drush provision-devshop-commit --help

Export the site's Features and commit the result.

drush @project_mysite              Recreates and Commits all features from the dev environment of @project_mysite with an additional commit
provision-devshop-commit dev       message.                                                                                                
--message="changed some settings"                                                                                                          

environment                               The name of the environment to commit from.

--message                                 Add a commit message                                     
--revert                                  Force revert all features after exporting and committing.

Aliases: pdc

$ drush provision-devshop-pull --help

Pull & verify platform code and (optionally) run update.php, clear cache, and revert features.

drush @project_mysite                    Triggers a git pull and a clear cache command on @project_mysite's dev and test environments.
provision-devshop-pull dev test --cache                                                                                               

environments                              A list of environment names to Pull Code to.

--update                                  Run update.php after code pull.     
--revert                                  Revert all features after code pull.
--cache                                   Clear all caches after code pull.   

Aliases: pdp

$ drush provision-devshop-sync --help

Sync database (and files, coming soon) from a chosen source site.

drush @project_mysite            Syncs the database from for project_mysite's live to  project_mysite's dev server.
provision-devshop-sync live dev                                                                                    

from                                      Environment to sync from.
to                                        Environment to sync to.  

--update                                  Run update.php after content sync.     
--revert                                  Revert all features after content sync.
--cache                                   Clear all caches after content sync.   
--files                                   Sync site files.                       

Aliases: pds

$ drush provision-devshop-test --help

Run a group of SimpleTest tests.

environment                               The name of the environment to run tests on.

--tests-to-run                            The list of tests to run.                    
--sync-from-live                          Sync contents from Live before running tests.

Aliases: pdt

Provision ACL

This page documents the Provision ACL extension to Aegir which allows more granular access control over your sites files and directories.

1. Install instructions

First, you'll need a running Aegir install (1.0-rc3 or later), see Most (if not all) of these commands will have to be run as root (or using sudo, etc.)

1.1. Download and install provision

drush dl provisionacl-6.x

1.2. Enable ACLs on your filesystem

mount -o remount,acl /

Here we assume everything is under the root (/) filesystem here, otherwise run this command for every filesystem Aegir will work on (e.g. /srv, /var or /home).

You also need to edit your /etc/fstab for this configuration to survive reboots.

1.3. Install ACL support package

apt-get install acl

1.4. Create a UNIX group

In this case we choose a group called "devs" but you can choose another name.

groupadd devs

1.5. Add users to the group

Add one or more UNIX users that you want to give access to that group. For an existing user (socrates32), this would look like:

usermod -a -G devs socrates32

For a new user (ergonlogic), this would look like:

useradd -G devs ergonlogic

1.6. Create a client

Create a client (should be called "devs" for this example) in the frontend at /node/add/client.

1.7. Create a site

Create a site for the client in the frontend at /node/add/site.

2. What it does

When the site is installed, members of the "devs" group will be able to write to the sites' directories (e.g. upload files and modules) and run drush commands on the site (yes, including site aliases, although see caveats below).

This works also for existing sites; make sure you create a group matching the internal name of the existing client and reverify the site.

3. LDAP integration

Provisionacl supports LDAP groups as well. Ensure that an LDAP client is running and that the 'aegir' user can see the LDAP-provided groups:

getent groups

You may need to restart the Name Service Cache Daemon (nscd):

/etc/init.d/nscd restart

4. API - how to add ACL support to your Aegir extension

To change ACLs on files, you should use something like this:

if (function_exists('provisionacl_set_acl')) {
    provisionacl_files_acls(d()->site_path . '/mysettings.php');

You can optionnally pass a group as an argument, but it will guess that from the client name of the site. Also note that this will raise a drush error if setfacl fails, but just set a warning if the group doesn't exist.

5. Caveats (ie. what it does not)

Giving shell access to users in Aegir is still insecure, see this upstream issue: #762138.

We aim to refactor this into the Aegir core in 2.x, but in the meantime this should provide a good workaround for the limitations of the existing permission system.

This will only work in 1.0 and above, as it needs the "client_name" field to be populated.

You will need to change your $HOME variable for aliases to work, because of this bug in drush: #1104438. Example:

env HOME=/var/aegir drush @hostmaster cc all

See also this post for context and design.

6. Debugging

If for some reason you have lost the ACLs on the directories and you need to restore them, use the following commands, which is basically what the module does:

cd sites/
setfacl -R -m user:aegir:rwx .
setfacl -R -m default:user:aegir:rwx .
setfacl -R -m group:www-data:rwx .
setfacl -R -m d:group:www-data:rwx .
setfacl -R -m group:cl-group:rwx .
setfacl -R -m default:group:cl-admin:rwx .

7. Notes

This page is the reference documentation for the Provision ACL module page on - keep this in mind when editing please.

Ubercart Integration

This module provides several features to ubercart products on an Aegir platform.


  • Hostmaster 6.x-1.0 or higher
  • Ubercart 6.x-2.4 or higher
  • Patience


  1. Download the module and its dependencies into sites/all/modules on your hostmaster platform (drush @hostmaster dl uc_hosting ubercart should work)
  2. Activate the clients feature for hostmaster (admin/hosting/features)
  3. Enable the module uc_hosting_products. This should enable all dependencies (drush @hostmaster en uc_hosting_products)

Creating your first site product

N.B. A video introduction covering configuration is available from the DrupalCon London session Aegir-based Business Models (starting at 26:30).

  1. Create a product. Make sure it is not shippable. (node/add/product)
  2. Edit the product. Go to the features tab.
  3. Choose the "Create a site and adjust quotas accordingly" feature. It should use the sku of your product automatically.
  4. For single-site products, make sure, on the product feature form, to check off "Force clients to create their site on purchase" if you want to be sure people create their site.
  5. Now all you need is a drupal platform that any user can create sites on and you are ready to go. (node/add/platform)

Creating more complex offerings using product kits

The method we recommend for creating complex offerings, including multiple site quotas and access to restricted platforms, is via Ubercart product kits.

  1. Enable uc_product_kit.
  2. Create one or more uc_hosting products.
  3. Create a product kit with these products in them in the appropriate quantities.


You can report bugs, request support and propose patches via our issue queue on


If you would like to use uc_hosting to develop your own Aegir dependant product features, be sure to read the relevant documentation.

Check out the roadmap.

Other Resources

Provision CiviCRM

provision_civicrm helps to manage the installation and upgrades of CiviCRM in Drupal sites managed with Aegir.

CiviCRM is not a typical Drupal module. It is a third-party system that integrates with Drupal, WordPress and Joomla for its front-end and permission system. CiviCRM has its own installer, upgrade system and cron. The "provision_civicrm" module helps to manage any CiviCRM+Drupal site as any other Drupal site managed in Aegir.


  • Aegir 2.x or 3.x
  • hosting_civicrm must be installed in the hostmaster front-end (~/hostmaster-x-y/sites/


Download the provision_civicrm module as the "aegir" user:

drush dl provision_civicrm-6.x-2.x

This should install the module in ~/.drush/provision_civicrm.

NB: provision_civicrm 6.x-2.x is a Drush module, and works with both Aegir 2 and Aegir 3. However, for Aegir 3, you must use the 7.x-3.x branch of the hosting_civicrm module.

Creating a CiviCRM platform

provision_civicrm assumes that if you have a CiviCRM installation in your sites/all/modules/civicrm, then this is a CiviCRM platform and CiviCRM should be installed automatically.

(A cleaner way, in theory, would be to have an install profile and let the user configure it through the front-end, patches welcome! -- however, you do not want any site to simply enable CiviCRM from the Drupal admin/build/modules, so having dedicated platforms for CiviCRM makes sense in any case.)

A sample drush makefile is provided with provision_civicrm.

Assuming you are running as the user 'aegir', whose $HOME is /var/aegir/, save this in a file such as ~/makefiles/drupal-6.22-civicrm-3.3.4.make

Then create the new platform:

mkdir ~/platforms/drupal-6.22-civicrm-3.3.4
cd ~/platforms/drupal-6.22-civicrm-3.3.4
drush make ~/makefiles/drupal-6.22-civicrm-3.3.4.make

You can now add your platform in the Aegir front-end and then create new sites.

Create a SUDO user for server administration

Sometimes you will need to administer your server beyond what you can do as the Aegir user.

Examples include installing additional software or editing PHP configuration.

It's not recommended to use the root user for administering things as it can be easy to make mistakes that could break your system.

Instead of running as root, it is recommended to create a user for yourself that has sudo privileges.

Create a user with SUDO privileges

In ubuntu/debian systems, creating a user and giving them the ability to run commands with sudo is easy with the adduser command.

Think of a username and password for yourself, then run the following commands as root:

root@aegir:~# adduser bob
Adding user `bob' ...
Adding new group `bob' (1001) ...
Adding new user `bob' (1001) with group `bob' ...
Creating home directory `/home/bob' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for bob
Enter the new value, or press ENTER for the default
    Full Name []: Bob
    Room Number []: 
    Work Phone []: 
    Home Phone []: 
    Other []: 
Is the information correct? [Y/n] y

Then add them to the "sudo" user group:

root@aegir:~# adduser bob sudo
Adding user `bob' to group `sudo' ...
Adding user bob to group sudo

Then you can switch to the "bob" user using sudo su, or login via ssh with your password.

root@aegir:~# sudo su - bob

Experimental: Aegir 2 on Ubuntu 12.04 with apache, php-fpm

These notes describe a possible way of installing Apache with fastcgi using php5-fpm. The below configuration works but is experimental.

On a Ubuntu 12.04 box:

Install Aegir2 from Debian packages

Follow Below is a shortened form.

Add the Aegir package "Software Source" repository:

echo "deb stable main" | sudo tee -a /etc/apt/sources.list.d/aegir-stable.list
wget -q -O- | sudo apt-key add -

Install aegir2:

sudo apt-get update
sudo apt-get install mysql-server
sudo mysql_secure_installation
sudo apt-get install aegir2

If the installation fails, it might be that your FQDN is not set or your postfix is not configured.

Verify your aegir site is working

Navigate your browser to the FQDN of your aegir server. You need to see the "Welcome to Aegir" page.

Modify the configuration to use fastcgi / php5-fpm

Edit /etc/apt/sources.list and enable the multiverse repository (it's needed for the libapache2-mod-fastcgi package).

Then install php5-fpm and make apache use it:

sudo apt-get update
sudo apt-get install php5-fpm libapache2-mod-fastcgi
sudo apt-get --purge remove libapache2-mod-php5

Modify /etc/php5/fpm/pool.d/www.conf Make it listen on socket, instead of IP:

;listen =
listen = /var/run/php-fpm.sock

Create /etc/apache2/conf.d/php-fpm.conf with this content:

ScriptAlias /php5.fastcgi /var/www/fastcgi
FastCGIExternalServer /var/www/fastcgi -socket /run/php-fpm.sock
AddHandler php-fastcgi .php
Action php-fastcgi /php5.fastcgi virtual

Options FollowSymLinks ExecCGI

<Directory /var/www/fastcgi>
  Options ExecCGI FollowSymLinks
  SetHandler fastcgi-script
  Order allow,deny
  Allow from all

Enable apache modules:

sudo a2enmod actions alias fastcgi

Restart php5-fpm and apache to load the new configs:

sudo service php5-fpm restart
sudo service apache2 restart

Verify that you can still reach your Aegir site

Navigate your browser to the FQDN of your aegir server. This time, you are using php5-fpm. Verify e.g. via phpinfo().

Page author: Marji Cermak,

Using a proxy cache to accelerate platform builds

While building (and re-building) platforms using makefiles and the Aegir front-end (node/add/platform) is great, it has a number of minor annoyances. They're slow, and consume lots of bandwidth, but worse still, even a small hiccup in (or other) infrastructure can break a platform build, which requires starting from scratch each time.

When you maintain platforms with upwards of 300 modules, themes and libraries, such as with kPlatforms, and you start to deploy these to multiple clients' Aegir servers, those minor annoyances can become significant challenges.

There is good documentation on setting this up for use with Drush Make already, such as this blog post. However, there are some gotchas when doing so in Aegir. Most of the suggested solutions involve something like setting environment variables in ~/.bashrc, which works fine if you're running 'drush make' yourself in a login shell. However, since the Aegir is running in a non-interactive shell, there isn't a opportunity to set environment variables.

Thankfully, Drush Make supports curl, and opts for it automatically if it's installed. Careful reading of curl's manpage indicates that:

[curl] always [...] checks for a default config file and uses it if found.

So, in the end, all that's required is a /var/aegir/.curlrc file containing:

proxy = "http://<proxy_host>[:port]"

Thus a basic configuration on Debian would involve installing a proxy, such as Squid:

# apt-get install squid3

Then add an acl in /etc/squid3/squid.conf allowing access from your local network, e.g.:

acl localnet src
http_access allow localnet

Restart Squid and you're good to go:

# /etc/init.d/squid3 restart

Testing that Aegir is actually using your new proxy cache, and that Squid is actually caching the makefile projects involves taking a quick look at the logs of the Squid server:

# tail -f /var/log/squid3

Upgrade Guide


1. Introduction

Upgrading Aegir is designed to be as easy as it possibly can be, and regularly improves over time as the developers attempt to streamline the process for users.

Nonetheless, the upgrade process can seem a little daunting to users. This is mainly because some expectation arises that because Aegir is built on Drupal, and is made for managing Drupal sites, it seems reasonable to expect the upgrade process to be as straightforward as, say, upgrading a regular Drupal site.

Aegir is a powerful system that goes beyond a normal Drupal application by being split into two parts: a frontend (the browser-based control panel) and the backend (bits on the system in /var/aegir, such as Drush and Drush extensions), along with a system user on your server that runs command-line scripts and restarts services, and cronjobs.

Typically what this means is that when it comes time to upgrade Aegir, you not only have to upgrade the frontend site, but also update the components that reside in the 'backend'.

But don't panic! We have instructions and even a script to run, to take care of almost all of it for you, eliminating as much as possible the chance for human error.

2. Upgrade options

There are three options you can choose to upgrade your Aegir install when a new release comes up:

3. New release of Drupal core?

Just as you would use the Migrate task in Aegir to upgrade one of your sites to a new copy of Drupal core, you can follow the UPGRADE.txt to upgrade your actual Aegir frontend system to a new copy of Drupal core too. The upgrade process (including the script) will always fetch the latest available copy of Drupal core to place the frontend on.

Currently you cannot upgrade the Aegir site itself from the frontend with a Migrate task as you do for your managed sites. This may change in the future, but has not been developed yet.

Manual Upgrade

This section outlines the requirements for doing a manual upgrade of Aegir to a new release. Before going ahead with this, you probably want to read the upgrade path and version-specific notes.

1. Conventions & Tips

All instructions and in general all commands must be run as aegir user, so all permissions are always set correctly.

To become aegir user you can issue this command:

su -s /bin/sh aegir

(Note you must run this as root or prefix with sudo).

Note that /bin/sh is an example. You may wish to instead use the shell of your choice, i.e /bin/bash

A standard umask of 022 is assumed. This is the default on most systems.

We assume that drush is in your path, if it is installed in /var/aegir/drush/drush.php, replace all occurences of drush by /var/aegir/drush/drush.php in the following steps, or add the following alias:

alias drush=/var/aegir/drush/drush.php

2. Upgrading Overview

2.1. Upgrading drush

As part of your Aegir upgrade, you need to upgrade Drush to the latest stable version compatible with the target Aegir release. AEgir 1.x only works with version 4.5. Versions 5 - 7 have been known to work with AEgir 2.x, however the Drush developers recommend version 6 as the most stable.

2.2. Upgrading the backend

After drush is updated, you must then proceed to upgrade the backend. The reason for upgrading the backend first before the frontend, is that the frontend upgrade process is instigated by the backend using Drush Make. Thus you need to be running the new backend first in order to successfully produce a new frontend.

In general, we try to keep the backend and the frontend compatible with each other during release cycles. That is: provision 1.8 and hosting 1.9 will always be able to talk to each other, but hosting 2.0 will have trouble talking to the 1.9 backend, so you need to upgrade the backend first when you do a major upgrade (for example, 1.9 -> 2.0).

Bottomline: first you upgrade the backend, then the frontend.

2.3. Upgrading the frontend

Once your backend is upgraded, you can upgrade your frontend. Think of this as the backend fetching a new copy of Drupal core and the Hostmaster frontend application onto your server, and then moving the Aegir site's settings.php and other bits and pieces over to the new codebase.

2.4. What hostmaster-migrate does

The command will make sure the target directory is a valid Aegir install. If the directory does not exist, provision will use drush_make to fetch and assemble the correct version of the front end for the specific release of the backend you are running.

hostmaster-migrate will also completely replace the crontab entry for the aegir user.

The command above will fetch the latest stable Drupal release, so it can simply be run again when a new security release of Drupal is made available.

3. Upgrading to AEgir 1.x

3.1. Upgrading drush and drush make

As part of your Aegir upgrade, you need to upgrade Drush to the latest stable version compatible with the target Aegir release. Aegir 1.x does not support Drush 5, although 2.x does.

If you are using the Drush Debian packages, the package should be upgraded through:

apt-get install drush

Otherwise, since drush 4.x is capable of upgrading itself, you can just run:

drush dl drush-7.x-4.5

If you are running a version before 4.x, use the following set of commands instead:

pear channel-discover
pear install drush/drush-4.5.0

Provision 0.4 has added a new dependency on drush_make, which will also need to be installed to upgrade the front end if you are upgrading from a pre-0.4 release.

If you are upgrading from an earlier 0.4 release, replace your copy of drush_make with the latest recommended release.

drush dl drush_make-6.x --destination="$HOME/.drush"

3.2. Upgrading the 1.x backend

Upgrading the backend is as simple as replacing your copy of Drush, Provision, and if necessary, Drush Make, with the new versions if available. Keep a copy of the old Provision and Drush in case something goes wrong in the frontend.

drush dl provision-6.x --destination=$HOME/.drush

3.3. Upgrading the 1.x frontend

Before upgrading, we set a few key variables to make the process easier. You must replace the arguments those variables to match your configuration. This means replacing $AEGIR_DOMAIN by the URL of your Aegir install, $AEGIR_VERSION with the version number of the Aegir you are trying to install, and also $OLD_AEGIR_DIR with the path to the previous directory where Aegir was installed.

The directory passed to hostmaster-migrate must be an absolute path to where you want the new release to be stored.


To upgrade your frontend, run the following commands, replacing the variables as described below:

drush hostmaster-migrate $AEGIR_DOMAIN $HOME/hostmaster-$AEGIR_VERSION

3.4. Special configurations and troubleshooting

If the upgrade fails, try running it again with the --debug flag:

drush hostmaster-migrate $HOME/hostmaster-$AEGIR_VERSION --debug

If you have customized your Aegir installation and are maintaining your own makefile, you can use the --makefile flag so the platform is created with another makefile than the default. Be warned that this may create problems if the makefile doesn't include the right Aegir modules.

4. Upgrading to AEgir 2.x

4.1. Upgrading drush

Install Drush 6.x per the directions given at the Drush repository. The maintainers have deprecated the PEAR installation procedure and are encouraging everyone to install Drush via the Composer dependency management tool.

You should also remove your copy of drush_make from $HOME/.drush.

4.2. Upgrading the 2.x backend

Upgrading the backend is as simple as replacing your copy of Drush & Provision with the new versions if available. Keep a copy of the old Provision and Drush in case something goes wrong in the frontend.

drush dl --destination=/var/aegir/.drush provision-6.x-2.0

Drush 5+ has a commandfile cache which you need to clear before installing Aegir:

drush cache-clear drush

4.3. Upgrading the 2.x frontend

Before upgrading, we set a few key variables to make the process easier. You must replace the arguments those variables to match your configuration. This means replacing $AEGIR_DOMAIN by the URL of your Aegir install, $AEGIR_VERSION with the version number of the Aegir you are trying to install, and also $OLD_AEGIR_DIR with the path to the previous directory where Aegir was installed.

The directory passed to hostmaster-migrate must be an absolute path to where you want the new release to be stored.


To upgrade your frontend, run the following commands, replacing the variables as described below:

drush hostmaster-migrate $AEGIR_DOMAIN $HOME/hostmaster-$AEGIR_VERSION

4.4. Special configurations and troubleshooting

Read the upgrade path notes again, you will have missed something.

If the upgrade fails, try running it again with the --debug flag:

drush hostmaster-migrate $HOME/hostmaster-$AEGIR_VERSION --debug

If you have customized your Aegir installation and are maintaining your own makefile, you can use the --makefile flag so the platform is created with another makefile than the default. Be warned that this may create problems if the makefile doesn't include the right Aegir modules.

If the update fails due to a bug in module Hosting, it will ask you to run "drush hostmaster-resume help". That command does not exist. Try this one instead.

drush --debug @hostmaster hostmaster-resume /var/aegir/hostmaster-6.x-1.11 /var/aegir/hostmaster-6.x-2.0

Automatic upgrades with Debian packages

1. Regular update process

Make sure you have the Aegir repository in your sources.list, as per the installation docs.

If you are upgrading from a Debian installation whereby you used the repositories, you should change this entry in your sources.list to be as per the instructions linked to above, and run apt-get update to refresh.

If you want to upgrade all packages in one shot, use:

apt-get update
apt-get install aegir

Note that you can upgrade Aegir in steps. Upgrading your backend to the Debian package should be as simple as running:

apt-get install aegir-provision

Upgrading the frontend to the Debian package works identically:

apt-get install aegir-hostmaster

As during install, you can use the DEBUG variable to run Drush in debugging mode:

env DEBUG=yes apt-get install aegir-hostmaster

Note: the DEBUG flag is deprecated. In 1.x releases, it is accepted, but in 2.x it won't. You should use DPKG_DEBUG instead, it is usable starting from 1.1-4.

2.x note: to upgrade to 2.x, use: apt-get install aegir2.

Note on contrib modules: some Aegir-specific contrib modules may have been installed on your Aegir deployment. This may fail if you are doing a major upgrade. In this case, you will probably want to disable those contrib modules. Look for directories in ~aegir/.drush or /usr/share/drush/commands or other components of the drush commandfiles search path, and move them out of the way. After the upgrade, download the new versions of the modules that are compatible with the new Aegir release.

2. Upgrading from non-Debian installs

The Debian package supports migrating from existing installs. You will need to move /var/aegir/.drush/provision out of the way before going ahead:

tar cfz /var/aegir/backups/provision.tgz /var/aegir/.drush/provision
rm -rf /var/aegir/.drush/provision

You'll also need to go through steps 1 through 3 of Automatic install on Debian.

Then just install the package as if you were installing from scratch.

3. Custom distributions

If you have your own makefile, you can go ahead with the above process, but change the makefile to the one you want:

echo debconf aegir/makefile string /var/aegir/makefiles/aegir/aegir-koumbit.make | debconf-set-selections
apt-get install aegir

Usually no questions are asked when upgrading - this allows you to specify the makefile path for your custom distribution of Aegir, even if you're upgrading. It's also how you can switch distributions.

An example aegir-koumbit.make file could look like:

core = 6.x
api = 2

includes[aegir] = "/usr/share/drush/commands/provision/aegir.make"

projects[] = module_filter

Note that for this to work, you will need the patch from this issue, allowing drush_make to reference absolute system paths.

3.1. Keeping custom distributions up to date

This section describes how to upgrade the code for custom distributions in between debian package upgrades. Here, we assume that Aegir is already installed through the debian package.

  1. Create a new Aegir makefile, or update the custom Aegir makefile. (You can use the makefile in as a starting point.)
  2. Add modules/features/themes/libraries/whatever to the makefile. Ex:
        projects[] = token
        projects[] = views
  3. Follow the manual upgrade path:
    • drush @hostmaster hostmaster-migrate URL /path/to/platform --makefile='/path/to/makefile'
    • Hope it's all green (no errors). If errors, fix makefile.
    • A new platform should exist, the new site should be in there, verifying. If the task is not running, check that hosting-queue-runner is running. If it's not, restart it using '/etc/init.d/hosting-queue-runner force-reload'. (Since hostmaster changed location, it is normal for hosting-queue-runner to crash at this point.)
    • When the debian package is upgraded, it should create a new hostmaster platform automatically. (You can test this with dpkg --configure.)

4. Rolling back the upgrade

If something went wrong with the upgrade, you can rollback by deleting the hostmaster site and redeploying on the older platform:

drush @hostmaster provision-delete
vi ~/.drush/hostmaster.alias.drushrc.php

...And edit the alias to make the following changes:

1. change the platform to point to the older platform alias
2. change the platform root path
3. change the site path

During the upgrade, a backup was done and you need to find which backup file it was in the backups directory. Use this backup to redeploy the older platform:

drush @hostmaster provision-deploy ~/backups/

5. Recovering a Failed Upgrade

When using the Regular Update Process and you encounter an error it leaves the debian package in a broken state.

First you need to figure out why it failed. For example is there a permission problem?
Once you determined the issue correct it and clean up the environment. It could be necessary to remove the new hostmaster platform. It is up to you to determine what state aegir is in.

Next you need to fix the broken package by running the fix-broken parameter:

apt-get install -f 

This tells the debian package system to start through the process again.

Automatic upgrades with script


This page describes the upgrade script in the Provision repository that tries to automate much of the upgrade process.

NOTE: At this time neither the Aegir 1.1 nor the Aegir 2.0 upgrade scripts are working for all setups. We recommend you use the Manual upgrades instead.

It is imperative that you read the version-specific upgrade notes before attempting to run the script, as the script will assume you have your system set up appropriately to handle the upgrade process.

You can download the script for Aegir 2.4 with the following command:

wget -O ''

or for AEgir 3.0 with the following command:

wget -O ''

Make sure you download it to somewhere that the aegir user can access in order to execute it.

You may need to edit the script to set any variables that are different from the defaults, for example to upgrade to a different Aegir version.

To do the upgrade, just run the script:

su -s /bin/sh aegir -c "sh"

Version-specific & upgrade path information

1. General upgrade path recommendations

In general, you shouldn't skip major releases. That is, if you are running 0.3, you should upgrade to 1.0 or 1.1, not 2.0. Upgrades within a stable branch (1.0 to 1.1, 2.0 to 2.1) are fully supported, and you can skip minor versions (1.0 to 1.2 should work fine), but you should always upgrade to the latest stable release if you are coming from a different release branch.

The rest of this page documents what version-specific changes happened that you need to make manual modifications to. If you are running the Debian packages, you probably don't need to configure anything here.

The upgrade process should make this clear, but keep in mind that you need to upgrade the backend (drush, provision) before the frontend (drupal, hostmaster profile, etc).

Provision/Drush contrib modules might require additional attention. As there is no version checking, the safest method is probably to move the module out of your .drush folder and later add the version compatible with the new Aegir version.

Hosting/Drupal contrib modules should also be handled carefully. If these were installed into the hostmaster site's directory, then they should be moved automatically to the new hostmaster platform during the upgrade. On the other hand, if they were installed on the platform, you'll need to provide the hostmaster-migrate or Debian package with a custom makefile. The default makefile in Provision (aegir.make) can be used as a model for this.

2. Changes in the 2.0 release

2.1. hosting-queue-runner renamed hosting-queued

The popular module hosting-queue-runner has been merged in the 2.0 release. In the process, it has been renamed to the more appropriate hosting-queued. The init script is also now installed directly with the Debian package, and started on install or upgrade.

You will, however, need to manually enable to module for the daemon to work (still):

drush @hostmaster en hosting_queued

Also, if you are migrating from an install using hosting-queue-runner, you will need to remove the old module and startup script. Enabling hosting-queued will already have disabled and uninstalled the module from Drupal, but you need to cleanup your filesystem:

rm /etc/init.d/hosting-queue-runner

2.2. queue daemon enabled by default

The above queue daemon is now enabled by default by the Debian package, and is properly restarted on upgrades. It can be disabled after install if necessary using the following comamnds:

service hosting-queued stop
su aegir -c "drush @hostmaster pm-disable hosting_queued"

2.3. hosting_platform_pathauto module bundled with Aegir

The popular module hosting_platform_pathauto has been bundled in the 2.0 release. If you installed it module manually then now is probably the time to remove your copy. Aegir 2.0-alpha1 comes bundled with hosting_platform_pathauto-2.0-beta1.

2.4. hosting-task --force

You used to be able to run hosting-task <nid> to re-run a task by its node ID. Because hosting-task now checks if the task is really queued, this can't be used to retry existing tasks directly, unless you use the --force argument. So this:

drush @hostmaster hosting-task 1234


drush @hostmaster hosting-task --force 1234

2.5. Deprecated functions removed

If you are using any of those functions in your custom code, lookup in the 1.x documentation to see the replacement functions, as they have been removed from 2.x:

  • hosting_alias_count_sites() (same as !hosting_alias_allow_domain())
  • hosting_site_exists() (same as !hosting_alias_allow_domain())
  • hosting_get_client_by_email() (use hosting_get_client() instead)
  • hosting_import_client() dropped the second argument (organization)
  • hosting_task_list_embedded() (use hosting_task_list() or hosting_task_list_table())

2.6. New Provision class naming convention

Provision classes used to start with provisionConfig_ or provisionService_, but these are now Provision_Config_ and Provision_Service_ respectively.

2.7. Client node type changes

  • the email field was removed from the client, now you need a user associated with the client. this was already the case in 1.x but the existing field wasn't touched.
  • the client_email field was removed from the site object

2.8. SSL and IP allocation refactoring changes

The SSL IP allocation refactoring has changed a good few things in the API and the way SSL certificates are managed.

2.8.1. Backend

The following functions are gone from the backend:

Certificates are not tracked from the backend anymore, other than to make sure that we delete a certificate when it's not used anymore. So we still use *.receipt files, but just to mark a site to SSL certificate association, not the IP allocation. The SSL directory in ~/config/server_foo/ssl.d/uri/ is removed when no site use that directory anymore.

The backend now expects the frontend to send an ip_address field and stopped sending a site_ip_addresses to the frontend.

2.8.2. Frontend

The hosting_ip_addresses table changes. A unique key has been added and it is now only for servers. It is used by the new hosting_ssl_cert_ips table to map those server IP addresses to certificates.

A new field for the IP (ip_address) is sent from the frontend during site install/verify tasks. The field is not present in non-ssl sites. It is the non-resolved IP address of the server assigned to the SSL certificate and must be used by the backend to write the vhost.

SSL certificates are removed from the frontend when sites using it are deleted.

2.9. Debian package name changed

To allow both packages to coexist in the same Debian archive, the name of the packages of the 2.x series have changed.

  • aegir -> aegir2
  • aegir-provision -> aegir2-provision
  • aegir-hostmaster -> aegir2-hostmaster
  • aegir-cluster-slave -> aegir2-cluster-slave

2.10. Platform drushrc.php moved

From Drush 5 documentation:

Drush 5 no longer looks for aliases, configs or command files in the Drupal
root folder, so if you previously used drushrc.php files in the Drupal root
you will need to move the file to sites/all/drush/drushrc.php.

Since Aegir 2 requires Drush 5 (or later), Provision now follows this standard, and places a platform's drushrc.php in sites/all/drush/drushrc.php.

2.11. Class auto-loading

Provision has been refactored to use class autoloading. This simplifies use of classes, as it obviates the need to explicitly include the files in which the class and it's parent classes are defined. In addition, it standardizes the placement of class definitions within a hierarchical file-system structure and will make name-spacing simpler if/when we begin to adopt Symfony components.

More info in the manual under Extending Aegir - Class auto-loading

This may also affect certain contrib extensions that used to have to reside in the provision directory itself. These extensions should probably be removed prior to the upgrade, and re-installed afterwards with an Aegir2-compatible version.

2.12. Other database changes

The release_id column was dropped. This column wasn't used anywhere in the code and was present only in some installs, see issue #1882708 for details.

3. Changes in the 1.0 release

3.1. Git dependency

If you intend on upgrading your system to the bleeding edge version of the code from our git repositories, you will need the git program installed. On Debian, this means:

apt-get install git-core

3.2. DNS Configuration

Aegir requires that the hostname returned by the hostname and uname -n shell commands, resolves to the IP address for this server.

Shell commands as root:

AEGIR_HOST=`uname -n`
resolveip $AEGIR_HOST

If the command returns your IP address, you are all set. If it returns an error you will need to edit your /etc/hosts file.

(Mac OSX notes: if you are running on OS X you will not likely have a resolveip binary. Just substitute ping $AEGIR_HOST ).

First line of this file looks like: localhost

Simply add all domains you want to this line. e.g: localhost $AEGIR_HOST $AEGIR_DOMAIN other1 other2

To be clear you cannot put $AEGIR_HOST $AEGIR_DOMAIN in your hosts file. Put in whatever uname -n returns for $AEGIR_HOST and what ever domain you want to use f or $AEGIR_DOMAIN (real domain or faked in hosts file). In OS X uname -n will return whatever you put in System Preferences -> Sharing -> Computer Name. I added that value (iMac 27 for me) to /etc/hosts and my faked aegir domain as follows:  localhost  iMac27  aegir.local

If you only intend to use Aegir on a single server, it is acceptable for the resolved IP address to be the '' loopback address.

If you intend to manage multiple servers using Aegir, you will need to make sure that the IP address is the public IP of this server.

Finally, set an $AEGIR_IP environment variable for use in the Database configuration step below.

Shell commands as root:: AEGIR_IP=resolveip $AEGIR_HOST | awk {'print $6'}

(If running OS X or are otherwise missing resolveip and you just want to use Aegir on your computer use you can do this: AEGIR_IP=

3.3. Unzip dependency

As of the 0.4-alpha3 release, 'unzip' is a required dependency on your server in order to successfully extract the jquery.ui library that is part of some UI improvements. On Debian, this means:

Shell commands::

apt-get install unzip

3.4. Database configuration

To make sure that the Aegir backend, and all the possible web servers can reach your database server, you need to configure mysql to listen on all the public IP addresses available to it.

/etc/mysql/my.cnf configuration line to comment out:: bind-address =

Now you need to restart mysql, to clear any caches.

Shell command as root:: /etc/init.d/mysql restart

Because you have already installed Aegir when it was using the generic grants, you will need to create new grants using the public IP address and hostname of this server.

Shell command :: mysql -uroot -p mysql

You need to generate the following grants using the hostname returned by the uname -n command, and the IP address that the resolveip command returns for that hostname.

You need to re-use the pasword you had for the account before.

Shell commands::

mysql -u root -p -e "GRANT ALL ON *.* to 'aegir_root'@'$AEGIR_HOST' IDENTIFIED BY 'xxxx' WITH GRANT OPTION;"
mysql -u root -p -e "GRANT ALL ON *.* to 'aegir_root'@'$AEGIR_IP' IDENTIFIED BY 'xxxx' WITH GRANT OPTION;"

3.5. Apache configuration

This release introduces multi-server support and required reorganizing the Apache configuration files in ~aegir/config. Instead of having all files in config/vhost.d, they are now split between vhost.d, platform.d and a single apache.conf. The vhost.d directory is for virtual hosts, platform.d is for platform-specific configuration and apache.conf is the server-wide configuration file.

You will need to change the line you added to either the httpd.conf file or /etc/apache2/conf.d/aegir file during installation.

Open your httpd.conf file and modify::

Include /var/aegir/config/vhost.d

To read ::

Include /var/aegir/config/apache.conf

If you are upgrading from 0.4 releases between alpha8 and (including) alpha14, you will need to rename your conf.d directory to post.d in Apache and pre.d in Nginx. Example, in Apache::

mv /var/aegir/config/server_master/apache/{conf.d,post.d}

Now log into Aegir, and verify the hostmaster platform. This will generate the correct apache.conf file and restart Apache.

Uninstalling Aegir


There is no formal method for uninstalling Aegir, but there is also no real mystery either since the system tries to keep itself together in one location, typically /var/aegir.

Below are the steps to completely remove all traces of Aegir from your server. We also include to leave Aegir intact, but destroy its data, attempting to reset to a almost post-install setup.

Ideally, you would delete all sites and all platforms from the system first. That would take care of deleting all databases and users. But this can take some time and is annoying, so we provide instructions on how to destroy everything.


Obviously if you have any sites and platforms currently managed by Aegir, you would want to move them out of the /var/aegir area before you delete it! Ensure you have set up your sites and platforms elsewhere, with Apache vhost files etc in their typical locations, or at least out of harm's way before attempting this.

WARNING: Performing these steps will remove Aegir from your server and may result in loss of data. Use with caution.

Run these commands as a privileged user (such as root). We assume your Aegir installation resides in /var/aegir.


You probably want to backup everything before trashing it.

Backup all you need to keep from the /var/aegir/ directory.

Backup your database server, we'll be also destroying that.

Uninstall script

Aegir 2.x comes with a hostmaster-uninstall script that allows you to automate good chunks of the steps below.

Destroying the data

Aegir manages three types of data:

  • configuration files - yes, we consider those as data
  • site and platform files
  • site databases

Trashing configuration files

This step is optional if you are going to remove everything anyways.

rm /var/aegir/.drush/*alias.drushrc.php
rm -r /var/aegir/config/*

Trashing site and platform files

At this point, you could still probably recover by verifying the platforms, which would recreate config files. At this point we start really destroying data.

rm -r /var/aegir/platforms/*
rm -r /var/aegir/hostmaster-*

Drop the databases and db users

There are no generic instructions for this, since every system differs. Essentially you can perform this within a MySQL shell

mysql -u root -p

Use the DROP DATABASE $databasename; syntax to drop databases. and DROP USER $user; to delete users, example:

DROP DATABASE aegirexamplecom;
DROP USER aegirexamplecom@localhost;

This removes the Aegir user, assuming you have not created any site. If you did, you may want to cleanup those sites if you are going to delete them anyways. To see a list of GRANTs that Aegir has made for your database users, you can use a command like the following:

USE mysql;
SELECT User,Host FROM user WHERE Host='localhost' AND User <> 'root' AND User <> 'debian-sys-maint';
SELECT Host,Db,User FROM db WHERE User <> '';

In Debian, the following will remove all non-system users (which may include non-aegir users!!!).


DELETE FROM db WHERE User <> '';
DELETE FROM user WHERE Host='localhost' AND User <> 'root' AND User <> 'debian-sys-maint';

Then you will need to DROP DATABASE for every database.

Consult the GRANT and DROP documentation from MySQL for more information.

Remove the aegir user's crontab

crontab -r -u aegir

Removing everything

At this point, we have removed all data that Aegir manages and we would be ready to reinstall the frontend. If we want to remove all traces, however, there's more work to do.

Remove /var/aegir

rm -rf /var/aegir

Delete the aegir user

userdel aegir

This will also remove the user from the www-data group.

Remove the user from sudoers


Remove the line that looks something like

aegir ALL=NOPASSWD: /usr/sbin/apache2ctl

Save and exit the file.

Delete the symlink/include from Apache

Depending on your installation and OS this may vary.


rm /etc/apache2/conf.d/aegir.conf

If your Include statements were contained in a global system httpd.conf file or similar, you will need to remove these lines manually.

Restart Apache when you have completed this.

Extracting a Drupal site from Aegir

You may occasionally want to take a Drupal site hosted on a server managed with Aegir and put it somewhere else. This is pretty easy, but not quite as simple as moving a normal Drupal site not managed by Aegir from one machine to another. In brief, you have to copy the site, delete the drushrc.php file, and replace settings.php with a copy of the default configuration file. More specifically:

  • download the same copy of drupal core to the new server (and re-apply core patches, if any)
  • copy sites/all/ to the new server
  • copy the Aegir backup of your site to the new server and unzip in sites/
  • create a database on the new server & import the database backup
  • copy sites/ to sites/
  • D7: copy custom site aliases in sites/sites.php (if any) to the new server
  • D6: replicate site alias symlinks in sites/ (if any) on the new server
  • copy custom configuration in local.settings.php (if any) to settings.php
  • edit settings.php to add the database authentication details for the new server

That's it!

Troubleshooting Aegir

Aegir is a complex system that depends on a number of components being properly integrated. This can obviously lead to difficulties on occasion. However, fear not! In all likelihood, any problem you can get yourself into has probably already been solved, and documented in this section. Just one of the benefits of using a popular open source system ;)

How to fix a stuck task

It is possible a task may run longer than expected and you suspect something has gone wrong. It is even possible the task may cause a server to become unresponsive. Restarting the server will not stop the task, although it may make the server become responsive again.

To stop a Task, find the related task node (install: in the content list: /admin/content/node/overview, and delete it. This will stop Aegir from trying to run the task.

In the case of a site install, it may also be necessary to also delete the node for the site itself. The site may have actually installed properly. Verify the affected platform and see if Aegir imports the site. If so, you may need to reset the password to gain access to the new site. If the site doesn't import in the verify, delete any files from the sites folder on the selected platform and either try again and/or research why the task may have failed.

It can also be very helpful to try running tasks from the command line with drush (the entire Aegir web frontend is basically a user-friendly interface to a series of drush commands). You can see which command is being run by looking at a task node in Aegir. For example, if you are having problems verifying a site, you could run:
drush provision-verify --debug

Another option is to run the hosting task itself within the hostmaster context, which will then invoke the drush command on the applicable site. You can find the task node ID in the web frontend (look at the URL generated by Aegir to create the popup box which shows the log). If the task ID was 1234, you would then run this from the command line:
drush @hostmaster hosting-task 1234 --debug

Debugging Aegir

Installation and configuration of Aegir has been greatly simplified with the release of .deb packages. However, for other operating systems, or for those installing manually, making a mistake during the installation or upgrade of Aegir or Drush is easy to do, and these tips identify some of the most common mistakes.

The Aegir User

  • Make sure you have an aegir user (who we call the Aegir User) and that the Aegir User is properly configured on your server:
    • cat /etc/passwd prints all users. Find the line aegir:x:1000:1000:,,,:/var/aegir:/bin/bash. aegir usually is the Aegir User. Be cautious about using a different username, and do notuse an existing user or a user that will have any other role on the server. The Aegir User should only be used for Aegir activities.
    • Verify the Aegir install directory is the user's home. Usually, the Aegir directory is /var/aegir. Be cautious about installing Aegir in a different directory only because you are likely to get confused and nearly all the documentation assumes you have used /var/aegir
    • Make sure that the node that defines your Aegir server (e.g., identifies the Script User as your Aegir User. (You can find this node by clicking on the Servers menu tab and then clicking on the server URI shown in the list that appears of Aegir servers.)
    • All this is detailed in the install profile wizard
  • Do not run aegir as root! - It's an unsafe and unsupported configuration that is known to cause problems

Make Sure drush Is Installed Properly

  • Make sure that the node that defines your Aegir Server has the correct path to drush.
    • See /var/aegir/drush/readme.txt for install instructions
  • Check your Drush setup:
    • Always run drush as your aegir user, and never as "root".
    • Make sure that the Provision module is in the aegir/.drush/provision/ directory.
    • Make sure that the Hosting module is in ~aegir/hostmaster-0.x/profiles/hostmaster/modules/hosting (substitute the platform hostmaster-0.x to match the directory on your system in which you have installed the Drupal code that is running your Aegir site)
    • Run "drush help" and make sure that "provision" commands appear. "hosting" commands will not appear in the latest (after 2009/05/18) Drush versions, unless Drupal can be fully bootstrapped


  • Make sure the Aegir User can restart Apache without a password and that the corresponding command is defined in your Aegir Server Node
    • As your Aegir User, run the command shown in the "Restart command" field in your Aegir Server Node to ensure that your Aegir User can restart Apache
    • On Ubuntu, it's sudo /usr/sbin/apache2ctl graceful. The command should execute and return without asking for a password when run as the Aegir User
  • Make sure Apache can parse its configuration
    • On Ubuntu, sudo apache2ctl configtest should report "System Ok"

Other Things

  • On a Linux system, check that /etc/sudoers is chmod 440 (i.e., read only for the file owner and group, which is usually root)
  • Attempt to run the cron tasks manually from the command line
    • php /var/aegir/drush/drush.php --root=/var/aegir/hostmaster-0.x --uri= hosting-tasks --debug
  • Or you can retry a specific task form the command line
    • php /var/aegir/drush/drush.php --root='/var/aegir/hostmaster-0.4-alpha5' --uri='' hosting-task <nid of the task> --debug

"strict warning" error

Aegir 2.x returns the following error message

strict warning: Non-static method view::load() should not be called statically in /var/aegir/hostmaster-6.x-2.1/profiles/hostmaster/modules/views/views.module on line 1113.


It's due to a conflict between Views 3.x and PHP 5.4. For example, your server uses PHP 5.4 or more recent. And you updated Drupal core for Aegir to Drupal 6.34 or more recent and this error message is showing on all Aegir pages.


Option 1: Install "disable_messages" module. And disable all messages related to:

strict .*.

Read more here, under "How to hide only specific error messages to specific users" section.

Option 2: Patch Views 3.x. Read more at or

Option 3: Turn off Strict warnings in your "php.ini" file. Read more at or

Community coordination guide

This section of the manual aims to document common release practices and coordination within the community.

This includes:

Release process


This page is being moved to

This page aims to document our release process. It documents the release cycle, but also the steps required to make a release.

1. The release cycle

In general, each major Aegir release comprises a simultaneous release of all the modules that are part of the project. We generally go through several testing releases (alphas, betas & RCs) before doing the first stable release on a branch.

  • First an alpha is released to test new functionalities and to accomplish the goals decided in the Project Roadmap for that major version. Example: 0.4-alpha1, 0.4-alpha15
  • When we have covered most of the functionalities outlined in the roadmap, we push out beta releases until no more critical issues show up. This is generally considered a soft feature freeze. Example: 0.4-beta1
  • Then we go into full feature freeze and release a first release candidate (RC). Then a stable release branch is created, and the development branch is kept opened for development for the next stable release. This is generally considered a soft API freeze. Release candidates are made as long as critical bugs are found. Example: 0.4-rc1, freeze announcement
  • Once the development branch has no known critical bugs, the stable release is announced. From there on only critical fixes (security, critical performance and critical bugfixes) are committed to the stable branch, and stable releases are published (without alpha/beta/RC) directly on the stable branch. The stable branch is in full API freeze. New features are generally committed to the development branch.

See also the tag and branch naming convention.

2. Steps for a release

For the specifics of release naming conventions and the cycle, see the branch naming convention.

2.1. Make sure Jenkins is all green

Look into Jenkins to see if all tasks have been performed without errors since the last commit. If there is an error, fix it before the release.

2.2. Verify that drupal-org.make specifies up-to-date versions

In the hostmaster project we maintain our own drupal-org.make file. Check that e.g. the ctools version specified is not out-dated.

2.3. Generating the release notes

We build complete release notes for every release. Those are made up of a summary of the release, an outline of key changes, of known issues, install and upgrade instructions and a full list of bugfixes and new features.

Using Git Release Notes for Drush

drush rn 7.x-3.0-alpha1 7.x-3.0-alpha2

The developers then proceed to format/edit the list of fixes as well as list other significant information/changes for this release. These notes end up becoming the Release Notes for the release, which are also entered in the debian/changelog file by the script below.

2.4. Running the script

Each time we make a new release, we run a script called in provision.

This script should only be used by the core dev team when doing an official release. If you are not one of those people, you probably shouldn't be running this.

This script does all the 'hard' work in that it doesn't forget all the very many places to edit version numbers etc of relevant documentation and other scripts. This includes and

note from just after 7.x-3.0-beta1: It's probably a good idea to disable the Jenkins jobs named 'D_aegir-debian*'. This could prevent later troubles in the 'Publish the Debian packages' section.

Paraphrasing from the script itself:

The following operations will be done:
0. prompt you for a debian/changelog entry
1. change the makefile to download tarball
2. change the version
3. display the resulting diff
4. commit those changes to git
5. lay down the tag
6. revert the commit
7. (optionally) push those changes

The operation can be aborted before step 7. Don't forget that as
long as changes are not pushed upstream, this can all be reverted (see
git-reset(1) and git-revert(1) ).

Next, we need to add the tag in hostmaster, and push it to the d.o repos. So in short, this sums up as:

cd provision
sh 1.10
cd ../hostmaster
git tag 6.x-1.10
git push origin 6.x-1.10

Notice how we just provide the Aegir release number (1.10) to the release script, not the Drupal branch (6.x), which is hardcoded in the script to remove potential confusion.

Special, for 2.x: While we wait for core support in drush (issue #1991764) we need to manually modify the makefiles in hostmaster, drupal-org.make and hostmaster.make to point to the tags we lay down manually in hostmaster, hosting and provision (and maybe eldir). So this ends up being:

cd provision
sh 2.0
cd ../hostmaster
git pull
git tag 6.x-2.0
git push origin 6.x-2.0
cd ../hosting
git pull
git tag 6.x-2.0
git push origin 6.x-2.0

2.4.1. Optional: new Eldir release

If we do a major release (say a point zero release), we may want to make a new release of the theme (Eldir). This can also be performed if there enough new changes on the theme to warrant a new release on its own.

To do a new release of Eldir:

  1. tag and push the tag
  2. update the version to fetch in hostmaster.make
  3. create a release node for Eldir

2.5. Test the manual install in Jenkins

Before making a full release, test the release in Jenkins. To do so, start a build of the launch the S_aegir_6.x-1.x_install job (or S_aegir_6.x-2.x_install job for 2.x) with the following parameters:

  • the right release as the AEGIR_VERSION parameter
  • the DRUSH_VERSION to match what is required for this release. (Currently '4.5' for Aegir 1.x)

If the build fails, delete the remote tags (using git push origin :6.x-1.7, for example), fix the bugs and start again.

2.6. Build the Debian packages

Build the package and upload to Jenkins can build and upload a Debian package for you with the S_aegir-debian-official job.

If you need to move the tags again, you will need to clear the testing archive using the R clear repo job, with the testing argument.

You can also build and upload the package yourself as explained in these detailed instructions. We first upload the package to the testing distribution, and it gets migrated down into stable after tests.

Special, for 2.x: build the package manually, see detailed instructions. It should be something like:

./ 2.0-rc5
git reset --hard 6.x-2.0-rc5
git-buildpackage --git-builder=debuild
dput aegir build-area/aegir2-provision_2.0~rc5_amd64.changes

See the detailed instructions for the dput configuration.

2.7. Test the upgrade in Jenkins

Once both of those tasks have executed successfully, you can test the upgrade of the Debian packages by running the following Jenkins job:

(Note that this test is currently non-functional)

2.8. Creating release nodes on

Once the tags are pushed and release notes published, we create a release node with an excerpt of (and a link to) the release notes so that tarballs are created and issue queue versions updated.

This needs to be done in the hostmaster and provision (and hosting and (maybe) eldir for 2.x) projects on

Note: this could be automated with the right stuff on

Special, for 2.x: make sure release nodes are created in order! The projects shipped with hostmaster (hosting, eldir, etc) need to be fully released before the hostmaster release node is created!

2.9. Build the release in Jenkins again

At this point, it's possible that the tarballs on were not created properly. We want to test the real procedure, so run a your build again, but choose 'package' as the AEGIR_FETCH_MODE. S_aegir_6.x-1.x_install job

Note: The link provided may reference the wrong test, since there doesn't appear to be an AEGIR_FETCH_MODE parameter.

2.10. Publish the Debian packages

Finally, when the Debian packages are tested you will need to pull them into the stable release channel:

2.x note: we pull to testing (and stable since the betas), manually:

reprepro copy testing unstable aegir2
reprepro copy testing unstable aegir2-hostmaster
reprepro copy testing unstable aegir2-provision
reprepro copy testing unstable aegir2-cluster-slave

3.x note: we pull to stable (since the betas), manually:

reprepro@zeus:~$ reprepro copy stable unstable aegir3
reprepro@zeus:~$ reprepro copy stable unstable aegir3-hostmaster
reprepro@zeus:~$ reprepro copy stable unstable aegir3-provision
reprepro@zeus:~$ reprepro copy stable unstable aegir3-cluster-slave

If Jenkins has managed to build .debs and upload them before you've have a chance to pull them into testing/stable, you can manually remove them like so:

reprepro remove unstable aegir2-cluster-slave aegir2 aegir2-provision aegir2-hostmaster

This should be prevented by disabling the Jenkins jobs named 'D_aegir-debian*' before starting to push the release tags.

You can then re-upload the new .debs you've generated, using the '-f' (force) flag:

dput -f aegir build-area/aegir2-provision_2.3_amd64.changes

After doing that, you can re-run the 'copy' commands to publish the .debs to the appropriate releases.

2.11. Publish the release notes widely

Once all this is done and the tarballs are generated, the release notes are published in:

Optionally, blog posts on,, and elsewhere may go into further detail about significant changes, screencasts etc.

Building and working with the debian packages


Debian is one of the main supported operating systems in Aegir. For other systems, see Operating System Support. See also the following instructions:

The following is aimed at developers wishing to maintain their own Debian packages or work within the packaging framework.

1. Basic requirements

You need the following packages to build the Aegir Debian packages:

apt-get install devscripts git-buildpackage

See also the section below on Adding a new uploader.

2. Building a package for a new release

Assuming we have just released 2.0-alpha2, those instructions will merge that code into the upstream branch (which is used to create the Debian diff) and then merged again in the debian branch (where the Debian code lives). We then use git-buildpackage to build the package and tag it, then push those changes back in the repository.

cd provision
git pull
(if you previously ran
git reset --hard 6.x-2.0-rc1
(otherwise run this next line)
dch -v 2.0~alpha2 -D unstable new upstream release
dput aegir ../build-area/aegir-provision_2.0~alpha2_i386.changes

Note: notice how the version number is slightly different in Debian - we use the "magic" ~ separator to indicate that 2.0~alpha2 is actually lower than 2.0...

The packages are initially uploaded to the "unstable" repository for initial test builds. The idea is that this final package can be moved to "testing" for broader testing, using the command:

sudo -u reprepro reprepro -b /srv/reprepro/ copy testing unstable aegir2 aegir2-provision aegir2-hostmaster aegir2-cluster-slave

When confirmed as ready, it is migrated to the stable repository, using the command:

sudo -u reprepro reprepro -b /srv/reprepro/ copy stable testing aegir2 aegir2-provision aegir2-hostmaster aegir2-cluster-slave

3. Building a branch package

Sometimes you want to have a test package for a given branch without going through a full release. Here how it's done.

git checkout debian
git merge 6.x-1.x
git describe
dch -v 1.0~rc3+28-1
git-buildpackage --git-tag

This is also available in the Debian package as:

./debian/rules jenkins-build-auto

4. Installing packages manually

dpkg -i aegir-provision_1.0~rc3+g6632e6e-1_all.deb

We also make sure our custom makefile fetches the right one from provision:

-includes[aegir] = ""
+includes[aegir] = ""

5. Developing on Debian

To develop third party extensions to Aegir on Debian, it is recommended to install the Debian packages. If you are working on Aegir core, this could be a bit trickier since the files are not where you expect them to be and are not deployed as git repositories however.

You can, however, copy in place a .git directory using the following:

git clone --branch=6.x-1.0-rc7
-Rp provision/.git /usr/share/drush/commands/provision/.git
cd /usr/share/drush/commands/provision
git stash

This will bring back a bunch of files that are removed from the Debian package, so it will yield warnings on uninstall of the Debian package but it should otherwise work.

You can do something similar with the frontend.

6. Package versioning

The stable repository should contain the latest release. The testing repository will also contain the latest release (unless we're in the process of building a release) but could have fixes to the Debian package that are being tested. The unstable repository is automatically built from the stable branch and may be broken.

To see what changes are done to the Debian package, see the debian/changelog which is maintained on the debian branch. To see which version of the package is currently available in the repository, you will unfortunately need to parse the Packages file for unstable, testing or stable.

7. Adding a new uploader

To enable a new maintainer to upload to the Debian repository at, something like the following steps will have to be followed:

Create a ~/.dput.cfg with the following entry:

# See /etc/ for examples
login     = *
# login     = another_username
fqdn      =
method      = scp
incoming    = ~reprepro/incoming

Next, GPG keys will have to be authorized to upload to the repository:

sudo -u reprepro -i
gpg --search-keys
gpg --fingerprint ; gpg --check-sigs # check if this is the real key
echo allow * by key 1234ABCD >> /srv/reprepro/conf/uploaders

8. Replacing an expired key

gpg --gen-key
gpg --list-keys
gpg --keyserver --send-keys <key id>
sudo -u reprepro -i
gpg --search-keys <key id>
gpg --fingerprint ; gpg --check-sigs # check if this is the real key
echo allow * by key <key id> >> /srv/reprepro/conf/uploaders

9. How the archive was built

The following documentation was used:

1.0 roadmap


This is a brief outline of development plans for Aegir.

Update: this roadmap is not up to date anymore. Effectively, 0.4 and parts of 0.5 and 0.6 were all squashed into an API-stable 1.0 release published on in spring 2011. 1.0 is now in maintenance mode and only critical bugfixes will be accepted in the tree. This roadmap is therefore superseded by the 2.0 roadmap.

Note that all formal Aegir releases (ie. not those marked, "alpha", "beta" or "release candidates" or "RC") are production-ready. We strive hard to maintain good code quality and Q/A by frequent releases and alpha/beta/RC stages before those formal releases so even if the releases are marked 0.x, it's not because they are not stable or ready, it's simply because the API is not stable (see below).

0.1 - "Sites" - Single platform support

Solid release for Drupal 5 platform. Will not be able to upgrade. Production ready.

0.2 - "Upgrades" - Multiple platforms support

Support for more than one Drupal release. Support for migration between Drupal releases. Experimental support for remote SQL servers. Frontend still in Drupal 5.

0.3 - "d6" - Drupal 6 frontend support

In the backend: bugfix release of 0.2. In the frontend: port to Drupal 6.

0.4 - "Cloud" - Multiple servers support

Support ssh as communication channel between multiple servers (see this issue) Move sites between servers, and support for multiple db servers and moving between them.

Release goals for 0.4

0.5 - "apt-get" - proper deployment procedures

proper deployment procedures (features? proper project management? etc)

0.6 - "UX" - User interface improvements

Clean up and make the user interface friendlier.

1.0 - "API" - API freeze

A stable, published API for Hostmaster modules that will be frozen during the whole lifetime of the 1.0 branch to ease long term support for third party extensions.

From there on...

Extension modules

There is also a host (pun intended) of provisioning tasks that it would be nice to see created:

  • LDAP (open LDAP)
  • Solr Search (Tomcat)
  • Jabber (ejabberd)
  • DNS (Bind, DNSmasq etc - Actually already implemented in the 0.4 line)
  • Pound (load balancer)
  • Email (Zimbra)
  • An RDF triple store (needs more research)
  • Asterisk (voicemail, proxy)

Mass site operation modules

  • Search (could be related to Solr)
  • Statistics (info on nodes/comments/users etc. across all / many sites)
  • Logging (centralized logging overview, might just be web interface for syslog)
  • Spam / Comment moderation (we had some discussion about writing a Mollom module that works across sites)

Feel free to contact the developers if you are interested in pitching in to work on one or more aspects of Aegir.

2.0 roadmap

Following the Drupalcon Chicago 2011 BOFs discussion, the community came up with a series of ideas and wishlist items for the upcoming 2.0 release. This roadmap may be updated or trimmed down as development goes ahead.

We do not commit to doing all of this for 2.0, this is mostly a wishlist of what people expressed were priorities for them during the brainstorm. If people want things to move forward, they will need to submit patches or create feature branches, basically lead development on the feature you want. This page can be used to coordinate overall leadership of those issues, while pointing to the issue queues for the specifics.

This roadmap supersedes the previous 1.0 roadmap.

Update: this roadmap is very ambitious, and should be considered more as a "wishlist". What we agreed on during the february 6th 2012 scrum was that we would focus on those items, in order of higher to lower priority:

  1. Autoloaded classes (means we drop support for PHP 5.2 and below)
  2. Drush 5 support

Once all those are done, 2.x should go in beta and once there are no criticals, it gets release, even if we don't have all the other features listed below.

Update: this is superseded by this roadmap:

1. Drush collaboration

We want to collaborate more with the good people in the Drush project. We had good conversations at Drupalcon and hope to keep on having more about how to do staging, sharing code, working with contexts and aliases and so on.

This collaboration should permeate the whole 2.0 release cycle, as a lot of goals here overlap work already happening in the Drush project. We have a long tradition of leading development of new features in Drush, by first implementing them in Provision, and we should continue that trend, with a focus on merging those changes back up into Drush, and eventually removing them from Provision in 2.0.

Koumbit plans to keep on taking care of the Drush Debian packages and coordinate with the Drush team as much as possible.

1.1. Sending more code upstream

Our "contexts" code could be refactored and sent upstream. provision-save would be a likely first target, along with the persistent "contexts" classes. Note that we have hit a significant wall in the current API because it is hard to interoperate with existing server and site contexts from the outside of the class, so that's something that should be cleared up before going ahead with those merges.

1.2. Removing common code

At the very least, we should start removing common code between site-install and provision-install. The new drush archive command should also replace our builtin provision-backup, and provision-save may be refactored around drush_save_config() too (see issue #736686 for this).

1.3. Standard archive support

... which brings us to the standard archive format. Drush and Aegir developers have collaborated to create a common format to export and import Drupal sites. A single archive could bundle one or many sites, including site-wide code, so this is a significant difference (and improvement) over the current de-facto Aegir standard.

We want to support that new format. Full multi-site archives should be imported as platforms, while Aegir could keep on exporting single-site archives for standard platforms, like OpenAtrium or other distributions.

1.4. Unit testing

Drush has started to implement unit testing with PHPUnit in Drush 5 (see the tests directory for samples), and we should jump in that party, extending those classes and unit-testing the hell out of Aegir itself. That will make merging features into Drush easier and make sure we have no regressions while doing so.

2. Multi-server improvements

While Aegir 1.0 has multi-server support, it is far from ideal or complete, and we wish to harden that design in 2.0.

2.1. From a hub-spoke to a mesh model

The current model where there is one main server (the "hub") where all platforms and sites are created and then synced to remote servers (the "spokes") seems to be showing scalability issues and concerns about where the authoritative data should be.

For example, it's currently not recommended to allow developpers to access sites on remote servers, as the authoritative data resides on the hostmaster site. Another issue is that aliases are maintained only on the master server, and therefore are not accessible on remote servers. Finally, the fact that drush and provision are not installed on remote servers make some operations unnecessarily slow as we need to make the operation locally and then sync the result.

The alternative has yet to be discussed. We especially want to chime in with the Drush community here to see how the best practices should be. The conversation has started, and with the migration of to git, a lot of possibilities just opened up, with a lot of people being all of a sudden more familiar with this excellent too.

In general, it should be possible to expect remote servers to have drush and provision installed and be relatively independent from the "master" server. A design like this could eventually mean that Aegir could manage other Aegir sites and upgrade them. It is the "mesh" design, of which the "hub and spoke" model is only a subset.

This follows the practice of "tools not policy" we are heading towards: we leave the mesh vs hub/spoke decision to the site administrators and provide the tools to support both approaches the best we can.

Koumbit plans to spearhead this effort this summer.

2.2. Improve cluster support (done & backported to 1.7)

The current multi-server model doesn't support clusters and shared filesystems very well. Aegir 2.0 should allow scaling your web hosts horizontally by spreading a single site amongst multiple servers. While 1.0 can setup sites on remote servers, it follows more the concept of "sharding", spreading different sites amongst different servers than load balancing all sites amongst all servers.

This involves supporting load balancers (e.g. IPVs, Pound, Varnish), maybe through the existing "cluster" service, but also shared filesystems (e.g. NFS, OCFS, GFS, GlusterFS), maybe through a new "fileserver" service.

Koumbit plans to spearhead this effort this summer.

Update: this has been implemented with the "web_pack" module, which will be released with 1.7, deprecating the cluster module. 2.x will remove support for the current "cluster" module. See also the updated documentation.

2.3. Optimizing clones and migrates

We quickly mentionned git support above, but this could lead to significant improvements, for example by using git clone --shared instead of the traditional "backup and deploy" approach to clone/migrate sites.

There is certainly the possibility of rewriting clone to optimize away "backup and deploy" and merge them in a single operation that could use copy on write mechanisms like hardlinks (cp -al), git tricks (git clone --shared) or filesystem snapshots (e.g. BTRFS snapshot directory/file support).

Once deploy is optimized, we could consider hooking it the Drupal 7 or third party unit tests to rollback on such failures.

Those optimizations would need to integrate with and support the multi-server model elegantly too, especially the hypothetical fileserver service.

3. Modularization of more systems

Aegir 1.0 is already pretty modular: "services" are an abstract concept that can be implemented and inherited. For example, the "HTTP service" has four implementations: Apache, Apache-SSL, Nginx and Nginx-SSL. The database and DNS layers are also abstracted that way.

But more can be done here.

3.1. Modular backup system

Right now backups can be pretty heavy and use the venerable (1979!) tar backup format and utilities, which made Aegir portable to almost any UNIX operating system. It's a good start, but it's highly inefficient. As mentionned above for the clone and migrate optimization, we could also use modern filesystem features like snapshots or use git support. Another suggestion was to use S3 or similar services for offsite backups.

The basic idea here is that backups should be extendable - if you want to backup in your shoebox, Aegir should allow you to write a plugin for it. There was some initial work done by computerminds on github.

3.2. Modular platform support

This is also known as the alien platform support, that is - being able to install other "things" than Drupal in the backend, for example (oh the heresy!) Wordpress. This involves ripping apart the "platform" code in the frontend and the backend to make it more CMS-agnostic, so that Drupal is just one of the implementations.

This would make sense of course if at least another implementation would be supported. This could also involve merging the site and platform creation forms for those platforms that do not support multi-site like Drupal does (so that creating a site effectively create a platform).

3.3. Modular queuing system

The current queuing system is what we informally call the "ghetto queue". It's a cron job that pulls tasks from a MySQL database. While this scales well for a few sites, on busy servers it's a total nightmare, especially for mass migrations. Tasks stack up and concurrency is not managed at all. This needs to be completely redone.

A possibility is to use Drupal 7's abstracted queue API and let administrators implement their own queuing system according to their local APIs.

The new queuing system could be a key part in how the multi-server "mesh" model would be implemented. It could also be how non-Drush backends could be handled by Aegir - in that scenario, Aegir would become an interface for a standard queuing system, yet to be determined, although a lot of ideas are flying around: Jenkins/Hudson, AMPQ, Drush itself, etc. See this evaluation for that decision.

Koumbit plans to spearhead this effort this summer.

4. Other features

4.1. Automatic upgrades

There were a few discussions around managing platforms automatically. The implementation of hosting-import is one of the building blocks of this, but there remains some fine-tuning for this to work out of the box, especially for new users, some of which have requested that we can build makefiles straight from the frontend, a bit like how it's done on One could also use feature servers feeds to update their platforms. Again, we should leave the policy to the user or at least make this pluggable.

This mostly consists of automating the creation of new platforms, the upgrade of sites between platforms and garbage collection of old platforms.

4.2. PostgreSQL backend support

The backend database layer (the "db class") now supports only MySQL, that is, while the Aegir frontend could technically run in PostgreSQL (although that is still unsure), the backend can't create sites in a PostgreSQL database.

Most of the work here will be around supporting user credentials handling, creation and destruction, which are fairly different between postgres and MySQL. The issue for this is #585796.

4.3. Statistics improvements

Work has already started at Koumbit to implement a "statistics" queue that would mostly pull Apache logfiles and parse it for size (and CPU timing) information. This is to implement bandwidth and CPU quotas, but could be extended in a more generic "statistics" queue that would collect all sorts of information:

  • if your Drupals need to be upgraded or are secure (the basic "status report")
  • how many modules/themes/profiles/libraries are installed (populating the frontend data)
  • how many users/nodes/fields instances do you have?

All this could be collected in a nice dashboard that would outline client, site or platform-specific information.

4.4. Full DNS support

The DNS support in the backend is already pretty mature, but it's not really intuitive how it works and how to integrate it into existing infrastructures. Issue #922280 details all the next steps required here, but we can already say we hope to have a zonefile editor in the frontend, probably based on D7 entities, reasonable access control for zones, registrar support and "host my mail on gmail button" type of wizards.

This could potentially be picked up by a GSoC student.

4.5. Improved intersite security

We are already going through some hoops to make sure the database credentials are not accessible from one site to the other. The credentials are stored in the Apache environment and cleared out as soon as they are used, which makes finding them in settings.php impossible. Koumbit has also worked on a Provision ACL module that implements POSIX ACLs on files which allow more granular access controls on files.

But there are other security issues remaining that we should be looking into, especially the way Drush and Drupal are bootstrapped during tasks, which is currently insecure.

Koumbit plans to spearhead this effort this summer.

5. Contrib modules

Other contrib modules may have different roadmaps, but they must respect the release naming conventions. Contrib modules should aim for a 1.y release now, that will be compatible with the 1.x series. 2.x modules should be ported to Drupal 7 and follow the API (in development) of the 2.x series. Modules do not have to follow the minor version numbers of Aegir. For example, Provision ACL 1.1 is compatible with any release of the 1.x core series.

We are also considering making point releases of the backend and the frontend independent, so that Provision 1.1 and Hostmaster 1.2 could be release independently.

5.1. Other modules roadmaps

This is a short index of other modules roadmaps to 2.0:

D7 port & DNS editor plan (google summer of code 2011)

Plan for porting Aegir to D7 and creating a DNS editor. A project for Google Summer of Code 2011.

Please offer advice on how to improve the plan I've outlined below.

Relevant links: Hostmaster sandbox for GSOC2011

Before May 24:

  • Review Git docs and other resources to learn more about using Git.
  • Review issues/patches relevant to D7 port and DNS editor.
  • Review and
  • Discuss planned work with aegir maintainers.
  • Refine plan below based on what I've learned from the handbook, api, and aegir maintainers.

Week one: Work on porting Aegir theme Eldir to Drupal 7. Finalize plans for porting the Aegir modules and install profile.

Week two: Finish porting Eldir to Drupal 7. Port the Aegir Hosting module to Drupal 7.

Weeks three through six: Port the Task, Client, DB Server, Package, Platform, Site, and Web Server modules to Drupal 7. Test ported modules.

Weeks six through nine: Port modules Alias, Clone, Cron, Migrate, Quota, Signup, Task, and Web Cluster to Drupal 7. Test ported modules.

Weeks ten and eleven: Work on the DNS zonefile editor.

Weeks twelve and thirteen: Continue testing ported projects and the DNS zonefile editor. Update documentation to reflect changes in the upgrade to Drupal 7.

Weekly Scrums

Since we have now a bigger team of people interested in the project (contributors in the queue, outside the queue, people at Koumbit, the community site, my my!!), we (koumbit) feel it would be important to start doing weekly scrums again.

Nothing complicated: just a 15 minutes where we agree we try to be available on IRC to talk about various issues that have or will come up during the week. No work, just talk.. to quote wikipedia:

  • The meeting starts precisely on time.
  • All are welcome, but only “pigs” [devs] may speak
  • The meeting is timeboxed to 15 minutes
  • The meeting should happen at the same location and same time every day
  • During the meeting, each team member answers three questions:
    • What have you done since yesterday?
    • What are you planning to do today?
    • Do you have any problems preventing you from accomplishing your goal?
(It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)

These occur via IRC on the #aegir channel twice a week at separate times:

Every Monday at 20h00 UTC. This works out to be:

  • 11h00 in Los Angeles, USA (PDT)
  • 15h00 in Montreal, Canada; New York, USA (EDT)
  • 19h00 in London, UK (GMT)
  • 06h00 in Melbourne, Australia (EST)(on Tuesday)

(See this useful tool for how we settled on those times.)

Every Thursday at 10h00 UTC. This works out to be:

  • 03h00 in Los Angelas, USA (PDT)
  • 06h00 in Montreal, Canada; New York, USA (EDT)
  • 11h00 in London, UK
  • 12h00 (noon) in Warsaw, Poland
  • 20h00 in Melbourne, Australia (EST)

We will keep logs of these here for future reference.

Archive: 2010


Archive of the weekly scrum from 2010

Weekly Scrum IRC Log: 2010-12-02

(03:00:54 PM) anarcat: hi.
(03:01:08 PM) anarcat: so now is the time for our newly established weekly scrums :)
(03:01:24 PM) anarcat: of course, mig5 is not there and vertice either, but i'll still do my part,
 just to kickstart this
(03:01:32 PM) hadsie: hey anarcat
(03:01:54 PM) anarcat: hey hadsie
(03:03:30 PM) anarcat: so basically, i haven't done much wrt to aegir this week, i'm busy
 with other koumbit work
(03:03:39 PM) anarcat: you're going to hear this often from me, unfortunately :)
(03:04:03 PM) anarcat: my latest thing though is the creation of a debian package for provision
 that can install and upgrade aegir automagically, it's pretty neat and needs testing
(03:05:42 PM) anarcat: i have contacted other debian developpers to get their feedback about
 the possibility of uploading that package straight into debian
(03:07:24 PM) anarcat: the followup for the debian package happens here: and here:
(03:07:36 PM) sfyn: hey folks
(03:07:36 PM) anarcat: in other news i started looking at STS here:
(03:08:04 PM) anarcat: so that's it for my past work, in the next week i'll try to:
(03:08:22 PM) anarcat: figure out proper permissions for multi-(shell)user setups in aegir
(03:08:49 PM) anarcat: right now a lot of our devs use sudo -u aegir to do stuff and that's quite 
messy, we're going to try to figure out the minimum set of perms for that to work, maybe with 
(03:09:03 PM) anarcat: we also need to figure out how we maintain site-specific packages in 
remote servers
(03:09:26 PM) anarcat: and i want to start fixing DNS in the frontend, but we are slowly pushing
 back our objective of having DNS in production to after christmast
(03:09:30 PM) anarcat: so that's it for me
(03:09:42 PM) anarcat: hi sfyn :)
(03:09:43 PM) anarcat: sfyn / ergonlogic / mvc : anything to add?
(03:11:24 PM) simesy: hey i actually made the scrum, (but only because I had to get up for a
 job and now I have to go :P)
(03:11:35 PM) anarcat: :)
(03:11:35 PM) anarcat: i see
(03:11:39 PM) anarcat: well, congratulations :)
(03:11:42 PM) sfyn: I have been sick all week and trying to catch up on my rpod stuff
(03:11:51 PM) sfyn: So very little progress to report
(03:11:59 PM) sfyn: I have a guy who is interested in writing tests for us
(03:12:13 PM) sfyn: Luigi - are you here?
(03:12:38 PM) sfyn: A guy in montreal, but he is a little new to the fabulous world of drupal,
 and FLOSS in general, I get the impression
(03:12:46 PM) sfyn: But he has done unit testing work before
(03:13:00 PM) sfyn: Maybe we should get him to come into the office so we can orient him
(03:13:18 PM) sfyn: hadsie: hey man
(03:14:07 PM) anarcat: thank you sfyn
(03:14:16 PM) anarcat: so our little scrum is almost over, anybody got anything to add before
 we move on?
(03:16:26 PM) anarcat: thank you for your attention, and see you next week!

Weekly Scrum IRC Log: 2010-12-09

(02:57:33 PM) ergonlogic: everyone: Weekly scrum being in ~5 mins
(02:57:57 PM) mig5: trying to wake up :)
(03:01:49 PM) anarcat: hey hey!
(03:01:55 PM) anarcat: good morning world!
(03:02:01 PM) omega8cc: hey
(03:02:10 PM) ***anarcat tries to play the gooooood moooorning vietnam cue here
(03:02:12 PM) mig5: good morning, here at least :)
(03:02:16 PM) anarcat: so
(03:02:31 PM) anarcat: welcome to our weekly scrum session, we have ... 13 minutes left
(03:02:35 PM) mig5: woot
(03:02:41 PM) anarcat: we failed at the first directive, and i'm sorry for that (start on time, damnit!)
(03:02:50 PM) ergonlogic: my fault
(03:02:51 PM) anarcat: and i'll start with my stuff, i didn't do much last week
(03:03:02 PM) anarcat: in fact, nothing i can remember
(03:03:14 PM) anarcat: next week is likely to be similar as i'm over[load]ed with thousands of internal needles
(03:03:20 PM) anarcat: that's all for me :)
(03:03:22 PM) mig5: yay
(03:03:29 PM) mig5: ok
(03:03:47 PM) mig5: to carry on that tune, i didn't do much last week, i have been trying to catch up on some tickets
(03:03:53 PM) mig5: my immediate aims are,
(03:04:04 PM) mig5: to test the debian packages now that i know they're in unstable
(03:04:07 PM) mig5: which i will do today
(03:04:24 PM) mig5: and possibly help ergonlogic with this clients permission stuff
(03:04:45 PM) mig5: after that i will start looking at the 'for review' patches in the queue per our beta2 plans
(03:04:51 PM) mig5: but that may not get to happen until next week
(03:05:01 PM) anarcat: rc2 you mean
(03:05:02 PM) mig5: that's about it from me
(03:05:06 PM) anarcat: ok
(03:05:08 PM) mig5: oh really
(03:05:10 PM) mig5: rc2?
(03:05:12 PM) anarcat: er
(03:05:13 PM) anarcat: no
(03:05:15 PM) anarcat: i don't
(03:05:16 PM) mig5: haha
(03:05:18 PM) ***anarcat is on crack, nevermind
(03:05:24 PM) anarcat: i was confusing us with drush, sorry
(03:05:29 PM) mig5: i would be happy to push for rc1 :)
(03:05:32 PM) anarcat: ergonlogic?
(03:05:48 PM) anarcat: sfyn is offline today, but i know he tried to get back into things and will keep on doing that
(03:05:50 PM) ergonlogic: well, I'm working on the permission issue that mig5 mentioned
(03:06:02 PM) ergonlogic: and the udev dependency
(03:06:11 PM) anarcat: right, about that
(03:06:22 PM) anarcat: i'm sure that moshe_work and other drush people would love to see that land in drush 4
(03:06:27 PM) ergonlogic: just trying to get into the swing of things, and familiarize myslef with some of aegir's inner workings
(03:06:32 PM) anarcat: but i'm not sure we'd make it for rc3 at this rate
(03:06:51 PM) anarcat: how do you feel about this?
(03:07:32 PM) ergonlogic: well, I think I'm about half way there on that issue
(03:07:40 PM) anarcat: alright
(03:07:41 PM) ergonlogic: but I still nee to post a patch
(03:07:47 PM) ergonlogic: s/nee/need
(03:07:48 PM) anarcat: ok
(03:08:11 PM) anarcat: *and* it would then need to be ported up to drush... so we can safely assume we won't make it into drush 4, those guys are in a rush :)
(03:08:20 PM) anarcat: speaking of drush
(03:08:28 PM) mig5: in a rush or in a drush? :)
(03:08:33 PM) anarcat: drush is that somebody omega8cc tested aegir with drush 4-rc1, and it works
(03:08:34 PM) anarcat: hehe
(03:08:35 PM) ergonlogic: groan
(03:08:40 PM) mig5: sorry..
(03:08:44 PM) anarcat: hehe
(03:08:49 PM) anarcat: alright
(03:08:55 PM) mig5: yes Vertice asked me to test that too, another thing on my todo list
(03:08:59 PM) anarcat: so
(03:09:00 PM) mig5: glad someone else did
(03:09:02 PM) anarcat: i guess one last thing
(03:09:32 PM) anarcat: we heard from vertice finally and he's coming back after a small hiatus, he's going to concentrate on documentation stuff and helping us figuring [stuff] out
(03:09:40 PM) anarcat: he's also eager (hehe) to release an rc
(03:09:45 PM) anarcat: so maybe it's something we should consider
(03:09:49 PM) ***anarcat looking at rc bugs
(03:10:22 PM) mig5: we have had the benefit of not having too many new criticals. i think if we can tie off some existing patches, we could look at that perhaps
(03:10:26 PM) anarcat: so most of those are postponed (so needs testing and closed: worksforme)
(03:10:44 PM) mig5: do you have a link to the rc bugs
(03:10:50 PM) anarcat:,+hosting,+hostslave,+eldir,+Hostmaster+(Aegir)&status=Open&priorities=1&categories=All
(03:11:05 PM) anarcat: one is the freaky multiserver thing, i'd like adrian or somebody else to look at that one as i don't have the resources or time or brain to look into this
(03:11:11 PM) anarcat: that one is
(03:11:20 PM) anarcat: the other one is the site form optimisation:
(03:11:27 PM) anarcat: which could be postponed to post 0.4
(03:11:33 PM) anarcat: so we need testing, basically
(03:11:39 PM) mig5: yeah i'm still not convinced the multiserver thing is just someone trying to do something we don't support at all (i.e spoke vs mesh model)
(03:11:42 PM) mig5: yep
(03:11:49 PM) anarcat: alright
(03:12:03 PM) anarcat: so i would favor more a testing + rc1 than a beta2 at this point
(03:12:07 PM) ergonlogic: I'm into testing the multi-server stuff, if that's on the menu
(03:12:17 PM) anarcat: ergonlogic: it is, take a look at
(03:12:20 PM) ergonlogic: and dns
(03:12:29 PM) anarcat: dns + ssl integration needs testing too:
(03:12:44 PM) anarcat: and this should probably just be closed: (new servers probably work fine)
(03:12:52 PM) anarcat: that one is more hairy:
(03:12:57 PM) anarcat: not suer about it
(03:13:12 PM) anarcat: but really, i believe we could just test those quickly and release next week, how about that?
(03:13:56 PM) mig5: sounds good, perhaps late next week, allowing me my thursday/friday where i can spend like a whole day looking at some of this
(03:13:56 PM) ergonlogic: I'll look into provisioning some new servers :)
(03:14:02 PM) anarcat: ok
(03:14:04 PM) anarcat: awesome
(03:14:07 PM) anarcat: okay, anybody else has something to add here?
(03:14:24 PM) anarcat: so thank you for attending, and have a nice day!
(03:14:31 PM) ergonlogic: cheers!
(03:14:34 PM) mig5: cheers

Weekly Scrum IRC Log: 2010-12-16


07:00 <@mig5> scrum time
07:00 <@anarcat> hi
07:00 <@mig5> morning
07:01 <@anarcat> good morning!
07:01 <@anarcat> not much to report on my side again, other than i forgot to book a session for drupalcon :/
07:01 <@mig5> hehe
07:01 <@anarcat> we're working on LDAP support and we'll focus on intersite security after christmas
07:01 <@mig5> i did make a tweet after i saw there are three aegir related proposals
07:01 <@mig5> oh sweet! LDAP++
07:01 <@anarcat> add a way for aegir to run tasks as a real user instead of itself, so that site A can't see site B's stuff
07:03 <@mig5> cool - that's it from you?
07:04 <@anarcat> yes, sorry
07:04 <@mig5> no worries
07:04 <@mig5> ok, so (again) i haven't done much
07:05 <@mig5> i tried to address some of the for review tickets in the queue, committing two of hadsie's work which i tested
07:05 <@anarcat> that's much :)
07:05 <@mig5> i didn't get to test your debian packages against another squeeze install but i did comment on the ticket about what i think the issue is there
07:05 <@anarcat> yeah, you're right about the issues, feel free to fix if you have time
07:06 <@mig5> but mainly i have been just staring at the queue and feeling out of steam (again), I wonder whether it is time to look at adding more people to the project
07:06 <@anarcat> i agree
07:06 <@mig5> as i feel i'm getting less and less useful, and vertice is taking a break etc,
07:06 <@mig5> and you are tied up a lot with internal stuff (which is fine)
07:06 <@anarcat> i don't feel you're less and less useful though :P
07:07 <@mig5> well that's ok :) i think it speaks for itself
07:07 <@mig5> and things have slowed down so lets get some more hands on deck basically.
07:07 <@mig5> also, i have a client at the moment who is interested in seeing two things happen:
07:07 <@mig5> a dns frontend and scheduled tasks
07:07 <@mig5> Steven Jones has been doing great work with scheduled tasks and created a contrib project hosting_backup_queue
07:08 <@mig5> i was going to ask whether Koumbit were already working on a dns frontend
07:08 <@mig5> we can discuss that later if you like
07:08 <@mig5> and that's about it from me
07:09 <@anarcat> ok, anybody else?
07:09 <@mig5> maybe it would be nice to summarise these scrum sessions as a 'weekly aegir news' email to the mailing list, making people aware of stuff like Steven Jones' contrib project etc
07:09 <@anarcat> mig5: i have ideas on the frontend: 1) there should be code we can resurrect from older git repos and 2) i have a workflow for the blacklisting algorithm (can't let anyone host any zone can't we...)
07:09 <@anarcat> yep
07:10 <@mig5> i am happy to do so
07:11 <@mig5> (re: news)
07:11 <@mig5> ok -we are 11 minutes in anyone else have anything to add?
07:12 < erutan> re: news to save time you could always just dump the relevant irc log onto the open atrium site
07:12 <@mig5> we do that already, yep
07:12 <@mig5> maybe that's enough.
07:12 <@anarcat> yeah...
07:13 <@anarcat> alright, thanks for coming everyone!
07:13 <@mig5> cheers
07:13 <@mig5> cheers
07:14 <@mig5> adding the irc log now
07:15 < noecc> mig5: anarcat: vertice: and others  You have done great things with aegir.  Don't let your steamlessness get you down.
07:15 <@anarcat> :)
07:15 <@anarcat> thanks :)

Weekly Scrum IRC Log: 2010-12-23

Note that none of the core devs were in attendance for this session. Regardless, this is the discussion that ensued:

(03:01:56 PM) darthsteven: Is the scrum at 2005?
(03:05:10 PM) ergonlogic: I guess I could start, pending the arrival of the core devs
(03:05:28 PM) ergonlogic: This week I upgraded to beta2 and began testing remote servers
(03:05:58 PM) ergonlogic: the beta2 upgrade required debugging some misconfiguration I had done previously, but otherwise everything seems to be working fine
(03:06:32 PM) ergonlogic: so far, I can verify a remote platform, but can't yet provision a site on it
(03:06:48 PM) ergonlogic: so that'll be something I look at over the holidays
(03:07:03 PM) ergonlogic: finally, I published and api site
(03:07:27 PM) ergonlogic: currently at, but hopefully will point ot it soon
(03:07:34 PM) ergonlogic: that's it for me
(03:07:49 PM) ergonlogic: happy holidays everyone
(03:08:07 PM) eft_: I started a Why Aegir wiki
(03:08:35 PM) eft_: hope to add some graphics at some point
(03:08:50 PM) eft_: we need to market Aegir more :)
(03:09:50 PM) ergonlogic: eft_: agreed about the mktg, but the move to beta seems to have helped already
(03:10:35 PM) eft_: how so?  do you mean the perception of getting out of alpha?
(03:11:21 PM) omega8cc: I submitted my first attempt to resolve the issue with remote files being removed on site verify, testing it is welcome:
(03:13:15 PM) omega8cc: the issue is mentioned on
(03:14:00 PM) ergonlogic: eft_: yes
(03:14:31 PM) omega8cc: oh, and is hosted on Aegir
(03:14:52 PM) eft_: cool

Archive: 2011


Archive of the weekly scrums from 2011

Weekly Scrum IRC Log: 2011-01-07

07:01 <@mig5> Scrum time
07:01 <@mig5> who is here for the meeting, anarcat?
07:01 <@mig5> nope :)
07:01 <@mig5> sfyn: 
07:02 <@mig5> well i'll start. another week gone by without looking at DNS, but we have a good roadmap now thanks to anarcat, i may start looking at that today
07:03 <@mig5> we're now compatible with drush 4 (at the moment)
07:03 <@mig5> i cleaned up some of the hostmaster profile thanks to drush 4's supporting of drupal_set_message being sent to stdout during install profile execution, which identified some legacy stuff that could be removed
07:04 <@mig5> i'm going to look at dns, upgrades, and some multiserver stuff today hopefully
07:05 <@mig5> i also hope to look at darthsteven's new contrib module hosting_backup_gc
07:05 <@mig5> and am trying to think of a nice way to let people list their contrib modules on teh community site. i wonder if we should have an inbuilt Featureserver for that sortof thing to let people upload them
07:05 <@mig5> thats it from me (i am talking to myself anyway? :) )
07:06 <@mig5> i'll leave it for another 5 min and if nothing happens, will drop that into the logs

Weekly Scrum IRC Log: 2011-01-14

06:59 <@anarcat> SCRUM START NOW!
06:59 <@anarcat> welcome everyone :)
06:59 <@anarcat> i'll start with myself
06:59 <@anarcat> i am just out of a lenghty (2.5 week) vacation
06:59 <@anarcat> which was very good
06:59 <@anarcat> i have done absolutely no aegir work since decembre
07:00 <@anarcat> and i don't plan on doing anything until monday
07:00 <@anarcat> at which point we'll update our prod server to head and try to make it work
07:00 <@anarcat> i had big unexpected issues last time with that
07:00 <@anarcat> in general, i feel there's something very fishy with aliases, i feel this affects more than one of my server instances\
07:00 <@anarcat> i suspect it may be related to drush 3.3 or the drush package of
07:01 <@anarcat> so i'll be working on that
07:01 <@anarcat> i have also a huge backlog of internal aegir issues that may yield a few bugfixes
07:01 <@anarcat> this will be a good Q/A to maybe lead to an RC somewhere next week
07:01 <@anarcat> so that's it for me
07:01 <@mig5> nice one
07:02 <@mig5> i've not done much except, updated our makefiles to depend on drush 4 and new drush make
07:02 <@mig5> i also updated the upgrade script to remove some hardcoded crap and be more consistent with the
07:02 <@anarcat> coool
07:02 <@mig5> i *wanted* to work on DNS but sorry, I am just really struggling to do anything aegir :(
07:02 <@anarcat> you've actually done some real work, crazy ;)
07:02 <@mig5> well not really.. :s
07:03 <@mig5> finally, i'll just note on what i think is our most critical bug right now, and i hope to focus on this instead
07:03 <@mig5>
07:03 <@anarcat> Vertice: anything to add? how is the DNS change coming up?
07:03  * anarcat takes a look
07:03 <@mig5> verify a remote platform/site and it deletes shit in your site's /files dir :s
07:03 <@anarcat> right, ok
07:03 <@anarcat> mig5: i think it's good to sync only some files and not the whole dir
07:03 <@mig5> because we do these crazy syncs of the entire codebase *after just syncing the settings.php, and then the drushrc.php, etc*
07:03 <@mig5> yes
07:04 <@mig5> anyway, can discuss that later, just wanted to mention what i think i'll focus on for the moment
07:04 <@anarcat> that's very good.
07:04 <@mig5> and that's it from me
07:04 <@anarcat> and it it's RC indeed
07:04 <@anarcat> i need Vertice to do changes to the DNS to activate ergonlogic's API site so we have
07:04 <@anarcat> anyone else wants to add something?
07:04 <@mig5> i'd like to add to that and possibly take over the hosting of at least, so we can get that updated
07:05 < ergonlogic> thanks anarcat
07:05 <@mig5> or possibly even take over the DNS for itself, in the event i ever need to move the mailing list server or something
07:05 < eft_> mig5 : +1 to that idea
07:05 <@mig5> just for the sake of speed, but it's up to devseed
07:05 <@anarcat> yeah
07:05 <@anarcat> i don't mind you hosting that, koumbit can also host DNS and the site
07:05 <@mig5> yeah either way :)
07:05 <@anarcat> i offered this to Vertice, i expect us to have DNS soon
07:05 <@mig5> cool
07:05 <@anarcat> (us = koumbit)
07:05 <@mig5> yep
07:06 <@anarcat> but for the site, yeah, it would be important to at least have a backup ...
07:06 <@mig5> darthsteven: feel free to chime in - you've been doing great work with contrib aegir stuff
07:06 < darthsteven> ah okay
07:06 < eft_> either way, it would be nice to increase the cookie timeout on
07:06 <@anarcat> yeah, if anyone else wants to jump in, feel free to talk :)
07:06 < darthsteven> So I've been thinking mostly
07:06 <@anarcat> if you're doing dev on aegir, now's the time to talk (after darthsteven :)
07:06 < darthsteven> Mainly about provision contexts
07:07 < darthsteven> and provision-save and services and how all the pieces fit together
07:07 < darthsteven> I have an outline for a handbook page(s) that should document most of what's going on
07:08 <@mig5> oh that'd be nice. since you have chosen the bit that no-one understands how it really is meant to work :)
07:08 < darthsteven> Nothing new in contrib land from me this week
07:08 <@anarcat> cool
07:08 <@anarcat> i think Vertice did some work in that direction in the handbook already
07:08 <@anarcat> ok
07:08 <@anarcat> anyone else?
07:08 < darthsteven> mig5: yeah, it is complex...
07:08 < darthsteven> that's it from me
07:08 <@mig5> yes darthsteven have a read of that if you've not already
07:09 <@anarcat> cool
07:09 <@anarcat> ok last call, anyone else?
07:09 <@anarcat> anybody have time to log this into the community site?
07:09 <@mig5> sure
07:09 <@mig5> thanks all! goodscrum
07:10 <@anarcat> thanks!
07:10 <@anarcat> happy new year everybody, and thanks for attending!
07:10 <@anarcat> SCRUM END!
07:10 < darthsteven> 

Weekly Scrum IRC Log: 2011-01-20

(03:00:17 PM) anarcat: welcome to our weeeeekly scrum!
(03:00:28 PM) anarcat: good morning, good evening, wherever you are!
(03:00:39 PM) anarcat: those new to the scrum can read on them here;
(03:00:43 PM) anarcat: otherwise i'll start
(03:00:57 PM) anarcat: yesterday i upgraded our prod server from alpha14 to beta2, and it went well
(03:01:00 PM) anarcat: mostly without an hitch
(03:01:05 PM) anarcat: i was really surprised, actually
(03:01:15 PM) anarcat: i expected to see the weird issues with aliases
(03:01:27 PM) anarcat:
(03:01:30 PM) anarcat: but i didn't
(03:01:34 PM) mig5: pretty smooth upgrades from the later alphas
(03:01:44 PM) anarcat: however, when upgrading a client from alpha6, i had issues with the upgrade path
(03:01:56 PM) anarcat:
(03:02:08 PM) anarcat: the above contains a nice demonstration on how to fix the issues
(03:02:22 PM) anarcat: i am not sure we should fix anything there, as it's really hairy to fix and affects very few people
(03:02:25 PM) anarcat: not worth it, i think
(03:02:32 PM) anarcat: i have filed a bunch of bug nevertheless
(03:02:36 PM) anarcat: after our prod upgrade
(03:02:40 PM) anarcat: had performance issues with the migrate page
(03:02:51 PM) anarcat: which we fixed:
(03:02:59 PM) anarcat: that needs testing, but maybe I can just merge it now
(03:03:13 PM) anarcat: we also have numerous issues with the site form that remain
(03:03:15 PM) anarcat: esp
(03:03:23 PM) anarcat: ie. the ssl cert selection doesn't pop up
(03:03:37 PM) anarcat: and that page is still slow as hell
(03:03:41 PM) anarcat: which may be related to
(03:03:59 PM) anarcat: so that's it for last week
(03:04:06 PM) mig5: wow! :)
(03:04:09 PM) anarcat: next week i'll try to fix a shitload of bugs i have in the backlog
(03:04:15 PM) anarcat: that other koumbit workers reported
(03:04:24 PM) anarcat: mostly upgrade issues, sometimes contrib-modules (e.g. date) related
(03:04:27 PM) ergonlogic: anarcat++
(03:04:38 PM) anarcat: once i'm through this, i am thinking of looking again at a RC release
(03:04:45 PM) mig5: anarcat has taken over skynet again
(03:04:49 PM) anarcat: but i am curious what others think about this
(03:04:58 PM) anarcat: mig5: i wish...
(03:05:07 PM) anarcat: i still struggle to free some time for aegir here
(03:05:12 PM) anarcat: but that may get better with time
(03:05:17 PM) anarcat: my focus right now is stabilising our thing
(03:05:24 PM) mode (+v grugnog_laptop) by ChanServ
(03:05:30 PM) mig5: i am the opposite, i have the time but not the skills :)
(03:05:33 PM) anarcat: targeting feb. for stabilisation, then working on security during feb.
(03:05:39 PM) mig5: yes for RC, that's a good idea
(03:05:49 PM) mig5: i even forgot we agreed to jump from 0.4 to 1.0
(03:05:52 PM) mig5: in september
(03:06:01 PM) anarcat: re. taht, we still have 2 RC bugs
(03:06:04 PM) anarcat:
(03:06:07 PM) anarcat:
(03:06:10 PM) anarcat: The bulk operations form for site listings shouldn't list install and import tasks
(03:06:14 PM) anarcat: ssl rollback failure
(03:06:25 PM) anarcat: we should consider the option of rolling back the bulk ops shit if it breaks stuff
(03:06:32 PM) anarcat: but that seems like an easy thing to fix
(03:06:36 PM) anarcat: the ssl rollback sounds more hairy
(03:06:46 PM) anarcat: but i think we can ship an RC with it as a known issue
(03:06:51 PM) mig5: yeah.. i opened a ticket here and there about bulk ops. not really major bugs, just little niggly things
(03:06:53 PM) anarcat: that's it for me
(03:06:55 PM) mig5: yeah
(03:07:01 PM) mig5: ok
(03:07:09 PM) anarcat: go mig5 !
(03:07:13 PM) mig5: in classic mig5 style i have done nothing
(03:07:15 PM) mig5: EXCEPT
(03:07:18 PM) mig5:
(03:07:26 PM) mig5: i fixed our major and possibly only data-loss bug
(03:07:39 PM) mig5: that was deleting stuff from a site's 'files'dir on a remote server on every verify
(03:07:43 PM) mig5: and hence migrate, etc.
(03:07:52 PM) anarcat: "just that"
(03:07:56 PM) anarcat: dude that's awesome
(03:08:00 PM) mig5: that was a major aegirwtf but it seems to be ok now
(03:08:07 PM) omega8cc: that fix makes rc possible, imo
(03:08:08 PM) anarcat: cool
(03:08:32 PM) anarcat: right
(03:08:36 PM) anarcat: mig5: what's up next week?
(03:08:43 PM) mig5: i don't think i've done anything else :s i have given up on the idea of getting anywhere with the dns stuff, so i won't make promises there
(03:08:44 PM) anarcat: dns? ;)
(03:08:47 PM) mig5: haha
(03:08:47 PM) anarcat: Vertice: you there?
(03:08:51 PM) mig5: damn
(03:08:52 PM) anarcat: hehe
(03:08:55 PM) anarcat: it's okay
(03:09:05 PM) anarcat: our discussion helped me rehash the roadmap, so it's all good
(03:09:39 PM) anarcat: mig5: anything else?
(03:09:53 PM) mig5: this is weird: and i think i've reproduced it, so i will probably take a look at that
(03:10:06 PM) mig5: it's not *too* critical but it means remote servers need a manual apache restart or something, after the task completes
(03:10:14 PM) anarcat: right
(03:10:15 PM) anarcat: ok
(03:10:15 PM) mig5: so this is just stability stuff
(03:10:22 PM) mig5: that's it from me
(03:10:28 PM) anarcat: i have seen weird ordering issues like this even in local, but i never found it to be a bug so far
(03:10:31 PM) anarcat: okay
(03:10:34 PM) anarcat: omega8cc / ergonlogic / others: any comments? what you did last week / will do next week?
(03:10:37 PM) anarcat: Vertice: ?
(03:11:10 PM) darthsteven: I didn't get chance to write up 'contexts' this week
(03:11:19 PM) darthsteven: But hope to next week
(03:11:23 PM) anarcat: awesome
(03:11:27 PM) anarcat: otherwise i want to say that we (the aegir project) are always looking for new blood
(03:11:34 PM) darthsteven: That's it from me
(03:11:49 PM) mig5: nice darthsteven, i am looking forward to learning how this stuff works :)
(03:11:55 PM) omega8cc: from me - I made a few important changes to nginx configuration and plan to submit all of them shortly, also next week I plan to submit nginx installer, promised long time ago
(03:11:59 PM) ergonlogic: nothing really on my end, though I've noticed some odd behaviour since updating to beta2, so I'll be looking through open issues and filing some bugs possibly this week
(03:12:12 PM) anarcat: we need testers (dl new release and report bugs, test existing issues), documentors (!) and developpers (submit and review patches and we will love you and give you commit access)
(03:12:35 PM) anarcat: ergonlogic: awesome!
(03:12:44 PM) anarcat: omega8cc: patches to hostmaster-install? or bash scripting?
(03:13:28 PM) anarcat: otherwise, anybody else has somethign to say?
(03:13:35 PM) ergonlogic: oh, also DNS for should shortly be working (thanks Anarcat!), so check out that resource
(03:13:42 PM) omega8cc: anarcat: mostly nginx conf templates, installer script (very simple bash) and some UI improvements
(03:13:58 PM) ergonlogic: It exposes some pretty spotty documentation in the code
(03:14:15 PM) anarcat: oh right, we are in the processing of transfering the dns to a new registrar (yay!) and hopefully that will go without an hitch
(03:14:23 PM) anarcat: omega8cc: i'd love to see this factored into hostmaster-install
(03:14:33 PM) anarcat: ergonlogic: those could be reported as bugs, maybe...
(03:14:43 PM) mig5: sure
(03:14:45 PM) anarcat: ergonlogic: Vertice expressed interest in working on those documentation issues
(03:14:55 PM) anarcat: okay, so that's pretty much it, thanks for attending our daily scrum!
(03:15:03 PM) mig5: cheers
(03:15:05 PM) anarcat: have a nice day, wherever you are!
(03:15:09 PM) ergonlogic: that's what I had in mind, with maybe some doc patches where I can grok the code
(03:15:16 PM) anarcat: can somebody file this in the OA site?
(03:15:19 PM) darthsteven: Bad docs are bugs for sure
(03:15:21 PM) omega8cc: anarcat: that is simple installer and how-to for standalone nginx based installs,
(03:15:23 PM) ergonlogic: I got it
(03:15:29 PM) anarcat: ergonlogic: thanks
(03:15:37 PM) anarcat: scrum over, see you again next week :)
(03:15:38 PM) anarcat: ciao !
(03:15:40 PM) darthsteven: Thanks everyone
(03:15:43 PM) ergonlogic: Take care
(03:15:47 PM) omega8cc: ciao

Weekly Scrum IRC Log: 2011-01-27

07:01 <@anarcat> morning!
07:01 <@anarcat> scrum is late omg! ;)
07:01 <@mig5> hai!
07:01 <@mig5> oops
07:01 <@anarcat> sorry i'm late :)
07:01 <@mig5> too many emails to read
07:01 <@anarcat> first rule of scrums : start on time damnit! ;)
07:01 < eft_> people still use email?
07:02 <@mig5> only 1 minute off. i blame timezones
07:02 <@anarcat> so anyways
07:02 <@anarcat> i almost caught up on all my issues
07:03 <@anarcat> i reported a few following significant upgrades
07:03 <@anarcat> maybe that was last week
07:03 <@mig5> I think so :)
07:03 <@anarcat> i want to make rc tonight
07:03 <@mig5> !
07:03 <@anarcat> oh, we have deployed our first d7 platform here
07:03 <@mig5> nicely done.hefring in here runs on d7
07:04 <@anarcat> still waiting on actual tests for this - i think i'll just merge it in:
07:04 <@anarcat> i agree with that path shouldn't be editable
07:04 <@anarcat> and well, that's it!
07:04 <@mig5> nice!
07:04 <@anarcat> i think that koumbit will rework its own roadmap next week, so i'll keep you up to date on that
07:04 <@anarcat> so how about an rc?
07:04 <@mig5> yes please do merge that in, i have heard a number of people add those indexes themselves and report good results
07:05 <@mig5> an rc sounds good
07:05 <@mig5> i would like to fix this
07:05 <@mig5> this functionality got ripped out for some reason in like, June
07:05 <@mig5> so it's not critical, but i hate seeing good work disappear
07:05 <@anarcat> ah
07:05 <@anarcat> yeah, agreed
07:06 <@mig5> i'll briefly run through what i've been doing in the last 48 hours
07:06 <@mig5> i've mainly been trying to stabilise a bunch of shit
07:06 <@mig5> You could create platforms and servers with the same names/hostnames, leading to Duplicate entries and context clashes
07:06 <@mig5> 
07:07 <@mig5> Drush 4.x is broken in terms of rsyncing stuff to remote servers, so I reverted HEAD to use 3.3. see
07:07 <@mig5> Drush Make beta10 is broken re: remote makefile referencing. So upped to beta11.
07:07 <@mig5> committed that fix for that Quota bug:
07:07 <@mig5> Some deprecated ereg_replace thing in provision
07:07 <@mig5> uid 1 was not mapped to client 1 in hosting_client_user which broke some client-based platform access control
07:08 <@mig5> unconed identified an infinite loop with provision-save and contexts:
07:08 <@mig5> I couldn't reproduce the infinite loop but can confirm clusters simply don't work
07:08 <@anarcat> about that uid1 thing - i thought uid1 was bypassing all access checks?
07:08 <@anarcat> i think ergonlogic had problems with that in the past too
07:08 <@anarcat> i see
07:08 <@mig5> it *was* at some point
07:08 <@anarcat> it'd be nice that node/267 be reported as a real bug...
07:08 <@mig5> but i decided, if we are letting people check a box granting access to that user, then maybe it should just work as expected
07:08 <@anarcat> too bad ppl report issues on community.a.o
07:08 <@anarcat> agreed
07:08 <@mig5> if it bypasses the checks, it should probably not even be a checklist option, 
07:08 <@mig5> so i just fixed it the other way
07:08  * anarcat nods
07:08 <@anarcat> ok
07:09 <@mig5> yes unconed, He supplied me with a patch that seems to fix clusters! but concerned that I still couldn't reproduce the infinite loop.
07:09 <@mig5> xk has similar issues, so I put the patch there for review:
07:09 <@anarcat> cool
07:09 <@mig5> and finally that Aliases thing
07:09 <@mig5> (phew! yes i did take notes in preparation for this scrum :)
07:09 <@mig5> that's me done
07:09 <@anarcat> man you're awesome
07:09 <@anarcat> do you plan to be as awesome next week? ;)
07:10 <@mig5> i can try, but i might balance it out by throwing in some migressions
07:10 <@mig5> :)
07:10 < eft_> my efforts are barely worth mentioning
07:10 < eft_> I didn't mention last week that I contributed a small wiki : using drush_make to optimize workflow
07:11 <@mig5> eft_: yes, nice article!
07:11 <@anarcat> mig5: excellent :)
07:11 <@anarcat> okay, anyone else has anything to add?
07:11 <@anarcat> anybody scared of an RC?
07:11 <+omega8cc> This week (well, in the last minute) I rewrote and finally submitted for review two commits: one to add Nginx related how-to in the docs/INSTALL.txt - and second (too big probably, sorry!) with many improvements for Nginx configuration templates: I promise to submit future changes in the small incremental chunks instead of one big update. Next week I plan to submit even more Nginx related improv
07:11 <+omega8cc> and will debug mysterious issue - Aegir fails to rewrite paths in the "files" table on second and next site rename tasks, it works only on the first rename and I reproduced it on more than 5 imported sites, so something for sure interesting to debug and submit a patch (I hope). Also, I plan to finally work on some multiserver deployments and hope to help to find a fix for Drush 4.1 - That is it from me.
07:12 <@anarcat> omega8cc: your first line was stripped
07:12 <@anarcat> at Nginx related improv
07:12 <@mig5> nice, yes i freaked out the other day not knowing how to set up aegir with just nginx :) so those docs would be great
07:12 <@anarcat> thanks omega8cc ! :)
07:13 <@anarcat> your work is really appreciated, i wonder if we shouldn't just commit the huge patch with the hope that next ones will be incremental :)
07:13 <@anarcat> esp. considering you also use git, you should really "commit often" :)
07:13 <@anarcat> okay, anybody else?
07:13 <@mig5> anRC would be great - either way, yes definitely a new release, there are some annoying and critical bugs in beta2 (the data loss multiserver one for one)
07:13 < eft_> any word from devseed on moving c.a.o. ?
07:13 <@mig5> oh yes. or a.o
07:14 <@mig5> does anyone want to work on a drupalised version of a.o? and maybe give it to anarcat to host (or i can host it)
07:14 <@mig5> i can't theme for shit, so I'm out :)
07:14 < eft_> how much is there?
07:14 <@anarcat> mig5: i don't think we should drupalize a.o, actually
07:14 <@mig5> ah, cool that's fine with me
07:14 <@anarcat> just leave it like this, but remove the time-changing stuff
07:14 <@anarcat> and yeah we can host it
07:14 <@mig5> i remember adrian mentioning it
07:15 <@anarcat> oh, the DNS transfer of a.o and .com is stuck
07:15 <@mig5> everyone is annoyed at the g.d.o link, so if we could change that at least
07:15 <@mig5> ah
07:15 <@anarcat> email problems between gandi and devseed
07:15 <@anarcat> yeah
07:15 <@anarcat> but they wanted to transfer ownership of the domains too
07:15 <@anarcat> and i started the xfer
07:15 <@mig5> oh i see
07:16 <@anarcat> but anyways, yeah, transfer the NS and we'll go ahead from there
07:16 <@anarcat> okay, that's it for the scrum folks, thanks for attendign!
07:16  * anarcat heading for a sandwich
07:16 <@mig5> cheers
07:16 < eft_> later

Weekly Scrum IRC Log: 2011-02-03

06:59 <@anarcat> scrum time!
06:59 <@anarcat> mig5: you there?
06:59 <@mig5> yep
06:59 <@anarcat> omega8cc / ergonlogic / others... scrum starts now
06:59 <@anarcat> mig5: you wanna start?
06:59 <@anarcat> need to remove my skis
07:00 <@mig5> ok
07:00 <@mig5> i haven't done much, i still would like testers of
07:00 <@mig5> but it sounds like we have two different issues there
07:00 <@mig5> and that i misunderstood the first issue
07:01 <@mig5> drush 4 remains unusable at least for multiserver, i had some difficulty convincing the drush guys that it was their problem
07:01 <@anarcat> i wanted to test that and for ya before the RC
07:01 <@mig5> yes it's that cluster thing and the aliases that would be nice to get in before the RC
07:01 <@mig5> oh
07:02 <@mig5> and the package indexes
07:02 <@mig5> which i confirmed did seem to speed things up even on my tiny system
07:02 <@mig5> so do go ahead and merge that
07:02 <@mig5> that's all from me I think :s
07:02 <@anarcat> okay
07:02 <@anarcat> i can take a look at the drush 4 issue
07:03 <@anarcat> they are correct that the API is not supposed to change in dr4
07:03 <@anarcat> so if it's a dr bug, we'll have to wait until dr5 for a fix
07:03 <@mig5> yeah, on the other hand, they have completely reversed the logic
07:03 <@mig5> mmm.
07:03 <@anarcat> which is fine because dr5 is coming soon
07:03 <@mig5> o rly. fair enough!
07:03 <@anarcat> i'll weigh in on that one and we'll see
07:03 <@anarcat> on my side
07:03 <@anarcat> i haven't done much. :)
07:03 <@anarcat> still swamped with internal work here
07:04 <@anarcat> i wanted to do an RC, but failed to find time, i have scheduled time to review patches and do the RC on monday
07:04 <@mig5> oh nice, thanks
07:04 <@anarcat> maybe we should stick with 3.3 for aegir 4
07:04 <@anarcat> if you want to take care of the release before that, that's fine with me too though :)
07:04 <@anarcat> otherwise well i opened a few crazy issues
07:05 <@mig5> oh i need to try and reproduce omega8cc's report here: . not sure that's drush 4's fault, unless we know it works fine on 
              3.3 too
07:05 <@anarcat> most notably the exportable backup and wordpress support craziness
07:05 <@mig5> haha
07:06 <@anarcat> also, we have migrated to koumbit's DNS servers so i can do DNS changes if people need that to happen from now on
07:06 <@anarcat> is up
07:06 <@anarcat> and has been fixed
07:06 <@mig5> awesome stuff
07:07 <@anarcat> i think this is it for me too, i'm getting more and more towards freeing up my time to work on aegir, and we are aiming to work on our internal roadmap
                 'real soon' here at koumbit
07:07 <@anarcat> anybody else wants to cue in?
07:08 <@anarcat> anybody else is awake? :)
07:09 <@anarcat> so i guess this just makes for a short scrum! :)
07:09 <@mig5> no problem - i can go back to bed :)
07:10 < kvanderw> anarcat: what is a scrum? and could dummies help?
07:10 <@anarcat> thank you all
07:11 <@anarcat> kvanderw:

Weekly Scrum IRC Log: 2011-02-10

07:00 <@anarcat> aaaalright
07:00 <@anarcat> hellow everybodyyy!
07:00 <@anarcat> welcome to our weekly scrums
07:00 <@anarcat> (we need a bot for that cheering crap - anyways)
07:00 <@anarcat> i
07:00 <@anarcat> have done nothing again. :P
07:00 <@anarcat> actually, that's not true
07:00 <@anarcat> i have done a good review of the queue
07:00 <@anarcat> to try to prepare for the RC
07:01 <@anarcat> committed a bunch of things lying around
07:01 <@mig5> you've done great
07:01 <@anarcat> and then univate decided to submit a bunch of patches on top of that, so i'll have to start all over again
07:01 <@anarcat> univate: thanks ;)
07:01 <@anarcat> yeah, it's been good
07:01 <@anarcat> i still have to review my own internal aegir shit before we go towards a release
07:01 <@anarcat> we have around 200+ issues in our internal queue, it's a mess
07:02 <@anarcat> we had a marketing meeting today where we determined our priorities, but i am not sure i should talk about that now ;)
07:02 <@mig5> :)
07:02 <@anarcat> expect another announce soon
07:02 <@anarcat> we are in talks with devseed to migrate the OA site (community.a.o) to Koumbit (? or mig5 ?) THIS MONDAY!
07:03 <@anarcat> so consider this the first announcement:
07:03 <@anarcat> ON MONDAY, 16H EST, the community site will go down for a migration
07:03 <@anarcat> (that's about the same time as now +1h)
07:03 <@anarcat> i still hope that we can RC next week, which will mean creating the 0.4.x branch
07:04 <@anarcat> but before that, i want to do some tests on my side and review our queue
07:04 <@anarcat> we had a weird issue with cron not running on a site here, that i have trouble making a diagnostic of
07:04 <@anarcat> with that
07:04 <@anarcat> i think i am done, mig5 ?
07:04 <@mig5> ok
07:04 <@mig5> not much to report, other than i think the only real blocker to getting an rc out, is that the upgrade path is broken
07:05 <@mig5>
07:05 <@anarcat> i was scared to read that issue
07:05 <@mig5> i really need to speak to unconed about this since it's his patch, 
07:05 <@mig5> and only he understands it, it's like talking to another Vertice :)
07:06 <@anarcat> good good :)
07:06 <@mig5> that's really all from me :s
07:06 <@anarcat> plans for next week?
07:06 <@mig5> to try and fix that, I suppose
07:06 <@anarcat> cool
07:07 <@anarcat> (as an aside, we just found this code in /var/aegir/fuck.php on our prod server, before destroying it, i pastebin'd it in the idea it might be useful for others:
07:07 <@anarcat> (i am not sure what it does)
07:07 <@mig5> wtf
07:07 <@anarcat> okay, anyone else?
07:07 <+omega8cc> Last week I worked on some new features in the Nginx for Aegir configuration, like improved caching and performance (patches to be submitted), and tested everything with Drush 4 and 5 (head)
07:07 <+omega8cc> Now still working on issues like, and hope to fix more Drush related issues next week to get Aegir Drush 4 compatible. That is it from me :)
07:08 <@anarcat> adrinux / darthsteven / EclipseGc / ergonlogic / grugnog_ / mvc / sfyn / skwashd / univate : you're all aegir contributors and welcome to say hi during this scrum - what you're working on these days... etc
07:08 <@anarcat> thanks omega8cc !
07:08 <+darthsteven> Sure...
07:08 <@mig5> oh yeas darthsteven wrote some killer docs :)
07:08 <+darthsteven> I added the first part if some docs about context
07:09 <+darthsteven> More to follow, and extra docs about services too
07:09 <+EclipseGc> anarcat: oh awesome
07:09 <+darthsteven> That's it from me
07:09 <@anarcat> thanks darthsteven
07:10 <+EclipseGc> all of my time these days has been devoted to non-aegir-specific Drupal 7 work these days, though I do see a number of potential point of collaboration on various items in D7 for whenever aegir decides to make that jump
07:10 <@anarcat> EclipseGc: have you done d6 to d7 porting work?
07:10 <@anarcat> would you be interested in contributing to that?
07:11 <+EclipseGc> anarcat: I've worked on ctools/page_manager porting to D7 yes, as well as my own context_admin
07:11 <@anarcat> how's that going? :)
07:12 <+EclipseGc> anarcat: very good all things considered, native support for all entity types in page_manager is a pretty freaking awesome thing
07:12 <@anarcat> :)
07:12 <@anarcat> alright
07:12 <@anarcat> thank you EclipseGc
07:12 <@anarcat> anyone else has anything to add to this mighty scrum?
07:13 <+EclipseGc> anarcat: from an aegir perspective, (as an example) if say, "site nodes" became "site entities" in the D7 version, we could still utilize panels to display the site information (not that we're doing that now, but it is a possibility)
07:13 <@anarcat> oh, an idea i had: we should have a "wildcard domains" variable in the frontend for wildcards pointing to the aegir server while we fix DNS, then when people create sites, they can just type the left part of the domain and choose the wildcard from a dropdown
07:13 <@anarcat> EclipseGc: right, ok
07:13 <@anarcat> EclipseGc: should we wait for d7 before creating the "dns zone" content-type for example?
07:13 <@anarcat> how easy is it to declare entities programmatically?
07:14 <@anarcat> anyways, i have to head out now, so thanks everyone for attending, and have a nice day
07:14 <+EclipseGc> anarcat: well, the only way to declare an entity is programatically, there's no... entity ui or anything that allows you to build new entities
07:14 <@anarcat> can anyone take care of uploading this to the community site?
07:14 <@anarcat> EclipseGc: ok
07:14 <+EclipseGc> anarcat: thus far, a new entity, front to back all manual is minimum about 400 lines of code if you want it to be fairly usable
07:15 <@mig5> yeah i'll sort it later
07:15 <@anarcat> EclipseGc: ow?
07:15 <+EclipseGc> anarcat: I'm hoping that fago's entity_api and ctools can have a meeting of the minds and do something really great to make all of that (including user interfaces) much easier
07:16 <+EclipseGc> but that is still non-existent yet, and many people are uncomfortable depending on entity_api at the moment (though I hear it cuts down on the necessary code for an entity significantly)
07:16 <@anarcat> aand how easy is it to port existing content types to that ... stuff?
07:16 <+EclipseGc> anarcat: I'm going to change your vocabulary real quick (if you don't mind) just so there's no confusion
07:17 <@anarcat> i really have to head out, but feel free, i'll read on later tonight
07:17 <@anarcat> ciao everyone
07:17 <+EclipseGc> anarcat: "content types" or what we call node types in D6 and below are actually "bundles" (generic term) of the node entity now.  You can still call them whatever you like, but to be precise I usually say "node bundles".  All entity types can have bundles
07:18 <@anarcat> fuck
07:18 <@anarcat> sorry, screwed up there
07:18 <@anarcat> EclipseGc: got it :)
07:18 <@anarcat> ciao for real
07:18 <+omega8cc> cia
07:18 <+omega8cc> o
07:18 <+omega8cc> :)

Weekly Scrum IRC Log: 2011-02-17

07:00 <@anarcat> so welcome to our weekly scrum
07:01 -!- JoshBenner_ [] has joined #aegir
07:01 <@anarcat> so to start with - i had a major fuckup with the community site with a verify that went bad
07:01 <@anarcat> because the alias didn't have the profile set in
07:01 <@anarcat> i documented all this in here
07:01 <@mig5> reading that now. why did oyu need to manually run provision-deploy rather than standard migrate?
07:02 <@anarcat> mig5: because the site wasn't in aegir at first
07:02 <@mig5> gotcha
07:02 <@anarcat> i was importing from devseed
07:02 <@mig5> oh ofcourse *slaps forehead*
07:02 <@anarcat> maybe i should clarify that.. but anyways
07:02 <@mig5> no i'm just a dick and just woke up :)
07:02 <@anarcat> other than that, this week i have struggled with the issue queue
07:02 <@mig5> +1...
07:03 <@anarcat> specificall with that eugene guy which apparently decided we were evil and decided to develop his own stuff privately and stop collaborating on the queue
07:03 <@anarcat> i wrote a response in the issue queue, but i wanted to share here that it pissed me off real bad to hear somebody just go away like this because we're not being nice enough
07:03 <@anarcat> when he's treating us with abuse and duplicate issues
07:04 <@anarcat> hopefully he will not come back to the queue but share his work with others so that we don't reinvent the wheel
07:04 <@anarcat> one of those duplicate issues is this:
07:05 <@mig5> his hosting_folders feature was just wrong anyway
07:05 <@anarcat> apparently eugene had a contrib module to fix this, but because i marked his issue as duplicate of mine, he got angry and removed his code from github
07:05 <@anarcat> but anyways, we talked about this vhost customization thing, and people were suggesting that it should be in contrib, but i feel like i disagree - if it's safe, it could be in core couldn't it?
07:05 <@mig5> the subfolder stuff?
07:06 <@anarcat> no no
07:06 <@anarcat>
07:06 <@anarcat> the custom vhost stuff
07:06 <@mig5> ah
07:06 <+omega8cc> in core, imo
07:06 <@anarcat> right
07:06 < eft_> anarcat: that's moving vhost config  into front end?
07:07 -!- Artusamak is now known as Artusamak_afk
07:07 <@anarcat> so anyways, that's about it for me - i'll try to work more on the issue queue and make an RC during next week unless there are objections here
07:07 <@anarcat> eft_: no
07:07 <@anarcat> mig5: next!
07:07 < eft_> anarcat: that's great that you migrated c.a.o. - do we still need the 1700 EST downtime in the header of this channel
07:07 <@anarcat> eft_: no
07:07 -!- anarcat changed the topic of #aegir to: Aegir hosting system 0.4-beta2 released! | Issue queue: | read this before asking: | scrums on thursdays 2000UTC
07:08 <@mig5> i've done nothing all week due to some hectic work and basically some of our users killing my love for the project.
07:08 <@mig5> i fixed a minor bug here or there
07:08 <@mig5> and will likewise attack the queue some more, i think we should rc soonor we'll just be forever trying to battle that
07:08 <@anarcat> yeah
07:08 <@anarcat> agreed
07:09 <@mig5> that's it from me
07:09 <@anarcat> seems like the only blocker is the ssl rollback, which we could roll into another rc
07:09  * eft_ wishes he had more to offer than nitpicks about channel headers
07:09 -!- Artusamak_afk is now known as Artusamak
07:09 <@anarcat> let's just RC the fucking thing
07:09 <@anarcat> mig5: if you feel like it - just do it, and ignore the issue queue ;)
07:09 < eft_> mig5: any progress on your workflow diags?
07:09 <@anarcat> eft_: you can fight with trolls in the issue queue and get them off our backs :)
07:09 <+omega8cc> go with RC - to avoid "one more thing" syndrome == release 3 years later ;)
07:09 <@anarcat> there's a lot of triage work that is needed in the queue, that mostly anyone could do
07:09 <@mig5> eft_: that was just for a client proposal, it wasn't very good,
07:10 <@anarcat> mig5: anything else?
07:10 <@mig5> anarcat: nope, that's it, i might release today then if i get time
07:10 < eft_> anarcat: bon cop, bad cop
07:10 <@anarcat> eft_: ouaip :)
07:10 <@anarcat> Vertice / adrinux / darthsteven / grugnog / mvc / omega8cc / sfyn / ergonlogic / univate_: anybody else got something to add to our scrum?
07:10 <@anarcat> mig5: that would be just amazing :)
07:10 <+omega8cc> not much from me this week, I only made barracuda/octopus compatible with Debian 6 and Ubuntu 10.10 plus some new fixes for Nginx config
07:11 <@anarcat> okay, anyone else?
07:11 <+ergonlogic> nothing from me
07:11 <+omega8cc> hope to work on contrib module for solr cores automatic setup - integrated with skwashd work
07:11 <@anarcat> univate_: thanks for those patches, btw, keep em coming!
07:11 <@anarcat> omega8cc: that would be freakin awesome!
07:12 <@anarcat> omega8cc: we got config for secure multi-core setups if you're interested... in our wiki
07:12 <+omega8cc> yep
07:12 <@mig5> anarcat: would love a review of
07:12 <@mig5> (re:univate)
07:12 <@anarcat> mig5: got it, maybe tomorrow
07:12 <@anarcat> mig5: but don't wait for this to rc
07:12 <@mig5> ok
07:12 <+omega8cc> anarcat: I will check that, thanks!
07:12 <@anarcat> okay, anyone else?
07:13 <+ergonlogic> now that is hosted at Koumbit, I could help if there's any issues with the site itself
07:13 <+ergonlogic> just let me know
07:13 <@mig5> eft_: wanted thesession_timeout something or other to be raised
07:13 <@mig5> so that it remembers you're loged in
07:13 <@mig5> logged* bah.
07:13 <@anarcat> ergonlogic: yeah, i think mig5 had issues with some images you could help with
07:13 <@anarcat> mig5: ^?
07:14 <@mig5> which images?
07:14 <@anarcat> mig5: i don't recall
07:14 <@anarcat> istr there was some thumbnail problem... wasn't there?
07:14 <@mig5> oh yes
07:14 < eft_> yea
07:14 <@mig5> possibly an atrium bug or something weird
07:14 <@anarcat> yeah
07:14 <@mig5>
07:14 <@anarcat> well now we have root, so let us know what we need to do :)
07:14 <@mig5> the href to that is the full size image, but it *always* loads the thumbnail
07:14 <@anarcat> ergonlogic can take care of it or i can help
07:14 <+ergonlogic> ok, I'll take a look
07:15 <@anarcat> okay, i gotta go
07:15 <@anarcat> and the scrum is over, thanks for attending, people!
07:15 <@anarcat> and have a nice day
07:15 <@mig5> cheers
07:15 <+ergonlogic> thanks all
07:15 < eft_> ciao
07:15 <+omega8cc> ciao

Weekly Scrum IRC Log: 2011-02-23

17:00:00  * anarcat **** WEEEKLY SCRUM TIME!!! ****
17:00:07 <@anarcat> alright, welcome everybody
17:00:16 <jcapelo> ok thx
17:00:34 <@anarcat> darthsteven: sfyn EclipseGc Vertice : our weekly scrum has started!
17:00:40 <@anarcat> it seems that our new developer didn't make it
17:00:44 <@mig5> bugger
17:00:45 <+EclipseGc> :-(
17:00:50 <@anarcat> or is stuck behind the netsplit...
17:01:03 <@mig5> oh true, he was here before
17:01:13 <@anarcat> anyways, let's start
17:01:22 <@anarcat> so i have worked on upgrading our server to rc1
17:01:25 <@anarcat> our prod server
17:01:32 <@anarcat> and people are yelling at me because everything is slower
17:01:38 <@anarcat> so i wanted to yell back at univate ;)
17:01:41 <@anarcat> but he's not here :)
17:01:47 <@anarcat> so i'll just yell in the void
17:01:50 <@anarcat> which is better
17:01:53 <@mig5> have you tried his patch
17:01:57 <@anarcat> anyways i'll test the patches he sent to see if that fixes it
17:02:04 <@anarcat> but in the meantime i had a more urgent matter to attend to
17:02:10 <@mig5> i find it odd it only affects upgrades (fresh installs are quire fast for me)
17:02:19 <@anarcat> the UPPGRADE PATH (wooooo...)
17:02:20 <@anarcat>
<@anarcat> mig5: it is quite odd
17:02:59 <@anarcat> mig5: maybe it's because upgrades have all modules installed and certain tasks (e.g. migrate) take more time to build their forms
17:03:07 <@mig5> ah!
17:03:17 <@mig5> thanks. that  was annoyingly confusing
17:03:26 <@anarcat> what was?
17:03:33 <@mig5> not understanding why
17:03:35 <@mig5> and now i do :)
17:03:37 <@anarcat> anyways, i do think it's the wrong approach to build all forms now, it's slow
17:03:41 ::: mattmcmanus [~mattmcman@] has quit [Quit: That's it! I QUIT! I can't take it anymore!]
17:03:47 <@mig5> yep. we copy temp tables  etc there for migrate
17:03:50 <@anarcat> so maybe we should have a metadata field instead
17:03:52 <@anarcat> yeah, fuck it
17:04:05 <@anarcat> so we'll use the cache as a workaround, but send univate back to do his homework there
17:04:11 <@mig5> agreed
17:04:15 <@anarcat> alright\
17:04:30 <@anarcat> regarding the upgrade path, i think we agreed me and mig5 that he would do some regression testing on master, is that right?
17:04:41 <@mig5> sure thing
17:04:56 <@anarcat> there are two commits (one in hostmaster, one in provision) that are only in head and need to be merged in 0.4 once they are tested without regression and fixing the upgrade path from 0.3
17:05:23 <@anarcat> the one in provision needs to be actually reverted in master when the merge occurs too, because it's a 0.4-specific upgrade path that we can drop from master
17:05:24 <@mig5> ok
17:05:49 <@anarcat> i'll try to work full day on aegir tomorrow to try to settle some issues here
17:06:17 <@anarcat> i think that's all for me, i'm happy to see a new dev join the project, and i hope we can welcome more!
17:06:33 <@mig5> anarcat++
17:06:55 <@mig5> ok, as for me, i've done nothing as usual unfortunately
17:07:04 <@anarcat> as usual, i do not believe you :P
17:07:10 <@mig5> no, this time i haven't
17:07:14 <@mig5> i've been scared of the queue
17:07:17 <@anarcat> so what haven't you done
17:07:37 <@mig5> i'll test the upgrade path, i haven't even really looked at the issue queue since Eugen has discovered it :)
17:07:55  * EclipseGc just sliced his finger open on a grape juice package...
17:07:56 <@anarcat> istr that you actually answered a few things in the queue and here
17:08:08 <talengix> i have finally sucessfully installed aegir and i get Aegir is now installed. You can visit it at <talengix> but the page is blank. i have restarted httpd and I have ensured  localhost $AEGIR_HOST $AEGIR_DOMAIN are in my host file. what else could it be?
17:08:10 <@anarcat> EclipseGc: bleeding edge! ;)
17:08:15 <+EclipseGc> seriously
17:08:24 <@anarcat> alright
17:08:33 <@anarcat> anyone else has anything to add to our weekly scrum?
17:08:33 <@mig5> anyone else?
17:08:35 <@mig5> snap
17:08:36 <+EclipseGc> so, I set up a new rc1 for myself
17:08:37 <@anarcat> hehe
17:08:59 <+EclipseGc> trying to put together a hosted system for my own dev outside of the MAMP package
17:09:08 <+EclipseGc> so, first ++ really easy to install these days
17:09:26 <+EclipseGc> second, trying to hunt down why an install profile that works in MAMP won't install for aegir
17:09:57 <@anarcat> awesome
17:09:58 <+EclipseGc> kind of lost, but... I do have some clues, will need to follow up with people more knowledgeable than myself probably to get anywhere, but still... that's what I did
17:10:02 <@anarcat> ok
17:10:10 <@anarcat> are you still interested in the d7 port?
17:10:42 <+EclipseGc> I AM interested, I'm unsure of what I will have time for beyond advising
17:10:47 <@anarcat> i see
17:10:49 <@anarcat> ah mig5, regarding this: - i think we'll have to live with some vagueness in the documentation, people will need to figure it out themselves, can't them?
17:11:01 <+EclipseGc> anarcat: sort of interested in trying to get ctools to a point to make that sort of dev easier for everyone
17:11:27 <@anarcat> mig5: if we have a thing that says something like "VERSION is the version you are trying to install, it's usually found on the frontpage of" and use VERSION or OLD_VERSION everywhere in the
17:11:44 <@anarcat> EclipseGc: yeah, i was kind of scared of your ctools/features/hostmaster profile reshuffling there :)
17:11:50 <@mig5> anarcat: they ought to be able to, but sometimes it seems there's only maybe 10% of our users who have ever used linux before :) aegir is an 'attractive toy' it seems..
17:11:58 <@anarcat> EclipseGc: you should setup a sandbox for that on when we migrate, so people can test it out
17:11:59 <@mig5> i am not that worried, i just want all of us to be aware of those issues
17:12:06 <@anarcat> mig5: awesome
17:12:07 ::: omega8cc [~omega8cc@] has joined #aegir
17:12:07 ::: basic[] has joined #aegir&#10;17:12:07 ::: CitizenKane [] has joined #aegir&#10;17:12:08 ::: mvc [] has joined #aegir&#10;17:12:08 ::: skwashd [~skwashd@phpgroupware/skwashd] has joined #aegir&#10;17:12:08 ::: kvanderw [] has joined #aegir&#10;17:12:08 ::: gusaus [] has joined #aegir&#10;17:12:08 ::: NeoID_ [] has joined #aegir&#10;17:12:08 ::: TrevorT [~paulius.p@] has joined #aegir&#10;17:12:08 ::: SeanBannister [] has joined #aegir&#10;17:12:08 ::: josh_k [] has joined #aegir&#10;17:12:08 ::: bertodsera [~quassel@] has joined #aegir&#10;17:12:08 ::: j0nathan [] has joined #aegir&#10;17:12:08 ::: Chipie [] has joined #aegir&#10;17:12:08 ::: mthart [] has joined #aegir&#10;17:12:08 ::: joestewart|afk [~joestewar@] has joined #aegir&#10;17:12:08 ::: Zelfje [] has joined #aegir&#10;17:12:08 ::: Letharion [] has joined #aegir&#10;17:12:08 ::: univate [] has joined #aegir&#10;17:12:08 ::: ServerMode/#aegir [+vvvo omega8cc mvc skwashd univate] by;17:12:08 ::: scyrma [] has joined #aegir&#10;17:12:11 &lt;@anarcat&gt; frak&#10;17:12:15 &lt;@anarcat&gt; okay&#10;17:12:16 ::: basic [] has quit [Changing host]
17:12:16 ::: basic` [~basic@osuosl/staff/basic] has joined #aegir
17:12:18 ::: AquaticDisorder [] has quit [Ping timeout: 248 seconds]
17:12:18 <@mig5> whoa
17:12:23 <@anarcat> univate: you missed part of the scrum :)
17:12:25 <@anarcat> omega8cc: scrum time!
17:12:32 <@anarcat> mvc / skwashd : scrum time
17:12:51 <+EclipseGc> anarcat: yeah, I literally have 14 patches for ctools that I'm running in production
17:13:09 ::: Irishgringo [] has quit [Ping timeout: 272 seconds]
17:13:12 ::: catatonicrelapse [] has joined #aegir
17:13:13 <@anarcat> summary of the scrum so far: i'm fixing the upgrade path, mig5 is scared of the queue and will do some regrsesion testing, EclipseGc has some patches for hostmaster.profile and is testing installs
17:13:14 <+EclipseGc> anarcat: so there's a lot of work left to do and a lot of signoff from earl left to get, but... I'm pretty confident
17:13:28 <@anarcat> we have this low-hanging fruit for documentors, which is reshuffling the installation manual
17:13:33 <@anarcat>
<@anarcat> if somebody wants to start working on that, that would be awesome
17:13:59 <+EclipseGc> anarcat: also worth mentioning that, for REALLY big aegir installs, D7 hold some interesting search possibilities
17:14:11 <+EclipseGc> i.e. an aegir with lots of sites
17:14:14 <@anarcat> EclipseGc: ... and probably horrible performance issues possibilities ;)
17:14:29 <@anarcat> so anyways
17:14:30 <+EclipseGc> anarcat: well, not from search
17:14:34 <+EclipseGc> but D7 maybe yes...
17:14:36 <@anarcat> EclipseGc: right
17:14:45 <@anarcat> i think that's it for our scrum, which was a bit disturbed by our netsplit
17:14:59 <@anarcat> if people have things to add to the scrum, freel free to add that now
17:15:02  * EclipseGc shakes fist @ netsplit
17:15:06 <@anarcat> i don't have to run anywhere this time :)
17:16:33 <@anarcat> univate: we really need to rework that patch of yours for the VBO stuff, it's a release critical
17:19:31 <@anarcat> now for something completely different
17:20:11 <@anarcat>
::: scientist_ [~scientist@] has joined #aegir
17:21:03 <+EclipseGc> anarcat: nice
17:21:10 <+EclipseGc> anarcat: definitely awesome
17:21:14 <@anarcat> :)
17:21:22 <@anarcat> i can take care of uploading the log into the community site for once
17:21:28 <@anarcat> unless mig5 has alraedy done it?
17:21:49 ::: Slydder1 [] has quit [Quit: Leaving.]
17:22:44 ::: joestewart [~joestewar@] has joined #aegir
17:22:55 ::: bertodsera_ [~quassel@] has joined #aegir
17:22:55 <+EclipseGc> anarcat:
<@anarcat> uh, and unless that wasn't clear, the scrum is over :)

Weekly Scrum IRC Log: 2011-03-09

09:01 <@anarcat> mig5: hey
09:01 <@mig5> up for scrum or inconvenient time?
09:01 <@anarcat> i can't believe i can't find those revisionsw
09:01 <@anarcat> hey, scrum time, look at that
09:01 <@anarcat> sure
09:01 <@anarcat> at a session here, but it still works :)
09:01 <@mig5> alright, go! :)
09:02 <@mig5> actually
09:02 <@mig5> first, i believe i saw you mention that this scrum time is inconvenient for you 
09:02 <@anarcat> did something fuckup on d.o or something?
09:02 <@mig5> drupalcon aside
09:02 <@mig5> anarcat: you'll have to be more specific about d.o fuckups :)
09:02 <@anarcat> every first wednesday of the month i have a meeting during this scrum
09:02 <@mig5> ah. let's move it then
09:03 <@anarcat> what's convenient for ya?
09:03 <@mig5> the following day, but i think that's when it used to be for you
09:04 <@mig5> and you couldn't do later
09:04 <@anarcat> right
09:04 <@anarcat> that is correct
09:04 <@mig5> so maybe we go earlier in the week
09:04 <@anarcat> yeah, i can do the day before or before before
09:04 <@mig5> let's do day before, so Wednesday for us, unless it's a problem for univate
09:04 <@anarcat> got it
09:04 <@mig5> anyway!
09:04 <@anarcat> tuesday for us
09:04 <@mig5> d.o issues?
09:04 <@anarcat> right
09:05 <@anarcat> so about the upgrade path
09:05 <@anarcat>
09:05 <@mig5> i noticed i committed a change to provision and all my old commits are still unattributed to my user account. yay
09:05 <@anarcat> that comment refers to two patches that are supposedly on head
09:05 <@anarcat> and that i can't find
09:05 <@mig5> hmm
09:05 <@mig5> they're in master aren't they?
09:05 <@anarcat> i can't find them
09:05 <@anarcat> git fetch
09:06 <@anarcat> git show f64487706638
09:06 <@anarcat> fatal: ambiguous argument 'f64487706638': unknown revision or path not in the working tree.
09:06 <@mig5>
09:06 <@mig5>
09:06 <@mig5> are you sure your origin is not ? :)
09:06 <@anarcat> um
09:07 <@anarcat> well
09:07 <@anarcat> those are not the commits i am looking for
09:07 <@mig5> oh
09:07 <@anarcat> that above comment refers to two other commits
09:07 <@mig5> oh oops
09:08 <@mig5> yeah i don't see it
09:08 <@mig5> weird
09:08 <@anarcat> oh well
09:08 <@anarcat> maybe i didn't push them and it works anyways... (?!)
09:08 <@anarcat> anywho
09:08 <@anarcat> so i wanted to merge shit in and release rc2 this week
09:09 <@anarcat> i talked to a bunch of people here at drupalcon about aegir
09:09 <@anarcat> i just did a aegir 101 session to about 20 people
09:09 <@mig5> nice
09:09 <@mig5> how'd that go
09:10 <@anarcat> pretty well
09:10 <@anarcat> people didn't really *want* to install aegir so that part didn't really work
09:10 <@anarcat> but we had good exchanges and dispelled common myths
09:10 <@anarcat> and gave away cool stickers :)
09:10 <@anarcat> we have a roadmap session planned for tomorrow
09:10 <@anarcat> at 2, in missouri again
09:10 <@anarcat> and then we are thinking of having a doc/code sprint on friday
09:11 <@mig5> nice
09:11 <@anarcat> maybe help people out writing drush extensions, and a bunch of other ideas
09:11 <@mig5> we have about 20 'for reviews' in the queues
09:11 <@anarcat> yeah
09:11 <@mig5> mostly eugen :P
09:11 <@anarcat> i'll try to throw people at those
09:11 <@anarcat> we may have new people to get into the project
09:11 <@mig5> excellent
09:11 <@anarcat> i met with shrop, EclipseGc and others
09:11 <@anarcat> what else
09:12 <@anarcat> i want to release rc2 :P
09:12 <@mig5> well - you can, i didn't see any errors doing an upgrade to master from 0.3
09:12 <@anarcat> i was hoping someone could shed light on this - but maybe i'll just do it myself:
09:12 <@mig5> regardless of that missing commit
09:12 <@anarcat> oh, and i have pushed 6.x-1.x as the stable branch
09:12 <@anarcat> for provision
09:13 <@mig5> yeah that sounds expected: drupal keeps those paths in the db, you need to cache clear before it fixes itself up, so your theory is probably right there
09:13 <@mig5> that would happen with or without a Migrate task, basically
09:13 <@mig5> but would be nice for Migrate to fix it
09:13 <@anarcat> and for hostmaster now
09:13 <@anarcat> cool
09:14 <@anarcat> so i'll look at that before the release
09:14 < shrop> anarcat: you have aegir stickers?
09:14 < shrop> that would be cool
09:14 <@anarcat> shrop: yes!
09:14 <@anarcat> of course :)
09:14 < shrop> ok.. want one tomorrow at the meetup if you have any.. :)
09:14 <@anarcat> come to the bof tomorrow :)
09:14 <@anarcat> of course
09:14 < shrop> will do
09:14 <@anarcat> alright
09:14 <@anarcat> so what else for the scrum
09:14 <@anarcat> we did a little spike on the install docs manual for the purpose of the session
09:15 <@anarcat> i'd actually like to get a debian package working for rc2, but i'm not sure i'll have time to do this
09:15 <@anarcat> ideally, we'd get rc2 out during that code sprint
09:15 <@mig5> maybe for 1.0 :)
09:15 <@anarcat> ok, i think that's it for me
09:16 <@anarcat> well, i'd like the package to be tested :)
09:16 <@mig5> i've got nothing to report. univate, you here?
09:16 <@mig5> omega8cc?
09:16 < univate> hey
09:16 < hefring> eh oh
09:17 <@mig5> did you want to add anything to the scrum?
09:17 <@anarcat> mig5: i have merged the two commits you mentionned on the stable branch
09:18 <@mig5> cheers
09:19 <@anarcat> and then some more
09:19 <@mig5> i dont fully understand omega8cc's patches here
09:19 <@mig5> +  $form_state['values']['parameters']['new_uri'] = $url; // force lowercase
09:19 <@mig5> does that variable assignment really force lowercase?
09:20 <@mig5> maybe it's for readability.
09:20 <@mig5> anyway
09:21 <@anarcat> that doesn't force lowercase
09:21 <@anarcat> at all
09:22 <@anarcat> otherwise, i think that's it for our scrum
09:23 <@mig5> yep
09:23 <@mig5> thanks all

Weekly Scrum IRC Log: 2011-03-15

09:01 <@anarcat> alright
09:01 <@anarcat> scrum time
09:01 <@anarcat> mig5 / univate / Vertice / darthsteven / mvc / omega8cc : scrum time
09:01 <+omega8cc> hello!
09:01 < hefring> que tal
09:01 <@mig5> morning
09:01 <+darthsteven> Hello!
09:01 < hefring> hello
09:01 <@anarcat> ghankstef / mrbaileys / sfyn_ / shrop / / others i forgot: welcome to our weekly scrum! feel free to jump in!
09:02 <@anarcat> so welcome everybody
09:02 <@anarcat> we're back from drupalcon! it was an insane week
09:02 <@anarcat> so i'll start with that
09:02 <@anarcat> crazy
09:02 <@anarcat> week
09:02 <+omega8cc> and sk]washd!
09:02 <@anarcat> met a bunch of people
09:02 <@anarcat> oh yeah! skwashd !
09:02 <@anarcat> even though we didn't have a formal aegir session schedule (which is strange considering there were 5 submitted), we did host 2 bofs and a training session, plus a code sprint
09:03 <@anarcat> i met with about 30-40 people to talk about aegir during those session
09:03 <@mig5> someone must've been anti-aegir on the organising committee :)
09:03 <@anarcat> for me the best session was the roadmap session, of which my coworker mvc posted a summary here:
09:03 < skwashd> anarcat, we should've had 34 at the initimate session alone :)
09:03 <@anarcat> mig5: i actually suspect it's because there weren't "big names" submitting a session
09:04 <@anarcat> skwashd: that's right!
09:04 <@mig5> ah ;)
09:04 <@anarcat> and i was late to the intimate aegir session, which sucked, but it was my only "free" day during the whole week
09:04 <@anarcat> koumbit *drove* to chicago, which was insane
09:04 <@anarcat> 1400km one way, so around 3000 km of driving, 30h total...
09:04 <@anarcat> lots of fun and spilled coffee
09:04 <@anarcat> oh and i scratch the fucking car when parking it in a narrow street
09:05 <@anarcat> 4500$CAD in damage, believe it or not
09:05 <@anarcat> lots of fun
09:05 <@anarcat> anyways
09:05 <@mig5> haha
09:05 <@anarcat> so we're passing the hat to pay for the stupid koumbit van ... ;) (kdding)
09:05 <@anarcat> we *almost* got rc2 released
09:05 <@anarcat> i was about to push the tags when they cut off power and wifi in the code sprint
09:05 <@anarcat> but mig5 ended up doing the last mile on that
09:06 <@mig5> sort of
09:06 <@anarcat> i personnally met with shrop, cashwilliams, ghankstef, joestewart, and probably others i forget here :)
09:06 <@anarcat> i feel that our presence there got people interested in participating in the project and i got that objective at least partially accomplished
09:07 <@anarcat> with people comitting to watching and helping in the queues, and i helped people review patches in the code sprint
09:07 <@mig5> it sounded like it had a better bof/community spirit than san francisco
09:07 <@mig5> which is excellent
09:07 <@anarcat> yeah
09:07 <@anarcat> we did more BOFs
09:07 <@anarcat> i think it's better for us to do BOFs than formal sessions - people know of aegir, we need to make it work now :)
09:08 <@anarcat> i closed 10-20 tickets in the issue queue and pissed of eugen again
09:08  * mig5 claps
09:08 <@anarcat> we're down to around 5-10 needs review tickets
09:08 < ghankstef> it works  great  -  except for when it doesn;t  : )  but when it does its really really great
09:08 <@anarcat> this week i am working from home so i am hoping to get more aegir work done than usual
09:08 <@anarcat> but so far i'm failing, mostly because of internal poutine again
09:09 <@mig5> you've got chips and gravy inside you?
09:09 <@mig5> :)
09:09 <@anarcat> i hope to get into it tomorrow and get a solid 3 days
09:09 <@anarcat> haha
09:09 <@anarcat> i mean internal to koumbit :P
09:09 <@mig5> :)
09:09 <@anarcat> and it's french fries and gravy and cheese, for your information :)
09:09 <@anarcat> but enough with quebecois cuisine
09:09 <@anarcat> i think i'm done when i start to talk about poutine :)
09:09 <@anarcat> ah, yeah
09:10 <@anarcat> this week i hope to get working on "i want to run drush on my sites as a regular user"
09:10 <@anarcat> which promises to be a real PITA
09:10 <@anarcat> and also working on the 2.x roadmap, after feedback from the community
09:10 <@anarcat> so that's it for me - next!
09:11 <@mig5> i did nothing except push out rc2, which went horribly wrong, but mostly works
09:11 <@mig5> next! :)
09:11 <@anarcat> haha
09:11 <@anarcat> a bit more on that though - we weren't able to tag hostmaster, because of a bug on d.o
09:11 <@anarcat> we're pushing the limits on git and install profiles on d.o, and that's cool for those people, they like us :)
09:11 <@anarcat> everybody is quite happy and proud that aegir is back on d.o
09:11 <@anarcat> if feels good
09:11 <@anarcat> ah and for everyone that contributed to aegir here:
09:12 <@anarcat> i had a *lot* of thanks and good feedback on the project
09:12 <@anarcat> people *love* aegir
09:12 <@anarcat> they are very grateful and thank me for my involvement
09:12 <@anarcat> so i want to share that with the team here
09:12 <@anarcat> because i couldn't possibly have done this alone, so you all share this credit :)
09:12 <@anarcat> mig5: you really should have been there :)
09:13 <@mig5> i doubt i'll ever make another drupalcon
09:13 <@mig5> the two times of the year are awful for me frankly
09:13 <@mig5> anyways
09:13 <@anarcat> that's too bad
09:13 <@mig5> i'll look at that core dump/segfault issue you're having
09:13 <@mig5> i have never reproduced it
09:13 <@anarcat> you don't *have* to come twice a year :)
09:13 <@mig5> but i feel i understand the *reason* for unconed's patch
09:13 <@anarcat> if you have xdebug enabled, it's not a core dump, it's a loop
09:13 <@mig5> right
09:14 <@mig5> but i've never seen the segfault myself, is what i mean
09:14 <@anarcat> yeah
09:14 <@anarcat> you need to reference a non-existing platform
09:14 <@mig5> unconed explained it was something about the stdin context in drush that caused a loop of loading the @self or @server_msater alias
09:14 <@mig5> ahy
09:14 <@mig5> ah*
09:14 <@mig5> he tried to specifically exclude the @server_master context in his patch, which fixed clusters in this case, but broke install/migrate
09:14 <@mig5> anyway, that's for the tickets, i won't noise up the scrum now
09:15 <@anarcat> alright, anyone else?
09:15 <+omega8cc> I did nothing new "inside" the project last week. There are still some Nginx config improvements waiting for review in the queue, but..
09:15 <+omega8cc> I released Barracuda and Octopus 1.0-boa-T to celebrate Aegir 1.0-rc2, which introduces support for Squeeze and Maverick, with even more speed improvements, so..
09:16 <+omega8cc> I *think* we are already as fast as Mercury (formerly Pantheon) out of the box ;) Seriously, it needs some testing to confirm. That is it from me!
09:16 <@anarcat> alright!
09:16 <@anarcat> people looking for low-hanging fruits!
09:16 <@anarcat> **** THIS IS YOU! ****
09:16 <@anarcat>,+hosting,+hostslave,+eldir,+Hostmaster+(Aegir)&status=8&priorities=All&categories=All
09:16 <@anarcat> this is the "needs review" queue
09:17 <@anarcat> what you need to do in there is to pick an issue in there, try to reproduce the issue described
09:17 <@anarcat> if you can't reproduce, close the issue (can't reproduce)
9:17 <@anarcat> if you can, try to apply the patch to see if it fixes the thing for you, if it does mark it RTBC (ready to be committed), if not, "needs work"
09:17 <@anarcat> there is also work to be done in the documentation
09:18 <@anarcat> we have reworked the manual, actually ergonlogic did
09:18 <@anarcat>
09:19 <@anarcat> followup on documentation is in the "documentation" category in hostmaster
09:19 <@anarcat> see also
09:19 <@anarcat> we specifically need help on the upgrade document
09:19 <@anarcat> and reorganising the "using aegir" section
09:19 <@anarcat> so if nobody has anything else to add
9:19 <@anarcat> i think that's it for our scrum this week
09:20 <@anarcat> thanks for everyone for attending
09:20 < ghankstef> I will have a look at the upgrade doc   see if I can add  to it
09:20 <@anarcat> ghankstef: alright!
09:20 < ghankstef> Will give me a good excuse to update an old aegir  site
09:20 < ghankstef> oh yeah its all empty
09:20 <@anarcat> well
09:21 < ghankstef> guess I can improve on that a bit
09:21 <@anarcat> it's not really empty - i feel ergonlogic forgot to update the status page
09:21 <@anarcat> it seems the UPGRADE.txt was migrated into separate wiki pages
09:21 <@mig5> the sub pages are where it's at
09:21 <@anarcat> maybe it can be merged in one page
09:21 <@mig5> the wrapper page is a bit bare
09:21 <@anarcat> i think we should throw everything in the parent page there
09:22 <+omega8cc> and the structure is too deep now
09:22 <@anarcat> alright
09:22 <@anarcat> that's it for me folks, going back in my "trying to code" hole :)
09:23 <@mig5> thanks all
09:23 <+omega8cc> thanks!

Weekly Scrum IRC Log: 2011-03-29

08:58 <@anarcat> alright, so we're 1 minute away from the scrum, but i'll start anyways :P
08:59 <@anarcat> i'm a bit in a rush since we're going to replace a switch at the datacenter in about an hour
08:59 <@mig5> np
08:59 <@anarcat> which could affect community.a.o momentarily
08:59 <@anarcat> we had a few issues with the server
08:59 <@anarcat> it was replaced with a spare recently and we diagnosed a problem with a corrupted bios
08:59 <@anarcat> our hw provider is running more tests and we hope to get the original server back online shortly
09:00 <@anarcat> as for actual dev
09:00 <@anarcat> i have worked on provisionacl recently and got it in good shape
09:00 <@anarcat> i hope to deploy it in production here this week and get rid of our ugly sudo -u aegir kludges we were giving to workers
09:00 < Aurorus> sounds interesting anarcat
09:00 <@anarcat> so now not only can worker access modules/ files/ etc without problems, but they can run drush commands as their regular user
09:01 <@anarcat> *plus* this gives access to the regular drush aliases
09:01 <@anarcat> although there are still warnings (fixed in drush 5 and drush 4-head)
09:01 <@anarcat> i'm working on having site aliases respect drush -i
09:01 <@anarcat> i have worked a lot on the debian packages too, they are mostly ready
09:02 < Aurorus> anarcat: Are there plans to allow the deletion of sites and platforms that fail verify?
09:02 <@anarcat> provision is packaged, and there's a meta-package for hostmaster that downloads provision
09:02 <@anarcat> i also want to get the debian packages finished this week and we'll update the docs accordingly
09:02 <@anarcat> hopefully we can ship 1.0 with debian
09:02 <@anarcat> i started coordination of the rc3 release, but we have a significant blocker with d.o that refuses to release hostmaster
09:03 <@anarcat> see
09:03 <@anarcat> for the drush issues: and
09:04 <@anarcat> i am going to work more on security in the coming weeks, i plan to work two weeks in a retreat in the woods with internet access :)
09:04 <@anarcat> i will make sure we don't bootstrap evil modules so that allowing access to modules and themes is secure
09:04 <@anarcat> i'd like to release rc3 tomorrow
09:05 <@anarcat> i am thinking of starting work on the d7 port and ldap integration for 2.x during the next two weeks
09:05 <@anarcat> and koumbit has done its internal roadmap and we'll be working hard on 2.x for the summer
09:05 <@anarcat> i think that's pretty much it for me!
09:05 <@mig5> nice one. you have given yourself a lot of work as usual :)
09:05 <@anarcat> i am glad to see that crazy stuff darthsteven has been doing here :)
09:05 <@anarcat> i think it should be merged in
09:06 <@anarcat> well, if anyone wants to pick up rc3 or similar things, be my guest :)
09:06 <@mig5> i read that: i think the queue thing would be good in aegir, hopefully doesn't have too many dependencies?
09:06 <@anarcat> drush especially needs a lot of love - and we'll need to work with them for aegir 2.0, which i suspect will support only drush 5 or above
09:06 <@anarcat> mig5: seems to be standalone contrib!
09:06 <@mig5> ok cool
09:06 <@anarcat> it's just a ghetto php daemon :)
09:06 <@anarcat> what Vertice didn't want :)
09:06 <@mig5> i thought it deopeneded on some obscure launchd-like OSX daemon
09:07 <@mig5> but i admit i didn't read it thoroughly
09:07 <@anarcat> darthsteven: recommends supervisor, but it's just to keep the php script alive - you could use whatever you want
09:07 <@anarcat> hey, we could even use the cronjob to restart the daemon if it fails
09:07 <@mig5> anyway: not much from me, as usual. i basically encountered some significant stability issues with the master branch, and fixed it as best as I could, though I worry i broke some of your ideas there.
09:08 <@mig5> i found the bug while writing my aegir build test in jenkins, which was exactly what it was designed to do (although it didn't literally fail the test :) )
09:08 <@mig5> and that's the other main thing i've been toying with (jenkins), although it's at an early stage in terms of aegir tests.
09:08 <@anarcat> cool :)
09:08 <@mig5> but i think we could use it more and more
09:08 <@anarcat> that is freakin awesome
09:08 <@anarcat> can you paste urls for that here?
09:08 <@anarcat> i'm really lazy, nevermind :)
09:09 <@mig5> sure
09:09 <@mig5> i'd like to at least give you or other developers access to that properly, so you can run tests
09:09 <@mig5> at my expense :)
09:09 <@mig5> as i figure you might catch migressions, and do me a favour
09:09 <@mig5> :)
09:10 <@anarcat> haha
09:10 <@anarcat> well, in this case the regression was mine wasn't it ;)
09:10 <@mig5> no matter
09:10 <@mig5> one other thing:
09:10 <@mig5> i'm less worried than you re:'s issues in releasing hostmaster
09:10 <@mig5> i think it would be nice
09:10 <@mig5> but it's not a blocker in my opinion
09:10 <@anarcat> ok
09:10 <@mig5> as our design works around it already
09:11 <@anarcat> ... since we depend on git
09:11 <@mig5> yeah
09:11 <@anarcat> ok
09:11 <@anarcat> but the doesn't know that :p
09:11 <@mig5> ah, true :)
09:11 <@anarcat> so i almost released a broken rc3 here :)
09:11 <@mig5> don't worry, i broke rc2
09:11 <@mig5> but i ignored it :)
09:11 <@anarcat> eh
09:11 <@anarcat> ok
09:12 <@anarcat> so if you want to break^Wrelease rc3 tomorrow, or anytime, in fact, be my guest
09:12 <@mig5> don't want to make more work for us in the though. but, i'm afraid i'm still crippled with a 'don't wait for to catch up with us' mentality :)
09:12 <@mig5> ok
09:12 <@anarcat> that's alright
09:13 <@anarcat> alright, anyone else?
09:13 <@mig5> i'll have some time, this time tomorrow
09:13 <@anarcat> omega8cc doesn't seem to be here, so i'll talk for her a little :)
09:13 <@anarcat> she found a vhost injection vulnerability in the alias
09:13 <@mig5> oh yeah
09:13 <@anarcat> it was fixed in head and I *think* i merged in stable
09:13 <@mig5> did the security team say anything?
09:13 <@anarcat> which is why i wanted to make a release
09:13 <@anarcat> yeah
09:13 <@anarcat> no embargo, just release
09:14 <@anarcat> since it's not a stable release, it's ok
09:14 <@mig5> ok
09:14 <@anarcat> so don't tag it as a security release either, because then it gets unpublished and all the shit
09:14 <@mig5> she has some nginx batch updates in the queue as well, since we never really test those ourselves, we should probably just roll them in
09:15 <@mig5> they missed rc2 already
09:15 <@mig5>
09:15 <@anarcat> yup
09:15 <@anarcat> a good review of the needs review patches would be good, but not mandatory
09:15 <@anarcat> too bad we got that silly security issue otherwise that would have been 1.0 :P
09:15 <@mig5> oh well. i admit i didn't read the security vulnerability properly. how was it exploitable?
09:15 <@anarcat> darthsteven: please do submit a patch for that stuff, it seems like gold
09:15 <@mig5> i spose i could find the ticket
09:16 <@anarcat> oh and i think we should fix this too:
09:16 <@anarcat> Files in sites/ are accessible.
09:16 <@mig5> yeah
09:16 <@anarcat> this is the security issue:
09:16 <@anarcat> i thought the private files was already done
09:16 <@mig5> i thought we could stick it in the platform vhost
09:16 <@mig5> the deny all
09:16 <@mig5> his .htaccess is probably being ignored for that reason
09:17 <@mig5> in that we don't have AllowOverride
09:17 <@anarcat> yes, the .htaccess are ignored, on purpose
09:17 <@mig5> yep
09:17 <@anarcat> okay folks, i need to go!
09:17 <@mig5> so i thought we could inject that into the template ourselves
09:17 <@mig5> sound sane?
09:17 <@mig5> ok
09:17 <@anarcat> yep
09:17 <@mig5> have fun with your switch
09:17 <@mig5> cheers
09:17 <@anarcat> hehe i will :)
09:17 <@anarcat> ciao ciao

Weekly Scrum IRC Log: 2011-04-05

(06:02:27 PM) anarcat: mig5 / Vertice / darthsteven / EclipseGc / mvc / omega8cc / sfyn / skwashd / ergonlogic : scrum time!
(06:02:35 PM) EclipseGc: anarcat: yay
(06:02:43 PM) anarcat: joestewart: scrum!
(06:02:48 PM) darthsteven: crouch...touch...engage
(06:02:52 PM) anarcat: shrop / univate : scrum!
(06:02:57 PM) anarcat: alright
(06:03:31 PM) anarcat: so welcome everybody, sorry i'm little late :)
(06:03:35 PM) anarcat: i got tons of stuff :)
(06:03:39 PM) anarcat: first
(06:03:41 PM) anarcat: master is dead
(06:03:52 PM) anarcat: being an anarchist and all, no masters no god and everything ;)
(06:04:00 PM) anarcat: more seriously - we're all on 6.x-1.x now
(06:04:09 PM) anarcat: it was too much of a pain to sync that all the time
(06:04:20 PM) EclipseGc: heh
(06:04:32 PM) darthsteven: anarcat: has the master branch actually been removed now?
(06:04:40 PM) anarcat: darthsteven: yes, it's dead.
(06:04:49 PM) darthsteven: cool
(06:04:51 PM) anarcat: also, i have cleaned up the docs regarding the branch naming conventions here:
(06:04:59 PM) ergonlogic: long live 6.x-1.x!
(06:05:05 PM) anarcat: reviews of that from the docs team would be welcome
(06:05:18 PM) anarcat: speaking of which, we talked about having maintainers for various sections of the project
(06:05:28 PM) anarcat: the first of which is the docs team, spearheaded by darthsteven and ergonlogic
(06:05:40 PM) anarcat: i don't remember the full list of teams, but i'll dig it out later
(06:05:55 PM) anarcat: so congrats to the docs team for the awesome work so far, more on that from darthsteven ltr i guess
(06:06:00 PM) anarcat: i did the roadmap for 2.0
(06:06:07 PM) anarcat:
(06:06:16 PM) anarcat: everyone is strongly encouraged to review and augment
(06:06:21 PM) anarcat: and especially take tasks
(06:06:48 PM) anarcat: koumbit will *not* do everything in there, but we *will* make a 2.0 release to deploy our changes in production, so the stuff that's not being taken care of will be pushed to 3.0
(06:07:12 PM) arianek is now known as arianekPHONE
(06:07:13 PM) anarcat: i would love to get betas for 2.0 released by the end of summer, with rcs in automn (ie. koumbit runnin 2.x in production by the end of the summer)
(06:07:21 PM) anarcat: we release rc3
(06:07:24 PM) anarcat: i want to release rc4
(06:07:26 PM) anarcat: tonight
(06:07:32 PM) EclipseGc: yay
(06:07:32 PM) anarcat: we have a bunch more changes
(06:07:47 PM) anarcat: especially the symlink stuff  (now sites are symlinked into /var/aegir/clients  for easier access)
(06:07:53 PM) anarcat: provisionacl has been updated to fix the perms there too
(06:08:08 PM) anarcat: debian packages have been released and uploaded to
(06:08:11 PM) mig5: whoop, daylight savings screwed me. morning
(06:08:23 PM) EclipseGc: morning mig5
(06:08:26 PM) anarcat: morning mig5 ! :)
(06:08:47 PM) anarcat: there's been a few bugs with the debian packages, mostly with the new installs (because i'm mostly testing upgrades from our existing installs)
(06:08:56 PM) anarcat: upgrades work well, installs need testing but should work now
(06:09:11 PM) anarcat: the docs have been updated so that the manual install doesn't use
(06:09:16 PM) anarcat: which has been removed from the tree
(06:09:23 PM) anarcat: completely
(06:09:33 PM) anarcat: and the manual docs have been updated to use hostmaster-install instead
(06:09:40 PM) anarcat: and favor the debian automatic installs through packages
(06:10:01 PM) anarcat: koumbit will deploy the stable branch in staging tonight or tomorrow and rc4 in prod tomorrow
(06:10:06 PM) anarcat: that's about it for me i think
(06:10:17 PM) anarcat: oh and i'm in a retreat in the woods to code like crazy for a week or two
(06:10:31 PM) omega8cc: haha
(06:10:31 PM) anarcat: i'm trying to work on the d7 port, but if people want to join that effort, that would be welcome
(06:10:43 PM) anarcat: i'll also focus on bootstrap security, as i see fun
(06:10:49 PM) anarcat: prioritisation welcome
(06:10:53 PM) anarcat: ok, next!
(06:10:58 PM) mig5: i've done nothing, i'm sick and also have busted my back. also, i fly to europe end of next week, what great timing
(06:11:06 PM) mig5: so i don't expect you'll get much out of me until end of may now
(06:11:31 PM) mig5: that's it for my pep talk
(06:11:35 PM) anarcat: yay! ;)
(06:11:38 PM) omega8cc: mig5: welcome to eu!
(06:11:41 PM) anarcat: well, rest and get well :)
(06:11:45 PM) mig5: thanks
(06:11:57 PM) EclipseGc: I also have done nothing, but anarcat if you're doing a 7.x upgrade I would love to be available in any capacity that you might find useful. Be that review, or just as someone to bounce ideas at
(06:12:08 PM) anarcat: EclipseGc: gotcha
(06:12:19 PM) anarcat: so let's welcome our new dev here - darthsteven , do you have something to share?
(06:12:33 PM) darthsteven: sure
(06:13:02 PM) darthsteven: So, prompted by ergonlogic's issue, I asked for commit access to aegir to work on the documentation
(06:13:13 PM) mode (+o darthsteven) by anarcat
(06:13:14 PM) darthsteven: and it was granted
(06:13:23 PM) anarcat: great timing :)
(06:13:30 PM) EclipseGc: woot, now he can kick us all
(06:13:36 PM) darthsteven: hurrah!
(06:13:46 PM) darthsteven: (no idea how to though)
(06:13:49 PM) anarcat: congratulations! :)
(06:13:55 PM) darthsteven: so yeah, just been working on some docs
(06:13:57 PM) anarcat: darthsteven: /kick EclipseGc now now
(06:13:58 PM) anarcat: ;)
(06:13:59 PM) omega8cc: darthsteven: congrats!
(06:14:05 PM) EclipseGc: :-(
(06:14:10 PM) omega8cc: lol
(06:14:12 PM) darthsteven: and wrote an article about passing data from the Aegir frontend to the backend
(06:14:12 PM) anarcat: EclipseGc: just kidding :)
(06:14:15 PM) EclipseGc: heh
(06:14:23 PM) ***EclipseGc saw that
(06:14:32 PM) mode (+v shrop) by anarcat
(06:14:45 PM) EclipseGc:
(06:14:58 PM) anarcat: darthsteven: that's nice!
(06:15:04 PM) anarcat: darthsteven: we should copy that into the manual somewhere...
(06:15:14 PM) darthsteven: from our work on the docs so far, I wonder if we wanted to clean up the API before the 1.0 final release?
(06:15:23 PM) darthsteven: it's not hugely consistent
(06:15:27 PM) EclipseGc: heh
(06:15:38 PM) mode (+v ergonlogic) by anarcat
(06:15:42 PM) darthsteven: but that would mean big changes I guess, so 2.0 stuff
(06:15:54 PM) ergonlogic: I've been promoted
(06:15:56 PM) anarcat: darthsteven: i would also think that api changes at this point would be a bit daring
(06:16:14 PM) anarcat: darthsteven: i would rather tag those inconsistencies as issues for 2.x
(06:16:17 PM) darthsteven: sure
(06:16:19 PM) anarcat: darthsteven: but document, document
(06:16:32 PM) anarcat: also, i think we should aim for a short 1.0 release cycle
(06:16:35 PM) darthsteven: so, plans are to add lots more documentation over the next days/weeks
(06:16:41 PM) anarcat: esp. because we're having api issues and so on
(06:16:42 PM) darthsteven: that's it for me
(06:16:46 PM) anarcat: alright
(06:16:57 PM) anarcat: thanks darthsteven and welcome again in the crew
(06:17:07 PM) anarcat: so a parenthesis on the statuses in this channel
(06:17:13 PM) anarcat: +o is for developers
(06:17:37 PM) anarcat: we're all equal there - if you need access to some resource on or, just ask and it will be granted
(06:17:47 PM) anarcat: +v is for (currently) occasional contributors
(06:17:53 PM) anarcat: it's the way to become a dev :)
(06:18:09 PM) anarcat: end of parenthesis
(06:18:19 PM) anarcat: so anyone else has something to add to our (late) scrum?
(06:18:19 PM) anarcat: omega8cc: ?
(06:18:53 PM) omega8cc: nothing from me this week, I'm sick, but hope to add something next week
(06:18:57 PM) anarcat: i can speak quickly for sfyn, who made his first official release of uc_hosting (1.0-beta1), ubercart integration
(06:19:06 PM) anarcat: which we're going to deploy soon
(06:19:18 PM) anarcat: also, we'll need to figure out where the heck univate has gone :)
(06:19:25 PM) anarcat: if anybody saw him, let me know ;)
(06:19:49 PM) ergonlogic: So, for my part, I've actually been pretty busy... 
(06:19:57 PM) ergonlogic: testing some of the aegir contrib modules
(06:20:09 PM) ergonlogic: some functional updates to the community site (spread out over the past few weeks really)... and more to come
(06:20:19 PM) ergonlogic: Some documentation, though I feel I need to better understand how to document hooks properly... 
(06:20:28 PM) ergonlogic: I'll be trying to debug some issues on
(06:20:42 PM) ergonlogic: And I have a new Aegir contrib module ( that denies uid1 to clients creating sites, and assignes them a role of our choosing
(06:20:52 PM) ergonlogic: which I'll release shortly on d.o, I think
(06:21:05 PM) ergonlogic: that's it, I think
(06:21:06 PM) anarcat: for hooks, we need to add sample code for it to make sense, e.g. hook_post_install()
(06:21:26 PM) darthsteven: ergonlogic: Feel free to ask me about documentation!
(06:21:30 PM) EclipseGc: ergonlogic: nice
(06:21:31 PM) anarcat: ah - ergonlogic and darthsteven - do we want to refactor your code straight into 1.0 core? or maybe we should wait for 2.x?
(06:21:33 PM) ergonlogic: I've some experience with a coule now, so I can try to put something together
(06:21:43 PM) ergonlogic: s/coule/could
(06:22:14 PM) darthsteven: anarcat: we're working in a branch of 1.0
anarcat AntiNSA-AFK 
(06:22:32 PM) anarcat: darthsteven: for docs, but i was talking about the scheduling, the dispatcher, and saas stuff
(06:22:46 PM) darthsteven: anarcat: ah okay
(06:22:48 PM) anarcat: darthsteven: i think we can merge that branch in rc4 - it's really all just docs
(06:23:10 PM) anarcat: i also think we can merge documentation into 1.x releases after 1.0
(06:23:23 PM) ergonlogic: I'd be happy for aegir core to appropriate hosting_saas
(06:23:34 PM) anarcat: so anyways, i think that's it for our scrum
(06:23:35 PM) ergonlogic: I think it might mean another promotion ;)
(06:23:44 PM) anarcat: hopefully we'll have rc4 ready tonight or tomorrow
(06:23:48 PM) EclipseGc: yay
(06:23:53 PM) anarcat: and 1.0 ready by next week or something
(06:23:54 PM) EclipseGc: mass migrate will come back :-D
(06:24:00 PM) anarcat: EclipseGc: yeah, i fixed it
(06:24:02 PM) darthsteven: cool
(06:24:04 PM) EclipseGc: anarcat: yeah I saw
(06:24:05 PM) ergonlogic: sounds good
(06:24:10 PM) EclipseGc: anarcat: thx for that :-D
(06:24:27 PM) anarcat: if someone wants to volunteer for the 1.x branch maintenance, i'd be happy to explain how that works and help with the work
(06:24:42 PM) ergonlogic: 
(06:24:45 PM) EclipseGc: lol
(06:24:48 PM) anarcat: ergonlogic: :P
(06:25:02 PM) anarcat: ergonlogic / darthsteven : i think i was too quick about the offer to merge the modules in core - let's do that merge in 2.x instead
(06:25:13 PM) darthsteven: anarcat: agreed
(06:25:29 PM) anarcat: okay, who wants the amazing and wonderful job of uploading the log in the site?
(06:25:31 PM) ergonlogic: k
(06:25:38 PM) ergonlogic: I'll do it
(06:25:47 PM) anarcat: great!
(06:26:04 PM) anarcat: thanks everyone for coming

Weekly Scrum IRC Log: 2011-04-12

23:02 darthsteven: mig5: ping
23:02 darthsteven: anarcat: ping
23:02 darthsteven: Scrum?
23:02 hefring: Every Tuesday at 22h00 UTC: 15h00 San Francisco, USA (PST), 18h00 Montreal, Canada (EDT), 23h00 London, UK (CET), 08h00 (Wednesday) Melbourne, Australia (EST)
23:03 darthsteven: Guess this is going to be a quiet scrum then...
23:03 darthsteven: Well, I'll start
23:04 obicke: go for it
23:04 darthsteven: I've not done a whole lot of extra documentation, just all the constants in hostmaster, and a couple more hooks
23:04 darthsteven: I've been chasing ergonlogic about the api.a.o site not updating, he should be looking at it soon
23:05 darthsteven: hoping to still push some more docs before the 1.0 final release
23:05 darthsteven: that's it from me
23:05 darthsteven: anyone else?
23:06 darthsteven: EclipseGc, ergonlogic, grugnog, mvc, omega8cc, sfyn, shrop, skwashd or anyone else have anything to add?
23:06 obicke: • obicke is trying to round up anarcat and ergonlogic
23:07 EclipseGc: • EclipseGc was not reading
23:07 EclipseGc: • EclipseGc has nothing to add
23:08 shrop: Nothing at this point
23:08 shrop: When is v1 coming out?
23:09 darthsteven: soon
23:10 EclipseGc: • EclipseGc would like to point out his new power-module though
23:11 darthsteven: I'll give this scrum until 22:15UTC
23:14 sethvincent: darthsteven: where are the api docs located?
23:15 darthsteven: sethvincent:
23:15 sethvincent: thanks
23:16 darthsteven: that's the end of the scrum then

Weekly Scrum IRC Log: 2011-04-19

[22:00:51]  <@anarcat>  alright, welcome everybody to our weekly scrum
[22:01:04]  <@anarcat>  i'm your host for this week and we have a wonderful agenda :)
[22:01:09]  <@anarcat>  enough with the bull
[22:01:14]  <@anarcat>  1.0 IS RELEASED!!!!!
[22:01:17]  <@anarcat>  YEEHAAA! :)
[22:01:24]  <@mvc>  :)
[22:01:26]  <@darthsteven>  YEAH!!!
[22:01:26]  <@anarcat>  *AND* we have found our first RC bug!
[22:01:33]  <@anarcat>
[22:01:38]  <@anarcat>  d5 migrations are fucked! :)
[22:01:42]  <@anarcat>  so that's already fixed and great
[22:01:48]  <@anarcat>  and i am thinking of making 1.1 already
[22:02:06]  <@anarcat>  also, we found a low-hanging fruit here to make exportable backups easy:
[22:02:17]  <@anarcat>  and i merged this in by mistake in 1.x, but now i think i won't revert it
[22:02:36]  <@anarcat>
[22:02:43]  <@anarcat>  if anyone opposes, feel free to revert
[22:03:03]  <@anarcat>  it's not an API change, and it's a nice quick fix to have people with SFTP access able to download backups of their sites
[22:03:09]  <@anarcat>  so i think it would be nice to get this in
[22:03:18]  <@anarcat>  koumbit is now running 1.0 in production
[22:03:35]  <@anarcat>  and we're going to test head 1.x tomorrow, and if that works well we'll release 1.1
[22:03:46]  <@anarcat>  what else, what else
[22:04:04]  <@anarcat>  did i mention we have a candidate student for the summer of code?
[22:04:16]  <@anarcat>
[22:04:19]  <@anarcat>  here, i mentionned it
[22:04:24]  * mapleleaf has quit (Quit: ChatZilla [Firefox 3.6.16/20110319135224])
[22:04:24]  <@anarcat>  results should be announced somewhere next week
[22:04:33]  <@anarcat>  his focus would be on the d7 port and maybe dns
[22:04:40]  <@anarcat>  so i decided to hold off on those tasks for now
[22:04:54]  * Chipie has quit (Quit: Leaving.)
[22:04:55]  <@anarcat>  i will however look more at inter site security
[22:04:57]  <@darthsteven>  all very cool
[22:05:02]  * FatGuyLaughing has quit (Quit: FatGuyLaughing)
[22:05:09]  <@anarcat>  and queueing, and i'd like to talk with darthsteven about that, but prolly more next week
[22:05:16]  <@anarcat>  so that's about it for me
[22:05:49]  <@anarcat>  mig5 darthsteven ergonlogic mvc omega8cc sfyn shrop skwashd - something to add to our weekly scrum?
[22:05:55]  <@darthsteven>  yup
[22:06:20]  <@anarcat>  oh, and of course, i forgot: 2.x is opened for dev, and i merged the chained cert support there
[22:06:33]  <@darthsteven>  I've just come from a Drupal Meetup where I saw that drupal 5 migration bug demoed
[22:06:42]  <@darthsteven>  and now I know what caused it
[22:06:44]  <@darthsteven>  :)
[22:06:58]  <@anarcat>  and now you can tell them it's fixed already :)_
[22:07:17]  <@darthsteven>  So I took a look at at patch to add SSL chained certificates to provision
[22:07:32]  <@darthsteven>  It needed a bit of cleanup, but was okay
[22:07:43]  <@anarcat>  i agree, and merged it into 2.x
[22:08:06]  <@darthsteven>  I think I added some docs since the last scrum, and ergonlogic got the api.c.o site working
[22:08:36]  <@darthsteven>  ermm...that's it for me, nothing else Aegir related really
[22:08:45]  <@darthsteven>  hoping to write more docs though...
[22:08:51]  <@darthsteven>  done
[22:08:55]  <@darthsteven>  anyone else?
[22:09:09]  <@anarcat>  cool
[22:09:22]  <@anarcat>  omega8cc: ?
[22:09:35]  <@anarcat>  omega8cc: you mentionned something about tracking 2.x, can you expand on that?
[22:09:36]  <@omega8cc> I released Barracuda/Octopus 1.0-boa-T-8 with Aegir 1.0
[22:10:08]  <@omega8cc> anarcat: just switched to 2.x to continue with patches related to Nginx
[22:10:22]  <@anarcat>  i am, in general, a bit worried that we won't get as much testing on 2.x than we have on 1.x now that 1.x is declared stable, but i'll try to run 2.x on my home server - we were also thinking of running 2.x on a dev server at koumbit, but that has yet to happen
[22:10:26]  <@anarcat>  omega8cc: cool, nice to hear
[22:11:04]  <@omega8cc> anarcat: I will use 2.x in Barracuda head, so people will test it and I hope to get more feedback
[22:11:08]  <@anarcat>  cool
[22:11:31]  <@anarcat>  i was thinking of reworking the platform access control for april, we set that as a target, so maybe that will land in 2.x and maybe get merged in 1.x if it doesn't break any apis
[22:11:41]  <@omega8cc> interesting that 5.x to 6.x to 7.x migrations worked for me
[22:11:48]  <@anarcat>  i am still looking for ways to radically change 2.x so that it's really different from 1.x :P
[22:12:01]  <@omega8cc> but I tested it only on basic core installs
[22:12:07]  <@anarcat>  i see
[22:12:12]  <@anarcat>  nice to hear anyways :)
[22:12:13]  <@ryanarmstrong>    anarcat: cross-site stats :P
[22:12:21]  <@ryanarmstrong>    *goes back into the background*
[22:13:25]  <@anarcat>  oh, darthsteven - this could use some more eyes as it touches on the context/services stuff that you may be familiar with:
[22:13:41]  <@anarcat>  omega8cc: thanks for your feedback
[22:13:44]  <@anarcat>  anyone else?
[22:13:54]  <@anarcat>  ryanarmstrong: you'll have to expand on that after the scrum :)
[22:14:03]  <@ryanarmstrong>    will do, didn't want to derail :)
[22:14:07]  <@omega8cc> we need UI improved in 2.x, I will submit patches soon, and will propose Fetaures integration etc
[22:14:17]  <@anarcat>  omega8cc: great idea!
[22:14:31]  <@anarcat>  omega8cc: one idea about features was to drop our idea of "features" in favor of features.module
[22:14:38]  <@darthsteven>  anarcat: yeah I saw that, and it is on my radar, but I've not used any of the DNS stuff, but could look at the code anyways
[22:14:57]  <@omega8cc> right, and move install profile to profiler
[22:15:06]  <@omega8cc> maybe
[22:15:10]  <@anarcat>  omega8cc: yeah
[22:15:20]  <@anarcat>  omega8cc: ergonlogic was saying it was a good upgrade path to d7
[22:15:33]  <@anarcat>  alright
[22:15:35]  <@omega8cc> anarcat: yes, noticed that
[22:15:47]  <@anarcat>  we're pretty much done here, thanks for attending our scrum session and see you next week!
[22:16:02]  <@darthsteven>  I'm not sure that converting to features features would get us much, as we don't use CCK/fields
[22:16:07]  <@anarcat>  anyone wants to upload this log to the com site?
[22:16:26]  <@darthsteven>  will do
[22:16:28]  <@anarcat>  darthsteven: indeed..
[22:16:31]  <@anarcat>  darthsteven: cool! tx
[22:16:59]  <@anarcat>  darthsteven: as for the dns issue, it's not as much for the DNS but for the part where he changes the way config information is stored in the services objects
[22:17:03]  <@anarcat>  hairy stuff
[22:17:09]  <@anarcat>  alright, scrum end!

Weekly Scrum IRC Log: 2011-04-26

[22:00:05]    <anarcat> hello everyone!
[22:00:09]  <EclipseGc>   'ello
[22:00:10]   <anarcat> welcome to our weeeeekly scrum!
[22:00:27]  <anarcat> tons of great news this week
[22:00:34] <anarcat> sethvincent: scrum time
[22:00:41]  <sethvincent> hello!
[22:00:41]   <hefring> hey
[22:01:05]  <anarcat> so alright, i'll start by welcoming our new google summer of code student that will work on the d7 port and dns frontend
[22:01:12]    <anarcat> sethvincent: congratulations on your admission! :)
[22:01:23]   <sethvincent> thanks! i'm pretty excited about it
[22:01:24] <anarcat> now, for my stuff
[22:01:28]    <EclipseGc>   sethvincent: congrats
[22:01:56]    <anarcat> i worked some time on the drush unit testing stuff and have a patch for drush 5 to refactor the unit testing code so we can test functions directly
[22:02:14]  <anarcat> i will work on unit testing before reshuffling the backend too much, which should make 2.x more robust throughout the refactoring
[22:02:30]    <anarcat> we upgraded everything to 1.1
[22:02:34]    <anarcat> which i released last week
[22:02:46]   <anarcat> and our stable release seems to be well.. pretty stable :)
[22:03:01]   <EclipseGc>   heh
[22:03:02]  <anarcat> sethvincent: i was wondering if we could make an announcement for your project, that would make nice publicity :)
[22:03:14]    <sethvincent> ok. that sounds good.
[22:03:30]    <anarcat> oh, and i met with ubuntu people at the local launch party to get help with the backport of drush in there, should followup shortly
[22:03:33]  <anarcat> that's it for me
[22:03:34]    <shrop>   hey hey
[22:04:20]  <anarcat> oh, next week, i'll work on that announcement, we're deploying provision ACL internally big time here, and i'll work more on the new jenkins server we have (thanks mig5!) and unit testing - that's all
[22:04:25] <anarcat> anyone else?
[22:04:33] <anarcat> sethvincent: maybe you want to introduce yourself a little? :)
[22:04:45]   <sethvincent> sure.
[22:05:19]    <sethvincent> i'll be working on the d7 port and dns.
[22:05:32] <anarcat> alright :)
[22:05:41]   <anarcat> and i'll be your mentor, from what i understand :)
[22:05:44]  <sethvincent> i'm a student at the evergreen state college, where i also work part time as an advisor to the student newspaper there
[22:06:04]  <anarcat> (if anyone else wants to help with that, that would be cool, btw)
[22:06:36]    <shrop>   d7 ports and dns stuff?
[22:06:37]  <EclipseGc>   is the plan to move all our major components to entities?
[22:06:47]    <sethvincent> yeah, i'm excited to hear any advice y'all have on the d7 port and dns
[22:06:52] <anarcat> right
[22:06:55]    <sethvincent> entities does look like the way to go
[22:06:59]    <anarcat> so we alraedy have a few things on the table here
[22:07:10]    <anarcat> univate has a patch to refactor the install profile with profiler and use features more
[22:07:16]  <anarcat> that will certainly facilitate the port
[22:07:30]  <anarcat> that's in
[22:07:45] <anarcat> as for entities, yes, i figured that most of our current content type should probably become entities
[22:08:11]    <anarcat> that, in turn, will facilitate implementation of the DNS frontend, which will be also based on entities
[22:08:21]  <anarcat> and will provide a good use case for creating a new "hosting" content-type
[22:08:36] <anarcat> having documentation on how to actually do that while it's coded would be useful too in the manual
[22:08:52]  <anarcat> i think that's all my brain has to offer now for that :)
[22:09:01]    * FatGuyLaughing has quit (Quit: FatGuyLaughing)
[22:09:08] <anarcat> sethvincent: you should get familiar with git and work on a development branch, at the very least
[22:09:26]    * FatGuyLaughing has joined #aegir
[22:09:34]   <shrop>   anarcat: Will there be a dev branch for d7? sorry if I missed that
[22:09:37]   <anarcat> or maybe work in a sandbox for the time being, not sure it's appropriate to give you full commit access from the start
[22:09:41]  * FatGuyLaughing has quit (Client Quit)
[22:09:42]  <anarcat> shrop: there will certainly be!
[22:09:53]  * realityloop has joined #aegir
[22:09:59]  <shrop>   cool. Just checked and didn't see it yet, but wanted to be sure.
[22:10:04]    <sethvincent> ok. i have some git experience. i'll start out with a sandbox
[22:10:32]   <anarcat> cool
[22:10:37] <omega8cc>    sethvincent: congrats!
[22:10:58]   <anarcat> awesome
[22:11:09]  <EclipseGc>   sethvincent: be sure to let us all know where you sandbox is
[22:11:16] <EclipseGc>   your*
[22:11:29]    <sethvincent> ok. what will be the best way to share things like that?
[22:11:34] <anarcat> i'm sure it will be quite popular :)
[22:11:41]    <anarcat> hum
[22:11:43]  <shrop>   Just caught up on sethvincent's position here.. great!
[22:12:11]  <anarcat> sethvincent: maybe here?
[22:12:22]   <sethvincent> anarcat: ok
[22:12:23]  <anarcat> omega8cc: maybe you want to add pointers to your repos in there, btw
[22:12:43] <anarcat> sethvincent: otherwise, what's the next step for you and us? :)
[22:12:44] <omega8cc>    anarcat: right, good idea
[22:12:59]    <anarcat> and if anyone else has anything to add to our scrum, now is a good time - we're almost done!
[22:13:04]    <anarcat> darthsteven, you awake? :)
[22:14:19]   <sethvincent> anarcat: i need to study some of the general changes from d6 to d7, the aegir api, and write out a plan for the d7 port.
[22:15:13] <sethvincent> google code expects students to start coding somewhere around may 24, but i'd like to do a slow start earlier than that so that by may 24 i've already made some progress.
[22:15:33] <anarcat> i see
[22:15:43]    * arianekWORK has quit (Quit: Smell ya later)
[22:15:44]    <anarcat> so between now and the 24th you start documenting a plan is that right?
[22:16:13]  <anarcat> the right place for this is probably the handbook on the community site
[22:16:19]  <sethvincent> yeah. a plan, studying documentation, and getting to know the mentors is what's listed on the google summer of code site, i think.
[22:16:20]  <sethvincent> ok
[22:16:51]   <anarcat> i have done some of that documentation here:
[22:16:56]   <anarcat> before starting some coding, at least
[22:17:01]    <sethvincent> ok
[22:17:49]   <anarcat> alright, so welcome on board again, and thanks everyone for attending our scrum session!

Weekly Scrum IRC Log: 2011-05-03


[22:01:15]    * anarcat SCRUM TIME!
[22:01:24]    * anarcat cues boom-boom beat
[22:01:30]    <anarcat> alrighty
[22:01:40] <anarcat> so
[22:01:56]   <anarcat> what i'll do this week: finish setting up the new jenkins server, and work on drush/provision unit testing in 2.x
[22:02:07]   <anarcat> i have fixed a pesky issue in the site form editing
[22:02:09]  <shrop>   Haha
[22:02:22] * trainer has joined #aegir
[22:02:31]  <anarcat> and we're struggling with a core dump in d7 installs on our production server we can't reproduce in staging, really weird
[22:02:39]  <anarcat> if anyone got more info, let me know
[22:02:52] <anarcat> that's it for me
[22:03:02]    <anarcat> anyone else?
[22:03:07] <sethvincent> i'll go
[22:03:11] <anarcat> c_mcintosh: you said you had something to mention for our scrum?
[22:03:18] * arianek is now known as arianek_afk
[22:03:20]    <anarcat> sethvincent: go ahead!
[22:03:28]   <sethvincent> sandbox:
[22:03:43]  <sethvincent> and the plan:
[22:03:51]    <gmclelland>  is hostmaster-pause still a valid drush command? It tells me could not be found?
[22:04:01] <sethvincent> if anyone has advice on the plan that i wrote up please let me know
[22:04:08]  <anarcat> gmclelland: please wait after the scrum :)
[22:04:20]   <EclipseGc>   sethvincent: I'll read through it
[22:04:33]   <sethvincent> i've been doing studying of the docs, and that's what i'll keep working on over the next week
[22:04:47] * scottrigby has joined #aegir
[22:04:48]   * anarcat reading up
[22:04:49] <sethvincent> @EclipseGc thanks!
[22:04:57]   <anarcat> sethvincent: sounds good!
[22:05:04]    * arianek_afk has quit (Remote host closed the connection)
[22:05:06]   <sethvincent> cool. that's it for me.
[22:05:20] <anarcat> sethvincent: do you plan on reviewing the existing work in the issue queue?
[22:05:25]  <anarcat> that's where most of the stuff is so far
[22:05:31]    <sethvincent> ah. yes
[22:06:13]  <anarcat> i'm happy to see a plan, so far it looks sound
[22:06:23]  <sethvincent> ok
[22:06:53]   <anarcat> sethvincent: you should authentify with nickserv when you hang around here, it will give you +v, which is a good way to get notified when the scrum starts
[22:07:03]   <EclipseGc>   I'm hoping to get to do this this week or next, but I'm actually intending on screwing around with drupal commerce some to see if I can get an outside of aegir D7 + DC platform requesting that aegir provision new sites
[22:07:19] <anarcat> we may make the channel +m (moderated, so only voiced users can talk) eventually so that will make it really important you authentify
[22:07:23]    <sethvincent> anarcat: ok. i'll do that
[22:07:23]   <anarcat> and that goes for everybody :)
[22:07:45]   <anarcat> EclipseGc: cool - note that c_mcintosh is working on that
[22:08:05]    <EclipseGc>   anarcat: I assume?
[22:08:07] <anarcat> koumbit is also rolling out a new ecommerce frontend that will talk with aegir through XMLRPC, maybe in collaboration with c_mcintosh, we'll see
[22:08:42]    <anarcat> wtf
[22:08:43]  <anarcat> no
[22:08:57]   <anarcat> c_mcintosh: that's not a good module name
[22:09:12]   <anarcat> c_mcintosh: first, it should be called hosting_* as hostmaster is the profile name
[22:09:19]   <anarcat> c_mcintosh: second, "plus" doesn't mean anything
[22:09:30]  <EclipseGc>   anarcat: I was just intending on trying to get a straight up drush provisioning call going and requiring that they be on the same server
[22:09:38] * Met4physica has quit (Quit: Leaving)
[22:10:31]   <anarcat> EclipseGc: not sure what you mean there
[22:10:40]  <EclipseGc>   anarcat: meh, no worries
[22:11:04] <EclipseGc>   anarcat: I've not even gotten to dig in yet, so, nothing to see here ;-)
[22:11:09]    <darthsteven> my turn?
[22:11:36] <anarcat> darthsteven: go ahead! :)
[22:12:11]    <darthsteven> Well, I looked at running cron using wget for D7 and popped a fix into the 2.x branch
[22:12:35]    <darthsteven> I think the change is pretty simple, and could be easily backported to 1.x
[22:12:59]   <darthsteven> Also, I have been thinking about the scheduled task problem
[22:13:24]  <darthsteven> so plan for coming week is more docs and coming up with a firm plan for scheduled/recurring task
[22:13:29] <darthsteven> that's all
[22:14:15]  <anarcat> cool
[22:14:21] <anarcat> i commented on your issue, but basically it's a great idea
[22:14:30]  <anarcat> so we're almost done with our scrum here
[22:14:45]    <anarcat> if anyone else has something to add, speak now or be silent for... a week ;)
[22:14:51] <anarcat> just kidding, you can speak whenever :P
[22:14:55]  <omega8cc>    I don't have anything special to report this week - it was a little spring holiday for me, but next week I plan to work on some Nginx related docs for c.a.o.
[22:14:57]   <anarcat> but now is the best time to get feedback!
[22:15:02]    <anarcat> awesome
[22:15:09]  <anarcat> omega8cc: thanks for that cron.php fix btw
[22:15:13]   <darthsteven> awesome module:
[22:15:24]  <anarcat> you guys were making me crazy with that to and fro :)
[22:15:42]    <anarcat> darthsteven: yeah, that's freaking awesome
[22:15:46]  <anarcat> we need to merge it into 2.x
[22:15:53] * ipwa has quit (Quit: ipwa)
[22:15:55] <darthsteven> or just add to the makefile?
[22:16:42] * sethvincent has quit (Quit: Page closed)
[22:17:31]   <EclipseGc>   add to makefile
[22:17:32]  <EclipseGc>   ftw
[22:17:46]  * dob_ has quit (Read error: Connection reset by peer)
[22:17:50]   <anarcat> i think it should be in
[22:18:07]  * dob_ has joined #aegir
[22:18:15] <anarcat> but whatever...
[22:18:20]  <darthsteven> anyone else
[22:18:24]  <anarcat> the biggest problem right now is that it hardcodes /var/aegir
[22:18:29]    <darthsteven> want to say anything?
[22:18:30]    <anarcat> i think we're done!
[22:18:37] <anarcat> or late
[22:18:45]  <anarcat> and since we're not allowed to be late, we're done :P
[22:18:48]  <anarcat> ciao everyone
[22:18:52]    <anarcat> thanks for attending :)

Weekly Scrum IRC Log: 2011-05-10


[12:14am] anarcat: darthsteven mig5 bgm ergonlogic mvc joestewart omega8cc sfyn shrop skwashd univate_ : scrum time!
[12:14am] anarcat: alright
[12:14am] anarcat: so for my part i haven't done much aegir work in the last week
[12:14am] anarcat: i was swamped with sysadmin duties and other koumbit stuff
[12:15am] anarcat: i am trying to fix that damn d7 segfault problem we're having and i'm stuck
[12:15am] anarcat: i will try to find sometime this week to finally setup the new jenkins server and start to work on provision unit tests
[12:15am] anarcat: sfyn something else to add to our scrum?
[12:15am] anarcat: omega8cc ?
[12:15am] omega8cc: I'm still busy writing some Nginx related updated docs for c.a.o when I have some rare free minutes, and in the meantime Barracuda and Octopus have been finally moved to d.o, yay!
[12:15am] omega8cc: See and, so we can co-operate better now.
[12:15am] anarcat: yay!
[12:16am] anarcat: awesome
[12:16am] omega8cc: Next week I plan to publish the docs I collected so far. That is it for me.
[12:16am] sfyn: Since last I came I started rolling out releases for uc_hosting
[12:16am] sfyn: I am working on the next one this week and then I am porting the puppy to D7
[12:17am] sfyn: And implementing remote storefronts, which means I am going to start working on services
[12:17am] anarcat: awesome
[12:17am] Pathin left the chat room. (Ping timeout: 252 seconds)
[12:17am] sfyn: cmcintosh has convinced me, along with 8 of his friends, to go with servicesapi
[12:17am] sfyn: also
[12:17am] anarcat: it seems our gsoc student is missing, but he's going to work on the d7 port of hostmaster, so you may want to coordinate with him on that
[12:18am] sfyn: quota api, and particularly the sites implementation of it could use some love, and i've noticed that platforms being locked prevent you from changing anything on a site at all
[12:18am] sfyn: anarcat: what is his nick on irc?
[12:18am] anarcat: sfyn: he's sethvincent
[12:18am] Pathin joined the chat room.
[12:18am] sfyn: anarcat: and maybe you could fire over his email
[12:18am] anarcat: about platforms being locked - yeah, another user reported something like this recently
[12:18am] anarcat: sfyn: not sure i have his email, lemme check
[12:19am] sfyn: thanks
[12:19am] sfyn: one last thing
[12:19am] anarcat: done
[12:19am] sfyn: this discussion:
[12:20am] sfyn: has a question about deploying phpmyadmin on slave servers, would be cool if someone could chip in with experience with those
[12:20am] anarcat: note that i haven't followed the issue queue or the community site in about a week, so i'm a bit lagging
[12:20am] Pasqualle left the chat room. (Ping timeout: 240 seconds)
[12:20am] sfyn: anarcat: received and thanks
[12:20am] anarcat: i see
[12:21am] Artusamak is now known as Artusamak_afk.
[12:21am] anarcat: not sure i have time for this right now, but i would just set it up as a separate vhost
[12:21am] anarcat: and no need to set it up on all servers...
[12:21am] anarcat: anyways, we need some integration there so that mysql servers get configured in PMA
[12:21am] anarcat: i think therE's an issue for that
[12:21am] anarcat: anyone else for the scrum?
[12:23am] • sfyn chirps like a cricket
[12:24am] mvc: did i mention my pet drush module here lately?
[12:24am] mvc:
[12:24am] anarcat: mvc: i don't think you did!
[12:24am] anarcat: sweet
[12:24am] mvc: it reports which projects (as in groups of modules) are in use by different sites in one or more platforms
[12:25am] anarcat: good work
[12:25am] mvc: as soon as i get around to testing it with d5 and d7 i'll move it out of the sandbox
[12:25am] anarcat: isn't status-report a bit confusing as a command name? i would expect that command to give me similar results than the status report page in the drupal site...
[12:26am] anarcat: otherwise, cool
[12:26am] omega8cc: there is some promising contrib to review, if you can help
[12:26am] Pathin left the chat room. (Quit: Lost terminal)
[12:27am] obrienmd: mvc: really intersted in testing that, will do so ASAP... agree w/ anarcat on the command name though
[12:27am] omega8cc: see
[12:27am] FatGuyLaughing left the chat room. (Quit: FatGuyLaughing)
[12:29am] anarcat: alright
[12:29am] anarcat: oh
[12:29am] anarcat: another thing
[12:29am] anarcat: koumbit is going to make a presentation at drupalcon this year
[12:29am] anarcat: i would have loved to talk with darthsteven about this, i guess we can catch up later this week
[12:29am] anarcat: but basically, we're going to send the proposal soon, the deadline is the 15th, iirc
[12:30am] anarcat: so there we go
[12:30am] anarcat: i think that covers it for our scrum
[12:30am] anarcat: thanks everybody for attending
[12:30am] anarcat: and see you next week!
[12:30am] • anarcat scrum over!
[12:30am] omega8cc: ciao
[12:30am] sfyn: salut
[12:30am] szczym: see you

Weekly Scrum IRC Log: 2011-05-24

[22:00:11]    * anarcat SCRUM TIME!
[22:00:27]    <j0nathan>    hi
[22:00:35]   <anarcat> darthsteven / mig5 / bgm / grugnog / joestewart / mvc / omega8cc / sethvincent / / sfyn / shrop : scrum time!
[22:00:35]    <hefring> anarcat: 2 days 8 hours ago <mig5> tell anarcat I don't know if one can export. I am happy to copy-and-paste, can you make me an admin of the system when you get a chance
[22:00:38]    <anarcat> hallo :)
[22:00:50] <anarcat> mig5: sure will!
[22:00:54] <anarcat> so i'll start by saying
[22:00:54] <omega8cc>    hello!
[22:00:54]   <hefring> que tal
[22:00:55]  <anarcat> hi!
[22:00:55]  <hefring> hola
[22:00:56] <anarcat> :)
[22:01:09]   <anarcat> i've got a few thinsg to touch base on
[22:01:18]  <anarcat> darthsteven: we need to talk about drupalcon
[22:01:31] <anarcat> darthsteven: we'd like to see if you could participate in the training
[22:01:40]  <anarcat> also
[22:01:53] <anarcat> i'll be going to the drush code sprint in boston 27-28 of june
[22:02:04]  <anarcat> and i'll probably be around boston during the weekend too for the design camp
[22:02:12]   <anarcat> so if anybody wants to hang out or say hi
[22:02:13]    <anarcat> hi :)
[22:02:18]    <anarcat> what else
[22:02:35]    <anarcat> i'll look in the sites security issues this week - the stuff about sites being visible by anonymous users
[22:02:50]   <anarcat> i know that sfyn is working on the uc_hosting module real hard, and got a 1.0 release out (or almost)
[22:03:11]    <anarcat> we're looking at creating a d7 ubercart frontend that could talk to the aegir backend using cmcintosh's services_api stuff
[22:03:14] * henk_ has quit (Remote host closed the connection)
[22:03:22] <anarcat> so i think that's it for me!
[22:03:33]    <anarcat> deadline for drupalcon votes is tomorrow, please vote for our sessions!
[22:03:50]  <anarcat>
[22:03:54]  <anarcat> anyone else?
[22:04:38] <sethvincent> i will officially start coding for gsoc today!
[22:04:50]   <anarcat> yaaay! :)
[22:04:57]    <anarcat> sethvincent: so what do you need help on now?
[22:05:07]    <sethvincent> i'll be getting started by making a branch in my snadbox to test out the relevant patches in the issue queue
[22:05:20]    * peterm95018 has quit (Quit: peterm95018)
[22:05:24]   <anarcat> cool
[22:05:34] <anarcat> take a look at this one, i think that's a key issue:
[22:06:11]  <sethvincent> right, that seems like the main one i need to work with
[22:06:20]  <anarcat> okay
[22:06:27] <anarcat> if you need any help, please do let me know
[22:06:53]  <anarcat> sethvincent: anything else?
[22:06:54]  <sethvincent> i figure once i start testing out patches, doing a test run through coder upgrade and such things i'll have a list of questions i could use help with
[22:06:55]   <anarcat> anyone else?
[22:07:02] <anarcat> awesome
[22:07:02]  <sethvincent> that's about it for me.
[22:07:05] <anarcat> sethvincent: ping me any time
[22:07:07]    <anarcat> as an aside, if anybody hangs around the channel wants some training for aegir, please look at
[22:07:09]  <sethvincent> ok. thanks
[22:07:28]   <anarcat> darthsteven / mig5 / josh_k / omega8cc / shrop : anything to add to our weekly scrum?
[22:07:54]    <anarcat> i can add for myself that i will be reviewing the patch queue tomorrow and try to get some of those commits in, and who knows - get 1.2 out the door? :)
[22:07:59] <joestewart>  I posted a couple of simple patches that should be easy to review.
[22:08:06]   <josh_k>  I am currently working a small side project to try and get universities to use aegir
[22:08:15] <anarcat> awesome!
[22:08:21] <anarcat> double-awesome! ;)
[22:08:22]   <josh_k>  if it works, it should mean more users and hopefully more support (of the good kind)
[22:08:26] <josh_k>  :)
[22:08:29]   <anarcat> great :)
[22:08:35] <anarcat> joestewart: thanks for the patches
[22:09:06]   <anarcat> alright, anyone else?
[22:10:15]    <anarcat> omega8cc: ?
[22:10:18]  <anarcat> maybe?
[22:10:48]   <omega8cc>    not much this week, still working on new docs for aegir/nginx
[22:10:59]    <omega8cc>    plus some video maybe
[22:11:04]    <anarcat> good
[22:11:56] <anarcat> alright
[22:12:05]  <anarcat> so i think that does it for our scrum, thanks everyone for attending!
[22:12:20]    <anarcat> if anyone has anything to add, i'll stick around another 3 minutes, but in the meantime i'll upload the log to the site
[22:12:21]    <omega8cc>    ciao

Weekly Scrum IRC Log: 2011-05-31

[22:00:12]    * anarcat SCRUM TIME!
[22:00:19]    <anarcat> so welcome to our weekly scrum and blablablablabla :)
[22:00:26]    <anarcat> I WANT TO RELEASE 1.2! :)
[22:00:42]    <Aciid>   more aegir harder faster stronger
[22:00:43]    <anarcat> i've been itching to make a new release, and since we have a few good patches in, i thought it'd be a good idea
[22:00:54]    <anarcat> i could do it on thursday
[22:00:56]    <sfyn>    WOW THAT SOUNDS GREAT ANARCAT! Is that the release we only talk about in all-caps?
[22:01:00]   <anarcat> if nobody freaks out until then
[22:01:07]  <anarcat> sfyn: no, it's not. :)
[22:01:22]  * bwood has joined #aegir
[22:01:27]    <anarcat> i've been mostly focused on working on the stable branch so far
[22:01:35] <anarcat> but i merged stuff around
[22:01:42]    <anarcat> i wonder where our gsoc student is
[22:02:12]   <anarcat> i'll be reviewing the patches sitting in the queue, so if you want to submit a patch for 1.x, now is a good time to push it up to RTBC
[22:02:19]  <anarcat> and that's about it for me!
[22:02:31] <anarcat> anyone else got something to announce here?
[22:02:43]  <sfyn>    nope
[22:02:49] <anarcat> oh and i'll be working on the dupe client/site visible to anon stuff too this week
[22:02:57]  * FransK has quit (Ping timeout: 258 seconds)
[22:03:23]    <anarcat> since nobody is saying anything, i'll just bring something on a completely unrelated note:
[22:03:33]   <mig5>    morning
[22:03:41]  <anarcat> i'm building a huge ham radio antenna, 15'x15'x14', 11' in the air
[22:03:43]  <anarcat> heey mig5 !
[22:03:46]  <sfyn>    anarcat: wow that really is very unrelated
[22:03:50]   <mig5>    omg i woke up in time for a scrum
[22:03:56]    <jmcclelland> anarcat: i only now saw your response to I'd like to follow up and see if we can come up with a reasonable strategy before your next release.
[22:03:59]   <anarcat> mig5: omgomgomg! :)
[22:04:24]  <sfyn>    Would this perhaps be a good time to mention I won't be going to London, and so Koumbit will need a third aegir dev interested in participating in our training?
[22:04:27]    <anarcat> mig5: i changed the DNS records as you asked
[22:04:43] <anarcat> sfyn: i already mentionned this to darthsteven, we'll see where it goes
[22:04:46] <sfyn>    sl;ash helping us to deliver our training
[22:04:49]    <mig5>    thanks anarcat. darthsteven has sudo on that box now so there's more hands on deck
[22:04:53]  <sfyn>    anarcat: ah, ok, thanks
[22:05:07]  <anarcat> we're having trouble getting him to sync in during the scrum these days, maybe we can retune our schedule...
[22:05:29]    <anarcat> mig5: great!
[22:05:46] <anarcat> jmcclelland: i'm not sure we can get that in 1.x, actually - it seems like this would change the API in a significant way...
[22:05:53]    <anarcat> jmcclelland: but we can certainly talk about this :)
[22:05:56]   <anarcat> and at least get a fix in 2.x
[22:06:04]    <jmcclelland> ok - i understand.
[22:06:49]   <anarcat> jmcclelland: but yeah, thanks a lot for getting involved, that issue is ... hard :)
[22:06:58]  <anarcat> alrighty
[22:07:02] <anarcat> anyone else wants to jump in?
[22:07:08]    <anarcat> doing cool aegir stuff?
[22:07:13]  <anarcat> building crazy ham radio antennas? :)
[22:07:25]    <mig5>    hehe
[22:07:37] <sfyn>    I am working on an extension to provision to provision ham radio antennaes
[22:07:38]   <mig5>    i've nothing else to add, i only worked on the jenkins machine since coming back from overseas
[22:07:58]  <anarcat> sfyn: you're so lying :P
[22:08:11]    <sfyn>    anarcat: no it should be ready by quarter 5, 2019
[22:08:32]    <anarcat> ok cool
[22:08:34]  <anarcat> mig5: okay!
[22:08:46]  <anarcat> mig5: i am not sure where to go with that other vserver now
[22:08:53]  <anarcat> i've been busy with other stuff so i couldn't take care of that
[22:09:22]    <anarcat> mig5: what do you think of a 1.2 thursday?
[22:09:31]   <anarcat> or friday in your timezone :)
[22:09:39]    <anarcat> (iirc)
[22:10:45]   * bwood has quit (Quit: bwood)
[22:10:49]   <mig5>    should be ok, i'll be 'around'
[22:10:57]    <mig5>    what other vserver are you referring to
[22:11:24]  <anarcat> mig5: the other jenkins server?
[22:11:27]  <mig5>    the original jenkins machine is my own jenkins machine that runs stuff on lots of my servers, so i've just dropped those old aegir jobs since migrating them
[22:11:47]    <anarcat> didn't you setup a separate jenkins server for me to play with?
[22:11:49] <mig5>    the reason we moved it was so i could give you sudo on a machine without exposing my evil little secrets :)
[22:11:56]  <mig5>    the new jenkins server is for you to play with
[22:12:06]   <anarcat> oh, so that new ip is excatly that!
[22:12:07]  <anarcat> i see
[22:12:11]    <mig5>    yep
[22:12:12]  <anarcat> so you migrated all the jobs!
[22:12:13]    <anarcat> awesome
[22:12:21]  <mig5>    yes so go crazy :)
[22:12:23]   <anarcat> okay, then i guess that's one thing less on my list :)
[22:12:24]  <anarcat> great!
[22:12:30]   <mig5>    i think we intended on not building 'cloud' machines but doing aegir installs directly on that box from git
[22:12:33]    <anarcat> one thing i want to do is autobuild debian packges
[22:12:40]   <mig5>    oooh yes
[22:12:40] <anarcat> yeah that too
[22:12:44]    <anarcat> do we still do the cloud thing?
[22:12:48]  <mig5>    yes for now
[22:12:55]  <anarcat> okay so here's my idea
[22:13:00]  <anarcat> we can chain jobs right?
[22:13:03] <mig5>    yep
[22:13:05]  <anarcat> so we have a job that builds the package
[22:13:11] <anarcat> another that installs it!
[22:13:15]    <anarcat> dumb and simple :)
[22:13:17]   <mig5>    perfect
[22:13:32]  <anarcat> oh wait, there's another one (duh) - another one removes the package! :)
[22:13:34]    <mig5>    and we can chain an install + upgrade too
[22:13:40]    <anarcat> totally
[22:13:45]  <anarcat> so we can have a builder for the last release
[22:13:56]    <anarcat> then use that package to install then chain with the upgrade
[22:14:13] <anarcat> the intricacies of this are just scary for a jenkins newbie like me, but it looks promising
[22:14:19]  <anarcat> i tried the openid plugin again
[22:14:25]  <anarcat> and it failed on me again
[22:14:37]    <mig5>    chaining seems pretty straightforward in jenkins: and it's smart enough to know whether to not build if the previous job failed, etc
[22:14:37]    <anarcat> problem is - i became the openid_provider maintainer now, so i have no excuse left :P
[22:14:40]    <mig5>    hrm
[22:14:40]  <mig5>    haha
[22:15:15] <anarcat> kinda sucks :P
[22:15:43]   <mig5>    fuckity fuck :)
[22:15:48]  <mig5>    too funny
[22:15:50]    <anarcat> yeah
[22:15:55] <anarcat> so anyways
[22:16:00]   <anarcat> i think that's it for our scrum folks!
[22:16:03]  <anarcat> thanks for attending!
[22:16:11]    <mig5>    cheers

Weekly Scrum IRC Log: 2011-06-07

[15:00]  * anarcat SCRUM TIME!
[15:00] <@anarcat> welcome everybody
[15:00] <+sfyn> hello
[15:00] <@anarcat> so this is our weekly scrum
[15:00] <j0nathan> halo
[15:00] <@anarcat> and i'll be your host, jolly-o-anarcat
[15:00] <@anarcat> this week
[15:00] <@anarcat> i want to release 1.2
[15:00] <@anarcat> i know i said that last week
[15:00] <@anarcat> but i failed
[15:00] <@anarcat> so i'll try again :)
[15:00] <@anarcat> if you guys have patches to review or commit, now is a good time
[15:00] <@anarcat> i'll do a sprint tomorrow and try to release thursday
[15:01] <@anarcat> also
[15:01] <@anarcat> koumbit wants to blog about "cool things done with aegir" - we have a few on our end
[15:01] <@anarcat> but if you guys have good examples, bring it!
[15:01] <@anarcat> you can send sample sites or blurbs or text or whatever to me on irc here or by email at
[15:01] <@anarcat> what else what else
[15:02] <@anarcat> i think that's it for me, other than the fact that i'm probably supposed to harrass our gsoc student here
[15:02] <@anarcat> sethvincent: prod!
[15:02] <+sethvincent> hello!
[15:02] <@anarcat> prod prod :)
[15:02] == dunkoh [] has joined #aegir
[15:02] <@anarcat> hey seth, how's it going
[15:02] <@anarcat> can you give us a little progress update?
[15:02] <+sethvincent> sorry. classes here have just finished, so i'll be more active starting this week.
[15:03] <+sfyn> yay
[15:03] <@anarcat> yay! :)
[15:03] <+sfyn> !
[15:03] <+sethvincent> i've been working on porting eldir first.
[15:03] <+sethvincent> made a few initial commits of that work
[15:03] <+sethvincent> applied the 'turn features into features' patch and have been looking through the changes that introduces
[15:04] <+sethvincent> and that's about it
[15:04] <@anarcat> okay, those commits don't seem to be pushed on, please do so when you can!
[15:04] <@univate> I am willing to help out with some of that "features" stuff if you need it
[15:04] <@anarcat> good work
[15:04] <@anarcat> awesome!
[15:04] == dunkoh [] has quit [Client Quit]
[15:04] <@anarcat> univate: please do! i understand you had good contributions there
[15:04]  * sfyn raises his hand
[15:04] <@anarcat> in fact, if you want to help sethvincent by reviewing and merging his patches in, that's great
[15:04] <@anarcat> sfyn: go right ahead
[15:04] <@anarcat> i think seth was done
[15:04] == jerryitt [] has joined #aegir
[15:05] <+sethvincent> cool. so far all the stuff i'm working on is here:
[15:05] <+sfyn> not much done, but I have started working on the servicesAPI imp from the hostmaster_plus module
[15:05] <+sfyn> Bit of a mess, but I am hosting that work on github for now
[15:05] <+sfyn>
[15:05] == AquaticDisorder [] has joined #aegir
[15:05] <+sfyn> The big news - the module can now be installed
[15:05] <@univate> I have a couple a major projects that are planning to use aegir, so hoping to have a a bit more time focused on this
[15:05] <@anarcat> sethvincent: i see... the url linked from the gsoc page is wrong:
[15:05] <+sfyn> I am waiting to hear back from cmcintosh - the original author - before publishing to
[15:06] <+sethvincent> anarcat: oh! i'll fix that
[15:06] <@anarcat> sfyn: why isn't that on
[15:06] <@anarcat> oh nevermind :)
[15:06] <@anarcat> sfyn: i think you should go ahead and publish
[15:06] <+sfyn> I agree
[15:06] <+sfyn> if mr. mac doesn't get back to me by friday I will
[15:06] <@anarcat> ok
[15:07] <@anarcat> great
[15:07] <+sfyn> YOU HEAR THAT CMCINTOSH?
[15:07] <@anarcat> SFYN: I DON'T THINK HE'S HERE!
[15:07] <@anarcat> ;)
[15:07] <@anarcat> alright, enough yelling :)
[15:07] <+sfyn> maybe he will read the scrum log later
[15:07] == FatGuyLaughing [~FatGuyLau@] has quit [Quit: FatGuyLaughing]
[15:07] <@darthsteven> my turn
[15:07] <@anarcat> sfyn, if you're done, i think we can move on to mig5 or darthsteven
[15:07] <@anarcat> alright :)
[15:07]  * sfyn clams up
[15:08] <@mig5> nothing from me this week i'm afraid
[15:08] <@darthsteven> so, this week I've been reviewing a few issues and committing some of my patches to the 7.x branch and 6.x too
[15:08] <@mig5> i hear the distribution relesae node issue was fixed
[15:08] <@darthsteven> thinking about things to do with cron
[15:08] <@anarcat> darthsteven: cool
[15:08] <@anarcat> mig5: yes, at last!!!
[15:08] <@darthsteven> I'm going to hit documentation hard over the next few weeks
[15:09] <@darthsteven> to live up to my 'documentation maintainer' title :)
[15:09] <@anarcat> cool :)
[15:09] <@anarcat> that's great!
[15:09] <@darthsteven> I'd also like to get sorted out
[15:09] <@darthsteven> cause it's a bit of a mess at the moment
[15:09] <@anarcat> darthsteven: we should really move the api site to our aegir server, that would fix a lot of shit
[15:09] <@anarcat> yeah
[15:09] <@anarcat> ergonlogic was proposing we move to d7 too
[15:10] <@darthsteven> we can discuss in the issue...
[15:10] <@anarcat> yeah
[15:10] <@darthsteven> that's it from me
[15:10] == ipwa [~ipwa@] has joined #aegir
[15:10] <@anarcat> alright
[15:10] <@darthsteven> anyone else?
[15:10] <@anarcat> mig5: anything to add?
[15:10] <@mig5> nope
[15:10] <@anarcat> otherwise i think we're kind of done here
[15:10] <@anarcat> thanks everyone for attending, and see you on the other side of 1.2 :)
[15:10] <@anarcat> oh
[15:10] <+sfyn> cya all next week
[15:10] <@anarcat> another thing
[15:11] <@anarcat> i am trying to remove aegir from ubuntu
[15:11] <@anarcat> because it currently ships with 0.3
[15:11] <+sfyn> oops
[15:11] <@anarcat> which is confusing some people
[15:11] <@anarcat> and is blocking the drush backport
[15:11] <@anarcat> but that seems to be hard
[15:12] <@anarcat> if anyone wants to help in the ubuntu effort, that would be apprecitated:
[15:12] <@anarcat> and
[15:12] <@anarcat> so that's about it
[15:12] <@anarcat> thanks again everyone

Weekly Scrum IRC Log: 2011-06-21

21:59 <@anarcat> hey
21:59 <@anarcat> gooood morning vietnam!
22:00 <@mig5> HELO
22:00 <@anarcat> alright
22:00  * anarcat SCRUM TIME!
22:00 <@anarcat> gosh this is early
22:00 <@anarcat> so welcome everyone
22:00 <@darthsteven> heh
22:01 <@anarcat> i'm your sleepy host, unless another timezone feels less jetlagged :)
22:01 <@mig5> getting sleepy :)
22:01 <@darthsteven> I'm your less sleepy host then
22:01 <@anarcat> yay! :)
22:01 <@darthsteven> Welcome to the scrum for 21 Jun 2011
22:01 <@darthsteven> Who wants to speak first?
22:01 <@darthsteven> anarcat?
22:01 <@anarcat> i can try! :)
22:02 <@anarcat> so i haven't published 1.2, but this time i have a good excuse
22:02 <@anarcat> we're really almost there - i want to test the debian packages first
22:02 <@anarcat> i was able to make an autobuilder in jenkins
22:02 <@anarcat> so jenkins now has a pgp key and can build packages. both from the debian branch and from the 1.x branch
22:02 <@anarcat>
22:02 <@darthsteven> cool
22:03 <@anarcat> there are a good few questions in there that i'd like feedback about
22:03 <@anarcat> esp. from mig5
22:03 <@mig5> awesome, you are now our CI ninja :)
22:03 <@anarcat> crap :)
22:03 <@darthsteven> anything else anarcat?
22:03 <@anarcat> well, there's this daemon thing :)
22:04 <@anarcat> i played with darthsteven's queue runner, and it's awesom
22:04 <@anarcat> we're running it in production, working very well, got people impressed
22:04 <@anarcat> i want to merge it in 2.x
22:04 <@anarcat> and port our dispatcher to the d7 queue system
22:04 <@anarcat> i think we should make queue-runner 1.1
22:04 <@anarcat> i think that's about it for me!
22:05 <@darthsteven> mig5?
22:05 <@darthsteven> (thanks anarcat)
22:05 <@anarcat> welcome!
22:05 <@mig5> nothing from me this week, i need to catch up on the jenkins changes
22:05 <@darthsteven> okay, cool
22:05 <@darthsteven> I'll go next...
22:06 <@darthsteven> I looked at the daemon for running tasks with anarcat
22:06 <@darthsteven> resulting in a 1.1 release, which anarcat hasn't noticed :)
22:06 <@anarcat> haha cool
22:06 <@darthsteven> We also got the api site sorted last week, though mostly not down to me
22:06 <@darthsteven> which is ace!
22:07 <@mig5> nice
22:07 <@darthsteven> I added a new hook to enable friendly names for servers in lists of servers
22:07 <@darthsteven> and released a module that uses the hook
22:07 <@darthsteven>
22:08 <@darthsteven> I think I added a ton of documentation the week before too
22:08 <@darthsteven> which was nice
22:08 < chouchou> Hello,
22:08 <@anarcat> cool
22:08 <@darthsteven> but that's it from me
22:08 < chouchou> pls i have an issue,
22:08 <@anarcat> note that i documented the 2.x api changes here
22:08 < chouchou> first, i wouuld like to know how do I change the drush gid download source ?
22:08 <@darthsteven> chouchou: We're in the middle of a scrum, please hold for the end, then you can ask
22:08 <@anarcat> i think we should keep that page in mind when we change the API
22:08 <@darthsteven> anyone else have anything for the scrum?
22:09 <+omega8cc> I finally started publishing some nginx related docs on and will extract from there to re-post on c.a.o handbook, also some new nginx patches are in testing and should be sumitted for review shortly, we are sponsoring also Aegir session at next week!
22:09 <@darthsteven> awesome
22:09 <@mig5> props to shrop who has done great work on the community site sorting some stuff out
22:09 <@darthsteven> omega8cc: anything else?
22:09 <@anarcat> all good
22:09 <+omega8cc> that is it from me, i think
22:10 <@anarcat> ah, note that i'll be at the drush test sprint next week, so i will probably miss the scrum
22:10 <@anarcat> if you guys have specifics of things i should work on with drush, let me know!
22:11 <@darthsteven> anyone else have anything to add?
22:11 <@darthsteven> I'll give it a minute...
22:11 <@anarcat> well, i'd like to chat quickly with mig5 about the jenkins stuff
22:11 <@anarcat> mig5: did you read up on the issue?
22:11 <@mig5> this one?
22:12 <@anarcat> mig5: upy
22:12 <@anarcat> yup*
22:12 <@anarcat> basically, we need to decide this:
22:12 <@anarcat> 1. do we install/remove/update/whatnot on the jenkins server? (be scared)
22:12 <@anarcat> 2. do we install using dpkg -i or do we upload to's unstable repository and use apt-get? (the latter has the disadvantage of having 
                 to wait a undetermined delay for repo to catchup, but has the upside of broadening the test capabilities)
22:12 <@anarcat> i am thinking more and more of this as a build bot, with packges uploaded to
22:13 <@anarcat> and then everyone can test them, including jenkins or "the cloud", from jenkins
22:13 <@mig5> 1. is fine with me but i was already scared :) but as far as I can tell, it's the only way to sanely chain tasks.. (as opposed to an isolated 
              cloud-generated VPS)
22:14 <@mig5> the fundamental thing i want to do with theses tests, is pretend like we are a user
22:14 <@anarcat> well that's the thing, if we upload to debian.k.n, then we can run install/upgrade/whatever independently...
22:14 <@mig5> except with preseeding :)
22:14 <@mig5> so i think the apt-get is good
22:14 -!- bgm_ is now known as bgm
22:14 <@anarcat> ok
22:14 <@anarcat> mig5: do you know about jenkins's "tasks"?
22:14 -!- bgm [~bgm@2607:f748:1200:105::5] has quit [Changing host]
22:14 -!- bgm [~bgm@pdpc/supporter/active/bgm] has joined #aegir
22:14 <@mig5> no
22:14 <@anarcat> ok
22:14 <@mig5> i've only done build steps
22:15 <@anarcat> i tried to play with that, but i don't feel it's what we need, basically...
22:15 <@anarcat> it's a weird thing
22:15 <@anarcat> so okay, that's cool
22:15 -!- mode/#aegir [+v shrop] by ChanServ
22:15 <@anarcat> i think i'll try to setup fabric stuff to deploy debian packages remotely
22:15 <@anarcat> and of course upload to debian.k.n
22:15 <@mig5> deploy as in send to koumbit.d.n ?
22:15 <@mig5> er
22:15 <@mig5> ah
22:15 <@anarcat> and fix the preseed
22:16 <@mig5> so by deploy debian packages remotely you mean, build on fresh VPS?
22:16 <@mig5> as i am not against the former
22:16 <@anarcat> deploy as in ssh 'apt-get install aegir; drush provision-tests ; apt-get remove aegir'
22:16 <@mig5> so long as we can clean up our mess on the jenkins server
22:17 <@anarcat> well, i'm worried about not being able to do that
22:17 < chouchou> are you free now?
22:17 <@mig5> my main worry about is we may lose the ability to chain builds
22:17 <@anarcat> *and* about interop problems with jenkins itself
22:17 <@darthsteven> Anyone else have anything for the scrum? Otherwise we'll wrap it up there, and leave mig5 and anarcat to it...
22:17 <@anarcat> darthsteven: yup, ok
22:17 <@darthsteven> 

Weekly Scrum IRC Log: 2011-06-28

[22:01:28]  <darthsteven>  scrum time!
[22:01:35]  <darthsteven>  who wants to go first?
[22:01:51]  <darthsteven>  me?
[22:01:55]  <darthsteven>  okay, if you insist
[22:02:09]  <darthsteven>  I've not done much since last week
[22:02:27]  <darthsteven>  Don't really have anything to report
[22:02:36]  <darthsteven>  that's it from me!
[22:02:43]  <darthsteven>  anyone else have anything to add?
[22:03:08]  <mig5>  i've done nothing this week either.. sadly I don't see things changing from that, either..
[22:03:16]  <shrop>  darthsteven: I hope to add more docs to soon. Some ldap config info for Active Driectory
[22:03:29]  <mig5>  nice
[22:03:34]  <darthsteven>  awesome
[22:03:42]  <darthsteven>  anyone else?
[22:04:15]  <omega8cc>  I fixed a few bugs in the Nginx config, submit even more patches for review and also discovered we don't support D7 properly yet:
[22:04:15]  <hefring> => Paths to images are broken in D7 after site clone/rename => Provision, Code, critical, needs work, 2 comments, 1 IRC mention
[22:05:08]  <darthsteven>  oh hello, that's a bit of a showstopper
[22:05:31]  <darthsteven>  anyone else?
[22:05:45]  <omega8cc>  and that is it from me, I think, I plan to submit even more patches next/this week
[22:06:04]  <darthsteven>  Thank you omega8cc
[22:06:13]  <darthsteven>  anyone else have anything to add/discuss?
[22:06:36]  * mrconnerton has joined #aegir
[22:06:41]  <omega8cc>  so, what about 1.2?
[22:07:05]  <omega8cc>  are we waiting for anarcat probably?
[22:07:27]  <darthsteven>  I think that anarcat was working to get the debian packages built and tested automatically before releasing 1.2
[22:07:36]  <darthsteven>  and we need to fix the issue you found
[22:07:43]  <omega8cc>  yeah
[22:08:20]  <darthsteven>  Well, we'll end the scrum there I think
[22:08:27]  <darthsteven>  thanks for coming
[22:08:33]  <darthsteven>  logs?
[22:08:33]  <hefring>  yeah, ok, i admit, i'm logging this channel in - ask me about log bookmark too ;)
[22:08:45]  <darthsteven>  hefring: log bookmark?
[22:08:45]  <hefring>

Weekly Scrum IRC Log: 2011-07-05

[22:01:04]    <mig5>    scrum time
[22:01:12]   <omega8cc>    hello!
[22:01:12]   <mig5>    anarcat sends his apologies for this week
[22:01:25]    <mig5>    but I hear he had a good time at the drush sprint and got some good work done, so hopefully we'll hear more about that soon
[22:02:03] <mig5>    me, i once again didn't do anything.. oh, I did add to the jenkins deb install of aegir to uninstall and purge the packages before destroying
[22:02:13]   <mig5>    which is a final good test of those packages
[22:02:18] <halcyonCorsair>  omega8cc: i'm trying a barracuda/octopus upgrade before i try again
[22:02:40] <mig5>    i think we are well overdue for a 1.2 release, I am conscious there are a lot of patches from omega8cc for review (I think?) so we should get those in
[22:02:53]   <halcyonCorsair>  omega8cc: but i was having trouble replicating the site installation commands, i think there might have been some arguments i was missing?
[22:02:55]   <omega8cc>    halcyonCorsair: please wait 15 minutes, we have scrum time
[22:02:56]   <mig5>    that's it from me, over to darthsteven and omega8cc
[22:03:27] <darthsteven> sure
[22:03:52] * Harley has joined #aegir
[22:03:56]   <darthsteven> I got the Jenkins deb install of aegir working
[22:04:07]   <mig5>    epic
[22:04:13] <darthsteven> and worked on getting notification integration with Aegir
[22:04:26]    <darthsteven>
[22:04:42]  <mig5>    oh nice. i saw somewhere a sandbox link but it had disappeared
[22:04:47]   <darthsteven> So I now get push notifications on my iPhone when Aegir tasks fail
[22:04:51]   <darthsteven> which is nice
[22:04:58]    <darthsteven> write-up coming soon
[22:05:02] <mig5>    nice. Notifo?
[22:05:11]    <darthsteven> that's it from me
[22:05:25]   <darthsteven> (using prowl, but whatever messaging module supports is possible)
[22:05:36]    <mig5>    gotcha
[22:06:23]   <mig5>    omega8cc, anything to add? other than 'commit my patches you bastards' :)
[22:06:42]  <omega8cc>    ok, so I want to attack that weird critical today: and it lock all our upgrades schedule currently, and then will submit next round of improvements to the Nginx config plus - yay! Aegir UI patches!
[22:06:42] <hefring> => Paths to images are broken in D7 after site clone/rename => Provision, Code, critical, needs work, 3 comments, 3 IRC mentions
[22:07:52]    <mig5>    cool!
[22:07:55]    <omega8cc>    and that is it from me, but the UI changes are long overdue and I want to share them finally
[22:09:09] <mig5>    omega8cc: i wonder if that patch of yours needs to be applied to the file?
[22:09:13]  <mig5>    as opposed to
[22:09:18] <mig5>    but i've forgotten how it all works
[22:09:54] <mig5>    don't think it would change that result anyway
[22:09:57]  <omega8cc>    mig5: that is exactly what I think, it misses d7 specific stuff there completely
[22:10:04] <mig5>    strange
[22:10:08]  <omega8cc>    yeah
[22:10:15] <mig5>    anyway - anyone else got something to add to the scrum? ergonlogic?
[22:10:25]  <joestewart>  not directly on aegir but I posted two patches to drush_make that are useful for aegir. one that adds ability to set options in the makefile - the other updated a patch that allows setting working-copy per project -
[22:10:25] <hefring> => introduce an options array in the root level of the makefile => Drush Make, Code, normal, needs review, 0 comments, 1 IRC mention
[22:10:26]    <hefring> => PATCH: Allow [working-copy] in makefile as well as on commandline => Drush Make, Code, normal, needs review, 18 comments, 1 IRC mention
[22:10:42]   <mig5>    nice, I saw the working-copy patch update
[22:11:08]    <mig5>    also see Owen's Drush sprint overview here for those interested:
[22:11:29]  * CraHan is now known as CraHan_out
[22:11:52]  <mig5>    ok, scrum done I think, and i'll do the log
[22:11:56] <mig5>    thanks all
[22:12:04]   <omega8cc>    thanks!

Weekly Scrum IRC Log: 2011-07-12

(08:01:34 AM) anarcat: heey scrum time
(08:01:39 AM) anarcat: mig5 / darthsteven : scrum!
(08:01:45 AM) anarcat: omega8cc / sfyn / shrop : scrum time
(08:01:52 AM) anarcat: am i the only one awake? :)
(08:01:59 AM) omega8cc: hello!
(08:02:01 AM) ergonlogic: anarcat: not the *only* one
(08:02:14 AM) ergonlogic: hi all
(08:02:35 AM) anarcat: hello ergonlogic !
(08:02:50 AM) anarcat: so welcome to our weekly scrum
(08:02:52 AM) anarcat: i don't have much to say
(08:02:57 AM) anarcat: i've been away for a while
(08:03:03 AM) anarcat: vacations, drush sprint, etc
(08:03:12 AM) anarcat: i'll try to do a reportback of that great drush sprint soon
(08:03:36 AM) anarcat: but basically, i worked on jenkins, debian packaging and cleaning up the drush bootstrap process to make real unit tests possible
(08:03:49 AM) anarcat: so we can now test *functions* (instead of just commands) in the drush unit test framework
(08:03:53 AM) anarcat: which will be useful for provision
(08:03:54 AM) anarcat: now
(08:04:01 AM) anarcat: how's 1.x doing?
(08:04:14 AM) anarcat: i have on my tuesday todo (and had for a while) to release 1.2
(08:04:27 AM) anarcat: so i'm thinking to test the 1.x debian packages all over the place then just release the damn thing
(08:04:53 AM) anarcat: how does that sound?
(08:04:55 AM) omega8cc: anarcat: there are patches waiting in the queue
(08:05:02 AM) anarcat: ah darn :)
(08:05:05 AM) anarcat: omega8cc: your patches? :)
(08:05:07 AM) omega8cc: ;)
(08:05:10 AM) omega8cc: yep
(08:05:13 AM) anarcat: hehe ok
(08:05:17 AM) anarcat: that shouldn't be a big issue
(08:05:26 AM) omega8cc: simple stuff
(08:05:59 AM) anarcat: ok, so i'll merge that in before release
(08:06:09 AM) omega8cc: thanks
(08:06:09 AM) anarcat: so one last thing for me
(08:06:17 AM) anarcat: i'll be going on a looong holiday around drupalcon
(08:06:33 AM) anarcat: i'm leaving on august 3rd for europe, then going to drupalcon, then i'm gone for september
(08:06:54 AM) anarcat: so that could stall dev of 2.x for a little longer, but i'll be back in full force after that
(08:07:22 AM) anarcat: ah and before i forget: darthsteven: our hosting-queue-runner daemon disappeared here for the first time ever, not sure why, i'll try to track it down today
(08:07:29 AM) anarcat: okay, anyone else has something to add here?
(08:07:45 AM) ergonlogic: For my part, I posted an Aegir extension module on d.o: Hosting Profile Roles
(08:07:50 AM) ergonlogic: ... and I've begun hacking on a couple more
(08:07:55 AM) ergonlogic: And worked on a couple small patches to Drush
(08:08:09 AM) ergonlogic: I've been testing .deb installs on some client VPSs, which has been going smoothly
(08:08:12 AM) omega8cc: not much from me this week, besides fixed support for open public and vudeola
(08:08:33 AM) omega8cc: err, videola
(08:08:52 AM) ergonlogic: ooh, lullabot's published it now?
(08:08:56 AM) omega8cc: yep
(08:09:04 AM) ergonlogic: I'll have to check it out
(08:09:14 AM) omega8cc: and merged my fix already
(08:09:44 AM) Aciid: oh no, videola. I hope it doesn't catch on at the company that we should start offerin sites with it..
(08:09:56 AM) Aciid: videola's performance and seek capabilities are horrible
(08:10:08 AM) Aciid: or maybe it's lullabot's CDN
(08:11:28 AM) anarcat: alright, anyone else?
(08:11:43 AM) ***anarcat notices our gsoc student missing
(08:11:52 AM) anarcat: has he checked in at all while i was gone?
(08:12:13 AM) omega8cc: I didn't notice
(08:12:26 AM) anarcat: that's reallly too bad
(08:12:32 AM) anarcat: i'll have to do an evaluation soon
(08:12:57 AM) ergonlogic: oh, one other things (not to do with our GSoC student), Koumbit is now accepting donations in support of the Aegir Project
(08:13:15 AM) ergonlogic: there's a link on the front page of
(08:14:29 AM) ergonlogic: if/when we receive any donations, we'll have to figure out how to disburse them
(08:14:33 AM) anarcat: ergonlogic: yeah, mig5 wanted to talk about this, actually
(08:14:55 AM) anarcat: ergonlogic: he was suggesting we (koumbit) get a rackspace cloud account and deal with the donations
(08:14:59 AM) anarcat: where are the donations going now?
(08:15:16 AM) ergonlogic: anarcat: Koumbit's PayPal acct
(08:15:23 AM) anarcat: ok, good
(08:15:46 AM) anarcat: alright
(08:15:57 AM) anarcat: so if there's nobody else, that will be it for our weekly scrum!
(08:16:13 AM) ergonlogic: I'll post to the community site
(08:16:28 AM) omega8cc: thanks

Weekly Scrum IRC Log: 2011-07-19

22:00 <@anarcat> alright
22:00 <@anarcat> scrum time!
22:00 <+omega8cc> oh
22:01 <@mig5> I didn't know if it had moved time yet or what :)
22:01 <@anarcat> darthsteven: scrum!
22:01 -!- Irssi: #aegir: Total of 75 nicks [4 ops, 0 halfops, 4 voices, 67 normal]
22:01 <@anarcat> so hi
22:01 <@anarcat> i am not sure what to do about the time
22:01 <@anarcat> steven says he can't attend every week because it's too late
22:02 <@anarcat> mig5: and you seem also to have issue about i
22:02 <@mig5> not ideal for everyone, ever.. maybe we just tolerate a 'rotation' of devs who might not always be here
22:02 <@anarcat> t
22:02 <@mig5> maybe it helps that I never have anything to add... :/
22:02 <@anarcat> well
22:02 <@anarcat> i will be on a holiday for two months
22:02 <@anarcat> so maybe we can flip that around somehow
22:03 <@anarcat> É
22:03 <@anarcat> ?
22:03 <@anarcat> 8hAM london, 5PM melbourne, midnight LA
22:04 <@mig5> we'll see if darthsteven complains about the early start :)
22:04 <@mig5> fine with me
22:04 <@darthsteven> Fine with me
22:04 <@anarcat> 2 am EDT
22:04 <@anarcat> anyways
22:04 <@anarcat> i don't know what to do
22:04 <@anarcat> and i wish somebody else would figure it out basically :P
22:05 <+omega8cc> fine with me too ^^
22:05 <@mig5> it won't ever work until I quit :)
22:05 <@darthsteven> Could we rotate early and late on alternate weeks?
22:05 <@anarcat> we could!
22:05 <@anarcat> and really, we need to keep in mind we don't absolutely need to readjust for seth
22:05 <@anarcat> he was pretty clear about that
22:06 <@darthsteven> So long as it's not too confusing
22:06 <@anarcat> he can (and should) provide feedback in other ways
22:06 <@anarcat> the 8AM is kinda hard on some people here though
22:06 <@anarcat> so anyways
22:07 -!- Chipie [] has quit [Quit: Leaving.]
22:07 <@anarcat> to be clear - i would rather see both of you guys (mig5 and darthsteven) than bring seth back in the loop and loose you :P
22:07 <@anarcat> so i suggest we stick to the schedule at least until i leave for europe
22:07 <@mig5> don't worry too much
22:07 <@anarcat> then you guys can organize as you want
22:07 <@mig5> sure
22:07 <@anarcat> which brings me to
22:08 <@anarcat> somebody should probably take over gsoc mentorship while i'm gone
22:08 <@anarcat> i may have *some* time to followup, but really not a lot
22:08 <@anarcat> i'll be traveling all over the place and I won't be able to prod seth
22:08 <@anarcat> and he needs prodding :P
22:08 <@anarcat> so if somebody could take that over, that would be cool
22:09 -!- redShadow[2V] [] has joined #aegir
22:09 <@anarcat> it's just sending an email from time to time to say "hey what's up" - he's usually pretty responsive
22:09 <@anarcat> i tried to encourage him to document hist stuff on the commmunity site
22:09 <@mig5> ok. I am probably doing the least all round so I will step up
22:09 <@anarcat> and we reoriented his roadmap
22:09 <@anarcat> which he needs to document
22:09 <@anarcat> mig5: awesome!
22:09 <@mig5> if you could brief me in an email on the current status, maybe cc him
22:09 <@anarcat> mig5: i can forward you the relevant communications
22:09 <@mig5> so i'm up to date
22:09 <@mig5> snap
22:09 <@anarcat> hehe
22:09 <@anarcat> cool
22:09 <@anarcat> so that will be it
22:10 <@anarcat> i will probably receive the "hey you need to evaluate this guy" at the end of the program, but we'll cross that bridge when we get there
22:10 <@anarcat> alright
22:10 <@anarcat> now
22:10 <@anarcat> i released 1.2
22:10 <@anarcat> whooohooo!
22:10 <@anarcat>
22:10 -!- romaingar [5d197493@gateway/web/freenode/ip.] has joined #aegir
22:10 <@mig5> thanks for that anarcat, it got a good response
22:10 <@anarcat> omega8cc found what seems to be a critical with the new cron code:
22:11 <@anarcat> i tried to roll out a patch for it and it failed to work, and i'm totally puzzled as to why
22:11 <@darthsteven> Cool
22:11 <@anarcat> i don't see the same issue at all here
22:11 <@mig5> i wondered if it was nginx specific, caching HTTP results
22:11 <@anarcat> and i'm about to give up on it for now, as we don't see the bug at koumbit
22:11 <@anarcat> mig5: s/was/is/
22:11 <@anarcat> the issue is still there
22:11 <@mig5> yeah.
22:11 <@anarcat> so i don't get it
22:11 <@anarcat> the original code *was* broken, but with the patch it should be fine
22:12 <@anarcat>
22:12 <@mig5> it would not be the first time i've seen nginx cache a 404
22:12 <+omega8cc> there is no caching there
22:12 <+omega8cc> none
22:12 <@mig5> 2 days is too much though
22:12 <@mig5> ok
22:12 <@darthsteven> Not sure I have time, but will try to look if I can
22:12 <+omega8cc> just one 403 error locks the queue
22:13 <@anarcat> omega8cc: and you did try the patch?
22:13 <@anarcat> omega8cc: do you see this watchdog entry?         watchdog('hosting_cron', 'cron failed on site %site with error %error', array('%site' => $site->title, '%error' => $response->error), WATCHDOG_NOTICE);
22:13 <+omega8cc> yes, and reported failure there
22:13 <@anarcat> we'll need more juice to figure that one out
22:13 <+omega8cc> yes, it says 403, as before, for site taken offline for maintenance
22:14 <+omega8cc> this should be easy to reproduce
22:14 <@anarcat> ok
22:14 <@anarcat> so anyways, maybe darthsteven will look into it
22:14 <@anarcat> we can talk more about it after the scrum
22:14 <@anarcat> i monopolized the space too long :)
22:14 <@anarcat> otherwise yeah, release++
22:14 <@anarcat> the debian packages kick major asses
22:15 <@anarcat> and we're deploying a bunch of vservers with those
22:15 <@anarcat> so it's fun
22:15 <@anarcat> that's about it for me, anyone else?
22:15 <@mig5> nothing here
22:16 <@anarcat> darthsteven?
22:16 <@anarcat> oh crap, that should be a continue, not a break
22:16 <@anarcat> i'm on acid
22:16 <@anarcat> ffs
22:17 <@mig5> ??
22:17 <@mig5> ah
22:17 <@anarcat> anyways, i have a fix for the cron thing
22:17 <@mig5> haha
22:17 <@darthsteven> I've been on holiday, and not had time to do anything Aegir related
22:17 <@darthsteven> Will do something Aegir related in the next week for sure
22:17 <@darthsteven> Need to check up on our Drupalcon presentation with anarcat
22:18 <@anarcat> darthsteven: any specific time you want to do this?
22:18 <+omega8cc> hah, break does just that - breaks things! lol
22:18 <@darthsteven> anarcat: not fussy about a time
22:18 <@mig5> failed to fail failed :)
22:19 <@darthsteven> anarcat: soon though, as I think they need things from us?
22:20 <@anarcat> yeah, i've been kind of sloppy with this
22:20 <@anarcat> darthsteven: maybe we can talk later today?
22:21 <@anarcat> omega8cc: try cb0c2d2

22:21 <@darthsteven> sure, I'm around for the next 3 hours or so...
22:21 -!- scientist [~scientist@] has joined #aegir
22:21 <@anarcat> ok
22:21 <+omega8cc> anarcat: sure, thanks
22:21 <@anarcat> i think that's it for our scrum unless somebody else wants to kick in...
22:21 <@anarcat> who's it?
22:22 <@anarcat> (who wants to upload the scrum log, that is)
22:22 <@mig5> i'll do it
22:22 <@darthsteven> I can
22:22 <@darthsteven> oh
22:22 <+omega8cc> :)
22:22 <@darthsteven> go for it mig5

Weekly Scrum IRC Log: 2011-07-26

[12:00pm] anarcat scrum time!
[12:00pm] anarcat: hello people
[12:00pm] univate: hello
[12:00pm] anarcat: welcome to our morning weekly scrum
[12:00pm] omega8cc: hi
[12:00pm] anarcat: hey univate what's up
[12:00pm] anarcat: alright
[12:00pm] You left the chat by being disconnected from the server.
[12:01pm] You rejoined the room.
[12:01pm] You were granted voice by ChanServ.
[12:01pm] anarcat: univate: i don't know! 
[12:01pm] anarcat: so our gsoc student is supposed to take care of that, but i didn't get any news from him since the evaluation
[12:02pm] anarcat: which is really too bad
[12:02pm] anarcat: i'll try to ping him by email now
[12:02pm] mig5: anarcat: please send me an email before you go, re GSOC student
[12:02pm] mig5: or cc me on that one ^^
[12:02pm] anarcat: alright, i'll do this right away
[12:02pm] anarcat: other than that, i think that's it for me
[12:03pm] mig5: nothing new from me, all my time atm is taken up by work and study
[12:03pm] anarcat: alright, sounds like me except s/work and study/vacation/ 
[12:04pm] anarcat: mig5: @gmail is okay?
[12:04pm] mig5: sure
[12:04pm] omega8cc left the chat room. (Ping timeout: 240 seconds)
[12:04pm] You are now known as omega8cc.
[12:06pm] anarcat: okay, anyone else?
[12:06pm] anarcat: darthsteven: ping
[12:06pm] anarcat: omega8cc: how are the cron jobs?
[12:07pm] darthsteven: anarcat: pong!
[12:07pm] Irishgringo joined the chat room.
[12:07pm] anarcat: ha!
[12:07pm] anarcat: darthsteven: anything for the scrum?
[12:07pm] anarcat: darthsteven: we need to coordinate for the training and the session
[12:07pm] omega8cc: anarcat: it works great, but it should probably go in 1.3 no? as it is a critical for all users
[12:07pm] darthsteven: nothing for the scrum 
[12:07pm] anarcat: darthsteven: ok
[12:07pm] anarcat: darthsteven: i'm leaving the internets for a while on the 1st, so we would need to coordinate this week... email?
[12:08pm] anarcat: omega8cc: well, not for *all*, the drush method works fine right?
[12:08pm] darthsteven: anarcat: sure
[12:08pm] omega8cc: yeah, so it is critical in 50% 
[12:08pm] anarcat: okay
[12:08pm] anarcat: i don't think i'll be making a 1.3 release now
[12:09pm] anarcat: if someone else wants to, be my guest!
[12:09pm] omega8cc: as long as we have crush method as default, it is fine
[12:09pm] omega8cc: drush
[12:09pm] anarcat: univate: so the d7 port is handled by seth.vincent's sandboxes on, if you want to followup on that it would be great
[12:09pm] omega8cc: uh, Lion autocorrection is crazy
[12:11pm] univate: anarcat: ok i will try and track down what is there
[12:11pm] anarcat: univate: can you give me your mail addy again
[12:14pm] univate: looks like seth.vincents last commits to his sandbox projects were 5 weeks ago
[12:15pm] anarcat: quite possible
[12:15pm] anarcat: he kinda stalled on the project at some point
[12:15pm] anarcat: i'll push him again now
[12:18pm] anarcat: so what's the next scrum time?
[12:18pm] welly left the chat room. (Quit: Textual IRC Client:
[12:18pm] anarcat: i won't be coordinating the next ones until october 1st
[12:19pm] anarcat: so we need someone to take that over, or we suspend those for a while
[12:19pm] mig5: I don't think we agreed on a new time, i'll coordinate with darthsteven / omega8cc
[12:20pm] mig5: if we can't agree on a good time we'll suspend them or rotate people
[12:20pm] anarcat: ok
[12:20pm] mig5: or i'll move to europe 
[12:20pm] omega8cc:                          
[12:21pm] omega8cc: it should be easy to find good time for EU/AU
[12:23pm] mig5: yeah
[12:24pm] jonhattan left the chat room. (Quit: llevaré una chaquete de guns'n'roses)
[12:24pm] anarcat: there was a time proposal here:
[12:28pm] omega8cc: mig5: what time works best for you? morning, evening?
[12:36pm] Egyptian[Laptop] joined the chat room.
[12:40pm] omega8cc: so maybe ?
[12:40pm] mig5: evening usually better for me
[12:41pm] omega8cc: 7, 8 or 9 pm?
[12:41pm] mig5: 8 or 9 is fine, that link above is fine with me
[12:41pm] mig5: let's see what darthsteven says
[12:41pm] omega8cc: k
[12:41pm] anarcat: mig5: ping
[12:41pm] mig5: pong
[12:42pm] q-rban left the chat room. (Remote host closed the connection)
[12:42pm] q0rban joined the chat room.
[12:43pm] anarcat:    
[12:44pm] mig5: that's quite good! when did that appear
[12:44pm] scientist joined the chat room.
[12:45pm] anarcat: i just wrote it
[12:45pm] mig5: nice
[12:45pm] mig5: some of that would be good in the wikipedia page
[12:46pm] mig5: (for those of you who missed it: )
[12:46pm] anarcat: yeah, that's why i wrote it
[12:46pm] mig5:                          
[12:47pm] Irishgringo left the chat room. (Quit: ChatZilla 0.9.87 [Firefox 5.0.1/20110707182747])
[12:47pm] omega8cc: nice!
[12:48pm] mig5: in other news, i rejoined twitter, and now feel dirty
[12:49pm] mig5: and am studying for my OSCP, so if you find I discover any XSS or other holes in aegir, you know why
[12:50pm] scottalan joined the chat room.
[12:51pm] darthsteven: mig5, omega8cc: 10AM UTC is fine with me
[12:52pm] omega8cc: mig5: I already grabbed that book about security thanks to your tweets, so it is a good thing (™)
[12:54pm] omega8cc: darthsteven, mig5: so let's change the scrum time to then for the summer
[12:54pm] darthsteven: agreed

Weekly Scrum IRC Log: 2011-08-02

20:00 <@mig5> ok, scrum time
20:00 <@mig5> as usual, no news from me this week :P
20:00 <@mig5> anarcat is away as we know
20:00 <@mig5> I have not heard from the GSOC student, so I will follow that up
20:01 <@mig5> there are currently no criticals in the queue which is nice, although I have vaguely heard about some issues with the cron queue, someone let me know if that's still an issue
20:01 <@mig5> aaaand I can't think of anything else significant, other than thanks to omega8cc for donating to hefring :)
20:02 <+omega8cc> haha
20:02 <@mig5> go for it darthsteven, omega8cc
20:02 <@darthsteven> I've done a little bit of work on the Aegir session for Drupalcon
20:02 <@darthsteven> hope to have that completed by the end of the week
20:02 <@mig5> oh nice
20:03 <@darthsteven> And then I hope to start writing docs again, but am away on holiday a lot over the next little while
20:03 <@darthsteven> but that's it from me
20:03 -!- aegir-jenkins [] has quit [Ping timeout: 252 seconds]
20:03 <@darthsteven> omega8cc?
20:04 <+omega8cc> I didn't submit any new patches, but I promise I will - related to the UI, soon
20:04 <+omega8cc> also, I released 1.0-boa-T-8.9, and it is using Aegir head
20:04 <+omega8cc> so good for receiving more feedback
20:05 <+omega8cc> and I noticed the sites cron is still an issue on some servers, when web based method is used
20:05 <+omega8cc> I will debug this and post more details soon
20:05 <@mig5> i am tired of this one in the queue: - I have been planning on removing a chunk of code from provision for that for a while, so I might do that in the 7.x branch and see how it goes
20:05 < hefring> => Undefined index: profiles => Provision, Code, normal, needs work, 14 comments, 2 IRC mentions
20:06 <@mig5> it is harmless but people keep carrying on about it
20:06 <@mig5> we have a fresh bug from ergonlogic too
20:06 < hefring> => "View client" permission broken => Hostmaster (Aegir), Code, normal, active, 0 comments, 1 IRC mention
20:06 -!- aegir-jenkins [] has joined #aegir
20:07 <@mig5> aegir-jenkins returns.. that was weird
20:07 <@mig5> it's been up for over 100 days now, \o/
20:07 <@darthsteven> mig5: 1111572, can we set up a test case that invokes that code, remove it and then see if anything breaks/changes
20:07 <+omega8cc> aegir-jenkins: welcome back :)
20:07 -aegir-jenkins:#aegir- omega8cc did you mean me? Unknown command 'welcome'
20:07 -aegir-jenkins:#aegir- Use '!78jujdd7yujufyyshhayuuufhhysjjhyew9i2 help' to get help!
20:07 <@mig5> hah
20:07 <+omega8cc> haha
20:08 <@mig5> oops, and there goes anarcat's clever idea to 'hide' the jenkins command...
20:08 <@darthsteven> hehe
20:08 <@darthsteven> that's genius!
20:08 <@darthsteven> anyone else have anything for the scrum?
20:09 <@mig5> darthsteven: that's the thing re: test case: we don't scan packages in the site-specific dir, which means those values are always null. anyway i promise to look at it
20:09 <@darthsteven> ok
20:09 < Aciid> I have something , never setup a VM with Amazon AWS
20:09 <@mig5> ok, scrum done, unless ergonlogic has anything to add
20:09 < Aciid> - mail sent by Amazon
20:10 <+omega8cc> so, thanks for attending!
20:10 <@mig5> cheers

Weekly Scrum IRC Log: 2011-09-13

[20:15:26]  <@darthsteven>  Scrum time
[20:15:30]  <@darthsteven>  at last!
[20:15:49]  <@mig5> yeah sorry about that
[20:15:52]  <@mig5> i have neglected it a bit
[20:16:14]  <@darthsteven>  ping: darthsteven, mig5, ergonlogic, grugnog, mvc, omega8cc, sfyn, skwashd (time for a scrum!)
[20:16:23]  <@darthsteven>  mig5: I kept forgetting to have them!
[20:16:33]  <@darthsteven>  do you want to go first?
[20:16:52]  <@darthsteven>  mig5: do you want to go first?
[20:17:04]  <@mig5> sure, that's easy: i've done nothing as usual
[20:17:06]  <@mig5> :)
[20:17:09]  <@omega8cc> lol
[20:17:13]  <@mig5> sigh
[20:17:26]  <@mig5> i want to look at getting those jenkins tasks into provision, but i haven't begun
[20:18:18]  <@mig5> i have built some cool automatic deployments using jenkins + aegir, all tracking changes in git, which i want to screencast soon
[20:18:28]  <@mig5> zero-touch deployment of dev > stage > live, good fun
[20:18:36]  <@darthsteven>  mig5: awesome!
[20:18:39]  <@mig5> anyway, that's me..
[20:18:57]  <@darthsteven>  mig5: Thanks!
[20:19:08]  <@darthsteven>  omega8cc: anything from yourself?
[20:19:27]  <@omega8cc> I already forgot what I did in the last few weeks :p but it was something, I'm sure! seriously, I probably helped with some drush issues and now working on a new theme, including mobile version for hostmaster
[20:19:46]  <@mig5> ooer
[20:19:53]  <@darthsteven>  cool! (the theme stuff, not forgetting things)
[20:20:21]  <@darthsteven>  omega8cc: anything else?
[20:20:50]  <@omega8cc> and the app for iOS and Android maybe is in the works, leveraging Aegir api where possible
[20:21:11]  <@omega8cc> but it is an Apple-like secret! lol
[20:21:44]  <@darthsteven>  heh, well the scrum logs don't get published anywhere ;)
[20:21:56]  <@omega8cc> but first, I will submit some simple UI related patches for the current theme
[20:22:02]  <@omega8cc> haha
[20:22:26]  <@omega8cc> I have some problems with it
[20:22:56]  <@omega8cc> I don't want to include ctools and stuff just to override some blocks, for example
[20:23:12]  <@omega8cc> so some patches will need to hit the core instead
[20:23:19]  <@omega8cc> I mean hostmaster
[20:23:40]  <@darthsteven>  omega8cc: ok, well I reckon we might end up with ctools in 7.x-2.x before long anyway
[20:23:58]  <@darthsteven>  because I want views in there :)
[20:24:09]  <@darthsteven>  omega8cc: anything else?
[20:25:06]  <@omega8cc> features_extra requires ctools, but we could too easily end up with fatcore instead of smallcore then
[20:25:08]  * skwashd stands up
[20:25:46]  <@omega8cc> so, features are nice, but always
[20:25:58]  <@omega8cc> but not* always, err
[20:26:28]  <@omega8cc> and that is it from me, I guess
[20:27:10]  <@darthsteven>  cool, thanks for the work on Aegir, as always
[20:27:17]  <@darthsteven>  skwashd: do you want to go next?
[20:27:45]  <@skwashd>  darthsteven: i have done 50% more work than mig5 on the same tasks as he has
[20:27:58]  <@skwashd>  darthsteven: and i plan to double my efforts on that task this week
[20:28:23]  <@mig5> that sounds believable
[20:28:30]  <@omega8cc> haha
[20:28:31]  <@darthsteven>  skwashd: sorry, what task was that?
[20:28:39]  <@mig5> trolling
[20:28:43]  <@skwashd>  darthsteven: doing fuck all for aegir
[20:28:46]  <@darthsteven>  heh
[20:29:07]  <@darthsteven>  well, thanks for keeping us in the loop :)
[20:29:16]  <@darthsteven>  skwashd: anything else?
[20:29:22]  <@skwashd>  mig5: i said i'd only done 50% more than you ... if we're talking about trolling there would be another 0 in there :P
[20:29:41]  <@darthsteven>  moving on...
[20:29:45]  <@darthsteven>  I'll go next
[20:29:46]  <@skwashd>  darthsteven: no
[20:30:06]  <@darthsteven>  I fixed an issue with PHP 5.2 and Drupal 7.8
[20:30:50]  <@darthsteven>  I've asked about spinning the theme out of hostmaster, back into it's own project
[20:30:51]  <@hefring> => Spin Eldir back out to its own project => Hostmaster (Aegir), Code, normal, needs review, 0 comments, 1 IRC mention
[20:31:17]  <@darthsteven>  I built a 'harness' for testing Eldir for Drupal 7:
[20:31:37]  <@darthsteven>  I.e. it's a 'port' of Hostmaster's HTML output for D7
[20:32:09]  <@darthsteven>  finally I have ported Eldir to D7:
[20:32:23]  <@darthsteven>  building on the work of Seth (SoC student)
[20:33:00]  <@darthsteven>  I think I've also fixed various little things in Aegir and tried to process the queues a little
[20:33:42]  <@darthsteven>  Future plans are to possibly make the 7.x-2.x branch actually use D7, and begin the porting...
[20:34:05]  * beautifulmind has joined #aegir
[20:34:15]  <@darthsteven>  that's it from me
[20:34:22]  <@darthsteven>  anyone else?
[20:36:20]  <@darthsteven>  I'll give them a minute...
[20:37:46]  <@darthsteven>  </scrum>
[20:37:51]  <@darthsteven>  Thanks everyone!

Weekly Scrum IRC Log: 2011-09-20

20:01 <@darthsteven> scrum in 1 minute!
20:02 <@darthsteven> mig5, mvc, omega8cc, sfyn, skwashd; scrum in 1 min
20:03 <@darthsteven> scrum time!
20:03 <+omega8cc> hello!
20:03 <@darthsteven> scrum?
20:03 < hefring> scrum is Every Tuesday at 10h00 UTC: 03h00 San Francisco, USA (PST), 06h00 Montreal, Canada (EDT), 11h00 London, UK (CET), 20h00 Melbourne, Australia 
20:03 <@darthsteven> indeed it is hefring
20:03 <@darthsteven> botsnack
20:03 < hefring> skynet thanks YOU!
20:03 <@darthsteven> who wants to go first?
20:04 <@mig5> just made it..
20:04 <@darthsteven> mig5: Hello!
20:04 <@mig5> you go firsst, you have been on fire in the queue!
20:05 <@darthsteven> I fixed some issues that were in the queue, and worked on the site form a little
20:05 <@darthsteven> Hopefully we can now handle database passwords that include special characters
20:05 <@darthsteven> though we may be chasing that one around a few more dark corners yet
20:06 <@darthsteven> I'd like some feedback about the site form changes (which are in a dev branch)
20:06 <@darthsteven> the issue is...
20:06 <@darthsteven>
20:06 < hefring> => Clean up the hosting form javascript => Hostmaster (Aegir), Code, normal, needs review, 2 comments, 1 IRC mention
20:06 <@darthsteven> I would really appreciate some reviews of that
20:07 <@mig5> i never understood any of that as i don't grok javascript - i'm glad you're tackling it
20:07 <@darthsteven> It's basically just adding an AJAX spinner, so you know that something is happening...
20:07 <@mig5> so i'm not sure how helpful i can be there but hopefully others..
20:07 <@mig5> ah right
20:07 <@darthsteven> even just a test and 'I like the look of that' or 'Can we do this' would be helpful
20:08 <@darthsteven> Also
20:08 <@darthsteven> I installed Drupal 8 using Aegir last night, and it worked!
20:08 <@darthsteven> which isn't a major surprise, but it is fun
20:08 <@darthsteven> that's it from me
20:08 <@darthsteven> who wants to go next?
20:09 <@mig5> nothing from me, i see you want to add some drupal8 tests into jenkins, i can do that
20:09 <@mig5> still way too busy right now to look at moving tests into provision
20:09 <@mig5> hopefully more time early october when i go full-time consultant
20:10 <@darthsteven> mig5: do you have time for a quick chat after the scrum about Aegir stuff?
20:10 <@mig5> should do, it's either you or dinner, whatever happens first
20:10 <@mig5> :)
20:11 <@darthsteven> mig5: been thinking about the tests stuff, have some ideas and thoughts about it...
20:11 <@darthsteven> mig5: anything else to add?
20:11 <@mig5> nope, other than to say thanks to you specifically for working the issue queue like a nutter this week
20:11 <@darthsteven> mig5: thanks for coming to the scrum even if you don't have much to report!
20:11 <@mig5> keep it up but don't burn out :)
20:11 <@darthsteven> mig5: these are my normal levels of involvement in projects... :)
20:12 <@darthsteven> anyone else have anything for the scrum?
20:12 <+omega8cc> I don't have anything new related to the Aegir core this week to report, however I worked on some BOA new features and there is a chance I will submit some new patches for Nginx config (and finally) the menu/UI.
20:12 <+omega8cc> darthsteven: and also thanks for your work in the queue!
20:12 <@darthsteven> omega8cc: awesome!
20:13 <@mig5> omega8cc: i expect to hear you move into Linode Tokyo soon ;)
20:13 <@darthsteven> omega8cc: I think we should make tiding up the UI a priority for 2.x
20:13 <@mig5> sorry offtopic
20:13 <@mig5> apparently there was a drupal montreal on
20:13 <@darthsteven> anyone else?
20:13 <@mig5> i read some french tweets about it
20:13 <@mig5> something about an 'albert method', a guy from koumbit did a talk
20:14 <@mig5> i am keen to find out more, there are slides somewhere, search on twitter under #aegir
20:14 <@mig5> i think it's deployment-related, i'll see if i can find out more and get some english-language focus on it as it looked interesting
20:15 <@darthsteven> cool
20:15 <+omega8cc>
20:15 <+omega8cc> or!/omega8cc/status/114783126844223488
20:16 <@mig5> oh nice already in english
20:16 <+omega8cc> yep
20:16 <@mig5> again, soon, i will have a new screencast up
20:16 <@mig5> about my 'zero touch' deployment for aegir
20:16 <@mig5> using jenkins
20:16 <@mig5> that 'reacts' to git push in de/v/stage/live environments
20:16 <@darthsteven> mig5: cool, have you seen that someone is doing screencasts of Aegir stuff?
20:16 <@mig5> that will come 'soon' ;)
20:16 <@darthsteven> mig5: that would be awesome
20:16 <@mig5> darthsteven: yes i did, i watched one
20:17 <+omega8cc> mig5: cool! finally! :)
20:17 <@darthsteven> mig5: I've not watched I've no idea if they're any good
20:17 <@darthsteven> To finish the scrum, I'd like to say...
20:18 <@darthsteven> that we seem to have had a bump in contributors, which is really cool!
20:18 <@mig5> yes! rock on, patchers!
20:18 <@darthsteven> There are also a few people who've started using Aegir, and are now blogging about the project
20:18 <@mig5> thanks GuyPaddock and halcyonCorsair
20:18 <@darthsteven> The 'Wedful' thing springs to mind
20:19 <@mig5> yes and hadsie, i think that was the first commercial 'payment' aegir system that implemented our api
20:19 <+omega8cc> right
20:19 <@darthsteven> So, with a bit of effort we make Aegir 2.x happen fast, and be super awesome in every way!
20:19 <@darthsteven> anyway
20:19 <@darthsteven> that's it for this scrum!
20:19 <@mig5> the pantheon project is getting a lot of publicity right now, i am keen to see people publish 'how to make your own pantheon' with aegir :)
20:19 <@mig5> just to balance things out :)
20:19 <@mig5> thanks scrummers
20:19 <@darthsteven> Thanks for attending
20:19 <+omega8cc> thanks
20:19 <@darthsteven> who wants to do the log thing?
20:20 <@mig5> i can
20:20 <@darthsteven> thanks!

Weekly Scrum IRC Log: 2011-09-27

[10:02am] darthsteven: mig5, ergonlogic, grugnog, mvc, omega8cc, sfyn: scrum time!
[10:02am] omega8cc: hello!
[10:02am] darthsteven: Welcome to our weekly Aegir Scrum
[10:02am] darthsteven: Who would like to go first?
[10:03am] merro left the chat room.
[10:04am] darthsteven: omega8cc: would you like to start us off?
[10:04am] beautifulmind joined the chat room.
[10:05am] omega8cc: darthsteven: all my nginx related new stuff is a bit delayed as it needs more testing
[10:05am] omega8cc: so I didn't submit any patches yet, but I hope to be able to do it this week
[10:06am] omega8cc: also new boa release has been delayed for this reason
[10:06am] darthsteven: okay
[10:06am] darthsteven: well, looking forward to reviewing those bits
[10:06am] merro joined the chat room.
[10:07am] darthsteven: anyone else?
[10:08am] darthsteven: I'll go next then
[10:08am] darthsteven: I factored out the Jenkins tests to a drush command in provision
[10:09am] darthsteven: so we can run them locally without python or Jenkins
[10:09am] darthsteven: which is nice
[10:09am] omega8cc: wow
[10:09am] darthsteven: We can also have different tests for the different branches now too
[10:10am] darthsteven: the tests are pretty basic, as we'll be using the Drush testing framework in a bit, when Drush 5 is out, but for now they're pretty basic
[10:10am] darthsteven: also
[10:10am] dfrt:  /t
[10:10am] darthsteven: I made the Jekins scripts use configuration from Jenkins, rather than new code in the repo
[10:11am] darthsteven: so we can do releases much more easily
[10:11am] darthsteven: speaking of which
[10:11am] darthsteven: We release 1.4 
[10:11am] darthsteven: *released
[10:11am] darthsteven: Fixing a security issue
[10:11am] darthsteven: Also
[10:11am] darthsteven: I created the 6.x-2.x branch, which was where the 7.x-2.x branch was
[10:11am] darthsteven: because...
[10:12am] darthsteven: 7.x-2.x now contains Drupal 7 code!
[10:12am] darthsteven: hurrah!
[10:12am] darthsteven: Porting is underway
[10:12am] omega8cc:
[10:12am] darthsteven: I was going to let everyone know via the community site, but couldn't because that had issues with the OA upgrade that was forced upon it
[10:12am] darthsteven: I will do that today though
[10:14am] omega8cc: darthsteven: so, is our gSoC student work/idea already cancelled, I suppose? as you are doing it currently
[10:14am] darthsteven: omega8cc: As far as I can tell, nothing really came of that
[10:14am] omega8cc: yeah 
[10:15am] darthsteven: we can always get him porting one of the modules if that's not the case
[10:15am] darthsteven: gSoC is over afaik anyway
[10:15am] darthsteven: Anyone else want to say anything?
[10:15am] omega8cc: so we may want to update our room header
[10:20am] szczym left the chat room. (Read error: Operation timed out)
[10:22am] omega8cc: darthsteven: Thanks for leading the work and our scrum! I can submit the log to c.a.o if you wish
[10:22am] darthsteven: end of scrum!

Weekly Scrum IRC Log: 2011-10-18

[21:00:33]  <@darthsteven>  anarcat, darthsteven, mig5, mvc, sfyn, skwashd: Scrum time!
[21:10:03]  <@mig5> sorry, nothing to report
[21:12:45]  <@darthsteven>  ok
[21:12:47]  <@darthsteven>  thanks!
[21:13:16]  <@darthsteven>  I applied some nasty patches to get the debian package installing correctly with drush 4.5
[21:13:46]  <@darthsteven>  I also got to the bottom of the problem when installing on debian, where it would consume all CPU and memory
[21:13:52]  <@darthsteven>  which anarcat then fixed!
[21:13:53]  <@mig5> excellent. do we need to roll a new release for that drush issue?
[21:14:57]  <@darthsteven>  I think we do
[21:15:08]  <@darthsteven>  I was going to add an issue to the queue
[21:15:20]  <@darthsteven>  See if we can do a release without anarcat :)
[21:15:58]  <@mig5> :)
[21:20:50]  <@darthsteven>  anyone else?
[21:21:06]  <@darthsteven>  speak now, or hold until next week...
[21:21:29]  <@darthsteven>  oh, and I just posted about changing the times of these:
[21:36:06]  <@darthsteven>  okay
[21:36:13]  <@darthsteven>  official end of scrum there

Weekly Scrum IRC Log: 2011-11-01

[21:00:57]     Scrum time!
[21:01:00]     scrum?
[21:01:00]     scrum is Every Tuesday at 10h00 UTC: 03h00 San Francisco, USA (PST), 06h00 Montreal, Canada (EDT), 11h00 London, UK (CET), 20h00 Melbourne, Australia (EST)
[21:01:08]    go!
[21:01:19]     shall I go first?
[21:01:26]     okay, if you insist
[21:01:40]     Aegir 1.5 is out!
[21:01:42]     Hurrah
[21:01:47]    \o/
[21:01:57]     Anarcat helped in advisory role
[21:02:17]     which means at least two people can complete the full release process, independently
[21:02:26]    excellent
[21:02:50]     and we found that Jenkins actually does most of the work, and we could get it to do most of the rest of Debian stuff very easily
[21:02:57]     other things:
[21:03:10]     I did some bug fixes
[21:03:29]     I completely re-factored the 6.x-2.x branch of provision to use autoloading for classes
[21:03:41]     so we can support contrib add-ons for provision
[21:03:51]     I still need to document those changes
[21:04:01]     will try to get a few mins to do that today
[21:04:31]     also, I increased the number of things tested by Jenkins, and improved the quality of the code running the tests a little
[21:04:44]     resulting in less code all round :)
[21:05:05]     Also, made the upgrade tests take parameters
[21:05:09]     which is handy
[21:05:29]     also we now test PHP 5.2, every 24 hours if there are changes
[21:05:32]     that's it from me
[21:05:39]     mig5 want to go next?
[21:05:48]    ok - incredible efforts as always darthsteven, thanks
[21:05:52]    that's amazing work
[21:06:20]    me - very little as always - i simply built a new debian squeeze image with backported php 5.2 from lenny, so that we could do those php 5.2 tests
[21:06:57]    i'm pondering giving an aegir talk at in January 2012, only a couple monts away now, but i'd like to diverge away from the usual 'how to install aegir, basic usage' thing we always do, as a lot of people will have seen that
[21:07:08]    any suggestions or ideas, let me know.
[21:07:11]    that's about it from me
[21:08:10]     mig5: thanks as always
[21:08:47]     anyone else?
[21:09:00]     mig5: we can chat talks after the scrum?
[21:09:23]    sure
[21:10:13]     anyone else? I'll give you a minute!
[21:11:31]     okay
[21:11:36]     thanks for attending mig5
[21:11:37]    i'll do log