openplotter / openplotter-settings

Main OpenPlotter app
GNU General Public License v3.0
77 stars 13 forks source link

openplotter-settings is uninstalling chrony #24

Closed FredericGuilbault closed 1 year ago

FredericGuilbault commented 1 year ago

When it come to time servers chrony is more resilient than NTP when time sources are Unstable. It also dynamically support multiple time sources ( NTP, GPS, NMEA, serialRTC...)

It would be nice if the openplotter-settings package would not have a hard dependency on ntp which conflict any other time deamon providing pacakge. Resulting in having openplotter-settings uninstalling whatever else time-server. I'm actually using.

Best thing would be to check which time-daemon is installed and show the buttons accordingly, instead of deleting stuff on the OS.

To list all the time management software available :
apt-cache showpkg "time-daemon" | sed -e '1,/^Reverse Provides: *$/ d' -e 's/ .*$//' | sort | uniq To list the installed ones: dpkg-query -l [THE_PACKAGE_LIST] |grep ii | awk '{print $2}'

sailoog commented 1 year ago

The most common use of openplotter is sailing without internet and getting time and date from GPS via signal k server. We set ntp as dependency because is acting as a server by default and we want any device on-board to have the right time and date. But you may be right, ntp is very aggressive and there is a tendency to use chrony in all systems.

Chrony is not set as a server by default but maybe we can run 2 instances, client as default and server optionally using the current button in openplotter-settings app.

https://chrony.tuxfamily.org/faq.html#_can_ntp_server_be_separated_from_ntp_client

Maybe it's time to rectify

FredericGuilbault commented 1 year ago

getting time and date from GPS via signal k server

You mean via this signalk plugin ? https://github.com/SignalK/set-system-time

I added chrony support to it a while ago. https://github.com/SignalK/set-system-time/commit/0845ab44eeb885121f6b5693df48575014300c14

If I remember, it goes like this:

if chrony is installed
    and it receive a valid time source ATM, 
         don't do anything. 
    but if chrony don't have a valid source of time At the moment, 
         do manually set time from signalk to chrony ( so chrony still manage the OS time just don't query it  )

otherwise if chrony is not installed, set time via the cli with the date command. 

The logic was that, Chrony should be first choice as it can read GPS time directly from /dev/serial and even use PPS if available and dynamically switch time source as they become come and go. While if I recall, the signalk plugin run on an infinite loop with a sleep/wait timer plus potentially dependent on NMEA sentence frequency to get time. So it should be last resort IMO.

....And the worst option is screwing all the good tools we could use by manually forcing arbitrary imprecise time inside the date command itself. ( specially if you want it to act an authoritative time server )

But I don't think this plugin talk to NTP at all.


is acting as a server by default and we want any device on-board to have the right time and date

True, chrony serverMode is not enabled by default ( Im surprised that NTP is still tho. After all the DoS amplification attacks revealed ). In all case, I don't rly see the advantage to run 2 separate instance in regard of the complications concerning ports and configs, and user confusion. And probably breaking assumptions of other components of the ecosystem we don't even think about like : upstream firewalls, apparmor/PAM rules, unattended updates, UFW rules....

Quick reading of the doc looks like it's a story of adding 1 line in a config file and restart to have the server running.

So something like : ENABLE : echo "allow 192.168.0.0/24 # Automatically added by openplotter" >> /etc/chrony.conf && systemctl restart chrony DISABLE: sed -i '/^allow\ .*\#\ Automatically\ added\ by\ openplotter$/d' /etc/chrony.conf && systemctl restart chrony

Would probably be enough, IMO ( more testing would be required to be affirmative )

Do you add those kinds of things all inside openplotter-settings or you do a wrapper package ?

sailoog commented 1 year ago

I have found more side effects of having ntp as time server, so you are right we should switch to chrony. I think I have found a way to rectify without pain. I will let you know when I have something to test.

sailoog commented 1 year ago

published new version of openplotter-settings removing ntp dependency and NTP server moved to openplotter-network using chrony. However the chrony detection in signal k is not working and it is always changig time. GPS and NTP time have different accuracy and you get certifications errors when updating packages. Basically the same issue you reported here: https://github.com/SignalK/set-system-time/issues/6

sailoog commented 1 year ago

more details: https://github.com/SignalK/set-system-time/issues/12

sailoog commented 1 year ago

closed by https://github.com/openplotter/openplotter-settings/commit/6872a4e3d417da2d230bcd7f61fd32600695ece2 and https://github.com/openplotter/openplotter-network/commit/91e0cb410435dfbc17447ed0d7bf8b508666b5d4

FredericGuilbault commented 1 year ago

thx :)