Traffic Ops

Traffic Ops is quite possible the single most complex and most important Traffic Control component. It has many different configuration options that affect a wide range of other components and their interactions.

Installing

System Requirements

The user must have the following for a successful minimal install:

Guide

  1. Install PostgreSQL Database. For a production install it is best to install PostgreSQL on its own server/virtual machine.

    See also

    For more information on installing PostgreSQL, see their documentation.

    #19 Example PostgreSQL Install Procedure
    yum update -y
    yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
    yum install -y postgresql13-server
    su - postgres -c '/usr/pgsql-13/bin/initdb -A md5 -W' #-W forces the user to provide a superuser (postgres) password
    
  2. Edit /var/lib/pgsql/13/data/pg_hba.conf to allow the Traffic Ops instance to access the PostgreSQL server. For example, if the IP address of the machine to be used as the Traffic Ops host is 192.0.2.1 add the line host  all   all     192.0.2.1/32 md5 to the appropriate section of this file.

  3. Edit the /var/lib/pgsql/13/data/postgresql.conf file to add the appropriate listen_addresses or listen_addresses = '*', set timezone = 'UTC', and start the database

    #20 Starting PostgreSQL with systemd(1)
    systemctl enable postgresql-13
    systemctl start postgresql-13
    systemctl status postgresql-13 # Prints the status of the PostgreSQL service, to prove it's running
    
  4. Build a traffic_ops-version string.rpm file using the instructions under the Building Traffic Control page - or download a pre-built release from the Apache Continuous Integration server.

  5. Install a PostgreSQL client on the Traffic Ops host

    #21 Installing PostgreSQL Client from a Hosted Source
    yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
    
  6. Install the Traffic Ops RPM. The Traffic Ops RPM file should have been built in an earlier step.

    #22 Installing a Generated Traffic Ops RPM
    yum install -y ./dist/traffic_ops-3.0.0-xxxx.yyyyyyy.el7.x86_64.rpm
    

    Note

    This will install the PostgreSQL client, psql as a dependency.

  7. Login to the Database from the Traffic Ops machine. At this point you should be able to login from the Traffic Ops (hostname to in the example) host to the PostgreSQL (hostname pg in the example) host

    #23 Example Login to Traffic Ops Database from Traffic Ops Server
    to-# psql -h pg -U postgres
    Password for user postgres:
    psql (13.2)
    Type "help" for help.
    
    postgres=#
    
  8. Create the user and database. By default, Traffic Ops will expect to connect as the traffic_ops user to the traffic_ops database.

    #24 Creating the Traffic Ops User and Database
    to-# psql -U postgres -h pg -c "CREATE USER traffic_ops WITH ENCRYPTED PASSWORD 'tcr0cks';"
    Password for user postgres:
    CREATE ROLE
    to-# createdb traffic_ops --owner traffic_ops -U postgres -h pg
    Password:
    to-#
    
  9. Now, run the following command as the root user (or with sudo(8)): /opt/traffic_ops/install/bin/postinstall. Some additional files will be installed, and then it will proceed with the next phase of the install, where it will ask you about the local environment for your CDN. Please make sure you remember all your answers and verify that the database answers match the information previously used to create the database.

    #25 Example Output
    to-# /opt/traffic_ops/install/bin/postinstall
    ...
    
    ===========/opt/traffic_ops/app/conf/production/database.conf===========
    Database type [Pg]:
    Database type: Pg
    Database name [traffic_ops]:
    Database name: traffic_ops
    Database server hostname IP or FQDN [localhost]: pg
    Database server hostname IP or FQDN: pg
    Database port number [5432]:
    Database port number: 5432
    Traffic Ops database user [traffic_ops]:
    Traffic Ops database user: traffic_ops
    Password for Traffic Ops database user:
    Re-Enter Password for Traffic Ops database user:
    Writing json to /opt/traffic_ops/app/conf/production/database.conf
    Database configuration has been saved
    ===========/opt/traffic_ops/app/db/dbconf.yml===========
    Database server root (admin) user [postgres]:
    Database server root (admin) user: postgres
    Password for database server admin:
    Re-Enter Password for database server admin:
    ===========/opt/traffic_ops/app/conf/cdn.conf===========
    Generate a new secret? [yes]:
    Generate a new secret?: yes
    Number of secrets to keep? [10]:
    Number of secrets to keep?: 10
    Not setting up ldap
    ===========/opt/traffic_ops/install/data/json/users.json===========
    Administration username for Traffic Ops [admin]:
    Administration username for Traffic Ops: admin
    Password for the admin user:
    Re-Enter Password for the admin user:
    Writing json to /opt/traffic_ops/install/data/json/users.json
    ===========/opt/traffic_ops/install/data/json/openssl_configuration.json===========
    Do you want to generate a certificate? [yes]:
    Country Name (2 letter code): US
    State or Province Name (full name): CO
    Locality Name (eg, city): Denver
    Organization Name (eg, company): Super CDN, Inc
    Organizational Unit Name (eg, section):
    Common Name (eg, your name or your server's hostname):
    RSA Passphrase:
    Re-Enter RSA Passphrase:
    ===========/opt/traffic_ops/install/data/json/profiles.json===========
    Traffic Ops url [https://localhost]:
    Traffic Ops url: https://localhost
    Human-readable CDN Name.  (No whitespace, please) [kabletown_cdn]: blue_cdn
    Human-readable CDN Name.  (No whitespace, please): blue_cdn
    DNS sub-domain for which your CDN is authoritative [cdn1.kabletown.net]: blue-cdn.supercdn.net
    DNS sub-domain for which your CDN is authoritative: blue-cdn.supercdn.net
    Writing json to /opt/traffic_ops/install/data/json/profiles.json
    
    ... much SQL output skipped
    
    Starting Traffic Ops
    Restarting traffic_ops (via systemctl):                    [  OK  ]
    Waiting for Traffic Ops to restart
    Success! Postinstall complete.
    
    Table 48 Explanation of the information that needs to be provided:

    Field

    Description

    Database type

    This requests the type of database to be used. Answer with the default - ‘Pg’ to indicate a PostgreSQL database.

    Database name

    The name of the database Traffic Ops uses to store the configuration information.

    Database server hostname IP or FQDN

    The hostname of the database server (pg in the example).

    Database port number

    The database port number. The default value, 5432, should be correct unless you changed it during the setup.

    Traffic Ops database user

    The username Traffic Ops will use to read/write from the database.

    Password for Traffic Ops

    The password for the database user that Traffic Ops uses.

    Database server root (admin) user name

    Privileged database user that has permission to create the database and user for Traffic Ops…

    Database server root (admin) user password

    The password for the privileged database user.

    Traffic Ops URL

    The URL to connect to this instance of Traffic Ops, usually https://Traffic Ops host

    Human-readable CDN Name

    The name of the first CDN which Traffic Ops will be manage.

    DNS sub-domain for which your CDN is authoritative

    The DNS domain that will be delegated to this Traffic Control CDN.

    Administration username for Traffic Ops

    The Administration (highest privilege) Traffic Ops user to create. Use this user to login for the first time and create other users.

    Password for the admin user

    The password for the administrative Traffic Ops user.

Deprecated since version ATCv6: The postinstall script is now written in Python. If you run into issues with the postinstall script, you are encouraged to file an issue at https://github.com/apache/trafficcontrol/issues/new/choose. The original Perl postinstall script is deprecated and will be removed in a future ATC release. To use the deprecated version anyway, run /opt/traffic_ops/install/bin/_postinstall.pl directly instead of /opt/traffic_ops/install/bin/postinstall.

The postinstall script can also be run non-interactively using traffic_ops/install/bin/input.json. To use it, first change the values to match your environment, then pass it to the postinstall script:
#26 Postinstall in Automatic (-a) mode
/opt/traffic_ops/install/bin/postinstall -a --cfile /opt/traffic_ops/install/bin/input.json

Deprecated since version ATCv6: Once the Perl script is removed, the values in input.json for the "hidden" properties will be changed from "1" and "0" to true and false.

Upgrading

To upgrade from older Traffic Ops versions, stop the service, use yum(8) to upgrade to the latest available Traffic Ops package, and use the admin tool to perform the database upgrade.

Tip

In order to upgrade to the latest version of Traffic Ops, please be sure that you have first upgraded to the latest available minor or patch version of your current release. For example, if your current Traffic Ops version is 3.0.0 and version 3.1.0 is available, you must first upgrade to 3.1.0 before proceeding to upgrade to 4.0.0. (Specifically, this means running all migrations, traffic_ops/app/db/seeds.sql, and traffic_ops/app/db/patches.sql for the latest of your current major version - which should be handled by the admin tool). The latest migration available before the release of 4.0.0 (pending at the time of this writing) was traffic_ops/app/db/migrations/20180814000625_remove_capabilities_for_reseed.sql, so be sure that migrations up to this point have been run before attempting to upgrade Traffic Ops.

See also

app/db/admin for more details about admin.

#27 Sample Script for Upgrading Traffic Ops
systemctl stop traffic_ops
yum upgrade traffic_ops
pushd /opt/traffic_ops/app/
./db/admin --env production upgrade
popd

After this completes, see Guide for instructions on running the postinstall script. Once the postinstall script, has finished, run the following command as the root user (or with sudo(8)): systemctl start traffic_ops to start the service.

Upgrading to 6.0

As of Apache Traffic Control 6.0, Traffic Ops supports PostgreSQL version 13.2. In order to migrate from the prior PostgreSQL version 9.6, it is recommended to use the pg_upgrade tool.

Running

While this section contains instructions for running Traffic Ops manually, the only truly supported method is via systemd(8), e.g. systemctl start traffic_ops (this method starts the program properly and uses its default configuration file locations).

traffic_ops_golang

traffic_ops_golang [--version] [--plugins] [--api-routes] --cfg CONFIG_PATH --dbcfg DB_CONFIG_PATH [--riakcfg RIAK_CONFIG_PATH]

--cfg CONFIG_PATH

This mandatory command line flag specifies the absolute or relative path to the configuration file to be used by Traffic Ops - cdn.conf.

--dbcfg DB_CONFIG_PATH

This mandatory command line flag specifies the absolute or relative path to a configuration file used by Traffic Ops to establish connections to the PostgreSQL database - database.conf

--plugins

List the installed plugins and exit.

--api-routes

Print information about all API routes and exit. If also used with the --cfg option, also print out the configured routing blacklist information from cdn.conf.

--riakcfg RIAK_CONFIG_PATH

Deprecated since version 6.0: This optional command line flag specifies the absolute or relative path to a configuration file used by Traffic Ops to establish connections to Riak when used as the Traffic Vault backend - riak.conf. Please use "traffic_vault_backend": "riak" and "traffic_vault_config": {...} (with the contents of riak.conf) instead.

Implementation Detail

The name of this flag is derived from the current database used in the implementation of Traffic Vault - Riak KV.

--version

Print version information and exit.

Configuring

traffic_ops_golang uses several configuration files, but the most important of these is cdn.conf.

Configuration Files

cdn.conf

This file deals with the configuration parameters of running Traffic Ops itself. It is a JSON-format set of options and their respective values. traffic_ops_golang will use whatever file is specified by its --cfg option. The keys of the file are described below.

acme_accounts

This is an optional array of objects to define ref:external_account_binding information to an existing ACME account. The acme_provider and user_email combination must be unique.

New in version 5.1.

acme_provider

The certificate provider. This field needs to correlate to the AuthType field for each certificate so the renewal functionality knows which provider to use.

user_email

The email used to set up the account with the provider.

acme_url

The URL for the ACME.

kid

The key ID provided by the ACME provider for ref:external_account_binding.

hmac_encoded

The HMAC key provided by the ACME provider for ref:external_account_binding. This should be in Base64 URL encoded.

acme_renewal

This object contains the information for the automatic renewal script for certificates.

New in version 5.1.

renew_days_before_expiration

Set the number of days before expiration date to renew certificates.

summary_email

The email address to use for summarizing certificate expiration and renewal status. If it is blank, no email will be sent.

default_certificate_info

This is an optional object to define default values when generating a self signed certificate when an HTTPS delivery service is created or updated. If this is an empty object or not present in the cdn.conf then the term “Placeholder” will be used for all fields.

business_unit

An optional field which, if present, will represent the business unit for which the SSL certificate was generated

city

An optional field which, if present, will represent the resident city of the generated SSL certificate

organization

An optional field which, if present, will represent the organization for which the SSL certificate was generated

country

An optional field which, if present, will represent the resident country of the generated SSL certificate

state

An optional field which, if present, will represent the resident state or province of the generated SSL certificate

geniso

This object contains configuration options for system ISO generation.

iso_root_path

Sets the filesystem path to the root of the ISO generation directory. For default installations, this should usually be set to /opt/traffic_ops/app/public.

Deprecated since version ATCv6: The geniso.iso_root_path configuration option is unused now that Traffic Ops is rewritten from Perl to Golang and will be removed in a future ATC release.

See also

Generate ISO

hypnotoad

This is a group of options that mainly no longer have any meaning..

group

Serves no known purpose anymore.

heartbeat_timeout

Serves no known purpose anymore.

listen

This must always be an array containing a single string. This very odd string is apparently a URL. The scheme of the URL doesn’t matter, as traffic_ops_golang ignores that and always uses HTTPS. The host (and optionally port) of the URL used to have a purpose, but no longer does. The “cert” query parameter sets the location of the SSL certificate to use for encrypting connections, while the “key” query parameter is the certificate’s corresponding private key. The default configuration file also has the “verify” query parameter which serves no known purpose anymore.

pid_file

Serves no known purpose anymore.

user

Serves no known purpose anymore.

workers

Serves no known purpose anymore.

inactivity_timeout

Serves no known purpose anymore.

influxdb_conf_path

An optional field which gives traffic_ops_golang the absolute or relative path to an influxdb.conf file. Default if not specified is to first check if the MOJO_MODE environment variable is set. If it is, then Traffic Ops will look in the current working directory for a subdirectory named conf/, then inside that for a subdirectory with the name that is the value of the MOJO_MODE variable, and inside that directory for a file named influxdb.conf. If MOJO_MODE is not set, then Traffic Ops will look for a file named influxdb.conf in the same directory as this cdn.conf file.

New in version 4.0.

Warning

While relative paths are allowed, they are discouraged, as the path will be relative to the working directory of the traffic_ops_golang process itself, not relative to the cdn.conf configuration file, which can be confusing.

ldap_conf_location

An optional field which gives traffic_ops_golang the absolute or relative path to an ldap.conf file. Default if not specified is a file named ldap.conf in the same directory as this cdn.conf file.

Warning

While relative paths are allowed, they are discouraged, as the path will be relative to the working directory of the traffic_ops_golang process itself, not relative to the cdn.conf configuration file, which can be confusing.

lets_encrypt

New in version 4.1.

user_email

A required email address to create an account with Let’s Encrypt or to receive expiration updates. If this is not included then rate limits may apply for the number of certificates.

send_expiration_email

A boolean option to send email summarizing certificate expiration status

Deprecated since version 5.1: Future versions of Traffic Ops will not support this legacy configuration option, see acme_renewal: { summary_email: <string> } instead.

convert_self_signed

A boolean option to convert self signed to Let’s Encrypt certificates as they expire. This only works for certificates labeled as Self Signed in the Certificate Source field.

renew_days_before_expiration

Set the number of days before expiration date to renew certificates.

Deprecated since version 5.1: Future versions of Traffic Ops will not support this legacy configuration option, see acme_renewal: { renew_days_before_expiration: <int> } instead.

environment

This specifies which Let’s Encrypt environment to use: ‘staging’ or ‘production’. It defaults to ‘production’.

portal

This section provides information regarding a connected UI with which users interact, so that emails can include links to it.

base_url

This URL should be the root and/or landing page of the UI. For Traffic Portal instances, this should include the fragment part of the URL, e.g. https://trafficportal.infra.ciab.test/#!/.

docs_url

The actual use of this URL is unknown, but supposedly it ought to point to the documentation for the Traffic Control instance. It’s hard to imagine a fantastic reason this shouldn’t just always be https://traffic-control-cdn.readthedocs.io

email_from

Most emails sent from the Traffic Ops server will use to.email_from, but specifically password reset requests (which contain a link to a fragment under portal.base_url) will instead use this as the value of their From field.

pass_reset_path

A path to be added to base_url that is the URL of the UI’s password reset interface. For Traffic Portal instances, this should always be set to “user”.

user_register_path

A path to be added to base_url that is the URL of the UI’s new user registration interface. For Traffic Portal instances, this should always be set to “user”.

secrets

This is an array of strings, which cannot be empty. The first secret in the array is used to encrypt Traffic Ops authentication cookies - multiple Traffic Ops instances serving the same CDN need to share secrets in order for users logged into one to be able to use their cookie as authentication with other instances.

smtp

This optional section contains options for connecting to and authenticating with an SMTP server for sending emails. If this section is undefined (or if enabled is explicitly false), Traffic Ops will not be able to send emails and certain Traffic Ops API endpoints that depend on that functionality will fail to operate.

New in version 4.0.

address

This is the address of the SMTP which will be used to send emails. Should include the port number, e.g. "localhost:25" for sendmail(8) on the Traffic Ops server.

enabled

A boolean flag that determines whether or not connection to an SMTP ought to be allowed. Whatever the settings of the other fields in the smtp object, email cannot and will not be sent if this is false.

password

The password to be used when authenticating with the SMTP server.

user

The name of the user to be used when authenticating with the SMTP server.

Note

The SMTP integration currently only supports Login Auth.

to

Contains information to identify Traffic Ops in a network sense.

base_url

This field is used to identify the location for the now-removed Traffic Ops UI. It no longer serves any purpose.

email_from

Sets the address that will appear in the From field of Emails sent by Traffic Ops.

no_account_found_msg

When a password reset is requested for an email address not registered to any known user, this is the message that will be sent to that email address.

traffic_ops_golang

This group configuration options is used exclusively by traffic_ops_golang.

crconfig_emulate_old_path

An optional boolean that controls the value of a part of Snapshots that report what Traffic Ops API endpoint is used to generate Snapshots. If this is true, it forces Traffic Ops to report that a legacy, deprecated endpoint is used, whereas if it’s false Traffic Ops will report the actual, current endpoint. Default if not specified is false.

Deprecated since version 3.0: Future versions of Traffic Ops will not support this legacy configuration option, and will always report the current endpoint.

crconfig_snapshot_use_client_request_host

An optional boolean which controls the value of the Traffic Ops server’s URL as inserted into Snapshots. If this is true, then the value used will be taken from the Host header of the request that generated the Snapshot. If it’s false, then it will instead use the value of the global “tm.url” Parameter. Default if not specified is false.

Deprecated since version 3.0: Future versions of Traffic Ops will not support this legacy configuration option, and will always use the global “tm.url” Parameter.

db_conn_max_lifetime_seconds

An optional field that sets the maximum lifetime in seconds of any given connection to the Traffic Ops Database. If set to zero, connections are held open until explicitly closed. Default if not specified is the value of DBConnMaxLifetimeSecondsDefault.

db_max_idle_connections

An optional limit on the number of connections to the Traffic Ops Database to keep alive while idle. If this is less than max_db_connections, that number will be used instead - even if this field is unset and using its default. Default if not specified is the value of DBMaxIdleConnectionsDefault.

db_query_timeout_seconds

An optional field specifying a timeout on database transactions (not actually single queries in most cases) within API route handlers. Effectively this is a timeout on a single handler’s ability to interact with the Traffic Ops Database. Default if not specified is the value of DefaultDBQueryTimeoutSecs.

idle_timeout

An optional timeout in seconds for idle client connections to Traffic Ops. If set to zero, the value of read_timeout will be used instead. If both are zero, then the value of read_header_timeout will be used. If all three fields are zero, there is no timeout and connections will be kept alive indefinitely - not recommended. Default if not specified is zero.

insecure

An optional boolean which, if set to true will cause Traffic Ops to skip verification of client certificates whenever necessary/possible. If set to false, the normal verification behavior is exhibited. Default if not specified is false.

Deprecated since version 5.0: Future versions of Traffic Ops will not support this legacy configuration option, see tls_config: { InsecureSkipVerify: <bool> } instead

log_location_debug

This optional field, if specified, should either be the location of a file to which debug-level output will be logged, or one of the special strings "stdout" which indicates that STDOUT should be used, "stderr" which indicates that STDERR should be used or "null" which indicates that no output of this level should be generated. An empty string ("") and literally null are equivalent to "null". Default if not specified is "null".

log_location_error

This optional field, if specified, should either be the location of a file to which error-level output will be logged, or one of the special strings "stdout" which indicates that STDOUT should be used, "stderr" which indicates that STDERR should be used or "null" which indicates that no output of this level should be generated. An empty string ("") and literally null are equivalent to "null". Default if not specified is "null". This field is also used to determine where server profiling statistics are written. Assuming profiling_enabled is true and profiling_location is unset, if this field’s value is given as a path to a regular file, a file named profiling will be written to the same directory containing the profiling information - overwriting any existing files by that name.

log_location_event

This optional field, if specified, should either be the location of a file to which event-level output will be logged, or one of the special strings "stdout" which indicates that STDOUT should be used, "stderr" which indicates that STDERR should be used or "null" which indicates that no output of this level should be generated. An empty string ("") and literally null are equivalent to "null". Default if not specified is "null".

log_location_info

This optional field, if specified, should either be the location of a file to which informational-level output will be logged, or one of the special strings "stdout" which indicates that STDOUT should be used, "stderr" which indicates that STDERR should be used or "null" which indicates that no output of this level should be generated. An empty string ("") and literally null are equivalent to "null". Default if not specified is "null".

log_location_warning

This optional field, if specified, should either be the location of a file to which warning-level output will be logged, or one of the special strings "stdout" which indicates that STDOUT should be used, "stderr" which indicates that STDERR should be used or "null" which indicates that no output of this level should be generated. An empty string ("") and literally null are equivalent to "null". Default if not specified is "null".

max_db_connections

An optional limit on the number of allowed concurrent connections to the Traffic Ops Database. If it is less than or equal to zero, there is no limit. Default if not specified is zero.

oauth_client_secret

An optional secret string to be shared with OAuth-capable clients attempting to authenticate via OAuth. The default behavior if this is not defined - or is an empty string ("") or null is to disallow authentication via OAuth.

Warning

OAuth support in Traffic Ops is still in its infancy, so most users are advised to avoid defining this field without good cause.

plugins

An optional array of enabled plugin names. These names must be unique. Note that a plugin that is installed will not be used unless its name appears in this list - thus “enabling” it. If not specified no plugins will be enabled.

plugin_config

This optional object maps plugin names - which must appear in the plugins array - to arbitrary JSON configurations for said plugins. It is up to the plugins themselves to parse these configurations. The default if not specified is no configuration information, somewhat obviously.

plugin_shared_config

This optional object is just an arbitrary JSON object that is converted into a native object and made available to any and all loaded and enabled plugins. A typical use-case for this field is avoiding repetition of identical configuration in plugin_config. The default if not specified is null.

port

Sets the port on which Traffic Ops will listen for incoming connections.

profiling_enabled

An optional boolean which, if true will enable the gathering of profiling statistics on the Traffic Ops server. Default if not specified is false.

profiling_location

An optional string which, if set, should be the absolute path (relative paths are allowed but not recommended) to a file where profiling statistics for the Traffic Ops server will be written. If profiling_enabled is true but this is not specified, or is an empty string ("") or null, then a file named “profiling” will be created or overwritten in the same directory as the file specified in log_location_error. If that file is not a regular file, then Traffic ops will instead create a temporary directory and write profiling statistics to a file named “profiling” within that directory.

proxy_keep_alive

Serves no known purpose anymore.

proxy_read_handler_timeout

Serves no known purpose anymore.

proxy_timeout

Serves no known purpose anymore.

proxy_tls_timeout

Serves no known purpose anymore.

read_header_timeout

An optional timeout in seconds before which Traffic Ops must be able to finish reading the headers of an incoming request or it will drop the connection. If set to zero, there is no timeout. Default if not specified is zero.

read_timeout

An optional timeout in seconds before which Traffic Ops must be able to finish reading an entire incoming request (including body) or it will drop the connection. If set to zero, there is no timeout. Default if not specified is zero.

request_timeout

An optional timeout in seconds that serves as the maximum time each Traffic Ops middleware can take to execute. If it is exceeded, the text “server timed out” is served in place of a response. If set to 0, 60 is used instead. Default if not specified is 60.

riak_port

An optional field that sets the port on which Traffic Ops will try to contact Traffic Vault for storage and retrieval of sensitive encryption keys.

Deprecated since version 6.0: Please use a "port" field in traffic_vault_config instead when using "traffic_vault_backend": "riak".

Implementation Detail

The name of this field is derived from the current database used in the implementation of Traffic Vault - Riak KV.

whitelisted_oauth_url

An optional array of URLs which are allowed to authenticate Traffic Ops users via OAuth. The default behavior if this field is not defined is to not allow OAuth authentication.

Warning

OAuth support in Traffic Ops is still in its infancy, so most users are advised to avoid defining this field without good cause.

write_timeout

An optional timeout in seconds set on handlers. After reading a request’s header, the server will have this long to send back a response. If set to zero, there is no timeout. Default if not specified is zero.

traffic_vault_backend

New in version 6.0: Optional. The name of which backend to use for Traffic Vault. Currently, the only supported backend is “riak”.

traffic_vault_config

New in version 6.0: Optional. The JSON configuration which is unique to the chosen Traffic Vault backend. See Traffic Vault Administration for the configuration options for each supported backend.

routing_blacklist

Optional configuration for explicitly disabling any routes via disabled_routes.

New in version 4.0.

perl_routes

Serves no known purpose anymore.

Deprecated since version 6.0: This was used back when Traffic Ops was still in the process of being rewritten from Perl. It serves no purpose anymore, and will be removed in the future.

disabled_routes

A list of API route IDs to disable. Requests matching these routes will receive a 503 response. To find the route ID for a given path you would like to disable, run ./traffic_ops_golang using the --api-routes option to view all the route information, including route IDs and paths.

ignore_unknown_routes

If false (default) return an error and prevent startup if unknown route IDs are found. Otherwise, log a warning and continue startup.

tls_config

An optional stanza for TLS configuration. The values of which conform to the crypto/tls.Config structure.

use_ims

New in version 5.0: This is an optional boolean value to enable the handling of the “If-Modified-Since” HTTP request header. Default: false

role_based_permissions

Toggle whether or not to use Role Based Permissions.

New in version 6.1: The blueprint can be seen Pull Request 5848

disable_auto_cert_deletion

This optional boolean value can be used to disable the automatic deletion of certificates for Delivery Services that no longer exist (which happens after a CDN Snapshot is taken). Default: false.

New in version 6.1.

Example cdn.conf
{
    "hypnotoad" : {
        "listen" : [
            "https://[::]:60443?cert=/etc/pki/tls/certs/localhost.crt&key=/etc/pki/tls/private/localhost.key&verify=0x00&ciphers=AES128-GCM-SHA256:HIGH:!RC4:!MD5:!aNULL:!EDH:!ED"
        ],
        "user" : "trafops",
        "group" : "trafops",
        "heartbeat_timeout" : 20,
        "pid_file" : "/var/run/traffic_ops.pid",
        "workers" : 12
    },
    "traffic_ops_golang" : {
        "port" : "443",
        "proxy_timeout" : 60,
        "proxy_keep_alive" : 60,
        "proxy_tls_timeout" : 60,
        "proxy_read_header_timeout" : 60,
        "read_timeout" : 60,
        "request_timeout" : 60,
        "read_header_timeout" : 60,
        "write_timeout" : 60,
        "idle_timeout" : 60,
        "log_location_error": "/var/log/traffic_ops/error.log",
        "log_location_warning": "",
        "log_location_info": "",
        "log_location_debug": "",
        "log_location_event": "/var/log/traffic_ops/access.log",
        "max_db_connections": 20,
        "db_max_idle_connections": 15,
        "db_conn_max_lifetime_seconds": 60,
        "db_query_timeout_seconds": 20,
        "whitelisted_oauth_urls": [],
        "oauth_client_secret": "",
        "traffic_vault_backend": "",
        "traffic_vault_config": {},
        "routing_blacklist": {
            "ignore_unknown_routes": false,
            "disabled_routes": []
        },
        "profiling_enabled": false,
        "supported_ds_metrics": [ "kbps", "tps_total", "tps_2xx", "tps_3xx", "tps_4xx", "tps_5xx" ],
        "tls_config": {
            "MinVersion": 769
        }
    },
    "disable_auto_cert_deletion": false,
    "use_ims": false,
    "role_based_permissions": false,
    "cors" : {
        "access_control_allow_origin" : "*"
    },
    "to" : {
        "base_url" : "http://localhost:3000",
        "email_from" : "no-reply@traffic-ops-domain.com",
        "no_account_found_msg" : "A Traffic Ops user account is required for access. Please contact your Traffic Ops user administrator."
    },
    "portal" : {
        "base_url" : "https://localhost/#!/",
        "docs_url" : "https://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_portal/usingtrafficportal.html",
        "email_from" : "no-reply@traffic-portal-domain.com",
        "pass_reset_path" : "user",
        "user_register_path" : "user"
    },
    "secrets" : [
        "mONKEYDOmONKEYSEE."
    ],
    "inactivity_timeout" : 60,
    "smtp" : {
        "enabled" : false,
        "user" : "",
        "password" : "",
        "address" : ""
    },
    "inactivity_timeout" : 60,
    "lets_encrypt" : {
        "user_email" : "",
        "send_expiration_email": false,
        "convert_self_signed": false,
        "renew_days_before_expiration": 30,
        "environment": "production"
    },
    "acme_renewal": {
        "summary_email": "",
        "renew_days_before_expiration": 30
    },
    "acme_accounts": [
        {
            "acme_provider" : "",
            "user_email" : "",
            "acme_url" : "",
            "kid" : "",
            "hmac_encoded" : ""
        }
    ],
    "default_certificate_info" : {
        "business_unit" : "",
        "city" : "",
        "organization" : "",
        "country" : "",
        "state" : ""
    }
}

database.conf

This file deals with configuration of the Traffic Ops Database; in particular it tells Traffic Ops how to connect with the database for its current environment. traffic_ops_golang will read this file in from the path pointed to by its --dbcfg flag. database.conf is encoded as a JSON object, and its keys are described below.

dbname

The name of the PostgreSQL database used. Typically different databases are used for different environments, e.g. “trafficops_test”, “trafficops”, etc. Many environments choose to use traffic_ops.

description

An optional, human friendly description of the database. Generally this should just describe the purpose of the database e.g. “This database is used for integration testing with our toolset”.

hostname

The hostname (FQDN) of the server that runs the Traffic Ops Database.

password

The password to use when authenticating with the Traffic Ops database. In a typical install process, the postinstall script will ask for a password to use for this connection, and this should match that.

port

The port number (as a string) on which the Traffic Ops Database is listening for incoming connections. traffic_ops_golang ignores this and always uses the default PostgreSQL port (5432).

ssl

A boolean that sets whether or not the Traffic Ops Database encrypts its connections with SSL.

type

A string that gives the “type” of database pointed to by all the other options. Once upon a time it was possible for this to either be “mysql” or “postgres”, but the only valid value anymore is “postgres” - and traffic_ops_golang ignores this field entirely (and in fact doesn’t even care if it’s defined at all) and only supports “postgres” databases.

user

The name of the user as whom to connect to the database. In a typical install process, the postinstall script will ask for the name of a user to set up for the Traffic Ops Database, and this should match that. Many environments choose to use traffic_ops.

Example database.conf
{
    "description": "Local PostgreSQL database on port 5432",
    "dbname": "traffic_ops",
    "hostname": "localhost",
    "user": "traffic_ops",
    "password": "password",
    "port": "5432",
    "ssl": false,
    "type": "Pg"
}

influxdb.conf

This file deals with configuration of the InfluxDB cluster that serves Traffic Stats; specifically it tells Traffic Ops how to authenticate with the InfluxDB cluster and which measurements to check. traffic_ops_golang will look for this file at the path given by the value of influx_db_conf_path in cdn.conf. This file is encoded as a JSON object, and its keys are described below.

See also

For more information about InfluxDB, see the InfluxDB documentation.

cache_stats_db_name

This field sets the name of the “database” (measurement) used to query for Cache Group statistics. traffic_ops_golang will default to "cache_stats" if this field is not defined. It is recommended that this field not be defined.

Danger

The only valid value for this is "cache_stats", if it is anything else Traffic Stats data for Cache Group statistics will be inaccessible through the Traffic Ops API.

deliveryservice_stats_db_name

This field sets the name of the “database” (measurement) used to query for Delivery Service statistics. traffic_ops_golang will default to "deliveryservice_stats" if this field is not defined. It is recommended that this field not be defined.

Danger

The only valid value for this is "deliveryservice_stats", if it is anything else Traffic Stats data for Delivery Service statistics will be inaccessible through the Traffic Ops API.

password

Sets the password to use when authenticating with InfluxDB clusters.

secure

An optional boolean that sets whether or not to use SSL encrypted connections to the InfluxDB cluster (the InfluxDB servers would need to be configured to use SSL). Default if not specified is false.

user

Sets the user name as whom to authenticate with InfluxDB clusters.

Example influxdb.conf
{
    "user": "influxuser",
    "password": "password",
    "deliveryservice_stats_db_name": "deliveryservice_stats",
    "cache_stats_db_name": "cache_stats",
    "secure": false
}

ldap.conf

This file defines methods of connection to an LDAP server and semantics for searching for users on it for the purpose of authentication. traffic_ops_golang will look for this file at the path given by the value of ldap_conf_location in cdn.conf. ldap.conf’s contents are a JSON-encoded object, the keys of which are detailed below.

See also

For more information on LDAP see the LDAP Wikipedia page and RFC 4511.

admin_dn

The LDAP DN of the administrative user.

admin_pass

The password of the administrative user for the LDAP.

host

The full hostname of the LDAP server, preceded by a scheme (only ldap:// and ldaps:// are supported), optionally including port number.

insecure

A boolean that tells Traffic Ops whether or not to verify the certificate chain of the LDAP server if it uses TLS-encrypted communications.

ldap_timeout_secs

Sets a timeout in seconds for connections to the LDAP.

search_base

The directory relative to which searches for users should be conducted.

search_query

A query to be used to search for users. The string %s should appear exactly once in this string, where user names will be inserted procedurally by the handler for LDAP logins.

Example ldap.conf
{
   "admin_pass" : "password",
   "search_base" : "dc=prefix,dc=domain,dc=suffix",
   "admin_dn" : "user@prefix.domain.suffix",
   "host" : "ldaps://host:[port]",
   "search_query" : "(&(objectCategory=person)(objectClass=user)(userName=%s))",
   "insecure" : false,
   "ldap_timeout_secs" : 20
}

riak.conf

Deprecated since version 6.0: The riak.conf configuration file and associated --riakcfg flag have been deprecated and will be removed from Traffic Control in the future. Please use "traffic_vault_backend": "riak" and put the existing contents of riak.conf into "traffic_vault_config": {...} in cdn.conf instead.

This file sets authentication options for connections to Riak when used as the Traffic Vault backend. traffic_ops_golang will look for this file at the path given by the value of the --riakcfg flag as passed on startup. The contents of riak.conf are encoded as a JSON object, the keys of which are described in Riak (deprecated).

Implementation Detail

The name of this file is derived from the current database used in the implementation of Traffic Vault - Riak KV.

Installing the SSL Certificate

By default, Traffic Ops runs as an SSL web server (that is, over HTTPS), and a certificate needs to be installed.

Self-signed Certificate (Development)

#28 Example Procedure
$ openssl genrsa -des3 -passout pass:x -out localhost.pass.key 2048
Generating RSA private key, 2048 bit long modulus
...
$ openssl rsa -passin pass:x -in localhost.pass.key -out localhost.key
writing RSA key
$ rm localhost.pass.key

$ openssl req -new -key localhost.key -out localhost.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US<enter>
State or Province Name (full name) []:CO<enter>
Locality Name (eg, city) [Default City]:Denver<enter>
Organization Name (eg, company) [Default Company Ltd]: <enter>
Organizational Unit Name (eg, section) []: <enter>
Common Name (eg, your name or your server's hostname) []: <enter>
Email Address []: <enter>

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: pass<enter>
An optional company name []: <enter>
$ openssl x509 -req -sha256 -days 365 -in localhost.csr -signkey localhost.key -out localhost.crt
Signature ok
subject=/C=US/ST=CO/L=Denver/O=Default Company Ltd
Getting Private key
$ sudo cp localhost.crt /etc/pki/tls/certs
$ sudo cp localhost.key /etc/pki/tls/private
$ sudo chown trafops:trafops /etc/pki/tls/certs/localhost.crt
$ sudo chown trafops:trafops /etc/pki/tls/private/localhost.key

Certificate from Certificate Authority (Production)

Note

You will need to know the appropriate answers when generating the certificate request file trafficopss.csr.

#29 Example Procedure
$ openssl genrsa -des3 -passout pass:x -out trafficops.pass.key 2048
Generating RSA private key, 2048 bit long modulus
...
$ openssl rsa -passin pass:x -in trafficops.pass.key -out trafficops.key
writing RSA key
$ rm localhost.pass.key

Generate the CSR file needed for CA request

#30 Example Certificate Signing Request File Generation
$ openssl req -new -key trafficops.key -out trafficops.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]: <enter country code>
State or Province Name (full name) []: <enter state or province>
Locality Name (eg, city) [Default City]: <enter locality name>
Organization Name (eg, company) [Default Company Ltd]: <enter organization name>
Organizational Unit Name (eg, section) []: <enter organizational unit name>
Common Name (eg, your name or your server's hostname) []: <enter server's hostname name>
Email Address []: <enter e-mail address>

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <enter challenge password>
An optional company name []: <enter>
$ sudo cp trafficops.key /etc/pki/tls/private
$ sudo chown trafops:trafops /etc/pki/tls/private/trafficops.key

You must then take the output file trafficops.csr and submit a request to your CA. Once you get approved and receive your trafficops.crt file

#31 Certificate Installation
sudo cp trafficops.crt /etc/pki/tls/certs
sudo chown trafops:trafops /etc/pki/tls/certs/trafficops.crt

If necessary, install the CA (Certificate Authority) certificate’s `.pem`` and .crt files in /etc/pki/tls/certs.

You will need to update cdn.conf with any necessary changes.

#32 Sample ‘listen’ Line When Path to trafficops.crt and trafficops.key are Known
'hypnotoad' => ...
    'listen' => 'https://[::]:443?cert=/etc/pki/tls/certs/trafficops.crt&key=/etc/pki/tls/private/trafficops.key&ca=/etc/pki/tls/certs/localhost.ca&verify=0x00&ciphers=AES128-GCM-SHA256:HIGH:!RC4:!MD5:!aNULL:!EDH:!ED'
    ...

Managing Traffic Ops Extensions

Traffic Ops supports “Check Extensions”, which are analytics scripts that collect and display information as columns in the table under Monitor ‣ Cache Checks in Traffic Portal.

See also

Traffic Ops also supports a more involved type of extension in the form of Go Plugins.

Check Extensions

Check Extensions are scripts that, after registering with Traffic Ops, have a column reserved in the Monitor ‣ Cache Checks view and usually run periodically using cron(8). Each extension is a separate executable located in $TO_HOME/bin/checks/ on the Traffic Ops server (though all of the default extensions are written in Perl, this is in no way a requirement; they can be any valid executable). The currently registered extensions can be listed by running /opt/traffic_ops/app/bin/extensions -a. Some extensions automatically registered with the Traffic Ops database (to_extension table) at install time (see traffic_ops/app/db/seeds.sql). However, cron(8) must still be configured to run these checks periodically. The extensions are called like so:

#33 Example Check Extension Call
$TO_HOME/bin/checks/<name>  -c "{\"base_url\": \",https://\"<traffic_ops_ip>\", \"check_name\": \"<check_name>\"}" -l <log level>
name

The basename of the extension executable

traffic_ops_ip

The IP address or FQDN of the Traffic Ops server

check_name

The name of the check e.g. CDU, CHR, DSCP, MTU, etc…

log_level

A whole number between 1 and 4 (inclusive), with 4 being the most verbose. Implementation of this field is optional

It is the responsibility of the check extension script to iterate over the servers it wants to check and post the results. An example script might proceed by logging into the Traffic Ops server using the HTTPS base_url provided on the command line. The script is hard-coded with an authentication token that is also provisioned in the Traffic Ops User database. This token allows the script to obtain a cookie used in later communications with the Traffic Ops API. The script then obtains a list of all cache servers to be polled by accessing servers. This list is then iterated, running a command to gather the stats from each server. For some extensions, an HTTP GET request might be made to the ATS astats plugin, while for others the server might be pinged, or a command might run over ssh(1). The results are then compiled into a numeric or boolean result and the script submits a POST request containing the result back to Traffic Ops using servercheck. A check extension can have a column of checkmark‘s and X‘s (CHECK_EXTENSION_BOOL) or a column that shows a number (CHECK_EXTENSION_NUM).

Check Extensions Installed by Default

CDU

This check shows how much of the available total cache disk is in use. A “warm” cache server should show 100.00.

CHR

The cache hit ratio for the cache in the last 15 minutes (the interval is determined by the cron(8) entry).

DSCP

Checks if the returning traffic from the cache has the correct DSCP value as assigned in the Delivery Service. (Some routers will overwrite DSCP)

MTU

Checks if the Traffic Ops host (if that is the one running the check) can send and receive 8192B packets to the ip_address of the server in the server table.

ORT

The ORT column shows how many changes the ORT script would apply if it was run. The number in this column should be 0 for cache servers that do not have updates pending.

10G

Is the ip_address (the main IPv4 address) from the server table ping-able?

ILO

Is the ilo_ip_address (the lights-out-management IPv4 address) from the server table ping-able?

10G6

Is the ip6_address (the main IPv6 address) from the server table ping-able?

FQDN

Is the FQDN (the concatenation of host_name and . and domain_name from the server table) ping-able?

RTR

Checks the state of each cache server as perceived by all Traffic Monitors (via Traffic Router). This extension asks each Traffic Router for the state of the cache server. A check failure is indicated if one or more monitors report an error for a cache server. A cache server is only marked as good if all reports are positive.

Note

This is a pessimistic approach, opposite of how Traffic Monitor marks a cache server as up, i.e. “the optimistic approach”.

Example Cron File

The cron(8) file should be edited by running crontab(1) as the traffops user, or with sudo(8). You may need to adjust the path to your $TO_HOME to match your system. Edit $TO_USER and $TO_PASS to match ORT input parameters.

#34 Example Cron File
PERL5LIB=/opt/traffic_ops/app/local/lib/perl5:/opt/traffic_ops/app/lib

# IPv4 ping examples - The 'select: ["hostName","domainName"]' works but, if you want to check DNS resolution use FQDN.
*/15 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"10G\", \"select\": [\"hostName\",\"domainName\"]}" >> /var/log/traffic_ops/extensionCheck.log 2>&1
*/15 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"10G\", \"select\": \"ipAddress\"}" >> /var/log/traffic_ops/extensionCheck.log 2>&1
*/15 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"10G\", \"name\": \"IPv4 Ping\", \"select\": \"ipAddress\", \"syslog_facility\": \"local0\"}" > /dev/null 2>&1

# IPv6 ping examples
*/15 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"10G6\", \"name\": \"IPv6 Ping\", \"select\": \"ip6Address\", \"syslog_facility\": \"local0\"}" >/dev/null 2>&1
*/15 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"10G6\", \"select\": \"ip6Address\"}" >> /var/log/traffic_ops/extensionCheck.log 2>&1

# iLO ping
18 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"ILO\", \"select\": \"iloIpAddress\"}" >> /var/log/traffic_ops/extensionCheck.log 2>&1
18 * * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"ILO\", \"name\": \"ILO ping\", \"select\": \"iloIpAddress\", \"syslog_facility\": \"local0\"}" >/dev/null 2>&1

# MTU ping
45 0 * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"MTU\", \"select\": \"ipAddress\"}" >> /var/log/traffic_ops/extensionCheck.log 2>&1
45 0 * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"MTU\", \"select\": \"ip6Address\"}" >> /var/log/traffic_ops/extensionCheck.log 2>&1
45 0 * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"MTU\", \"name\": \"Max Trans Unit\", \"select\": \"ipAddress\", \"syslog_facility\": \"local0\"}" > /dev/null 2>&1
45 0 * * * root /opt/traffic_ops/app/bin/checks/ToPingCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"MTU\", \"name\": \"Max Trans Unit\", \"select\": \"ip6Address\", \"syslog_facility\": \"local0\"}" > /dev/null 2>&1

# FQDN
27 * * * * root /opt/traffic_ops/app/bin/checks/ToFQDNCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"FQDN\""  >> /var/log/traffic_ops/extensionCheck.log 2>&1
27 * * * * root /opt/traffic_ops/app/bin/checks/ToFQDNCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"FQDN\", \"name\": \"DNS Lookup\", \"syslog_facility\": \"local0\"}" > /dev/null 2>&1

# DSCP
36 * * * * root /opt/traffic_ops/app/bin/checks/ToDSCPCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"DSCP\", \"cms_interface\": \"eth0\"}" >> /var/log/traffic_ops/extensionCheck.log 2>&1
36 * * * * root /opt/traffic_ops/app/bin/checks/ToDSCPCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"DSCP\", \"name\": \:term:`Delivery Service`\", \"cms_interface\": \"eth0\", \"syslog_facility\": \"local0\"}" > /dev/null 2>&1

# RTR
10 * * * * root /opt/traffic_ops/app/bin/checks/ToRTRCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"RTR\"}"  >> /var/log/traffic_ops/extensionCheck.log 2>&1
10 * * * * root /opt/traffic_ops/app/bin/checks/ToRTRCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"RTR\", \"name\": \"Content Router Check\", \"syslog_facility\": \"local0\"}" > /dev/null 2>&1

# CHR
*/15 * * * * root /opt/traffic_ops/app/bin/checks/ToCHRCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"CHR\"}"  >> /var/log/traffic_ops/extensionCheck.log 2>&1

# CDU
20 * * * * root /opt/traffic_ops/app/bin/checks/ToCDUCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"CDU\"}"  >> /var/log/traffic_ops/extensionCheck.log 2>&1

# ORT
40 * * * * ssh_key_edge_user /opt/traffic_ops/app/bin/checks/ToORTCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"ORT\", \"to_user\":\"$TO_USER\", \"to_pass\": \"$TO_PASS\"}"  >> /var/log/traffic_ops/extensionCheck.log 2>&1
40 * * * * ssh_key_edge_user /opt/traffic_ops/app/bin/checks/ToORTCheck.pl -c "{\"base_url\": \"https://localhost\", \"check_name\": \"ORT\", \"name\": \"Operational Readiness Test\", \"syslog_facility\": \"local0\", \"to_user\":\"$TO_USER\", \"to_pass\": \"$TO_PASS\"}" > /dev/null 2>&1