I've 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':
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):
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 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:
$: aegir:x:112:120::/var/aegir:/bin/false
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:
sites/$sitename/modules sites/$sitename/themes sites/$sitename/libraries
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.
$thishost = $_SERVER[HTTP_HOST]; if(preg_match(“/(.dev)/”, $thishost)) { $conf[‘cache’] = ‘0’; }
@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.
Post new comment