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.
[]: