Re: [CentOS] What besides Postfix should not start until system time set?

[Robert Moskowitz]

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



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Kenneth Porter]

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

Re: [CentOS] What besides Postfix should not start until system time set?

[Robert Moskowitz]

On 04/21/2017 09:25 AM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane, 
JXVS wrote:


From: Robert Moskowitz [r...@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 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 </etc/sysconfig/chronyd || exit 1
OPTIONS=" -s"
EOF

cat <>/etc/chrony.conf || exit 1
rtcdevice /dev/doesnotexist
EOF

With chronyd 2.2, you only need the "-s" option.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

From: Robert Moskowitz [r...@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 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.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Robert Moskowitz]

On 04/20/2017 06:17 PM, Warren Young wrote:

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz  wrote:

On 04/20/2017 05:16 PM, Warren Young wrote:

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  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@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Robert Moskowitz]

On 04/20/2017 06:17 PM, Warren Young wrote:

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz  wrote:

On 04/20/2017 05:16 PM, Warren Young wrote:

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  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.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Warren Young]

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

Re: [CentOS] What besides Postfix should not start until system time set?

[Robert Moskowitz]

On 04/20/2017 05:16 PM, Warren Young wrote:

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  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


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Warren Young]

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  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.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Alice Wonder]

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.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] What besides Postfix should not start until system time set?

[Robert Moskowitz]

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos