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
Comment #1
joestewart CreditAttribution: joestewart commentedWe'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
Comment #2
anarcat CreditAttribution: anarcat commentedWhat I hope to do (this week?) is to have a clients/site hierarchy, so you would have:
~/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:
would be a symlink to ~/clients/koumbit...
Comment #3
anarcat CreditAttribution: anarcat commented@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.
Comment #4
anarcat CreditAttribution: anarcat commentedAlso - don't hardcode /var/aegir.
Comment #5
joestewart CreditAttribution: joestewart commented:) 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.
Comment #6
anarcat CreditAttribution: anarcat commentedI'm working on this now.
Comment #7
anarcat CreditAttribution: anarcat commented1.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.
Comment #8
joestewart CreditAttribution: joestewart commentedI 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.
Comment #9
ergonlogicWow! 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.
Comment #10
anarcat CreditAttribution: anarcat commentedjoe: 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...