Aegir 0.4 alpha 7 released

Events happening in the community are now at Drupal community events on www.drupal.org.
anarcat's picture

The Aegir project is proud to announce the seventh alpha of our 0.4 release cycle. In the craziness of Drupalcon San Francisco, we have decided to make a long awaited release to share all the good stuff that is happening on the master branch. Most of those changes are stability and bugfixes and should be useable in production, but keep in mind this is still an alpha release, so it hasn't gone through the usual release-candidate proofing cycle.

Also note that we've been very busy on a separate development branch (dev-services) to implement the core goal of the 0.4 release that is multi-server support. Progress is advancing there, thanks in part to the contributions of Neil Drumm, which was given commit access due to the continuous quality of his patches submitted in the issue queues.

The canonical source of installation documentation is the excellent INSTALL.txt. We have an automated and scripted upgrade process for the front end, which you can read more about in UPGRADE.txt.

Update: please do take note of the instructions at the bottom of UPGRADE.txt! You need to update your apache configuration! (Thanks for the people that mentioned it in the comments here...)

Important: aegir now depends on Drush 3.0 beta 1 or later, and will install the latest drush release for you through the excellent install script.

Backend changes and fixes:

  • #724294 - implement a rollback hook to delete stale tarballs after failed backups
  • #728140 - try to wean the platform apache config off crack
  • #731816 - provide comments explaining why and how site db credentials are stored in apache vhosts as environment variables
  • #642948 - backup_migrate compatibility: block files/backup_migrate/ paths from apache
  • #685076 - be more tolerant on hook_update() function names so that media_mover upgrades work properly
  • #604800 - ignore site-specific modules in aegir
  • The .htaccess file is now source from your platform's .htaccess instead of our hardcoded values, which allows you to easily override the vhost settings (just edit your .htaccess and run platform verify)
  • Fixed SSL for mixed SSL + non-SSL sites
  • We don't chown/chgrp symlinks anymore in site verification
  • Drupal 7 provisionning works again

Frontend changes and fixes:

  • #731550 - set the default db server to be that of the web server now that the nodes have merged
  • #724498 provide help info explaining why it might be useful to set the queue dispatch frequency to every 1 second
  • fix for #725952 - always show all enabled platforms for uid 1. Only show the platform access control checkboxes if the Client feature is enabled, as that's only when it'd really be required
  • fix for hostmaster upgrade path from 6.15 to 6.16
  • disable the ability to run the lock or delete task on the default platform. another platform will need to be made the default before this occurs, else the site form becomes more crazy than mig5. Probably will need end-user documentation to suit.
  • #752700 - display last executed time on task list
  • #732676 - sort platforms alphabetically
  • #726756 - fix to send welcome mail to clients
  • #674916 - fix default values for SSL form, don't fiddle with the port when changing SSL settings since it's ignored in the backend anyways
  • #758682 - prevent a site from being cloned to a locked platform. introduce a hosting_platform_is_locked helper function for that sort of thing. hide bits of forms as a result.
  • #764410 - change wording to be non migrate-specific to account for clone
  • don't save the unprivileged db user/pass to the db server as superuser credentials. to avoid the misleading information causing the most common user error in the next alpha that will still have a forms-based hostmaster profile
  • Some documentation fixes to the INSTALL.txt

Comments

Awesome, looks good!

butler360's picture

Regarding this point: "The .htaccess file is now source from your platform's .htaccess instead of our hardcoded values, which allows you to easily override the vhost settings (just edit your .htaccess and run platform verify)"

Does that mean that if a module requires htaccess changes (such as boost or css gzip), we can now make those changes to the htaccess file and reverify and the changes will apply?

Yes, that is what it means

anarcat's picture

However, for boost, you should probably use the provision_boost module instead, which does this automatically for you.

Upgrade Problem

jacobson's picture

I've just tried to upgrade from 0.4-alpha6 to alpha7. The back end upgrade went fine. I had trouble with the front end following the instructions in UPGRADE.TXT.

