After creating a new site in an Octopus instance, I went to the command line and ran drush sa to get a lit of site aliases. It retuened the following:

o1.ftp:/data/disk/o1/static/example-dev-pressflow-22-14102011$ drush sa

I thought it was odd that they didn't show the @ symbol infront of them like they usually do with Drush, but it did list three aliases non the same. The actual name of the site was, and and were aliases for the site that I set up in aegir.

I then created a file at ~/.drush/live.example.alias.drushrc.php with a drush alias definition to a currently live version of this site which lives on a remote server, since I intended to use drush sql-sync and drush rsync to pull across the database and files. However, after creating that alias file, `drush sa` now only returns one alias:


^ the one that I manually added. So the aliases that were provided by Aegir have somehow disappeared by the simple fact of me adding a custom aliases file.

Soin ~/.drush there are only 2 things - the alias file I created, and the symlink to drush make). I tried removing my alias file and running rush sa again, but then no aliases were listed.

Is Octopus set up to work with Aegir's site aliases? Has it ben tested in combination with custom site aliases added in a similar fashion to how I added this one?


Status:Active» Closed (works as designed)

Octopus standard user with limited shell can't use drush aliases, at least not yet, because of the 'by design' separation of Aegir system user o1 and webmaster user with limited shell o1.ftp. If you wish to use Drush aliases remotely, you must give the system user o1 a valid shell and then use it instead of o1.ftp user.

Status:Closed (works as designed)» Active

If you change into the platform root, and then run sa you get different results:

o1.ftp:/data/disk/o1/static/example-dev-pressflow-22-14102011$ drush sa

There, it has the correct site alias for the one that I added manually, as well as the three site aliases for the Site that's in Octopus. Though, still those don't show the @ symbol in front of their names.

Status:Active» Closed (works as designed)

Closing per comment #1.

We plan to add Drush aliases support for limited shell users in the future, just no ETA is known yet.

Category:support» feature
Status:Closed (works as designed)» Postponed

Let's change it into feature request.

Does this mean that something like running drush sql-sync on my local machine - to clone the database on the aegir server - has no chance of working? I'm running drush sql-sync @prod @dev and I can't figure out if it's not allowed or if I've just configured it wrong.


You can use this only via your Octopus system user (by default o1) after adding a valid shell (by default this user has no shell). You can't use drush aliases remotely (or even locally on the Aegir server) with your limited shell user (by default o1.ftp) because this user doesn't have an access to system user (o1) environment.

By the way, using things like drush sql-sync @prod @dev is totally against entire Aegir idea and best practices. You need to think the Aegir way to leverage its power and forget about using such Drush pseudo-shortcuts.

Well, please point me in the right direction; is there a good tutorial for how to clone sites for local development? @dev is my local environment, btw - I don't particularly want to maintain code using vim.

Here are some things to note and remember to avoid confusion:

1. Aegir doesn't support (yet, but there is a feature request for it already) migrating sites between hostmaster instances/servers.
2. You should never bypass Aegir system with running manually Drush commands like drush sql-sync.
3. It is not a good idea to develop in different environment than your server environment.
4. If you have the same environment on the server and localhost (like BOA), create a backup on the server and import it on localhost.

The how-to for site's import:

Some good starting point for best workflow/practices:

Status:Postponed» Needs work

To make it more clear: you *can* use drush aliases, both remotely and locally on the BOA server, but when you are logged in as a limited shell user, you don't have an access to drush aliases managed by Aegir backend, so you would need to create your own aliases, as explained in this article. Of course it is less than ideal, but it is possible.

However, maybe we could automate this somehow, so drush aliases from /data/disk/o1/.drush would be automatically available in /home/o1.ftp/.drush and similarly for all extra clients/users. We just need to figure out how to sync them between those accounts, so I'm changing the status here.

Status:Needs work» Postponed

Would be nice to be able to download the drush alias via sites list in aegir

I have a drush command that is able to fetch drush aliases from a remote aegir server. This allows you to run a simple command to fetch a working remote drush alias from your aegir server:

drush fa

This will fetch a drush alias for directly from Super handly if you are using aegir as part of a continuous integration setup where the aliases change after every deployment.

thanks for sharing mrfelton !

is it possible to get a drush alias file that has ALL sites?

also, quite interested in the Aegir CI workflow...

QUESTION: do you develop on localhost in Aegir? or do you have single-site/single-codebase (non Aegir) localhost dev and upload of sites folders into Aegir only?

Our current fetchalias command only handles fetching a single aegir site alias. One day I'll add the ability to fetch all aliases (patches welcome!)

Essentially, the workflow that we use at SystemSeed is very similar to the setup that mig5 describes in - Jenkins+Aegir+Selenium based Continuous Integration. We have a remote Jenkins server, that builds onto a separate remote aegir master, which then pushes sites out to a cluster of dev/stage/production servers.

We sync from dev/stage/live back to local for development. We Commit to -dev branches of our platform, which triggers Jenkins builds and aegir site migrations. Then we merge to -stage and then onto -live branches, which also trigger Jenkins platform builds and site migrations against the respective environments and sites.

With constant platform builds and site migrations happening, our aliases on the aegir server change frequently - making our drush fetchalias command essential for effective development workflows.

thanks for the info.

btw, have you looked at Aegir DevShop / Valkyrie ?

Version:» 6.x-2.x-dev
Status:Postponed» Fixed


is this the mig5 workflow of which you type?

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.