>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1205458. --> Reported by: [sfyn](https://www.drupal.org/user/400944) >>> <p>This issue has addressed several intermingled issues, with lots of questions and suggestions. I'll try to summarize and synthesize them here.</p> <h4>Do we want allow files/modules/themes/libraries to be moved out of the sites/ directories?</h4> <p>Sites are "owned" by clients, and just happen to live on platforms. Benefits would include the possibility of using a separate mount for files, and greatly simplify setup of ACLs, SFTP, etc. We seem to be converging on these settings being system wide, rather than per platform or per-site, but it hasn't been discussed in depth. It would however break our current backup methods, and so these would have to be addressed as well. Consensus seems to be that we should allow for it, but not make it the default.</p> <h4>Where should they go?</h4> <p>There appears to be two schools of thought about where a client's sites' directories should live. </p> <p>The first is along side everything else in the site's directory. That is: <strong>/var/aegir/clients/[client_name]/sites/[site_name]/files</strong>. The client's directory, since it stays stable through upgrades and such, would be a good candidate for a chroot (for SFTP, etc.) There is no automated way to delete a client's directory at present, but safeguards would have to be put in place to check for the existence of sites, before deleting a client (as we do presently for platforms.) Allowing these safeguards to be overridden could be good for quota management. Moving a site between clients would involve moving these files as well.</p> <p>The other option is somewhere outside of the clients directory, such as <strong>/var/aegir/site-files/[site_name]</strong>. This avoids the possibility of accidental deletion of files when deleting clients, and could simplify changes in site owner/client, since it would just involve re-writing symlinks.</p> <p>Either way, we'll need to allow this to be set or overridden easily, based on the policies and priorities of the Aegir admins.</p> <h4>How would we do it?</h4> <p>First, we'll need a flag that lets the backend provision commands (install, deploy and verify) know about the fact that we're symlinking, so that those operations can move file directories into the symlink root and construct symlinks. We should consider splitting that function between directory creation and permission verification. This would allow ACL code to be merged in or hooked better, but would also allow us to avoid making modifications to core for every contrib module.</p> <p>We already have several patches that provide hooks to:</p> <ul> <li>override these optional install directories,</li> <li>adjust symlinks accordingly, and </li> <li>allow altering the chgrp behaviours.</li> </ul> <p>Backups and clones would have to know about these new directories, or risk losing files from backups, or having multiple sites share the same files after clones. Since we cannot reliably follow symlinks, we may also need to adjust the backup command to add those files to the archive when doing backups, which in turn may mean doing the backup in two steps (tar then gzip) to be able to append to the archive. An alternative would be to start using "zip" instead of tgz, which supports appending natively.</p> <p>The core of this refactoring needs to happen install and deploy hooks, most specifically in _provision_drupal_create_directories(). Verify also uses that function, but possibly just to change permissions. We'll probably also need to prevent backups from fetching files directories on remote server, to cover cases where the symlink goes to an NFS share or DFS share like Gluster.</p> <h3>Original issue description:</h3> <p>Here is what I am thinking:</p> <p>1. Add attributes to sites for files and tmp directories - this attribute cannot be shared with other sites (in Hostmaster?)<br> 2. Install, Verify and Migrate tasks merely create or move around symlinks to these directories<br> 3. Backup and Restore tasks work normally</p> > Related issue: [Issue #2714641](https://www.drupal.org/node/2714641)