run the `fix_dir_perms` role after gcsfuse+nginx

[thraxil]

utility role to clean up some permission conflicts as described in https://github.com/appsembler/roles/pull/60

[thraxil]

I want to make sure that people do understand the problem.

The playbook (before this):

• installs our gcsfuse role. This creates the /var/www/letsencrypt directory as a mountpoint owned by root.
• installs the general edx nginx role. That role includes steps to create the www-data user/group that nginx runs as. Normally, it would also create the /var/www/ directory and set it to be owned by that user/group. But since gcsfuse already created /var/www (in the process of creating /var/www/letsencrypt), the nginx role skips that task, which has the side-effect of not setting ownership on the directory, leaving it as root:root as gcsfuse created it.
• since the www-data user has to be able to traverse the full path to access /var/www/letsencrypt/acme-challenges-custom-folder (which .well-known is aliased to), we get 403s on the challenge requests and letsencrypt certificate renewals fail.

Normally, we would fix it by just running nginx first, so it creates /var/www before gcsfuse and the permissions are set right. Unfortunately, the nginx role with our config references /etc/letsencrypt paths for SSL certificates. /etc/letsencrypt on Tahoe is also mounted from GCS Fuse and thus requires the gcsfuse role to have mounted it. If you run the nginx role before gcsfuse, configs point to nonexistent SSL certificate files on disk, the nginx service fails to start, and the playbook won't get any further.

So this little role afterwards is a fix to get around that circular dependency between gcsfuse and nginx. It allows the playbook to run both steps, and just cleans up the error.

[OmarIthawi]

Thanks @thraxil, now I see that the other PR (https://github.com/appsembler/roles/pull/60) was to create the role and this one is to use it.

Thank you for the detailed explanation again.