Posted by mrfelton on September 11, 2010 at 10:21am
5 followers
Jump to:
| Project: | Provision |
| Version: | 6.x-0.4-alpha3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
After migrating a site from one platform to another, the permissions of all subdirectories of the files directory seems to be set incorrectly. They are owned by aegir:aegir so the webserver is unable to write to them. The problem is instantly noticeable as the files/css directory can not be written to for css aggregation, and so the site has no css right after a migration.
chown -R aegir:www-data files;
chmod -R g+w filesseems to sort it out.
The files directory itself seems to have the correct permissions - just not any of its subdirectories (such as the css dir)
Comments
#1
#2
Edit 9/24/2010, 7:23 PM: Just solved this again. My last reply was inaccurate.
SUMMARY: I think that there might be a bug here. If you import a site and the files directory is owned by aegir.aegir (the apache user doesn't have correct permissions), provision-verify doesn't set the correct permissions.
Last week I ran into the situation you describe. After discussing it on the aegir list (http://lists.aegirproject.org/pipermail/aegir/2010-September/000020.html) I modified my migrate method and got it working.
Migrate an aegir 0.3 site into aegir 0.4
* create a platform on the 0.4 hostmaster server that is identical to the platform on which the 0.3 site resides.
* create a vanilla site on the new 0.4 platform
* untar the latest backup of the site to be transferred. manually read database.sql into the db that was created when you did step 2.
* as a result of the untarring your files/ dir is owned by your $user.$user (aegir.aegir if that's who you are).
If I verify the site now when it is rsync'd to the webserver I see:
drwxrwx--- 2 app_aegir app_aegir 4096 Sep 24 18:09 sites/testcampuslife-dev.localhost/files/css/
which will cause problems because the webserver user (www-data or apache) can't read that directory. This results in errors like
warning: opendir(sites/testcampuslife-dev.localhost/files/css) [function.opendir]: failed to open dir: Permission denied in /var/aegir/platforms/dev/drupal-6.15/includes/file.inc on line 895.
and
The selected file /var/aegir/platforms/dev/drupal-6.15/sites/testcampuslife-dev.localhost/files/tmp/file7p98cS could not be uploaded, because the destination sites/testcampuslife-dev.localhost/files/js/js_49296e2e0b454ea7cca98dbfb65b7992.js is not properly configured.
If this has happened to you you can correct it thusly:
On the HOSTMASTER server:
* cd to the platform directory
* chgrp -R apache testcampuslife-dev.localhost/files
* reverify the site:
/var/aegir/drush/drush.php --uri='testcampuslife-dev.localhost' provision-save '@testcampuslife-dev.localhost' -v
(Or do the Verify in the hostmaster web UI.)
That should fix it.
#3
I experienced the above using a pre-alpha14 installation.
#4
I guess this isn't really aegir's fault:
The problem is that I migrate in a client's site which has a module enabled which creates a directory. If I forget to do things in the right order apache, not aegir creates the directory.
Here are the bad directories:
drwxrwxr-x 2 apache apache 4096 Oct 8 17:31 css/
drwxrwxr-x 3 apache apache 4096 Oct 8 17:19 ctools/
drwxrwxr-x 3 apache apache 4096 Oct 8 17:31 imagecache/
#5
This is why I suggested the patch attached here: #994210: Add support for some common files/subdirs like css/js/ctools/imagecache.
However, it helps only for those defined subdirectories and not for their sub-sub directories and other directories because of default system umask and different mv/cp actions performed by modules using /files/ directory, so I recommend to fix this on the system level, by forcing umask 002, so it will help also when you are uploading new files. Of course any files you are importing from extracted tar/gz archive, still needs to receive chmod/chown set correctly before verifying the site in Aegir - see my short how-to for Octopus: https://gist.github.com/802945 (of course you could use more advanced chmod for dirs/files separately, but I wanted to keep it simple for new users).
For Debian and Ubuntu the trick is:
apt-get install libpam-umaskecho "UMASK=002" >> /etc/default/login
echo "UMASK 002" >> /etc/login.defs
echo "session optional pam_umask.so umask=0002" >> /etc/pam.d/login