I'm not totally sure which issue queue this should go in, but the error message is coming from this module so I'll start here.
When migrating a site that has been working just fine with Backup Migate to an Aegir platform, I get this message during the verification stage:
Security notice: Backup and Migrate will not save backup files to the server because the destination directory is publicly accessible. If you want to save files to the server, please secure the 'sites/[mysite].com/files/backup_migrate/manual' directory
Security notice: Backup and Migrate will not save backup files to the server because the destination directory is publicly accessible. If you want to save files to the server, please secure the 'sites/[mysite].com/files/backup_migrate/scheduled' directoryI've checked permissions on those directories and files. I've set everything to what it was before when it was working, a combination of 755 and 644 I think, and even tried very strict permissions for all of the files and directories. Every time I go and check the permissions after requeuing the verification, I find everything set to 770.
I bypassed this step on another site by removing the module from the platform and then re-adding it after the site had migrated, but then it would complain that it can't write to the directory, not that it's insecure. So I'm not sure how to satisfy this security check.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | bam_aegir.zip | 569 bytes | nicksanta |
Comments
Comment #1
butler360 commentedStill having the same problem. Should this go in another issue queue?
Comment #2
ronan commentedI've never used aegir so i'm not familiar with the specifics of this issue but I can explain the basics of securing the backups directory and maybe that will help.
Backup and migrate needs to be able to write to the backup directory but it is important that files in that directory are not remotely accessible (ie: not being served up by the web server). The module does a check to see if the directories are secure by writing a test file to the directory and then attempting to access it via http (by trying to download it from http://[mysite.com]/sites/[mysite.com]/files/backup_migrate/manual/test.txt, or wherever). If it is able to read this file remotely then it assumes the directory is insecure it gives an error.
To secure this directory, backup and migrate adds a .htacess file to the directory which instructs apache to deny any http requests to files in that directory. It's possible that somewhere in the Aegir process this procedure of adding the .htaccess file and checking the remote access is not working as expected.
Does this make sense?
When I get some time I'll set up an Aegir environment and see if I can reproduce this issue.
Comment #3
Annakan commentedI suspect that on a standard aegir installation .htaccess use is disabled, you have to move the permission change to your httpd.conf file or better to the include associated file in the aegir/conf directory, I suspect verification might overwrite your settings though.
Comment #4
butler360 commentedI think I have tried that with the htaccess file but it didn't work. I'll double-check to make sure, though.
Comment #5
Annakan commentedWhat I meant is that in "by the book" installation of AEgir, .htaccess interpretation is disabled.
I seem to remember that at least in an old doc.
It make sense since everything is made in included xxx.conf, and .htaccess is slower and a bit more risky.
What you need to do with backup and migrate is to translate the .htaccess rules in the equivalent rules inside the site *.conf / http.conf. With the risk of overwrite when verifying the site.
I just answer on top of my head at this hour but it may be worth checking that :
.htaccess interpretation is indeed disabled in your httpd.conf.
and if it is the case put the access rules there.
Comment #6
Ryan Palmer commentedThe problem is that each platform.conf file generated by Aegir contains at the bottom:
This is an issue more so with Aegir itself and not backup_migrate, IMHO. I have a good idea where this code shouldn't go, but can't figure out where such code should go that it won't be overwritten every time sites or platforms are verified.
Comment #7
Anonymous (not verified) commentedPer Annakan's comment, this is by design in Aegir: we deliberately disable the .htaccess overrides because it is a major performance killer (in and outside of Drupal land)
You could write a custom Provision extension to modify the template to suit your use case, or take the much faster route and simply modify the template that gets written into the platform's .conf. The relevant code is in the Provision component, typically in /var/aegir/platform/verify.provision.inc
Comment #8
butler360 commentedThanks for the definitive answer, mig5.
Comment #9
nicksanta commentedThis is quite late in the game, and Backup Migrate might support aegir now. If not, here is a fairly good solution:
Download this and unzip it in aegir's ~/.drush directory.
If you then verify the site (from the aegir UI) it should add the new htaccess rule to it!
Comment #10
anarcat commentedfaq material