CentOS - Apr 2017 - What besides Postfix should not start until system time set?

On 04/20/2017 05:16 PM, Warren Young wrote:
> On Apr 20, 2017, at 3:00 PM, Robert Moskowitz <rgm at
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 at centos.org
> https://lists.centos.org/mailman/listinfo/centos

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz <rgm at 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 at
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%20download%20%20server.txt

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 at
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 at
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%20download%20%20server.txt
>
> That looks like a ?Don?t stick your hand in this hole.? sign to me.
I got mine from a US supplier:

http://www.iotllc.com

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 at
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 at
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%20download%20%20server.txt
>
> 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 at centos.org
> https://lists.centos.org/mailman/listinfo/centos