Aegir 0.4 Alpha15 released
The Aegir project is pleased to announce our 0.4 alpha 15 release. This release is primarily a bug fix release, which aims to tie off a huge amount of outstanding bugs and other tasks.
We did aim to release beta1 but decided that there were a few critical bugs still lingering that we wouldn't want to overshadow in such a momentous release. Instead we've chosen to push out one last alpha before (finally) heading out into beta and RC stages of the 0.4 cycle.
community.aegirproject.org
In our biggest news, which we've chosen to announce in this release, we are very proud and excited to announce the launch of our new community site, http://community.aegirproject.org !
Much preparation and planning has gone into building a clean, feature-rich community portal for our ever-growing Aegir users. We hope you'll agree that the documentation space, development information and community resources are long-awaited and desperately needed features to help users understand how Aegir works and how to use it.
The community portal features:
- News area (blog, announcements)
- Almost all the Aegir documentation has been re-written and dramatically improved in a new Aegir handbook, covering all aspects of installing, using, understanding and developing Aegir.
- Screencasts and videos from sessions and tutorials (all the historical ones have been collated and added)
- Events calendar
- Shop resources (to be completed)
- Feed syndication of the Aegir universe (twitter, articles, git commits)
The Documentation on groups.drupal.org is largely out of date and not in any sane order, and will be decommissioned in favour of the new documentation. Some of the still relevant and well-written documentation was dragged across and cleaned up where necessary.
The documentation area on the new site is still a wiki so we would like to encourage users to continue to keep them up to date and add more to help improve the experience for other users.
We'd like to thank all the contributors to the existing docs for their hard work and initiatives and hope you'll enjoy the new space and structure to keep helping make Aegir awesome.
Key changes in 0.4-alpha15
In our 0.4 alpha 15 release, these notable changes/improvements have occured:
- The DNS feature has been implemented and is available in /admin/hosting/features (Experimental)
- install.sh script has been changed considerably - most of the MySQL tests and user creation have been moved into provision to be handled by drush/php. There is no longer an 'aegir_root' user required for MySQL, we simply use your MySQL root user, which must have a password. You are required to supply a valid FQDN on installation, so that remote web servers can theoretically resolve the Aegir server if connecting to it for databases.
- upgrade.sh script added (see below, adventurous people please test)
- UPGRADE.txt updated to be a provide a little more clarity
- There's a new /admin/hosting/settings area with misc settings/customisations, including:
- ability to run wget instead of drush cron
- delete sites without having to disable them first
- when selecting a core profile, hide platforms that incidentally have those core profiles but are intended as distributions (i.e OpenAtrium)
- backup task saves site's settings.php with uncloaked creds. Useful for exporting to non-aegir servers or for importing into new aegir servers
Installing and upgrading:
The canonical source of installation documentation is as usual the excellent INSTALL.txt.
For the first time, we offer an upgrade.sh script in Provision, which tries to automate much of the steps outlined in the UPGRADE.txt.
It is still imperative that you read the UPGRADE.txt and follow all version-specific upgrade instructions located at the end of the document before trying to run the upgrade script. This especially applies to users upgrading from before 0.4-alpha8, including 0.3.
The upgrade.sh script attempts to backup the existing backend components, download new versions, and then run the hostmaster-migrate command. It assumes you are upgrading from the previous release (hostmaster-0.4-alpha14). If you are not, you may have to edit the script to change the OLD_DRUPAL_DIR variable.
The script is in its infancy and has not been tested except by the developers while writing it. We urge caution (take backups!) but encourage feedback. If in doubt, just follow the UPGRADE.txt steps and perform all the manual commands as you usually would. Edit: some users report problems using the script on servers with really old versions of drush_make: the script stalls after upgrading Provision. Either run the upgrade process manually or apply this fix to your upgrade.sh.txt
Known Issues:
The following are known issues with the current release, for which there are tickets, but we didn't feel were critical enough to prevent another alpha release.
Some of the issues have been present since prior to alpha14, they aren't all new issues.
- DNS - currently there is no access control
- Hostmaster install doesn't yet support remote db servers
- 'Save' button on forms under some versions of Firefox/Iceweasel on Linux is greyed out
Bugs fixed:
#868896 : INSTALL.TXT needs updates
#880712 : install.sh.txt not prompting for the root MySQL password on Fedora 13
#882970 : settings.php should not be updated before a vhost file is created and verified
#888210 : Undefined variable: missing_requirement install_6.inc:214
#894004 : install.sh lies about mysql listen AKA move the mysql creds handling to hostmaster-install
#896492 : Anonymous users can't view the 'hosting/disabled/$site' disabled page
#897326 : Typo in provision.config.inc
#898732 : Deleted sites are counted against quotas
#911392 : Cloned site shows wrong database in UI
#913486 : Database server service stores port '0' in the hosting_service table
#914040 : Server crashed because hosting_site_alias table was huge
#919848 : verifying a server queues platform verification before the server verification
#922716 : Expand link opens new window when used from modal frame.
#928570 : Modal Frame font is inconsistent
#931136 : You can't delete the D7 alpha7 and beta1 sites.
#934830 : no width limit of 320px for div#navigation ul.links
#937490 : Fix Platform access control to deal with profile > platform paradigm
#940816 : SSL Enabled Settings do not trigger insertion of Rewrite rules in vhost file unless domain aliases specified
#942144 : Warnings when deleting a site
#944450 : Saving a Package Node removes attached data
#945894 : Enabling DNS service on server node gives MySQL errors
#946422 : cannot sync platform to remote
#947898 : Code in global.inc not picked up by settings.php
#949044 : It is possible to create broken site or duplicate sites nodes because there is not enough strtolower(trim(domain)) used
#950976 : Update hints for OS X
#950980 : New OpenSSL breaks install script
#951296 : @localhost no longer allowed in email addresses in Drupal 7
#955184 : Backup task breaks any site by replacing settings.php with version working only with Apache
#958094 : Disabling a site through Aegir front-end doesn't make it inaccessible
#960106 : That the 'Publish path' for a new platform should be absolute is not obvious (usability)
various others not reported in the queue
Feature requests fixed:
#366420 : DNS slave server support
#366814 : manage DNS records properly when creating/restoring/verifying/disabling/deleting sites
#826840 : Save settings.php with uncloaked credentials on backup (for using on non-aegir hosts)
#896914 : Migrate form displays current platform as a target
#897982 : Limit choice of install profiles to those on available platforms
#903884 : Delete task should be visible and inactive, not hidden.
#922278 : configure the master server to allow slaves to do zone transfers
#955550 : Improve Documentation to Reduce IRC Support Requests
various others not reported in the queue.
This was a mammoth and long-awaited release. Thanks to all our users for their continuing support, patience and contributions!
-- The Aegir core devs

