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.