pkg fails if you don't set the system time

S

Steinhelten

Perhaps this will be self-evident to many of you folks out there, but it came as a total surprise to me. On systems without a battery-backed up clock, if you don't set the time, pkg may fail. Even though I have a timeserver and ntp server in my DHCP configuration, the RPI came up with the time as the image date (31 May). After I manually invoked ntpdate, pkg installed perfectly. This interdependence is mystical to me, but perhaps obvious to others, but I hope my experience will be useful to someone.
 
That goes for *any* communication that uses some form of encryption. Time on the machine needs to be "in sync" with time on the servers it talks too - if time is too far off the communication fails.
https - yes. SSL - yes. ssh - yes. And so on.
 
OK. This expands my understanding consideably. Thanks. I would like to mention that the first comment is a bit too broad - the relationship is asymmetric. I didn't try to use SSH to connect out from the machine, but it is "headless" and it certainly accepted my incoming SSH connection - which is good, since being "headless" it otherwise would have been a brick.

Is some sort of remediation/impact reduction appropriate? Maybe include a warning message in the motd?
 
Steinhelten said:
I didn't try to use SSH to connect out from the machine, but it is "headless" and it certainly accepted my incoming SSH connection - which is good, since being "headless" it otherwise would have been a brick.
Click to expand...
SSH keys don't have a "Valid After" and "Valid Until" date stamp. So ssh(1) will work, even if the source and/or target date/time is completely off the mark. SSL certificates on the other hand do have a "Valid After" and "Valid Until" date/time stamp.
 
The default changed in the freebsd pkg repository from http to https, so you could simply use http instead of https if you are not concerned about data confidentiality.
In any case, pkg will verify that you get the correct packages, so it is not possible to change the data without pkg noticing.
 
Here's the deal, folks. My DHCP supplies "option time-servers". Other operating systems on the same hardware, including Raspberry Pi OS (formerly known as Raspbian) use that and set the time. Nothing had called my attention to the fact that the system time was not set appropriately. As soon as I realized that the system time was not set, I issued the "ntpdate" command to the time server and the problem went away. Even a very experienced FreeBSD individual whom I will not name at this moment didn't recognize the symptoms of what was causing pkg to fail (in a different topic). I just think it might be nice if we at least warned people of this potential pitfall, or even developed the capability that if DHCP supplies "option time-servers" that the system uses that to set the time.
 
Still requires a daemon to set the time, even if DHCP supplies a time-server. If I recall correctly there is an option to enable NTP during installation. Or enable it yourself of course.
 
Right! And - the reason I've never noticed this before is that my system building script does just that - invokes "ntpdate" and then "ntpd" - but I was just trying to build as "vanilla" a system as possible for a problem recreation scenario (two of them, in fact) so I didn't use my usual script, and I got stung - so I'm wondering if there are reasonable steps we could take to help others avoid this, or at least warn them. That's why I was taken by surprise by this - after building many systems, this situation had not arisen before. I realize it would take a daemon to set the time, but other operating systems do it, so it must be possible. I don't know how to query the dhclient.leases.if files/databases so maybe that's not easy - but if someone knows a simple solution, it might be nice, is all I'm saying. Ironically, I am explicitly giving the ntp server in the rc.conf file, so nothing on my FreeBSD systems is actually using the DHCP option, though the Linux and Windows systems do. Obviously, I'd prefer the more general and elegant solution, if there is one. I certainly appreciate all the time you folks have taken to help me sort this out, and I really hope that someone else out there may benefit from my experience, rather than getting stuck and confused as I was for a while.
 
Just as a small note here, for quite some time now there's no need to run ntpdate via /etc/rc.conf for most people (if ntpd is enabled.) ntpd_sync_on_start="YES" has ntpd doing more or less the same thing. However, neither one of these choices is right or wrong per se, and there might be corner cases where one or the other would be preferable.
 
cracauer@ said:
… enable ntpdate (and maybe ntpd) in /etc/rc.conf as a matter of principle on computers without battery.
Click to expand...

Code: 
% pkg info --list FreeBSD-ntp | grep rc
        /etc/rc.d/ntpd
        /etc/rc.d/ntpdate
% grep ntp /etc/rc.conf
ntpd_enable="YES"
ntpd_sync_on_start="YES"
% less /etc/rc.d/ntpdate
% grep desc /etc/rc.d/ntpdate
desc="Set the date and time via NTP"
% sudo rg --count --sort path ntpd_sync_on_start /etc
/etc/defaults/rc.conf:1
/etc/rc.conf:1
/etc/rc.d/ntpd:1
%
 
adorno said:
Just as a small note here, for quite some time now there's no need to run ntpdate via /etc/rc.conf for most people (if ntpd is enabled.) ntpd_sync_on_start="YES" has ntpd doing more or less the same thing. However, neither one of these choices is right or wrong per se, and there might be corner cases where one or the other would be preferable.
Click to expand...
Thanks! I like it. I'll change my scripts to do this instead. I still wish there was a way to automatically set the time server from the DHCP options.
 
SirDice said:
SSH keys don't have a "Valid After" and "Valid Until" date stamp. So ssh(1) will work, even if the source and/or target date/time is completely off the mark. SSL certificates on the other hand do have a "Valid After" and "Valid Until" date/time stamp.
Click to expand...
Can pkg not just assume a time for the download process without requesting the system clock or does this have to comply with (POSIX?) security policy?
 
You must log in or register to reply here.
Back
Top