Jump to:
| Project: | Hosting |
| Version: | 6.x-0.3 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
How does aegir platforms work in comparison with the traditional way of managing multisite installations?
What I struggle to get my head around is this:
The way I manage my sites today, I have one drupal core codebase for each major version of Drupal (i.e. 4.7, 5 and 6).
Each of my sites lives in the sites/sitename.com directory where all the contrib modules, themes and files for each site is placed. This means that each site have their own copy of all the contrib modules and themes they utilize, but share the same Drupal core (within each major Drupal version)
The way I understand Aegir platforms from reading the documentation, a platform consists of a Drupal core and all contrib modules and themes that should be available for sites running this platform. Does this mean that two sites on the same platform needs to share the same modules and themes? Can I have customizations for individual sites sharing a platform, or will I need to create individual platforms for each site that needs to be just a little bit different?
Allso, where is the modules for each site placed? Are they placed in sites/all or sites/sitename?
Any attempts to enlighten me will be received with great gratitude.
Comments
#1
Hi Vidar!
It's much more simpler than you fear: there is no need to change your existing structure with Aegir.
Each of these core codebases would be a 'Platform' in Aegir.
Each 'site' in Aegir would be a site living in the sites/$site directory of any of these platforms. Sites can have their own modules and themes inside their own site specific directory such as drupal-6/sites/$site/modules or drupal-6/sites/$site/themes. And indeed, this is how I do it with my sites. I dislike putting common contrib modules in sites/all, because it makes migrations that little bit more difficult.
But you can do that if you like: Drupal supports both, and Aegir doesn't do anything to stop the way Drupal normally works: it just provides you with the tools to manage your multisite setup easier but doesn't try and deviate away from the way things are normally done in Drupal.
In Aegir, if a new Drupal core release comes out (like yesterday with 6.14), you can make a new Platform and migrate your site onto it. If all the contrib modules for that site lived in the site-specific directory, all of it gets moved to the new platform and everything just keeps working. Easy!
Hope this answers your question :) Thanks for asking!
#2
while creating sites using aegir it s showing " pls fill a valid profile" ...... wat s the reason for this ???
Thanks in advance....
#3
@sindhujavn - your question is not related to this ticket. Please open a separate support request with your problem if it persists and read the bug reporting guidelines
#4
ya k.. sorry for the interrupt...
#5
Thank you very much for taking the time to respond.
If I understood you correctly this means that I can go about installing module on separate sites like I've always done using Drush or CVS, without having to worry about Aegir at all?
Allso, would I have to do anything special for migrating from 5.x to 6.x using aegir? Or could I just do like I'm doing now:
-Make sure all modules are updated
-Disable all contrib modules
-Upgrade core (I suppose this would now be done in Aegir, migrate site?)
-Get 6.x version of all modules
-Enable modules
-Fix quirks
Have I understood this correctly or am i missing some special Aegir step?
As before: Any attempts to enlighten me will be received with great gratitude.
#6
You can do that, but if you add new modules, you should re-verify the site afterward so that Aegir knows about the new modules. This will make migrations safer among other things
You're pretty close to understanding it yes: in Aegir you don't really upgrade an existing core, but you actually add a *new* core (called a 'Platform') and then you migrate your *site* onto it, away from the old core. It's a lot more elegant.
According to Adrian, you don't even need to disable your contrib modules when you do a migrate, Aegir should handle it for any modules that have upgrade paths. The one exception to this is that Views doesn't upgrade, so that would have to be a manual task.
I actually haven't tried a d5 to d6 migration with lots of contrib modules but Adrian assures me it works with the exception of Views :) I recommend you test on a dummy d5 site with some modules, to see how it goes: so you know what to expect and so that you reduce risk when moving any production sites. On the other hand, Aegir is very careful with your sites and site data: if something goes awry, it ought to rollback the changes and tell you what went wrong.
Good luck!
#7
Once again, thank you very much for replying.
I have to admit that this seems almost too good to be true...(Compared to my rather tedious do-everything-by-hand-through-putty approach that I'm currently employing)
I suppose I'll get to grips with all this in time, when my company gets my two new Ægir servers up and running :-)
But, since I'm the person with the most Drupal experience in the organization, I have a feeling that I'll be sort of responsible for fixing stuff when something does not work, and thus I feel I need to gather som knowledge up front.
On last question:
After reading the documentation I've come to the conclusion that Ægir does not yet provide any means for upgrading, installing and otherwise managing contrib modules. (With the exception of the migrate process where I understand for your reply that Ægir actually gets and install all the modules my site needs on the new platform).
Is this correct. If so, how do you recommend going about this part of administering multiple sites. (I.e. keeping contrib modules up to date, and adding new modules).
My guess is that the most efficient way would be to use Drush from the command line, perhaps through some custom shell scripts, but then again there might be better approaches.
Any thoughts on this?
#8
Managing source code is a process called build management.
the recommended process to follow is to manage all your code in svn or git or something similar, and then make new checkouts whenever you release a new version, and migrate all the sites over to the latest code.
#9
Others have suggested that approach to me earlier but failed explaining why it is a good thing to keep my own repository of modules already in the Drupal CVS system.
I have very few custom coded modules on my sites, so my challenge is mostly to keep up with security upgrades of existing modules from the Drupal contrib library. And keeping my own local copies of all revisions of these modules seems to me as just being more work, not less.
If you, or someone else could take the time to explain the benefits of the local SVN / GIT approach I would be very thankful.
#10
There is no reason at all to do so .. what they are saying is for ur own custom bits not something already in druapl cvs et al.
Just run the drush commands to update ur modules on each of ur sites.
drush -l somesite.com update
...should do everything it even triggers the updatedb command at the end.
You will need to do this for each site in the given platform and also re-verify the platform after all new modules are in place, for good measure.
Another option .. create another platform with all the updated modules & then migrate your sites to it.
Im closing this unless you have any more related comparison questions.
Cheers & welcome to Aegir!
P.S. Just wondering why you said "This means that each site have their own copy of all the contrib modules and themes they utilize" whats the use of doing a multisite then? AFAIK contribs should be in sites/all/modules .. so all sites have access to them and you dont have all that code repetition. Of course you may want to hide some modules and have some customs particular to a given site, in that case they go in .. sites/sitename.com/modules directory; but at least "most" of the contribs should be in sites/all/modules.
#11
It's certainly easier to put the modules in sites/sitename.com/modules when it comes to Migrating the site in Aegir, because you don't have to put any dependencies in place on the target platform - the site move will move all the required modules with itself. You miss copying a module to the target platform in advance, and it gets disabled on the site during the migration.
On the other hand there is a 'code repetition' issue (I would rather call this disk usage - the code isn't being 'repeated' anywhere really). But disk is cheap, and dealing with site module dependency issues is sometimes not so cheap, especially when it's Friday 5pm and you really wanted to get your arse to the pub :)
There are also cases where $site1 works with $module1-1.3 but it can't with $module1-1.4 because it breaks $module2, but you want $site2 and $site3 to use $module-1.4, so they can't all live in sites/all. Maybe you're nuts and you have to use a dev version of the module on that mission critical site. Drupal only supports a single namespace, you can't choose between versions of the module in admin/build/module.
This is largely my opinion and not the opinion of the Aegir team: I personally prefer to deal with the extra disk usage of duplicated modules for the sake of migrations etc. sites/all/ is more lightweight but for me it inevitably leads to problems / increases risk
I don't think there is a wrong or right way of doing this since Drupal supports both, it's a 'your mileage may vary' thing. Just don't put them in the $core/modules dir :)
#12
heehee .. yea I have to agree with mig5, its a matter of taste/need.
I didnt realize that bits in sites/sitename.com/modules get disabled on migrate ... come to think of it I did notice that but didnt figure it was the migrate that did it. Good to know for future migrations. Mig5 so you have to go in and re-enable all those modules for each site? ...sounds like a lot of work!
Cheers!
And I also want to add that I am merely an Aegir user and my opinions are my own and not necessarily reflective of anyone else.
#13
For reference, this was a misunderstanding of what I was trying to say, in fact the complete opposite, explained it in IRC :)