TeamForge Services and Domain Configuration Tokens

host:SERVICES

The host:SERVICES token is used to define the TeamForge services running on a host.

The syntax for defining the services running on a TeamForge host is:

<hostname>:SERVICES = list of services separated by space

Where <hostname> can be localhost or the server name as returned by the hostname command on the console. The latter is recommended as this allows reuse of the same site-options.conf file across all servers in a distributed setup. Here’s a few examples.

Example—Default Single-server Setup

localhost:SERVICES=ctfcore ctfcore-database ctfcore-datamart etl mail search codesearch subversion eventq redis mongodb rabbitmq

Example—Single-server Setup with Git Integration

localhost:SERVICES=ctfcore ctfcore-database ctfcore-datamart etl mail search codesearch subversion eventq redis mongodb rabbitmq gerrit gerrit-database

Example—Single-server Setup with Review Board Integration

localhost:SERVICES=ctfcore ctfcore-database ctfcore-datamart etl mail search codesearch subversion eventq redis mongodb rabbitmq reviewboard reviewboard-database 

Example—Three-server Setup with Git and Binary Integration

server01:SERVICES=ctfcore etl mail search codesearch eventq redis mongodb rabbitmq binary binary-database
server02:SERVICES=subversion gerrit
server03:SERVICES=ctfcore-database ctfcore-datamart gerrit-database

Example—Distributed Setup with Multiple Git Integration Servers

server01:SERVICES=ctfcore ctfcore-database ctfcore-datamart etl mail search codesearch eventq redis mongodb rabbitmq binary binary-database
server02:SERVICES=subversion
server-03:SERVICES=gerrit gerrit-database
server-04:SERVICES=gerrit gerrit-database

host:PUBLIC_FQDN

The host:PUBLIC_FQDN token is used to define the domain name of your TeamForge site. Assign a public FQDN (optional, but strongly recommended). Make sure there is a DNS A or CNAME record for this FQDN. Here’s a few examples.

server01:PUBLIC_FQDN = teamforge.example.com
server02:PUBLIC_FQDN = scm.example.com

Service-specific FQDNs

Installing TeamForge with service-specific FQDNs (instead of machine-specific host/domain names) is highly recommended so that you will be able to change the system landscape at a later point in time without having any impact on the URLs (in other words, end users do not have to notice or change anything). Service-specific FQDNs come in handy when you want to get started with a single server and later distribute TeamForge across multiple servers as you scale up.

For example, you can create FQDNs specifically for services such as Subversion, Git, mail, Codesearch and so on.

• All such service-specific FQDNs must belong to a single sub domain and it is recommended to create a new sub domain for TeamForge.
• A wildcard SSL cert is required if you are using service-specific FQDNs. SNI SSL cert cannot be used.
• When no custom SSL-certificates are provided, a self-signed wildcard cert is generated for the sub domain.
• When a custom SSL-certificate is provided, the CN of the certificate is verified to be a wildcard CN.

Services and Domain Configuration Examples

• Here’s an example to illustrate the Services and FQDN tokens in a single-server setup with unique service-specific FQDNs for ctfcore, subversion, gerrit and mail.

  # host:SERVICES token
  localhost:SERVICES = ctfcore ctfcore-database ctfcore-datamart etl mail search codesearch reviewboard reviewboard-database reviewboard-adapter binary binary-database cliserver webr webr-database subversion gerrit gerrit-database
  
  # host:PUBLIC_FQDN token
  localhost:PUBLIC_FQDN = app.forge.collab.net
  
  # Service-specific FQDNs
  localhost:ctfcore:PUBLIC_FQDN = ctf.forge.collab.net
  localhost:subversion:PUBLIC_FQDN = svn.forge.collab.net
  localhost:gerrit:PUBLIC_FQDN = git.forge.collab.net
  localhost:mail:PUBLIC_FQDN = mail.forge.collab.net
  

  In this single server setup, all these domain names point to a single server. However, when services are later distributed across multiple servers, all it takes to avoid an end user impact is to adjust these domain names to point to different servers.

• Here’s an example to illustrate the Services and FQDN tokens in a two-server distributed setup with unique service-specific FQDNs for Subversion and Git.

  # host:SERVICES tokens
  apphost:SERVICES = ctfcore ctfcore-database ctfcore-datamart etl mail search codesearch reviewboard reviewboard-database reviewboard-adapter binary binary-database cliserver webr webr-database gerrit-database
  svngithost:SERVICES = subversion gerrit
  
  # host:PUBLIC_FQDN tokens
  apphost:PUBLIC_FQDN=my.app.domain.com
  svngithost:PUBLIC_FQDN=my.app.domain.com
  
  # Service-specific FQDNs for Subversion and Git
  svngithost:subversion:PUBLIC_FQDN=svn.app.domain.com
  svngithost:gerrit:PUBLIC_FQDN=git.app.domain.com
  

  Where:

  • apphost is the TeamForge Application Server.
  • svngithost is the SCM Server that hosts Subversion and Git.