Common network configuration values

In the following part of the file:
vars:
    app_fqdn: <VALUE>
    #(pick from timedatectl list-timezones)
    timezone: "<VALUE>"
    #must begin with server or pool
    time_servers: ["<OPTIONAL>"]
    dns_servers: ["<VALUE>"]
update the following sections:
  • Application fully qualified domain name

    The app_fqdn is the name by which you can reach the applications. This name should already be set in customer DNS, along with the wildcard (see Deprecated: Setting up a wildcard DNS entry).

     vars:
        app_fqdn:
    Insert the FQDN that is set in the customer's DNS A record.
    Example:
    vars:
        app_fqdn: os_apps.customer_domain.customer.com
  • Timezone

    Valid values are found from the command timedatectl list-timezones. The default is America/New_York.

    Example:
    vars:
        [...]
        timezone: "America/Los_Angeles"
  • Time servers
    Note: The system is capable of keeping time in sync among the components without the need for an upstream time source. Unless time sensitive operations are to be performed on the system, adding an external time source is optional and discouraged.

    For time sensitive services, synchronization with the rest of the customer infrastructure is required. In order to sync time with the customer infrastructure, an external NTP server must be configured. This comes with the benefit of syncing time with the customer time, but puts a large burden on that piece of infrastructure. Enterprise quality product must be used.

    If there are any issues with it, and it causes time to drift among the nodes, the stability of the platform is in jeopardy.

    When not adding upstream time source, leave the line untouched. To set an upstream source, you must know if the source is a single system (server), or a group of systems (pool).
    Example:
    vars:
        [...]
        time_servers: ["server ntp.customer.com","pool ntpN.customer.com"]

    Each time server entry must be enclosed by quotation marks (" ") and a description (server or pool) is required with each entry. More than one entry must be separated by a comma (,). The entire list must be enclosed by square brackets ([ ]).

  • DNS servers

    A maximum of 3 entries is enforced, based on bind/named implementation. Values in this item must be dotted quad addresses.

    Example:
    vars:
        [...]
        dns_servers: ["192.168.1.11","172.32.1.11"]
    Note: This is the list of customer DNS server(s). Each DNS server must be enclosed by quotation marks (" "). More than one entry must be separated by a comma (,). The entire list must be enclosed by square brackets ([ ]).
    Starting with 1.0.5.1, a new optional field dns_search_strings in the customer YML file is allowed:
    dns_servers: ["<VALUE>"]
    dns_search_strings: ["<OPTIONAL>"]
    
    The optional field may be populated with comma-separated search strings that will be used in DNS querying of client entries.
    For example, with the following setting:
    dns_search_strings: ["ibm.com", "company.com", "subnet.example"]
    when you lookup myhost, DNS will attempt to lookup the FQDNs myhost.ibm.com, myhost.company.com, and myhost.subnet.example in the order provided in the dns_search_strings[] list.

    Without this field, all DNS entries require the fully qualified suffix to be provided for every host.