So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
What other services need to be delayed?
Apache? Bind?
Of course if this is a nameserver, Chronyd will probably not be able to resolve the NTP server addresses until Bind is running!
thanks
On 04/20/2017 02:00 PM, Robert Moskowitz wrote:
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
What other services need to be delayed?
Apache? Bind?
Of course if this is a nameserver, Chronyd will probably not be able to resolve the NTP server addresses until Bind is running!
thanks
I use unbound on all my servers listening only on the localhost, not sure if it needs the current time to be accurate when it starts or not but it never seems to be an issue.
I'm of the opinion every server should have locally provided DNSSEC enforcing DNS services simply because it takes away a potential attack vector to have local DNS queries stay local.
On Apr 20, 2017, at 3:00 PM, Robert Moskowitz rgm@htt-consult.com wrote:
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
I think it’s more the case that CentOS is written with the assumption that you’re running it on a host with a battery-backed RTC, so that system time isn’t wildly off at boot time. This includes VMs, since the VM host should pass its RTC through to the VM.
What are you running CentOS on that doesn’t have this property?
The only such system I can think of which will also run CentOS is the Raspberry Pi 3. They dropped the battery-backed RTC in the name of cost savings and that most Pi boards are network-connected, so they can get Internet time soon after boot. But yeah, there is a small window...
What other services need to be delayed?
I can only speculate. But take the above as a warning: lots of other software may assume sane system time at startup. Short of a massive code audit or your present “canvass the audience” approach, I don’t know how you find out which ones.
Apache?
Just speculating here, but my sense is that Apache doesn’t care about dates and times until it gets an HTTP request, in order to handle Expires headers and such correctly. And, HTTP being stateless, even if an HTTP request comes in so early that it gives the wrong answer, it should get back on track once the system clock is fixed.
Bind?
Similar to Apache, due to cache expiration rules. Since “now” minus time_t(0) is $bignum, that means as soon as the system clock is fixed, it will expire all the info it learned in the time the clock was wrong, and any info it gave out with start time equal to 0 + epsilon will expire immediately in clients’ DNS caches.
Since so much other software depends on having a local DNS server early in their startup, I would definitely not delay BIND startup on any machine where the local DNS configuration points to localhost.
On 04/20/2017 05:16 PM, Warren Young wrote:
On Apr 20, 2017, at 3:00 PM, Robert Moskowitz rgm@htt-consult.com wrote:
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
I think it’s more the case that CentOS is written with the assumption that you’re running it on a host with a battery-backed RTC, so that system time isn’t wildly off at boot time. This includes VMs, since the VM host should pass its RTC through to the VM.
What are you running CentOS on that doesn’t have this property?
It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion) of these. See:
http://medon.htt-consult.com/arm.html
The only such system I can think of which will also run CentOS is the Raspberry Pi 3. They dropped the battery-backed RTC in the name of cost savings and that most Pi boards are network-connected, so they can get Internet time soon after boot. But yeah, there is a small window...
What other services need to be delayed?
I can only speculate. But take the above as a warning: lots of other software may assume sane system time at startup. Short of a massive code audit or your present “canvass the audience” approach, I don’t know how you find out which ones.
Apache?
Just speculating here, but my sense is that Apache doesn’t care about dates and times until it gets an HTTP request, in order to handle Expires headers and such correctly. And, HTTP being stateless, even if an HTTP request comes in so early that it gives the wrong answer, it should get back on track once the system clock is fixed.
On the Apache list, I was just told
"There are some parts of the HTTP conversation which could be affected by having the wrong time, but HTTPD itself doesn't care. For example, if you are using cookies, caching, those could be affected by the time change (even more specifically, for PHP sessions, when the clock changes, the PHP session cleanup handler might think a session is very old and remove it)."
Bind?
Similar to Apache, due to cache expiration rules. Since “now” minus time_t(0) is $bignum, that means as soon as the system clock is fixed, it will expire all the info it learned in the time the clock was wrong, and any info it gave out with start time equal to 0 + epsilon will expire immediately in clients’ DNS caches.
Since so much other software depends on having a local DNS server early in their startup, I would definitely not delay BIND startup on any machine where the local DNS configuration points to localhost. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Apr 20, 2017, at 3:39 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On 04/20/2017 05:16 PM, Warren Young wrote:
On Apr 20, 2017, at 3:00 PM, Robert Moskowitz rgm@htt-consult.com wrote:
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
I think it’s more the case that CentOS is written with the assumption that you’re running it on a host with a battery-backed RTC
It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion) of these.
So you picked an alternative that cites “server stability” when explaining why they’re redirecting you to a Kim Dotcom service to get info about the product? No, no, no. No thank you. No.
http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20downlo...
That looks like a “Don’t stick your hand in this hole.” sign to me.
Apache?
Just speculating here, but my sense is that Apache doesn’t care about dates and times until it gets an HTTP request, in order to handle Expires headers and such correctly. And, HTTP being stateless, even if an HTTP request comes in so early that it gives the wrong answer, it should get back on track once the system clock is fixed.
On the Apache list, I was just told
"There are some parts of the HTTP conversation which could be affected by having the wrong time, but HTTPD itself doesn't care. For example, if you are using cookies, caching, those could be affected by the time change (even more specifically, for PHP sessions, when the clock changes, the PHP session cleanup handler might think a session is very old and remove it).”
That pretty much just backs up and amplifies my speculation: strange things will happen in the window where the clock is wrong, but operations will get on track quickly without restarting the web server once the clock changes out from under it.
It is possible that some particular web apps won’t cope nicely, such as because they keep server time info on the client and then make later stateful comparisons, but that isn’t about Apache or PHP.
On 04/20/2017 06:17 PM, Warren Young wrote:
On Apr 20, 2017, at 3:39 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On 04/20/2017 05:16 PM, Warren Young wrote:
On Apr 20, 2017, at 3:00 PM, Robert Moskowitz rgm@htt-consult.com wrote:
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
I think it’s more the case that CentOS is written with the assumption that you’re running it on a host with a battery-backed RTC
It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion) of these.
So you picked an alternative that cites “server stability” when explaining why they’re redirecting you to a Kim Dotcom service to get info about the product? No, no, no. No thank you. No.
http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20downlo...
That looks like a “Don’t stick your hand in this hole.” sign to me.
I got mine from a US supplier:
Fedora-arm and Centos-arm developers use the Cubietruck. FWW.
Apache?
Just speculating here, but my sense is that Apache doesn’t care about dates and times until it gets an HTTP request, in order to handle Expires headers and such correctly. And, HTTP being stateless, even if an HTTP request comes in so early that it gives the wrong answer, it should get back on track once the system clock is fixed.
On the Apache list, I was just told
"There are some parts of the HTTP conversation which could be affected by having the wrong time, but HTTPD itself doesn't care. For example, if you are using cookies, caching, those could be affected by the time change (even more specifically, for PHP sessions, when the clock changes, the PHP session cleanup handler might think a session is very old and remove it).”
That pretty much just backs up and amplifies my speculation: strange things will happen in the window where the clock is wrong, but operations will get on track quickly without restarting the web server once the clock changes out from under it.
It is possible that some particular web apps won’t cope nicely, such as because they keep server time info on the client and then make later stateful comparisons, but that isn’t about Apache or PHP.
To delay httpd is no biggie. To delay bind is a no-no. To delay Postfix, apparently, is important.
There seems to be a way with the chronyd -s option to use the timestamp on the driftfile. I need to look more into that.
On 04/20/2017 06:17 PM, Warren Young wrote:
On Apr 20, 2017, at 3:39 PM, Robert Moskowitz rgm@htt-consult.com wrote:
On 04/20/2017 05:16 PM, Warren Young wrote:
On Apr 20, 2017, at 3:00 PM, Robert Moskowitz rgm@htt-consult.com wrote:
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
I think it’s more the case that CentOS is written with the assumption that you’re running it on a host with a battery-backed RTC
It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion) of these.
So you picked an alternative that cites “server stability” when explaining why they’re redirecting you to a Kim Dotcom service to get info about the product? No, no, no. No thank you. No.
http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20downlo...
That looks like a “Don’t stick your hand in this hole.” sign to me.
If you want a US built SoC, go with the Wandboard by Freescale. Oh, wait, NXP bought Freescale, that makes it a UK company.
There are lots of affordable armv7 boards from lots of sources. You want one that has a good uboot development and does not need a custom kernel like RPi does.
Apache?
Just speculating here, but my sense is that Apache doesn’t care about dates and times until it gets an HTTP request, in order to handle Expires headers and such correctly. And, HTTP being stateless, even if an HTTP request comes in so early that it gives the wrong answer, it should get back on track once the system clock is fixed.
On the Apache list, I was just told
"There are some parts of the HTTP conversation which could be affected by having the wrong time, but HTTPD itself doesn't care. For example, if you are using cookies, caching, those could be affected by the time change (even more specifically, for PHP sessions, when the clock changes, the PHP session cleanup handler might think a session is very old and remove it).”
That pretty much just backs up and amplifies my speculation: strange things will happen in the window where the clock is wrong, but operations will get on track quickly without restarting the web server once the clock changes out from under it.
It is possible that some particular web apps won’t cope nicely, such as because they keep server time info on the client and then make later stateful comparisons, but that isn’t about Apache or PHP. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
________________________________________ From: Robert Moskowitz [rgm@htt-consult.com] Sent: Thursday, April 20, 2017 5:00 PM To: CentOS mailing list Subject: [CentOS] What besides Postfix should not start until system time set?
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
Something you might consider to make the time delta _less_ drastic, is to create a service which on system shutdown touches a file {in /etc/} and on boot early in the start-up {make some other services depend on it} checks to see if the system date&time is before the time on that file, if it is then use the time stamp {+ a few sec} on the file to set the current time. That way time would at least move forward.
in the olden days we used to use `hwclock --badyear` mitigate part of it. perhaps you could extend hwclock for --dead-batteries and make it easier for every one with an arm {assuming hwclock is still used in the boot process to pull the initial time from the clock}. :)
Even when this disclaimer is not here: I am not a contracting officer. I do not have authority to make or modify the terms of any contract.
On 04/21/2017 09:25 AM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS wrote:
From: Robert Moskowitz [rgm@htt-consult.com] Sent: Thursday, April 20, 2017 5:00 PM To: CentOS mailing list Subject: [CentOS] What besides Postfix should not start until system time set?
So I have learned that Postfix should delay until Chronyd has moved the system time from 0 to current.
Something you might consider to make the time delta _less_ drastic, is to create a service which on system shutdown touches a file {in /etc/} and on boot early in the start-up {make some other services depend on it} checks to see if the system date&time is before the time on that file, if it is then use the time stamp {+ a few sec} on the file to set the current time. That way time would at least move forward.
in the olden days we used to use `hwclock --badyear` mitigate part of it. perhaps you could extend hwclock for --dead-batteries and make it easier for every one with an arm {assuming hwclock is still used in the boot process to pull the initial time from the clock}. :)
Even when this disclaimer is not here: I am not a contracting officer. I do not have authority to make or modify the terms of any contract.
Miroslav has been a great help over on the chronyd list. I have learned to add the -s option to chronyd and point the rtcdevice to nothing so that the Centos version of Chronyd, 2.1.1, will read the timestamp from the driftfile if no ntp respose:
cat <<EOF>/etc/sysconfig/chronyd || exit 1 OPTIONS=" -s" EOF
cat <<EOF>>/etc/chrony.conf || exit 1 rtcdevice /dev/doesnotexist EOF
With chronyd 2.2, you only need the "-s" option.
Samba. Authentication won't work if the client and server have different clocks.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Thanks. Good to know, and I will add this as a footnote to my howto.
I am currently, not tackling Samba. I tried a year ago without success. My current domain server is ClearOS.
On 04/21/2017 11:38 AM, Kenneth Porter wrote:
Samba. Authentication won't work if the client and server have different clocks.
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Alice Wonder -
Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS -
Kenneth Porter -
Robert Moskowitz -
Warren Young