Re: time question, as in ntp?
On Fri, Dec 01, 2023 at 04:57:25PM -0500, gene heskett wrote:
> root@mkspi:/etc# ls -ld /etc/network/interfaces
> -rwxr-xr-x 1 root root 106 Jul 24 19:10 /etc/network/interfaces
OK. Now we have something to work with, at least.
> date
> Tue 03 Jan 2023 06:44:56 AM PST
> The clock is apparently restarted from midnight 12/1/2022 at every reboot.
> This overwrite was done that way as soon as I could login at the old address
> with ssh so I have to say it was done by network start time in the bootup
> from a 10 second power down.
All right, then. Let's see if I have everything straight.
At some point in the recent past, you edited /e/n/i. Then you rebooted,
an undetermined amount of time later, and after the reboot, the file had
been restored to the state shown above. Yes?
If we assume the file wasn't changed *prior* to the reboot, then something
in the operating system startup must be overwriting this file.
If your assertion about the clock being set to 2022-12-01 each boot is
correct, then the timestamp on the file is *not* coming from the system
clock. It's probably coming from whatever "gold copy" of the file is
being restored during startup.
There are *lots* of ways a file could be copied and retain the mtime of
the original file. "cp -a" is one of them.
unicorn:~$ cp -a .bashrc copy-of-bashrc; ls -lad .bashrc copy-of-bashrc; date
-rwxr-xr-x 1 greg greg 3329 Nov 12 08:28 .bashrc*
-rwxr-xr-x 1 greg greg 3329 Nov 12 08:28 copy-of-bashrc*
Fri Dec 1 17:05:52 EST 2023
unicorn:~$
Of course there are many others. Extracting a .tar.gz archive, for
example, is another way to do it.
You could look through the system startup stuff, wherever that is on
this operating system, and see if you find anything about restoring
factory default configuration files.
If you can't find it, the people who support this operating system might
be able to tell you exactly what's happening, and why. You really ought
to talk to them.
As a side note, copying a "gold standard" /e/n/i file which happens to
contain a comment *saying* that it's from Network Manager would retain
that comment, possibly leading to some confusion. One might argue that
the OS vendor should have replaced the comment with something more
accurate. (E.g. "This interfaces file is copied from ____ to /etc/network
at boot time. Do not edit this file in /etc/network. If you need to
modify it, edit it in ____ instead, but you do so at your own risk.")
That's another thing you could talk to the OS support people about,
assuming my guesswork holds up.
***********
Now let's talk about NTP. Originally you asked about installing and
configuring an NTP service on this printer. And you had some concerns
because you didn't know how to assign a static IP address to it.
However, you've stated a few times now that you *are* able to ssh into
it, from some other host on your network.
The fact that you can ssh into it means that it's got a working IP
address (either v4 or v6), and that your ssh client is able to determine
that IP address and connect to it. So, either it's already got a static
address, or your ssh client configuration is very clever, and knows
how to determine the printer's dynamic address.
In either case, the static-ness or dynamic-ness of the address is much
less important than the fact that the address *works*. You are able
to communicate with the printer, using your network.
This means the printer should be able to communicate *back*, and
specifically, it should be able to contact an NTP server on your network
to synchronize its system clock.
So all you should have to do is:
1) Determine which host on your network will act as your NTP server. Get
an NTP package installed and running on that host, and configure it
to allow connections from your LAN. You may select more than one if
you like.
2) Make sure the NTP server(s) are getting their time synced correctly,
most likely from public NTP sources on the Internet.
3) Install an NTP package on the printer, and configure it to use your
designated local NTP server(s).
4) Ensure that the NTP services all start at boot time, and don't get
their configuration files overwritten or anything like that.
If some part of this doesn't work, then please report the exact nature
of the failure, with details (commands and their output). Example
commands that would be useful in debugging might include:
date
ntpq -p
systemctl status ntp # or some sysv-rc equivalent
ls -ld /etc/ntp.conf
cat /etc/ntp.conf
journalctl -u ntp # if it's systemd-based; otherwise:
grep ntpd /var/log/syslog | tail -n20
You get the idea, I hope. Your logs might be in some other location.
Find them. Read them.
Reply to: