Changing global NTP and DNS settings post configuration
The DNS and NTP settings that are configured at installation time for Triton are intended to remain static. However, if your circumstances dictate that either or both of these must be changed, it can be achieved as described below.
CAUTIONS:
- It is only recommended that these settings be changed if it is a hard requirement. Additionally, it is recommended that the change be accompanied by a reboot of the head node as well as thorough test of the changes.
- NTP - If the head node NTP service fails due to not having accesses to a valid NTP source, this can cause error conditions and instability within the Triton software.
- DNS - Changing DNS takes effect immediately on all instances using the networks that are changed. If DNS server names/IPs are inaccessible this will cause failure conditions in your instances and in some Triton Core Services.
Changing NTP on the head node
Triton uses its own internal NTP server which runs on the head node. This cannot be changed. All components of Triton must synchronize against the head node; however, the external time source that Triton uses to synchronize against can be updated if required.
Validate new NTP server(s)
-
The first step is to ensure that you are able to reach and synchronize against the new NTP server(s). This can be accomplished by using the ntpdate(1m) command from the GZ of the head node:
headnode# ntpdate -d time.nist.gov 4 Nov 16:15:28 ntpdate[35083]: ntpdate 4.2.7p446@1.2483-o Thu Sep 4 11:58:37 UTC 2014 (1) Looking for host time.nist.gov and service ntp 128.138.141.172 reversed to utcnist2.colorado.edu host found : utcnist2.colorado.edu transmit(128.138.141.172) receive(128.138.141.172) transmit(128.138.141.172) transmit(128.138.141.172) receive(128.138.141.172) transmit(128.138.141.172) receive(128.138.141.172) server 128.138.141.172, port 123 stratum 1, precision -29, leap 00, trust 000 refid [ACTS], delay 0.07411, dispersion 8.00015 transmitted 4, in filter 4 reference time: d80379e5.e60978dc Tue, Nov 4 2014 16:14:29.898 originate timestamp: d8037a26.a45321f7 Tue, Nov 4 2014 16:15:34.641 transmit timestamp: d8037a26.9e3bab97 Tue, Nov 4 2014 16:15:34.618 filter delay: 0.07411 0.00000 0.07423 0.07422 0.00000 0.00000 0.00000 0.00000 filter offset: -0.00035 0.000000 -0.00068 -0.00051 0.000000 0.000000 0.000000 0.000000 delay 0.07411, dispersion 8.00015 offset -0.000350 4 Nov 16:15:34 ntpdate[35083]: adjust time server 128.138.141.172 offset -0.000350 sec -
The output above shows us that we are able to successfully contact the NTP server. The
-dflag tellsntpdateto not set the clock, just show what it would do. -
Conversely, a failure will look like this.
headnode# ntpdate -d 192.168.212.12 4 Nov 16:17:24 ntpdate[35172]: ntpdate 4.2.7p446@1.2483-o Thu Sep 4 11:58:37 UTC 2014 (1) Looking for host 192.168.212.12 and service ntp host found : 192.168.212.12 transmit(192.168.212.12) transmit(192.168.212.12) transmit(192.168.212.12) transmit(192.168.212.12) transmit(192.168.212.12) 192.168.212.12: Server dropped: no data server 192.168.212.12, port 123 stratum 0, precision 0, leap 00, trust 000 refid [192.168.212.12], delay 0.00000, dispersion 64.00000 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000 originate timestamp: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000 transmit timestamp: d8037a9a.fe8de440 Tue, Nov 4 2014 16:17:30.994 filter delay: 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 filter offset: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 delay 0.00000, dispersion 64.00000 offset 0.000000 4 Nov 16:17:32 ntpdate[35172]: no server suitable for synchronization found
Change running configuration
The optional, but recommended, procedure is to modify the config file and reboot the head node to ensure that the change is reboot-safe. However, if you are unable to afford the downtime on the head node yet still need to change the NTP settings it is possible to do it using this procedure.
Note: You do not need to follow this procedure if you are intending on changing the configuration file and rebooting the head node. This procedure is only required if you are unable to reboot the head node yet need to change the NTP server. If you follow this procedure without going through the procedure Change config File above, your head node will revert to the NTP servers listed in the config file.
-
To change the running configuration, you will need to modify the file
/etc/inet/ntp.conf. A sample file is shown below.headnode# cat /etc/inet/ntp.conf driftfile /var/ntp/ntp.drift logfile /var/log/ntp.log # Ignore all network traffic by default restrict default ignore restrict -6 default ignore # Allow localhost to manage ntpd restrict 127.0.0.1 restrict -6 ::1 # Allow servers to reply to our queries restrict source nomodify noquery notrap # Allow local subnets to query this server restrict 10.1.1.0 mask 255.255.255.0 # Time Servers pool 0.smartos.pool.ntp.org burst iburst minpoll 4 -
Create backup of the ntp.conf file. This can be used for recovery in the event there are problems with the new configuration.
headnode# cd /etc/inet headnode# cp ntp.conf ntp.conf.orig -
Change server address in the ntp.conf file; You will need to change the entry under Time Servers to reflect the address / type of time server you are using. Note Do not change any other lines in this file! Doing so may cause your installation to become unstable.
-
Using the svcadm(1m), restart the ntp service:
headnode# svcs -a | grep ntp online 15:29:47 svc:/network/ntp:default headnode# svcadm restart ntp headnode# svcs -a | grep ntp online 19:36:36 svc:/network/ntp:default -
Once you have restarted the NTP service you need to test the new NTP server using the ntpq(1) command.
headnode# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.smartos.pool. .POOL. 16 p - 16 0 0.000 0.000 0.000 +207.150.168.70 130.207.244.240 2 u 482 512 377 47.128 -6.064 2.553 +time.gac.edu 128.138.141.172 2 u 257 1024 377 35.711 -4.275 5.911 *pool-test.ntp.o 216.218.254.202 2 u 16 1024 377 73.210 -5.816 4.786 -deekayen.net 209.51.161.238 2 u 370 1024 377 40.576 2.106 4.277 -ec2-54-235-96-1 152.2.133.53 2 u 360 512 377 40.869 13.775 8.973 +li290-38.member 128.138.141.172 2 u 331 1024 377 47.029 -5.155 5.216 -segfault.boom.n 204.123.2.72 2 u 409 512 377 45.565 -10.630 3.512 -ntp.southwestit 173.203.211.73 3 u 470 512 377 49.851 -6.356 3.493 -199.167.29.243 204.9.54.119 2 u 373 1024 377 60.533 2.551 2.810
Change persistent configuration
Updating the persistent data to set NTP server(s) for Triton involves a modification to the config file that is located on the boot key; this process reviews the steps for updating the key.
-
Using the
sdc-usbkeycommand, mount the USB key on the head node.headnode# sdc-usbkey mount -
Create a backup copy of the config file.
headnode# cp /mnt/usbkey/config /mnt/usbkey/config.ntp.backup -
Using a text editor, adjust the following line in the config file to use the IP address or Hostname of the new NTP server(s).
headnode# ntp_hosts=0.smartos.pool.ntp.org-
For example:
headnode# diff config config.ntp.backup 116c116 < ntp_hosts=my_new_ntp_host --- > ntp_hosts=0.smartos.pool.ntp.org
-
-
Verify that the config file is syntactically correct; this can be done easily by sourcing the file.
headnode# source /mnt/usbkey/config- If this command throws any errors, you will need to correct them prior to proceeding.
-
Unmount the usbkey via the
sdc-usbkeycommand.headnode# sdc-usbkey unmount -
Reboot the head node
headnode# reboot -
Once the head node has rebooted, you need to test the new NTP server using the ntpq(1) command.
headnode# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.smartos.pool. .POOL. 16 p - 16 0 0.000 0.000 0.000 +207.150.168.70 130.207.244.240 2 u 482 512 377 47.128 -6.064 2.553 +time.gac.edu 128.138.141.172 2 u 257 1024 377 35.711 -4.275 5.911 *pool-test.ntp.o 216.218.254.202 2 u 16 1024 377 73.210 -5.816 4.786 -deekayen.net 209.51.161.238 2 u 370 1024 377 40.576 2.106 4.277 -ec2-54-235-96-1 152.2.133.53 2 u 360 512 377 40.869 13.775 8.973 +li290-38.member 128.138.141.172 2 u 331 1024 377 47.029 -5.155 5.216 -segfault.boom.n 204.123.2.72 2 u 409 512 377 45.565 -10.630 3.512 -ntp.southwestit 173.203.211.73 3 u 470 512 377 49.851 -6.356 3.493 -199.167.29.243 204.9.54.119 2 u 373 1024 377 60.533 2.551 2.810
Changing DNS on the head node
It is possible to change the DNS servers that Triton uses post-installation. Please be aware, however, that this will only affect the resolver files in the global zones. DNS servers associated with networks are managed in NAPI via the process described on the page titled Configuring networks.
Note: You should never manually change DNS settings for Triton core services, including the global zone. Doing so may render your installation non-functional.
-
First, verify that the DNS server that you are planning on using is accessible and responding to DNS queries. You can do this by using the dig(1) command from the GZ of the head node.
headnode# dig @192.168.212.1 A ; <<>> DiG 9.8.0 <<>> @192.168.212.1 A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40285 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 18247 IN NS m.root-servers.net. . 18247 IN NS c.root-servers.net. . 18247 IN NS e.root-servers.net. . 18247 IN NS j.root-servers.net. . 18247 IN NS h.root-servers.net. . 18247 IN NS b.root-servers.net. . 18247 IN NS l.root-servers.net. . 18247 IN NS f.root-servers.net. . 18247 IN NS k.root-servers.net. . 18247 IN NS g.root-servers.net. . 18247 IN NS a.root-servers.net. . 18247 IN NS d.root-servers.net. . 18247 IN NS i.root-servers.net. ;; Query time: 43 msec ;; SERVER: 192.168.212.1#53(192.168.212.1) ;; WHEN: Tue Nov 4 19:56:08 2014 ;; MSG SIZE rcvd: 228 -
The server above is responding as expected. Conversely, a failure will look like this.
headnode# dig @192.168.212.11 ; <<>> DiG 9.8.0 <<>> @192.168.212.11 ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
Change the Triton config file
- Mount the USB key
Using the sdc-usbkey command, mount the USB key on the head node.
headnode# sdc-usbkey mount-
Create a backup copy of the config file.
headnode# cp /mnt/usbkey/config /mnt/usbkey/config.ntp.backup -
Using a text editor, adjust the following line in the config file to use the new DNS server(s).
dns_resolvers=8.8.8.8,8.8.4.4 -
For example.
headnode# diff config config.dns.backup 102c102 < dns_resolvers=208.67.222.222,208.67.220.220 --- > dns_resolvers=8.8.8.8,8.8.4.4 -
Verify that the config file is syntactically correct; this can be done easily by sourcing the file.
headnode# source /mnt/usbkey/config -
If this command throws any errors, you will need to correct them prior to proceeding.
-
Unmount the usbkey via
sdc-usbkeyheadnode# sdc-usbkey unmount -
Reboot the head node
headnode# reboot -
Once the head node has rebooted, you need to test DNS. You can do this by first inspecting the contents of
/etc/resolv.confin the GZ of the head node.headnode# cat /etc/resolv.conf search virington.com nameserver 10.1.1.11 nameserver 208.67.222.222 nameserver 208.67.220.220- Note: You will always see an address on the admin network listed first in your resolvers file. Do not change this; this is required for Triton to function properly.
-
Use the
pingcommand to resolve a foreign host:headnode# ping tritondatacenter.com tritondatacenter.com is alive
