Currently the installer is broken in HEAD. After running 'profiles/hostmaster/modules/drush/drush.php hosting setup' and moving on to the next page in the wizard you get the following error:

Warning: include_once(./sites/default/settings.php) [function.include-once]: failed to open stream: Permission denied in /var/aegir/drupal-5/includes/bootstrap.inc on line 248

Warning: include_once() [function.include]: Failed opening './sites/default/settings.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/aegir/drupal-5/includes/bootstrap.inc on line 248

Warning: Cannot modify header information - headers already sent by (output started at /var/aegir/drupal-5/includes/bootstrap.inc:248) in /var/aegir/drupal-5/includes/common.inc on line 141

Unsupported database type

CommentFileSizeAuthor
#8 verify.patch1.09 KBanarcat
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

anarcat’s picture

Can you detail what the permissions are on the sites/ hierarchy?

ls -lR sites/
anarcat’s picture

Status: Active » Postponed (maintainer needs more info)
anarcat’s picture

Priority: Normal » Critical

we can't release in this state.

anarcat’s picture

so we have found similar conditions on Yann's test server although the system was properly installed beforehand.

rerunning the platform sync fixed the problem, provided that we 'chown hostmaster provision.settings.php'. The WEB_GROUP in that config file was set to 'root', which is obviously wrong.

I suspect some cronjob or platform install was ran as root at some point instead of as hostmaster.

ac’s picture

From a fresh install I fixed this by chmod 777 sites/default - Adrian explained the permissions were being set wrong on that directory. I didn't look what they were set to after the aegir install but will check again.

spiderman’s picture

I ran into this issue while attempting to install on my MacOS machine. For some reason, the Drupal codebase I checked out from CVS ended up with strange group permissions, such that the webserver could not write files within the sites/default directory. I resolved the issue by doing a 'chgrp -R www' command on the Drupal root install directory (the DocumentRoot).

I subsequently removed the install completely, and checked out a fresh copy of Drupal 5 from CVS, along with the hosting, provision, drush, and cvs_deploy modules, plus the hostmaster install profiles, and making sure the group ownership was set to 'www' (the Apache primary group) before hitting the install.php. After this, I no longer received the above mentioned errors.

anarcat’s picture

Title: Can not install aegir » Verify task for sites
Category: bug » feature
Priority: Critical » Normal
Status: Postponed (maintainer needs more info) » Active

So at this point I do not consider this a critical issue anymore. From what I was able to see, all the problems here were permission problems caused by improper initial configuration. That may be a documentation bug, but even that is not exactly clear to me.

spiderman suggested on IRC that this should be checked for in the wizard or the setup process somehow. I would go further in saying that we would need a "site verify" task, the same way we have a "platform verify" task, that would ensure proper permissions are in place for sites/ directories and files.

So as long as we don't have a concrete report of how to reproduce this bug, I'm turning it into a feature request.

anarcat’s picture

Title: Verify task for sites » Permission problem when installing aegir
Version: 5.x-0.1-beta1 » 5.x-0.1-beta2
Category: feature » bug
Priority: Normal » Critical
Status: Active » Needs review
FileSize
1.09 KB

So I'm disagreeing with myself here: there are already enough checks on site installs, and although a verify task for sites would be a good thing, I don't think it warrants a complete task to fix this particular bug here (as it is really a bug, i think). The sites/default directory is really the platform's responsability and there's already a verify task there, that is performed exactly at the moment described in the original issue.

Besides, people keep on hitting this issue. So we need to fix this better, therefore I'm putting this back into the critical queue so that this gets fixed in the RC.

I also have a patch, attached, which checks the site directory when verifying the platform. I will test it shortly.

anarcat’s picture

Status: Needs review » Needs work

So this still doesn't work, for some reason.

I tried forcing platform verification (calling provision_verify) in the provision setup hook (which gets run in hosting setup), and that yields even weirder results. The hosting setup command fails and displays the dreaded "Unable to select database" *webpage* (Access denied for user 'hostmaster'@'localhost' to database 'mysql'). Since that should be hostmaster_root here, I took a look at the provision_settings.php file then, and it had the wrong configuration set. I guess that is fixed by running the queue after, which runs the provision synch command...

But still, nothing is fixed.

anarcat’s picture

