Common network configuration values
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).
Insert the FQDN that is set in the customer's DNS A record.vars: app_fqdn:
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 serversNote: 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.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).
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.
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 fielddns_search_strings
in the customer YML file is allowed:
The optional field may be populated with comma-separated search strings that will be used in DNS querying of client entries.dns_servers: ["<VALUE>"] dns_search_strings: ["<OPTIONAL>"]
For example, with the following setting:
when you lookupdns_search_strings: ["ibm.com", "company.com", "subnet.example"]
myhost
, DNS will attempt to lookup the FQDNsmyhost.ibm.com
,myhost.company.com
, andmyhost.subnet.example
in the order provided in thedns_search_strings[]
list.Without this field, all DNS entries require the fully qualified suffix to be provided for every host.