The problem I encountered was that hostmaster-migrate tries to restart Apache, but the condition of the Apache configuration files prevents Apache from restarting. Specifically, in my case, the apache.conf file had an include to itself, which obviously wouldn't work. So, I had to fix the Apache configuration files problem (following the instructions later in UPGRADE.TXT), and then re-run hostmaster-migrate.

HAJ

Apache wouldn't restart for

Ryan Palmer's picture

Apache wouldn't restart for me because a conf directory was missing. Try this:

mkdir /var/aegir/config/apache.d/

Then try $DRUSH hostmaster-migrate aegir.resonancedev.net $DRUPAL_DIR again.

I had the same issue with

jamiet's picture

I had the same issue with Apache not restarting. The UPGRADE.txt. advises me to change the file /etc/apache2/conf.d/aegir.conf for:

Include /var/aegir/config/vhost.d

To read :

Include /var/aegir/config/apache.conf

However within my setup (based on 0.4-alpha6 install) the problem is the fact the /etc/apache2/conf.d/aegir.conf file is a symlink to /var/aegir/config/apache.conf so it is called within itself which causes a multiple recursion error. I commented out this include statement within /var/aegir/config/apache.conf and apache was able to restart and I then ran the hosting-migrate command again - this time successfully.

HTH,

JamieT

That is correct

anarcat's picture

That is correct, and I have updated the announcement to point to the UPGRADE.txt notes that indicate how to properly upgrade your apache config.

file permissions are changed after uploading content

spangaroo's picture

I successfully upgraded from alpha6 to alpha7. Great work on the easy-to-understand UPGRADE.txt instructions.

File permission issues did trip me up so if you're going to upgrade it might be good to watch out for those.

aegir.mydomain.com verifies without a single error, but I'm still having trouble with the file permissions on an Open Atrium install profile at sub.mydomain.com.

I've added only a couple of contrib modules to OA. I added content earlier this afternoon and images are being uploaded with www-data:www-data permissions rather than aegir:www-data.

I'm using the Wysiwig (Tiny MCE) along with the IMCE Wysiwyg API bridge module for adding images.

I went ahead and did chown -R aegir:aegir files and that works for now but I'm curious to know why images aren't being added with the correct permissions or if I should change my setup to prevent this from happening in the future?

What are those permissions?

anarcat's picture

What are those permissions?

aegir:aegir for files/ is not quite right: it should be aegir:www-data. There was a problem with this during the development of 0.4-alpha7, but I have fixed it, as far as I know.

I double checked and yes

spangaroo's picture

I double checked and yes you're right, the permissions are aegir:www-data.

But files uploaded with the Wysiwyg editor are www-data:www-data. From what I've learned so far about Aegir it seems that it's very important that everything is owned by the aegir user or warnings will show up.

What should I do to figure out how to make uploaded files to have aegir:www-data file permissions?

Great changes

timwood's picture

Lots of great fixes in the change log. Looking forward to testing this upgrade. Thanks for the continued hard work!

SSL

timwood's picture

I encountered some trouble with SSL certificates and the apache configuration settings after the update. If anyone has any insight I've updated the ticket here with two comments: http://drupal.org/node/712958#comment-2874816

Thanks,
-Tim

A few missing instructions

mmartineau's picture

I'm new to Aegir and installed it for the first time today. At the time I installed it a few instructions were missing from INSTALL.txt for the .4 alpha7 version. I found needed additions in the .3 release install.txt instructions:

Creating Aegir's virtualhost
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hostmaster provides an example virtualhost for apache. Copy it to Aegir's
virtual hosts directory and modify it to suit your needs,
particularly the path leading to the Drupal core ($DRUPAL_DIR in the
examples above).

Shell commands::
export AEGIR_DOMAIN=aegir.example.com
cp profiles/hostmaster/apache2.conf.txt ../config/vhost.d/$AEGIR_DOMAIN
# edit and configure

I don't know if this is required or if there is a more "official" way, but it worked for me.

These steps are not required

mig5's picture

These steps are not required in the 0.4 releases because the install.sh script does it for you. Maybe you didn't follow the step in the INSTALL.txt which instructs to run the install script (but then you would've been missing a lot other stuff too)

I did run the script

mmartineau's picture

