Controlling Tinderbox from within a FreeBSD jail (take 2)

A few months ago, I wrote about how I managed to control my FreeBSD Ports Tinderbox
from within a FreeBSD Jail. The original article is here. I have since refined the way in which
my Ports Tinderbox is managed, and so far, I am quite pleased with the results. I hope this
blog entry is useful to a wider audience.

The problem I was trying to solve was simple:

• I had a machine that did not have a public-facing IP address that was
  powerful enough to be a build server, yet no way to easily control it from
  outside my network.
• I had a public-facing webserver, but less powerful and with much less
  free space than the non-public machine. Not to mention, the non-public
  machine can build FreeBSD Ports for both i386 and amd64 architectures.
  • Note: If you do not currently have a public-facing machine, I strongly
    recommend RootBSD.net as a provider of high quality, no hassle, no headache
    VPS hosting.
• I wanted to keep public-facing services as separate as possible, each
  within their own jail, so no one application can result in disruption of the
  package building system as a whole. From a security point of view, this was
  the most critical part of the goal.
• I needed to be able to build packages for FreeBSD 10-CURRENT, as well as
  the supported branches. Since my public machine does not run -CURRENT, this
  was impossible. My build machine, however, does run -CURRENT.

The specific details of your configuration will certainly vary from mine, so I
will try to be as generic as possible so this post does not target one
specific audience (such as choice of webserver application, database server
preference, etc.).

Througout this post, I will reference three servers, each with a specific
purpose. They are:

• tb: the tinderbox build machine (the non-public machine)
• www: the tinderbox web front-end machine (a jail)
• dbase: the tinderbox database machine (a jail)

A graphical representation of the layout is as follows:

	     ____
	    | tb |
	    |    |
	    |____|_____
	      |	      |
	     [3]     [4] 
	      |	      |
      ~~~~~~~~~~~~~~~~~~~~~
	   Internet
      ~~~~~~~~~~~~~~~~~~~~~
	 [3]___|      |_[4]
	  |		  |
	 \/		  \/
       _____		 _____
      |dbase|		| www |
      |     |< - [2] -  |     |
      |_____|		|_____|
			  ^
			  |
			 [1]

      ~~~~~~~~~~~~~~~~~~~~~
	   Internet
      ~~~~~~~~~~~~~~~~~~~~~

The steps outlined in the above representation are:

1. A port is entered into the web UI to be added to the build queue
2. The port is added to the build queue in the database
3. The build machine (tb) periodically queries the database to see if new
   ports have been added to the queue
4. Upon build completion, the build logs are transferred to the webserver

Installation steps:

• On the “dbase” database server:
  • Install your choice database server
  • Create the user for your Tinderbox database, and configure database
    permissions as necessary, in addition to ensuring connections to the
    database are secure.

• On the “tb” build machine:
  • Install the ports-mgmt/tinderbox port, deselecting the
    WITH_WEBUI option, and selecting the WITH_{DB} (where DB is replaced by
    the database server installed on “dbase”).
  • When ports-mgmt/tinderbox has been installed, run the
    ./tc Setup script. The physical location of where the builds
    take place is important – this must be done on the “tb” machine.
  • Be sure to use the hostname for “dbase” as the database server during
    configuration.
  • Enable the tinderd daemon by adding
    tinderd_enable="YES" to /etc/rc.conf.
  • Configure your build options, jail configurations, and distfile caching
    (as necessary) on the “tb” build machine. This must be done on the
    machine performing the builds.

• On the “www” webserver machine:
  • Install the ports-mgmt/tinderbox port, this time ensuring
    the WITH_WEBUI option is enabled, WITH_{DB} is enabled, and
    WITH_{WEBSERVER} is enabled (where WEBSERVER is replaced by your choice
    webserver software). WITH_CHECK_FOR_ROOT and WITH_LSOF can be disabled,
    as tc is not intended to be run directly from the “www”
    webserver. (Note: You could also copy the tinderbox/scripts/webui
    directory from the “tb” build machine, but building the ports-mgmt/tinderbox
    port will ensure all dependencies are installed.
  • When ports-mgmt/tinderbox has been installed, follow the
    configuration steps relevant to your webserver.
  • Disable tinderd from starting on the webserver, because it
    runs on the “tb” build machine. To disable tinderd, add
    tinderd_enable="NO" to /etc/rc.conf, or remove
    the /usr/local/etc/rc.d/tinderbox rc script (not recommended).
  • Configure the Tinderbox settings (in /usr/local/tinderbox/webui/
    by default), setting the “dbase” database server as the tinderbox
    database, as well as adding the username and password for the Tinderbox
    database.

• Test communications between all services:
  • By this point, if everything is running properly, you should be able to
    access the webserver publicly, add a port to the build queue which, within
    a few minutes, should begin building on the “tb” build machine.

• If necessary:
  • Configure a mechanism through which your Tinderbox build logs can be
    copied from the “tb” build machine to the “www” webserver. This isn’t an
    essential part of this setup, though if you wish for your build logs to be
    publicly accessible, several mechanisms can be used to achieve the
    accessibility of these log. Additionally, packages can be made publicly
    accessible as well, if desired.

Hopefully the information in this post is useful to you. If you found it
helpful, please help others find it in their web searches by clicking the
“Google +1” button at the top of this page.