How to change time on local NTP server and distribute?

Latest response

Hi,
Is there any solution to retrieve time from a NTP server and change time locally (Increase or decrease) and then distribute new time to other servers?
As an example, server retrieve UTC time and change it GMT+1 and then distribute GMT+1 to others.

BR

Responses

Not sure why you would do this. NTP distributes the time code, the box that is syncing should have the TZ set locally.

Davoud Teimouri,

I recommend using Ansible with a playbook (or Ansible Tower) to set time appropriately for systems under your administrative jurisdiction.

Regards,
RJ

First, for background, NTP is timezone independent. All servers discuss time using the value of GMT aka UTC only. The local server displays time based on TZ variable. In newer OS, the timezone that your sever users is setup with timedatectl. Older versions use the config file like /etc/sysconfig/clock:Zone="America/Los Angeles" Second, we pull time from several sources at once to develop a consensus. Thus you need multiple 'server' lines in your config file.

Installing the ntp package will allow you to both receive and serving NTP. Then create the /etc/ntp.conf file

--- /etc/ntp.conf Allow others to pull time, but not to modify the time on this system

restrict -6 default kod nomodify notrap nopeer noquery

Known Internet Time Servers - replace as you wish Clients will point to the master server you refer to server davoudt.mydomain

server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org

Fallback config. sync time to yourself if no other server found

server 127.127.1.0 # local

driftfile /var/lib/ntp/drift keys /etc/ntp/keys

---- end of /etc/ntp/ntp.conf --

. . . You can update /etc/sysconfig/ntpd : SYNC_HWCLOCK=yes to set the hardware clock of your server. This will put you close to correct when the server reboots.

Now enable and run the service
RHEL5:/etc/init.d/ntpd start ; ln -s /etc/rc3.d/S77ntpd /etc/init.d/ntpd RHEL6: chkconfig ntpd on; service ntpd start RHEL7: systemctl enable ntpd.service; systemctl start ntpd.service

Adam - thanks for your detailed explanation. I often (very often) forget that sometimes a detailed explanation can answer many questions before they even need be asked. Thank you for the reminder - sincerely.

Adam, thanks for your detailed reply!

Regards,
RJ

Hi guys, Thank you, actually our application needs GMT+1 instead of local time. we need to solution for converting UTC to current time +1 and distribute the localtime of internal time server to the others. I know, this is not a standard solution. RJ, how can wedoit by Ansible ?

Hi Davoud Teimouri,

UPDATED first paragraph

I do not have a quick answer to set a plus-one to GMT, I'd recommend opening a case with Red Hat. Arguably you could set your systems for a time zone that is one hour ahead of GMT, however, that doesn't seem optimal and I'd recommend a case with Red Hat if you really must have a non-typical time offset. You've probably heard that if you keep your tzdata rpm updated, daylight savings time is automatically accounted for.

However, if you are considering how to compensate for the end of Daylight Savings Time, most modern systems will pick that up if you keep your rpms updated (the rpm is tzdata).

For Ansible, here's some references, this at docs.ansible.com and also this. Obviously, you need to substitute your time zones for what you see in the examples, and I'd evaluate this against a test set of systems prior to sending it your entire collection.

Additionally, I've seen some people make a script, then actually send it through ansible to one, some or all of their collection using Ansible.

Now on this note, it's important to know if your systems are using actual ntpd or chronyd.

Additionally, examine the principles for this Red Hat Solution https://access.redhat.com/solutions/28425, and while it says RHEL 6, note this:

# rpm -q tzdata
tzdata-2009u-1.el5
  • This reports the year and revision of the files in use and it means that the installed timezone files date from 2009, and are at revision u.

One of my RHEL 7.9 servers reports this:

# yum -y update tzdata
# rpm -q tzdata
tzdata-2020d-2.el7.noarch
  • So my system (as I type this) has the most current rpm for tzdata for 2020, revision "d" (based in the link just prior)

  • To view the changeover dates for DST in a particular timezone:

 zdump -v /usr/share/zoneinfo/America/New_York  | egrep 2020
/usr/share/zoneinfo/America/New_York  Sun Mar  8 06:59:59 2020 UTC = Sun Mar  8 01:59:59 2020 EST isdst=0 gmtoff=-18000
/usr/share/zoneinfo/America/New_York  Sun Mar  8 07:00:00 2020 UTC = Sun Mar  8 03:00:00 2020 EDT isdst=1 gmtoff=-14400
/usr/share/zoneinfo/America/New_York  Sun Nov  1 05:59:59 2020 UTC = Sun Nov  1 01:59:59 2020 EDT isdst=1 gmtoff=-14400
/usr/share/zoneinfo/America/New_York  Sun Nov  1 06:00:00 2020 UTC = Sun Nov  1 01:00:00 2020 EST isdst=0 gmtoff=-18000

Regards,
RJ

Hi, thanks again for all comments. I need to something like the below software on Linux: https://nts.softros.com/server/ It can response time with larger or smaller offset to clients.

Davoud,

Maybe you could clarify the use case. There are a few solutions already presented here, but now it looks like you want something that is a proprietary NTP service?

I get that you want to change the offset; why? What are you trying to do? Are the machines you are wanting to update not timezone aware? Is there some other problem preventing you from placing an NTP server at the edge and using the NTP protocol internal to your network?

I think if you can answer some or all of those questions, we can definitely help.

Davoud,

The product you speak of is third-party software, I've never seen an NTP server force a plus-one hour offset to clients (in the context of this discussion), ever in my experience. However, I'd recommend putting in a case with Red Hat directly based on the history of our discussion because maybe they can do something we're not aware of.

Regards,
RJ

Davoud - You're asking for a solution that doesn't follow the standards of the NTP protocol (distribute time in UTC then the local OS or app will transpose the UTC time based on timezone). We don't understand what is unique about your situation that could not fit into the existing model for handling time.

Can you set the TZ for all servers that will run the application to be local+1? Can you set local timezone on the OS, but set a local+1 timezone environment variable before starting the application that will just affect those processes? One more idea - I believe that you can edit the timezone files themselves - to show local timezone (example EST for eastern US), but to transpose the time displayed from UTC to an hour ahead of localtime. These would be overwritten periodically be patches, but you can probably save your customized file under a new name.

I think RJ made a really good point about timezones that move the hour forward and backward certain times during the year. Important to consider this.

Completely concur with Adam Deridder above (and thanks to Adam).

Regards,
RJ

Thank you all. I hope that the below explanation is enough. We have to use UTC as timezone on our application/database servers, I don't know why? I asked the develop team to explain the exact issue for us that why have they to use UTC instead of local timezone. Anyway, we can not use external time source and we have some offline time sources. I know this situation is very weird!. One of our colleagues has idea to developing an application or solution to use as time server. They want to put a server as NTP server at edge and then another server as internal time server and increase local time of second server and then the server will response to NTP requests by its local time. I want to know, is there any standard solution for that? Or we must develop it. I've created customized TZ but it doesn't work at this situation, I guess that they are using timestamp in database or application as unique field and because of rules in TZ binary file, the timestamp will be different with local time at all. Still I don't know what is exact problem and why they can't change it in application codes.