2 ms·
Which is one of the reasons I always insist our dev and prod teams use FQDNs (under domains the company owns) in all of their configurations. In more dynamic e
by PowerBar 6y ago
Which is one of the reasons I always insist our dev and prod teams use FQDNs (under domains the company owns) in all of their configurations.
In more dynamic environments, the config may have the domain as its own setting and each service as just the hostname, but the software must combine them before use, or better yet combine them in the config if variable expansion is possible in the config language they are using (ex: db_server="db-01.${domain}" with domain being defined near the top).