At Koumbit, we have lots of developers working on many different sites, which reside on several different platforms. We have a dedicated person who handles platform updates, and migrates sites to the new platforms once every week or two.

A recurring problem, is that after a site is migrated to a new platform, developers can't find the code-base anymore, and have to go search amongst our various platforms to find it. Now, admittedly, I think we could simplify how we manager our platforms...

But still, this is a gripe I hear fairly frequently. Now admittedly, you can find this by running `drush @site-alias status` and looking under `Drupal root`. But maybe we could create /var/aegir/sites folder, and maintain symlinks to the various site directories as sites are created and migrated.

Comments

joestewart’s picture

We've been using a /var/aegir/sites directory with symlinks to the correct example.com directory for awhile now. The basic code came from Omega8.cc's previous method of vhost setup for Nginx. After the aegir services rewrite I got as far as creating the symlinks again. But I haven't added the symlink deletion if a site is deleted. I uploaded the current code to a sandbox - http://drupal.org/sandbox/joestewart/1076180

anarcat’s picture

What I hope to do (this week?) is to have a clients/site hierarchy, so you would have:

~/clients/koumbit/koumbit.org
~/clients/koumbit/alternd.com
~/clients/aegir/community.aegirproject.org

~/clients/koumbit would be a directory, and within it symlinks to all sites for this client. ~ is /var/aegir or whatever your aegir home is.

Would that answer your requirement?

BTW, shell/SFTP homes could have symlinks that would point to accessible clients the same way:

~anarcat/clients/koumbit

would be a symlink to ~/clients/koumbit...

anarcat’s picture

Priority: Normal » Major

@joestuart - a good start! I would add another layer of indirection for the groups/clients, now that we have unix-valid names for clients...

also, that's not the right hook. :) you want post_provision_install, post_provision_verify and post_provision_delete... grep around provision for example.

this could easily be patched into 1.0 in time for the release, bumping up.

anarcat’s picture

Also - don't hardcode /var/aegir.

joestewart’s picture

:) I just looked at the code and farther down I'm not hardcoding it. I cringed and it jumped out at me too. This came from a previous proof-of-concept to get input from designers and their usage. They like this type of thing by the way.

We currently don't have a need for the client portion but would be more robust with that support. We just need to remember the goal is for them to be easy to find.

anarcat’s picture

Assigned: Unassigned » anarcat

I'm working on this now.

anarcat’s picture

Status: Active » Fixed

1.x now has this code in, i'll make an rc4 for this.

http://drupalcode.org/project/provision.git/commitdiff/39de65b80ca2a383b...
http://drupalcode.org/project/provision.git/commitdiff/80e599d5c1d214b64...

I have also rolled a new provisionacl release to fix perms on those directories with good ACLs.

joestewart’s picture

I look forward to testing this. thanks. One quirk using my hack patch is that there are conditions where "cd to ~/sites/example.org, drush dl module" puts the module in the sites/all/modules directory. Not in sites/example.org/modules nor sites/all/modules/contrib. I guess because the ~/sites/example.org path doesn't match what the alias has.

ergonlogic’s picture

Wow! This is the first chance I've had to really read through this. Quick turn around! I was just floating a brainstorm...

@#2 I think putting sites under clients is brilliant. That it makes sftp easier is icing on the cake.

anarcat’s picture

joe: the quirk you mentionned is an issue regardless of the symlink - we're having this all the time. our fix is to use the provisionacl module and forbid regular users from touching the platform.

i think that is a drush bug, should be reported elsewhere...

Status: Fixed » Closed (fixed)

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