TeamForge script

Overview

Use the teamforge script wherever applicable as it subsumes the functions of the following legacy TeamForge scripts:

bootstrap-data.sh
bootstrap-data.py
bootstrap-reporting-data.sh
bootstrap-reporting-data.py
create-runtime.py
collabnet
migrate.py
post-install.py

Important: Starting from TeamForge 17.8, /opt/collabnet/teamforge/bin/teamforge has been linked to /usr/bin. You can simply run the teamforge command from any path.

Run teamforge script as follows:

teamforge [command] [-s serviceName] [parameter]

For example, the following command displays the status of all the services:

teamforge status

TeamForge components and services

Components

TeamForge comprises of a set of components such as ctfcore, subversion, james, and so on. Some components are always required to be installed, while others are optional. By spreading these components over multiple RPMs, we make sure that users do not have to install everything all the time. Though this is valuable, RPMs alone prove insufficient to manage the components and their inter-dependencies.

Some components do not have a physical representation but are configuration-only.
RPM dependencies are restricted to the local machine only; however, in a distributed installation, dependencies between components must be tracked across servers.

In addition to the physical componentization (using RPMs), there is also a need for a logical componentization of TeamForge.

Services

Services represent a logical component of TeamForge. Such a logical component may either be a feature, which the user explicitly opts to install (for example, CVS) or a technical component (for example, Apache and Logrotate), which other services depend on. Services come with additional metadata which makes it possible to track and manage dependencies to a more fine-grained level.

Deployment dependencies specify which other services need to be deployed locally.
Provided Endpoints specify which network endpoints the service offers.
Required Endpoints specify which network endpoints the service depends on.

As such services are more fine-grained than RPMs and it is common to have a single RPM containing multiple services.

Service life cycle

A service can be in one of the following states:

Uninstalled: A service is uninstalled if the RPM that contains it is not installed. Uninstalled services do not exist as far as TeamForge is concerned.
Undeployed: The RPM containing the service is installed, but the service has not been deployed yet. Deployment is also referred to as "creating the runtime", but is specific to one service.
Dependencies unavailable: The service itself might be available, but at least one of its deployment dependencies is not in "Available" state.
Available: Service is fully functional.

Services that manage data have the following additional states:

Not bootstrapped: Data structures have not been initialized yet.
Not migrated: Data structures are initialized, but data needs to be migrated.

Services that have a daemon have the following additional states:

Dependencies unavailable: The service itself might be available, but at least one of its deployment dependencies is not in "Available" state.
Ports Blocked: The service is impeded from starting up because at least one of the ports it needs is in use by a different process.
Stopped: Service is an auto start-type service, yet is stopped.
Inactive: Service is a demand start-type service and is stopped.
Starting: Service is in the process of starting up.
Available: Service is running and healthy according to its health check.
Unhealthy: Service is running but unhealthy according to its health check.
Dead: Service is supposed to be running, but the process disappeared.
Doomed: Service is technically running, but it will never work properly because some part of it failed to initialize properly.
Stopping: Service is in the process of stopping.

Parameters

teamforge script accepts the following command line parameters:

[-s | --service]

Use the -s parameter to selectively start, stop, and bootstrap a specific service or component. For example, the following command gets you the status of Jboss:

teamforge status -s jboss

[-f | --site_options_file]

Use the -f parameter to pass the site-options.conf file's path as a command line parameter (default is /opt/collabnet/teamforge/etc/site-options.conf).

[--skip-verification]

Pass this parameter if you want to skip environment verification.

[-y | --yes]

Pass this parameter if you want to skip confirmation prompts.

Commands

teamforge script can perform the following actions:

status: Show status of all services. Use the -s parameter to know the status of a specific service.
bootstrap: Bootstrap data (re-create data structures). Use the -s parameter to selectively bootstrap a specific component. Suppose, you did not have SVN on your TeamForge site and if you add SVN while upgrading to TeamForge 16.10. You can now selectively bootstrap SVN alone.
deploy: Deploy service(s).
migrate: Migrate data to latest schema.
provision: Provision/reprovision machine. The "provision" command performs tasks such as creating the runtime, starting and stopping services, bootstrapping (fresh install) or migrating (upgrade) data, deploying services, setting file permissions, setting SELinux permissions, initializing services and so on.
undeploy: Undeploy service(s).
start: Start service(s).
stop: Stop service(s).
verify: Verify environment.
show-endpoints: Show endpoints
show-dependencies: Show deployment dependencies
reinitialize: Reinitializes all the TeamForge services
apply-permissions: Applies the TeamForge filesystem permissions when you restore the TeamForge data in a new server while upgraing to a latest TeamForge version.
snapshot: Dumps relevant diagnostic information to the console (stdout) for each deployed service.

Logging

teamforge script writes entries to /opt/collabnet/teamforge/log/runtime/runtime.log file.