Comments
Hostmaster remote db servers
A month or two ago in IRC Adrian told me that we "might never" use a remote db for the hostmaster site. Is this now a feature that might appear in the next few releases? If so great! It would be nice to support non-standard ports to for those of us not using 3306.
Adrian might have a good
Adrian might have a good reason for that that I don't know about. Antoine seems to think it's a good idea (and I can't think of a good reason why not)
I recommend you subscribe to http://drupal.org/node/956910 , and maybe we'll hear from Adrian there on why it's not a good idea.
P.S I think the only real
P.S I think the only real task required to achieve this in the installer is to detect if @server_master doesn't match --remote-db or something, and if so, in hostmaster.profile we just need to create a new server node of type DB (and service type mysql). So feel free to even experiment there! There might be a bigger issue there that I'm overlooking though.
Just upgraded from a14 and
Just upgraded from a14 and that was one of the most painless upgrades of aegir yet (been using since around 0.4a4) - nice job guys.
JamieT
Nice to hear, thanks! I
Nice to hear, thanks!
I discovered there's a small bug in UPGRADE.txt if you are upgrading from 0.4-alpha8 or earlier: the new GRANT statements you need to make for the aegir_root user in the version-specific notes, lack some quotes around the $AEGIR_HOST and $AEGIR_IP variables, so MySQL complains.
The fix is here if anyone needs to check.
Been trying to do an upgrade screencast but my laptop hates me right now :)
Easiest upgrade
ditto on the kudos!
Do let me know if any of you
Do let me know if any of you try the upgrade.sh script and have good or bad results.
Ran upgrade.sh script for an
Ran upgrade.sh script for an a14 to a15 upgrade, on an ubuntu 9.10 server
After script ran, all url's are now pointing to the first vhost in apache, including the aegir url
Got these warnings during the running of the script:
No hook functions were found for hostmaster-pause. [warning]
Available drush_invoke() hooks for hostmaster-pause: [warning]
array_keys(): The first argument should be an array deploy.provision.inc:84 [warning]
array_merge(): Argument #2 is not an array deploy.provision.inc:88 [warning]
Invalid argument supplied for foreach() deploy.provision.inc:89 [warning]
Thanks for the report. Those
Thanks for the report.
Those warnings occur on a manual migration too, separate bug.
Not sure about your vhost overlap, didn't get that in my upgrade a14 > a15 demo yesterday. I'll investigate.. but only the hostmaster-migrate command would manipulate vhosts, and that's run in the manual steps too same as the upgrade.sh.
Do the actual vhosts look normal in your /var/aegir/config/server_master/apache/vhost.d/ directory? Start debugging with an apache2ctl -S to see what's happening with the vhosts, possibly the Include path to aegir's managed vhosts needs to be changed (although that shouldn't be required for alpha14)
Feel free to open a support request
Thanks. Got the issue with
Thanks.
Got the issue with overlapping vhosts squared away by switching all of them to "any" instead of using the IP of the server, using webmin.
Not sure what happened - and can't recall how they were set previously - although I do remember after a14 that I had vhost issue with one of my non-aegir sites and the fix for that is likely what ended up causing this.
We did have the Virtualhosts
We did have the Virtualhosts fixed to IP address instead of wildcard (troubles getting SSL stuff to work) but this got removed around alpha13 or so I think. your alpha14 should've had wildcards too, perhaps your previous upgrade didn't work out right.
I used the upgrade.sh script
I used the upgrade.sh script and it went flawlessly. However I am having a problem creating new sites and I do not know if it is a problem with A15 or not and also where to raise the issue (which project on d.o)?
The problem is I have a number of platforms with alternative install profiles (Drupal Commons, Voicebox etc) after upgrade when I navigate to node/add/site I see the choice of profiles momentarily but then the disappear and I only have Drupal (default install profile) and no radio button? Changing the platform does not alter the install profile options.
I was able to create a drupal commons demo site using the drupal commons install profile prior to upgrade - I have since added a voicebox platform to try that out but now I cannot choose any install profile other than drupal. I know there was a lot of discussion around switching the install profile - platform vice versa but thought that was settled on some wording updates.
Is this a bug within A15 and if so which project do I raise it against (hostmaster, provision etc)?
TIA,
JamieT
JamieT, sounds like a
JamieT,
sounds like a permissions thing - do you happen to have the Client module enabled, and if so, did you set platform access control on those platforms that contain those install profiles?
The profiles might get hidden if it's detected that the user doesn't have access to those platforms (and thus profiles).
Not sure if that's your problem, but try editing those platform nodes and removing any platform access control by unchecking the clients listed there (you'll only see those if the Client feature is enabled).
Submitting the form will verify the platforms - now try and see if it's changed in the site form.
If it doesn't help and you feel it's a bug, file the ticket against the 'Hosting' project on drupal.org
Spot on... That was exactly
Spot on...
That was exactly the problem. I had the client module enabled for the last 2-3 upgrades and I also added a platform to a specific client - this never seemed to cause an issue before. However unticking the client on the platform enables me to use the install profiles for the given platform.
I did edit the client and noticed that there was no user associated with the client - I thought I had previously associated admin the the client but guess I may have missed that before.
Thanks a lot - my aegir install is now back to it's usual rocking self ;).
JamieT
Upgrade script appears to
Upgrade script appears to have worked just fine. I did get some warnings, though:
file_get_contents(/tmp/drush_make_tmp_1289209932/header): failed to open stream: No such file or directory drush_make.download.inc:117No hook functions were found for hostmaster-pause.Available drush_invoke() hooks for hostmaster-pause:
array_keys(): The first argument should be an array deploy.provision.inc:84array_merge(): Argument #2 is not an array deploy.provision.inc:88
Invalid argument supplied for foreach() deploy.provision.inc:89
Also, I found this part a bit ambiguous:
If you run this script (after satisfying the requirements of the Version-specificupgrade notes at the bottom of this document), you may skip the rest of this
document.
So do you do what's asked at the bottom before running the upgrade script or after? Upgrading from Alpha14, I actually did neither of the changes and it still seems to have worked fine.
Yes that's an unfortunate
Yes that's an unfortunate part of our UPGRADE.txt, I try to explain it in the screencast I did yesterday on upgrading.
Basically: you have to run/satisfy all the version-specific notes at the bottom of the UPGRADE.txt before you do anything else (including running the upgrade.sh)
Once you have completed those version-specific notes, you can either
a) run the upgrade.sh script or
b) manually set the environment variables, upgrade the backend, then upgrade the frontend per the 'generic upgrade instructions' in the docs (the upgrade.sh does this part for you automatically)
It's unfortunate that we have version-specific upgrade notes at the end of the document and always have - a lot of people miss this. That's why in this release we added the short 'table of contents' at the start of the document that indicates the various sections and instructs you to 'read the version-specific notes first'.
If you upgraded from alpha14 and didn't perform any of the version-specific notes, you have more-or-less gotten lucky, because there weren't many changes, however you will have missed one minor step included there, that isn't critical to successfully upgrading:
you need to move your /var/aegir/config/server_master/apache/conf.d to /var/aegir/config/server_master/post.d.
Check the end of the UPGRADE.txt for more info on that.
We'll try and make this more obvious in future releases (about version-specific release notes), as putting them at the end of the document isn't all that ideal - however, putting them at the start of the document is just as confusing :)
To be clear, I don't mind
To be clear, I don't mind them being at the bottom, I just found the wording telling you to look down there ambiguous.
Something more blunt, like, "If you are upgrading from so-and-so, you must complete the version specific upgrade steps as the bottom prior to running the upgrade script."
And I do have both conf.d and post.d directories there, but both are empty. Is that right or am I going to eventually have a problem?
Error adding an event to community.aegirproject.org
I'm doing a talk on Aegir at BADCamp this weekend. Tried to add an event on the community site. When I click submit I get
* warning: date_offset_get() expects parameter 1 to be DateTime, null given in /var/aegir/atrium-1-0-beta8/profiles/openatrium/modules/contrib/date/date/date_elements.inc on line 491.* warning: date_format() expects parameter 1 to be DateTime, null given in /var/aegir/atrium-1-0-beta8/profiles/openatrium/modules/contrib/date/date/date_elements.inc on line 494.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /var/aegir/atrium-1-0-beta8/profiles/openatrium/modules/contrib/date/date/date_elements.inc on line 498.
* warning: date_format() expects parameter 1 to be DateTime, null given in /var/aegir/atrium-1-0-beta8/profiles/openatrium/modules/contrib/date/date/date_elements.inc on line 500.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /var/aegir/atrium-1-0-beta8/profiles/openatrium/modules/contrib/date/date/date_elements.inc on line 509.
* warning: date_format() expects parameter 1 to be DateTime, null given in /var/aegir/atrium-1-0-beta8/profiles/openatrium/modules/contrib/date/date/date_elements.inc on line 511.
* A 'From date' date is required for field Date .
The from date is there. It was selected from the date picker.
Yeah i get this too, although
Yeah i get this too, although a few users seem to be immune. The error is reported on openatriums issue queues too so I suspect it's an atrium bug or a bug in latest date module?
Possibly a timezone issue if it works for some users..
Easiest upgrade ever! :-)
I upgraded from a14 to a15 and it was a piece of cake! Two lines to download and run the script and I after a little light reading and hitting "Y" a few times, I breezed into a15. :-) Just wondering, if I have one server, would I have much use for the DNS feature? I currently use slicehost for my virtual server and add in the DNS records via their web admin.