Use the host:SERVICES and the host:PUBLIC_FQDN tokens to define the services and domain names of your TeamForge site respectively. You can also have unique service-specific FQDNs for services such as Subversion, Git, mail, Codesearch and so on.

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.

[]:

Tags for this page: ctf_19.2 installation upgrade site-options.conf config_files site_admin_tasks security