aplha11 new sites get wrong group perms in files subdirs

sub

subscribe, same here

In previous releases we were handling this implicitly because we did recursive permission changes. This caused problems with remote servers and sometimes data loss ( http://drupal.org/node/874716 )

When i hastily fixed that i seem to have missed the permission changes on the directories we create somewhat. I'm working on a patch to test this, but i need testers.

Here's the patch i just committed to master (http://is.gd/ekEPY) . Could one of you guys just test it for us, before i close this issue?

To test (as the aegir user):

  cd /var/aegir/.drush/provision
  curl 'http://is.gd/ekEPY' | patch -p1

Then just reverify one of the sites.

drush @site.com provision-verify --debug

Your output will have a bunch of stuff like this :
http://skitch.com/vertice/d1eqy/terminal-bash-186x49

Confirmed migrate still not setting perms correctly

Looks like group is not getting set to www-data

drwxrws--- 7 aegir www-data 4096 Aug 13 01:36 .
drwxr-xr-x 7 aegir aegir 4096 Aug 16 23:09 ..
drwxrwxr-x 2 aegir aegir 4096 Aug 16 23:09 css
drwxrws--- 2 aegir aegir 4096 Aug 13 01:35 images
drwxrwxr-x 2 aegir aegir 4096 Aug 16 23:09 js
drwxrws--- 2 aegir aegir 4096 Aug 13 01:35 pictures
drwxrws--- 2 aegir aegir 4096 Aug 13 01:35 tmp

This fixed in head now, with the application of this additional patch (http://is.gd/ekIKZ)

will release an alpha12 later this week with this and other fixes.

confirmed as fixed in head with above two patches (http://is.gd/ekEPY and http://is.gd/ekIKZ )

Still seeing problems on migrate and clone.

The content of css and js is not copied.

I applied both patches and will double-check to reproduce this for you if I can.

A fresh install using HEAD is working great so far and i am testing server to server migration today.

I am using the (Barracuda Aegir with Nginx Edition 0.4-alpha11-A11.A) install script on Lenny at Linode.com node and working on an a stack script to make testing images a little less painful.

If you would like and account on a testing none I would be happy to provide one for anyone who has time to test but needs a server.

One question i have is:

Have you considered storing private/public files in the database as one method or resolving issues with user files across many sites?

Keep up the great work... this will bring many users to Drupal

css and js are caches, and should be getting regenerated by the verify (which happens automatically during clone / migrate).

I think that was meant to be marked as needs work, as the patch was committed.

From the above, am I right to understand this hasn't been reproduced when installing from scratch?

Could you try again with alpha14 or better yet: head?

I have been able to reproduce the problem in head.

I am using Barracuda/Octopus on a Debian 64bit Linode.

Permissions are not being set for private/ and ownership is being set to [aegir-user]:users on all files

The web server can not read/write to private/temp or caches

Also see:
http://drupal.org/node/908524#comment-3472038
http://lists.aegirproject.org/pipermail/aegir/2010-September/000022.html

In addition the local.settings.php is not a good solution to set the location of private files because the global files path is not relative and gets copied on a clone or migrate with the wrong files path.

For an interim workaround, instead of using a local.settings.php I edit provision_drupal_settings.tpl.php with the following:

$conf['file_directory_path'] = 'sites/ print $this->uri /private/files';
$conf['file_directory_temp'] = 'sites/ print $this->uri /private/temp';
$conf['file_downloads'] = 2;

This enforces private files for an instance of hostmaster until relative file paths can be implemented.

Wait, are we having two different issues here? the original issue described here was about perms not set properly in our existing directories (images/pictures/tmp). I believe this is working.

What you are describing now is the private file upload mechanism that's not working, but that's a new feature that may require some polishing (#610912: Changes to file download method (public/private downloads) not supported).

Can you clarify what your issue is? Keep in mind there's now a separate issue for the perms problem (#908524: Permissions of sites/example.com/files/* incorrect after migration - webserver can not write), in which the original reporter say it was a local problem.

Marking "needs more info", reopen when things are clearer...

Thanks!

no response from submitters, closing.