More detail on subdirectory permissions.

diff --git a/Installation.md b/Installation.md
index c93d9fcc911150a2a775e7ae1084ab67689d78cf..2c04f9a999b96619b3b3a06368ec70d032899128 100644 (file)
--- a/Installation.md
+++ b/Installation.md
@@ -28,7 +28,7 @@ This will create the repo checkout in the directory *~/code/*.
 `mkdir $HOME/buildfarm`
 **CAUTION:** Do not ever change anything in the git repo under that is created in *$HOME/buildfarm/HEAD/exim/*. It will cause the build to fail in the Git-Checkout phase.
 11. Directory permissions must be lax enough for the **exim** user running the test suite to be able to access the files that user farm has checked out.  One recommendation that we know works is to make the **farm** user's home directory be both group and world readable and group and world searchable:
 `mkdir $HOME/buildfarm`
 **CAUTION:** Do not ever change anything in the git repo under that is created in *$HOME/buildfarm/HEAD/exim/*. It will cause the build to fail in the Git-Checkout phase.
 11. Directory permissions must be lax enough for the **exim** user running the test suite to be able to access the files that user farm has checked out.  One recommendation that we know works is to make the **farm** user's home directory be both group and world readable and group and world searchable:

-`chmod og+rx $HOME`.  Additionally, every subdirectory between */* and *$HOME/buildfarm* should have this permissive access.  One thing that these tighter permissions will break, for example, is test 0005, because the sudo'd exim process in the test suite will be unable to read that test config file.
+`chmod og+rx $HOME`.  Additionally, every subdirectory between */* and *$HOME/buildfarm* should have this permissive access.  Some users have reported they must set *$HOME/buildfarm* to 0775 for the test suite to run.  What do these open permissions fix?  One thing that tighter permissions will break, for example, is test 0005, because the sudo'd exim process in the test suite will be unable to read that test config file.

 12. Make sure that your umask is 0022: `umask 0022`.  This also will need to be set in any script you call the run_build.pl script.
 13. Test the configure process by running `./run_build.pl --test --verbose=2 --only-steps=configure`. If there are errors, you'll need to correct them until the process succeeds (ends with OK).  You can repeat this as many times as necessary because test mode does not store the status of the git repo or the status of each stage of the build.
 14. Test the build process by running `./run_build.pl --test --verbose=2 --only-steps=configure,make`. If there are build errors, make adjustments, install additional packages, etc, and repeat the test.
 12. Make sure that your umask is 0022: `umask 0022`.  This also will need to be set in any script you call the run_build.pl script.
 13. Test the configure process by running `./run_build.pl --test --verbose=2 --only-steps=configure`. If there are errors, you'll need to correct them until the process succeeds (ends with OK).  You can repeat this as many times as necessary because test mode does not store the status of the git repo or the status of each stage of the build.
 14. Test the build process by running `./run_build.pl --test --verbose=2 --only-steps=configure,make`. If there are build errors, make adjustments, install additional packages, etc, and repeat the test.