Add comment about umask 0022
[buildfarm-client-wiki.git] / Installation.md
index 60b8bf49ad2e8fff0388ffafa2cd4a345a468645..aea41688f69072dab2592f0c1c513db6971939ea 100644 (file)
@@ -1,5 +1,5 @@
 # Installing Exim BuildFarm Client
-So you want to give back to the Exim project but don't know how?  Being a member of the Exim BuildFarm is one way you can help.  If your distro and version is not on the list that is currently being built, or if your build configuration is drastically different than others with your distro and version, then please consider submitting a request to join the farm.  I would also like to point out that the Debian project has excellent Exim coverage on Experimental their [Build Farm](https://buildd.debian.org/status/package.php?p=exim4&suite=experimental).  We're not discouraging you from joining the Exim BuildFarm if you're Debian or Debian derivative, but merely want to acknowledge the excellent job the Debian project already does with it.
+So you want to give back to the Exim project but don't know how?  Being a member of the Exim BuildFarm is one way you can help.  If your distro and version is not on the list that is currently being built, or if your build configuration is drastically different than others with your distro and version, then please consider submitting a request to join the farm.  I would also like to point out that the Debian project has excellent Exim coverage on their Experimental [Build Farm](https://buildd.debian.org/status/package.php?p=exim4&suite=experimental).  We're not discouraging you from joining the Exim BuildFarm if you're Debian or Debian derivative, but merely want to acknowledge the excellent job the Debian project already does with it.
 
 This Installation page works on the assumption that you have already submitted your [Exim BuildFarm Application](http://eximbuild.mrball.net/cgi-bin/register-form.pl) and the BuildFarm administration has sent you an email with your machine alias (aka _animal_) and secret password, which you will enter in step 9 below.  If you just want to run the build farm client and never submit the results, you call simply run everything with the --test option and it will still work.  If you ever run it without --test, it will still work, but the server will reject the feedback because it's from an unknown _animal_.
 
@@ -24,13 +24,32 @@ This will create the repo checkout in the directory *~/code/*.
 `mkdir $HOME/buildfarm`
 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.  Make the **farm** user's home directory be world readable and world searchable:
 `chmod o+rx $HOME`
-12. 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.
-13. 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.
-14. Test the test suite by running `./run_build.pl --test --verbose=2 --only-steps=configure,make,test --override range_num_tests='1 2'`.  If there are build errors when building the test suite, or runtime errors trying to run the test suite, you may need to install additional packages (you shouldn't though).
-15. If you enabled the documentation building process in the *build-farm.conf*, then you can try to build it with `./run_build.pl --test --verbose=2 --only-steps=configure,make-doc`.  For documentation generation to succeed, it will require extra packages to be installed to support xml, xslt, pdf, and a few other things.
-16. If you can get past each of these steps, then your build farm system meets the minimum requirements.
-17. The official process can be kicked off by running `/home/farm/code/run_cron.sh --run-all`.  This will run the default build configuration, keep track of the git repository status, and upload the build results to the server.
-18. Once that command runs with no complaints, add it to the **farm** user crontab.  You can run it at whatever frequency you choose, I suggest 1 hour.  If a previous instantiation is still running, the script will detect the lockfile and exit so as not to step on each other.
+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.
+15. Test the test suite by running `./run_build.pl --test --verbose=2 --only-steps=configure,make,test --override range_num_tests='1 2'`.  If there are build errors when building the test suite, or runtime errors trying to run the test suite, you may need to install additional packages (you shouldn't though).
+16. If you enabled the documentation building process in the *build-farm.conf*, then you can try to build it with `./run_build.pl --test --verbose=2 --only-steps=configure,make-doc`.  For documentation generation to succeed, it will require extra packages to be installed to support xml, xslt, pdf, and a few other things.
+17. If you can get past each of these steps, then your build farm system meets the minimum requirements.
+18. The official process can be kicked off by running `/home/farm/code/run_cron.sh --run-all`.  This will run the default build configuration, keep track of the git repository status, and upload the build results to the server.
+19. Once that command runs with no complaints, add it to the **farm** user crontab.  You can run it at whatever frequency you choose, I suggest 1 hour.  If a previous instantiation is still running, the script will detect the lockfile and exit so as not to step on each other.
+20. I had a problem running the *run_cron.sh* script in that cron gives a highly sanitized path to the script when it runs it.  I made a second wrapper script to call the first one so I could put path elements in that were needed:
+<pre><code>$ more /home/farm/bin/build_farm.sh
+#!/bin/bash
+export PATH="/usr/local/bin:/sbin:/usr/sbin:$PATH"
+$HOME/code/run_cron.sh --run-all $@
+</code></pre>
+Then I make my cronjob call: `6 * * * * $HOME/bin/build_farm.sh` .... but ...
+21. My cronjob ran great for a couple weeks.  Then another problem popped up running the cron job in that the test portion suddenly started failing with an odd error:
+<pre><code>** runtest error: Failed to open /dev/tty: No such device or address</code></pre>
+This is not a sudo issue.  This is happening because the cron daemon does not give a tty to the cronjob that it starts.  (How the heck did it ever work?)  The runtest script needs a tty in normal operation.  To fix this, I used an old trick of ssh'ing to localhost with the *-tt* option to **force** allocation of a local tty when starting the *build_farm.sh* script.  To do this, you need to configure the **farm** user to use key-based authentication with its own key.  Assuming you have not generated an ssh key yet:
+<pre><code># Press Enter to use defaults for all questions in
+# next command, including no password
+ssh-keygen -t dsa
+cat .ssh/id_dsa.pub >> .ssh/authorized_keys
+# Do the following command once to accept the new host key
+ssh farm@localhost</code></pre>
+Once that works properly, then the cron command changes to:
+<pre><code>6 * * * * ssh -tt farm@localhost $HOME/bin/build_farm.sh</code></pre>
 
 ## Multiple build clients on one machine
 As mentioned above, you can start at step 9.  A second application must be filled out to put the appropriate data in the database because this is treated a separate BuildFarm client:
@@ -44,3 +63,4 @@ As mentioned above, you can start at step 9.  A second application must be fille
 ## Further documentation
 * Details of options in [build-farm.conf](https://github.com/mrballcb/exim-build-farm-client/wiki/BuildConfigConf)
 * Details of [potential testing commandlines](https://github.com/mrballcb/exim-build-farm-client/wiki/TestingBuilds)
+* Details of [building documentation](https://github.com/mrballcb/exim-build-farm-client/wiki/BuildingDocs)