This is driving me completely crazy.

So the current status is that, even with the patch, the paths are wrong. For some reason, the permissions are set to:

-rw-rw-rw- 1 hostmaster nogroup 5980 nov 13 18:22 settings.php

Notice the nogroup?

Oddly enough, the platform has the right value for the group:

define('PROVISION_WEB_GROUP', 'www-data');

What I think happens is that some step sets the group to nogroup at some point and then provision synch or verify can't set it back to www-data...

mumia:~/drupal-5.x/sites/default$ LANG=C chown www-data .
chown: changing ownership of `.': Operation not permitted

so the bug here, in my opinion, is that the provision.settings.php file doesn't get written properly in provision setup. If that would be the case, everything would fall into place nicely with my patch.

I'm exhausted at this point and giving up for tonight, I'd appreciate if someone else can take a look at this.

anarcat’s picture

Argh.

With or without my patch, platform verification fails with this error:

 Unable to connect to database server@import "/misc/maintenance.css";@import "/modules/system/defaults.css";@import "/modules/system/system.css";Unable to connect to database serverIf you still have to install Drupal, proceed to the installation page.If you have already finished installing Drupal, this either means that the username and password information in your settings.php file is incorrect or that we can't connect to the MySQL database server. This could mean your hosting provider's database server is down.The MySQL error was: .Currently, the username is hostmaster_root and the database server is localhost. Are you sure you have the correct username and password? Are you sure that you have typed the correct hostname? Are you sure that the database server is running?For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider., code: 0)

adrian’s picture

The synch command needs to be called before the verify task, as that's how the provision.settings.php is generated.

hosting setup calls the queue, which calls the provision synch and provision verify tasks

adrian’s picture

Status: Needs work » Needs review

Committed a patch which does a system call to chmod u+wx on the sites directory during setup,
and then during verify, it runs the provision_drupal_create_directories on the default directories, to match
the perms with all the other sites.

anarcat’s picture

So with this patch Aegir installs fine on d5. I will test d6 platform deployment now.

Permissions in the sites dir:

total 20K
drwxr-xr-x  5 hostmaster nogroup  4096 nov 14 13:18 .
drwxr-xr-x 10 hostmaster nogroup  4096 nov 14 13:20 ..
drwxr-xr-x  4 hostmaster nogroup  4096 nov 14 13:18 all
drwxr-xr-x  2 hostmaster nogroup  4096 nov 14 13:18 CVS
drwxr-x---  6 hostmaster www-data 4096 nov 14 13:20 default

Not ideal (why the nogroup again?) but acceptable.

anarcat’s picture

Priority: Critical » Minor
Status: Needs review » Needs work

I can also deploy a d6 platform and create d6 sites now, so the problem is mostly resolved, however, we still have ugly perms.

drupal-5.x/sites/:
total 20K
drwxr-xr-x  5 hostmaster nogroup  4096 nov 14 13:18 .
drwxr-xr-x 10 hostmaster nogroup  4096 nov 14 13:20 ..
drwxr-xr-x  4 hostmaster nogroup  4096 nov 14 13:18 all
drwxr-xr-x  2 hostmaster nogroup  4096 nov 14 13:18 CVS
drwxr-x---  6 hostmaster www-data 4096 nov 14 13:20 default

drupal-6.x/sites/:
total 24K
drwxr-xr-x  6 hostmaster nogroup  4096 nov 14 14:34 .
drwxr-xr-x 10 hostmaster nogroup  4096 nov 14 13:38 ..
drwxr-xr-x  3 hostmaster nogroup  4096 nov 14 13:23 all
drwxr-xr-x  2 hostmaster nogroup  4096 nov 14 13:27 CVS
drwxr-x---  6 hostmaster www-data 4096 nov 14 14:31 default
drwxr-x---  5 hostmaster www-data 4096 nov 14 14:34 testd6.localhost

The platform verification should fix that, but it's really minor.

anarcat’s picture

Priority: Minor » Critical
Status: Needs work » Fixed

This issue (install problem) is resolved, i'll open a seperate issue for the permissions.

anarcat’s picture

Note that the permission issue is: http://drupal.org/node/338657

Also take note of the security between sites issue: http://drupal.org/node/334416#comment-1129042

Status: Fixed » Closed (fixed)

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