On Thu, Sep 20, 2018 at 04:12:16PM -0700, Gaijin wrote: > On 2018-09-20 13:04, unman wrote: > > On Wed, Sep 19, 2018 at 07:50:59PM -0700, Gaijin wrote: > >> On 2018-09-19 07:36, Ivan Mitev wrote: > >> > On 9/19/18 9:22 AM, Gaijin wrote: > >> >> On 2018-09-19 05:22, Ivan Mitev wrote: > >> >>> On 9/19/18 5:17 AM, Gaijin wrote: > >> >>>> Running Qubes R3.2 > >> >>>> > >> >>>> I have some software that I run in an AppVM that needs to be accurate > >> >>>> to > >> >>>> within a second or two of NTP server time in order to work. I have > >> >>>> finally figured out how to get my ClockVM to sync to an NTP server and > >> >>>> for timesyncd.service to run when sys-net boots. > >> >>>> > >> >>>> My problem is that my AppVM slowly loses several seconds after some > >> >>>> time, and I can't figure out a way to manually or automatically force > >> >>>> it > >> >>>> to resync itself. > >> >>> > >> >>> I don't have a R3.2 to test, but if it's like R4 your VM has a systemd > >> >>> timer that updates the time every 6 hours [1]. In that case you could: > >> >>> - change the definition of the timer so that it's run more frequently > >> >>> - disable the timer and run a ntp client ; that'll be the best solution > >> >>> if your software is very time sensitive, but it increases the attack > >> >>> surface because of the ntp client. > >> >>> > >> >>> > >> >>> [1] > >> >>> https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md > >> >> > >> >> How might I adjust the schedule of qubes-sync-time.timer in the AppVM if > >> >> that is available in R3.2? That looks like a safer way to proceed if > >> >> possible. > >> > > >> > Provided that R3.2 time sync mechanism is the same as R4, you could > >> > paste the following text into /etc/systemd/system/qubes-sync-time.timer: > >> > > >> > [Timer] > >> > OnUnitActiveSec=10min > >> > > >> > > >> > Doing so allows you to override stuff from > >> > /usr/lib/systemd/system/qubes-sync-time.timer and preverve your changes > >> > in case the original unit file is updated. > >> > > >> > Then reload the definitions with `sudo systemctl daemon-reload` > >> > > >> > You can see the timer's status with `systemctl list-timers` > >> > > >> > If you want those changes to stick after a reboot, apply them in the > >> > TemplateVM you're using for your AppVM; alternatively you could add the > >> > new file to your AppVM's /rw/config and issue commands in the rc.local > >> > script there (copy the file + reload systemd). > >> > >> Looks like this would be easier in R4. The 3.2 doesn't have the > >> qubes-sync-time.timer or perhaps it's named something else. Would anyone > >> know which file might control this in 3.2? Or is there a way to make a > >> systemd timer in an AppVM to force Qubes to resync with the NTP server? > >> > > > > In 3.2 time synchronizing was somewhat different, so the advice re 4.0 > > doesn't help. > > You should not have needed to do anything special to the clockVM to get > > time syncing working there. Almost certainly you should revert those > > changes. > > I recall there was a cron job running every 6 hours : I believe > > you can find the cron file under /etc/cron.d in dom0 > > You could try changing the cron job to make the timer reset more > > regularly. > > > > You haven't said what period you are seeing the time drift occur, but > > change the frequency to something that preempts the drift without > > constantly firing off. > > > > Remember this is undoubtedly going to help fingerprint your system. > > > > unman > > What I had to do special in the ClockVM to get it working (Fedora 28 > minimal) was to follow the instructions here > https://github.com/QubesOS/qubes-issues/issues/3983 as systemd-timesyncd > wasn't starting. I have that working and the time syncing in the ClockVM > seems to be OK. > > My time drift comes in my AppVM (Fedora 28). Right now it's about 2 > seconds off after running overnight. In that the > systemd-timesyncd.service is not active. I thought the ClockVM was > supposed to control the time in the other VMs, so I haven't changed > that. > > I found the qubes-sync-clock.cron and switched it from 6 hours to 3 > hours and I'll leave the AppVM running to see if the drift fixes. >
Those instructions are for 4.0 and the mechanism in 3.2 is quite different. timesyncd is disabled under 3.2 in Qubes. You should not be enabling it. The Qubes mechanism is that dom0 triggers a call using ntpdate and then distributes that time to client qubes. The change you've made to the cron timer should help to stop the drift. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180922083306.vss5jhdztxfty5xw%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
