On 09/01/2015 10:38 AM, Reindl Harald wrote:
Am 01.09.2015 um 16:28 schrieb John Miller:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz
<r...@htt-consult.com> wrote:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe this and I have some serious problems.
Part of my challenge is I am running the new server on an armv7
board that
does not have a rtc. So when the system boots, the time is jan 1
1970. The
first thing you want to run is ntp to set the time, but requires named
running and resolving.
For the 'fun' of it, I used 'date' to set the time to now, and then no
problem resolving 0.centos.pool.ntp.org. So there is something
about that
resolution that does not like the early date.
So I am caught in a time bind here!
Is there anyway to get bind not to be particular about system time
at first?
Hopefully this isn't a production server... rtc's kind of important
;-) I'll ditto here and say: static /etc/hosts entries or static IPs
in ntp.conf
additionally every network normally should have it's own ntpd using
the public pool and act as source for all other machines,
But this is the system that will be the internal ntp server :) At
least at first. One of the base boards I can add has the battery on
it. But I would only pay for that for this server. This is one of the
other obvious punts: get a battery rtc.
just because to be nice too the "pool.ntp.org" and hence any other box
needs just an IP address for doing "ntpdate xx.xx.xx.xx" *before* it's
own ntpd starts
There will be a lot of arm IoT boxes in the next few years needing their
time on boot. Of course booting will not be that frequent, but it will
interesting to see how it plays out. And check devices like the
esp8266, as $6 IoT device. It also gets its time once connected.
so you just need to make sure the correct order
* ntpdate xx.xx.xx.xx
* start ntpd
* start named
I will be looking more into this. Obvious when you get ones nose
dragged into time wrong on boot. This is actually a broader problem on
arm SoC booting. Your logs all have the wrong time for the boot
messages until there is a network to get time. I have some ideas for a
process that will set time a boot to the time of the last poweroff. at
least that is 'close enough' for starters.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