I thought I followed the INSTALL.txt file exactly including running the script. When the script finished running it didn't report any errors. After the script finished I went to load the website (install.php), nothing came up. A little investigating revealed that the vhost.d and platform.d directories in the config directory were empty, so I copied the example apache2 conf file to vhost.d as directed by the .3 INSTALL.txt file.

I may have just missed something in the .4 INSTALL.txt. Everything else seems to have worked fine.

Very nice

Macronomicus's picture

The upgrade was nice n easy!

Smooth

Letharion's picture

Thanks guys for all the hard work.
Upgrade went smooth.

Upgrade problem

popmechanic's picture

I started the upgrade process from Alpha 6 today, and I'm running into trouble with the hostmaster-migrate command. After running, "$DRUSH hostmaster-migrate aegir.[mydomain].com $DRUPAL_DIR" I'm given the following errors:

Could not find a Drupal settings.php file at [error]
./sites/default/settings.php.
The drush command 'hostmaster-migrate aegir.mimeo.us [error]
/var/aegir/hostmaster-0.4-alpha7' could not be found.

Copying the settings.php file doesn't fix the problem. Any idea what's going on here? Thanks in advance.

Did you run the

mig5's picture

Did you run the hostmaster-migrate command from inside the old hostmaster platform directory?

'Could not find a Drupal settings.php file at [error] ./sites/default/settings.php' means that 'aegir.mimeo.us' was not found inside the sites directory of the old platform, so it fell back to trying 'default' with no better option. (which either means it is missing,in a different platform, or in some other way unbootstrappable)

Error runnung hostmaster migrate

cocoshogo's picture

Backend upgrade went fine, but upgrading the front end fails to migrate the hostmaster. I am very sure I went step by step in the Upgrade.txt. Any one know anything on this:

Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.06 sec, [bootstrap]
3.49 MB]
Loading drushrc "/var/aegir/hostmaster-6.x-0.4-alpha3/drushrc.php" [bootstrap]
into "drupal" scope. [0.06 sec, 3.49 MB]
Initialized Drupal 6.15 root directory at [notice]
/var/aegir/hostmaster-6.x-0.4-alpha3 [0.07 sec, 4.28 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.08 sec, [bootstrap]
4.28 MB]
Initialized Drupal site core.loqalhost.com at [notice]
sites/core.loqalhost.com [0.1 sec, 4.28 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.11[bootstrap]
sec, 4.28 MB]
Undefined index: db_type settings.php:12 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_name settings.php:13 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_user settings.php:14 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_passwd settings.php:15 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_host settings.php:16 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_type settings.php:18 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_user settings.php:18 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_passwd settings.php:18 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_host settings.php:18 [0.11 sec, 4.31 MB] [notice]
Undefined index: db_name settings.php:18 [0.11 sec, 4.31 MB] [notice]
parse_url(://:@/): Unable to parse URL environment.inc:700 [0.11 sec, [warning]
4.3 MB]
PHP Fatal error: Unsupported operand types in /var/aegir/drush/includes/environment.inc on line 701

Fatal error: Unsupported operand types in /var/aegir/drush/includes/environment.inc on line 701
Drush command could not be completed. [0.11 sec, 4.3 MB] [error]

Also, checked the settings.php file for my hostmaster and it doesnt seem to be configured right after running the hostmaster-migrate :

*/
$databases['default']['default'] = array(
'driver' => urldecode($_SERVER['db_type']),
'database' => urldecode($_SERVER['db_name']),
'username' => urldecode($_SERVER['db_user']),
'password' => urldecode($_SERVER['db_passwd']),
'host' => urldecode($_SERVER['db_host']),
);
$db_url = "$_SERVER[db_type]://$_SERVER[db_user]:$_SERVER[db_passwd]@$_SERVER[db_host]/$_SERVER[db_name]";

$profile = "default";

is this right? there is no info on the correct db to connect to. The info, however, does exist in /default/settings.php

BTW this was a migration from hostmaster-6.x-0.4-alpha3 -> hostmaster-0.4-alpha7

Please help if you can anyone :(

Aegir hosting system

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: