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
Comment | File | Size | Author |
---|---|---|---|
#8 | verify.patch | 1.09 KB | anarcat |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedCan you detail what the permissions are on the sites/ hierarchy?
Comment #2
anarcat CreditAttribution: anarcat commentedComment #3
anarcat CreditAttribution: anarcat commentedwe can't release in this state.
Comment #4
anarcat CreditAttribution: anarcat commentedso 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.
Comment #5
acFrom 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.
Comment #6
spidermanI 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.
Comment #7
anarcat CreditAttribution: anarcat commentedSo 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.
Comment #8
anarcat CreditAttribution: anarcat commentedSo 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.
Comment #9
anarcat CreditAttribution: anarcat commentedSo 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.
Comment #10
anarcat CreditAttribution: anarcat commentedThis 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:
Notice the nogroup?
Oddly enough, the platform has the right value for the group:
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...
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.
Comment #11
anarcat CreditAttribution: anarcat commentedArgh.
With or without my patch, platform verification fails with this error:
Comment #12
adrian CreditAttribution: adrian commentedThe 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
Comment #13
adrian CreditAttribution: adrian commentedCommitted 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.
Comment #14
anarcat CreditAttribution: anarcat commentedSo with this patch Aegir installs fine on d5. I will test d6 platform deployment now.
Permissions in the sites dir:
Not ideal (why the nogroup again?) but acceptable.
Comment #15
anarcat CreditAttribution: anarcat commentedI can also deploy a d6 platform and create d6 sites now, so the problem is mostly resolved, however, we still have ugly perms.
The platform verification should fix that, but it's really minor.
Comment #16
anarcat CreditAttribution: anarcat commentedThis issue (install problem) is resolved, i'll open a seperate issue for the permissions.
Comment #17
anarcat CreditAttribution: anarcat commentedNote 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