Four tips for developing Drupal under Aegir
If you’ve fallen under the spell of mig5 (aka Miguel Jacq) and moved your Drupal deployment workflow to drush, drush_make, Aegir and git you might have been scratching your head over how to carry over your normal development workflow. Here’s four tips to help you along. Note that all commands presume a Debian/Ubuntu style OS.
1. Master the cache
Aegir hard codes Drupal cache to ’normal’. Let me repeat that. Aegir hard codes Drupal cache to ’normal’ or in other words ‘on’ in in settings.php. You can’t change cache settings via the UI. This is of course disastrous when you’re developing a new site, particularly when it comes to theming.
Thanks to a tip from macrocosm and omega8cc we can turn this problem into a feature. Aegir keeps a global configuration file for all sites at /var/aegir/config/includes/global.inc. With a consistent sub domain naming scheme and some regex you can force all development sites to cache ‘off’:
$thishost = $_SERVER[HTTP_HOST];
if(preg_match("/(-dev\.perlucida\.com)/", $thishost)) {
$conf['cache'] = '0';
}
All my development sites are on sitename-dev.perlucida.com the code above hardwires cache to ‘off’ – exactly what we need for development phase. Of course as soon as the site is migrated (with Aegir) onto a staging or live domain the cache is on!
There’s potential here I haven’t yet explored fully. There’s several features it would be nice to automatically turn on when going live, off during development.
2. Stay in touch with your VCS repository.
Use drush’s –working-copy flag when building platforms with drush_make and the VCS tracking folders will be left intact (.git, .svn etc):
php /var/aegir/drush/drush.php --working-copy make /var/aegir/builds/myplatform.build /var/aegir/platforms/myplatform_20100218-01
Now you can commit changes back to your repo ready for the next platform build to pick them up. Even for live sites this means hotfixes you make can be pushed back to the VCS repo and automatically included by drush_make in the next platform build.
3. Give Aegir your keys
Update: if you’re only wanting to edit module and theme files see mig5’s comment no 2 below before reading on.
You’ve moved in with Aegir, isn’t it about time you gave him some keys?
I have lots of lovely gui desktop editors and sftp clients that I use during development – Forklift, YummyFTP, BBEdit, Textmate, Espresso, CSSEdit and so on (Yes that’s a lot. I know. I’m fickle.) – and one of the first issues I had was using those applications via ssh/sftp on code ‘remotely’ which was ‘owned’ by Aegir.
To cut a long story short the best thing to do is provide aegir with your ssh public key. But how to transfer your key? Aegir doesn’t have a password set and being a good sysadmin you’ve probably already locked down ssh, disallowed passwords and only allow login with public keys. Faff about with enabling and setting passwords? No thanks. You already have an account on the server with your public key – your own – so the quick and dirty solution is to copy your ~/.ssh/authorized_keys file to /var/aegir/.ssh (check that /var/aegir/.ssh and authorized_keys don’t already exist) like this:
sudo cp /home/adrian/.ssh/authorized_keys /var/aegir/.ssh
sudo chown aegir:aegir /var/aegir/.ssh/authorized_keys
sudo chmod 600 /var/aegir/.ssh/authorized_keys
At this point, if you’re wise, you’ll inspect this freshly copied authorized_keys to make sure there are no keys present Aegir doesn’t need.
But wait! We still can’t login as the aegir user with our desktop software, first we need to give the aegir user a shell. By default the aegir user is created without a shell:
sudo more /etc/passwd
$: aegir:x:112:120::/var/aegir:/bin/false
Lets change aegir’s shell:
sudo chsh -s /bin/sh aegir
sudo more /etc/passwd
$: aegir:x:112:120::/var/aegir:/bin/sh
Sweet. Now configure your desktop clients/editors to access the server as user aegir and using ssh keys and edit away.
4. Backup!
Ever find yourself during a site build installing a module, testing it, making changes to your site to integrate it – and then deciding it’s not fit for purpose? Aegir has a wonderful 1-click backup. If you get into the habit of doing a backup before making a set of changes then Aegir’s 1-click restore is a great way to rewind.
Last words
I’ve barely started using Aegir, drush, drush_make and git, I’m sure there’s much more to discover and with the whole suite of software under active development there’s always more to learn. I hope these help you along and please share your own tips in the comments.
Great little blog post. Bookmarked :)
Thanks for taking the time to jot these down.
One of the little-known changes we made about a release or two ago so that one can avoid having to give the aegir user a shell, is to make certain folders writable by the group (the ‘aegir’ group).
These folders inside a platform include:
The intention here is, and especially if you have multiple developers working on a project, that you create regular accounts for your users, i.e ‘miguel’ or ‘adrian’, and all you need to do is add those users to the ‘aegir’ group.
This means those users can write files inside those site dirs provisioned or managed by Aegir, i.e for theme development and so on, and the ‘aegir’ account really does become a ‘system’ account simply for use by the Aegir system itself.
Great article Adrian!
@mig5 Nice to know, I was vaguely aware of that. As far as I can tell that also extends to sites/all/modules, sites/all/themes and sites/all/libraries.
What happened when I tried editing as another user before was that file ownership changed – I see it doesn’t now! Nice! Not that file ownership isn’t easily changed with chown, but ‘it just works’ is clearly better. That does weaken the argument for tip number 3.
On the other hand I suppose if you’re hacking on Aegir itself, or editing anything else in the aegir filesystem (vhost template files come to mind) giving aegir your public key could still be useful.
In my case I’ve only done this on a virtual machine sitting behind my firewall, and since it’s running Ubuntu the aegir user gets the dash shell – which we’re well aware has limited capabilities. For me I still think veering slightly away from security best practice is worth the trade off in easy workflow, at least on my development system.
Thank you very much for the pointers Adrian.
With regard to the first tip, your regex caters for cases where you create subdomains that end in “-dev” on a valid domain.
I have been able to set up a local development server with wildcard second level domains ending on a fictional top level domain “.dev” (E.g. drupal6.dev, awesome.dev).
I have no clue about regex but going with your example I assume that the following would work for such domains, including any subdomains.
@whatdoesitwant I’m no regex expert, but you’d need to escape the period in the dev:
Facepaw. Escaping does the trick, thanks!
I keep running into permissions problems when using git under the aegir user. How do you use git with aegir?
Thanks for the article, very helpful.
@gmclelland
- Platform builds are made running drush_make as the aegir user, so code is checked out of repositories as aegir.
- I use git whilst logged in as the aegir user.
- I’ve also generated ssh keys for aegir for public key access to my gitosis based repositories. So I can pull and push as aegir.
Basically I do everything as aegir if I’m working in /var/aegir.
One of the issues that you run into in using multiple developer accounts instead of the aegir user is that debian’s default umask is 0022, which means folks just in the aegir group have no write permissions to files. You can change this on debian so that new files will be group writeable by changing the default umask to 0002.
However, drush downloading code from drupal.org and untarring it will still be creating stuff with no group write permissions, making lots of little unwriteable ghettos accross your codebase.
We’ve just gone the route of having folks logged in as the aegir user, but I could see the need here for a drush plugin to set group write permissions of downloaded code.
This is a great explanation of some of the different ways of doing things the “Aegir way”.
If you are using the —working-copy flag with drush, you really should add some extra directives to your apache configuration to prevent your VCS repo information leaking.This article in Russian (English translation) explains how to avoid the issue with SVN directories on apache, it can be expanded to deal with git.
Doesn't Drupal's default .htaccess deal with this? Aegir may not use .htaccess files but still uses the same code AFAIK.
I couldn't reach anything checked out from VCS on my own server.
Just installed a new dev server with aegir 0.4-beta1 on debian lenny with php 5.3.3 over dotdeb. I noticed that HTTP_HOST now requires quotes:
point 1) will be erased within the next aegir release … it seems the responsible line was removed:
http:// git.aegirproject.org/?p=provision.g…
@Georg Yeah there was a whole issue about the hard coded cache: http://drupal.org/node/984396
This post is nearly a year old, not surprising that it’s starting to get out of date, but thanks to everyone for keeping it up to date with comments!
@Georg though of course you can then just reverse point 1, and use it to turn hard coding back on :)
No. 1’s disabling cache trick works for Drupal-7 too \o/
Until the next aegir release.
Ack! I thought that you had solved my permissions woes, but I’ve been done in once again! I thought I was in the clear with what you’ve described above… except that we’ve adopted the workflow found here. That means that my theme is in the profiles directory, and not the directory for the site. A quick check revealed that I do not have write access for theme directories in that are inside the profiles directory.
Any chance that could change in the future?
To be more clear, the aegir group does not have write access to themes inside the profiles directory.
@ ldweeks Sounds like a feature request, maybe you should add an issue: http://drupal.org/project/issues/provision…
@Adrian: Thanks for the idea. Did it just now: http://drupal.org/node/1107948
Nice article !!
How to upgrade the sites in aegir form one platform to another.
Example - Currently latest version is of drupal-6.22 and earlier was drupal-6.20.
while we upgrade the aegir it provides a new pack known as platform, there is no interface/ feature to upgrade existing sites of aegir from one platform to another.
RE: 1. Master the cache.
It looks like that issue has been resolved: http://drupal.org/node/984396#comment-4014626 and included in the Aegir 1.0 release: http://community.aegirproject.org/1.0#Majo…