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.