Changes to file download method (public/private downloads) not supported

this is by design. otherwise the sites would walk all over their directories and it would be impossible to migrate them cleanly

private download is a major performance drain, and that code is from the hostmaster code base.

you can comment out that line in the settings template file for now, and we can patch it to allow it to be set.

i've opened to issue again and changed it to be more specific to your needs.

Perhaps it would be useful for Aegir to have an option at creation time of a 'site' for public/private file systems. I know private file systems are invaluable to many of our intranet sites, and it wouldn't be too hard for Aegir to have another directory, say '/var/aegir/privatefs/templatename/sitename', for this purpose. Thoughts?

I have solved this problem similarly to @obrienmd, by overriding the $conf array using a settings.inc file.

I decided upon this directory structure: /var/aegir/private_files/sitename.com.au

The main difference between mine and #4 being that the platform isn't included in the path, mainly for less pain when migrating a site from one platform to another.

If anyone is wanting to do this at the moment, do the following:
In /var/aegir/config/includes/global.inc add this snippet

<?php

// Look for a settings.inc in the sites/blah.com directory.
if (file_exists(conf_path() . '/settings.inc')) {
  include_once conf_path() . '/settings.inc';
}

Create a settings.inc file in the sites directory alongside the settings.php file

<?php

// overwriting these values to allow private downloads
$conf['file_directory_path'] = '/var/aegir/private_files/domain.com';
$conf['file_directory_temp'] = $conf['file_directory_path'] .'/tmp';
$conf['file_downloads'] = 2;

Enjoy

mm, that was something i overlooked.

I'm not an apache expert, so I'm not entirely sure if this will work - mainly because im not sure whether the subdirectories will inherit these rules or not.

In /etc/apache2/conf.d/nick_custom I've put this in:

# This is to protect the private downloads directory from execution of arbitrary files - see SA_2006_06
<Directory "/var/aegir/private_files">
  SetHandler This_is_a_Drupal_security_line
</Directory>

If you agree that this will work, I'll edit #5 and add this in.

I don't think we should hardcode the file method. As long as private downloads are secured by Aegir (which is something that should be checked before we stop enforcing this), we shouldn't enforce public downloads.

Backups in aegir work because sites are considered 'atomic' .. ie everything needed to roll out the backup or install the site is in the same tarball, and can be moved between servers / etc.

So i have nothing much against private / public downloads .. but i have objections against having the files directory outside of the web tree, as it also complicates write permissions, and introduces situations where multiple sites can have access to the same files tree.

subscribing...

This is still a problem in 6.x-0.4-alpha6.

subscribing

So in the future you might not want this hardcoded, or in the web tree.

the example being multiple web server using a mounted files directory.

My main concern is that end users on the sites, change the paths.
Which gives them the ability to break things they aren't meant to be able to break.

This needs to still be enforced by aegir, but we should make what it enforces configurable (to the aegir admin).

subscribe

sub

Subscribing. It appears that site verify in the latest Aegir 0.4 alpha 8 regenerates the settings.php file and kills off any changes. Is this correct?

Incidentally, not sure if I'm missing a trick, but private downloads doesn't seem to need the files directory situated outside of the web tree in order to block unauthorised download requests with a 403 error message. This retains the atomic nature of Aegir's site handling.

subscribing

I removed the line in head which overrides it

it's now up to the sites , or the admin if he wants to use global.inc to enforce a value.

adrian - Just to confirm, you are saying sites can now set file storage setting in UI, and change will persist, through clones/migrations/etc?

obrienmd - no, ONLY the private/public download bit.

setting the file path is still something that can break things really horribly.

marking as fixed.

if you want to shoot yourself in the foot you can use the new 'local.settings.php' in the site directory to override the file dir.