First, I’d like to thank the US Congress for causing so much work for people to update all their systems to the new daylight savings rules… We really appreciate it.
Since the rule kicked in over the weekend, we were able to see easily which of our devices failed to make the cut. Luckily there were only a few.
The FreeBSD servers were easy to fix and were already patched and
tested. All we had to do was copy over the file
a very recently installed system onto every other system which had
the outdated one… simply upgrading the OS is insufficient! Note
however that long running programs won’t re-read the file. Of
particular note is the
cron daemon. We had to restart that today after we realized the jobs ran at the wrong time this weekend. It also appears that
syslogd wants to be restarted to get the timestamps right.
Cyclades Terminal Servers #
The Cyclades terminal servers (one Ts1000 and one Alterpath ACS) both needed fixing. The TS1000 is running version 1.4.0 and the ACS is running version 2.3.0 of the firmware. The fix was pretty trivial. Edit the /etc/TIMEZONE file and change it to the following string:
A simple logout/login and the shell was happy. Longer running programs that need to know the time probably need to be restarted, but I didn’t bother. If you’re not East coast, then adjust the first parameter to your timezone name; the key is the part after the first comma.
Sipura SIP Adapters #
We also have a couple of SPA1001 SIP adapters running version 3.1.8 of the firmware. This was a trival fix as well. In the Regional “Advanced” menu, update the daylight savings rule to:
After the save and automatic reset, the time is correct.
Grandstream Budgetone 101 #
In our server rooms, we have some Grandstream Budgetone 101 SIP phones (firmware 10.0.8.33). These also use a very trivial daylight savings rule. Update it to:
Also be sure to enable the DST setting. After save and reboot, the time is correct.
Polycom IP Phones #
Our collection of Polycom IP500, IP501, and IP301 phones with firmware 1.4.1 are also showing the incorrect time. However, the fix to these is a bit more involved because it is not just a simple string to update. I found instructions to do this online for a single phone, but I really don’t like the idea of manually fixing each of these devices!
For now, we have just modified the ipmid.cfg file to change the parameters as follows:
tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.date="8" tcpIpApp.sntp.daylightSavings.stop.month="11" tcpIpApp.sntp.daylightSavings.stop.date="1"
Followed by rebooting every phone. A lot easier than reconfiguring ever phone via the web interface, for sure. Perhaps the next version of the firmware will fix it by default.