CentOS - Apr 2017 - 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.

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 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?

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 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

________________________________________
From: Robert Moskowitz [rgm at 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 at 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 at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>